Configuring OSPF IP FRR

Usage Scenario

As networks develop, services such as Voice over IP (VoIP) and on-line video services require high-quality real-time transmission. However, OSPF takes more than 50 ms to rectify a fault, which cannot meet the requirement for real-time transmission of these services.

Nevertheless, if an OSPF fault occurs, traffic can be switched to a new link only after the fault detection that lasts several milliseconds, fault notification to the routing control plane that lasts several milliseconds, new topology information generation and flooding that last tens of milliseconds, Shortest Path First (SPF) calculation that lasts tens of milliseconds, and new route notification and adding that last hundreds of milliseconds. Therefore, traffic can be quickly switched to a new link only when the time for new route notification and adding is shortened, ensuring that the traffic interruption time is less than 50 ms.

With OSPF IP FRR that calculates a backup link in advance, devices can fast switch traffic to the backup link without interrupting traffic if the primary link fails, which protects traffic and improves OSPF network reliability.

As shown in Figure 1, traffic flows from Device S to Device D. The preceding inequality is met. Device S switches the traffic to the backup link if the primary link fails.

Figure 1 OSPF IP FRR link protection

OSPF IP FRR also applies to node protection. For details, see "OSPF" in HUAWEI NetEngine 8000 F Series Feature Description.

OSPF IP FRR is applicable to services that are sensitive to packet delay and packet loss.

The NetEngine 8000 F supports OSPF IP FRR that uses LFA or Remote LFA as the algorithm.

LFA Auto FRR cannot be used to calculate alternate links on large-scale networks, especially on ring networks. To address this problem, enable Remote LFA Auto FRR. Remote LFA takes effect only when LFA has been enabled.

Both OSPF LFA FRR and OSPF remote LFA FRR use the SPF algorithm to calculate the shortest path to the destination node, with each neighbor that provides a backup link as the root node. The backup next hop is node-based, which applies to single-node routing scenarios. As networks are increasingly diversified, two ABRs or ASBRs are deployed to improve network reliability. In this case, OSPF FRR in a multi-node routing scenario is needed. In Figure 2, Device B and Device C function as ABRs to forward area 0 and area 1 routes. Device E advertises an intra-area route. Upon receipt of the route, Device B and Device C translate it to a Type 3 LSA and flood the LSA to area 0. After OSPF FRR is enabled on Device A, Device A considers Device B and Device C as its neighbors. Without a fixed neighbor as the root node, Device A fails to calculate FRR backup next hop. To address this problem, a virtual node is simulated between Device B and Device C and used as the root node of Device A, and Device A uses the LFA or remote LFA algorithm to calculate the backup next hop. This solution converts multi-node routing into single-node routing.

Figure 2 OSPF FRR in the scenario where multiple nodes advertise the same route

After OSPF IP FRR is configured, the lower layer needs to fast respond to a link change so that traffic can be fast switched to the backup link. After FRR and BFD are bound, link failures can be detected rapidly so that traffic is rapidly switched to the backup link if the primary link fails.

Pre-configuration Tasks

Before configuring OSPF IP FRR, complete the following tasks:

• Configure a link layer protocol.

• Configure IP addresses for interfaces to ensure that neighboring nodes are reachable at the network layer.

• Configure basic OSPF functions.

• Before you configure remote LFA FRR, configure LDP LSPs to perform recursion hop by hop between the source node and PQ node. That is, configure a local LDP session between each pair of directly connected nodes along the link from the source node to PQ node.