Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

How to Configure Microloop Avoidance in OSPFv2 Segment Routing Networks

SUMMARY Microloops can consume the available bandwidth of the links, which impacts the efficient transmission of useful packets. Microloop avoidance can prevent forwarding of looping packets.

Understanding OSPF Microloop Avoidance

Benefits of Avoiding Microloops in OSPFv2 Networks with Segment Routing

  • Micro loop-free path avoids delays and traffic loss.

  • Microloop avoidance can prevent forwarding of looping packets and avoid wasteful bandwidth consumption.
  • Microloop avoidance path is computed only for the impacted links in case of multiple link failures. If the second link failure does not impact the computed microloop avoidance path, OSPFv2 continues to use the same microloop avoidance path.

Junos OS enables a device to defer OSPFv2 route download when an OSPFv2 link fails in order to avoid micro loops. When local links go down, the OSPFv2 protocol floods an entire area with the database. If the node connected to the local interface that has failed converges faster than the neighboring node, then the connected node redirects traffic to the converged path. This redirection can result in micro looping of traffic until the neighboring node converges. When the primary path of a protected node fails, the connected node does not need to converge quickly if the configured backup path is not impacted. In this case, traffic flow towards a converged path is deferred until the configured delay time. This time delay helps in avoiding microloops because all routers do not arrive at the post-convergence forwarding states simultaneously.

Figure 1: Microloop Avoidance in OSPFv2 NetworksMicroloop Avoidance in OSPFv2 Networks

In the Figure 1, the primary path from Source to Destination is SR0R1R2R3D. When the link between R2 and R3 fails, traffic sent from S to D, is subject to transient forwarding loops while routers update their forwarding state for destination D.

• If R0 updates its forwarding state before R5, packets loop between R0 and R5

• If both R0 and R5, have updated their forwarding states, and R4 has not, packets loop between R4 and R5.

• R0 detects the link failure between R2 and R3, and temporarily steers traffic destined to Destination over SR path [NodeSID(R4), AdjSID(R4->R3), D].

• When the configured timeout elapses, R0 just uses the node-SID to D to reach the destination.

Microloop Avoidance in OSPFv2 Networks with Segment Routing

Starting in Junos OS Release 22.1R1, you can enable a post convergence path calculation on a device to avoid microloops if a link or metric change occurs in an OSPFv2 segment routed network. To configure microloop avoidance in an OSPFv2 segment routing network for both local and remote network events including link down, link-up, and metric-change, include the maximum-labelsdelay milliseconds statement at the [edit protocols ospf spf-options microloop avoidance post-convergence-path] hierarchy level. For effective microloop avoidance, configure this feature on all the nodes in the network.

Note:

Micro-loop avoidance is not a replacement for local repair mechanisms like TI-LFA which detects local failure very fast and activates a pre-computed loop-free-alternative path.

Routers that implement micro-loop avoidance compute the micro-loop avoiding path only after receiving the link state update for the event. So, micro-loop avoidance mechanism is not a replacement for local repair mechanisms like TI-LFA which detects local failure very fast and activates a pre-computed loop-free-alternative path at PFE level. In the above example, if local repair mechanism is not present for the R2R3 failure, there will be a lot of traffic loss before R0 can detect the failure (through global convergence) and program a micro-loop avoiding path. Micro-loop avoidance cannot avoid traffic loss due to delayed detection of the failure. Microloop avoidance avoids traffic loss due to micro-loops only. Both local-repair mechanisms like TI-LFA and micro-loop avoidance, have to be enabled on all the nodes in the network to ensure that traffic loss is in milli-seconds range.

To avoid micro-loops, the following process is used:

1. After computing the new path to D, for a predetermined time, R installs an entry for D that steers packets to D through a loop-free segment routed path. This time should be greater than worst case delay of any router in the network.

2. After the configured time delay, R installs the post-convergence route entry for D, which is without any SIDs.

Supported and Unsupported Features

Junos OS supports microloop avoidance in the following scenarios:

  • Microloop avoidance is supported on all the Junos OS platforms that support OSPF routing protocol.

  • Microloop avoidance is supported for IPv4 networks only.

  • Microloop avoidance is supported for flexible algorithm topologies.

Junos OS does not support the following features in conjunction with microloop avoidance:

  • Microloop avoidance path that needs more than 8 labels is not supported. The maximum number of labels installed for microloop avoidance path is 8. For the microloop avoidance ECMP path to be usable, the number of labels must be less than or equal to maximum labels.
  • Cannot prevent traffic loss because of slow control plane convergence.
  • OSPFv2 multi-topology is not supported with microloop avoidance.
  • Adjacency SIDs are not supported with microloop avoidance.
  • If shortcuts are available OSPFv2 does not provide a microloop avoidance path.

Configuring Segment Routing Microloop Avoidance in OSPFv2 Networks

Overview

Microloops are packet forwarding loops that occur in the network following network change events such as link down, link up, or metric change. When a network change event occurs, different routers update their forwarding states at different times. This can lead to packets getting looped between upstream and downstream routers for a transient period, resulting in packet loss, jitter, and out-of-order packets. Microloops can consume the available bandwidth of the links, which impacts the efficient transmission of useful packets.

Microloop avoidance can prevent forwarding of looping packets. The segment routing microloop avoidance detects if microloops are possible following a topology change. When a network change event is detected, the routes are programmed to take the post-convergence path, that uses a combination of node and adjacency SIDs. This ensures the routers that might not yet have converged do not loop the packets causing microloops. This behavior lasts for a configurable delay. Once the delay timer expires, routes are programmed normally by using node-SID of the destinations.

Requirements

This example uses the following hardware and software components:

  • Eight MX Series routers.

  • Junos OS Release 22.1R1 or later.

Topology

In Figure 2 device R0 and device R7 are the ingress and egress routers that support devices CE1 and CE2. The devices R1, R2, R3, R4, R5, and R6 comprise an IPv4 only provider core network. All the devices belong to the same autonomous system. OSPFv2 is the interior gateway protocol in the core configured to support microloop avoidance. In this example the device R2 is configured as an IPv4 route reflector with IBGP peering sessions to both R0 and R7. No other routers speak BGP in this example. The Device R6 has the firewall filter configured to detect packets with microloops if any following a link down event.

Figure 2: Microloop Avoidance TopologyMicroloop Avoidance Topology

Configuration

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level.

Device R0

Device R1

Device R2

Device R3

Device R4

Device R5

Device R6

Device R7

Configuring Device R0

Step-by-Step Procedure

To configure segment routing microloop avoidance path in an OSPFv2 network, perform the following steps on the R0 device:

  1. Configure the device interfaces to enable IP and MPLS transport.

  2. Configure the loopback interface (lo0) addresses that is used as router ID for OSPF sessions.

  3. Configure the router ID and autonomous system (AS) number to propagate routing information within a set of routing devices that belong to the same AS.

  4. Define a policy to load balance packets and apply the per-packet policy to enable load balancing of traffic.

  5. Configure R0 to advertise the loopback address. The prefix-segment index option sets the base label for each router's loopback. In this example the base index is set to reflect| the router number. As a result, R0 uses 1000.

  6. Configure MPLS on all interfaces excluding the management interface. Also enable traffic engineering.

  7. Configure the MPLS label range to assign static labels for the links.

  8. Configure BGP peering between R0 and the route reflector R2. Configure the unicast network layer reachability information (NRLI) to allocate a unique label for each prefix on the devices.

  9. Configure TI-LFA to enable protection against link and node failures. SR using TI-LFA provides faster restoration of network connectivity by routing the traffic instantly to a backup or an alternate path if the primary path fails or becomes unavailable.

  10. Configure backup shortest path first (SPF) attributes such as maximum equal-cost multipath (ECMP) as 8 and maximum number of labels as 5 for TI-LFA for the OSPFv2 protocol.

  11. Configure prefix segment attributes, the start label and the index range for segment routing global blocks (SRGBs) in SPRING for the OSPFv2 protocol.

  12. Configure the loopback interface as passive to ensure the protocols do not run over the loopback interface and that the loopback interface is advertised correctly throughout the network.

  13. Configure OSPF area 0 on the point-to-point interface of the device R0.

  14. Configure the computation and installation of a backup path that follows the post-convergence path on the given area and interface for the OSPFv2 protocol. Also enable node-link protection on the these interfaces that follow post-convergence path.

  15. Configure microloop avoidance that temporarily installs a post-convergence path for routes potentially affected by microloops and specify a delay time period of 60000 milliseconds for the OSPFv2 protocol. The temporary path reverts to the node SIDs of the destination after the delay timer expires.

Results

Check the results of the configuration:

Verification

Confirm that the configuration is working properly.

The following section explains microloop avoidance for a link down event.

Verify Connectivity Between R0 and R7 Before the Link is Disabled Between R0 and R1

Purpose

Verify that the Device R0 can reach the destinations on Device R7.

Action

From operational mode, run the ping command on the device R0.

Meaning

These results confirm that the device R0 can reach device R7 in the OSPFv2 network.

Verify Disabling the Link Between R0 and R1

Purpose

To verify disabling the link between R0 and R1 on the device R0

Action

From configuration mode, run the disable interface command on the device R0

To verify the link is disabled, from operational mode, run the show interfaces command on the device R0

Meaning

The output indicates the physical link between R0 and R1 is disabled and is administratively down.

Verify Microloop-avoidance Path Installed for the Destination After the Link is Disabled

Purpose

Verify microloop-avoidance path installed for the destination routes R7 from R0 when the link is disabled between R0 and R1 by verifying routes in the inet.3 table and route label details in the mpls.0 table.

Action

From operational mode, run the show route table inet.3 command on the device R0.

From operational mode, run the show route label label value protocol ospf extensive command on the device R0.

Meaning

The output indicates that when the link between R0 and R1 goes down, the microloop-avoidance path is installed for R7 from R0 through R4 until the delay timer expires.

Verify Packets With Microloops

Purpose

Verify packets with microloops by using firewall counter information

Action

From operational mode, run the show firewall command on the device R6.

Meaning

The output displays the mplsfilter configured on the device R6 to display microloops if there are any. The value 0 indicates there are no packets with microloops.

Verify Microloop-avoidance Path Changes to Post-convergence- path After the Delay Timer Expires

Purpose

Verify microloop-avoidance path installed for the destination routes R7 from R0 changes to post-convergence-path after the delay timer 60000 ms expires.

Action

From operational mode, run the show route table inet.3 command on the device R0.

From operational mode, run the show route label label value protocol ospf extensive command on the device R0.

Meaning

The output indicates that the microloop-avoidance path is changed to post-convergence-path after the delay timer expires.

Verify Connectivity Between R0 and R7

Purpose

Verify that the Device R0 can reach the destinations on Device R7.

Action

From operational mode, run the ping command on the device R0.

Meaning

These results confirm that the device R0 can reach device R7 in the OSPFv2 network and that the traffic flows with 0% packet loss in case of link down because of the microloop-avoidance path configured.

Verify the Path Changes to Microloop-avoidance Path After the Link is Enabled

Purpose

Verify the path changes to microloop-avoidance path for the destination when the link is enabled between R0 and R1.

Action

From operational mode, run the show route table inet.3 command on the device R0.

From operational mode, run the show route label label value protocol ospf extensive command on the device R0.

Meaning

The output displays the routes to the destination R7 from R0 which includes microloop-avoidance path and the post-convergence path after the link is enabled between R0 and R7.