Subject: Outgoing mbone OK?

From: Don McGregor <[email-masked]>
Date: Tue, 10 Feb 1998 12:07:08 -0800 (PST)

I'm attempting to trouble shoot some mbone problems.
Our incoming feed is OK, but I suspect our outgoing
packets are getting lost.

If anyone can see "VRML98" or "dis-java-vrml" in sdr,
drop me a line.

---

From: Beau Williamson <[email-masked]>
Date: Tue, 10 Feb 1998 16:42:07 -0600

Not seeing either one here in Cisco.

Beau Williamson

---

From: [email-masked] (Jeremy Hall)
Date: Tue, 10 Feb 1998 23:14:34 -0500 (EST)

nor at UUNET.

---

From: Bill Fenner <[email-masked]>
Date: Tue, 10 Feb 1998 21:51:38 PST

I'd suggest doing something like
"mtrace -S 300 -g fixw-mbone.nsn.nasa.gov <your-sdr-machine> 224.2.127.254"
to try to figure out where your packets might be getting lost.

  Bill

---

From: Bill Fenner <[email-masked]>
Date: Tue, 10 Feb 1998 22:26:42 PST

If you're using an address inside 131.120/16, it looks like your
problem is that 10.10.10.10 and 12.12.12.12 are advertising a route for
131.120/16.  "Prune sent upstream" is a classic symptom of a Cisco
which is configured to advertise a route that it's not using to forward
multicast.

  Bill

Mtrace from 131.120.0.0 to 192.203.230.243 via group 224.2.0.1
Querying full reverse path... * switching to hop-by-hop:
  0  FIXW-MBONE.NSN.NASA.GOV (192.203.230.243)
 -1  FIXW-MBONE.NSN.NASA.GOV (192.203.230.243)  PIM/Special  thresh^ 0  -40 s    [131.120/16]
 -2  mae-west-mbone.ibm.net (198.32.136.110)  PIM/Special  thresh^ 0  -40 s    [131.120/16]
 -3  ? (206.13.16.254)  PIM/Special  thresh^ 0  -40 s    [131.120/16]
 -4  ? (10.10.10.10)  DVMRP  thresh^ 64  -159 s   Prune sent upstream [131.120/16]
 -5  * * * * ? (12.12.12.12) didn't respond

---

From: Don McGregor <[email-masked]>
Date: Tue, 10 Feb 1998 22:44:04 -0800 (PST)

> 
> If you're using an address inside 131.120/16,

Yes

> it looks like your

Eh? I'm not particularly conversant on all this. 10 is a private
net, right? But what's 12? (I'm caught in the middle here, attempting
to track down a problem for someone else.)

Routing stuff: we're supposed to have all outgoing traffic going
over dren.net, but incoming traffic is coming over a T1 to pacbell.
As I recall, dren doesn't do mcast routing, but pacbell does. Are 
the symptoms here (seeing incoming mbone, no outgoing mbone)
consistent with dren dumping outgoing mcast packets?

And if so, what's the best way to fix this?

---

From: Bill Fenner <[email-masked]>
Date: Tue, 10 Feb 1998 23:00:20 PST

12.12.12.12 is an address that someone made up and started using.  Only
the person who made it up can tell us who they are.

You have one or more multicast routers.  One or more has a connection,
whether native or tunneled, to a service provider who provides you with
multicast service.  Either that router, or your provider's router, is
misconfigured to not advertise proper routes for your site.

In addition, some router which may or may not belong to Pac Bell
Internet (PBI owns the address before the private addresses in the
mtrace) is advertising your route.  This does not appear to be
correct.

Both of these problems need to be fixed before you will be able to
transmit multicast.  (Since you say you think you get multicast service
from PBI, they may be related, or may even be the same problem.)

  Bill

---

From: Bill Fenner <[email-masked]>
Date: Wed, 11 Feb 1998 08:39:43 PST

Turns out that 10.10.10.10 is an NPS router (aka 131.120.252.255 and
epsilon.nps.navy.mil).  So it's the NPS router that's misconfigured to
RPF to 12.12.12.12 for most NPS sources.  Why is NPS using 10.10.10.10
for their tunnel to PBI instead of their public addresses?

  Bill