Layer 3 Multicast and Troubleshooting

PIM-SM - Rendezvous Point Tree

A Rendezvous Point Tree (RPT) is the path between a Rendezvous Point (RP) and the receivers in a multicast group. The RPT results from multicast routers joining the RP by sending PIM Join messages upstream to reach the RP of the topology. The RPT is also known as a shared distribution tree. Each multicast group may have different sources and receivers, so we may have multiple RPTs on the network. Here's how an RPT is built: 

Note: Multicast in each L2 domain functions as described in the "L2 Multicast" section above, relying on IGMP. 

1. In response to an IGMP Join from the receiver, a multicast router (receiver-side DR) generates and sends a PIM Join toward the RP. 

2. Similarly, when multicast traffic reaches the upstream multicast router (source-side DR), it would encapsulate part of the multicast stream from the source in a PIM Register message and unicast it to the RP.

3. When the RP sees a Join (IGMP Membership Report or PIM Join) from an interested receiver, it will allow the multicast traffic from the sender to the receiver.

   1. Note that the RP allows multicast traffic from the source to the receiver by sending a PIM Join to the source. This PIM Join allows the source-side DR to send multicast traffic without encapsulating the stream. 

   2. During this, the RP also sends a PIM Register-Stop to stop the PIM Registers from the source-side DR. 

4. If the RP has not seen a Join, it will reject the PIM Register message with a PIM Register-stop and temporarily suppress the source switch/router from trying to send the multicast traffic to the RP. 

RP 192.168.10.2 is sending a PIM Register-stop

Note: PIM relies on the unicast routing table when determining where to send the PIM Joins/Prunes and Registers/Register-stops.

                                        Rendezvous Point Tree (RPT)

 

Switch 1 (RP) does not have a Join for group 239.1.1.1 and, as such, sends a PIM Register-stop to Switch 2

PIM-SM - Shortest Path Tree

1. Once multicast traffic begins flowing through the Rendezvous Point Tree (or RPT), the receiver-side DR learns the source IP of the multicast stream. At this point, the receiver-side DR performs a lookup of the source IP in the unicast routing table to determine if a shorter path exists. If a shorter path exists between the sender and receiver, the receiver-side DR will send PIM Joins towards the source. 

2. The multicast stream can now flow between sender and receiver without passing through the RP (Shortest Path Tree or SPT). 

3. Since the receiver-side DR is now receiving multicast traffic through the SPT, it doesn’t need it from the RPT anymore. It will send PIM Prune messages to the RP, informing any routers in between that they can stop forwarding multicast traffic for this group.

                                        Shortest Path Tree (SPT)

PIM-SM - Reverse Path Forwarding

Reverse Path Forwarding (RPF) prevents multicast loops. Unlike unicast, routing in multicast depends on where the source is. PIM uses the unicast routing table to check what interface will be used to reach the source. If the multicast stream ingresses on a different interface than expected, PIM drops the stream.

PIM-SM - Expected Traffic Flow

As discussed above, multicast routing sends multicast traffic across L3 boundaries, and PIM relies heavily on IGMP. Multicast routers work with the device acting as the Rendezvous Point (RP) to route multicast traffic between different broadcast domains. The RP's role becomes essential when dealing with multiple L3 segments between the source and the receiver. When a single PIM router is present, it's essentially multicast routing on a stick where the RP points to itself.

A high-level overview of the expected traffic flow:

1. Multicast Routing is enabled, and PIM routers form neighbor adjacencies. 

2. The server streams traffic to a specified multicast address.

3. The source-side DR will encapsulate part of the stream into a PIM-Register and forward it to the Rendezvous Point (RP). 

   • If no clients are attempting to access the stream, the RP will respond with a PIM Register-stop, temporarily suppressing the source-side DR from sending the multicast traffic to the RP.

4. When a client attempts to access the stream, it will send an IGMP Membership Report, which the receiver-side DR receives, converts into a PIM Join, and forwards to the RP.

5. The RP will now allow the multicast traffic from the sender to the receiver. At this point, the multicast stream must flow through the RP (RPT).

6. If a shorter path exists between the sender and receiver, the receiver-side DR will send PIM Joins towards the source. The multicast stream can now flow between sender and receiver without passing through the RP (SPT).

 

The following topology will be used for our example:

Step 1:

Once Multicast Routing has been enabled on an SVI, PIM Hellos will be sent to the multicast address 224.0.0.13. This is to discover and form adjacencies with PIM Neighbors. 

You can find the current PIM Neighbors by selecting the switch in question under Switch > Monitor > Switches and running Multicast Routing under the Tools tab.

Step 2:

The server initiates the stream to the multicast address of 239.1.1.70:

Step 3:

The source-side DR switch encapsulates part of the stream into a PIM-Register and forwards it to the RP. While the Destination IP is 239.1.1.70, the Destination MAC will be the MAC of the RP, or the next-hop MAC until it reaches the RP:

At first, no client attempted to access the stream, so the RP responded with a PIM Register-Stop. Expanding the PIM Options, the example source (192.168.50.2) and group (239.1.1.70) addresses can be seen:

Step 4:

A client attempts to access the stream by sending an IGMP Membership Report for 239.1.1.70. 

A PIM Join is generated and sent to the RP. This is evident by the IP of our RP (192.168.10.2) as shown below: 

Step 5:

Upon receipt of the PIM Join, the RP will now forward the multicast traffic down towards the client requesting the stream.

PIM-SM - PIM Prune Override

On point-to-point links, there is only one other multicast router on the other end, so when the RP receives a prune message, it’s safe to stop forwarding the traffic. However, the RP may have more than one downstream multicast router interested in receiving the multicast traffic on multi-access links. When the RP receives a prune on a multi-access link, it must ensure no other multicast router still wants to receive the multicast stream. The RP does this with the PIM Prune Override mechanism.

When the RP receives a PIM Prune, it sets a 3-second timer on the interface before pruning, and due to the nature of a multi-access network, another multicast router using the multicast group traffic will also receive the prune message. This multicast router will send a Prune Override (Join) to the RP, causing the RP not to prune its interface. 

PIM-SM - Neighbor Discovery and DR Election

In a PIM domain, each multicast router periodically sends multicast PIM Hello messages to all other multicast routers (destination address 224.0.0.13) on the local subnet(s) for which they are routing multicast. By exchanging Hello messages, all PIM routers on the subnet determine their PIM neighbors.

PIM router is sending a PIM Hello

PIM-SM requires a designated router (DR) on the source- and receiver-side networks. A source-side DR acts on behalf of the multicast source to send Register messages to the RP. The receiver-side DR acts on behalf of the multicast receivers to send Join messages to the RP.

Source DR 192.168.50.2 is sending a PIM Register 

Receiver DR 192.168.20.2 is sending a PIM Join 

The DR election process is as follows:

• The multicast routers send Hello messages to one another, which contain the DR priority for DR election. The multicast router with the highest DR priority becomes the DR.

• If the multicast routers have the same DR election priority, the multicast router with the highest IP address wins the DR election. 

If the DR fails, the other routers will initiate the election of a new DR.

Multicast Router Discovery (MRD) 

MRD is a protocol defined in RFC 4286. 

To build the necessary PIM database, any SVI running PIM-SM must receive every IGMP packet and all multicast data streams inside the VLAN. Usually, a switch only forwards IGMP report packets out to the ports where IGMP queries are received, and data streams are similarly only sent out to ports with known receivers or ports where IGMP queries are received. Due to the IGMP Querier election, only one querier will be active per VLAN. So, if a VLAN has several PIM-enabled SVIs, only one will regularly transmit IGMP queries. The others will then fail to receive all IGMP packets and multicast data streams.

MRD solves this problem. PIM-enabled SVIs will also transmit regular MRD advertisement packets sent to 224.0.0.106. The reception port of MRD advertisement packets is also used to send all IGMP reports and data streams out, which solves the problem. 

RPF (Reverse Path Forwarding) Check 

Reverse Path Forwarding is a loop-prevention mechanism that validates the source of a multicast stream. If the source of the stream ingresses on a different interface than expected, the stream will be dropped. This is typically introduced by a missing or misconfigured route to access the source of the stream. 

Let's revisit our example topology but with an additional link added between the Client and Server switch (192.168.60.0/30). A static route has been configured on the Client switch so that the Sender (192.168.50.2) is reachable via this new link. 

The Client switch will receive the multicast stream via the Client Transit (192.168.20.0/30) link, as this is where the PIM Neighbor Adjacency is formed. Upon receipt, the Client switch will check its unicast route table and see that the 192.168.50.0/24 subnet is reachable via the newly established link (192.168.60.0/30) instead. Because the path that the stream ingresses is different from the path that the Client switch would use to access the source of the stream, the RPF Check fails, and the stream is dropped. 

There are two options available to resolve this:

1. Adjust the static route on the Client switch so that the server subnet (192.168.50.0/24) is reachable via the Client Transit link (192.168.20.0/30)
2. Enable Multicast Routing on the newly established link (192.168.60.0/30), and make sure that the Client and Server switch point to each other as the next hop to reach each other's subnets.

TTL (Time-To-Live) 

The TTL has been put in place to help reduce the impact of routing loops. The TTL value of a packet will decrease with every hop until it reaches a value of "0," in which it's then discarded. The TTL must be set to a value high enough to accommodate the number of hops between the multicast sender and receiver. 

Some applications use a default TTL of "1" that will need to be adjusted, as a value of "1" indicates that the packet isn't routable. If there are issues with the application, the stream may also be sent with an incorrect value.  

You can find the TTL by selecting any packet of the multicast stream and expanding its "IPv4" section. Below, we can see the TTL of the stream was set to "100:"