Subject: Re: mbone routing failure

From: Bill Fenner <[email-masked]>
Date: Mon, 21 Apr 1997 12:18:30 PDT

>I can mtrace stockholm fine, but just end up following a bogus default
>to symantec when I trace to mtrace one hop beyond it to broodjeham.

That's because broodjeham's physical interfaces are disabled, so
there's nowhere to trace to.  You have to go one hop beyond:

sandbox% mtrace 131.174.72.129
ld.so: warning: /usr/lib/libc.so.1.8 has older revision than expected 9
mtrace: WARNING: no multicast group specified, so no statistics printed
Mtrace from 131.174.72.129 to 192.216.54.1 via group 224.2.0.1
Querying full reverse path... 
  0  sandbox (192.216.54.1)
 -1  disco-ext.parc.xerox.com (192.216.54.251)  DVMRP  thresh^ 32  
 -2  dodgedart.parc.xerox.com (204.162.228.7)  DVMRP  thresh^ 1  
 -3  ? (140.173.144.1)  DVMRP  thresh^ 1  
 -4  mbone.nsi.nasa.gov (192.203.230.241)  DVMRP  thresh^ 32  
 -5  dec3800-2-fddi-0.SanFrancisco.mci.net (204.70.158.61)  DVMRP  thresh^ 64  
 -6  paloalto-mbone1.bbnplanet.net (192.42.110.249)  PIM/Special  thresh^ 32  
 -7  collegepk-mbone1.bbnplanet.net (128.167.252.196)  PIM/Special  thresh^ 64  
 -8  ? (199.94.207.2)  PIM/Special  thresh^ 32  
 -9  schnell.ebone.net (198.67.134.250)  DVMRP  thresh^ 32  
-10  stockholm.mbone.ebone.net (192.36.148.206)  DVMRP  thresh^ 64  
-11  broodjeham.surfnet.nl (193.148.15.2)  DVMRP  thresh^ 48  
-12  wps9.uci.kun.nl (131.174.72.129)  DVMRP  thresh^ 32  
-13  wps9.uci.kun.nl (131.174.72.129)
Round trip time 520 ms; total ttl of 72 required.

If you can give specific subnets that you're wondering about, I can
tell you when they disappeared from the routing table at Xerox.

  Bill

---

From: dave pratt <[email-masked]>
Date: Tue, 22 Apr 1997 10:04:11 +0100 (BST)

Dear Bill, MBone community,

I was thinking of a possible improvement to mrouted, which may possibly
make it into a future release (3.9?).

A problem I have is that occasionally routes are only valid in a single
direction, and one end of a tunnel is marked as up and the other as
down. (This is unfortunately quite common when routes get lost, when
forward/return routes diverge, or when firewalls are present). This
causes Mbone breakage even when alternative routes exist.

I would like to see mrouted exchange a token(s) with it's neighbour to
confirm the tunnel is operating in both directions before the tunnel is
marked up.

This will be quite difficult with peers that have not been upgraded. 
However, is there some "version number" or something similar in the
present hello messages that could indicate that a reply token is
needed/supported ? If this were not possible then I guess manual
configuration in mrouted.conf could turn on this feature (once you know
the neighbour has been upgraded).

What do people think ?

Cheers
--------
Usual Disclaimers apply.
WWW - doesn't that stand for "Wait a Week Word" ?
   Nope - It's Wait a Week Windows !
Dave Pratt      (tel: +44 1473 643840 )
[email-masked]

---

From: Magnus Danielson <[email-masked]>
Date: Tue, 22 Apr 1997 12:13:22 +0200

>>>>> "dp" == dave pratt <[email-masked]> writes:

 dp> Dear Bill, MBone community,
 dp> I was thinking of a possible improvement to mrouted, which may possibly
 dp> make it into a future release (3.9?).

 dp> A problem I have is that occasionally routes are only valid in a single
 dp> direction, and one end of a tunnel is marked as up and the other as
 dp> down. (This is unfortunately quite common when routes get lost, when
 dp> forward/return routes diverge, or when firewalls are present). This
 dp> causes Mbone breakage even when alternative routes exist.

 dp> I would like to see mrouted exchange a token(s) with it's neighbour to
 dp> confirm the tunnel is operating in both directions before the tunnel is
 dp> marked up.

You obviously wants the mrouted to build a link state. In a way, this
is not a bad idea. I have had cases where mrouted thinks the link is
up in both directions, yeat no multicast trafic will get
througth. This is usually due to the fantastic support and bugfree
software surrounding some unmentional network techniques, but could
occur even in normal cases as mentioned above.

There is obviously the general upgrade problem and then there is a lot
more of Cisco's and other router manufactors equipment out there than
it was during the 3.6->(3.7)->3.8 upgrade.

 dp> This will be quite difficult with peers that have not been upgraded. 
 dp> However, is there some "version number" or something similar in the
 dp> present hello messages that could indicate that a reply token is
 dp> needed/supported ? If this were not possible then I guess manual
 dp> configuration in mrouted.conf could turn on this feature (once you know
 dp> the neighbour has been upgraded).

Or the oposite way, you need to make specific notage of disabeling the
function, since we will want this to be the default case, right?

 dp> What do people think ?

Based from my debuging experience it is not such a bad idea. Better
point-to-point status is needed to aid the debugging. I would
even propose to have these levels:

0 Disabled (just as today)
1 Down (no unicast or multicast)
2 Sensed (mrouted handshaking/unicast connectivity, no multicast)
3 Up (mrouted handshaking and multicast token/packet capable)

The up state is only reached when both sides both been in sensed state
and agreed that the multicast connection is bidirectional.

The sensed state is reached whenever an router heard an hello packet
from it's neighbor.

This is not all that diffrent from todays scheme.

I can imagine that this approach can possibly create other problems,
so you DVMRP experts, yell out :)

Cheers,
Magnus

---

From: Tom Pusateri <[email-masked]>
Date: Tue, 22 Apr 1997 10:45:04 -0400

>confirm the tunnel is operating in both directions before the tunnel is

Currently, in the most recent DVMRP spec, it says:

  |In order to minimize one-way neighbor relationships, a router MUST
  |delay sending poison route reports to a neighbor until the neighbor
  |includes the routers address in its probe messages. On point-to-point
  |interfaces and tunnel pseudo-interfaces, this means that no packets
  |should be forwarded onto these interfaces until two-way neighbor
  |relationships have formed.

I believe this is similar to your request. After all, if no
poison routes are exchanged, then packets shouldn't be forwarded.
The biggest problem is getting older implementations upgraded to
adhere to this.

Let me know if you think this is sufficient or if additional changes
should be included in the spec. The latest version is available
from http://www.jnx.com/~pusateri/dvmrp

Thanks,
Tom