Subject: Re: Top 50 unstable DVMRP routes

From: Bill Fenner <[email-masked]>
Date: Mon, 1 Dec 1997 14:23:55 PST

>    o The second paragraph about requiring "ip dvmrp metric" on each interface
>      to avoid feedback routing loops is incorrect. You need to have the 
>      unicast route that your injecting into DVMRP have a better distance so 
>      when the DVMRP route that comes back to the cisco, won't be used or 
>      readvertised.

It doesn't say it's required, it just says that it's easier for the problem
to occur.

>    o On the Solution section describing distance C, the cisco won't advertise
>      unicast routes where the next-hop interface or next-hop neighbor is
>      not multicast capable (not PIM-enabled or the neighbor isn't a PIM
>      router).

This must be new.  When was this introduced?

>    o The last paragraph indicates that if you have many unicast routing
>      protocols in which you are injecting routes from, you have to deal with
>      distances for each one. There is another approach which is simpler where
>      you just have to make the DVMRP distance worse (higher value) than any
>      unicast route.

This depends on the new behavior described above, which did not exist
in the routers that I was testing on.  It's sure nice to be able to say
"This is not a problem if you're running current code", but as we all know
very few people actually run current code.

  Bill

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 1 Dec 1997 19:32:30 -0800 (PST)

>> It doesn't say it's required, it just says that it's easier for the problem

    But you made it sound too strong.

>> This must be new.  When was this introduced?

    Been there for a long time.

Dino

---

From: Bill Fenner <[email-masked]>
Date: Tue, 2 Dec 1997 10:39:44 PST

Dino Farinacci <[email-masked]> wrote:
>>> [not advertising or using unicast routes that don't point to
>>>  PIM neighbors] must be new.  When was this introduced?
>

Well, it appears to at least be in 11.2 from August.  You still have to
do A<B<C if you want to prefer a DVMRP route over a PIM-unicast route
for some reason, but I think that only affects route preference and not
route stability.  It's too bad you and I didn't think about this during
that 3-hour phone call when we were first trying to figure out what to
do about this problem.

So, the solution to this problem appears to be to make the default
DVMRP distance higher than any other routes.  Remind me again why
cisco's default DVMRP distance is lower than any other routes?

Thanks,
  Bill

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 2 Dec 1997 11:28:34 -0800 (PST)

>> do A<B<C if you want to prefer a DVMRP route over a PIM-unicast route

    I did more research on this while looking at a customer problem. It
    turns out that the interface (only) must be multicast capable. Yes, this
    was put in in August.

>> for some reason, but I think that only affects route preference and not

    But only in the case where you are getting the routes from both directions.

>> It's too bad you and I didn't think about this during

    There were many things we talked about. The bugfix was unrelated to the
    discussion but helps some of the issues.

>> cisco's default DVMRP distance is lower than any other routes?

    Because a router that runs BGP and DVMRP would prefer BGP routes over
    DVMRP routes and would RPF fail for MBONE sources.

Dino

---

From: Bill Fenner <[email-masked]>
Date: Tue, 2 Dec 1997 11:58:23 PST

Dino,

  Configuring the DVMRP distance high is sufficient to prevent the
route instability problem, you're right.  However, if you don't use the
A<B<C solution as described on the web page, you will create black
holes.  I don't want to trade one problem for another, which is why the
web page suggests the A<B<C configuration which solves both.  The set
of routes requiring the C distance could be empty, of course, and in
that case it reduces to the solution you were suggesting.

  I revised the web page to try to be more clear about the exact
requirements for distances and when it's possible to eliminate the
requirement for using distance C.

  Bill

---

From: [email-masked] (Jeremy Hall)
Date: Tue, 2 Dec 1997 15:25:22 -0500 (EST)

because if your unicast and multicast topologies are NOT congruent, you
need multicast to win by default.  It really does make sense, since
multicast isn't stable enough to run in a production environment with
unicast.  In a native world, you wouldn't use dvmrp anyway, so it is a
non-issue.

_J

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 2 Dec 1997 12:37:39 -0800 (PST)

>> that case it reduces to the solution you were suggesting.

    The distance C introduces a problem. What if there is a DVMRP route that
    covers one of the unicast routes your not advertising into DVMRP. Then
    a multicast packet from a local source will RPF to the DVMRP route and
    not get forwarded to local members.

    You should only use 2 distances in my opinion.

Dino

---

From: Bill Fenner <[email-masked]>
Date: Tue, 2 Dec 1997 13:02:02 PST

What if there is a DVMRP route that is exactly the same as one of the
unicast routes you're not advertising into DVMRP (and not using for
multicast)?  The unicast route will be preferred, since it has a better
metric, and you will have a black hole for this external traffic.

You should carefully configure three distances, in my opinion.

  Bill

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 2 Dec 1997 13:15:58 -0800 (PST)

>> metric, and you will have a black hole for this external traffic.

    Yes, I know. That was the motivation for you do describe 3 distances. But
    let's face it, most people are aggregating their PIM routes when sent into
    DVMRP so most sources are being advertised (with few routes).

    I just want to make sure we document the normal case and not emphasize
    a corner case.

Dino

---

From: Bill Fenner <[email-masked]>
Date: Tue, 2 Dec 1997 13:35:47 PST

[email-masked] (Jeremy Hall) wrote:
>need multicast to win by default.

Except when you don't.  It really depends heavily on the topology.

  Bill