CCIE VERIFY RPF FAIL

One of the major issues with Multicast is finding the RPF and making sure that there is no Failure in it, as if we do have a fail we can patch it by adding ip mroute (like a static route but only to pass the RPF, not actually changing the path of the packet). So how we can find such fail we have several tools the first one is to find if we have rp mapping. R6#sh ip pim rp ma PIM Group-to-RP Mappings Group(s) 224.0.0.0/4 RP 150.1.5.5 (?), v2v1 Info source: 150.1.3.3 (?), elected via Auto-RP Uptime: 00:14:48, expires: 00:00:02 R6# we see here in that example that we do have RP Mapping so we defiantly passed the RPF. I have made an RPF fail and we now will try to trace it: R6#sh ip mroute count IP Multicast Statistics 3 routes using 1962 bytes of memory 3 groups, 0.00 average sources per group Forwarding Counts: Pkt Count/Pkts(neg(-) = Drops) per second/Avg Pkt Size/Kilobits per second Other counts: Total/RPF failed/Other drops(OIF-null, rate-limit etc) Group: 227.0.0.1, Source count: 0, Packets forwarded: 0, Packets received: 0 Group: 224.0.1.1, Source count: 0, Packets forwarded: 0, Packets received: 0 Group: 224.0.1.40, Source count: 0, Packets forwarded: 0, Packets received: 0 we see that we are not receiving packets from our mapping agent when we listen on group 224.0.1.40 so some where along the path we have an RPF fail. R6#sh ip mrou 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 Outgoing interface flags: H - Hardware switched, A - Assert winner Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (*, 227.0.0.1), 00:02:19/00:02:47, RP 0.0.0.0, flags: SJCL Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: FastEthernet0/0, Forward/Sparse, 00:02:19/00:02:47 (*, 224.0.1.1), 00:02:19/00:02:53, RP 0.0.0.0, flags: SJCL Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: FastEthernet0/0, Forward/Sparse, 00:02:19/00:02:53 (*, 224.0.1.39), 00:01:12/stopped, RP 0.0.0.0, flags: DP Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Null (150.1.5.5, 224.0.1.39), 00:01:12/00:01:47, flags: PT Incoming interface: FastEthernet0/0, RPF nbr 166.1.12.1 Outgoing interface list: Null (*, 224.0.1.40), 00:02:20/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/Sparse, 00:02:20/00:02:54 R6# we see above that we do get see the RP and we get it from 166.1.12.1 so lets got to R1 (166.1.12.1). R1#sh ip mroute count IP Multicast Statistics 5 routes using 2946 bytes of memory 4 groups, 0.25 average sources per group Forwarding Counts: Pkt Count/Pkts(neg(-) = Drops) per second/Avg Pkt Size/Kilobits per second Other counts: Total/RPF failed/Other drops(OIF-null, rate-limit etc) Group: 227.0.0.1, Source count: 0, Packets forwarded: 0, Packets received: 0 Group: 224.0.1.1, Source count: 0, Packets forwarded: 0, Packets received: 1 RP-tree: Forwarding: 0/0/0/0, Other: 1/0/1 Group: 224.0.1.39, Source count: 1, Packets forwarded: 12, Packets received: 12 Source: 150.1.5.5/32, Forwarding: 12/1/48/0, Other: 12/0/0 Group: 224.0.1.40, Source count: 0, Packets forwarded: 0, Packets received: 0 R1# we see here that we still do not recive any packet on the mapping group. R1#sh ip mrou 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 Outgoing interface flags: H - Hardware switched, A - Assert winner Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (*, 227.0.0.1), 00:01:24/00:02:10, RP 0.0.0.0, flags: SP Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Null (*, 224.0.1.1), 00:01:24/stopped, RP 0.0.0.0, flags: SP Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Null (166.1.12.4, 224.0.1.1), 00:00:20/00:03:09, flags: T Incoming interface: FastEthernet0/0, RPF nbr 0.0.0.0 Outgoing interface list: Serial1/0, Forward/Sparse, 00:00:20/00:03:09 (166.1.12.6, 224.0.1.1), 00:00:20/00:03:09, flags: T Incoming interface: FastEthernet0/0, RPF nbr 0.0.0.0 Outgoing interface list: Serial1/0, Forward/Sparse, 00:00:20/00:03:09 (*, 224.0.1.39), 00:01:26/stopped, RP 0.0.0.0, flags: D Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: FastEthernet0/0, Forward/Sparse, 00:01:26/00:00:00 Serial1/0, Forward/Sparse, 00:01:26/00:00:00 (150.1.5.5, 224.0.1.39), 00:01:26/00:02:56, flags: T Incoming interface: Serial1/0, RPF nbr 166.1.0.5 Outgoing interface list: FastEthernet0/0, Forward/Sparse, 00:01:26/00:00:00 (*, 224.0.1.40), 00:01:27/00:02:04, RP 0.0.0.0, flags: DCL Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: FastEthernet0/0, Forward/Sparse, 00:01:27/00:00:00 Serial1/0, Forward/Sparse, 00:01:27/00:00:00 R1# now lets go again one step forward to R5 to see if R5 is also not receiving packets for group of the mapping agent. R5#sh ip pim rp ma PIM Group-to-RP Mappings This system is an RP (Auto-RP) Group(s) 224.0.0.0/4 RP 150.1.5.5 (?), v2v1 Info source: 150.1.3.3 (?), elected via Auto-RP Uptime: 00:00:45, expires: 00:00:01 R5# and we can see that we do receive the mapping from 150.1.3.3 on R5 so we know that the RPF fail happen on R1 to R3 Now I will tell you that R5 R3 and R1 are connected over FR (Physical Interface only) R5 is the hub and R1 and R3 are the spokes. so first we need to make sure that we enabled R5(config-if)#ip pim nbma-mode that command will make sure that packets received on one VC of the FR can go out that same interface to another VC for Sparse Groups Only here bellow you can see the output of sparse group with the nbma-mode enable you can see it is going out of that same interface but to different IP (VC) (*, 227.0.0.1), 20:05:09/stopped, RP 150.1.5.5, flags: SJCL Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Serial1/0, 166.1.0.3, Forward/Sparse, 00:15:40/00:01:01 Serial1/0, 166.1.0.5, Forward/Sparse, 04:28:41/00:02:42 And on that same router R5 although I have enabled nbma-mode you can see that for dense mode group it is acting different. (*, 224.0.1.40), 17:24:56/stopped, RP 0.0.0.0, flags: DCL Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Loopback0, Forward/Sparse, 17:24:56/00:00:00 Serial1/0, Forward/Sparse, 17:24:56/00:00:00 So now that we see that we traced where the RPF is we need to solve it, on R1 R1#sh ip route 150.1.3.3 Routing entry for 150.1.3.3/32 Known via "ospf 1", distance 110, metric 65, type intra area Redistributing via eigrp 1 Advertised by eigrp 1 metric 1536 1 255 1 1500 Last update from 166.1.0.3 on Serial1/0, 00:17:50 ago Routing Descriptor Blocks: * 166.1.0.3, from 150.1.3.3, 00:17:50 ago, via Serial1/0 Route metric is 65, traffic share count is 1 R1#sh ip route 166.1.0.3 Routing entry for 166.1.0.0/24 Known via "connected", distance 0, metric 0 (connected, via interface) Redistributing via eigrp 1 Advertised by eigrp 1 Routing Descriptor Blocks: * directly connected, via Serial1/0 Route metric is 0, traffic share count is 1 we know that 224.0.1.40 is Dense mode group and it cannot pass the RPF due to that as it will not be able to go out the same interface it came in. so what we can do is create a tunnel interface between R1 to R3. And set the RPF to check the path trough that tunnel. interface Tunnel0 ip unnumbered Loopback0 ip pim sparse-mode tunnel source Loopback0 tunnel destination 150.1.3.3 ! R1#sh run inc ip mrou ip mroute 150.1.3.3 255.255.255.255 Tunnel0 R1# ! interface Tunnel0 ip unnumbered Loopback0 ip pim sparse-mode tunnel source Loopback0 tunnel destination 150.1.1.1 end R3# we must make sure that the source and the destination match exactly on both side like showed here and both on the interface that we are sourcing and destination and the tunnel we enabling PIM. R1#sh ip pim neighbor PIM Neighbor Table Mode: B - Bidir Capable, DR - Designated Router, N - Default DR Priority, S - State Refresh Capable Neighbor Interface Uptime/Expires Ver DR Address Prio/Mode 166.1.0.5 Serial1/0 20:52:24/00:01:20 v2 1 / DR S 166.1.12.4 FastEthernet0/0 17:20:06/00:01:24 v2 1 / S 166.1.12.6 FastEthernet0/0 20:51:54/00:01:21 v2 1 / DR S 150.1.3.3 Tunnel0 00:02:12/00:01:30 v2 1 / S R1# R1#sh ip pim rp ma PIM Group-to-RP Mappings Group(s) 224.0.0.0/4 RP 150.1.5.5 (?), v2v1 Info source: 150.1.3.3 (?), elected via Auto-RP Uptime: 00:00:10, expires: 00:00:02 R1# And now we can go back to R6 and see that we have also mapping on R6 so we solved RPF fail. R6#sh ip pim rp ma PIM Group-to-RP Mappings Group(s) 224.0.0.0/4 RP 150.1.5.5 (?), v2v1 Info source: 150.1.3.3 (?), elected via Auto-RP Uptime: 00:00:33, expires: 00:00:03 R6#