gurfin / ENCOR #9 - The big scary multicast

I have a special appreciation for the multicast technology. Back when I used to work in first line support for a Swedish service provider of IPTV, I was always intrigued by the efficiency of using multicast to deliver the TV to peoples homes. Using multicast drastically reduced the bandwidth requirements for the central streaming sources that were used to send out the TV broadcasts onto the fiber networks. Now, in recent years service providers have moved away from this and into using unicast streaming in stead. This has the benefit of reducing complexity along the delivery path of the television traffic and makes it easier for the end customers to connect up the IPTV receiver to any internet enabled network, instead of having to connect it to a special IPTV access.

Multicast is designed for single source to multiple receivers, but is not as broad as broadcast traffic. This makes the network operate a lot more efficiently than if you were to use either uni- or broadcast. Now, on the other hand, it requires each router (and in some ways every switch) to be capable of handling the multicast traffic. In this post I will explore the basics of building and running multicast across multiple routers and switches.

The protocols used

There are typically two protocols that come to mind when you are to manage multicast in your network.

Protocol Independent Multicast

This first is Protocol Independent Multicast (PIM), which is typically used between routers to ensure that they are able exchange information about routing multicast with one another. PIM has some global commands, but must be enabled on each interface that is to receive or transmit multicast packets along the multicast path. Here is an example of PIM configuration:

!
interface GigabitEthernet0/0
 description Client network
 ip address 192.168.10.1 255.255.255.0
 ip pim sparse-mode
!
interface GigabitEthernet0/1
 description To upstream router
 ip address 10.0.12.1 255.255.255.0
 ip pim sparse-mode
 ip ospf network point-to-point
!
ip pim rp-address 10.0.12.2
!

Internet Group Multicast Protocol

The second protocol, typically used for LAN segments where the sending/receiving hosts are located, is Internet Group Multicast Protocol (IGMP). This allows the hosts to communicate with the switches and routers on a LAN segment about which multicast streams they wish to receive.

The routers on that segment can then use PIM to communicate with upstream routers in order to ensure that the source is connected to the destination.

Multicast Addresses

There are some common multicast addresses you should be aware of. Namely the following are the most important:

Multicast Trees

Multicast needs to be delivered from a single source to multiple destinations. This is often depicted as a tree.

Shared tree

This is where the RP is the single converge point for all traffic. That is, The RP is the router which all multicast stream will from to and from. This type of tree is usually associated with running PIM in what’s known as dense mode.

Shortest Path Tree

Unlike the shared tree, the source tree or Shortest Path Tree (SPT) is calculated when the source of a specific multicast group is known. This is learned through the RP. Once the source of the group is known, the SPT can be established.

There is another scenario, in which you are running neither dense or sparse mode, but in a mode known as Source Specific Multicast (SSM). This requires the end devices to know which source is intended to send the multicast before they join a specific multicast group and allows the network to establish a SPT without querying the RP first.

Different modes

As eluded to in the paragraphs above there are three different modes you can run PIM in. Dense mode, sparse mode and SSM mode. These all operate in different ways, but based on my experience sparse mode is most commonly used. SSM is the most efficient, but it also requires the receivers to know the source from which they wish to receive the multicast streams from.

There are also two other special modes: Sparse dense and Bidirectional PIM.

Dense mode

Running PIM in dense mode will cause all multicast flows to be forwarded everywhere. The PIM routers will then be able to prune the multicast streams that they do not wish to receive. The multicast tree is built from the root out towards the leaves in this mode.

Every three minutes the flooding process will restart and all multicast streams will be flooded to all routers once more, just to be pruned again.

If the Last Hop Router (LHR) har multiple different Incoming Interfaces (IIF), it will perform a Reverse Path Forwarding (RPF) check, which we will cover more soon, towards the source of the multicast stream, and then a prune message will be sent up any undesirable IIFs.

Sparse mode

In sparse mode the PIM routers need to request the specific multicast groups they wish to receive. The default is not to forward all flows, unlike dense mode. The RP is a router statically set or set through an automated election process which then orchestrates the multicast streams that are sent out by sources as well as the multicast streams that are requested by the destinations. This is usually much more efficient than dense mode, and thus it is what is usually used in production environments.

It is important to note however, that the destination devices are required to explicitly request the multicast groups they wish to receive.

If there are multiple different PIM routers on the same network segment, they will trigger a process to elect a Designated Router for that segment. The DR will be responsible for forwarding multicast traffic to and from that particular network segment.

Reverse Path Forwarding

RPF is a method for ensuring optimal routing of multicast traffic. Each router along the multicast path will perform a RPF check by looking up the unicast routing path towards the source address of the multicast stream. The interface which would be the outgoing interface for such unicast traffic is known as the RPF Interface, which, as mentioned, is added to the list of Incoming Interfaces.

However, if the source of the multicast stream is not known, then the RPF check will be performed towards the RP. Once the source is learned, The stream can move to a SPT flow, in stead of a Shared Tree flow.

Duplicate multicast flows

As you probably could have guessed, there can be issues when you have redundant routes between a multicast source and all of its destinations. RPF checks are a useful way to mitigate when routers have redundant IIFs for a multicast group. However, what happens if you have multiple routers on the same multi-access network (broadcast domain, ie. VLAN)?

PIM Assert Mechanism

To solve the issues with having multiple routers on the same network segment, the PIM Assert Mechanism (I will shorten it to PIMAM, even though this is not a recognized term) is used. The PIMAM is triggered if a PIM router receives the same multicast flow, that is the same source to multicast group destination flow is received on one of the routers Outgoing Interface (OIF).

Once triggered the PIMAM will send assert packets between the two routers containing their respective Administrative Distance (AD) to the source or RP of the multicast stream. The router with the lowest AD will win. If there is a tie, then the route metric is used. If there is still a tie, then the primary IP-address of the interface on the given network segment will be used as the tie breaker, with the highest IP being preferred.

The router that wins this election will then be known as the PIM forwarder. The router which lost the election will then prune its interfaces. This concept is the same for Sparse and Dense mode.

Setting a Rendezvous Point

When using PIM Sparse mode you must also set a RP. Every router in the multicast domain must be aware of which router is the RP. The simplest way of configuring this is statically setting the RP on every router (including the RP itself) using the following command:

ip pim rp-address <rp-router-address>

This can be useful for testing and smaller networks. However, for increased scalability and to be able to have the RP role failover to a different router, should the RP go down, you should use a dynamic election of the RP.

Auto-RP

This is our first option. Auto-RP is a Cisco proprietary protocol, which you should take into consideration before rolling out this solution.

Auto-RP uses two different type of components: Candidate-RP (C-RP) and RP Mapping Agents (RP MA). The C-RP routers are the ones which are eligible to be elected as the RP for that PIM domain. They will announce their candidacy to the multicast group of 224.0.1.39. By default the C-RP has the group scope of 224.0.0.0/4. However, using Auto-RP allows you to customize which router should be RP for which multicast group addresses. Therefore, you can customize the placement of your RP based on the source of the multicast stream, thus decreasing unnecessary overhead.

RP MA routers will join the group 224.0.1.39 and listen for the C-RPs. The RP MA routers then elect a candidate preferring the C-RP with the highest IP. The RP MA decisions are then announced to all PIM routers on 224.0.1.40. You should have multiple RP MA routers to provide redundancy and since they work independently from one another they can coexist without an election process of their own.

You are able to configure a C-RP and RP MA on the same router if you should choose.

Configuring the C-RP

ip pim send-rp-announce <interface> scope <ttl-hops>

Where the interface in this case would be the interface you want to announce your candidacy out of, and the scope is how many hops you want your candidacy to reach.

Configuring the RP MA

ip pim send-rp-discovery <interface> scope <ttl-hops>

Same deal as before, interface is where you want to send out the RP MA packets and ttl-hops is how far.

Bootstrap router

Bootstrap Router (BSR) is a process that is similar to that of Auto-RP, but non proprietary. It uses Candidate-BSR (C-BSR) much like Auto-RP. The BSR router receives the C-RP routers announcements and stores it, along with which groups the C-RP has in its scope. This information is then forwarded to every router in the PIM domain, where the election of the RP takes place. The election process is thus distributed out to all the PIM routers, in stead of handled by MA routers as with Auto-RP.

BSR and Auto-RP should generally not be combined, as this is not the design that the protocols where created for.

Some useful multicast routing commands

I will include a list of some useful Cisco IOS-XE commands for inspecting multicast routing:

Generating testing multicast from a Linux box can easily be done using regular old ping:

ping -t 64 224.1.1.42

In the above example I am using a TTL of 64 (default is 1 I think), and I am sending data to the multicast group of “224.1.1.42”.

Further reading and references

https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipmulti_pim/configuration/xe-16/imc-pim-xe-16-book/imc-tech-oview.html https://www.cisco.com/c/en/us/support/docs/ip/ip-multicast/212595-how-well-do-you-know-pim-assert-mechanis.html https://www.rfc-editor.org/rfc/rfc7761