Subject: dis-java-vrml

From: Yves Lepage <[email-masked]>
Date: Fri, 13 Feb 1998 16:17:30 -0500

Hello,

I understand that dis-java-vrml is supposed to be mcasted but nobody can
see the advertisement (from conversations on this list).

Is it because the session is not going to be mcasted or is there another
reason?

Would it be possible for me to get the related group addresses and
origin IP of the session so I can do a bit of debugging up here
(Canada)?

Thanks  a lot,

Yves Lepage

---

From: Don McGregor <[email-masked]>
Date: Fri, 13 Feb 1998 19:05:45 -0800 (PST)

> Is it because the session is not going to be mcasted or is there another

There are campus routing problems that prevent outgoing mcast,
to my great frustration. We're attempting to get those problems solved 
before vrml98 next week.

> origin IP of the session so I can do a bit of debugging up here

There's supposed to be an mcast session going out on 
224.2.181.145, port 62040, from the machine electric.stl.nps.navy.mil.
that machine will probably be torn down sometime this weekend
so it can be used at vrml98.

---

From: Don Brutzman <[email-masked]>
Date: Sat, 14 Feb 1998 08:17:49 -0800

> Is it because the session is not going to be mcasted or is there another

The session is being advertised with ttl 127 from 
blacknoise.stl.nps.navy.mil 131.120.63.33

There is a problem with our campus routing/mrouting which is preventing
this from going out.  We've had some help diagnosing (from folks on this
list and from cisco tech support) but our router sysadmin has not
gotten it working yet.

The problem may have to do with
There is definitely a problem with bogus IP numbers 10.10.10.10 and 
12.12.12.12, which she says are 

-- 
all the best, Don
-- 
Don Brutzman  Naval Postgraduate School, Code UW/Br Root 200  work 408.656.2149
              Monterey California 93943-5000 USA              fax  408.656.3679
Virtual worlds/underwater robots/Internet http://www.stl.nps.navy.mil/~brutzman

---

From: Don Brutzman <[email-masked]>
Date: Sat, 14 Feb 1998 08:41:56 -0800

[corrected copy, please ignore earlier incomplete version]

There is a problem with our campus routing/mrouting which is preventing
dis-java-vrml from going out.  We've had some help diagnosing (from folks 
cc:ed on this message and from cisco tech support) but we have not been able
to get our mrouting working properly yet.  Major symptom:  we can see
global MBone sessions coming in, but cannot send past our campus.

The problem likely has to do with RPF (?) and bogus IP numbers 
10.10.10.10 and 12.12.12.12.  I wasn't able to follow her
explanations of why these were needed, apparently they have something
to do with loopback (on a router?) and the box crashed when she tried
alternatives.

Terry Gentry <[email-masked]> wrote:
> I can see routes in the mroute tables for 
>
> 131.120.63.33/32, 224.2.127.254), 00:02:27/00:00:29, flags: PT
>   Incoming interface: Tunnel1, RPF nbr 12.12.12.12, Dvmrp
>   Outgoing interface list: Null
> 
> (131.120.63.33/32, 224.2.172.238), 00:01:36/00:01:21, flags: PT
>   Incoming interface: Tunnel1, RPF nbr 12.12.12.12, Dvmrp
>   Outgoing interface list: Null
> 
> (131.120.7.91/32, 224.2.181.145), 00:00:00/00:02:58, flags: PT
>   Incoming interface: Tunnel1, RPF nbr 12.12.12.12, Dvmrp
>   Outgoing interface list: Null
>   
> The incoming interface is the tunnel I have set up through 
> the firewall.
> 
> I talked with PacBell Internet and when I had them do a 
> sh ip dvmrp route 131.120.0.0 on their router they see 
> us coming in. [...]

Our ISP for MBone is PacBell Internet.  The situation is complicated
by our recent simultaneous connection to DREN (which reportedly
doesn't support multicast, yet).

Terry, please provide:

- router make, model, current operating system version/revision
- pertinent multicast routing table entries
- identify upstream mrouter
- point of contact on upstream side, and cisco tech rep who has
  been working with you 
- send the pacbell/cisco contacts a copy of this message
- any other symptoms/results you want to report

> origin IP of the session so I can do a bit of debugging up here

Sure, thanks.  Our DIS-Java-VRML MBone Testing page has full detail at
http://www.stl.nps.navy.mil/dis-java-vrml/MBoneTesting.html

We still hope to multicast the SIGGRAPH/SIGCOMM VRML 98 symposium
next week - tutorials monday/tuesday, program wednesday/thursday.
Wireless bridge to the hotel was successfully established yesterday.
http://ece.uwaterloo.ca/vrml98

Thanks anyone who can help us resolve this months-long problem.

all the best, Don

---

From: Bill Fenner <[email-masked]>
Date: Sun, 15 Feb 1998 22:51:17 PST

>>   Outgoing interface list: Null

Here's one problem - your router doesn't think that PBI wants the
traffic.  Perhaps someone who knows something about ciscos can help you
debug this one.

The mtrace for this source and group looks like:

Mtrace from 131.120.63.33 to 192.203.230.243 via group 224.2.127.254
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  -41 s    [131.120/16]
 -2  ? (198.32.136.110)  PIM/Special  thresh^ 0  -41 s    [131.120/16]
 -3  ? (206.13.16.254)  PIM/Special  thresh^ 0  -41 s    [131.120/16]
 -4  ? (10.10.10.10)  DVMRP  thresh^ 64  -162 s   Prune sent upstream [131.120/16]
 -5  * * * * ? (10.10.10.10) didn't respond

I can't imagine how 10.10.10.10 (your router) decided that it was its
own previous hop, especially since the active cache entry shown above
says that the RPF neighbor is 12.12.12.12.  I know why it sent a prune
(the OIFlist is null, see above).

>> sh ip dvmrp route 131.120.0.0 on their router they see 

This has been true the whole time.  You're advertising your route to
PBI; it's what happens on your two routers (10.10.10.10 and 12.12.12.12)
that is causing your problems.  (BTW, you really shouldn't be using
12.12.12.12 as a private address, since net 12 is being assigned to
real people -- RFC1918 has plenty of legitimate fake addresses so that
you don't have to steal real ones)

>The situation is complicated

Well, nccosc-mbone.dren.net, arl-mbone.dren.net, cewes-mbone.dren.net,
nrl-mbone.dren.net, and wpafb-mbone.dren.net might disagree with you.
Of course, I don't have the whole picture, so I can't really comment.

If it helps, I saw the sdr advertisement at Xerox twice on Thursday;
at 11:39am and 6:28pm PST, and not at all since.

  Bill