Multicast over FR NBMA 1

This lab focus on Frame Relay NBMA, Non-Broadcast Multiple Access… the confusion already begin from the title : ) a multiple access network shouldn’t support broadcast?

In this first part I will try to describe the problematic forwarding of multicast over FR NBMA as well as different solutions to remediate to the problem, subsequent parts will focus on the deployment of those solution.

Well, the issue is a result of the difference between how layer2 operates and how layer 3 consider the result of layer2 functioning.

Let’s begin by the layer2, in the case of Frame Relay it is composed of Permanent Virtual Circuits each one is delimited by a physical interface in the both ends and a local Data Link Connection identifier (DLCI)mapped to each end; so there is no multi-access network at all at the layer 2, just the fact that multiple PVCs ends with a single physical interface or sub-interface gives the illusion that it is a multiple access network (figure1).

Figure1 : layer2 and layer3 views of the network

With such configuration of multipoint interfaces or sub-interfaces a single subnet is used at the layer 3 for all participant of the NBMA which makes the layer think that it is a multiple access network.

Let’s precise that we are talking here about partial meshed NBMA.

All this misunderstanding between layer2 and layer3 about the nature of the medium makes that broadcast and multicast doesn’t work.

Many solutions are proposed:

1 – “Pseudo broadcast” – IOS feature that emulates the work of multicast.

Figure2 : Interface HW queues

In fact a physical interface has two hardware queues (figure2) one for unicast and one (strict priority) for broadcast traffic, and because the layer 3 think that it is a multi-access network it will send only one packet over the interface and hope all participants in the other part will receive that packet, which will not happen of course.

Do you remember the word “broadcast” added at the end of a static frame relay mapping?

Frame-relay map ip X.X.X.X <DLCI> broadcast

This activate the feature of pseudo broadcasting, the router before sending a broadcast packet, will make “n” copies and send them to the “n” spokes attached to the NBMA whether they requested it or not. Finally such mechanism is against the concept of multicasting, therefore pseudo broadcast can lead to serious issues of performance in large multicast networks.

Another issue with pseudo broadcast in an NBMA HUB & spoke topology is when one spoke forward multicast data or control traffic that other spokes are supposed to receive, particularly PIM prune and override messages.

The concept is based on the fact that if one downstream PIM router send a prune message to the upstream router, other downstream routers connected to the same multi-access network will receive the prune and those who still want to receive the multicast traffic will send a prune override (join) message to the upstream router.

As we mentioned before the HUB is capable of emulating multicast by making multiple copies of the packet, but only for traffic forwarded from HUB internal interfaces to the NBMA interface or just generated at the HUB router, but not if traffic is received from the NBMA interface.

Conclusion è do not use PIM-DM nor PIM-SPARSE-DENSE (auto-RP) mode with pseudo broadcasting, however you can use PIM-SM with static RP.

2 – PIM NBMA mode – makes more clear relationship between layer2 and layer3, NBMA mode will tell “the truth” to the layer 3: that the medium is in reality not a multi-access but a partial meshed NBMA so PIM can act accordingly.

The router now will track IP addresses of neighbors from which it received a join message and make an outgoing interface list of such neighbors for RPT (*,G) and SPT (S,G).

PIM NBMA mode still do not support DENSE mode nevertheless it is possible to use Auto-RP with PIM-SPARSE-DENSE mode ONLY if you make sure that the mapping agent is located on the HUB network so it can communicate with all spokes.

3 – Point-to-point sub-interfaces – If you want to avoid all previously mentioned complications with multipoint interfaces in an NBMA HUB & Spoke, you can choose to deploy point-to-point sub-interfaces, spokes will be treated as they are connected to the HUB through separated physical interfaces with separated IP subnets and the layer 2 is no more considered multi-access.

4 – GRE Tunneling – I would like to mention another alternative by keeping the NBMA multipoint FR interface with all that can be considered as advantages such saving IP addresses, and just make it transparent by deploying tunnel technology multipoint-GRE.

With a multipoint GRE logical topology over the layer3 in which multicast will be encapsulated inside GRE packets and forwarded as unicast and decapsulated at the layer3 on the other side of the tunnel without dealing with layer2.