Multicast over NBMA with auto-rp and a spoke mapping agent

Here is the topology. There is no PVC between R2 and R3. Nice frame cloud, eh?


R1 (hub), R2 and R3 are connected via frame-relay: 172.12.123.0/24.
R4 connects to R3 via another serial connection: 192.168.14.0/24.

OSPF area 0 is everywhere.

R1 will be the RP-candidate.
R3 will be the mapping agent.
R2 will be joining group 232.0.0.2.
R4 will sending pings to 232.0.0.2.

R1 will announce itself as RP candidate and R3 as the MA:

R1(config)#ip pim send-rp-announce lo 0 scope 5

R3(config)#ip pim send-rp-discovery loopback 0 scope 5

Now according to this doc:

Using IP Multicast Over Frame Relay Networks

"All candidate RPs must be connected to the MA"
AND
"All MAs must be connected to all PIM routers"

In order for R2 to successfully receive the rp-to-group mappings from R3, they need to be PIM neighbors. The reason is R1 will not forward an autorp message received on it's frame-relay interface back out that same interface. So R2 will never get it!

We can create a tunnel between the two and enabling sparse-mode on the tunnel:

R2(config)#int tun 0
R2(config-if)#ip address 172.12.23.2 255.255.255.0
R2(config-if)#tunnel source 172.12.123.2
R2(config-if)#tunnel destination 172.12.123.3
R2(config-if)#ip pim sparse-mode

R3(config)#int tun 0
R3(config-if)#ip address 172.12.23.3 255.255.255.0
R3(config-if)#tunnel source 172.12.123.3
R3(config-if)#tunnel destination 172.12.123.2
R3(config-if)#ip pim sparse-mode

Now R2 and R3 are PIM neighbors:

R2#show 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
172.12.123.1 Serial1/0 01:44:07/00:01:38 v2 1 / S
172.12.13.3 Tunnel0 00:06:29/00:01:42 v2 1 / S

However theres is still one issue. When R2 receives the auto-rp messages from R3 the rpf check fails because R2 uses its FR interface to perform the rpf check:

R2#show ip rpf 3.3.3.3
RPF information for ? (3.3.3.3)
RPF interface: Serial1/0
RPF neighbor: ? (172.12.123.1)
RPF route/mask: 3.3.3.3/32
RPF type: unicast (ospf 1)
RPF recursion count: 0
Doing distance-preferred lookups across tables

Thus R2 will never learn the rp-to-group mapping. We can fix this by making a static mroute for R3's loopback pointing towards the tunnel:
R2(config)#ip mroute 3.3.3.3 255.255.255.255 Tunnel0


Now the RPF will pass for auto-rp messages:

R2#show ip rpf 3.3.3.3
RPF information for ? (3.3.3.3)
RPF interface: Tunnel0
RPF neighbor: ? (172.12.23.3)
RPF route/mask: 3.3.3.3/32
RPF type: static
RPF recursion count: 0
Doing distance-preferred lookups across tables

Let's verify on R4:

R4#ping 232.0.0.2 repeat 5

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

Reply to request 0 from 172.12.123.2, 500 ms
Reply to request 1 from 172.12.123.2, 188 ms
Reply to request 2 from 172.12.123.2, 492 ms
Reply to request 3 from 172.12.123.2, 300 ms
Reply to request 4 from 172.12.123.2, 292 ms

Sweet!