Subject: Missing Announcements

From: Marty Hoag <[email-masked]>
Date: Thu, 12 Mar 1998 17:59:33 -0600 (CST)

For several days we have seemed to be "losing" some of the
announcements (SAP) here.  For example, the Berkeley Seminar was seen on
Monday but not on Wednesday.   #unix and NDSS'98 Symposium were missing
here yesterday but showed up today (well, #unix has dropped off here).

   Using a couple of the Web-based SDR pages (mSD and Precept) I got mixed
results.  Yesterday the Berkeley seminar was on neither of them and other
announcements would be on one and not the other.

   We did recently upgrade our mrouted to 3.9beta3 (the other end of our
tunnel is 3.8) but since I'm seeing things missing other places too I
wondered if there was a general problem or maybe just a lot of problems
with distribution.  Our mrouted had 6635 entries in its multicast routing
table this morning.

   I did run an mtrace to Berkeley from our mrouted machine when we
weren't seening the announcements.  I'll include it below as I'm a novice
at trying to read these...  134.129.90.208 (joy.cs.ndsu.nodak.edu is the
mrouted system and I traced on the SAP group / sap.mcast.net).

   Any suggestions for getting a handle on this would be appreciated.

   Thank you.

   Marty Hoag   [email-masked]

Mtrace from 128.32.131.87 to 134.129.90.208 via group 224.2.127.254
Querying full reverse path... * switching to hop-by-hop:
  0  joy.cs.ndsu.NoDak.edu (134.129.90.208)
 -1  joy.cs.ndsu.NoDak.edu (134.129.90.208)  DVMRP  thresh^ 1  
 -2  * * dec3800-2-fddi-0.Denver.mci.net (204.70.152.61)  DVMRP  thresh^ 64  
 -3  dec3800-1-fddi-0.WillowSprings.mci.net (204.70.104.29)  DVMRP  thresh^ 1  
 -4  * * * * mrouter.chi2.nap.net (207.112.240.150) didn't respond
 -5  * * 
Resuming...
 -4  mrouter.chi2.nap.net (207.112.240.150)  DVMRP  thresh^ 64  
 -5  fixw-mbone.nsn.nasa.gov (198.32.136.99)  PIM/Special  thresh^ 64  
 -6  * * ames-rt1.es.net (192.203.230.13)  PIM/Special  thresh^ 64  
 -7  * * lbl-mcp2p-ames.es.net (198.129.78.46)  PIM/Special  thresh^ 0  
 -8  * * * f5-0.inr-666-eva.berkeley.edu (198.128.16.21) [cisco 11.2] didn't respond
 -9  dilbert.CS.Berkeley.EDU (128.32.131.87)
Round trip time 160 ms; total ttl of 70 required.

Waiting to accumulate statistics... Results after 10 seconds:

  Source        Response Dest    Overall     Packet Statistics For Traffic From
   * * *        134.129.90.208   Packet      128.32.131.87 To 224.2.127.254
     v       __/  rtt 1626 ms     Rate       Lost/Sent = Pct  Rate
198.128.16.11  
198.129.78.46   lbl-mcp2p-ames.es.net 
     v     ^      ttl    1        51 pps        0/0    = --%   0 pps
198.129.78.45  
192.203.230.13  ames-rt1.es.net 
     v     ^      ttl   66        50 pps        0/0    = --%   0 pps
192.203.230.243
198.32.136.99   fixw-mbone.nsn.nasa.gov 
     v     ^      ttl   67       140 pps        0/0    = --%   0 pps
207.112.240.150 mrouter.chi2.nap.net 
     v     ^      ttl   68        50 pps        0/0    = --%   0 pps
204.70.104.45  
204.70.104.29   dec3800-1-fddi-0.WillowSprings.mci.net 
     v     ^      ttl   68         0 pps        0/0    = --%   0 pps
204.70.152.77  
204.70.152.61   dec3800-2-fddi-0.Denver.mci.net 
     v     ^      ttl   70         0 pps        0/0    = --%   0 pps
134.129.90.208  joy.cs.ndsu.NoDak.edu 
     v      \__   ttl   70         0 pps
134.129.90.208  134.129.90.208
  Receiver      Query Source

---

From: Bill Fenner <[email-masked]>
Date: Fri, 13 Mar 1998 09:55:05 PST

>mrouted system and I traced on the SAP group / sap.mcast.net).

You need to let the statistics collection run longer, since SAP
announcements are only sent occasionally.  "mtrace -S 300" increases
the statistics interval to 300 seconds (which should be enough to
see an announcement), or "mtrace -l" just runs statistics continually.

The reason that you can't read that mtrace is because 0 packets flowed
so it couldn't tell you anything about packet losses.

  Bill

---

From: Mark Handley <[email-masked]>
Date: Fri, 13 Mar 1998 13:04:01 -0500

>   Any suggestions for getting a handle on this would be appreciated.

What you are describing could be the result of many causes, but two
are likely - either a Cisco with the route-blaster bug could be
upstream of you and you're losing routes to some of the sources, or a
tunnel upstream from you might be configured with a rate-limiter that
is being saturated.  For historic reasons the SAP port falls in the
very-low-priority class of mrouted's rate-limiter, so SAP packets can
be consistently droppped under some circumstances.

Cheers,
	Mark