Subject: RE: How to run with a minmal DVMRP table using IOS

From: Arlie Davis <[email-masked]>
Date: Tue, 18 Feb 1997 18:32:58 -0500

Uh, just because it works.  The tunnel sequence-datagrams is just
experimentation, left over from long ago.  The text on the page is from
a real configuration, not just invented, so there are some things there
that are not essential to the purpose of the page.

The fast switching is disabled because I have not yet moved that machine
to a version which has fixed fast switching.  I'm sure you can
understand being cautious about firmware upgrades on important machines.

>-----Original Message-----
>From:	Toerless Eckert [SMTP:[email-masked]]
>Sent:	Tuesday, February 18, 1997 6:26 PM
>To:	Arlie Davis
>Cc:	[email-masked]
>Subject:	Re: How to run with a minmal DVMRP table using IOS
>
>> I've gotten so many messages about running with a minimal DVMRP table
>> that I wrote up a quick page on how to do it, with most of my
>> configuration.
>> 
>> The URL is http://tis-www.thepoint.net/minimal-dvmrp.htm .  If you have
>> any comments on this / suggested changes, let me know.
>
>There are some obstacles as to your URL's description.
>
>1. I don't know why i would want to have 
>
>   "tunnel sequence-datagrams"
>
>   because even though it's a tunnel it's still datagram service and as
>   such misordering is a normal fact of life but still better than
>   packet loss.
>
>2. I also don't know why i should set
>
>   "no ip mroute-cache"
>
>   True, there have been a lot of problems with mroute-cache over the years,
>   but i'm not aware of any problem still surviving on this battlefield.
>   Even if there was one, i'd rather quickly report it. At least i don't
>   know how to run my routers without "mroute-cache", they'd simply overload.
>   (I am not quite sure about the speedups on tunnels though, meaning that
>    i've never willingly disabled it there to test).
>
>3. Providing only a dvmrp-default route to some stub-area in the mbone
>   is basically a nice thing that the cisco can do. Nevertheless you
>   should be aware, that not all multicast-software is able to run correct
>   multicasting with only a defaul-route supplied. I know definitely
>   that it is not supported in release 11 of Bay Networks dvmrp software
>   and i am quite persuaded that it won't work with current 3com  software
>   either (meaning: with 3com i still don't know a working support channel
>   to get real answers to technical questions). (no, please don't start
>   a war over this ;-). Nevertheless: it seems to work for all of my
>   tunnels going down to other ciscos (what a surprise) and for mrouted3.8
>   downstream. I guess that's the majority of mbone routers.
>
>[Arlie Davis]  I'll make a note of this.  All my mrouters are either Cisco's
>running recent firmware or mrouted 3.8.
>
>4. To make life much more easier, i always recommend not only to use
>   an
>
>   "ip unnumbered <if>" 
>
>   command, but also to use the same address as the tunnel source address
>   of all tunnels. This way, you've got the same simple config as with
>   mrouted, at least when it comes to the ip-addresses locally being used
>   for multicasting, i.e.:
>
>   tunnel source <if>
>
>[Arlie Davis]  
>This is necessary for one of my tunnels, because the tunnel does not share
>the same IP address as any real (physical) interface.  Again, this is just an
>artifact of a "real machine".
>
>5. I don't think that it is such a great idea to go for dense-mode PIM
>   with some DVMRP unicast-routing for your local area network. Just for this
>   crap to go away, PIM was made. In my experience the most painless
>   thing with IOS multicasting was always sparse-mode PIM in my local
>   network. I could just configure it everywhere and never had to worry
>   about any useless multicast traffic or dvmrp routing loops. The
>   worst thing that can happen there, as to my experience is that
>   multicast traffic does not arrive if something is misconfigured.
>
>[Arlie Davis]  
>Look, if I had the option, I would totally do away with DVMRP.  But I don't
>yet have the option, so I can't.  I still have quite a few paths that require
>DVMRP.
>
>6. One should clearly make a distinction between a full-mbone router
>   and a stub router. In your configuration it seemed to me as
>   if the one router carrying the full mbone routing table gotan
>
>   "ip mroute 0.0.0.0 0.0.0.0"
>
>   into his routing tables too. I would not recommend this. Either you carry
>   the full mbone-dvmrp routing tables, then you should not have a 0.0.0.0
>   multicast default route, or you do not, but then you should get the
>   dvmrp-default route through dvmrp, and not through a statically
>   configured "mroute".
>
>[Arlie Davis]  True.  I'll clarify this.
>
>7. If you start out using a multicast-default route, you should always
>   very carefully check that RPF is working as you like it. If you do
>   not have a full mbone-dvmrp routing table and you have something like:
>
>   ip route  0.0.0.0 0.0.0.0 188.1.13.9 10
>   ip mroute 0.0.0.0 0.0.0.0 tunnel     1
>
>   cisco% show ip rpf 123.123.0.0 ! something not in your routing table
>
>   will still show toward the unicast route, so basically:
>
>   a "mroute" command will work only if the same network is in the
>   unicast-routing table, with the exception of a 0.0.0.0 route where
>   it will only work as a dvmrp route (to my experience).
>[Arlie Davis]  
>I'll throw this in, as well.
>
>Best regards
>	Toerless
>  
>
>[Arlie Davis]  Thanks for the comments...
>
>-- arlie

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 19 Feb 1997 00:38:47 +0100 (MET)

> understand being cautious about firmware upgrades on important machines.

Sure, but if you want to give recommendations it is good to make
people understand when there are specific things that are most likely
not true for them. On a tunnel link with load balancing i can imagine
the sequence-datagrams a real pain and as for the mcast disabling
it's the same.

Best regards
	Toerless

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 19 Feb 1997 09:47:46 -0800

>> that are not essential to the purpose of the page.

    "tunnel sequenced-datagrams" works only for GRE tunnels.

Dino