Troubleshooting multicast – RPF failure

In unicast routing we are interested in how to forward packets to their destination. In multicast routing we are interested where the source came from, multicast packets need to pass a RPF (Reverse Path Forwarding) check. Packets that are received on an interface are checked that the route back to the source is through the same interface, otherwise the RPF check will fail. RPF check failing is one of the most common errors in multicast networks. Lets look at the topology.

The goal of the scenario is that R6 should be able to ping SW4 which has joined multicast group 224.10.10.10. PIM dense mode has been enabled on R6 -> R4, between R4 and R5 PIM is only enabled on the frame-relay connection. PIM is enabled between R5 -> SW2 and SW2 -> SW4. Dense mode is being used. This is configuration from SW4.

Rack11SW4#sh run int vlan 10
Building configuration…
Current configuration : 96 bytes
!
interface Vlan10
 ip address 155.11.10.10 255.255.255.0
 ip igmp join-group 224.10.10.10
end

Ping from R6 to SW4.

Rack11R6#ping 224.10.10.10 re 3
Type escape sequence to abort.
Sending 3, 100-byte ICMP Echos to 224.10.10.10, timeout is 2 seconds:
…

Not successful, lets look at what multicast packets are being sent. We need to disable fast switching on the interface to see any packets.

Rack11R5(config)#int s0/0/0
Rack11R5(config-if)#no ip mroute-cache
Rack11R5(config-if)#^Z
Rack11R5#debug ip mpacket
IP multicast packets debugging is on
Rack11R5#
Feb 15 10:30:53.727: IP(0): s=155.11.146.6 (Serial0/0/0) d=224.10.10.10 id=93, ttl=253, prot=1, len=104
(100), RPF lookup failed for source
Feb 15 10:30:53.727: IP(0): s=155.11.146.6 (Serial0/0/0) d=224.10.10.10 id=93, ttl=253, prot=1, len=104
(100), not RPF interface
Rack11R5#
Feb 15 10:30:55.723: IP(0): s=155.11.146.6 (Serial0/0/0) d=224.10.10.10 id=94, ttl=253, prot=1, len=104
(100), not RPF interface
Rack11R5#
Feb 15 10:30:57.723: IP(0): s=155.11.146.6 (Serial0/0/0) d=224.10.10.10 id=95, ttl=253, prot=1, len=104
(100), not RPF interface

Packets are not coming in on the RPF interface. Lets look at the multicast routing table.

Rack11R5#sh ip mroute
IP Multicast Routing Table
Flags: D – Dense, S – Sparse, B – Bidir Group, s – SSM Group, C – Connected,
       L – Local, P – Pruned, R – RP-bit set, F – Register flag,
       T – SPT-bit set, J – Join SPT, M – MSDP created entry,
       X – Proxy Join Timer Running, A – Candidate for MSDP Advertisement,
       U – URD, I – Received Source Specific Host Report,
       Z – Multicast Tunnel, z – MDT-data group sender,
       Y – Joined MDT-data group, y – Sending to MDT-data group,
       V – RD & Vector, v – Vector
Outgoing interface flags: H – Hardware switched, A – Assert winner
 Timers: Uptime/Expires
 Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 224.10.10.10), 00:03:41/stopped, RP 0.0.0.0, flags: D
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    FastEthernet0/0, Forward/Dense, 00:03:41/00:00:00
    Serial0/0/0, Forward/Dense, 00:03:41/00:00:00
(155.11.146.6, 224.10.10.10), 00:00:02/00:02:57, flags:
  Incoming interface: Null, RPF nbr 155.11.45.4
  Outgoing interface list:
    FastEthernet0/0, Forward/Dense, 00:00:02/00:00:00
    Serial0/0/0, Forward/Dense, 00:00:02/00:00:00
(*, 224.0.1.40), 00:39:35/00:02:54, RP 0.0.0.0, flags: DCL
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    FastEthernet0/0, Forward/Dense, 00:38:30/00:00:00
    Serial0/0/0, Forward/Dense, 00:14:20/00:00:00 

We are interested in the (155.11.146.6, 224.10.10.10) which is a dense mode group. Our RPF neighbor is 155.11.45.4 which is the address of R4 on the S0/1/0 interface which is not enabled for PIM. How do we reach 155.11.146.6?

Rack11R5#sh ip mroute
IP Multicast Routing Table
Flags: D – Dense, S – Sparse, B – Bidir Group, s – SSM Group, C – Connected,
       L – Local, P – Pruned, R – RP-bit set, F – Register flag,
       T – SPT-bit set, J – Join SPT, M – MSDP created entry,
       X – Proxy Join Timer Running, A – Candidate for MSDP Advertisement,
       U – URD, I – Received Source Specific Host Report,
       Z – Multicast Tunnel, z – MDT-data group sender,
       Y – Joined MDT-data group, y – Sending to MDT-data group,
       V – RD & Vector, v – Vector
Outgoing interface flags: H – Hardware switched, A – Assert winner
 Timers: Uptime/Expires
 Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 224.10.10.10), 00:03:41/stopped, RP 0.0.0.0, flags: D
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    FastEthernet0/0, Forward/Dense, 00:03:41/00:00:00
    Serial0/0/0, Forward/Dense, 00:03:41/00:00:00
(155.11.146.6, 224.10.10.10), 00:00:02/00:02:57, flags:
  Incoming interface: Null, RPF nbr 155.11.45.4
  Outgoing interface list:
    FastEthernet0/0, Forward/Dense, 00:00:02/00:00:00
    Serial0/0/0, Forward/Dense, 00:00:02/00:00:00
(*, 224.0.1.40), 00:39:35/00:02:54, RP 0.0.0.0, flags: DCL
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    FastEthernet0/0, Forward/Dense, 00:38:30/00:00:00
    Serial0/0/0, Forward/Dense, 00:14:20/00:00:00
Rack11R5#sh ip route 155.11.146.6
Routing entry for 155.11.146.0/24
  Known via “eigrp 100”, distance 90, metric 2172416, type internal
  Redistributing via eigrp 100, ospf 1
  Advertised by ospf 1 subnets
  Last update from 155.11.45.4 on Serial0/1/0, 00:55:04 ago
  Routing Descriptor Blocks:
  * 155.11.45.4, from 155.11.45.4, 00:55:04 ago, via Serial0/1/0
      Route metric is 2172416, traffic share count is 1
      Total delay is 20100 microseconds, minimum bandwidth is 1544 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 1/255, Hops 1

Traffic to R6 is sent over the S0/1/0 interface which is not enabled for PIM, this is a problem…How can we pass the RPF check? By adding a static mroute we can enable the frame-relay interface to be a valid RPF interface.

Rack11R5(config)#ip mroute 155.11.146.6 255.255.255.255 155.11.0.4

The ping should now be successful.

Rack11R6#ping 224.10.10.10 re 3
Type escape sequence to abort.
Sending 3, 100-byte ICMP Echos to 224.10.10.10, timeout is 2 seconds:
Reply to request 0 from 155.11.108.10, 52 ms
Reply to request 1 from 155.11.108.10, 44 ms
Reply to request 2 from 155.11.108.10, 44 ms

Traffic is flowing, one final look at the mroute table.

Rack11R5#sh ip mroute
IP Multicast Routing Table
Flags: D – Dense, S – Sparse, B – Bidir Group, s – SSM Group, C – Connected,
       L – Local, P – Pruned, R – RP-bit set, F – Register flag,
       T – SPT-bit set, J – Join SPT, M – MSDP created entry,
       X – Proxy Join Timer Running, A – Candidate for MSDP Advertisement,
       U – URD, I – Received Source Specific Host Report,
       Z – Multicast Tunnel, z – MDT-data group sender,
       Y – Joined MDT-data group, y – Sending to MDT-data group,
       V – RD & Vector, v – Vector
Outgoing interface flags: H – Hardware switched, A – Assert winner
 Timers: Uptime/Expires
 Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 224.10.10.10), 00:06:53/stopped, RP 0.0.0.0, flags: D
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    FastEthernet0/0, Forward/Dense, 00:06:53/00:00:00
    Serial0/0/0, Forward/Dense, 00:06:53/00:00:00
(155.11.146.6, 224.10.10.10), 00:03:14/00:02:35, flags: T
  Incoming interface: Serial0/0/0, RPF nbr 155.11.0.4, Mroute
  Outgoing interface list:
    FastEthernet0/0, Forward/Dense, 00:03:14/00:00:00
(*, 224.0.1.40), 00:42:47/00:02:47, RP 0.0.0.0, flags: DCL
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    FastEthernet0/0, Forward/Dense, 00:41:42/00:00:00
    Serial0/0/0, Forward/Dense, 00:17:32/00:00:00

The RPF neighbor is now 155.11.0.4 which is the next-hop over frame-relay. When doing multicast we need to think more about traffic patterns and ensuring that interfaces that are in the multicast transit path should be PIM enabled or not be used for multicast traffic.