Understanding Multicast-Only Fast Reroute
Multicast-only fast reroute (MoFRR) minimizes packet loss for traffic in a multicast distribution tree when link failures occur, enhancing multicast routing protocols like Protocol Independent Multicast (PIM) and multipoint Label Distribution Protocol (multipoint LDP) on devices that support these features.
On switches, MoFRR with MPLS label-switched paths and multipoint LDP is not supported.
For MX Series routers, MoFRR is supported only on MX Series
routers with MPC line cards. As a prerequisite, you must configure
the router into network-services enhanced-ip
mode, and all the
line cards in the router must be MPCs.
With MoFRR enabled, devices send join messages on primary and backup upstream paths toward a multicast source. Devices receive data packets from both the primary and backup paths, and discard the redundant packets based on priority (weights that are assigned to the primary and backup paths). When a device detects a failure on the primary path, it immediately starts accepting packets from the secondary interface (the backup path). The fast switchover greatly improves convergence times upon primary path link failures.
One application for MoFRR is streaming IPTV. IPTV streams are multicast as UDP streams, so any lost packets are not retransmitted, leading to a less-than-satisfactory user experience. MoFRR can improve the situation.
MoFRR Overview
With fast reroute on unicast streams, an upstream routing device preestablishes MPLS label-switched paths (LSPs) or precomputes an IP loop-free alternate (LFA) fast reroute backup path to handle failure of a segment in the downstream path.
In multicast routing, the receiving side usually originates the traffic distribution graphs. This is unlike unicast routing, which generally establishes the path from the source to the receiver. PIM (for IP), multipoint LDP (for MPLS), and RSVP-TE (for MPLS) are protocols that are capable of establishing multicast distribution graphs. Of these, PIM and multipoint LDP receivers initiate the distribution graph setup, so MoFRR can work with these two multicast protocols where they are supported.
In a multicast tree, if the device detects a network component failure, it takes some time to perform a reactive repair, leading to significant traffic loss while setting up an alternate path. MoFRR reduces traffic loss in a multicast distribution tree when a network component fails. With MoFRR, one of the downstream routing devices sets up an alternative path toward the source to receive a backup live stream of the same multicast traffic. When a failure happens along the primary stream, the MoFRR routing device can quickly switch to the backup stream.
With MoFRR enabled, for each (S,G) entry, the device uses two of the available upstream interfaces to send a join message and to receive multicast traffic. The protocol attempts to select two disjoint paths if two such paths are available. If disjoint paths are not available, the protocol selects two non-disjoint paths. If two non-disjoint paths are not available, only a primary path is selected with no backup. MoFRR prioritizes the disjoint backup in favor of load balancing the available paths.
MoFRR is supported for both IPv4 and IPv6 protocol families.
Figure 1 shows two paths from the multicast receiver routing device (also referred to as the egress provider edge (PE) device) to the multicast source routing device (also referred to as the ingress PE device).
With MoFRR enabled, the egress (receiver side) routing device sets up two multicast trees, a primary path and a backup path, toward the multicast source for each (S,G). In other words, the egress routing device propagates the same (S,G) join messages toward two different upstream neighbors, thus creating two multicast trees.
One of the multicast trees goes through plane 1 and the other through plane 2, as shown in Figure 1. For each (S,G), the egress routing device forwards traffic received on the primary path and drops traffic received on the backup path.
MoFRR is supported on both equal-cost multipath (ECMP) paths
and non-ECMP paths. The device needs to enable unicast loop-free alternate
(LFA) routes to support MoFRR on non-ECMP paths. You enable LFA routes
using the link-protection
statement in the interior gateway
protocol (IGP) configuration. When you enable link protection on an
OSPF or IS-IS interface, the device creates a backup LFA path to the
primary next hop for all destination routes that traverse the protected
interface.
Junos OS implements MoFRR in the IP network for IP MoFRR and at the MPLS label-edge routing device (LER) for multipoint LDP MoFRR.
Multipoint LDP MoFRR is used at the egress device of an MPLS network, where the packets are forwarded to an IP network. With multipoint LDP MoFRR, the device establishes two paths toward the upstream PE routing device for receiving two streams of MPLS packets at the LER. The device accepts one of the streams (the primary), and the other one (the backup) is dropped at the LER. IF the primary path fails, the device accepts the backup stream instead. Inband signaling support is a prerequisite for MoFRR with multipoint LDP (see Understanding Multipoint LDP Inband Signaling for Point-to-Multipoint LSPs).
PIM Functionality
Junos OS supports MoFRR for shortest-path tree (SPT) joins in
PIM source-specific multicast (SSM) and any-source multicast (ASM).
MoFRR is supported for both SSM and ASM ranges. To enable MoFRR for
(*,G) joins, include the mofrr-asm-starg
configuration statement
at the [edit routing-options multicast stream-protection]
hierarchy. For each group G, MoFRR will operate for either (S,G)
or (*,G), but not both. (S,G) always takes precedence over (*,G).
With MoFRR enabled, a PIM routing device propagates join messages on two upstream reverse-path forwarding (RPF) interfaces to receive multicast traffic on both links for the same join request. MoFRR gives preference to two paths that do not converge to the same immediate upstream routing device. PIM installs appropriate multicast routes with upstream RPF next hops with two interfaces (for the primary and backup paths).
When the primary path fails, the backup path is upgraded to primary status, and the device forwards traffic accordingly. If there are alternate paths available, MoFRR calculates a new backup path and updates or installs the appropriate multicast route.
You can enable MoFRR with PIM join load balancing (see the join-load-balance automatic
statement). However, in that case the distribution
of join messages among the links might not be even. When a new ECMP
link is added, join messages on the primary path are redistributed
and load-balanced. The join messages on the backup path might still
follow the same path and might not be evenly redistributed.
You enable MoFRR using the stream-protection
configuration
statement at the [edit routing-options multicast]
hierarchy.
MoFRR is managed by a set of filter policies.
When an egress PIM routing device receives a join message or an IGMP report, it checks for an MoFRR configuration and proceeds as follows:
If the MoFRR configuration is not present, PIM sends a join message upstream toward one upstream neighbor (for example, plane 2 in Figure 1).
If the MoFRR configuration is present, the device checks for a policy configuration.
If a policy is not present, the device checks for primary and backup paths (upstream interfaces), and proceeds as follows:
If primary and backup paths are not available—PIM sends a join message upstream toward one upstream neighbor (for example, plane 2 in Figure 1).
If primary and backup paths are available—PIM sends the join message upstream toward two of the available upstream neighbors. Junos OS sets up primary and secondary multicast paths to receive multicast traffic (for example, plane 1 in Figure 1).
If a policy is present, the device checks whether the policy allows MoFRR for this (S,G), and proceeds as follows:
If this policy check fails—PIM sends a join message upstream toward one upstream neighbor (for example, plane 2 in Figure 1).
If this policy check passes—The device checks for primary and backup paths (upstream interfaces).
If the primary and backup paths are not available, PIM sends a join message upstream toward one upstream neighbor (for example, plane 2 in Figure 1).
If the primary and backup paths are available, PIM sends the join message upstream toward two of the available upstream neighbors. The device sets up primary and secondary multicast paths to receive multicast traffic (for example, plane 1 in Figure 1).
Multipoint LDP Functionality
To avoid MPLS traffic duplication, multipoint LDP usually selects only one upstream path. (See section 2.4.1.1. Determining One's 'upstream LSR' in RFC 6388, Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths.)
For multipoint LDP with MoFRR, the multipoint LDP device selects two separate upstream peers and sends two separate labels, one to each upstream peer. The device uses the same algorithm described in RFC 6388 to select the primary upstream path. The device uses the same algorithm to select the backup upstream path but excludes the primary upstream LSR as a candidate. The two different upstream peers send two streams of MPLS traffic to the egress routing device. The device selects only one of the upstream neighbor paths as the primary path from which to accept the MPLS traffic. The other path becomes the backup path, and the device drops that traffic. When the primary upstream path fails, the device starts accepting traffic from the backup path. The multipoint LDP device selects the two upstream paths based on the interior gateway protocol (IGP) root device next hop.
A forwarding equivalency class (FEC) is a group of IP packets that are forwarded in the same manner, over the same path, and with the same forwarding treatment. Normally, the label that is put on a particular packet represents the FEC to which that packet is assigned. In MoFRR, two routes are placed into the mpls.0 table for each FEC—one route for the primary label and the other route for the backup label.
If there are parallel links toward the same immediate upstream device, the device considers both parallel links to be the primary. At any point in time, the upstream device sends traffic on only one of the multiple parallel links.
A bud node is an LSR that is an egress LSR, but also has one or more directly connected downstream LSRs. For a bud node, the traffic from the primary upstream path is forwarded to a downstream LSR. If the primary upstream path fails, the MPLS traffic from the backup upstream path is forwarded to the downstream LSR. This means that the downstream LSR next hop is added to both MPLS routes along with the egress next hop.
As with PIM, you enable MoFRR with multipoint LDP using the stream-protection
configuration statement at the [edit routing-options
multicast]
hierarchy, and it’s managed by a set of filter
policies.
If you have enabled the multipoint LDP point-to-multipoint FEC for MoFRR, the device factors the following considerations into selecting the upstream path:
The targeted LDP sessions are skipped if there is a nontargeted LDP session. If there is a single targeted LDP session, the targeted LDP session is selected, but the corresponding point-to-multipoint FEC loses the MoFRR capability because there is no interface associated with the targeted LDP session.
All interfaces that belong to the same upstream LSR are considered to be the primary path.
For any root-node route updates, the upstream path is changed based on the latest next hops from the IGP. If a better path is available, multipoint LDP attempts to switch to the better path.
Packet Forwarding
For either PIM or multipoint LDP, the device performs multicast source stream selection at the ingress interface. This preserves fabric bandwidth and maximizes forwarding performance because it:
Avoids sending out duplicate streams across the fabric
Prevents multiple route lookups (that result in packet drops).
For PIM, each IP multicast stream contains the same destination address. Regardless of the interface on which the packets arrive, the packets have the same route. The device checks the interface upon which each packet arrives and forwards only those that are from the primary interface. If the interface matches a backup stream interface, the device drops the packets. If the interface doesn’t match either the primary or backup stream interface, the device handles the packets as exceptions in the control plane.
Figure 2 shows this process with sample primary and backup interfaces for routers with PIM. Figure 3 shows this similarly for switches with PIM.
For MoFRR with multipoint LDP on routers, the device uses multiple MPLS labels to control MoFRR stream selection. Each label represents a separate route, but each references the same interface list check. The device only forwards the primary label, and drops all others. Multiple interfaces can receive packets using the same label.
Figure 4 shows this process for routers with multipoint LDP.
Limitations and Caveats
- MoFRR Limitations and Caveats on Switching and Routing Devices
- MoFRR Limitations on Switching Devices with PIM
- MoFRR Limitations and Caveats on Routing Devices with Multipoint LDP
MoFRR Limitations and Caveats on Switching and Routing Devices
MoFRR has the following limitations and caveats on routing and switching devices:
MoFRR failure detection is supported for immediate link protection of the routing device on which MoFRR is enabled and not on all the links (end-to-end) in the multicast traffic path.
MoFRR supports fast reroute on two selected disjoint paths toward the source. Two of the selected upstream neighbors cannot be on the same interface—in other words, two upstream neighbors on a LAN segment. The same is true if the upstream interface happens to be a multicast tunnel interface.
Detection of the maximum end-to-end disjoint upstream paths is not supported. The receiver side (egress) routing device only makes sure that there is a disjoint upstream device (the immediate previous hop). PIM and multipoint LDP do not support the equivalent of explicit route objects (EROs). Hence, disjoint upstream path detection is limited to control over the immediately previous hop device. Because of this limitation, the path to the upstream device of the previous hop selected as primary and backup might be shared.
You might see some traffic loss in the following scenarios:
A better upstream path becomes available on an egress device.
MoFRR is enabled or disabled on the egress device while there is an active traffic stream flowing.
PIM join load balancing for join messages for backup paths are not supported.
For a multicast group G, MoFRR is not allowed for both (S,G) and (*,G) join messages. (S,G) join messages have precedence over (*,G).
MoFRR is not supported for multicast traffic streams that use two different multicast groups. Each (S,G) combination is treated as a unique multicast traffic stream.
The bidirectional PIM range is not supported with MoFRR.
PIM dense-mode is not supported with MoFRR.
Multicast statistics for the backup traffic stream are not maintained by PIM and therefore are not available in the operational output of
show
commands.Rate monitoring is not supported.
MoFRR Limitations on Switching Devices with PIM
MoFRR with PIM has the following limitations on switching devices:
MoFRR is not supported when the upstream interface is an integrated routing and bridging (IRB) interface, which impacts other multicast features such as Internet Group Management Protocol version 3 (IGMPv3) snooping.
Packet replication and multicast lookups while forwarding multicast traffic can cause packets to recirculate through PFEs multiple times. As a result, displayed values for multicast packet counts from the
show pfe statistics traffic
command might show higher numbers than expected in output fields such asInput packets
andOutput packets
. You might notice this behavior more frequently in MoFRR scenarios because duplicate primary and backup streams increase the traffic flow in general.
MoFRR Limitations and Caveats on Routing Devices with Multipoint LDP
MoFRR has the following limitations and caveats on routers when used with multipoint LDP:
MoFRR does not apply to multipoint LDP traffic received on an RSVP tunnel because the RSVP tunnel is not associated with any interface.
Mixed upstream MoFRR is not supported. This refers to PIM multipoint LDP in-band signaling, wherein one upstream path is through multipoint LDP and the second upstream path is through PIM.
Multipoint LDP labels as inner labels are not supported.
If the source is reachable through multiple ingress (source-side) provider edge (PE) routing devices, multipoint LDP MoFRR is not supported.
Targeted LDP upstream sessions are not selected as the upstream device for MoFRR.
Multipoint LDP link protection on the backup path is not supported because there is no support for MoFRR inner labels.