PIM FRR
PIM fast reroute (FRR) is a multicast traffic protection mechanism that allows PIM-SM/PIM-SSM-capable devices to set up both primary and backup shortest path trees (SPTs) for multicast receivers. PIM FRR enables a device to switch traffic to the backup SPT within 50 ms after the primary link or a node on the primary link fails, thus minimizing multicast traffic loss.
Background
SPT setup relies on unicast routes. If a link or node failure occurs, a new SPT can be set up only after unicast routes are converged. This process is time-consuming and may cause severe multicast traffic loss.
PIM FRR resolves these issues. It allows a device to search for a backup FRR route based on unicast routing information and send the PIM Join message of a multicast receiver along both the primary and backup routes, setting both primary and backup SPTs. The cross node of the primary and backup links can receive one copy of a multicast flow from each of the links. Each device's forwarding plane permits the multicast traffic on the primary link and discards that on the backup link. However, the forwarding plane starts permitting multicast traffic on the backup link as soon as the primary link fails, thus minimizing traffic loss.
PIM FRR supports fast SPT switchovers only in IPv4 PIM-SSM or PIM-SM. In extranet scenarios, PIM FRR supports only source VPN, not receiver VPN entries.
Implementation
PIM FRR implementation involves three steps:
Setup of primary and backup SPTs for a multicast receiver
Each PIM-SM/PIM-SSM device adds the inbound interface information to the (S, G) entry of the receiver, and then searches for a backup FRR route based on unicast routing information. After a backup FRR route is discovered, each device adds the backup route's inbound interface information to the (S, G) entry so that two routes become available from the source to the multicast group requested by the receiver. Each device then sends a PIM Join message along both the primary and backup routes to set up two SPTs. Figure 4-16 shows the process of setting up two SPTs for a multicast receiver.
Fault detection and traffic protection
After the primary and backup SPTs are set up, each multicast device on the primary link receives two copies of a multicast flow. Their forwarding planes permit the multicast traffic on the primary link and discard that on the backup link. If the primary link or a node on the primary link fails, the forwarding plane starts permitting the traffic on the backup link as soon as it detects the failure. Table 4-4 describes PIM FRR implementation before and after link or node failure occurs.
Table 4-4 PIM FRR implementation before and after a link or node failure occursFailure Type
Before a Failure Occurs
After a Failure Occurs
Local primary link
In Figure 4-17, Device A permits the multicast traffic on the primary link and discards that on the backup link.
In Figure 4-18, Device A starts permitting multicast traffic on the backup link (Device B -> Device D -> Device A) as soon as the local primary link fails.
Node
In Figure 4-19, Device A permits the multicast traffic on the primary link and discards that on the backup link.
In Figure 4-20, Device A starts permitting multicast traffic on the backup link (Device C -> Device D -> Device A) as soon as Device B fails on the primary link.
Remote primary link
In Figure 4-21, Device A permits the multicast traffic on the primary link and discards that on the backup link.
In Figure 4-22, Device A starts permitting multicast traffic on the backup link (Device C -> Device D -> Device A) as soon as Device A detects the remote primary link failure.
Traffic switchback
After the link or node failure is resolved, PIM detects a route change at the protocol layer, starts route switchback, and then smoothly switches traffic back to the primary link.
PIM FRR in Scenarios Where IGP FRR Cannot Fulfill Backup Root Computation Independently
PIM FRR relies on IGP FRR to compute both primary and backup routes. However, a live network may encounter backup route computation failures on some nodes due to the increase of network nodes. Therefore, if IGP FRR cannot fulfill route computation independently on a network, deploy IP FRR to work jointly with IGP FRR. The following example uses a ring network.
On the ring network shown in Figure 4-23, Device C connects to a multicast receiver. The primarily multicast traffic link for this receiver is Device C -> Device B -> Device A. To compute a backup route for the link Device D -> Device C, IGP FRR requires that the cost of link Device D -> Device A be less than the cost of link Device C -> Device A plus the cost of link Device D -> Device C. That is, the cost of link Device D -> Device E -> Device F -> Device A must be less than the cost of link Device C -> Device A plus the cost of link Device D -> Device C. This ring network does not meet this requirement; therefore, IGP FRR cannot compute a backup route for link Device D -> Device C.
- The IGP route is Device C -> Device B -> Device A, which has a higher preference and functions as the primary link.
- The static route is Device C -> Device D -> Device E -> Device F -> Device A, which has a lower preference and functions as the backup link.
Before a link or node failure occurs, Device C permits the multicast traffic on the primary link and discards that on the backup link. After a link or node failure occurs, Device C starts permitting the multicast traffic on the backup link as soon as it detects the failure.
Benefits
PIM FRR helps improve the reliability of multicast services and minimize service loss for users.