Tuesday, July 29, 2008

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:
R4 connects to R3 via another serial connection:

OSPF area 0 is everywhere.

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

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"
"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
R2(config-if)#tunnel source
R2(config-if)#tunnel destination
R2(config-if)#ip pim sparse-mode

R3(config)#int tun 0
R3(config-if)#ip address
R3(config-if)#tunnel source
R3(config-if)#tunnel destination
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 Serial1/0 01:44:07/00:01:38 v2 1 / S 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
RPF information for ? (
RPF interface: Serial1/0
RPF neighbor: ? (
RPF route/mask:
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 Tunnel0

Now the RPF will pass for auto-rp messages:

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

Let's verify on R4:

R4#ping repeat 5

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

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



  1. Hey man, this site rule !!!

    anyway, i tried this config, with no PVC btween r2 and r3!!

    i configured the hub as multipoint and the spokes as point to point and adjusted the timers, so i could succesfully create a neigh between the routers, BUT the spokes are not receiving any ospf updates with the loopback addresses, so i am not able to reach any loopbacks!!
    could you tell me a little bit on your config to have ospf fully operational?? i appreciate man !! regards !!

  2. wow man, i got it, simple mistake !!

    i forgot the ip ospf net broad statement on the spokes !!!

    anyway, this blog is helping me a lOT !!



Note: Only a member of this blog may post a comment.