Subject: Ok, what are we doing wrong?

From: Bill Blue <[email-masked]>
Date: Thu, 20 Mar 1997 18:31:05 -0800

Hi -

We recently set up a tunnel between mbone.idt.net and ctshub.cts.com, which
doesn't appear to be handling traffic correctly.  mbone.idt.net is running
mrouted on a Sun configured thusly:

tunnel  169.132.44.9    205.163.23.250  metric 2        threshold 32

On our end is a Cisco 7507.  It is dual-homed DS3 connections, and we're
using the ethernet0/0 address as the tunnel endpoint.  Here are relevant
parts of the config file:

ip multicast-routing
ip dvmrp routehog-notification 5000
ip dvmrp route-limit 7000

interface Tunnel1
 description DVMRP tunnel to mbone.idt.net (169.132.44.9)
 ip unnumbered Ethernet0/0
 ip pim dense-mode
 ip multicast ttl-threshold 127
 ip dvmrp accept-filter 15
 no ip mroute-cache
 ip sdr listen
 tunnel source 205.163.23.250
 tunnel destination 169.132.44.9
 tunnel mode dvmrp

interface Ethernet0/0
 ip address 205.163.23.250 255.255.255.0
 ip access-group 130 in
 ip pim dense-mode
 ip dvmrp default-information only
 ip dvmrp unicast-routing
 no ip mroute-cache

ip mroute 0.0.0.0 0.0.0.0 Tunnel1

access-list 15 deny   any

access-list 130 permit ip 205.163.23.0 0.0.0.255 any
access-list 130 deny   ip any any log

The symptoms are that we don't seem to be seeing the majority of mbone
traffic, though there is some.  sdr programs on the local net show
occasional entries, but most of the time are blank.  Only occasionally is
there any traffic that we can actually receive.

show ip mroute summ on the router shows anything from no traffic (just
local interfaces) to 2-3 screen pages of listings, but at that time there
may or may not be any indications on sdr.  Traffic that we feed downstream
to another mrouted and on our local ethernet seems to be consistent with
what we see on the router, and idt.net seems to have no problem feeding
other mrouted tunnels.

Does anyone who has experience with this see a potential problem with the
way we are configured?  I'm suspicious that it is some sort of a basic
communications problem between the mrouted and the Cisco, which is running
IOS 11.2.

There are about 7 ip hops between us.

Any assistance would be greatly appreciated.

--Bill Blue, CTSNET

---

From: "John M. Zwiebel" <[email-masked]>
Date: Thu, 20 Mar 1997 19:04:55 -0800

Its not that the cisco and mrouted don't talk to each other, its that you've
used a static mroute to tell the router to RPF only to the tunnel.

Try "sh ip pim RPF".

Of course, it isn't just that simple.  It also depends on where your tunnel
end-point is in relation to your unicast routing table and all the hosts
you have in your network.

So, look in ftp://ftp-eng.cisco.com/ipmulticast

or at:
	ftp://ftp-eng.cisco.com/ipmulticast.html 

For DVMRP.metric.cmd and ISP.DVMRP.trans and Multicast-route-preference
for a discussion of how the cisco does RPF and some examples of 
configurations.

z

I think I heard you say....

    Hi -

    
    
    ip multicast-routing
    
    interface Tunnel1
    
    interface Ethernet0/0

    access-list 15 deny   any

    

    
    
    --Bill Blue, CTSNET

------------------------------------------------------------------------------
	John Zwiebel                       Phone: 408-526-5303
	Cisco Systems Inc.                 Fax:   
	Multimedia Group                   Email: [email-masked]

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 20 Mar 1997 19:51:48 -0800

>> Try "sh ip pim RPF".

    How about "show ip rpf <source>".

Dino

---

From: "Mark T. Ganzer" <[email-masked]>
Date: Thu, 20 Mar 1997 21:07:34 -0800 ()

Your config looks a lot like Arlie Davis's "Minimal DVMRP Routing
Table Using Cisco IOS" configuration. There is a note on Arlie's web
site:
---------------------------------------------------------------------
Note (2/26/1997)

It has come to my attention that there is a problem with using this
technique. Apparently, mrouted monitors peers to see if they attempt to
re-announce with a (poisoned metric) a route that mrouted originated. If
the peer does, then mrouted assumes that the peer is interested in traffic
from those sources. The effect of this is that mrouted will not propagate
traffic to the downstream peer if the peer rejects the DVMRP route. I'm
working on an effective solution to this problem. -- Arlie
-----------------------------------------------------------------------

I could not get Arlie's configuration to work either - instead I had to
add a "access-list 15 permit 0.0.0.0" to make this work (I'm certain that
John or Dino will jump in if I am taking the wrong approach here).
Unfortunately you lose the DVMRP "routing table explosion" protect that
Arlie's config was supposed to supply (I've seen a bunch of route-hog
warnings of over 5000 routes over the last few days...).

Mark Ganzer          Naval Command, Control & Ocean Surveillance Center,
[email-masked]      RDT&E Div (NRaD), Code 4123,  San Diego, CA
Ph: (619) 553-1186   FAX: (619) 553-4808

---

From: Christian DONOT <[email-masked]>
Date: Fri, 21 Mar 1997 09:42:00 +0100 (MET)

Quoting > Bill Blue wrote,
>  ip multicast ttl-threshold 127

			      ^^^
			      Your threshold is uppest. You have to put
			      32 like your end tunnel. Otherwise, all
			      datagram equal or inferior at 127 will'nt
			      forward on your interfaces.

			      Regards.

			      Christian

-- 
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=
			  Christian Donot
			  =+=+=+=+=+=+=+=
* INRIA's Activities Demonstrations 
* French Multicast Bone Co-ordinator ([email-masked]) (ARISTOTE)
  To get "mbone-fr" map & multicast packages:
	    http://electre.inria.fr/
* To get "ivs"  : (INRIA) 
	    ftp anonymous from zenon.inria.fr:rodeo/ivs/last_version
	    http://www.inria.fr/rodeo/ivs.html
* To get "telesia"  : (Aristote) 
	    ftp://electre.inria.fr/pub/videoconf/last_version
			  =+=+=+=+=+=+=+=
Tel	: +33 01 39 63 57 75		| INRIA/DPRT/ARISTOTE
Fax	: +33 01 39 63 55 34/53 30	| BP 105
Email	: [email-masked]	| 78153 LE CHESNAY CEDEX
	: [email-masked]			| FRANCE
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=

---

From: Bill Fenner <[email-masked]>
Date: Fri, 21 Mar 1997 10:11:11 PST

> ip dvmrp accept-filter 15

As far as I can tell, this means "Don't accept any DVMRP routes on
tunnel1".  If you're not accepting routes, then you're obviously not
poison-reversing them, so you're giving your neighbor the impression
that you have a better path elsewhere for the traffic.

The reason that you get any traffic at all is that mrouted implements
the algorithm described in footnote 3 on page 87 of Deering's thesis;
basically it floods (instead of multicasts) packets until it determines
who wants them via poison-reverse.  So you get traffic during the
flooding interval but since you're not telling mrouted that you want
the traffic it stops sending it.

One of the random ideas that floats around in the back of my head is a
"poor-man's default"; when you get a route report from a neighbor, you
just send it back with all non-infinite and non-poisoned routes
poisoned, and point a static default at the tunnel.  This ONLY works if
you are a singly-connected leaf connected via a tunnel; otherwise you
can end up with duplicate packets and no way to choose which incoming
interface to accept them from (that's what routing's for, after all).

  Bill