Subject: Re: Missing Mbone routes, sources, ...

From: [email-masked]
Date: Fri, 20 Feb 1998 11:34:06 -0800 (PST)

> maew-mbone's problem is that mbone.idt.net is a cisco, and maew-mbone's
> tunnel is configured in DVMRP mode.  Cisco says that DVMRP tunnels
> between two ciscos don't work.  Interestingly enough, the route
> exchange works, since maew-mbone is pointing 5042 routes towards
> mbone.idt.net ("show ip dvmrp route tunnel14").  However, multicast
> forwarding fails to work and so apparently any route going over this
> tunnel will simply blackhole.
> 
> (Interestingly enough, "mrinfo" on both ends of the tunnel show it
> to be down.  I can't imagine why a router might accept routes pointing
> to a down tunnel.)
> 
> Configuring PIM over a GRE tunnel is the accepted way to tunnel two
> Ciscos together.

Just thought I would follow up on this, since it can cause a 
serious problem.  If anyone happens to be doing a DVMRP tunnel
between a Cisco and an mrouted box, and, there are quite a few
of these out there obviously, please don't change the mrouted box
to a Cisco without notifying the other end.  On the Cisco, you
need to remove the command "tunnel mode dvmrp" from your tunnel
configuration (on both ends).  Failure to do so may result under 
some conditions in a blackhole in which routes are exchanged 
between the Ciscos but traffic isn't...

On another note: there may be some misconfigured route hogs out there,
but, it appears that the number of legitimate routes is increasing
lately and may have exceeded the 7000 threshold.  In any case, there 
is a lot of route flapping going on.  I suggest that people running
Ciscos with DVMRP routing increase the route limit: e.g. instead of 
the default limit of 7000, try:

  ip dvmrp route-limit 8000

Also, it would be nice if sites with Ciscos and campus-wide multicast
would take advantage of the IOS 11.2 DVMRP route summarization feature.
This is the "ip dvmrp summary-address".  Apparently auto-summarization
doesn't always take place.  

I see a number of networks with 100-200 subnets with individual routes; 
this is one reason the DVMRP routing table is so large.  I would guess 
that most of these could be collapsed into one route or only a few routes.  
Please apply with caution, however.  

Here is the complete 11.2 command:

[no] ip dvmrp summary-address <address> <mask> metric <value>
        Configures a summary address to be advertised out the interface. If 
        there is at least one more specific route in the unicast routing table
        that matches the <address>/<mask>, the summary will be advertised. 
        Routes in the DVMRP routing table are not candidates for summarization.
        When the metric keyword is supplied, the summary will be advertised 
        with metric <value>. The default metric <value> is 1. Multiple summary
        addresses can be configured on an interface. When multiple overlapping
        summary addresses are configured on an interface, the one with the 
        longest mask takes preference. [11.2]

Additions/corrections/deletions/warnings/contradictions welcome.

-Hugh LaMaster

  Hugh LaMaster, M/S 258-5,     ASCII Email:  [email-masked]
  NASA Ames Research Center     Or:           [email-masked]
  Moffett Field, CA 94035-1000  No Junkmail:  USC 18 section 2701
  Phone:  415/604-1056          Disclaimer:   Unofficial, personal *opinion*.

---

From: Bill Fenner <[email-masked]>
Date: Fri, 20 Feb 1998 13:29:12 PST

>On another note: there may be some misconfigured route hogs out there,

Looks like some frontiernet router (209.130.128.73) is advertising
around 2k routes (maybe more).

  Bill

---

From: Domain Registration Account <[email-masked]>
Date: Sun, 22 Feb 1998 12:33:18 -0500 (EST)

Router was restored with an invalid configuration, it should be repaired 
  now.

  -pee