Subject: Re: Please don't use 11.1-MFIB with DVMRP-mode tunnels

From: David Meyer <[email-masked]>
Date: Tue, 31 Mar 1998 16:50:18 -0800 (PST)

Bill,
	
>>  Please don't use the 11.1-MFIB branch with DVMRP-mode tunnels.
>> There is a bug (which Cisco knows about and is working on) which
>> can cause DVMRP-mode tunnels to black hole all traffic flowing
>> through them.

	The basic problem is that when a downstream neighbor poisoned 
	the cisco, the tunnel didn't get put into the OLIST for the 
	(for that (S,G)). On inspection, it turns out that this
	occurs only when ip dvmrp unicast-routing is configured on
	a dvmrp tunnel. Turning off 'dvmrp unicast-routing' on the
	tunnel solves this problem. We'll harden this up (i.e.,
	check for 'ip dvmrp unicast-routing' on a dvmrp tunnel)
	so that this doesn't occur again.

	Dave

---

From: Göran Bengtson <[email-masked]>
Date: Wed, 1 Apr 1998 15:27:32 +0200 (MET DST)

On Tue, 31 Mar 1998, David Meyer wrote:

> From: David Meyer <[email-masked]>
> To: [email-masked]
> Cc: [email-masked], [email-masked]
> Message-ID: <[email-masked]>
> Date: Tue, 31 Mar 1998 16:50:18 -0800 (PST)
> Subject: Re: Please don't use 11.1-MFIB with DVMRP-mode tunnels
> 
> 
> 	Bill,
> 	

I've seen the same problem for 11.3(1 and 2) and it applies to both
tunnels and DVMRP-neighbors on LANs. On LANs the work-around may not
be feasible since 'dvmrp unicast-routing' may be needed for RPF-checks.

> 	Dave

		/ Göran Bengtson, Chalmers Univ. of Technology

---

From: [email-masked] (Jeremy Hall)
Date: Wed, 1 Apr 1998 12:03:49 -0500 (EST)

except you might not want to put ``tunnel mode dvmrp'' on a lan.

This does, however, raise an interesting point.

_J

---

From: "John M. Zwiebel" <[email-masked]>
Date: Wed, 01 Apr 1998 16:33:26 -0800

^ 
 ^ I've seen the same problem for 11.3(1 and 2) and it applies to both
 ^ tunnels and DVMRP-neighbors on LANs. On LANs the work-around may not
 ^ be feasible since 'dvmrp unicast-routing' may be needed for RPF-checks.
 ^ 

"ip dvmrp unicast-routing"  should _never_ be configured on a DVMRP tunnel
under any circumstances.  never ever.
 
------------------------------------------------------------------------------
	John Zwiebel                       Phone: 408-526-5303
	Cisco Systems Inc.                 
	Multimedia Group

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 1 Apr 1998 22:19:31 -0800 (PST)

>> under any circumstances.  never ever.

    And from now on, we will enforce that.

Dino

---

From: Göran Bengtson <[email-masked]>
Date: Thu, 2 Apr 1998 12:10:57 +0200 (MET DST)

On Wed, 1 Apr 1998, John M. Zwiebel wrote:

> From: "John M. Zwiebel" <[email-masked]>
> To: Göran Bengtson <[email-masked]>
> Cc: David Meyer <[email-masked]>, [email-masked],
>     [email-masked], [email-masked]
> Message-ID: <[email-masked]>
> Date: Wed, 01 Apr 1998 16:33:26 -0800

I agree (DVMRP-tunnels and DVMRP-based RPF-checks even worked before the
'unicast-routing' command was implemented, if I remember correct) - but:

1	This is not very clear from the Documentation.

2	It doesn't change the fact that I've seen the problem with
	a LAN-interface never showing up in the Olist for (S,G) if the
	downstream DVMRP-neighbor (the only one) on that LAN poisoned the
	route (or an aggreagate of the route). It clearly has to do with
	the changes made to use poisoned-reverse from downstream DVMRP-
	neighbors ("conditional flooding"). I've seen it in 11.3(1 and 2).
	I don't know if it present in the 11.1-MFIB too.

	In the case of DVMRP-neighbors on LAN, the 'ip dvmrp unicast-routing'
	is needed.

			/ Göran Bengtson
			  Chalmers Univ. of Technology

---

From: [email-masked] (Jeremy Hall)
Date: Thu, 2 Apr 1998 08:49:58 -0500 (EST)

yes, one would wonder what happens if you put ``tunnel mode dvmrp'' on a
lan interface so it would do the poisoning bit right.

_J

---

From: Bill Fenner <[email-masked]>
Date: Mon, 6 Apr 1998 15:33:29 PDT

Since IOS doesn't accept prunes from DVMRP neighbors on a LAN, you should
never have DVMRP neighbors on a LAN anyway, so the fact that it doesn't
work shouldn't be an issue.

  Bill

---

From: Göran Bengtson <[email-masked]>
Date: Tue, 7 Apr 1998 11:22:02 +0200 (MET DST)

On Mon, 6 Apr 1998, Bill Fenner wrote:

> From: Bill Fenner <[email-masked]>
> To: Göran Bengtson <[email-masked]>
> Cc: "John M. Zwiebel" <[email-masked]>, David Meyer <[email-masked]>,
>     [email-masked], [email-masked], [email-masked]
> Message-ID: <[email-masked]>
> Date: Mon, 6 Apr 1998 15:33:29 PDT

I pointed at the fact that when conditional flooding was implemeted, DVMRP-
interaction with a DVMRP-neighbors on LAN (10Mbps Ethernet in our case) ceased
to work, or to be more specific - the INTERACTION works but the output
interface to the downstream DVMRP-neighbor is never put in the O-list of a
(S,G) entry (S is upstreams from the DVMRP-router). From the description of
how and why the "conditional flooding" was implemented, I can understand that
a bug could be introduced.

DVMRP-interaction does otherwise work (and has done so for a long time) for
LAN DVMRP-neighbors when using "ip dvmrp unicast-routing" on the interface. I
don't believe that is a coincidence. Furthermore, unless that documentation is
totaly wrong, it states that it should work - se below for some excerpts. 

"PIM routers dynamically discover DVMRP multicast routers on attached networks."

"When Cisco routers are directly connected to DVMRP routers OR interoperate
with DVMRP routers over an MBONE tunnel."

"When a Cisco router runs DVMRP over a tunnel, it advertises sources in DVMRP
Report messages much as it does on real networks."

"By default, only 7000 DVMRP routes will be advertised over an interface
enabled to run DVMRP (that is, a DVMRP tunnel, an interface where a DVMRP
neighbor has been discovered, or an interface configured to run ip dvmrp
uncast-routing)."

			/ Göran Bengtson

---

From: Bill Fenner <[email-masked]>
Date: Tue, 7 Apr 1998 09:19:53 PDT

But Cisco didn't implement DVMRP pruning on LAN interfaces, so if you
want to prune (and I hope you do), you shouldn't peer with DVMRP neighbors
on LAN interfaces.  It's an operational issue, not a technical issue.

Now that DVMRP peering doesn't work on LAN interfaces any more, it's just
another reason not to peer with DVMRP neighbors on LAN interfaces.

  Bill

(This suggestion only applies to Cisco's IOS; more complete DVMRP
implementations like in mrouted or as supplied most other rounter
vendors can peer on LANs all they want.)