Configuring MoFRR
Information about MoFRR
Multicast only Fast Re-Route (MoFRR) is an IP solution that minimizes packet loss in a network when there is a link or node failure. It works by making simple enhancements to multicast routing protocols like Protocol Independent Multicast (PIM). It reduces multicast traffic disruption for the receivers in the event of Node or Link failure anywhere along the Multicast Tree.
MoFRR transmits a multicast join message from a receiver toward a source on a primary path, while also transmitting a secondary multicast join message from the receiver toward the source on a backup path. Data packets are received from both the primary path and the secondary paths. The redundant packets are discarded at topology merge points due to Reverse Path Forwarding (RPF) checks. When a failure is detected on the primary path, the repair is made by changing the interface on which packets are accepted to the secondary interface. Because the repair is local, it is fast—greatly improving convergence times in the event of node or link failures on the primary path.
The MoFRR feature provides the ability to minimize packet loss in a network when there is a link or node failure by enhancing, but not changing, multicast routing protocols such as PIM. With MoFRR, multicast routing protocols do not have to wait or depend on unicast routing protocols to detect network failures.
The MoFRR feature can be divided into two planes, red and blue, that are fully disjoint from each other all the way into the points of presence (POPs) as shown in the figure.
This two-plane design eliminates single points of failure in the core network. The upstream full-line arrows indicate the normal path taken when the PIM joins the flow from the POPs toward the source of the network.
MoFRR adds the broken‐arrow path where the provider edge (PE) routers send an alternate PIM join to their neighbor toward the source. Each PE router then receives two copies of the same stream, one from the blue plane and one from the red plane. As a result of multicast RPF checks, the following occurs:
-
The multicast stream received over the primary path (in the reverse direction of the full-line arrows) is accepted and forwarded to the downstream links.
-
The copy of the stream received on the alternate path (in the reverse direction of the broken-line arrows) is discarded.
In the example above, when a routing failure occurs due to a link failure between R4 and R6 routers, R3 becomes the primary upstream router to reach the source. This link to the router then becomes the RPF interface, and a copy of the multicast stream being received on the link is accepted and forwarded to the downstream links.
When a routing failure occurs, for example due to a link failure in the blue path, the red upstream router in the red plane becomes the primary upstream router to reach the source. This link to the router then becomes the RPF interface, and the copy of the multicast stream being received on the link is accepted and forwarded to the downstream links.
MoFRR achieves faster convergence by prebuilding the alternate multicast tree and receiving the traffic on that alternate path. The example discussed above is a simple case where there are two paths from each PE device toward the source, one along the blue plane and one along the red plane.
Beginning with Release 8.2(1), Cisco Nexus 7000 Series Switches targets to achieve sub-sec convergence delay for 2K (S, G) running on F3/M3 cards, using MoFRR feature. MoFRR feature allows faster programming and improved convergence. Beginning with Cisco NX-OS Release 8.4(1), MoFRR support has been extended to F4 Series modules.
Prerequisites for MoFRR
-
Ensure IP Multicast is enabled. For more information on configuring IP Multicast, refer Cisco Nexus 7000 Series NX-OS Multicast Routing Configuration Guide.
-
Ensure that you have disjoint ECMP paths towards the source.
Guidelines and Restrictions for MoFRR
-
The MoFRR feature is disabled by default and must be enabled using the CLI.
-
MoFRR feature is supported on Cisco Nexus 7000 Series Switches, F3, F4, and M3 modules only.
-
The Equal Cost Multipath Protocol (ECMP) feature is a requirement for the MoFRR feature to function.
-
If ECMP is not configured, the two paths that are chosen from the ECMP paths are based on the RPF neighbor address.
-
MoFRR works only for Sparse Multicast (SM) S, G, and Source Specific Multicast (SSM) routes.
-
MoFRR is applicable to only IPv4 Multicast, not IPv6 Multicast.
-
MoFRR does not support extranet routes.
-
MoFRR works where the Reverse Path Forwarding (RPF) lookups are done in a single VRF.
-
Both primary and secondary paths should exist in the same multicast topology.
-
MoFRR is supported on images supporting IPv4 MFIB only.
-
We recommend that you enable MoFRR feature on the last hop router.
-
ip multicast multipath legacy MoFRR is not supported.
-
For better convergence numbers instead of using default values for MoFRR, use below BGP Optimization CLI and OSPF Aggressive Timers.
Note
Ensure that the detailed analysis is done before using the below configurations to avoid negative impact for other features enabled on the DUT.
BGP Optimization CLI : nexthop trigger-delay{critical | non-critical} milliseconds
Example:
switch(config-router-af)# nexthop trigger-delay critical 5000
Specifies next-hop address tracking delay timer for critical next-hop reachability routes and noncritical routes. The range is from 1 to 4294967295 milliseconds. The critical timer default is 3000 milliseconds and noncritical timer default value is 10000 milliseconds. As critical default value is 3000 millisecond, the resolution can delay upto 3 seconds for NH calculations.
Suggestions: Have an aggressive trigger -delay. This must be tuned as per requirement.
<nexthop trigger-delay critical 1 non-critical 1 >
OSPF Aggressive Timers: This must be tuned as per requirement. The OSPF timers can be tuned as below:
Example router ospf 100 timers throttle spf 20 50 500 timers lsa-arrival 50 timers throttle lsa 20 50 500
Configuring MoFRR
Perform the following steps to enable MoFRR:
Procedure
Step 1 |
Enter the global configuration mode. |
Step 2 |
Enable the MoFRR feature. damping-interval is specified in seconds and the value can range between 10 and 180. Use the resilient option to make MoFRR RPF resilient. This option avoids reuse of flows after an ECMP path returns after the MoFRR switchover event. Configure resilient option to make RPF resilient with ECMP path changes. If the ECMP path list changes and old RPF information is still part of the ECMP, configuring the resilient option will utilize old RPF information instead of reusing flows and potentially changing the RPF information. Use the option route-map map-name to specify the route map policy name. |
Verifying Configuring MoFRR
Perform the following steps to verify the configuration of MoFRR:
Procedure
Step 1 |
show ip mroute mofrr Example:
Displays the information that IP multicast routing uses and the MoFRR information. |
Step 2 |
show ip pim route Example:
Displays the PIM status and configuration. |
Step 3 |
show forwarding distribution multicast route group group-addr source source-addr Example:
|
Step 4 |
show forwarding multicast route group group-addr source source-addr Example:
|
Troubleshooting
The command-line interface (CLI) allows you to configure and monitor Cisco NX-OS using a local console or remotely using a Telnet or SSH session. Using the CLI, you can enable debugging modes and view a real-time updated activity log. You can use show commands to list historical and real-time information.
- You can enable debugging by running the debug ip mrouting mofrr command.
- Run the show routing multicast internal event-history mofrr command to view MoFRR data.
Feature Information for Configuring MoFRR
This table lists the release history for this feature.
Feature Name |
Releases |
Feature Description |
---|---|---|
Configuring MoFRR |
8.4(1) |
Added support for F4 series modules. |
Configuring MoFRR |
8.2(1) |
The MoFRR feature provides the ability to minimize packet loss in a network when there is a link or node failure by enhancing multicast routing protocols such as PIM. |