WB1 8.10 PIM NBMA Mode

8.10 PIM NBMA Mode
• Configure R3 to join the multicast group 224.110.110.110 and make sure R6 can ping it.

----------------------------------------------

PIM NBMA mode is an extension to PIM protocol operations on WAN interfaces,
particularly for Frame-Relay and ATM which utilize the concept of virtual-circuits.

Look at the figure above. First, imagine that R5 is forwarding multicast traffic
down to R1, R2 and R3. By default, all multicast packets are treated as
broadcast on the Frame-Relay segment, and queued in the special broadcast
queue. This queue is a priority queue, used to store the routing protocol updates
and L2 keepalives. Packets from this queue are replicated and sent over all
active VCs terminating on the interface. This is called “pseudo-broadcast” and is
performed at the router’s CPU level. Needless to say, this procedure is very CPU
intensive when multicast flows are intensive. Not to mention that it may also
block critical routing updates on the interface.

Secondly, PIM treats the Frame-Relay interface as a “broadcast” media. That is,
it assumes that all multicast packets received on this interface are heard by all
members connected to the cloud. However, Frame-Relay is a non-broadcast
technology, and it only works like broadcast in case of a fully meshed topology. If
you look at the figure above, you will see that the hub-and-spoke topology does
not satisfy this requirement. When R1 sends a multicast packet, only R5 receives
it. Based on the RPF rule, it will never send the packet back out of the same
interface. Thus, any multicast packets sent from one spoke will never reach other
spokes. If you want to resolve this issue, you have to configure sub-interfaces on
R5 for all spokes.

The other issue that comes from the NBMA nature of Frame-Relay technology is
that spokes don’t hear each other’s PIM messages. For example, if R1, R2 and
R3 all have multicast subscribers, they all build SPT trees across R5. At R5, all
the trees converge to a single (S,G) state. Now suppose that R1 loses its last
receiver, and sends a PIM Prune message to R5. Since R5 assumes that all
other routers also heard this message, it declares that the shared segment is free
of any receivers. After this, R5 prunes the (S,G) state and leaves R2 and R3
without multicast traffic. Both R2 and R3 never had a chance to override the PIM
Prune message sent from R1, as they never heard it.

PIM NBMA mode resolves all of the above issues. First of all, it works only with
PIM SM (sparse mode groups), as it relies on PIM Join messages to function.
Secondly, it treats the “monolithic” Frame-Relay interface as a collection of pointto-
point links connected to other nodes. It does so by tracking the PIM Join
messages received from those neighbors. For every neighbor that sends a Join
message the router creates a separate (S,G) state bound to this neighbor’s IP
address. Now this state emulates a point-to-point link connected to this neighbor.
All PIM Prune messages received from this neighbor will only affect its own (S,G)
state, leaving other neighbors’ states intact. Also, any multicast traffic received
from this neighbor is treated like it has been received from a point-to-point link.
Thus, the RPF procedure will allow forwarding the multicast packets back out of
the same interface to all other interested neighbors. Finally, PIM NBMA mode
replaces the ineffective pseudo-broadcast replication on all PVCs with fastswitched
packet distribution only to the PVCs with subscribed neighbors. This
saves router CPU resources and WAN bandwidth.

Notice that you may enable NBMA mode on a PIM SM/DM interface, even
though this is not the recommended configuration. It will only work for groups
signaled via sparse mode.

Rack1R5(config-if)#ip pim nbma-mode
PIM nbma-mode is not recommended for sparse-dense-mode

----------------------------------------------

R3:
ip multicast-routing
!
ip access-list standard SPARSE_GROUPS
permit 224.0.0.0 0.255.255.255
!
ip pim rp-address 150.1.5.5 SPARSE_GROUPS
!
interface Serial 1/0.1
ip pim sparse-dense-mode
!
interface Loopback0
ip pim sparse-dense-mode
ip igmp join-group 224.110.110.110

R5:
interface Serial 0/0/0
ip pim nbma-mode

----------------------------------------------

First we are going to temporarily disable the serial link between R4 and R5 to
prevent R5 from building a SPT to R6 over that link. With this serial link down R1
the, DR for the VLAN 146 segment, will register R6 with R5, the RP. R5 will then
build the SPT to R6 across the FR cloud. As you have probably already noticed
there is an additional situation we must deal with - by default R3 will prefer R5's
Loopback via SW1. To correct this, we will lower the metric on R3's Frame Relay
interface to a value of 10, to ensure R3 builds the SPT towards the RP correctly.

R4:
interface Serial 0/1/0
shut

R3:
interface Serial 1/0.1
ip ospf cost 10

Now ping the group from R6 before you apply the NBMA mode configuration.
The operation will fail, and you can see that the OIL for the group on R5 is Null.
Note that the multicast traffic has to go out the Serial 0/0/0 interface of R5 to
reach R3, but it can’t because it arrived on S0/0/0 from R1 thus the OIL is
“empty” or Null.