Multicast Troubleshooting relating to RP

We will be using the same topology and config as the previous lab.
But in this lab I will raise the R3 candidate-rp priority value to 1 to make sure R4 is the RP used by all the routers.

R3 Config
ip pim rp-candidate Loopback0 priority 1

R1#show ip pim rp mapping
PIM Group-to-RP Mappings

Group(s) 224.0.0.0/4
  RP 4.4.4.4 (?), v2
    Info source: 2.2.2.2 (?), via bootstrap, priority 0, holdtime 150
         Uptime: 00:32:13, expires: 00:01:53
  RP 3.3.3.3 (?), v2
    Info source: 2.2.2.2 (?), via bootstrap, priority 1, holdtime 150
         Uptime: 03:03:06, expires: 00:01:54

R4#show ip mroute

(*, 235.0.0.1), 00:01:33/00:02:23, RP 4.4.4.4, flags: SJC
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    FastEthernet2/1, Forward/Sparse, 00:01:33/00:02:23

(*, 235.0.0.2), 00:00:06/00:02:53, RP 4.4.4.4, flags: SJC
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    FastEthernet2/1, Forward/Sparse, 00:00:06/00:02:53

(*, 224.0.1.40), 00:02:35/00:02:12, RP 0.0.0.0, flags: DCL
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    Loopback0, Forward/Sparse, 00:02:35/00:02:12

Then I will inject one fault which could lead R5 not being able to ping 235.0.0.1 to which address R7 is listening.


R5#ping 235.0.0.1 repeat 10

Type escape sequence to abort.
Sending 10, 100-byte ICMP Echos to 235.0.0.1, timeout is 2 seconds:
....

-It is failed. So let's try to check the RP mapping information and pim adjacency between R1 and R4.
We will see that R4(4.4.4.4) is the prefer RP to be used. We have pim adjacency between R1 and R4.
R4 has multicast receiver for 235.0.0.1 and 235.0.0.2. Then why it is failed at the first place.

R1#show ip pim rp mapping
PIM Group-to-RP Mappings

Group(s) 224.0.0.0/4
  RP 4.4.4.4 (?), v2
    Info source: 2.2.2.2 (?), via bootstrap, priority 0, holdtime 150
         Uptime: 00:02:00, expires: 00:02:11
  RP 3.3.3.3 (?), v2
    Info source: 2.2.2.2 (?), via bootstrap, priority 1, holdtime 150

R1#show ip pim neighbor
PIM Neighbor Table
Mode: B - Bidir Capable, DR - Designated Router, N - Default DR Priority,
      P - Proxy Capable, S - State Refresh Capable, G - GenID Capable
Neighbor          Interface                Uptime/Expires    Ver   DR
Address                                                            Prio/Mode
192.168.12.2      FastEthernet1/0          03:28:29/00:01:29 v2    1 / DR S P G
192.168.14.4      FastEthernet1/1          02:32:11/00:01:16 v2    1 / DR S P G


R4#show ip mroute

(*, 235.0.0.1), 00:10:03/00:02:53, RP 4.4.4.4, flags: SJC
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    FastEthernet2/1, Forward/Sparse, 00:10:03/00:02:53

(*, 235.0.0.2), 00:08:36/00:02:52, RP 4.4.4.4, flags: SJC
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    FastEthernet2/1, Forward/Sparse, 00:08:36/00:02:52

(*, 224.0.1.40), 00:11:05/00:02:39, RP 0.0.0.0, flags: DCL
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    Loopback0, Forward/Sparse, 00:11:05/00:02:39

-Now let's try to ping whether we can reach the RP address itself or not.

R5#ping 4.4.4.4

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 5.5.5.5, timeout is 2 seconds:
U.U.U
Success rate is 0 percent (0/5)

-We find that even though we have RP(4.4.4.4) information in the multicast routing domain wide, but in fact we don't even have the reach-ability to RP. It is really tricky, right. We have RP information that we can reach and essentially we are using that RP for multicast traffic forwarding.

-This is the fault I injected by not advertising the R4 Loopback0 network into OSPF.
So I will  correct this back.

R4(config)#int loo 0
R4(config-if)#ip ospf 1 area 0


-Now R5 can ping to RP and multicast feeds sending to 235.0.0.1 is successful.

R5#ping 4.4.4.4
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 24/57/92 ms

R5#ping 235.0.0.1
Reply to request 0 from 192.168.47.7, 192 ms