All things related to multicast

[Jimmy Kyriannis <>]

If Lea or anyone else has the Cisco BugID (assuming it's one of those 
which are "publicly" viewable on Cisco's BugTracker), that would be 
helpful, since it'll help other I2 multicast participants determine 
if they're running affected code as well.

Thanks,


Jimmy


At 09:54 AM 11/11/2005, Russ Hobby wrote:
> Any thoughts on how we can resolve this problem and more importantly 
> detect where it is happening before the researcher has to complain 
> about it?  It is still going on without resolution for Steve on his 
> link to UMich .  It is just a matter of time when they try the next 
> location and find the problem.
>
> Russ
>
> At 08:57 PM 10/26/2005, Steven Senger wrote:
> > Well it has been a while since I got out of class but other things
> > interrupted.
> >
> > One caveat. I'm not a network engineer and I almost certainly don't
> > use the correct terminology but here goes.
> >
> > Lea has described the problem we were seeing in CENIC and Stanford.
> > From my point of view the symptoms were a little more exciting then
> > the short description implies. When we first started this we would
> > see setup delays in excess of 10 minutes before traffic would start
> > flowing. Going from Abilene to CENIC in LA changed from Juniper to
> > Cisco and when we finally got an answer from Cisco it had to do with
> > a difference in implementation on how the routers handled the
> > encapsulated and non-encapsulated cases. The result was that traffic
> > sourced in Wisconsin would not show delays going to Stanford but
> > traffic sourced from Michigan would. The solution was that Cisco was
> > changing their behavior to agree with Juniper. When tech support
> > finally told us this, after several months of on and off testing, it
> > was rather anticlimactic but did fix the problem in CENIC.
> >
> > Once that problem was solved we found that there is still a small
> > amount of setup delay (0 - 45 sec, measured every hour) between the
> > source in michigan and Merit. It presumably has a similar cause but
> > has not yet been solved.
> >
> > We are also seeing a weird situation in WiscNet. We first stumbled
> > upon this using Access Grid between Wisconsin and Stanford. Things
> > would work correctly for weeks at a time and then one day the video
> > traffic from Wisconsin would not get to Stanford but the audio
> > traffic would or vice versa. I eventually figured out that I could
> > source traffic from Wisconsin on a group and have it arrive at
> > Stanford without problems. But starting a receiver for the group on
> > my campus would block the traffic from getting through WiscNet. So
> > far we have determined that there is a Juniper box in WiscNet that is
> > misbehaving. Restarting the rpd process on the box corrects the
> > situation and it will stay working for a month or more but will
> > eventually fail. When it is failing, in addition to the basic
> > behavior of local receivers blocking outbound traffic, there seem to
> > be a number of other odd behaviors that I have not fully cataloged.
> >
> > I don't think we are trying to do the impossible but any help would
> > be greatly appreciated.
> >
> > - steve
> >
> > On Oct 25, 2005, at 11:39 AM, Lea Roberts wrote:
> >
> > > hello everyone!
> > >
> > > the simple answer is that it was an MSDP propagation issue for an ASM
> > > application.
> > >
> > > the bug was in Cisco IOS (I can look back for the bug ID if there's
> > > any
> > > interest) where the remote source address would take tens of
> > > seconds to
> > > propagate from one router to the next...  once we zeroed in what was
> > > happening, it took a while to get the answer but once the code was all
> > > upgraded things have been workihg fine in the normal path.  Now
> > > I'll let
> > > Steve Senger comment on how they've continued to find other sites that
> > > need to upograde their Cisco routers...
> > >
> > > Lea Roberts
> > > Stanford Network Operations
> > >
> > > On Tue, 25 Oct 2005, Russ Hobby wrote:
> > >
> > >
> > > > I wasn't directly involved with the problem or the solution but I
> > > > will get
> > > > the details and report back. (or if any of you on the list were
> > > > involved
> > > > you can report directly ;-)
> > > >
> > > > Russ
> > > >
> > > > At 06:01 AM 10/25/2005, Russ Hobby wrote:
> > > >
> > > > > Hi All,
> > > > >
> > > > > I have been asked a question from a researcher who's project has
> > > > > been
> > > > > trying to use multicast for some time with many problems, and she
> > > > > asked me
> > > > > "Are we trying to do the impossible?"
> > > > >
> > > > > Their particular use of multicast relies on multiple multicast
> > > > > connections
> > > > > and for them to be set up in a timely fashion.  It is the setup
> > > > > time for a
> > > > > connection with which they have been having trouble.  Connections
> > > > > can take
> > > > > up to several minutes to be established.  They have worked the
> > > > > problem out
> > > > > with a couple of campuses and a gigapop to get it to work (which
> > > > > had to
> > > > > wait for new router codes to be installed in several places).
> > > > > However
> > > > > every time they go to a new site, they are likely to have the
> > > > > problem
> > > > > again and they have to work it through those network engineers.
> > > > >
> > > > > So the researcher is asking if they should give up on multicast and
> > > > > redesign their application.  What do you think?
> > > > >
> > > > > Russ