All things related to multicast

[Laurence Kirchmeier <>]

Bob outlined our testing plan - namely to break down the path from UM  
to Stanford and try to test with intermediate nodes along the way.  I  
chose iperf because it can be used to generate a UDP multicast stream  
with a very small payload and providing one has access to the  
listening server machine, one can perfrom repeated tests whilst  
looking at the routers to see when they see the streams propagate.
The biggest problem I have faced is getting access to machines out of  
Merit regional network that are located on Abilene and are on subnets  
that can receive multicast.  Ideally I would like to get access to a  
machine on abilene in Chicago that I could ssh to and set up tests  
when Merit's network engineers are able to also look at the routers.
I have bwctl servers set up on Merit's network and can access the  
Internet2 testing infrastructure but bwctl does not allow me to set  
up a udp iperf server and then observe the server machine to see when  
the stream propagates. I'm also not sure that the iperf multicast  
commands are surfaced through the bwctl interface.

With regards to the CISCO IOS bug, Merit is not using any CISCO  
equipment in the path between UM & Abiliene so we can rule that out  
as an issue.

 Any help with access to an iperf box outside of Merit across at  
least one Abilene core node that can be used for repeated testing  
using low-bandwidth multicast streams would be most helpful at this  
time.

Laurie
_________________________________
Laurence Kirchmeier
Senior Engineer, Networking R&D
Merit Network Inc.              Tel. 734 936 9703
Email: 

     Fax. 734 647 3185
_________________________________



On Nov 11, 2005, at 8:57 PM, bdr wrote:

> 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