Multicast – PIM, RP, BSR and MSDP for Multicast Across Routed Networks

Extreme Networks Networking
Tristan SelfLeave a Comment on Multicast – PIM, RP, BSR and MSDP for Multicast Across Routed Networks

Multicast is a networking method used to efficiently transmit data to multiple recipients simultaneously. Unlike unicast (one-to-one) and broadcast (one-to-all) communication, multicast is a one-to-many or many-to-many method where data is sent only to devices that are interested in receiving it, rather than to all devices on a network. In multicast, devices that want to receive specific data streams (e.g. a TV channel) join a multicast group. Each multicast group is identified by a unique IP address from a reserved range (224.0.0.0 to 239.255.255.255 for IPv4). Devices that don’t belong to the group don’t get the multicast data, which conserves bandwidth.

However, if a sender of a multicast stream is on a different VLAN/Layer 2 segment to the receiver of said stream additional mechanisms are required to facilitate the reliable and efficient transport of this multicast traffic across the network. Techniques such as PIM (Protocol Independent Multicast) which includes topics such as RP (Rendezvous Points), BSR (Boot Strap Routers) for operational, but additionally depending on the network configuration additional techniques such as MSDP (Multicast Source Discovery Protocol) are required; all these topics are the subject of this document. 

Introduction and Example Environment

We discussed in Multicast – IGMP Snooping and IGMP Querier – Sender and Receiver(s) in same VLAN/Layer 2 Segment about how a Receiver (client) can join a Network Group (Stream) being provided by a Sender (Server) on a network where both the Sender and Receiver(s) are within the same VLAN/Layer 2 segment.

However, commonly the Receiver (client) will be connected to a different VLAN/Layer 2 segment than the Sender (Server) at which point Multicast will not work. PIM allows Multicast to work between different VLAN/Layer 2 segments, by facilitating the join requests from a receiver (client) to leave the source VLAN/Layer 2 segment traverse a routed layer 3 network (across one or more hops) and then to find, then utilise a Network Group (Stream) being provided by a Sender (Server) on a different VLAN/Layer 2 segment.

We’re assuming for this document that we’re using PIM Sparse mode, other modes do exist, and those will be explored in the section PIM Modes later, but for now, assume PIM Sparse mode is in place.

Multicast Routing and PIM must be enabled on all the routers between the Sender (Server) and Receiver (Client) for the Receiver (Client) to be able to “find” and use the Network Group (stream).

Sender (Server) and Receivers (Clients) of a multicast stream should be able to unicast ping each other before PIM is configured.

Taking a simple example scenario detailed below in Diagram 1, we have two network switches separated by two routers which have a routed link between them. The Receivers (clients) TV 2 and TV3 are connected to Network Switch B and are in a different VLAN/Layer 2 segment to the Sender (Server) that is connected to Network Switch A which is in a different VLAN/Layer 2 segment.

Diagram 1

In Diagram 1, the two Receivers (clients) TV2 and TV3 will be unable to join the Network Groups (Streams) because their join requests will be unable to reach the VLAN/Layer 2 Segment where the Sender (Server) is hosted.

It’s assumed that IGMP Snooping has already been enabled on Network Switch A and Network Switch B, but that only helps the switch determine which ports are requesting a Network Group (Stream) it doesn’t help the Layer 3 Routing aspect. To remediate this we need a few more mechanisms to be turned on and configured these, which are discussed in more detail later are:

  • Multicast Routing
  • IGMP Querier (typically the Multicast Router for the VLAN/Layer 2 segment)
  • PIM (Protocol Independent Multicast)
    • PIM Mode (discussed later)
  • RP (Rendeavous Point)
  • BSR (Bootstrap Router)

So in Diagram 2, we have all these mechanisms present and configuration, and we’ll discuss each one in turn.

Diagram 2

We’ve ensured that IGMP Snooping has been enabled on both Network Switch A and Network Switch B, this ensures that the switches are aware of the join requests being sent by the Receivers (Clients) and ensures the multicast can work reliability and efficiently. We have then enabled Multicast Routing on both Router A port 1 and Router B port 1, essentially enabled for VLAN A and VLAN B respectively, we have then also specified that both of these are IGMP queriers for their respective VLANs/Layer 2 segments; this means that the multicast streams can be routed through those interfaces, but additionally that the IGMP Querier listens for the join requests from Receivers (clients) and ensures the list of clients is kept up to date periodically for efficiency (of network usage) and reliability of the streams.

We’ve then enabled Multicast Routing on the port 2, which is VLAN C, which is a point to point link between Router A and B, this is the routing component, VLAN A and VLAN B are separate VLANs/Layer 2 Segments and are separated by this point to point link. Because Multicast traffic will be flowing across this link, we must enable multicast routing on these interfaces too.

And then we have PIM, we have enabled PIM on Router A and Router B (the mode has also been configured, but this will be covered later), then to allow PIM to work, we need some roles to be assigned. We have enabled a Rendezvous Point (RP) on Router A, which is where the Routers which have PIM enabled will look to see what Network Groups (Streams) are being made available on the network; so they then know where to send the multicast join requests to. We’ve also assigned the BSR (Bootstrap Router), this acts as a way that routers on the network can find the Rendezvous point. Okay in this example it’s not really that helpful, there are only 2 routers, but if you had 10 or 50 routers, you wouldn’t want to manually specific the RP each router should use, you’d want all the routers to autoconfigure themselves with the desired RP, and that is where BSR (Bootstrap Router) comes in.

Multicast Mechanism Overview

As mentioned there a some mechanisms required to make multicast work when flowing across a routed network between VLAN/Layer 2 segments via Layer 3 routing.

  • Multicast Routing
  • IGMP Querier (typically the Multicast Router for the VLAN/Layer 2 segment)
  • PIM (Protocol Independent Multicast)
    • PIM Mode (discussed later)
  • RP (Rendeavous Point)
  • BSR (Bootstrap Router)

Multicast Routing (and IGMP Querier)

We enable multicast routing on the gateway of each VLAN/Layer 2 segment where multicast receivers will be present, this allows multicast traffic to be routed through that interface, without it enabled the multicast traffic wouldn’t be routed, it would just be discarded by the interface if it were to be received.

We also enable the IGMP Querier on that same interface so that there is at least one switch on the VLAN/Layer 2 segment that is acting as the IGMP Querier, without the querier, receivers (clients) on the VLAN/Layer 2 segment may or may not be able to join a stream correctly, because there is no IGMP querier to maintain the list of current receivers (clients). Or in some cases they may be able to join the stream successfully, only to be disconnected after a period of time, because the stream has been erroneously “pruned” by the IGMP Snooping role, because the switches didn’t know it was still being used and if they are not told otherwise will “time out” the joined client after a period of time.

PIM (Protocol Independent Multicast)

PIM is a way of routing multicast traffic between VLANs of an existing layer 3 routeable network. The Sender (Server)  and Receivers (Clients) of a multicast stream should be able to unicast ping (i.e. have routed connectivity to) each other before PIM is configured. So where does PIM fit in? See diagram 3 below.

Diagram 3

Multicast Routing must be enabled on the routing interface of all VLANs where multicast traffic will traverse, PIM must be enabled on all routers where multicast traffic will traverse. You don’t need PIM on a VLAN/Layer 2 Segment assuming that there is no routing and IGMP and IGMP Snooping are enabled.

RP (Rendezvous Point)

PIM defines the use of a Rendezvous Point (RP) which facilitates PIM operation.

RP (Rendezvous Point) and CRPs (Candidate Rendezvous Points), the PIM RP is the central router where other PIM routers register new multicast streams (from Senders/Servers) and also look for multicast streams being serviced by the RP (on behalf of Recievers/Clients).

Configuring a router as a PIM CRP means the router to advertise to be a candidate for the RP for a list of multicast streams in the configured policy file.

The CRP with the lowest priority value is elected as the RP.

The RP is configured with a list of multicast ranges, i.e. Network Groups (Streams) that the RP will service. 

There must be at least one RP for a given Network Group (Stream), also known as a PIM domain, although there can be more than one RP on the network for load balancing and redundancy, so you’d configure two routers as CRPs, typically a pair of distribution switches, A and B, so that in the event that switch A were to fail, its counterpart B would take over. 

So in our example Diagram 2, the Receiver (Client) would make a join request, the request would make its way to the Multicast Router for the VLAN/Layer 2 Segment, this would then check to see where its RP is then made a request to the RP, the RP would have a list of all the available Network Groups (Stream), and the RP would essentially “join” or Rendezvous 🙂 the Network Group (Stream) from the Sender (Server) and the join request from the Receiver (Client) together, so the client can then receive the stream.

BSR (Bootstrap Router)

So the configuration of the RP on a small network like ours is no problem, we’ve set Router A to be the RP, and Router B is then manually configured to use Router A as the RP, that’s fine, but if we had a larger network and/or we wanted to ensure resilience if the router that was the RP was to go away for some reason, a replacement could take its place, without reconfiguration of all the routers. The BSR (Bootstrap Router) deals with actually this.

The PIM BSR informs all the other PIM routers of where to find the RPs in the PIM domain and also which Network Groups (Multicast Streams) are being serviced by each RP.

To illustrate here is an example in Diagram 4.

Diagram 4

So as you can see we now have four routers, Router A, B, C and D. 

Router A is configured as the CBSR (Candidate Bootstrap Router), in this case none of the other routers are CBSRs, so in the election Router A becomes the BSR, if other routers were also CBSRs, the CBSR with the highest priority value is elected as the BSR.

A Router with PIM enabled will attempt to find the BSR within the PIM domain for the Network Group (Multicast Stream) it wants, once it has found the BSR, it is able to find the RP (Rendezvous Point) for the PIM domain and the Network Groups (Multicast Streams) it wants, or more specifically what its downstream receivers (clients) want. 

So in the Diagram 4 example above Routers B, C and D at the point of booting (with PIM already enabled) or enabling PIM (for the first time) will be informed of where the BSR is for the PIM domain, from what the BSR tells them, they will then determine the RP for the PIM domain, and therefore will have the information they need to join receivers (clients) with senders (Servers), as and when downstream receivers (clients) request a particular Network Group (Multicast Stream).

If you don’t statically configure the RP on each of the routers manually, there must be at least one CBSR specified within the PIM domain, so that one BSR will be elected and functional. 

It is strongly recommended to use a CBSR and BSR coupled with at least 2 RPs so that routers can automatically determine which RP is currently active for a particular PIM Domain to allow them to find Network Groups (Multicast Streams), but also additionally respond automatically, i.e. to select a replacement, if the router acting as the RP and/or the router acting as the BSR were to fail or require maintenance. 

PIM Modes

Fundamentally the differences between sparse and dense mode PIM is:

  • Dense Mode (PIM-DM) – we forward multicast traffic on all interfaces until a downstream router requests us to stop forwarding.
  • Sparse Mode (PIM-SM) – we do not forward multicast traffic on any interface until a downstream router requests that we start to forward it.

But there is the third one Sparse-Dense mode, this is something in between, it allows PIM to operate in sparse or dense mode depending on the multicast group. When you enable sparse-dense mode, the interface is treated as dense mode if the multicast group is in dense mode. If the group is in sparse mode, the interface is treated in sparse mode. You must have a rendezvous point (RP) if the interface is in sparse-dense mode, and you want to treat the group as a sparse group. You might use Sparse-Dense Mode if you want to use AutoRP (Cisco) which allows the discovery of the RP (Rendevous Point) automatically. Sparse-dense mode just means it will fall back to dense mode (broadcast) if there is no PIM enabled router on the network, meaning your sparse mode devices will work.

For this document, we’ll ignore Sparse-Dense mode and just focus on the two main ones: Sparse and Dense modes. 

So to recap: When using Dense Mode the multicast traffic is flooded on all interfaces until a downstream router “says please don’t forward me this multicast traffic I don’t have any receivers” by sending PIM Prune requests. However, with Sparse mode it doesn’t forward multicast traffic unless a downstream router forwards it a PIM Join request, at which point it starts to forward traffic down just that interface.

So now we know the different types and how they work, let’s explore a multicast worked example.

Multicast Worked Example (PIM, RP and BSR)

Here is a worked example of a more real world example network based on Extreme Networks (XOS/SwitchEngine) switches, with the relevant configuration for each component of the network configuration, it has been simplified for brevity, but provides the basic idea of the overall solution and configuration required. In our example we have a VLAN called “tv” which has a single Video Server which is the “Sender”, we then have a set of routers in an OSPF area which are exchanging routes. The routing interfaces for each of the VLANs, the one at the top and the one at the bottom of the diagram are present on it’s nearest Distribution Switches as a VRRP pair (although this doesn’t matter in this case particularly). The client is on another VLAN called “desktop1” which is a separate layer 3 network meaning multicast routing is required for multicast streams to be able to traverse the network.

We also have Sparse mode in use, with a particular set of Network Groups (streams) which is being advertised from a particular RP. 

It is possible to have multiple RPs on a network, each of which act as RP for a different set of Network Groups (Streams).

Diagram 5

Edge Switch A – send-edge-sw-a

The switch to which the source of the multicast streams is connected, minimal configuration is needed to ensure that the multicast streams use separate memory on the switch. You don’t have to have this, but it is recommended.

configure igmp snooping filters per-vlan
configure forwarding ipmc lookup-key mac-vlan

Sender Distribution Switches – send-dist-sw-a & send-dist-sw-b

The common distribution switches are most active in the multicast configuration, because these are responsible for receiving the multicast streams from the source server and distributing them across the rest of the network via the concept of a Rendezvous Point. IPMCforwarding is needed on the “tv” VLAN that houses the source server and the Point to Point links to the core layer switches to allow multicast packets to be routed just like unicast packets are routed. PIM is enabled and configured for the “tv” VLAN to listen for publishers and subscribers of multicast streams to allow the multicast streams to be routed like uni-cast packets are. Additionally, the Rendezvous Point is configured by use of a policy to specify which stream addresses should be accessible across the network.

enable ipmcforwarding vlan "tv"
enable igmp
enable igmp snooping
 
configure pim add vlan "tv" sparse
configure pim crp vlan "tv" "rp-list" 60
configure pim cbsr vlan "tv" 60
  
Policy: rp-list
entry mcast1 {
if match any {
}
then {
    nlri 239.1.0.0/16 ;
    nlri 239.4.0.0/16 ;
    nlri 239.101.0.0/16 ;
    nlri 239.121.0.0/16 ;
    nlri 225.50.0.0/16 ;
    nlri 224.2.127.254/32 ;
    permit  ;
}
}

Using send-dist-sw-a as an example we can see two routed links one going to core-sw-a and one going to send-dist-sw-b, each of these are routed point to point links, because of this we require both PIM to be enabled on the VLAN, but also multicast forwarding, see below, of course the same is also required in reverse on the B side distribution switch send-dist-sw-b.

enable ipmcforwarding vlan "SendA-CoreA"
configure pim add vlan "SendA-CoreA" sparse
 
enable ipmcforwarding vlan "SendA-SendB"
configure pim add vlan "SendA-SendB" sparse

Core Switches – core-sw-a & core-sw-b

The Core switches just pass multicast join requests and traffic, because of this they require PIM to be enabled and any and all interfaces (and Point to Point VLANs) that will pass multicast traffic to have multicast forwarding and PIM enabled.

enable ipmcforwarding vlan <P2P-VLAN>
enable pim
configure pim add vlan <P2P-VLAN> sparse

Receiver Distribution Switches – rec-dist-sw-a & rec-dist-sw-b

The receiver distribution switches will require the same multicast forwarding to be enabled on the VLAN interface for “desktop1” being that “desktop1” VLAN will contain clients which wish to connect to multicast streams. By enabling multicast forwarding on the interface IGMP Snooping is automatically activated.

enable ipmcforwarding vlan "desktop1"
configure pim add vlan "desktop1" sparse

Edge Switch B – rec-edge-b

No specific configuration is required.

Stepping through the above diagram:

Step 1 – The sender server sends a multicast stream 239.1.1.1 onto the network, this is picked up by the routing interface for the “tv” VLAN/subnet which is on send-dist-a distribution switch. In this case the switch is the RP, however if it wasn’t, and since we are using PIM Sparse Mode, it would pass this information onto the RP. If there are no clients (recievers) who are interested in the 239.1.1.1 stream the RP will reject the PIM register message (the setting a suppression timer) to the upstream router (if there is one), which in our case there isn’t. If however there is at least one receiver, the RP will accept the PIM register message.

Step 2 – A receiver (client) wishes to see the multicast stream 239.1.1.1, so it sends a IGMP Join request, this being not in the 192.168.20.0/24 subnet it is therefore directed at the default gateway, which happens to be the routed interface on the rec-dist-sw-a switch. The rec-dist-sw-a distribution switch which is PIM enabled has learnt where the RP is, so it then sends this Join request as a PIM Join request towards the RP which in this case is the next hop router core-sw-a. The next hop router (core-sw-a) then in turns sends this PIM join request onto the RP.

Step 3 – Once the PIM Join has been received by the RP, the RP then starts to forward the multicast traffic towards core-sw-a (because it sees this as the source interface), at that point core-sw-a then sends the multicast traffic towards the source of the PIM join message, which is rec-dist-sw-a, and then rec-dist-sw-a then then forwards the multicast stream onto the requesting client PC (receiver).

In the example the RP was also the router which first gets the multicast stream from the sender, but this may not always be the case. It’s also possible that the route from the client (receiver) to the RP and the route to the sender may be different, in fact in some cases so different that the sending traffic “via” the RP would be suboptimal. In such an eventuality a router along the path, which has learnt the sender source IP from the RP may instead join the multicast stream directly from the routes nearest, thus bypassing the RP, when this happens a router along the path will send PIM Prune requests to “prune” back the stream from being sent via the suboptimal path. Multicast traffic going via the RP is known as RPT (Root Tree Path), however if a more optimal path is available swapping to this is known as SPT (Source Tree Path). 

Multicast Worked Example (including MSDP)

Before we can go through a worked example which includes MSDP, we need to define what MSDP actually is!

MSDP is Multicast Source Discovery Protocol, a protocol used in multicast networking to enable the discovery and sharing of active multicast sources between different multicast (PIM) domains; it facilitates inter-domain multicast communication, allowing multicast receivers in one domain to receive traffic from senders (sources) in another multicast (PIM) domain. MSDP is typically used by Internet Service Providers (ISPs) or large organizations that need multicast communication across autonomous systems (AS). You may also need MSDP if you have a network where there are different types of network infrastructure in use, and you can’t have a single PIM domain that crosses both, or some of your network infrastructure doesn’t support PIM, although it might support some other mechanism; so you need to operate two separate PIM multicast domains and use MSDP to “join” them together.

In essence, it allows the RP on each PIM-SM domain to learn about the network groups (i.e. multicast streams) in other PIM-SM domains. These RPs are configured with MSDP peers (in the other PIM-SM domain(s)) and use those to pass the information about the multicast network groups (multicast streams) they know about to each other.

The diagram 6 below provides a very simple example of how MSDP works in a two PIM-SM domain network. Each PIM-SM domain has its own RP which maintains the list of the network groups available in its own domain, i.e. if there is a TV Server (Sender) in PIM-SM Domain A providing network group 224.0.0.2 (multicast stream), the RP on Router A is aware of this stream being available. The RP can provide the network group information to other routes in the PIM domain (not pictured) so clients in different subnets can reach the multicast streams provided by the TV Server (Sender). In relation to MSDP, the RP on Route A being an MSDP peer provides the information of the network groups (multicast streams) it is aware of via SA messages to any and all MSDP peers it is configured with; in this example there is only one other MSDP peer, the RP on Router B. 

Its worth noting that each RP is still the root of its own PIM-SM Domain, multicast tree. 

Let’s step through an example:

TV 2 which is connected to Network Switch B in PIM-SM Domain B if say it wanted to view the 224.0.0.2 stream, it would make a join request, the IGMP Querier for the VLAN i.e. the network subnet would get this join request and forward it to the RP (Router B), in our example the RP is the same router as the IGMP Querier. 

Without MSDP the RP on Router B would not be aware of the 224.0.0.2 network group (multicast stream) because it is being provided by a Sender (TV Server) in PIM-SM Domain A, these would be acting as two independent PIM domains.

But with MSDP as we have configured in our example (diagram 6), Router A and Router B being MSDP peers means that Router A’s RP has learnt of the 224.0.0.2 network group and propagated that information to Router B’s RP; which means when TV 2 requests it Router B is aware of it. Router B then forwards a join request to Router C, Router C then forwards a join request to Router A, Router A then make a join request to the network switch A (which is aware of where TV Server is).

Now that Network Switch A knows there is a reciever/client (or clients) wanting the stream on as it sees it Port 24 (of Network Switch A) it forwards the 224.0.0.2 multicast stream out that port. Router A being aware of there being reciever/client (or clients) on port 2 then sends that 224.0.0.2 out of port 2, Router C is aware of there being reciever/client (or clients) on it’s port 2 then sends that 224.0.0.2 stream out of it’s port 2. Then Router B which is aware of there being a reciever/client (or clients) on port 1 sends that 224.0.0.2 stream out port 1 (towards Network Switch B).

Although a bit off the MSDP topic, this point this is where the IGMP Snooping kicks in, if Network Switch B did not have IGMP Snooping enabled, it would flood this traffic out of Network Switch B Ports 1 and Port 2, when only Port 1 (i.e. TV 2) wanted it. However, in our example Network Switch B does have IGMP Snooping enabled, and it’s knowing that there is a receiver/client on Port 1 that is wanting the 224.0.0.2 forwards that traffic out that port toward the consuming client.

Diagram 6

Although this is a simple example where there is no redundancy, in a full production usage you should ensure that you have redundant unicast and multicast routers, you should also ensure you have redundant RPs (and BSRs if possible) and that each RP has MSDP peering with both the RP and any CRP (Candidate Rendezvous Points) just in case one were to fail (or require maintenance) so that the multicast streams and joins continue to work.

Using VLC Player to View Multicast Stream

Let’s say you want to use VLC Player to view a multicast stream,

Open a Network Stream with VLC Player

Open VLC Player, click on “Media” from the menu, then “Open Network Stream..>”, enter the required multicast stream URL:

Your multicast stream network group address will likely be different, but you should be entering it in the format: udp://@239.4.6.0:1234

Where the udp:// specifies the protocol, the @239.4.6.0 specifies the multicast group (i.e. multicast address) of a particular stream and the :1234 specifies the port number of this particular stream.

Session Announcement Protocol (SAP) Server

What? Another protocol? Yes, SAP, Session Announcement Protocol is another protocol which provides end-users an easy way to find a stream, rather than having to manually enter it via multicast address. A SAP Server which is located on the network, provides the list of available streams to a compatible client, meaning an end-user doesn’t need to know the Network Group Multicast address for say BBC News multicast stream, they can instead look it up from a kind of TV Guide channel list.

But how does the client (e.g. VLC Player) know where the SAP server is? It uses a multicast Network Group address of course!

RFC 2974 defines the multicast address: 224.2.127.254 which is what the SAP Server (announcer) sends the announcement packet on a well known multicast address and port (note there is no rendezvous mechanism). A client such as VLC Player which supports the discovery of multicast streams via SAP, just sends a join request to this network group address (multicast stream) when the user requests channel list within the software.

For example the output of the local edge switch port (1:32) my PC is connected to, you can see that my client has sent a join request for the 224.2.127.254 network group (i.e. the SAP Server).

switchA.6 # show igmp group | include 1:32
224.2.127.254     2   desktop01       1:32     2
239.195.255.255   2   desktop01       1:32     2
239.255.255.250   2   desktop01       1:32     75
224.0.0.251       2   desktop01       1:32     73
224.0.0.252       2   desktop01       1:32     78
239.255.255.255   2   desktop01       1:32     3
224.0.0.255       2   desktop01       1:32     3

And within VLC media player it renders the output from the SAP server (via the 224.2.127.254 multicast address), so I can see the list of multicast streams (in this case TV Channels) which the TV Server (Sender) has available, double click to view the stream, or right click and examine the information to see that particular multicast stream Network Group address.

Additional Documentation

Related Posts

Schedule Reboot of Extreme Networks XOS Switch

Tristan Self

Cisco 4500 IOS Upgrade

Tristan Self

Cisco VPN Client to PIX not Passing Traffic

Tristan Self

Leave a Reply

Your email address will not be published. Required fields are marked *