Subject: Configuring DVMRP between 2 Cisco's

From: Niels den Otter <[email-masked]>
Date: Fri, 14 Feb 1997 17:32:15 +0100

I have tried in many different ways to setup a DVMRP tunnel between two Cisco
routers, but I still have not succeeded yet. However configuring a tunnel from
the Cisco's to SUN machines running mrouted works perfectly well.

Can anyone tell me how to setup such a tunnel? What is the difference in
configuration between a tunnel between two Cisco's and between a Cisco and a
mrouted router?

The current configuration with respect to the tunnel interfaces is:
!
interface Tunnel3
 description Tunnel naar Utecht3
 ip unnumbered ATM4/0.3
 ip pim dense-mode
 ip multicast ttl-threshold 16
 no ip mroute-cache
 no ip route-cache
 tunnel source ATM4/0.3
 tunnel destination 145.125.8.2
!

AND 

!
interface Tunnel0
 description Tunnel naar Amsterdam6
 ip unnumbered ATM3/0.1
 ip pim dense-mode
 ip multicast ttl-threshold 16
 no ip mroute-cache
 no ip route-cache
 tunnel source ATM3/0.1
 tunnel destination 145.125.8.1
!

Thanks in advance,

Niels den Otter
SURFnet - Network Services

---

From: "Heiko W. Rupp" <[email-masked]>
Date: Fri, 14 Feb 1997 18:03:10 +0100

> the Cisco's to SUN machines running mrouted works perfectly well.

I guess that you have to issue a

tunnel mode dvmrp

command on each side ?!? Else the routers don't encapsulate the
multicast packets as they should in that tunnel.

 Heiko

-- 
NTG Netzwerk und Telematic GmbH   /          Heiko W.Rupp
Geschaeftsbereich Xlink         \/           phone: +49 721 9652 0
Vincenz-Priessnitz-Str. 3       /\ link      fax:   +49 721 9652 210
D-76131 Karlsruhe, Germany     /_______      email: [email-masked]

---

From: "Daniel A. Alvarez" <[email-masked]>
Date: Fri, 14 Feb 1997 09:10:49 -0800

> configuration between a tunnel between two Cisco's and between a Cisco and a

	Can't do it, you can use a GRE tunnel between two ciscos
	to connect two multicast clouds.  Look at the documentation
	in ftp://ftpeng.cisco.com/ipmulticast

dan

---

From: Niels den Otter <[email-masked]>
Date: Fri, 14 Feb 1997 18:09:45 +0100

==> From: "Heiko W. Rupp"

> multicast packets as they should in that tunnel.

Sorry, I didn't provide the correct configuration (I have tried a lot of
different configurations). 
The 'tunnel mode dvmrp' command is in the configuration on the tunnel
interfaces of both routers. 

I just found the following lines at a web page at Cisco:

> [no] tunnel mode dvmrp
> 
> Configures a tunnel to encapsulate IP in IP using protocol number 4. This mode
> can be used when a cisco connects to a mrouted machine to run DVMRP over a
> tunnel. This
> is a popular way to connect to the MBONE. It is required to configure PIM and
> an IP address or "ip unnumbered interface" on the DVMRP tunnel. The tunnel
> source and
> the tunnel destination must also be configured.

> Cisco does not support DVMRP tunnels between cisco routers.
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Is this still not possible? Or is it possible starting at a certain IOS
version. We use IOS 11.0(13) on both routers mentioned before.

Niels den Otter

---

From: "Daniel A. Alvarez" <[email-masked]>
Date: Fri, 14 Feb 1997 09:27:16 -0800

> multicast packets as they should in that tunnel.

	DVMRP tunnels from a cisco are only supported to connect
	to a mrouted box, to connect a DVMRP cloud to a PIM cloud,
	If you want to connect two PIM clouds across some non-multicast
	routers you need a GRE tunnel.

dan

---

From: "Jeff Young" <[email-masked]>
Date: Fri, 14 Feb 1997 12:28:21 -0500

as far as i know, you can't. by design.

Jeff Young
[email-masked]

> Return-Path: [email-masked] 
> Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160])
> 	by postoffice.Reston.mci.net (8.8.5/8.8.5) with SMTP id LAA28373;
> 	Fri, 14 Feb 1997 11:56:22 -0500 (EST)
> Received: by zephyr.isi.edu (5.65c/5.61+local-23)
> 	id <AA24493>; Fri, 14 Feb 1997 08:33:11 -0800
> Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
> 	id <AA24484>; Fri, 14 Feb 1997 08:33:09 -0800
> Received: from zephyr.isi.edu by venera.isi.edu (5.65c/5.61+local-26)
> 	id <AA01989>; Fri, 14 Feb 1997 08:33:09 -0800
> Received: by zephyr.isi.edu (5.65c/5.61+local-23)
> 	id <AA24463>; Fri, 14 Feb 1997 08:32:28 -0800
> Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
> 	id <AA24456>; Fri, 14 Feb 1997 08:32:26 -0800
> Received: from survis.surfnet.nl by venera.isi.edu (5.65c/5.61+local-26)
> 	id <AA01954>; Fri, 14 Feb 1997 08:32:21 -0800
> Received: from surah.surfnet.nl by survis.surfnet.nl with SMTP (PP) with ESMTP;
>           Fri, 14 Feb 1997 17:32:19 +0100
> Received: from surfnet.nl (actually host surah.surfnet.nl) 
>           by surah.surfnet.nl           with SMTP (PP) with ESMTP;
>           Fri, 14 Feb 1997 17:32:16 +0100
> Message-Id: <[email-masked]>
> To: [email-masked]
> Subject: Configuring DVMRP between 2 Cisco's
> Organisation: SURFnet bv
> Address: Radboudburcht, P.O. Box 19035, 3501 DA Utrecht, NL
> Phone: +31 302 305 305
> Telefax: +31 302 305 329
> Date: Fri, 14 Feb 1997 17:32:15 +0100
> From: Niels den Otter <[email-masked]>
> Sender: [email-masked]
> Precedence: bulk
> Content-Type: text
> Content-Length: 983
> 
>

---

From: "Daniel A. Alvarez" <[email-masked]>
Date: Fri, 14 Feb 1997 09:29:05 -0800

> version. We use IOS 11.0(13) on both routers mentioned before.

	Its still not possible and I doubt it will ever be.
	Cisco's DON'T run DVMRP, we just give you the means
	to attach to a DVMRP cloud.

dan

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 14 Feb 1997 18:29:37 +0100 (MET)

> multicast packets as they should in that tunnel.

Good guess, but it won't work. You cannot use a pure DVMRP tunnel
between two Cisco routers. Period. If you configure the "tunnel mode dvmrp",
then the tunnel will be a pure DVMRP tunnel and refuse to work if it's
both Cisco. So it will work only with one Cisco and something which is
not Cisco at the remote end.

The replacement of a DVMRP tunnel between two Ciscos is a
GRE tunnel with DVMRP being used for unicast routing. This
requires IOS >= 11.1-x, where X is (i think) something like 6 or 7.
Just use the current 11.1-9.

You then need to configure the tunnel like

    no tunnel mode dvmrp     ! just in case it's still there
    tunnel mode gre          ! redundant too if you start out with a new tunnel
			     ! because it's default
    ip dvmrp unicast-routing ! requires newer IOS as outlined above
    ip pim dense-mode        ! so that the tunnel runs in dense-mode

The effect is that you are actually running a PIM dense-mode tunnel, but
DVMRP routing information is still passed, as if you are using DVMRP.

Why do you need to do this ? :
If you look at it from a Cisco perspective, a DVMRP tunnel consists
of passing routing information via DVMRP and of using DVMRP for
multicasting (with regards to prune & graft and multicast tree building
properties).  Now Cisco thinks that dense-mode PIM has about the same
multicasting properties as DVMRP but is better. Now PIM requires you to get
the routing information from the unicast routing tables, which is the mayor
difference over DVMRP. So "ip dvmrp unicast-routing" effectively enables
that DVMRP is used to pass routing information, just like with a real
DVMRP-tunnel, but that multicasting is done with dense-mode PIM (this was
an easy solution to the problem: How do i get a different multicasting
topology between unicast and multicast when using PIM).

Generally you do not need to bother if you're using a DVMRP-tunnel to
some distant mrouted or a tunnel as outlined above to another cisco.
The problematic points (as to my experience) are in both cases the same.
What is the problem: It is that the cisco in terms of internal routing
between all attached interfaces always runs the PIM way, so you always
have to consider how the DVMRP and unicast routing information work
together. This behavior is not very difficult to understand, it is
just different from a pure DVMRP router that doesn't care about unicast
routing information at all (i've appended a readme to the end of this mail).
[ If you ONLY have dvmrp tunnels, AND if you do not use the DVMRP
  default route, you most likely have to consider nothing at all of
  your unicast routing ]

Side-note: you can as well run "sparse-mode" over the interface, but
then again you should consider how sparse-mode influences your life.
(Which is, in my opinion always positive but confusing ;-)

Hope this helps

Toerless

---

	How does RPF check pick the right unicast route ?

	  --- a DVMRP-PIM interoperability note

				      Last updated: 5/23/96
				      Liming Wei & Dino Farinacci

1. Interoperability

When PIM is interoperating with DVMRP, there are often multiple unicast
routing protocols running at the same time. This note explains the rules
for doing RPF (reverse path forwarding) check when more than one routing
protocol has a route for the same source.  DVMRP routes are treated
differently because of its presence in the MBONE.

2. Rules
 
Rule 1) When different routing tables have different distances,
        the one with the smallest value of distance is chosen;

Rule 2) When the distances are the same, DVMRP routes is preferred over
        other unicast routes.

Rule 3) When static mroutes are present, and configured with a
        distance value no greater than that of the DVMRP routes,
	the static mroutes are used.

Rule 4) Longest match routing is done among routes within the same
        routing table, but not across different tables.

Note that a bug (CSCdi578111) was found in the IOS software that violated
rule 4 above and did longest match routing across different tables. This
bug may affect multicast connectivity when the unicast topology differs
from the multicast topology. A software upgrade should be considered
if you think your network may have this problem. The following IOS
versions were known to be affected by this bug:

    10.2(11.1)  -- current,
    10.3(8.1)   -- current,
    11.0(4.0.1) -- 11.0 (8.2),
    11.1(0.12)  -- 11.1 (3.0.2)
    11.2(0.0)   -- 11.2 (0.8)

When in doubt, it is suggested that the command "show ip rpf <source>"
be used, to verify what table and what RPF information the router uses
for that source.

3. Routing anomaly in multi-home networks

In a multihomed PIM region, when a PIM-DVMRP border router advertises
a unicast route into the DVMRP cloud, the unicast route may eventually
be passed back to the other PIM-DVMRP border router, appearing as just
another DVMRP route. But this may not necessarily depending on the
topology and how the metrics are configured on the two border routers.

If the advertised unicast route does come back to the PIM border router
in the disguise of a DVMRP route, multicast forwarding should still work,
except, for some receivers packets may take a longer path than the
shorter one --- e.g. packets may exit at one router, going through
a DVMRP path then come back at the second border router and be forwarded
to receivers to the second border router.

If this happens, and if it is desirable to avoid this situation,
an "ip dvmrp accept-filter" command can be used at the second border
to reject the DVMRP routes for the local networks.

---

From: Bill Fenner <[email-masked]>
Date: Fri, 14 Feb 1997 09:35:00 PST

>tunnel mode dvmrp

Actually, I was going to suggest "tunnel mode gre"; I thought that
Ciscos refused to talk DVMRP-encapsulation between themselves.
You might also need "ip dvmrp unicast-routing".

  Bill

---

From: "John M. Zwiebel" <[email-masked]>
Date: Fri, 14 Feb 1997 09:51:34 -0800

And configure "ip dvmrp unicast-routing" on the two tunnel end points to 
pass the dvmrp routes between the two ciscos.

z

---

From: Paul Gray <[email-masked]>
Date: Fri, 14 Feb 1997 14:00:47 -0500

Dan,

What does "Cisco's DON't run DVMRP" mean. I am confused. I thought a
Cisco router
would participate in DVMRP routing exchanging the DVMRP unicast
routing information, etc. and base the forwarding of multicast datagrams
on the DVMRP routing tables. I always thought Cisco router could be part
of the DVMRP cloud and did not require a tunnel over it.

Paul

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 14 Feb 1997 20:04:39 +0100 (MET)

> of the DVMRP cloud and did not require a tunnel over it.

You know, technology far enough advanced is magic.
So in summary: everything you said is true but does not explain the problem.

;-)))

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 14 Feb 1997 11:13:12 -0800

>> Just use the current 11.1-9.

    Nope, it's 11.1(1). This feature actually went into 10.2(x), where x > 1.

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 14 Feb 1997 11:42:14 -0800

>> What does "Cisco's DON't run DVMRP" mean. I am confused. I thought a

    All it means is that we do not support a *DVMRP tunnel* between two
    cisco routers. We do support a DVMRP tunnel between a cisco and another
    mrouted compatible device.

Dino

---

From: "Daniel A. Alvarez" <[email-masked]>
Date: Fri, 14 Feb 1997 13:15:33 -0800

> of the DVMRP cloud and did not require a tunnel over it.

	Cisco will interchange unicast routes with the DVMRP side
	but the multicast forwarding mechanism is PIM not DVMRP.

	In other words the Cisco can use the "DVMRP unicast route"
	information for making its forwarding decisions, but it is
	PIM who created the multicast routing table and forwards the
	data.

dan

---

From: Andre Uratsuka Manoel <[email-masked]>
Date: Fri, 14 Feb 1997 19:27:11 -0200 (GMT-0200)

On Fri, 14 Feb 1997, Dino Farinacci wrote:

->>> The replacement of a DVMRP tunnel between two Ciscos is a
->>> GRE tunnel with DVMRP being used for unicast routing. This
->>> requires IOS >= 11.1-x, where X is (i think) something like 6 or 7.
->>> Just use the current 11.1-9.
->
->    Nope, it's 11.1(1). This feature actually went into 10.2(x), where x > 1.
->

	Yes, but you can't run 11.1(1) in MBONE, because of the rp-address
problem... The older you can use is 11.1(7), I think.

	Regards,
	Andre

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 14 Feb 1997 13:29:26 -0800

>> problem... The older you can use is 11.1(7), I think.

    Understand, I'm just informing people when it went in. The history is
    important to determine the stability :-)

Dino

---

From: Steve Deering <[email-masked]>
Date: Mon, 17 Feb 1997 15:24:49 -0800

I wish people would stop using the the expression "DVMRP unicast routing".
It is bound to confuse some folks into thinking it means routing unicast
packets via DVMRP, and heaven knows this stuff is confusing enough without
us making it worse with such misleading terminology.  How about we use the
expression "DVMRP route exchange" instead?

The other part of what DVMRP does, which PIM-DM does in a different way,
could be called "branch maintenance".

Steve