Subject: Pruning problem

From: Jeremy George <[email-masked]>
Date: Mon, 25 Aug 1997 14:03:07 -0400

I'm getting 1 to 1.5Mbps across our DVMRP link to MCI.  Everything
else prunes appropriately.  I've checked with debug.  I've cut off most
of campus.  Noone has joined this group ( trace just below ) but it
won't stop.  TTL and destination don't seem run-of-the-mill.  Am I the
only one having a problem here?

  I'm running current Cisco EFT software on the tunnel end at Yale.
Relevant portions of the configuration follow.

- Jeremy

maze#debug ip mpacket detail
IP multicast packets debugging is on (detailed)
maze#
IP: MAC sa=*Tunnel* (Tunnel0)
IP: IP tos=0x0, len=1488, id=0x9F29, ttl=248, prot=17
IP: s=152.2.21.6 (Tunnel0) d=238.221.204.1 (Ethernet0) len 1488, mforward
IP: MAC sa=*Tunnel* (Tunnel0)
IP: IP tos=0x0, len=1488, id=0x9F3B, ttl=248, prot=17
IP: s=152.2.21.6 (Tunnel0) d=238.221.204.1 (Ethernet0) len 1488, mforward
IP: MAC sa=*Tunnel* (Tunnel0)
IP: IP tos=0x0, len=1488, id=0x9F53, ttl=248, prot=17
IP: s=152.2.21.6 (Tunnel0) d=238.221.204.1 (Ethernet0) len 1488, mforward
IP: MAC sa=*Tunnel* (Tunnel0)
IP: IP tos=0x0, len=1488, id=0x9F54, ttl=248, prot=17
IP: s=152.2.21.6 (Tunnel0) d=238.221.204.1 (Ethernet0) len 1488, mforward
IP: MAC sa=*Tunnel* (Tunnel0)
IP: IP tos=0x0, len=1488, id=0x9F55, ttl=248, prot=17
IP: s=152.2.21.6 (Tunnel0) d=238.221.204.1 (Ethernet0) len 1488, mforward
IP: MAC sa=*Tunnel* (Tunnel0)
IP: IP tos=0x0, len=1488, id=0x9F56, ttl=248, prot=17
IP: s=152.2.21.6 (Tunnel0) d=238.221.204.1 (Ethernet0) len 1488, mforward
IP: MAC sa=*Tunnel* (Tunnel0)

ip multicast-routing
ip dvmrp route-limit 7000
!
interface Loopback0
 description # LBack Loopback #
 ip address 10.0.0.1 255.0.0.0
!
interface Tunnel0
 description # Mbone #
 ip unnumbered Loopback0
 ip pim dense-mode
 ip multicast ttl-threshold 32
 ip multicast boundary 3
 ip dvmrp metric 0 list 2
 ip dvmrp metric 1 list 1
 ip dvmrp unicast-routing
 shutdown
 random-detect 10
 tunnel source Ethernet0
 tunnel destination 204.70.64.61
 tunnel mode dvmrp
!
interface Ethernet0
 description # Spine #
 ip address 130.132.1.29 255.255.255.0
 ip broadcast-address 130.132.1.255
 ip pim dense-mode
 ip dvmrp default-information only
 ip dvmrp unicast-routing
 ip ospf authentication-key 7 141917190A0C382F36
 random-detect 10
!
access-list 1 permit 130.132.0.0 0.0.255.255
access-list 1 permit 128.36.0.0 0.0.255.255
access-list 1 deny   any
access-list 2 permit any
access-list 3 deny   239.0.0.0 0.255.255.255
access-list 3 permit 224.0.0.0 15.255.255.255

---

From: Bill Fenner <[email-masked]>
Date: Mon, 25 Aug 1997 13:26:07 PDT

Jeremy George <[email-masked]> wrote:
>else prunes appropriately.  I've checked with debug.

Try "debug ip dvmrp detail prune", and make sure you are sending prunes
to MCI.  Also use "show ip mr <group> <source>", to make sure that
you're not forwarding it anywhere.  And "show ip dvmrp route <source>"
to make sure you have a DVMRP route for the source.

I've also heard people say that you can run into trouble with
"ip dvmrp unicast-routing" on a dvmrp-mode tunnel, but don't have
any direct experience with that.

  Bill

---

From: Bill Fenner <[email-masked]>
Date: Mon, 25 Aug 1997 13:35:38 PDT

I forgot the most important command, "show ip rpf <source>" to make
sure you know the RPF neighbor (which is where a prune should be sent).
According to an mtrace I just did, maze.net.yale.edu is using a default
route pointing to bifrost.net.yale.edu for traffic from this source,
which is presumably wrong.  So check your DVMRP routing table and figure
out why you're preferring your unicast default over the DVMRP route
that you should have for the source.

  Bill

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 25 Aug 1997 15:00:11 -0700

>> any direct experience with that.

    What happens is that we do split horizon only (and not poison-reverse).
    No need to configure "ip dvmrp unicast-routing" on a DVMRP tunnel.

Dino