Subject: Odd behavior

From: [email-masked] (Alan Batie)
Date: Tue, 28 Jan 1997 14:36:25 -0800 (PST)

I'm getting very odd behavior with the SGI broad, er, multicast :-)

I start up vic/vat and it works as well as usual... for a few minutes.
Then it stops and all the members in vat grey out.  I stop and restart
vic/vat and everything starts up immediately and runs fine... for another
few minutes.  It's like the IGMP messages are getting lost after the first
join.  Previous sessions, e.g. the shuttle just a week or so ago, worked
just fine, but it seems to be affecting all sessions now (I just tried with
the Stanford Channel and it did it too).  In fact, mtrace shows it getting
pruned:

<mbone1.jf.intel.com> [532] $ sudo mtrace -g 192.198.161.3 150.166.61.12 224.2.191.112
Mtrace from 150.166.61.12 to 192.198.161.3 via group 224.2.191.112
Querying full reverse path... * switching to hop-by-hop:
  0  mbone1.jf.intel.com (192.198.161.3)
 -1  mbone1.jf.intel.com (192.198.161.3)  DVMRP  thresh^ 5  
 -2  MBONE2.UU.NET (137.39.246.98)  DVMRP  thresh^ 32  Output pruned
 -3  * dec3800-2-fddi-0.SanFrancisco.mci.net (204.70.158.61)  DVMRP  thresh^ 64  
 -4  * paloalto-mbone1.bbnplanet.net (192.42.110.249)  DVMRP  thresh^ 32  
 -5  * * * * sgi-too.SGI.COM (204.94.211.39) didn't respond
 -6  * * * 
 -7  * * * 
 -8  * * * ...giving up
Round trip time 271 ms

Results after 40 seconds:

  Source        Response Dest    Packet Statistics For     Only For Traffic
   * * *        224.0.1.32       All Multicast Traffic     From 150.166.61.12
     v       __/  rtt  252 ms    Lost/Sent = Pct  Rate       To 224.2.191.112
192.42.110.249  paloalto-mbone1.bbnplanet.net 
     v     ^      ttl   32     5787/8051 = 72% 201 pps     1/8    = --%   0 pps
204.70.158.61   dec3800-2-fddi-0.SanFrancisco.mci.net 
     v     ^      ttl   64      913/9670 =  9%   2 pps     0/7    = --%   0 pps
137.39.246.98   MBONE2.UU.NET  
     v     ^      ttl   65      165/3074 =  5%  76 pps     5/7    = --%   0 pps
192.198.161.3   mbone1.jf.intel.com 
     v      \__   ttl   66          2283         0 pps       2            0 pps
192.198.161.3   192.198.161.3
  Receiver      Query Source

mbone1 is running mrouted 3.8.

-- 
Alan Batie                     ------        What goes up, must come down.
[email-masked]        \    /        Ask any system administrator.
+1 503-264-8844 (voice)         \  /         --unknown
D0 D2 39 0E 02 34 D6 B4          \/          5A 41 21 8F 23 5F 08 9D

---

From: Bill Fenner <[email-masked]>
Date: Tue, 28 Jan 1997 15:17:51 PST

There's a bug in mrouted 3.8 where it will release its querier status
if it hears from an IGMP querier which is not a DVMRP neighbor.  When
the other querier goes away, mrouted will not become the querier.  The
solution is to kill and restart mrouted.

There's another bug in 3.8 where HUP'ing mrouted will cause it to
lose group memberships, so you should actually kill and restart it
instead.

  Bill

---

From: "Bill Nowicki" <[email-masked]>
Date: Wed, 29 Jan 1997 17:54:57 -0800

I do not think it is related, but thought I might explain
why your mtrace stopped at "sgi-too.SGI.COM". For the
replays on the second day, we sourced the multicast from
a lab inside our firewall. This actually seemed to work
better than trying to do it from a net strung up at
the last minute outside the firewall, which is what
we used for the live event and replays on the 27th.

Did anybody observe any differences? Other feedback would
be welcome too. Don't flame me for the corny songs. :-)