All things related to multicast

[bdr <>]

FWIW - I talked with Lauire about some of these issues this week.  We 
thought we might try a couple of things, using iperf.  We thought we 
might do a traceroute from each of the endpoints to the other.  Then we 
thought we might try some multicast using iperf between UMich and the 
Merit GigaPop, then between UMich and the first Abilene node, then  
between UMich and the next Abilene node, working our way out to Stanford 
- measuring setup time, RTT, and reliability. 

Seemed like trying to identify the network node(s) where the problems 
are occuring might be a good place to start. 

Laurie - what did I forget?



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:
--
Bob Riddle 
()
    Technologist,Internet2
3025 Boardwalk, Suite 100         Ann Arbor, Michigan  48108
Business Phone: 734.913.4257      Fax Number:  734.913.4255

"Never be afraid to try something new.  Remember that amateurs built the Ark.  
Professionals built the Titanic."  Dave Barry