Multicast, Bidirectional PIM

1. Introduction

This post is about multicast state and why PIM-SM scales poorly when using a certain type of application. Bidirectional PIM is then introduced as a solution to this problem.

2. Multicast vs. Unicast State

An important difference between multicast and unicast is how the size of the control plane scales when the number of destinations in unicast and the number of groups in multicast, increase. Consider for example adding a single new entry to a unicast routing table. Each new entry would require some insignificant amount of additional memory in the RIB, and use 1 of the available entries in the FIB’s TCAM memory. Full routing protocol updates would also grow slightly larger. The important point here is that we have a fairly linear relationship between the number of routes and the size of the control plane in unicast routing.

Multicast routing with PIM-SM, the multicast routing protocol that I’ve covered up to this point, does not have this linear scaling. A router will not only maintain state for each group address, but also for each source that is sending to this destination. The source address is important because we typically want to create a multicast distribution tree directly between receiver and source (the shortest path tree switchover). For example, if we have 10 sources for a group, the last hop router will install 11 entries in the multicast RIB when a receiver is listening for that group (10 (s,g) entries and the (*,g)). Additionally, PIM will periodically want to refresh the state for all the entries by sending PIM join messages. The amount of state in the downstream portion of the network can be somewhat mitigated by not doing the SPT switchover, but the delivery from source to RP would still rely on source specific state.

Multicast on the CCNP:SP 642-885 SPADVROUTE Exam, Part 5, MSDP Basics

2.8 Describe multicast source discovery protocol (MSDP) operations
2.14 Implement MSDP operations on IOS-XR and IOS-XE

1. Multiple RPs

An issue with the RP is that senders and receivers must use the same one (at least for one group). If this is not the case you could end up in a situation where the first hop router’s register message and the (*, G) join from the last hop router are sent to different devices. Creation of a multicast tree from sender to receiver will fail in that situation because the RP on the sender side will not have (*,G) state for the group, and because of that will not send the (S,G) join to the source. Even if the (S,G) join was sent anyway, there will be no shared tree from that RP to the receiver and the multicast packets would be dropped at the RP.

The two situations where this can occur are when using an anycast RP, and when actually using different RP IP addresses, like for example in interdomain multicast. Both anycast RP and interdomain multicast will get their own posts (and it will probably be useful to already know MSDP at that point). What they have in common is that a complete end to end multicast tree cannot be built due to the previously mentioned issue of neither RP having the full information about sender and receiver.

2. MSDP Introduction

To solve this problem, we introduce a new control plane feature called Multicast Source Discovery Protocol (MSDP). Each RP becomes an MSDP peer and a TCP session is established between them using port 639. This works pretty much like BGP in the sense that the neighbor must be explicitly configured.

Multicast on the CCNP:SP 642-885 SPADVROUTE Exam, Part 4, Multicast BGP

2.6 Describe multiprotocol BGP functions in mroute distribution

This post is more or less a direct continuation of the previous one, and uses the same topology. I’ll also reference things discussed there so if you want to follow along, it’s probably a good idea to go to read that one first.

In the part 3 we discussed that PIM uses information from other protocols to do its RPF checks, the multicast loop prevention mechanism. This makes PIM more lightweight than earlier multicast protocols, such as DMVRP, that had to build a loop free topology independent of the unicast routing protocol. It does however have the side effect of having to manipulate these, external to PIM, sources of RPF information if we want to change how the multicast tree is built. One such mechanism explored in part 3 was static mroutes that we used to create a network where unicast and multicast used different paths.

Multicast BGP is to static mroutes what unicast BGP is to static unicast routes. They have the same overall goal; to create a topology for PIM to use for the RPF check, and typically override the information derived from the unicast IGP. But, MBGP allows you to do things that wouldn’t be possible using static mroutes, like use BGP policy to control the traffic flows. A big limitation of static mroutes is their undynamic nature. In the previous post, we observed that we were unable to fail over to a secondary link when our multicast link failed since the static mroute remained, but was unable to be resolved to a new interface. We drew the conclusion that a static mroute depends on the configured ip next hop being directly connected. In this post we’ll demonstrate that BGP allows us to fail over to the secondary link.

Multicast on the CCNP:SP 642-885 SPADVROUTE Exam, Part 3, RPF Failure

My exploration of the CCNP:SP blueprint continues.

2.5 Describe and illustrate how RPF check can fail if the unicast and multicast topologies are non-congruent

PIM uses the unicast routing information to ensure that there are no loops in the multicast data or control planes. It does this because PIM itself doesn’t have a loop prevention mechanism, like for example OSPF’s link state database and its shortest path calculation. This makes PIM more lightweight than it would have been if it had to calculate the topology itself, but it does mean that there’s a dependency on unicast routing.

PIM uses something called Reverse Path Forwarding (RPF) to determine if a multicast packet arrives at an appropriate interface, and if it isn’t, the packet is dropped. If a packet arrives on the same interface that would be used to route a unicast packet towards the source of that packet, it passes the RPF check. The logic behind this is that if it comes in on the same interface as you would use to unicast to the source, the packet is following the loop free topology calculated by the unicast routing protocol.

Multicast on the CCNP:SP 642-885 SPADVROUTE Exam, Part 2, PIM-SM

2.7 Describe the principles and operations of PIM-SM
2.10 Implement PIM-SM operations on IOS-XR and IOS-XE

1. Introduction

The items on the blueprint aren’t presented in a logical order so I’m jumping directly to item 2.7 and 2.10 that covers PIM Sparse Mode. Notably, this CCNP:SP exam doesn’t cover PIM DM. Probably because it’s now considered legacy and not supported on IOS-XR.

2. PIM-SM Basics

PIM Sparse Mode is a multicast routing protocol. Its purpose is to build a multicast distribution tree that allows multicast traffic to flow from a sender to a receiver. PIM-SM solves the problem of only sending traffic to receivers after they have requested it, and this in an environment where the receivers do not know the IP addresses of the senders.

With dense mode, traffic is flooded everywhere, and then pruned. Multicast packets are simply replicated and sent out all PIM-DM enabled interfaces except the incoming one. Packets can therefore reach receivers without receivers having any knowledge of the senders. Due to the scaling limitations of that approach, in sparse mode flooding doesn’t occur and an “explicit join” has to be performed before traffic can reach a receiver. The explicit join process creates the multicast distribution trees and is the key element of PIM-SM.