The PIM protocol is a set of protocols for transmitting multicast in networks between routers. Neighbor relationships are established similarly to dynamic routing protocols. PIMv2 sends Hello messages every 30 seconds to the reserved multicast address 224.0.0.13 (All-PIM-Routers). The message contains Hold Timers, which are typically equal to 3.5 * Hello Timer, or 105 seconds by default.
PIM uses two main operating modes — Dense and Sparse mode. Let's start with Dense mode.
Source-Based Distribution Trees.
Dense mode is advisable to use when there are a large number of clients from various multicast groups. When a router receives multicast traffic, the first thing it does is check it against the RPF rule. RPF is a rule used to verify the source of the multicast against the unicast routing table. The traffic must arrive on the interface behind which the host is hidden according to the unicast routing table. This mechanism solves the problem of loops occurring during multicast transmission.
R3 learns the source of the multicast (Source IP) from the multicast message and checks two streams from R1 and R2 against its unicast table. The stream from the interface indicated by the table (R1 to R3) will be forwarded, while the stream from R2 will be dropped, as packets need to be sent via S0/1 to reach the multicast source.
What happens if you have two equivalent routes with the same metric? In this case, the router will choose based on the next-hop of these routes. The one with the higher IP address wins. If you need to change this behavior, you can use ECMP. Learn more. .
After checking the RPF rule, the router sends the multicast packet to all its PIM neighbors, except for the one from whom the packet was received. The other PIM routers repeat this process. The path that the multicast packet takes from the source to the final recipients forms a tree called a source-based distribution tree, shortest-path tree (SPT), or source tree. Three different names, choose any.
How to deal with situations where some routers don't want a particular multicast stream and have no one to send it to, yet an upstream router sends it to them? The Prune mechanism was invented for this.
Prune Message.
For instance, R2 will continue sending multicast to R3, even though R3 drops it according to the RPF rule. Why overload the channel? R3 sends a PIM Prune Message, and upon receiving this message, R2 will remove the S0/1 interface from the outgoing interface list for that stream, which is the list of interfaces from where this traffic should be sent.
The following is a more formal definition of a PIM Prune message:
The PIM Prune message is sent by one router to a second router to cause the second router to remove the link on which the Prune is received from a particular (S,G) SPT.
After receiving the Prune message, R2 sets the Prune timer to 3 minutes. After three minutes, it will start sending traffic again, unless it receives another Prune message. This is in PIMv1.
In PIMv2, a State Refresh timer is added (default 60 seconds). As soon as a Prune message is sent from R3, this timer starts on R3. Upon the timer expiring, R3 will send a State Refresh message, which will reset the 3-minute Prune Timer on R2 for that group.
Reasons for sending a Prune message:
- When a multicast packet has failed the RPF check.
- When there are no locally connected clients that have requested the multicast group (IGMP Join), and there are no PIM neighbors to which multicast traffic can be sent (Non-prune Interface).
Graft Message.
Imagine that R3 did not want traffic from R2, sent a Prune, and was receiving multicast from R1. But suddenly, the link between R1 and R3 goes down, and R3 is left without multicast. Waiting for 3 minutes until R2's Prune Timer expires is too long; to avoid waiting, it is necessary to send a message that will immediately bring the S0/1 interface on R2 out of the pruned state. This message will be the Graft message. After receiving the Graft message, R2 will respond with a Graft-ACK.
Prune Override.
Let's look at this diagram. R1 is broadcasting multicast in a segment with two routers. R3 receives and broadcasts traffic, R2 receives but has no one to broadcast to. It sends a Prune message to R1 in this segment. R1 must remove Fa0/0 from the list and stop broadcasting to this segment, but what will happen to R3? R3 is in the same segment, also received this Prune message, and understands the gravity of the situation. Before R1 stops broadcasting, it sets a timer for 3 seconds and will stop broadcasting in 3 seconds. R3 has exactly 3 seconds to avoid losing its multicast. Therefore, R3 quickly sends a Pim Join message for this group, and R1 no longer thinks about stopping broadcasting. More on Join messages below.
Assert Message.
Imagine a situation where two routers simultaneously broadcast to one network. They receive the same stream from the source and both broadcast it to one network through interface e0. Therefore, they need to determine who will be the sole broadcaster for this network. Assert messages are used for this purpose. When R2 and R3 detect duplication of multicast traffic, meaning both routers received the multicast they themselves are broadcasting, they realize something is wrong. In this case, the routers send Assert messages that include Administrative Distance and the route metric used to reach the multicast source — 10.1.1.10. The winner is determined as follows:
- The one with the lower AD.
- If the ADs are equal, then the one with the lower metric.
- If there's still a tie, the one with the higher IP address in the network to which they are broadcasting this multicast.
The router that wins this voting becomes the Designated Router (DR). Pim Hello messages are also used to select the DR. At the beginning of the article, a PIM Hello message was shown, where the DR field can be noticed. The one with the higher IP address on this link wins.
Useful table:
MROUTE Table.
After initially reviewing the PIM protocol operation, we need to understand how to work with the multicast routing table. The mroute table stores information about which streams have been requested by clients and which streams are flowing from multicast servers.
For example, upon receiving an IGMP Membership Report or PIM Join on some interface, a record of type ( *, G ) is added to the routing table:
This entry means that a request for traffic has been received from the address 238.38.38.38. The DC flag indicates that multicast will operate in Dense mode, and C means that the recipient is directly connected to the router, meaning the router has received the IGMP Membership Report and the PIM Join.
If there is an (S,G) entry, it means that we have a multicast stream:
In the field S — 192.168.1.11, we have the IP address of the multicast source, which will be checked by the RPF rule. In case of problems, the first thing to check is the unicast table for a route to the source. The Incoming Interface field indicates the interface through which the multicast arrives. In the unicast routing table, the route to the source should point to the interface specified here. The Outgoing Interface indicates where the multicast will be redirected. If it is empty, it means that there were no requests for this traffic sent to the router. More detailed information about all the flags can be found .
PIM Sparse-mode.
The Sparse-mode strategy is the opposite of Dense-mode. When Sparse-mode receives multicast traffic, it will send traffic only through those interfaces where there have been requests for this stream, such as Pim Join or IGMP Report messages requesting this traffic.
Similar elements in SM and DM:
- Neighbor relationships are established the same way as in PIM DM.
- The RPF rule is in effect.
- The selection of DR is similar.
- The Prune Overrides mechanism and Assert messages are analogous.
To control who needs what multicast traffic and where in the network, a common information center is required. This center will be the Rendezvous Point (RP). Anyone who wants any multicast traffic or who has started receiving multicast traffic from the source sends it to the RP.
When the RP receives multicast traffic, it will send it to those routers that previously requested this traffic.
Let's imagine a topology where the RP is R3. Once R1 receives traffic from S1, it will encapsulate this multicast packet in a unicast PIM Register message and send it to the RP. How does it know who the RP is? In this case, it is statically configured, and we will talk about dynamic RP configuration later.
ip pim rp-address 3.3.3.3
The RP will check if there was any information from someone who wanted to receive this traffic. Let's assume there wasn't. Then, the RP will send R1 a PIM Register-Stop message, meaning that no one needs this multicast, and registration is denied. R1 will not send the multicast. However, the multicast source host will continue to send it, so after receiving the Register-Stop, R1 will start the Register-Suppression timer, set to 60 seconds. Five seconds before this timer expires, R1 will send an empty Register message with the Null-Register bit (i.e., without the encapsulated multicast packet) toward the RP. In turn, the RP will act as follows:
- If there were no recipients, it will respond with a Register-Stop message.
- If recipients appear, it will not respond to it at all. Not receiving a denial to its registration within 5 seconds, R1 will be happy and send a Register message with the encapsulated multicast to the RP.
Having established how the multicast reaches the RP, let's now address how the RP delivers the traffic to the recipients. Here, we need to introduce a new concept — root-path tree (RPT). The RPT is a tree with its root at the RP, growing toward the recipients, branching at each PIM-SM router. The RP creates it by receiving PIM Join messages and adds a new branch to the tree. Each downstream router does the same. The general rule is as follows:
- When a PIM-SM router receives a PIM Join message on any interface other than the interface behind which the RP is hidden, it adds a new branch to the tree.
- A branch is also added when a PIM-SM router receives an IGMP Membership Report from a directly connected host.
Imagine we have a multicast client on router R5 for group 228.8.8.8. As soon as R5 receives an IGMP Membership Report from the host, R5 sends a PIM Join toward the RP and adds the interface facing the host to the tree. Next, R4 receives the PIM Join from R5, adds interface Gi0/1 to the tree, and sends the PIM Join toward the RP. Finally, the RP (R3) receives the PIM Join and adds Gi0/0 to the tree. Thus, we have a registration for the multicast recipient. A tree is constructed with root R3-Gi0/0 → R4-Gi0/1 → R5-Gi0/0.
After this, a PIM Join will be sent to R1, and R1 will start sending multicast traffic. It is important to note that if the host requests traffic before the multicast broadcasting starts, the RP will not send a PIM Join and will not send anything to R1 at all.
If, while the multicast is being sent, the host stops wanting to receive it, as soon as the RP receives a PIM Prune on the Gi0/0 interface, it will immediately send a PIM Register-Stop directly to R1, and then a PIM Prune message through the Gi0/1 interface. The PIM Register-Stop is sent unicasted to the address from which the PIM Register was received.
As we mentioned earlier, as soon as the router sends a PIM Join to another, for example R5 to R4, an entry is added on R4:
And a timer starts, which the R5 must continually reset by sending PIM Join messages, otherwise R4 will exclude it from the outgoing list. R5 will send PIM Join messages every 60 seconds.
Shortest-Path Tree Switchover.
We will add an interface between R1 and R5 and see how the traffic flows with this topology.
Let's assume that traffic was sent and received using the old scheme R1-R2-R3-R4-R5, and now we have connected and configured an interface between R1 and R5.
First, our unicast routing table on R5 will be rebuilt, and now the network 192.168.1.0/24 is reachable through the R5 Gi0/2 interface. Now R5, receiving multicast on the Gi0/1 interface, understands that the RPF rule is not satisfied and it would be more logical to receive multicast on Gi0/2. It must disconnect from the RPT and build a shorter tree called the Shortest-Path Tree (SPT). For this, it sends a PIM Join to R1 through Gi0/2, and R1 starts sending multicast also through Gi0/2. Now R5 needs to unsubscribe from RPT to avoid receiving two copies. To do this, it sends a Prune message specifying the source IP address and inserting a special bit — the RPT-bit. This means that it does not need traffic sent to it, as it has a better tree. The RP also sends PIM Prune messages towards R1, but does not send a Register-Stop message. Another feature: R5 will now constantly send PIM Prunes to the RP since R1 continues to send PIM Registers to the RP every minute. The RP will respond with refusals until there are new requests for this traffic. R5 notifies the RP that it continues to receive multicast through the SPT.
Dynamic RP Discovery.
Auto-RP.
This technology is proprietary to Cisco and is not widely popular, but it is still in use. The operation of Auto-RP consists of two main stages:
1) RP sends RP-Announce messages to the reserved address — 224.0.1.39, announcing itself as the RP either for all or for specific groups. This message is sent every minute.
2) A necessary RP mapping agent sends RP-Discovery messages indicating which RP should be listened to for which groups. It is from this message that regular PIM routers will identify the RP for themselves. The Mapping Agent can be either the RP router itself or a separate PIM router. RP-Discovery is sent to address 224.0.1.40 with a one-minute timer.
Let's take a closer look at the process:
We will configure R3 as the RP:
ip pim send-rp-announce loopback 0 scope 10
R2 as the mapping agent:
ip pim send-rp-discovery loopback 0 scope 10
And on all others, we will wait for RP through Auto-RP:
ip pim autorp listener
Once we configure R3, it will start sending RP-Announce:
And R2, after being configured as the mapping agent, will start waiting for the RP-Announce messages. Only when it finds at least one RP will it begin sending RP-Discovery:
Thus, as soon as regular routers (PIM RP Listener) receive this message, they will know where to look for the RP.
One of the main problems with Auto-RP is that to receive RP-Announce and RP-Discovery messages, it is necessary to send PIM Join to the addresses 224.0.1.39-40, and to send, the RP's location must be known. This is the classic chicken and egg problem. To resolve this issue, the PIM Sparse-Dense Mode was invented. If the router does not know the RP, it operates in Dense-mode; if it does know, it operates in Sparse-mode. When PIM Sparse-mode and the command ip pim autorp listener are configured on the interfaces of regular routers, the router will operate in Dense-mode only for the multicast directly related to the Auto-RP protocol (224.0.1.39-40).
BootStrap Router (BSR).
This function operates similarly to Auto-RP. Each RP sends a message to the mapping agent, which collects mapping information and then informs all other routers. We will describe the process similarly to Auto-RP:
1) Once we configure R3 as a candidate to be the RP, using the command:
ip pim rp-candidate loopback 0
R3 will not do anything; to start sending special messages, it first needs to find the mapping agent. Therefore, we move to the second step.
2) We configure R2 as the mapping agent:
ip pim bsr-candidate loopback 0
R2 begins sending PIM Bootstrap messages, designating itself as the mapping agent.
This message is sent to the address 224.0.0.13, which the PIM protocol uses for its other messages as well. It sends them in all directions, so there's no chicken-and-egg issue as in Auto-RP.
3) As soon as the RP receives a message from the BSR router, it immediately sends a unicast message to the BSR router's address.
After that, BSR, having received information about the RP, will multicast it to the address 224.0.0.13, which is listened to by all PIM routers. Therefore, there is no equivalent command ip pim autorp listener for regular routers in BSR.
Anycast RP with Multicast Source Discovery Protocol (MSDP).
Auto-RP and BSR allow us to distribute the load on the RP as follows: Each multicast group has only one active RP. It's not possible to distribute the load for a single multicast group across multiple RPs. MSDP does this by providing the RPs with the same IP address with a mask of 255.255.255.255. MSDP learns information using one of the methods: static, Auto-RP, or BSR.
In the diagram, we have an Auto-RP configuration with MSDP. Both RPs are configured with the IP address 172.16.1.1/32 on the Loopback 1 interface and are used for all groups. During RP-Announce, both routers inform about themselves, referencing this address. The Auto-RP mapping agent, upon receiving this information, broadcasts RP-Discovery about the RP with the address 172.16.1.1/32. For the network 172.16.1.1/32, we inform the routers using IGP, and so on. Thus, PIM routers query or register streams from the RP specified as the next-hop in the route to the network 172.16.1.1/32. The MSDP protocol itself is designed for the RPs to exchange messages about multicast information.
Let's consider the following topology:
Switch6 broadcasts traffic to the address 238.38.38.38, and only RP-R1 knows about it so far. Switch7 and Switch8 have requested this group. Routers R5 and R4 will send PIM Join to R1 and R3, respectively. Why? The route to 13.13.13.13 for R5 will point to R1 based on IGP metric, just like R4.
RP-R1 knows about the stream and will start broadcasting it towards R5, while R4 knows nothing about it since R1 won't send it without a request. Hence, MSDP is necessary. We configure it on R1 and R5:
ip msdp peer 3.3.3.3 connect-source Loopback1 on R1
ip msdp peer 1.1.1.1 connect-source Loopback3 on R3
They will establish a session between each other and upon receiving any stream will inform their RP neighbor about it.
As soon as RP-R1 receives a stream from Switch6, it will immediately send a unicast MSDP Source-Active message containing information such as (S, G) — information about the source and destination of the multicast. Now, when RP-R3 is aware that there is a source like Switch6, upon receiving a request from R4 for that stream, it will send a PIM Join towards Switch6, guided by the routing table. Consequently, R1 receiving such a PIM Join will start sending traffic towards RP-R3.
MSDP operates over TCP, with RPs sending keepalive messages to each other for viability checks. The timer is set to 60 seconds.
The function of separating MSDP peers into different domains remains unclear, as the Keepalive and SA messages do not specify belonging to any domain. Additionally, in this topology, a configuration specifying different domains was tested — there was no difference in operation.
If anyone can provide clarity, I would be happy to read it in the comments.
Source: habr.com
