Skip to Content.
Sympa Menu

Subject: All things related to multicast

List archive


Chronological Thread 
  • From: "Marshall Eubanks" <>
  • To: Alan Crosswell <>,
  • Cc: , MboneD Mail List <>
  • Subject:
  • Date: Mon, 25 Jun 2001 21:47:40 -0400

Hello;

1.) I am cross posting this to mboned.

2.) Thanks for figuring this out. The 3 minute prune problem has
been bedeviling us for a while now.

3.) Right now we mbgp route to you through vBNS.
We do have announcements through Sprint - 1239 11537 3754 14 is
the path. We could set up a test through Sprint if
you thought that would be useful.

Or you could just set up an accessgrid beacon and listen to the beacon groups
- lot's of I1 choices there.

Regards
Marshall Eubanks

Multicast Technologies, Inc.
10301 Democracy Lane, Suite 410
Fairfax, Virginia 22030
Phone : 703-293-9624 Fax : 703-293-9609
e-mail :

http://www.on-the-i.com

Test your network for multicast :
http://www.multicasttech.com/mt/
Check the status of multicast in real time :
http://www.multicasttech.com/status/index.html

-------- Original Message --------
Subject: Columbia alternating prune problem fixed (worked around?)
Date: Mon, 25 Jun 2001 17:11:24 EDT
From: Alan Crosswell
<>
To:


I know many of you heard be talk about this at the Lincoln meeting or on
the list here....

We were having this problem where multicast sessions from I2 that crossed
our campus network would prune every 3 minutes and then come back 3 minutes

later. This appears to have been fixed. How? It's the unicast, stupid!

At least, fixing the unicast routing fixed the multicast problem. Namely,
we have two main exterior routers, one for I1 and one for I2 and a bunch
of interior routers (8 or 9 6509's running Cosmos). Our routing config
was set up such that the interior routers did not have full Internet routes

and used a default route to our I1 router which would then one-armed route
traffic to our I2 router. We knew this was dumb but didn't have our routing

together enough to inject I2-leared routes into our interior routers.

So, in debugging the pruning problem, it become apparent to our Cisco
TAC engineer after having me do a bunch of debugging that the SPT
calculation was causing the tree to be rooted at the I1 router while
the traffic was coming in to the I2 router. The I1 router is not
running any multicast protocols at all but it was on the reverse path
to the source. By doing a "ip pim spt-threshold infinity" we made the
the SPT recalculation stop happening. Then, since we just finished
upgrading our interior 6509 routers to MSFC/2's with 512M we were able
to turn on iBGP on them and, with a full routing table, the RPF was
now correct for these I2 sources. The errant pruning has stopped.

I wonder, though, with the MIX, if I were to get an I1 source would
this work correctly? The mcast would come in from I2 but the reverse
path would be via I1. I can't seem to find an I1 multicast source that
comes through from the MIX....

/a



  • [no subject], Marshall Eubanks, 06/25/2001

Archive powered by MHonArc 2.6.16.

Top of Page