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!

RPF check

RPF check is another way to prevent spoofing. If you are familiar with Multicast routing then this shouldn't be too hard to understand. Basically the router looks up the source IP address of the packet in the route-table and (depending on the configuration) can drop it if the source interface doesn't match the interface in the route table.

For example, if R4 receives a packet on serial 1/0 but the source address isn't in it's table it drops the packet. Let's try it out.

Here's our topology:

[R1]----[R4] s1/0 ----[R5]

R1-R4: 10.0.0.0/24
R4-R5: 155.1.45.0/24

OSPF area 0 is on all interfaces

R5 has 2 loopbacks:
155.1.55.55/32
155.1.155.155/32

We are not going to advertise the loopbacks into OSPF so that the RPF check will fail on R4. We are also going to use an ACL so that only one loopback is actually checked via RPF.

On R4:

R4(config)#access-list 100 permit ip 150.1.55.0 0.0.0.255 any
R4(config)#access-list 100 deny ip any any log

R4(config-if)#int s1/0
R4(config-if)#ip verify unicast reverse-path 100

That's it for the config! Let's look at R4's routing table.

R4#show ip route | begin Gateway
Gateway of last resort is not set

155.1.0.0/24 is subnetted, 3 subnets
C 155.1.0.0 is directly connected, Serial1/1
C 155.1.4.0 is directly connected, Loopback0
C 155.1.45.0 is directly connected, Serial1/0
10.0.0.0/24 is subnetted, 1 subnets
C 10.0.0.0 is directly connected, FastEthernet0/0

Notice that R4 has no route to either of R5's loopbacks, but it will only perform an RPF check on packets coming from 155.1.155.155. On R5 (both pings get no reply because R4 has no route back but only the first set get blocked by R4 as we'll see below):

R5#ping 10.0.0.1 source 155.1.155.155

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.1, timeout is 2 seconds:
Packet sent with a source address of 155.1.155.155
.....
Success rate is 0 percent (0/5)
R5#ping 10.0.0.1 source 155.1.55.55

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.1, timeout is 2 seconds:
Packet sent with a source address of 155.1.55.55
.....
Success rate is 0 percent (0/5)
R5#

On R4:

R4#
*Mar 1 08:21:29.285: %SEC-6-IPACCESSLOGDP: list 100 denied icmp 155.1.155.155 -> 10.0.0.1 (0/0), 1 packet
R4#

For more go here:
Configuring Unicast Reverse Path Forwarding