DVMRP Conditional Flooding -------------------------- In previous releases, a cisco router would always forward multicast packets to a DVMRP neighbor until a prune was received. In redundant DVMRP topologies, a mrouted implementation may not send a prune if the forwarding router wasn't the upstream router (RPF neighbor). This results in continued forwarding of data that gets dropped by the mrouted implementation due to RPF failures and therefore wasting bandwidth. This issue doesn't occur between ciscos because they use the PIM-DM algorithm for pruning redundant paths. This issue is only relevant when a cisco router is an upstream neighbor and there are one or more downstream neigbhors running mrouted. The feature works like this: a cisco router will only put a tunnel in it's outgoing interface list for any (S,G) entry if and only if the downstream neighbor has sent a DVMRP Report for S or an aggregate route for S with a metric greater than infinity (therefore poison-reversing the route). An interface will always remain in the outgoing interface list of the (*,G) entry so you can tell that a DVMRP neighbor has been discovered on that interface. An interface in the outgoing interface list of a (S,G) entry that is in Prune state means the route has been poison-reversed and there are no downstream members for the group on the source-tree for S. If an interface in the outgoing interface list of a (S,G) entry is in Forward state, it means the route has been poison-reversed and the downstream router wants traffic for the group on the source-tree for S. There are no configuration commands to turn on this feature. It is enabled by default. This feature is in the latest 11.2F release. DVMRP conditional flooding will occur on all point-to-point links including ATM PVCs. A route that has been poison-reversed will appear as follows in the DVMRP routing table. The "poison" field indicates the interface on which a poison reverse has been received from the neighbor. 171.69.214.152/29 [0/2] uptime 19:23:49, expires 00:02:36, poison 0x20000 via 171.69.214.153, Tunnel1 171.69.215.64/29 [0/2] uptime 19:23:49, expires 00:02:36, poison 0x20000 via 171.69.214.153, Tunnel1 The interfaces are in "write term" order. 0x20000 should actually read 0x020000 (there is a DDTS to fix this). This number is a bit representation of the interfaces on the router. Bit 0 is never used. The bit-ordering is a bit confusing because it is a hexidecimal number: 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 23 22 21 20 19 18 17 16 ... So 0x020000 has bit 1 set, which means the first interface in the router that is listed when you do a "write term". 0x0222 means interface number 1, interface number 9, and interface number 13 are interfaces which have received a poisoned-reverse advertisement "debug ip dvmrp detail" will include the following messages for poison-reversed routes. "poison clear 9" means the router has received a DVMRP report from its neighbor advertising a route to a source network and that the neighbor does _not_ want to be a child for that route. In the second line, the neigbor router is setting up a child relationship for that route. The number "9" represents the ninth interface on the router. DVMRP: Received Report on Tunnel0 from 172.21.32.98 DVMRP: Origin 130.1.0.0/16, metric 2, metric-offset 1, poison clear 9, distance 0 DVMRP: Origin 171.69.215.64/29, metric 35, metric-offset 1, > infinity, poison set 9 .