McDewey

Unicast routes 4. If multiple entries for a route occur within the same route table, the longest match route is used. • The show ip mroute 224.1.1.1 command output shows the RPF interface is E2/0, but the incoming interface must be E3/1. Enter the show ip mroute 224.1.1.1 command in order to see why the RPF interface is different from what was expected.

<#root> ip22-72a# show ip route 10.1.1.1 Routing entry for 10.1.1.1/32 Known via "static", distance 1, metric 0 (connected) Routing Descriptor Blocks:

• directly connected, via Ethernet2/0 Route metric is 0, traffic share count is 1

You can see from this show ip route 10.1.1.1 command output that there is a static /32 route, which makes the wrong interface to be chosen as RPF interface. Enter some further debug commands:

<#root> ip22-72a# debug ip mpacket 224.1.1.1

*Jan 14 09:45:32.972: IP: s=10.1.1.1 (Ethernet3/1) d=224.1.1.1 len 60, not RPF interface *Jan 14 09:45:33.020: IP: s=10.1.1.1 (Ethernet3/1) d=224.1.1.1 len 60, not RPF interface *Jan 14 09:45:33.072: IP: s=10.1.1.1 (Ethernet3/1) d=224.1.1.1 len 60, not RPF interface *Jan 14 09:45:33.120: IP: s=10.1.1.1 (Ethernet3/1) d=224.1.1.1 len 60, not RPF interface

The packets come in on E3/1, which is correct. However, they are dropped because that is not the interface the unicast routing table uses for the RPF check. Note: Debugging packets is dangerous. Packet debugging triggers process switching of the multicast packets, which is CPU intensive. Also, packet debugging can produce huge output which can hang the router completely due to slow output to the console port. Before you debug packets, special care must be taken in order to disable logging output to the console, and enable logging to the memory buffer. In order to achieve this, configure no logging console and logging buffered debugging. The results of the debug can be seen with the show logging command.