Router ID

A router ID is a 32-bit unsigned integer, which identifies a router in an autonomous system (AS). A router ID must exist if OSPF needs to be run.

A router ID can be manually configured or automatically selected by the router.

If a router ID is specified when an OSPF process is created in the system view, the configured router ID is used. If no router ID is specified when an OSPF process is created, the OSPF process uses the router ID in RM. For details about router ID selection rules in RM, see the router id command in the system view. In any of the following situations, OSPF router ID re-selection is performed:

• After you run this command to configure a new OSPF router ID, the OSPF process automatically restarts.
• No router ID is specified for an OSPF process, the router ID in RM changes, and the OSPF process is restarted using the reset ospf process command.
• If the self-healing function is enabled for OSPF router ID conflicts and an OSPF router ID conflict occurs on the network, a new OSPF router ID is selected and the OSPF process is automatically restarted. If no router ID is specified when an OSPF process is created and the device restarts in CFG mode, the router ID in the RM module when the OSPF process is created is used as the OSPF router ID after the restart. Therefore, you are advised to manually specify a router ID when creating the OSPF process.

Areas

When a large number of routers run OSPF, link state databases (LSDBs) become very large and require a large amount of storage space. Large LSDBs also complicate shortest path first (SPF) computation and overload the routers. As the network scale expands, there is an increasing probability that the network topology changes, causing the network to change continuously. In this case, a large number of OSPF packets are transmitted on the network, leading to a decrease in bandwidth utilization efficiency. In addition, each time the topology changes, all routers on the network must recalculate routes.

OSPF prevents frequent LSDB updates and improves network utilization by partitioning an AS into different areas. routers can be logically allocated to different groups (areas), and each group is identified by an area ID. A router, not a link, resides at the border of an area. A network segment or link can belong to only one area. An area must be specified for each OSPF interface.

OSPF areas include common areas, stub areas, and not-so-stubby areas (NSSAs). Table 1-592 describes these OSPF areas.

Router Types

Routers are classified by location in an AS. Figure 1-1455 and Table 1-593 show the classification.

Figure 1-1455 Router types

LSA

OSPF encapsulates routing information into LSAs for transmission. Table 1-594 describes LSAs and their functions.

Table 1-595 describes whether a type of LSA is supported in an area.

Packet Types

OSPF uses IP packets to encapsulate protocol packets. The protocol number is 89. OSPF packets are classified as Hello, database description (DD), link state request (LSR), link state update (LSU), or link state acknowledgment (LSAck) packets, as described in Table 1-596.

Route Types

AS intra-area and inter-area routes describe the network structure within an AS, and AS external routes describe how to select routes to destinations outside the AS. OSPF classifies the imported AS external routes into Type 1 and Type 2.

Table 1-597 describes OSPF routes in descending order of priority.

OSPF Network Classification

According to the link layer protocol type, OSPF classifies networks into four types, as described in Table 1-598.

DR and BDR

On broadcast or NBMA networks, any two routers need to exchange routing information. As shown in Figure 1-1456, n routers are deployed on the network. n x (n - 1)/2 adjacencies must be established. Any route change on a router is transmitted to other routers, which wastes bandwidth resources. OSPF resolves this problem by defining a DR and a BDR. After a DR is elected, all routers send routing information only to the DR. Then the DR broadcasts LSAs. routers other than the DR and BDR are called DR others. The DR others establish only adjacencies with the DR and BDR and not with each other. This process reduces the number of adjacencies established between routers on broadcast or NBMA networks.

Figure 1-1456 Network topologies before and after a DR election

If the original DR fails, routers must reelect a DR and the routers except the new DR must synchronize routing information to the new DR. This process is lengthy, which may cause incorrect route calculations. A BDR is used to shorten the process. The BDR is a backup for a DR. A BDR is elected together with a DR. The BDR establishes adjacencies with all routers on the network segment and exchanges routing information with them. If the DR fails, the BDR immediately becomes a new DR. Because no re-election is required and adjacencies have been established, this process is very short. In this case, a new BDR needs to be elected. Although this process takes a long time, it does not affect route calculation.

The DR and BDR are not designated manually. Instead, they are elected by all routers on the network segment. The DR priority of an interface on the router determines whether the interface is qualified for DR or BDR election. On the local network segment, the routers whose DR priorities are greater than 0 are all candidates. Hello packets are used for the election. Each router adds information about the DR elected by itself to a Hello packet and sends the packet to other routers on the network segment. If two routers on the same network segment declare that they are DRs, the one with a higher DR priority wins. If they have the same priority, the one with a larger router ID wins. If the priority of a router is 0, it cannot be elected as a DR or BDR.

OSPF Multi-Process

OSPF multi-process allows multiple OSPF processes to independently run on the same router. Route exchange between different OSPF processes is similar to that between different routing protocols. A router's interface can belong only to one OSPF process.

A typical application of OSPF multi-process is that OSPF runs between PEs and CEs in VPN scenarios and OSPF is also used as an IGP on the VPN backbone network. The OSPF processes on the PEs are independent of each other.

OSPF Default Route

A default route is the route whose destination address and mask are both all 0s. If no matching route is found, the default route can be used by the router to forward packets.

OSPF default routes are generally applied to the following scenarios:

• An ABR in an area advertises Type 3 default summary LSAs within the area to help the routers in the area forward inter-area packets.

• An ASBR in an AS advertises Type 5 external default ASE LSAs or Type 7 external default NSSA LSAs to help the routers in the AS forward AS external packets.

OSPF routes are hierarchically managed. The priority of the default route carried in Type 3 LSAs is higher than the priority of the default route carried in Type 5 or Type 7 LSAs.

The rules for advertising OSPF default routes are as follows:

• An OSPF device can advertise default route LSAs only when it has an external interface.
• If an OSPF device has advertised default route LSAs, it no longer learns the same type of default route advertised by other routers. That is, the device no longer calculates the same type of default route LSA advertised by other routers. However, the corresponding LSAs exist in the database.
• If the advertisement of external default routes depends on other routes, the dependent routes cannot be the routes (learned by the local OSPF process) in the local OSPF routing domain. This is because external default routes are used to guide packet forwarding outside the domain. However, the next hops of routes in the OSPF routing domain are within the domain, unable to guide packet forwarding outside the domain.
• Before a router advertises a default route, it checks whether a neighbor in the full state is present in area 0. The router advertises a default route only when a neighbor in the full state is present in area 0. If no such a neighbor exists, the backbone area cannot forward packets and advertising a default route is meaningless. For the concept of the Full State, see OSPF Neighbor States.

Table 1-599 describes the principles for advertising default routes in different areas.

OSPF Neighbor States

To exchange routing information on an OSPF network, neighbor routers must establish adjacencies. The differences between neighbor relationships and adjacencies are described as follows:

• Neighbor relationship: After the local router starts, it uses an OSPF interface to send a Hello packet to the remote router. After the remote router receives the packet, it checks whether the parameters carried in the packet are consistent with its own parameters. If the parameters carried in the packet are consistent with its own parameters, the remote router establishes a neighbor relationship with the local router.
• Adjacency: After the local and remote routers establish a neighbor relationship, they exchange DD packets and LSAs to establish an adjacency.

OSPF has eight neighbor states: Down, Attempt, Init, 2-way, Exstart, Exchange, Loading, and Full. Down, 2-way, and Full are stable states. Attempt, Init, Exstart, Exchange, and Loading are unstable states, which last only several minutes. Figure 1-1457 shows the eight neighbor states.

Figure 1-1457 OSPF neighbor states

The neighbor state of the local device may be different from that of a remote device. For example, the neighbor state of the local router is Full, but the neighbor state of the remote router is Loading.

Adjacency Establishment

Adjacencies can be established in either of the following situations:

• Two routers have established a neighbor relationship and communicate for the first time.

• The designated router (DR) or backup designated router (BDR) on a network segment changes.

The adjacency establishment process is different on different networks.

Adjacency establishment on a broadcast network

Figure 1-1458 shows the adjacency establishment process on a broadcast network.

On the broadcast network, the DR and BDR establish adjacencies with each router on the same network segment, but DR others establish only neighbor relationships.

Figure 1-1458 Adjacency establishment process on a broadcast network

Figure 1-1458 shows the OSPF adjacency establishment process on a broadcast network.

1. Neighbor relationship establishment

   1. Router A uses the multicast address 224.0.0.5 to send a Hello packet through the OSPF interface connected to a broadcast network. In this case, Router A does not know which router is the DR or which router is a neighbor. Therefore, the DR field is 0.0.0.0, and the Neighbors Seen field is 0.

   2. After Router B receives the packet, it returns a Hello packet to Router A. The returned packet carries the DR field of 2.2.2.2 (ID of Router B) and the Neighbors Seen field of 1.1.1.1 (Router A's router ID). Router A has been discovered but its router ID is less than that of Router B, and therefore Router B regards itself as a DR. Then Router B's state changes to Init.

   3. After Router A receives the packet, Router A's state changes to 2-way.

   The following procedures are not performed for DR others on a broadcast network.

2. Master/Slave negotiation and DD packet exchange

   1. Router A sends a DD packet. The packet carries the following fields:

      • Seq field: The value x indicates the sequence number is x.
      • I field: The value 1 indicates that the packet is the first DD packet, which is used to negotiate a master/slave relationship and does not carry LSA summaries.
      • M field: The value 1 indicates that the packet is not the last DD packet.
      • MS field: The value 1 indicates that Router A declares itself a master.

      To improve transmission efficiency, Router A and Router B determine which LSAs in each other's LSDB need to be updated. If one party determines that an LSA of the other party is already in its own LSDB, it does not send an LSR packet for updating the LSA to the other party. To achieve the preceding purpose, Router A and Router B first send DD packets, which carry summaries of LSAs in their own LSDBs. Each summary identifies an LSA. To ensure packet transmission reliability, a master/slave relationship must be determined during DD packet exchange. One party serving as a master uses the Seq field to define a sequence number. The master increases the sequence number by one each time it sends a DD packet. When the other party serving as a slave sends a DD packet, it adds the sequence number carried in the last DD packet received from the master to the Seq field of the packet.

   2. After receiving the DD packet from Router A, Router B sets the neighbor state of Router A to Exstart and returns a DD packet. The returned packet does not carry LSA summaries either. Because Router B's router ID is greater than Router A's router ID, Router B declares itself a master and sets the Seq field to y.

   3. After Router A receives the DD packet, it agrees that Router B is a master and Router A's state changes to Exchange. Then Router A sends a DD packet to Router B to transmit LSA summaries. The packet carries the Seq field of y and the MS field of 0. The value 0 indicates that Router A declares itself a slave.

   4. After Router B receives the packet, Router B's state changes to Exchange and Router B sends a new DD packet containing its own LSA summaries to Router A. The value of the Seq field carried in the new DD packet is changed to y + 1.

   Router A uses the same sequence number as Router B to confirm that it has received DD packets from Router B. Router B uses the sequence number plus one to confirm that it has received DD packets from Router A. When Router B sends the last DD packet, it sets the M field of the packet to 0.

3. LSDB synchronization

   1. After Router A receives the last DD packet, it finds that many LSAs in Router B's LSDB do not exist in its own LSDB, so Router A's state changes to Loading. After Router B receives the last DD packet from Router A, Router B's state directly changes to Full, because Router B's LSDB already contains all LSAs of Router A.

   2. Router A sends an LSR packet for updating LSAs to Router B. Router B returns an LSU packet to Router A. After Router A receives the packet, it sends an LSAck packet for acknowledgment.

   The preceding procedures continue until the LSAs in Router A's LSDB are the same as those in Router B's LSDB. Router A sets the state of the neighbor relationship with Router B to Full. After the routers exchange DD packets and update all LSAs, they establish an adjacency.

Adjacency establishment on an NBMA network

The adjacency establishment process on an NBMA network is similar to that on a broadcast network. The blue part shown in Figure 1-1459 highlights the differences from a broadcast network.

On an NBMA network, all routers establish adjacencies only with the DR and BDR.

Figure 1-1459 Adjacency establishment process on an NBMA network

The adjacency establishment process on an NBMA network is as follows:

1. Neighbor relationship establishment

   1. After Router B sends a Hello packet to a down interface of Router A, Router B's state changes to Attempt. At this time, Router B regards itself as a DR but does not know which router is the neighbor. The packet carries the DR field of 2.2.2.2 (ID of Router B) and the Neighbors Seen field of 0.

   2. After Router A receives the Hello packet, Router A sets the neighbor state to Init and returns a Hello packet. Router A agrees that Router B is a DR. The DR and Neighbors Seen fields are both set to 2.2.2.2.

   The following procedures are not performed for DR others on an NBMA network.

2. Master/Slave relationship negotiation and DD packet exchange

   The procedures for negotiating a master/slave relationship and exchanging DD packets on an NBMA network are the same as those on a broadcast network.

3. LSDB synchronization

   The procedure for synchronizing LSDBs on an NBMA network is the same as that on a broadcast network.

Adjacency establishment on a point-to-point (P2P)/Point-to-multipoint (P2MP) network

The adjacency establishment process on a P2P/P2MP network is similar to that on a broadcast network. On a P2P/P2MP network, however, no DR or BDR needs to be elected and DD packets are transmitted in multicast mode.

Route Calculation

OSPF uses the shortest path first (SPF) algorithm to calculate routes, implementing fast route convergence.

OSPF uses an LSA to describe the network topology. A Router LSA describes the attributes of a link between routers. A router transforms its LSDB into a weighted, directed graph, which reflects the topology of the entire AS. All routers in the same area have the same graph. Figure 1-1460 shows a weighted, directed graph.

Figure 1-1460 Weighted, directed graph

Based on the graph, each router uses the SPF algorithm to calculate an SPT with itself as the root. The SPT shows routes to nodes in the AS. Figure 1-1461 shows an SPT.

Figure 1-1461 SPT

When a router's LSDB changes, the router recalculates a shortest path. Frequent SPF calculations consume a large number of resources and affect router efficiency. Changing the interval between SPF calculations can prevent resource consumption caused by frequent LSDB changes. The default interval between SPF calculations is 5 seconds.

The route calculation process is as follows:

1. A router calculates intra-area routes.

   The router uses an SPF algorithm to calculate shortest paths to other routers in an area. Router LSAs and Network LSAs accurately describe the network topology in an area. Based on the network topology described by a Router LSA, the router calculates paths to other routers in the area.

   If multiple equal-cost routes are produced during route calculation, the SPF algorithm retains all these routes in the LSDB.

2. The router calculates inter-area routes.

   For the devices in an area, the network segment of the routes in an adjacent area is directly connected to the area border router (ABR). Because the shortest path to the ABR has been calculated in the preceding step, the devices can directly check a Network Summary LSA to obtain the shortest path to the network segment. The autonomous system boundary router (ASBR) can also be considered connected to the ABR. Therefore, the shortest path to the ASBR can also be calculated in this phase.

   If the router performing an SPF calculation is an ABR, the router needs to check only Type 3 LSAs in the backbone area.

   If there are multiple paths to an ASBR, check whether the rules for selecting a path to the ASBR among intra-area and inter-area paths on different types of devices are the same. If the rules are different, routing loops may occur.

   The RFC 1583 compatibility mode and RFC 1583 non-compatibility mode may affect path selection rules. Even in the same mode, the path selection rules on devices from different vendors may be slightly different. In this case, the rules used in RFC 1583 compatibility mode or RFC 1583 non-compatibility mode for selecting a path to an ASBR can be adjusted, preventing loops to some extent.

3. The router calculates AS external routes.

   AS external routes can be considered to be directly connected to the ASBR. Because the shortest path to the ASBR has been calculated in the preceding phase, the device can check AS External LSAs to obtain the shortest paths to other ASs.

Route Summarization

When a large OSPF network is deployed, an OSPF routing table includes a large number of routing entries. To accelerate route lookup and simplify management, configure route summarization to reduce the size of the OSPF routing table. If a link frequently alternates between Up and Down, the links not involved in the route summarization are not affected. This process prevents route flapping and improves network stability.

Route summarization can be carried out on an ABR or ASBR.

• ABR summarization

  When an ABR transmits routing information to other areas, it generates Type 3 LSAs for each network segment. If consecutive network segments exist in this area, you can summarize these network segments into a single network segment. The ABR generates one LSA for the summarized network segment and advertises only that LSA.

• ASBR summarization

  If route summarization has been configured and the local router is an ASBR, the local router summarizes imported Type 5 LSAs within the summarized address range. If an NSSA has been configured, the local router also summarizes imported Type 7 LSAs within the summarized address range.

  If the local router is both an ASBR and an ABR, it summarizes Type 5 LSAs translated from Type 7 LSAs.

Route Filtering

OSPF routing policies include access control lists (ACLs), IP prefix lists, and route-policies. For details about these policies, see the section "Routing Policy" in the NetEngine 8100 M, NetEngine 8000E M, NetEngine 8000 MFeature Description - IP Routing.

OSPF route filtering applies in the following aspects:

• Route import

  OSPF can import the routes learned by other routing protocols. A router uses a configured routing policy to filter routes and imports only the routes matching the routing policy. Only an ASBR can import routes, and therefore a routing policy for importing routes must be configured on the ASBR.

• Advertising of imported routes

  A router advertises imported routes to its neighbors. Only an ASBR can import routes, and therefore a routing policy for the advertising of imported routes must be configured on the ASBR.

  If OSPF imports a large number of external routes and advertises them to a device with a smaller routing table capacity, the device may restart unexpectedly. To address this problem, configure a limit on the number of LSAs generated when an OSPF process imports external routes.

• Route learning

  A router uses a routing policy to filter received intra-area, inter-area, and AS external routes. The router adds only the routes matching the routing policy to its routing table. All routes can still be advertised from an OSPF routing table.

  The router filters only routes calculated based on LSAs, and therefore learned LSAs are complete.

• Inter-area LSA learning

  An ABR in an area can be configured to filter Type 3 LSAs advertised to the area. The ABR can advertise only Type 3 LSAs, and therefore a routing policy for inter-area LSA learning must be configured on the ABR.

  During inter-area LSA learning, the ABR directly filters Type 3 LSAs advertised to the area.

• Inter-area LSA advertising

  An ABR in an area can be configured to filter Type 3 LSAs advertised to other areas. The ABR can advertise only Type 3 LSAs, and therefore a routing policy for inter-area LSA advertising must be configured on the ABR.

OSPF Database Overflow

OSPF requires that devices in the same area have the same LSDB. As the number of routes increase continually, some devices cannot carry excess routing information due to limited system resources. This situation is called an OSPF database overflow.

You can configure stub areas or NSSAs to prevent resource exhaustion caused by continually increasing routing information. However, configuring stub areas or NSSAs cannot prevent an OSPF database overflow caused by a sharp increase in dynamic routes. To resolve this issue, set the maximum number of external routes supported by the LSDB to dynamically limit the LSDB's size.

The maximum number of external routes configured for all devices in the OSPF AS must be the same.

When the number of external routes in the LSDB reaches the maximum number, the device enters the overload state and starts the overflow timer at the same time. The device automatically exits from the overflow state after the overflow timer expires. Table 1-601 describes the operations performed by the device after it enters or exits from the overload state.

Background

All non-backbone areas must be connected to the backbone area during OSPF deployment to ensure that all areas are reachable.

In Figure 1-1462, area 2 is not connected to area 0 (backbone area), and Device B is not an ABR. Therefore, Device B does not generate routing information about network 1 in area 0, and Device C does not have a route to network 1.

Figure 1-1462 Non-backbone area not connected to the backbone area

Some non-backbone areas may not be connected to the backbone area. You can configure an OSPF virtual link to resolve this issue.

Related Concepts

A virtual link refers to a logical channel established between two ABRs over a non-backbone area.

• A virtual link must be configured at both ends of the link.
• The non-backbone area involved is called a transit area.

A virtual link is similar to a point-to-point (P2P) connection established between two ABRs. You can configure interface parameters, such as the interval at which Hello packets are sent, at both ends of the virtual link as you do on physical interfaces.

Principles

In Figure 1-1463, two ABRs use a virtual link to directly transmit OSPF packets. The device between the two ABRs only forwards packets. Because the destination of OSPF packets is not the device, the device transparently transmits the OSPF packets as common IP packets.

Figure 1-1463 OSPF virtual link

OSPF in the MPLS TE Architecture

In the MPLS TE architecture, OSPF functions as the information advertising component:

• Collects related information about TE.

• Floods TE information to devices in the same area.

• Uses the collected TE information to form the TE database (TEDB) so that CSPF can calculate routes.

OSPF does not care about information content or how MPLS uses the information.

TE-LSA

OSPF uses a new type of LSA (Type 10 opaque LSA) to collect and advertise TE information. Type 10 opaque LSAs contain the link status information required by TE, including the maximum link bandwidth, maximum reservable bandwidth, current reserved bandwidth, and link color. Based on the OSPF flooding mechanism, Type 10 opaque LSAs synchronize link status information among devices in an area to form a uniform TEDB for route calculation.

Interaction Between OSPF TE and CSPF

OSPF uses Type 10 LSAs to collect TE information in an area, such as the bandwidth, priority, and link metrics. After processing the collected TE information, OSPF provides it for CSPF to calculate routes.

IGP Shortcut and Forwarding Adjacency

OSPF supports IGP shortcut and forwarding adjacency. The two features allow OSPF to use a tunnel interface as an outbound interface to reach a destination.

Differences between IGP shortcut and forwarding adjacency are as follows:

• An IGP shortcut-enabled device uses a tunnel interface as an outbound interface but does not advertise the tunnel interface to neighbors. Therefore, other devices cannot use this tunnel.

• A forwarding adjacency-enabled device uses a tunnel interface as an outbound interface and advertises the tunnel interface to neighbors. Therefore, other devices can use this tunnel.

• IGP shortcut is unidirectional and needs to be configured only on the device that uses IGP shortcut.

OSPF SRLG

OSPF supports the applications of the Shared Risk Link Group (SRLG) in MPLS by obtaining information about the TE SRLG flooded among devices in an area. For details, refer to the chapter "MPLS" in this manual.

OSPF TE Tunnel Microloop Avoidance

If a network fault occurs, IGP convergence is triggered. In this case, a transient forwarding status inconsistency may occur among nodes because of their different convergence rates, which poses the risk of microloops. If the outbound interface of a route before IGP convergence is a shortcut TE tunnel interface and the OSPF TE tunnel microloop avoidance function is enabled, the outbound interface of the route remains unchanged during IGP convergence. In this case, traffic is forwarded through a hot standby TE tunnel, and the forwarding process does not depend on IGP convergence on each device, preventing microloops.

Definition

As an extension of OSPF, OSPF VPN enables Provider Edges (PEs) and Customer Edges (CEs) in VPNs to run OSPF for interworking and use OSPF to learn and advertise routes.

Purpose

As a widely used IGP, in most cases, OSPF runs in VPNs. If OSPF runs between PEs and CEs, and PEs use OSPF to advertise VPN routes to CEs, no other routing protocols need to be configured on CEs for interworking with PEs, which simplifies management and configuration of CEs.

Running OSPF Between PEs and CEs

In BGP/MPLS VPN, Multi-Protocol BGP (MP-BGP) is used to transmit routing information between PEs, whereas OSPF is used to learn and advertise routes between PEs and CEs.

Running OSPF between PEs and CEs has the following benefits:

• OSPF is used in a site to learn routes. Running OSPF between PEs and CEs can reduce the number of the protocol types that CEs must support.

• Similarly, running OSPF both in a site and between PEs and CEs simplifies the work of network administrators and reduces the number of protocols that network administrators must be familiar with.

• When a network using OSPF but not VPN on the backbone network begins to use BGP/MPLS VPN, running OSPF between PEs and CEs facilitates the transition.

In Figure 1-1465, CE1, CE3, and CE4 belong to VPN 1, and the numbers following OSPF refer to the process IDs of the multiple OSPF instances running on PEs.

Figure 1-1465 Networking with OSPF running between PEs and CEs

The routes that PE1 receives from CE1 are advertised to CE3 and CE4 as follows:

1. PE1 imports OSPF routes of CE1 into BGP and converts them to BGP VPNv4 routes.

2. PE1 uses MP-BGP to advertise the BGP VPNv4 routes to PE2.

3. PE2 imports the BGP VPNv4 routes into OSPF and then advertises these routes to CE3 and CE4.

The process of advertising routes of CE4 or CE3 to CE1 is the same as the preceding process.

Configuring OSPF Areas Between PEs and CEs

OSPF areas between PEs and CEs can be non-backbone or backbone areas (Area 0). PEs can function only as ABRs.

In the extended application of OSPF VPN, the MPLS VPN backbone network serves as Area 0. OSPF requires that Area 0 be contiguous. Therefore, Area 0 of all VPN sites must be connected to the MPLS VPN backbone network. If a VPN site has OSPF Area 0, the PEs that CEs access must be connected to the backbone area of this VPN site through Area 0. If no physical link is available to directly connect PEs to the backbone area, a virtual link can be deployed between the PEs and the backbone area. Figure 1-1466 shows the networking for configuring OSPF areas between PEs and CEs.

Figure 1-1466 Configuring OSPF areas between PEs and CEs

A non-backbone area (Area 1) is configured between PE1 and CE1, and a backbone area (Area 0) is configured in Site 1. The backbone area in Site 1 is separated from the VPN backbone area. To ensure that the backbone areas are contiguous, a virtual link is configured between PE1 and CE1.

OSPF Domain ID

If inter-area routes are advertised between local and remote OSPF areas, these areas are considered to be in the same OSPF domain.

• Domain IDs identify domains.

• Each OSPF domain has one or more domain IDs. If more than one domain ID is available, one of the domain IDs is a primary ID, and the others are secondary IDs.

• If an OSPF instance does not have a specific domain ID, its ID is considered as null.

Before advertising the remote routes sent by BGP to CEs, PEs need to determine the type of OSPF routes (Type 3, Type 5, or Type 7) to be advertised to CEs based on domain IDs.

• If local domain IDs are the same as or compatible with remote domain IDs in BGP routes, PEs advertise Type 3 routes.

• Otherwise, Type 5 or Type 7 routes are advertised.

Routing Loop Prevention

Routing loops may occur between PEs and CEs when OSPF and BGP learn routes from each other.

Figure 1-1467 Networking for OSPF VPN routing loops

In Figure 1-1467, on PE1, OSPF imports a BGP route destined for 10.1.1.1/32 and then generates and advertises a Type 5 or Type 7 LSA to CE1. Then, CE1 learns an OSPF route with 10.1.1.1/32 as the destination address and PE1 as the next hop and advertises the route to PE2. Therefore, PE2 learns an OSPF route with 10.1.1.1/32 as the destination address and CE1 as the next hop.

Similarly, CE1 also learns an OSPF route with 10.1.1.1/32 as the destination address and PE2 as the next hop. PE1 learns an OSPF route with 10.1.1.1/32 as the destination address and CE1 as the next hop.

As a result, CE1 has two equal-cost routes with PE1 and PE2 as next hops respectively, and the next hop of the routes from PE1 and PE2 to 10.1.1.1/32 is CE1, which leads to a routing loop.

In addition, the priority of an OSPF route is higher than that of a BGP route. Therefore, on PE1 and PE2, BGP routes to 10.1.1.1/32 are replaced with the OSPF route, and the OSPF route with 10.1.1.1/32 as the destination address and CE1 as the next hop is active in the routing tables of PE1 and PE2.

The BGP route is inactive, and therefore, the LSA generated when this route is imported by OSPF is deleted, which causes the OSPF route to be withdrawn. As a result, no OSPF route exists in the routing table, and the BGP route becomes active again. This cycle causes route flapping.

OSPF VPN provides a few solutions to routing loops, as described in Table 1-603.

Disabling Routing Loop Prevention

Exercise caution when disabling routing loop prevention because it may cause routing loops.

During BGP or OSPF route exchanges, routing loop prevention prevents OSPF routing loops in VPN sites.

In the inter-AS VPN Option A scenario, if OSPF runs between ASBRs to transmit VPN routes, the remote ASBR may fail to learn the OSPF routes sent by the local ASBR due to the routing loop prevention mechanism.

In Figure 1-1468, inter-AS VPN Option A is deployed with OSPF running between PE1 and CE1. CE1 sends VPN routes to CE3.

Figure 1-1468 Networking for inter-AS VPN Option A

1. PE1 learns routes to CE1 using the OSPF process in a VPN instance, imports these routes into MP-BGP, and sends the MP-BGP routes to ASBR1.

2. After receiving the MP-BGP routes, ASBR1 imports the routes into the OSPF process in a VPN instance and generates Type 3, Type 5, or Type 7 LSAs carrying DN bit 1.

3. ASBR2 uses OSPF to learn these LSAs and checks the DN bit of each LSA. After learning that the DN bit in each LSA is 1, ASBR2 does not add the routes carried in these LSAs to its routing table.

The routing loop prevention mechanism prevents ASBR2 from learning the OSPF routes sent from ASBR1. As a result, CE1 cannot communicate with CE3.

To address the preceding problem, use either of the following methods:

• Disable the device from setting the DN bit to 1 in the LSAs when importing BGP routes into OSPF. For example, if ASBR1 does not set the DN bit to 1 when importing MP-BGP routes into OSPF. After ASBR2 receives these routes and finds that the DN bit in the LSAs carrying these routes is 0, ASBR2 will add the routes to its routing table.

• Disable the device from checking the DN bit after receiving LSAs. For example, ASBR1 sets the DN bit to 1 in LSAs when importing MP-BGP routes into OSPF. ASBR2, however, does not check the DN bit after receiving these LSAs.

The preceding methods can be used based on specific types of LSAs. You can configure a sender to determine whether to set the DN bit to 1 or configure a receiver to determine whether to check the DN bit in the Type 3 LSAs based on the router ID of the device that generates the Type 3 LSAs.

In the inter-AS VPN Option A scenario shown in Figure 1-1469, the four ASBRs are fully meshed and run OSPF. ASBR2 may receive the Type 3, Type 5, or Type 7 LSAs generated on ASBR4. If ASBR2 is not configured to check the DN bit in the LSAs, ASBR2 will accept the Type 3 LSAs, which may cause routing loops, as described in Routing Loop Prevention. ASBR2 will deny the Type 5 or Type 7 LSAs, because the VPN route tags carried in the LSAs are the same as the default VPN route tag of the OSPF process on ASBR2.

To address the routing loop problem caused by Type 3 LSAs, ASBR2 can be disabled from checking the DN bit in the Type 3 LSAs generated by devices with router ID 1.1.1.1 and router ID 3.3.3.3. After the configuration is complete, if ASBR2 receives Type 3 LSAs sent by ASBR4 with router ID 4.4.4.4, ASBR2 checks the DN bit and denies these Type 3 LSAs because the DN bit is set to 1.

Figure 1-1469 Networking for fully meshed ASBRs in the inter-AS VPN Option A scenario

Sham Link

OSPF sham links are unnumbered P2P links between two PEs over an MPLS VPN backbone network.

Generally, BGP extended community attributes carry routing information over the MPLS VPN backbone between BGP peers. OSPF running on the other PE can use the routing information to generate inter-area routes from PEs to CEs.

Figure 1-1470 OSPF Sham link

In Figure 1-1470, if an intra-area OSPF link exists between the network segments of local and remote CEs. Routes that pass through the intra-area route link and have higher priorities than inter-area routes that pass through the MPLS VPN backbone network. As a result, VPN traffic is always forwarded through the intra-area route instead of the backbone network. To prevent such a problem, an OSPF sham link can be established between PEs so that the routes that pass through the MPLS VPN backbone network also become OSPF intra-area routes and take precedence.

• A sham link is a link between two VPN instances. Each VPN instance contains the address of an end-point of a sham link. The address is a loopback address with the 32-bit mask in the VPN address space on the PE.

• After a sham link is established between two PEs, the PEs become neighbors on the sham link and exchange routing information.

• A sham link functions as a P2P link within an area. Users can select a route from the sham link and intra-area route link by adjusting the metric.

Multi-VPN-Instance CE

OSPF multi-instance generally runs on PEs. Devices that run OSPF multi-instance within user LANs are called Multi-VPN-Instance CEs (MCEs).

Compared with OSPF multi-instance running on PEs, MCEs have the following characteristics:

• MCEs do not need to support OSPF-BGP association.

• MCEs establish one OSPF instance for each service. Different virtual CEs transmit different services, which ensures LAN security at a low cost.

• MCEs implement different OSPF instances on a CE. The key to implementing MCEs is to disable loop detection and calculate routes directly. MCEs also use the received LSAs with the DN-bit 1 for route calculation.

Background

As defined in OSPF, stub areas cannot import external routes. This mechanism prevents external routes from consuming the bandwidth and storage resources of routers in stub areas. If you need to both import external routes and prevent resource consumption caused by external routes, you can configure not-so-stubby areas (NSSAs).

There are many similarities between NSSAs and stub areas. However, different from stub areas, NSSAs can import AS external routes into the OSPF AS and advertise the imported routes in the OSPF AS without learning external routes from other areas on the OSPF network.

Related Concepts

• N-bit

  A router uses the N-bit carried in a Hello packet to identify the area type that it supports. The same area type must be configured for all routers in an area. If routers have different area types, they cannot establish OSPF neighbor relationships. Some vendors' devices do not comply with standard protocols, but the N-bit is also set in OSPF Database Description (DD) packets. You can manually set the N-bit on a router to interwork with the vendors' devices.

• Type 7 LSA

  Type 7 LSAs, which describe imported external routes, are introduced to support NSSAs. Type 7 LSAs are generated by an ASBR in an NSSA and advertised only within the NSSA. After an ABR in an NSSA receives Type 7 LSAs, it selectively translates Type 7 LSAs into Type 5 LSAs to advertise external routes to other areas on an OSPF network.

Principles

To advertise external routes imported by an NSSA to other areas, a translator must translate Type 7 LSAs into Type 5 LSAs. Notes for an NSSA are as follows:

• By default, the translator is the ABR with the largest router ID in the NSSA.

• The propagate bit (P-bit) is used to notify a translator whether Type 7 LSAs need to be translated.

• Only Type 7 LSAs with the P-bit set and a non-zero forwarding address (FA) can be translated into Type 5 LSAs. An FA indicates that packets to a destination address will be forwarded to the address specified by the FA.

  FA indicates that the packet to a specific destination address is to be forwarded to the address specified by.

  The loopback interface address in an area is preferentially selected as the FA. If no loopback interface exists, the address of the interface that is Up and has the smallest logical index in the area is selected as the FA.

• The P-bit is not set for default routes in Type 7 LSAs generated by an ABR.

Figure 1-1471 shows an NSSA.

Figure 1-1471 NSSA

Advantages

Multiple ABRs may be deployed in an NSSA. To prevent routing loops caused by default routes, ABRs do not calculate the default routes advertised by each other.

Background

When multicast and an MPLS TE tunnel are configured on a network and the TE tunnel is configured with IGP Shortcut, the outbound interface of the route calculated by an IGP may be not an actual physical interface but a TE tunnel interface. The TE tunnel interface on the Device sends multicast Join messages over a unicast route to the multicast source address. The multicast Join messages are transparent to the Device spanned by the TE tunnel. As a result, the Device spanned by the TE tunnel cannot generate multicast forwarding entries.

To resolve the problem, configure OSPF local multicast topology (MT) to create a multicast routing table for multicast packet forwarding.

Implementation

Multicast and an MPLS TE tunnel are deployed on the network, and the TE tunnel is enabled with IGP Shortcut. As shown in Figure 1-1472, DeviceB is spanned by the TE tunnel and therefore does not create any multicast forwarding entry.

Figure 1-1472 OSPF Local MT

Because the TE tunnel is unidirectional, multicast data packets sent from the multicast source are directly sent to the routers spanned by the tunnel through physical interfaces. These routers, however, do not have multicast forwarding entries. As a result, the multicast data packets are discarded, and services are unavailable.

After local MT is enabled, if the outbound interface of the calculated route is an IGP Shortcut TE tunnel interface, the route management (RM) module creates a separate Multicast IGP (MIGP) routing table for the multicast protocol, calculates the actual physical outbound interface for the route, and then adds the route to the MIGP routing table. Multicast then uses routes in the MIGP routing table to forward packets.

In Figure 1-1472, after the messages requesting to join a multicast group reach DeviceA, they are forwarded to DeviceB through interface 1. In this manner, DeviceB can correctly create the multicast forwarding table.

Definition

Bidirectional Forwarding Detection (BFD) is a mechanism to detect communication faults between forwarding engines.

To be specific, BFD detects the connectivity of a data protocol along a path between two systems. The path can be a physical link, a logical link, or a tunnel.

In BFD for OSPF, a BFD session is associated with OSPF. The BFD session quickly detects a link fault and then notifies OSPF of the fault, which speeds up OSPF's response to network topology changes.

Purpose

A link fault or a topology change causes routers to recalculate routes. Routing protocol convergence must be as quick as possible to improve network availability. Link faults are inevitable, and therefore a solution must be provided to quickly detect faults and notify routing protocols.

BFD for Open Shortest Path First (OSPF) associates BFD sessions with OSPF. After BFD for OSPF is configured, BFD quickly detects link faults and notifies OSPF of the faults. BFD for OSPF accelerates OSPF response to network topology changes.

Table 1-604 describes OSPF convergence speeds before and after BFD for OSPF is configured.

Principles

Figure 1-1473 BFD for OSPF

Figure 1-1473 shows a typical network topology with BFD for OSPF configured. The principles of BFD for OSPF are described as follows:

1. OSPF neighbor relationships are established between these three routers.

2. After a neighbor relationship becomes Full, a BFD session is established.

3. The outbound interface on Device A connected to Device B is interface 1. If the link between Device A and Device B fails, BFD detects the fault and then notifies Device A of the fault.

4. Device A processes the event that a neighbor relationship goes Down and recalculates routes. The new route passes through Device C and reaches Device A, with interface 2 as the outbound interface.

Definition

Generalized TTL security mechanism (GTSM) is a mechanism that protects services over the IP layer by checking whether the TTL value in an IP packet header is within a pre-defined range.

Purpose

On networks, attackers may simulate OSPF packets and keep sending them to a device. After receiving these packets, the device directly sends them to the control plane for processing without checking their validity if the packets are destined for the device. As a result, the control plane is busy processing these packets, resulting in high CPU usage.

GTSM is used to protect the TCP/IP-based control plane against CPU-utilization attacks, such as CPU-overload attacks.

Principles

GTSM-enabled devices check the TTL value in each received packet based on a configured policy. The packets that fail to pass the policy are discarded or sent to the control plane, which prevents the devices from possible CPU-utilization attacks. A GTSM policy involves the following items:

• Source address of the IP packet sent to the device

• VPN instance to which the packet belongs

• Protocol number of the IP packet (89 for OSPF)

• Source port number and destination port number of protocols above TCP/UDP

• Valid TTL range

GTSM is implemented as follows:

• For directly connected OSPF neighbors, the TTL value of the unicast protocol packets to be sent is set to 255.

• For multi-hop neighbors, a reasonable TTL range is defined.

The applicability of GTSM is as follows:

• GTSM takes effect on unicast packets rather than multicast packets. This is because the TTL value of multicast packets can only be 255, and therefore GTSM is not needed to protect against multicast packets.

• GTSM does not support tunnel-based neighbors.

Definition

Hello packets are periodically sent on OSPF interfaces of routers. By exchanging Hello packets, the routers establish and maintain the neighbor relationship, and elect the DR and the Backup Designated Router (BDR) on the multiple-access network (broadcast or NBMA network). OSPF uses a Hello timer to control the interval at which Hello packets are sent. A router can send Hello packets again only after the Hello timer expires. Neighbors keep waiting to receive Hello packets until the Hello timer expires. This process delays the establishment of OSPF neighbor relationships or election of the DR and the BDR.

Enabling Smart-discover can solve the preceding problem.

Principles

In the following situations, Smart-discover-enabled interfaces can send Hello packets to neighbors regardless of whether the Hello timer expires:

• On broadcast or NBMA networks, neighbor relationships can be established and a DR and a BDR can be elected rapidly.

  • The neighbor status becomes 2-way for the first time or returns to Init from 2-way or a higher state.

  • The interface status of the DR or BDR on a multiple-access network changes.

• On P2P or P2MP networks, neighbor relationships can be established rapidly. The establishment of neighbor relationships on a P2P or P2MP network is the same as that on a broadcast or NBMA network.

Background

When a new device is deployed on a network or a device is restarted, network traffic may be lost during BGP route convergence because IGP routes converge more quickly than BGP routes.

OSPF-BGP synchronization can address this problem.

Purpose

If a backup link exists, BGP traffic may be lost during traffic switchback because BGP routes converge more slowly than OSPF routes do.

In Figure 1-1474, Device A, Device B, Device C, and Device D run OSPF and establish IBGP connections. Device C functions as the backup of Device B. When the network is stable, BGP and OSPF routes converge completely on the router.

In most cases, traffic from Device A to 10.3.1.0/30 passes through Device B. If Device B fails, traffic is switched to Device C. After Device B recovers, traffic is switched back to Device B. During this process, packet loss occurs.

Consequently, convergence of OSPF routes is complete whereas BGP route convergence is still going on. As a result, Device B does not have the route to 10.3.1.0/30.

When packets from Device A to 10.3.1.0/30 reach Device B, Device B discards them because Device B does not have the route to 10.3.1.0/30.

Figure 1-1474 Networking for OSPF-BGP synchronization

Principles

If OSPF-BGP synchronization is configured on a device, the device remains as a stub router during the set synchronization period. During this period, the link metric in the LSA advertised by the device is set to the maximum value (65535), instructing other OSPF routers not to use it as a transit router for data forwarding.

In Figure 1-1474, OSPF-BGP synchronization is enabled on Router B. In this situation, before BGP route convergence is complete, Device A keeps forwarding data through Device C rather than Device B until BGP route convergence on Device B is complete.

Background

LDP-IGP synchronization is used to synchronize the status between LDP and an IGP to minimize the traffic loss time if a network fault triggers the LDP and IGP switching.

On a network with active and standby links, if the active link fails, IGP routes and an LSP are switched to the standby link. After the active link recovers, IGP routes are switched back to the active link before LDP convergence is complete. In this case, the LSP along the active link takes time to make preparations, such as adjacency restoration, before being established. As a result, LSP traffic is discarded. If an LDP session or adjacency between nodes fails on the active link, the LSP along the active link is deleted. However, the IGP still uses the active link, and as a result, LSP traffic cannot be switched to the standby link, and is continuously discarded.

LDP-IGP synchronization supports OSPFv2 and IS-IS (IPv4).

On a network enabled with LDP-IGP synchronization, an IGP keeps advertising the maximum cost of an IGP route over the new active link to delay IGP route convergence until LDP converges. That is, before the LSP of the active link is established, the LSP of the standby link is retained so that the traffic continues to be forwarded through the standby link. The standby LSP is torn down only after the active LSP is established successfully.

LDP-IGP synchronization involves the following timers:

• Hold-max-cost timer

• Delay timer

Implementation

Figure 1-1475 Switchback in LDP-IGP synchronization

• The network shown in Figure 1-1475 has active and standby links. When the active link recovers from a fault, traffic is switched from the standby link back to the active link. During the traffic switchback, the standby LSP cannot be used, and a new LSP cannot be set up over the active link once IGP route convergence is complete. This causes a traffic interruption for a short period of time. To prevent this problem, LDP-IGP synchronization can be configured to delay IGP route switchback until LDP convergence is complete. Before convergence of the active LSP completes, the standby LSP is retained, so that the traffic continues to be forwarded through the standby LSP until the active LSP is successfully established. Then the standby LSP is torn down. The detailed process is as follows:

  1. The link fault is rectified.

  2. An LDP session is set up between LSR2 and LSR3. The IGP advertises the maximum cost of the active link to delay the IGP route switchback.

  3. Traffic is still forwarded along the standby LSP.

  4. The LDP session is set up. Label messages are exchanged to notify the IGP to start synchronization.

  5. The IGP advertises the normal cost of the active link, and its routes converge to the original forwarding path. The LSP is reestablished and entries are delivered to the forwarding table (within milliseconds).

• If an LDP session between nodes fails on the active link, the LSP along the active link is deleted. However, the IGP still uses the active link, and as a result, LSP traffic cannot be switched to the standby link, and is continuously discarded. To prevent this problem, you can configure LDP-IGP synchronization. If an LDP session fails, LDP notifies an IGP of the failure. The IGP advertises the maximum cost of the failed link, which enables the route to switch from the active link to the standby link. In addition to the LSP switchover from the primary LSP to the backup LSP, LDP-IGP synchronization is implemented. The process of LDP-IGP synchronization is as follows:

  1. An LDP session between two nodes on the active link fails.

  2. LDP notifies the IGP of the failure in the session over the active link. The IGP then advertises the maximum cost along the active link.

  3. The IGP route switches to the standby link.

  4. An LSP is set up over the standby link, and then forwarding entries are delivered.

  To prevent repeated failures in LDP session reestablishment, you can use the Hold-max-cost timer to configure the device to always advertise the maximum cost, so that traffic is transmitted along the standby link before the LDP session is reestablished on the active link.

• LDP-IGP synchronization state transition mechanism

  After LDP-IGP synchronization is enabled on an interface, the IGP queries the status of the interface and LDP session according to the process shown in Figure 1-1476, enters the corresponding state according to the query result, and then transits the state according to Figure 1-1476.

  Figure 1-1476 LDP-IGP synchronization state transition
  
  
  The preceding states may slightly vary between different IGPs.

  • When OSPF is used as the IGP, the state transition is the same as that in Figure 1-1476.
  • When IS-IS is used as the IGP, the Hold-normal-cost state does not exist. After the Hold-max-cost timer expires, IS-IS advertises the normal link cost, but the Hold-max-cost state is displayed even though this state is nonexistent.

Usage Scenario

LDP-IGP synchronization applies to the following scenario:

On the network shown in Figure 1-1477, an active link and a standby link are established. LDP-IGP synchronization and LDP FRR are deployed.

Figure 1-1477 LDP-IGP synchronization scenario

Benefits

Packet loss is reduced during an active/standby link switchover, improving network reliability.

PRC

When a node in a network topology changes, the Dijkstra algorithm needs to recalculate all routes on the network. This calculation takes a long time and consumes a large number of CPU resources, which affects the convergence speed on the entire network. However, PRC uses only the nodes that have changed to recalculate routes, thereby decreasing CPU usage.

For example, if a new route is imported, the SPT of the entire network remains unchanged. In this case, PRC updates only the interface route for this node, thereby reducing the CPU usage.

OSPF Intelligent Timer

On an unstable network, routes are calculated frequently, which consumes a great number of CPU resources. In addition, link-state advertisements (LSAs) that describe the unstable topology are generated and transmitted on the unstable network. Frequently processing such LSAs affects the rapid and stable operation of the entire network.

To speed up route convergence on the entire network, the OSPF intelligent timer controls route calculation, LSA generation, and LSA receiving.

The OSPF intelligent timer works as follows:

• On a network where routes are calculated repeatedly, the OSPF intelligent timer dynamically adjusts the route calculation based on user's configuration and the exponential backoff technology. The number of route calculation times and the CPU resource consumption are decreased. Routes are calculated after the network topology stabilizes.

• On an unstable network, if a router generates or receives LSAs due to frequent topology changes, the OSPF intelligent timer can dynamically adjust the interval. No LSAs are generated or processed within an interval, which prevents invalid LSAs from being generated and advertised on the entire network.

Background

If an interface carrying OSPF services alternates between Up and Down, OSPF neighbor relationship flapping occurs on the interface. During the flapping, OSPF frequently sends Hello packets to reestablish the neighbor relationship, synchronizes LSDBs, and recalculates routes. In this process, a large number of packets are exchanged, adversely affecting neighbor relationship stability, OSPF services, and other OSPF-dependent services, such as LDP and BGP. OSPF neighbor relationship flapping suppression can address this problem by delaying OSPF neighbor relationship reestablishment or preventing service traffic from passing through flapping links.

Related Concepts

Flapping-event: reported when the status of a neighbor relationship on an interface last changes from Full to a non-Full state. The flapping-event triggers flapping detection.

Flapping-count: number of times flapping has occurred.

Detecting-interval: detection interval. The interval is used to determine whether to trigger a valid flapping_event.

Threshold: flapping suppression threshold. When the flapping_count reaches or exceeds threshold, flapping suppression takes effect.

Resume-interval: interval for exiting from OSPF neighbor relationship flapping suppression. If the interval between two successive valid flapping_events is longer than resume-interval, the flapping_count is reset.

Implementation

Flapping detection

Each OSPF interface on which OSPF neighbor relationship flapping suppression is enabled starts a flapping counter. If the interval between two successive neighbor status changes from Full to a non-Full state is shorter than detecting-interval, a valid flapping_event is recorded, and the flapping_count increases by 1. When the flapping_count reaches or exceeds threshold, flapping suppression takes effect. If the interval between two successive neighbor status changes from Full to a non-Full state is longer than resume-interval, the flapping_count is reset.

The detecting-interval, threshold, and resume-interval are configurable.

The value of resume-interval must be greater than that of detecting-interval.

Flapping suppression

Flapping suppression works in either Hold-down or Hold-max-cost mode.

• Hold-down mode: In the case of frequent flooding and topology changes during neighbor relationship establishment, interfaces prevent neighbor relationship reestablishment during Hold-down suppression, which minimizes LSDB synchronization attempts and packet exchanges.
• Hold-max-cost mode: If the traffic forwarding path changes frequently, interfaces use 65535 as the cost of the flapping link during Hold-max-cost suppression, which prevents traffic from passing through the flapping link.

Flapping suppression can also work first in Hold-down mode and then in Hold-max-cost mode.

By default, the Hold-max-cost mode takes effect. The mode and suppression duration can be changed manually.

If an attack causes frequent neighbor relationship flapping, Hold-down mode can minimize the impact of the attack.

When an interface enters the flapping suppression state, all neighbor relationships on the interface enter the state accordingly.

Exiting from flapping suppression

Interfaces exit from flapping suppression in the following scenarios:

• The suppression timer expires.
• The corresponding OSPF process is reset.
• An OSPF neighbor is reset.
• A command is run to exit from flapping suppression.

Typical Scenarios

Basic scenario

In Figure 1-1478, the traffic forwarding path is Device A -> Device B -> Device C -> Device E before a link failure occurs. After the link between Device B and Device C fails, the forwarding path switches to Device A -> Device B -> Device D -> Device E. If the neighbor relationship between Device B and Device C frequently flaps at the early stage of the path switchover, the forwarding path will be switched frequently, causing traffic loss and affecting network stability. If the neighbor relationship flapping meets suppression conditions, flapping suppression takes effect.

• If flapping suppression works in Hold-down mode, the neighbor relationship between Device B and Device C is prevented from being reestablished during the suppression period, in which traffic is forwarded along the path Device A -> Device B -> Device D -> Device E.
• If flapping suppression works in Hold-max-cost mode, 65535 is used as the cost of the link between Device B and Device C during the suppression period, and traffic is forwarded along the path Device A -> Device B -> Device D -> Device E.

Figure 1-1478 Flapping suppression in a basic scenario

Single-forwarding path scenario

When only one forwarding path exists on the network, the flapping of the neighbor relationship between any two devices on the path will interrupt traffic forwarding. In Figure 1-1479, the traffic forwarding path is Device A -> Device B -> Device C -> Device E. If the neighbor relationship between Device B and Device C flaps, and the flapping meets suppression conditions, flapping suppression takes effect. However, if the neighbor relationship between Device B and Device C is prevented from being reestablished, the whole network will be divided. Therefore, Hold-max-cost mode (rather than Hold-down mode) is recommended. If flapping suppression works in Hold-max-cost mode, 65535 is used as the cost of the link between Device B and Device C during the suppression period. After the network stabilizes and the suppression timer expires, the link is restored.

By default, the Hold-max-cost mode takes effect.

Figure 1-1479 Flapping suppression in a single-forwarding path scenario

Broadcast scenario

In Figure 1-1480, four devices are deployed on the same broadcast network using switches, and the devices are broadcast network neighbors. If Device C flaps due to a link failure, and Device A and Device B were deployed at different time (Device A was deployed earlier for example) or the flapping suppression parameters on Device A and Device B are different, Device A first detects the flapping and suppresses Device C. Consequently, the Hello packets sent by Device A do not carry Device C's router ID. However, Device B has not detected the flapping yet and still considers Device C a valid node. As a result, the DR candidates identified by Device A are Device B and Device D, whereas the DR candidates identified by Device B are Device A, Device C, and Device D. Different DR candidates result in a different DR election result, which may lead to route calculation errors. To prevent this problem in scenarios where an interface has multiple neighbors, such as on a broadcast, P2MP, or NBMA network, all neighbors on the interface are suppressed when the status of a neighbor relationship last changes to ExStart or Down. Specifically, if Device C flaps, Device A, Device B, and Device D on the broadcast network are all suppressed. After the network stabilizes and the suppression timer expires, Device A, Device B, and Device D are restored to normal status.

Figure 1-1480 Flapping suppression on a broadcast network

Multi-area scenario

In Figure 1-1481, Device A, Device B, Device C, Device E, and Device F are connected in area 1, and Device B, Device D, and Device E are connected in backbone area 0. Traffic from Device A to Device F is preferentially forwarded along an intra-area route, and the forwarding path is Device A -> Device B -> Device C -> Device E -> Device F. When the neighbor relationship between Device B and Device C flaps and the flapping meets suppression conditions, flapping suppression takes effect in the default mode (Hold-max-cost). Consequently, 65535 is used as the cost of the link between Device B and Device C. However, the forwarding path remains unchanged because intra-area routes take precedence over inter-area routes during route selection according to OSPF route selection rules. To prevent traffic loss in multi-area scenarios, configure Hold-down mode to prevent the neighbor relationship between Device B and Device C from being reestablished during the suppression period. During this period, traffic is forwarded along the path Device A -> Device B -> Device D -> Device E -> Device F.

By default, the Hold-max-cost mode takes effect. The mode can be changed to Hold-down manually.

Figure 1-1481 Flapping suppression in a multi-area scenario

Scenario with both LDP-IGP synchronization and OSPF neighbor relationship flapping suppression configured

In Figure 1-1482, if the link between PE1 and P1 fails, an LDP LSP switchover is implemented immediately, causing the original LDP LSP to be deleted before a new LDP LSP is established. To prevent traffic loss, LDP-IGP synchronization needs to be configured. With LDP-IGP synchronization, 65535 is used as the cost of the new LSP to be established. After the new LSP is established, the original cost takes effect. Consequently, the original LSP is deleted, and LDP traffic is forwarded along the new LSP.

LDP-IGP synchronization and OSPF neighbor relationship flapping suppression work in either Hold-down or Hold-max-cost mode. If both functions are configured, Hold-down mode takes precedence over Hold-max-cost mode, followed by the configured link cost. Table 1-606 lists the suppression modes that take effect in different situations.

For example, the link between PE1 and P1 frequently flaps in Figure 1-1482, and both LDP-IGP synchronization and OSPF neighbor relationship flapping suppression are configured. In this case, the suppression mode is selected based on the preceding principles. No matter which mode (Hold-down or Hold-max-cost) is selected, the forwarding path is PE1 -> P4 -> P3 -> PE2.

Figure 1-1482 Scenario with both LDP-IGP synchronization and OSPF neighbor relationship flapping suppression configured

Scenario with both bit-error-triggered protection switching and OSPF neighbor relationship flapping suppression configured

If a link has poor link quality, services transmitted along it may be adversely affected. If bit-error-triggered protection switching is configured and the bit error rate (BER) along a link exceeds a specified value, a bit error event is reported, and 65535 is used as the cost of the link, triggering route reselection. Consequently, service traffic is switched to the backup link. If both bit-error-triggered protection switching and OSPF neighbor relationship flapping suppression are configured, they both take effect. Hold-down mode takes precedence over Hold-max-cost mode, followed by the configured link cost.

Context

If network-wide OSPF LSA flush causes network instability, source tracing must be implemented as soon as possible to locate and isolate the fault source. However, OSPF itself does not support source tracing. A conventional solution is to isolate nodes one by one until the fault source is located, but the process is complex and time-consuming and may compromise network services. To solve the preceding problem, OSPF introduces a proprietary protocol, namely, the source tracing protocol. This protocol supports the flooding of flush source information. When the preceding problem occurs, you can quickly query the flush source information on any device on the network to quickly locate the fault source.

Related Concepts

Source tracing

Flush

Network-wide OSPF LSAs are deleted.

PS-Hello packets

Packets used to negotiate the OSPF flush source tracing capability between OSPF neighbors.

PS-LSA

When a device flushes an OSPF LSA, it generates a PS-LSA carrying information about the device and brief information about the OSPF LSA.

PS-LSU packets

OSPF flush LSA source tracing packets that carry PS-LSAs.

PS-LSU ACK packets

Acknowledgment packets used to improve OSPF flush source tracing packets.

OSPF flush source tracing port

ID of the UDP port that receives and sends OSPF flush source tracing packets. The default port ID is 50133, which is configurable.

Fundamentals

The implementation of OSPF flush source tracing is as follows:

1. Source tracing capability negotiation

   After an OSPF neighbor relationship is established between two devices, they need to negotiate the source tracing capability through PS-Hello packets.

2. PS-LSA generation and flooding

   When a device flushes an OSPF LSA, it generates a PS-LSA carrying information about the device and brief information about the OSPF LSA, adds the PS-LSA to a PS-LSU packet, and floods the PS-LSU packet to source tracing-capable neighbors, which helps other devices locate the fault source and perform isolation.

Only router-LSAs, network-LSAs, and inter-area-router-LSAs can be flushed. Therefore, a device generates a PS-LSA only when it flushes a router-LSA, network-LSA, or inter-area-router-LSA.

Source tracing capability negotiation

The source tracing protocol uses UDP to carry source tracing packets and listens to the UDP port, which is used to receive and send source tracing packets. If a source tracing-capable Huawei device sends source tracing packets to a source tracing-incapable Huawei device or non-Huawei device, the source tracing-capable Huawei device may be incorrectly identified as an attacker. Therefore, the source tracing capability needs to be negotiated between the devices. In addition, the source tracing-capable device needs to send source tracing information on behalf of the source tracing-incapable device, which also requires negotiation.

Source tracing capability negotiation depends on OSPF neighbor relationships. Specifically, after an OSPF neighbor relationship is established, the local device initiates source tracing capability negotiation. Figure 1-1483 shows the negotiation process.

Figure 1-1483 Source tracing capability negotiation

PS-LSA generation and flooding

Figure 1-1484 PS-LSA generation rules

PS-LSA generation rules

• When DeviceA flushes a router-LSA, network-LSA, or inter-area-router-LSA, it generates a PS-LSA in which the Flush Router field is its router ID and the Neighbor Router field is 0, and adds the PS-LSA to the queue where packets are to be sent to all source tracing-capable neighbors.
• After DeviceA receives the flush LSA from source tracing-incapable DeviceB, DeviceA generates a PS-LSA in which the Flush Router field is its router ID and the Neighbor Router field is the router ID of DeviceB, and adds the PS-LSA to the queue where packets are to be sent to all source tracing-capable neighbors.
• After DeviceA receives the flush LSA from DeviceB, followed by the same flush LSA sent by DeviceC, DeviceA generates a PS-LSA in which the Flush Router field is its router ID and the Neighbor Router field is the router ID of DeviceB, and adds the PS-LSA to the queue where packets are to be sent to all source tracing-capable neighbors. No PS-LSA is generated in response to the flush LSA received from DeviceC.

PS-LSU packet sending rules

• During neighbor relationship establishment, a device initializes the sequence number of the PS-LSU packet of the neighbor. When the device replies with a PS-LSU packet, it adds the sequence number of the PS-LSU packet of the neighbor. During PS-LSU packet retransmission, the sequence number remains unchanged. After the device receives a PS-LSU ACK packet with the same sequence number, it increases the sequence number of the neighbor's PS-LSU packet by 1.
• The neighbor manages the PS-LSA sending queue. When a PS-LSA is added to the queue which was empty, the neighbor starts a timer. After the timer expires, the neighbor adds the PS-LSA to a PS-LSU packet, sends the packet to its neighbor, and starts another timer to wait for a PS-LSU ACK packet.
• After the PS-LSU ACK timer expires, the PS-LSU packet is retransmitted.
• When the device receives a PS-LSU ACK packet with a sequence number same as that in the neighbor record, the device clears PS-LSAs from the neighbor queue, and sends another PS-LSU packet after the timer expires.
  • If the sequence number of a received PS-LSU ACK packet is less than that in the neighbor record, the device ignores the packet.
  • If the sequence number of a received PS-LSU ACK packet is greater than that in the neighbor record, the device discards the packet.

PS-LSU packet sending is independent among neighbors.

PS-LSU packet receiving rules

• When a device receives a PS-LSU packet from a neighbor, the neighbor records the sequence number of the packet and replies with a PS-LSU ACK packet.
• When the device receives a PS-LSU packet with the sequence number the same as that in the neighbor record, the device discards the PS-LSU packet.
• After the device parses a PS-LSU packet, it adds the PS-LSA in the packet to its LSDB. The device also checks whether the PS-LSA is newer than the corresponding PS-LSA in its LSDB.
  • If the received PS-LSA is newer, the device floods it to other neighbors.
  • If the received PS-LSA is the same as the corresponding local one, the device does not process the received PS-LSA.
  • If the received PS-LSA is older, the device floods the corresponding local one to the neighbor.
• If the device receives a PS-LSU packet from a neighbor and the neighbor does not support source tracing, the device modifies the neighbor status as source tracing capable.

Source Tracing Security

The source tracing protocol uses a UDP port to receive and send source tracing packets. Therefore, the security of the port must be taken into consideration.

The source tracing protocol inevitably increases packet receiving and sending workload and intensifies bandwidth pressure. To minimize its impact on other protocols, the number of source tracing packets must be controlled.

The following security measures are available:

Typical Scenarios

Scenario where all nodes support source tracing

All nodes on the network support source tracing, and DeviceA is the faulty source. Figure 1-1485 shows the networking.

Figure 1-1485 Scenario where all nodes support source tracing

When DeviceA flushes an OSPF LSA, it generates a PS-LSA that carries DeviceA information and brief information about the flush LSA and floods it. After the fault occurs, maintenance personnel can log in to any node on the network to locate DeviceA, which keeps sending flush LSAs, and isolate DeviceA from the network.

Scenario where source tracing-incapable nodes are not isolated from source tracing-capable nodes

All nodes on the network except DeviceC support source tracing, and DeviceA is the fault source. In this case, the PS-LSA can be flooded on the entire network, and the fault source can be accurately located. Figure 1-1486 shows the networking.

Figure 1-1486 Scenario where source tracing-incapable nodes are not isolated from source tracing-capable nodes

When DeviceA flushes an OSPF LSA, it generates a PS-LSA that carries DeviceA information and brief information about the flush LSA and floods it. When DeviceB and DeviceE negotiate the source tracing capability with DeviceC, they find that DeviceC does not support source tracing. Therefore, after DeviceB receives the PS-LSA from DeviceA, DeviceB sends the PS-LSA to DeviceD, but not to DeviceC. After receiving the flush LSA from DeviceC, DeviceE generates a PS-LSA that carries information about the advertisement source (DeviceE), flush source (DeviceC), and the OSPF flush LSA, and floods the PS-LSA on the network.

After the fault occurs, maintenance personnel can log in to any device on the network except DeviceC to locate the faulty node. Two possible faulty nodes can be located in this case: DeviceA and DeviceC, and they both send the same flush LSA. In this case, DeviceA takes precedence over DeviceC when the maintenance personnel determine the most possible faulty source. After DeviceA is isolated, the network recovers.

Scenario where source tracing-incapable nodes are isolated from source tracing-capable nodes

All nodes on the network except DeviceC and DeviceD support source tracing, and DeviceA is the fault source. In this case, the PS-LSA cannot be flooded on the entire network. Figure 1-1487 shows the networking.

Figure 1-1487 Scenario where source tracing-incapable nodes are isolated from source tracing-capable nodes

When DeviceA flushes an OSPF LSA, it generates a PS-LSA that carries DeviceA information and brief information about the flush LSA and floods it. However, the PS-LSA sent by DeviceA can reach only DeviceB because DeviceC and DeviceD do not support source tracing.

During source tracing capability negotiation, DeviceE finds that DeviceC does not support source tracing, and DeviceF finds that DeviceD does not support source tracing. After DeviceE receives the flush LSA from DeviceC, DeviceE generates and floods a PS-LSA on behalf of DeviceC. Similarly, after DeviceF receives the flush LSA from DeviceD, DeviceF generates and floods a PS-LSA on behalf of DeviceD.

Background

In OSPF, intra-area links take precedence over inter-area links during route selection even when the inter-area links are shorter than the intra-area links. Each OSPF interface belongs to only one area. As a result, even when a high-speed link exists in an area, traffic of another area cannot be forwarded along the link. A common method used to solve this problem is to configure multiple sub-interfaces and add them to different areas. However, this method has a defect that an independent IP address needs to be configured for each sub-interface and then is advertised, which increases the total number of routes. In this situation, OSPF multi-area adjacency is introduced.

OSPF multi-area adjacency allows an OSPF interface to be multiplexed by multiple areas so that a link can be shared by the areas.

Figure 1-1488 Traffic forwarding paths before and after OSPF multi-area adjacency is enabled

In Figure 1-1488, the link between Device A and Device B in area 1 is a high-speed link.

In Figure 1-1488 a, OSPF multi-area adjacency is disabled on Device A and Device B, and traffic from Device A to Device B in area 2 is forwarded along the low-speed link of Device A -> Device C -> Device D -> Device B.

In Figure 1-1488 b, OSPF multi-area adjacency is enabled on Device A and Device B, and their multi-area adjacency interfaces belong to area 2. In this case, traffic from Device A to Device B in area 2 is forwarded along the high-speed link of Device A -> Device B.

Related Concepts

Multi-area adjacency interface: indicates the OSPF logical interface created when OSPF multi-area adjacency is enabled on an OSPF-capable interface (main OSPF interface). The multi-area adjacency interface is also referred to as a secondary OSPF interface. The multi-area adjacency interface has the following characteristics:

Principles

Figure 1-1489 Networking for OSPF multi-area adjacency

In Figure 1-1489, the link between Device A and Device B in area 1 is a high-speed link. In area 2, traffic from Device A to Device B is forwarded along the low-speed link of Device A -> Device C -> Device D -> Device B. If you want the traffic from Device A to Device B in area 2 to be forwarded along the high-speed link of Device A -> Device B, deploy OSPF multi-area adjacency.

The optimal path in area 2 obtained by OSPF through calculation is the high-speed link of Device A -> Device B. In this case, the high-speed link is shared by area 1 and area 2.

Background

As networks develop, voice over IP (VoIP) and online video services pose higher requirements for real-time transmission. Nevertheless, if a primary link fails, OSPF-enabled devices need to perform multiple operations, including detecting the fault, updating the link-state advertisement (LSA), flooding the LSA, calculating routes, and delivering forward information base (FIB) entries before switching traffic to a new link. This process takes a much longer time, the minimum delay to which users are sensitive. As a result, the requirements for real-time transmission cannot be met. OSPF IP FRR can solve this problem. OSPF IP FRR conforms to dynamic IP FRR defined by standard protocols. With OSPF IP FRR, devices can switch traffic from a faulty primary link to a backup link, protecting against a link or node failure.

Major FRR techniques include loop-free alternate (LFA), U-turn, Not-Via, Remote LFA, and MRT, among which OSPF supports only LFA and Remote LFA.

Related Concepts

OSPF IP FRR

OSPF IP FRR refers to a mechanism in which a device uses the loop-free alternate (LFA) algorithm to compute the next hop of a backup link and stores the next hop together with the primary link in the forwarding table. If the primary link fails, the device switches the traffic to the backup link before routes are converged on the control plane. This mechanism keeps the traffic interruption duration and minimizes the impacts.

OSPF IP FRR policy

An OSPF IP FRR policy can be configured to filter alternate next hops. Only the alternate next hops that match the filtering rules of the policy can be added to the IP routing table.

LFA algorithm

A device uses the shortest path first (SPF) algorithm to calculate the shortest path from each neighbor with a backup link to the destination node. The device then uses the inequalities defined in standard protocols and the LFA algorithm to calculate the next hop of the loop-free backup link that has the smallest cost of the available shortest paths.

Remote LFA

LFA FRR cannot be used to calculate alternate links on large-scale networks, especially on ring networks. Remote LFA FRR addresses this problem by calculating a PQ node and establishing a tunnel between the source node of a primary link and the PQ node. If the primary link fails, traffic can be automatically switched to the tunnel, which improves network reliability.

P space

Remote LFA uses the source end of a protection link as the root node and calculates an SPT to all the other nodes on the network (with the protection link calculated in the tree). Then Remote LFA removes all the nodes along the protection link from the SPT, and the set of the remaining nodes is called a P space.

Extended P space

Remote LFA uses neighbors of the source end of a protection link as root nodes and calculates separate SPTs (with the protection link calculated in the trees). Then Remote LFA removes all the nodes along the protection link from each SPT, and the set of the remaining nodes on the SPTs is called an extended P space.

Q space

Remote LFA uses the destination end of a protection link as the root node and calculates an SPT to all the other nodes on the network (with the protection link calculated in the tree). Then Remote LFA removes all the nodes along the protection link from the SPT, and the set of the remaining nodes is called a Q space.

PQ node

A PQ node exists both in the extended P space and Q space and is used by Remote LFA as the destination of a protection tunnel.

OSPF LFA FRR

OSPF LFA FRR protects traffic against either a link failure or a node-and-link failure. The node-and-link protection takes precedence over the link protection.

Link protection

Link protection takes effect when the traffic to be protected flows along a specified link.

In Figure 1-1490, traffic flows from Device S to Device D. The primary link is Device S->Device E->Device D, and the backup link is Device S->Device N->Device E->Device D. If link costs meet the inequality: Distance_opt(N, D) < Distance_opt(N, S) + Distance_opt(S, D) and OSPF IP FRR is enabled, Device S switches the traffic to the backup link if the primary link fails, reducing the traffic interruption duration.

Distance_opt(X, Y) indicates the shortest link from X to Y. S stands for a source node, E for the faulty node, N for a node along a backup link, and D for a destination node.

Figure 1-1490 OSPF IP FRR link protection

Node-and-link protection

Node-and-link protection takes effect when the traffic to be protected.

In Figure 1-1491, traffic flows from Device S to Device D. The primary link is Device S->Device E->Device D, and the backup link is Device S->Device N->Device D. The preceding inequalities are met. With OSPF IP FRR, Device S switches the traffic to the backup link if the primary link fails, reducing the traffic interruption duration.

Node-and-link protection takes effect when the following conditions are met:

• The link costs meet the inequality: Distance_opt(N, D) < Distance_opt(N, S) + Distance_opt(S, D).
• The interface costs meet the inequality: Distance_opt(N, D) < Distance_opt(N, E) + Distance_opt(E, D).

Distance_opt(X, Y) indicates the shortest link from X to Y. S stands for a source node, E for the faulty node, N for a node along a backup link, and D for a destination node.

Figure 1-1491 OSPF IP FRR node-and-link protection

OSPF Remote LFA FRR

Similar to OSPF LFA FRR, remote LFA is also classified as link protection or node-and-link protection. The following example shows how remote LFA works to protect against link failures:

In Figure 1-1492, traffic flows through PE1 -> P1 -> P2 -> PE2, and the primary link is between P1 and P2. Remote LFA calculates a PQ node (P4) and establishes an LDP between P1 and P4. If P1 detects a failure on the primary link, P1 encapsulates packets into MPLS packets and forwards MPLS packets to P4. After receiving the packets, P4 removes the MPLS label from them and searches the IP routing table for a next hop to forward the packets to PE2. Remote LFA ensures uninterrupted traffic forwarding.

Figure 1-1492 Networking for Remote LFA

OSPF microloop avoidance

In Figure 1-1492, OSPF remote LFA FRR is enabled, the primary link is PE1 -> P1 -> P2 -> PE2, and the backup link is PE1 -> P1 -> P3 -> P4 -> P2 -> PE2, and the link P1 -> P3 -> P4 is an LDP tunnel. If the primary link fails, traffic is switched to the backup link, and then another round of the new primary link calculation begins. Specifically, after P1 completes route convergence, its next hop becomes P3. However, the route convergence on P3 is slower than that on P1, and P3's next hop is still P1. As a result, a temporary loop occurs between P1 and P3. OSPF microloop avoidance can address this problem by delaying P1 from switching its next hop until the next hop of P3 becomes P4. Then traffic is switched to the new primary link (PE1 -> P1 -> P3 -> P4 -> P2 -> PE2), and on the link P1 -> P3 -> P4, traffic is forwarded based on IP routes.

OSPF microloop avoidance applies only to OSPF remote LFA FRR.

OSPF FRR in the Scenario Where Multiple Nodes Advertise the Same Route

The SPF algorithm is used by OSPF LFA FRR and OSPF Remote LFA FRR to calculate the shortest path from each neighbor (root node) that provides a backup link to the destination node. The calculation result is a node-based backup next hop. This applies to the scenarios where a route is advertised by a single node. As networks are increasingly diversified, two ABRs or ASBRs are deployed to improve network reliability. In this case, OSPF FRR in a scenario where multiple nodes advertise the same route is introduced.

In a scenario where multiple nodes advertise the same route, OSPF FRR is implemented by calculating the Type 3 LSAs advertised by ABRs of an area for intra-area, inter-area, ASE, or NSSA routes. Therefore, the OSPF FRR calculation methods are the same when multiple nodes advertise the same route. Inter-area routing is used as an example to describe how FRR in a multi-node routing scenario works.

Figure 1-1493 OSPF FRR in the scenario where multiple nodes advertise the same route

In Figure 1-1493, Device B and Device C function as ABRs to forward routes between area 0 and area 1. Device E advertises an intra-area route. Upon receipt of the route, Device B and Device C translate it into a Type 3 LSA and flood the LSA to area 0. After OSPF FRR is enabled on Device A, Device A considers both Device B and Device C as its neighbors. Without a fixed neighbor as the root node, Device A fails to calculate the FRR backup next hop. To address this problem, a virtual node is simulated between Device B and Device C, converting the scenario where multiple nodes advertise the same route into the scenario where the route is received from only one node. Then the backup next hop of the virtual node is calculated based on LFA and Remote LFA. Then the route advertised by multiple nodes inherits the backup next hop from the virtual node.

For example, Device B and Device C advertise a route with prefix 10.1.1.0/24, and OSPF FRR is enabled on Device A. Device A cannot calculate a backup next hop for the route 10.1.1.0/24 because this route has two sources (Device B and Device C). To address this problem, a virtual node is simulated between Device B and Device C based on the two sources of the route 10.1.1.0/24. The virtual node forms a link with each of Device B and Device C. If the virtual node advertises a 10.1.1.0/24 route, it will use the smaller cost of the routes advertised by Device B and Device C as the cost of the route. If the cost of the route advertised by Device B is 5 and that of the route advertised by Device C is 10, the cost of the route advertised by the virtual node is 5. The cost of the link from Device B to the virtual node is 0, and that of the link from Device C to the virtual node is 5. The costs of the links from the virtual node to Device B and Device C are both 65535, the maximum value. Device A is configured to consider Device B and Device C as invalid sources of the 10.1.1.0/24 route and use the LFA or remote LFA algorithm to calculate the backup next hop for the route, with the virtual node as the root node.

In a scenario where multiple nodes advertise the same route, OSPF FRR can use the LFA or remote LFA algorithm. When OSPF FRR uses the remote LFA algorithm, PQ node selection has the following restrictions:

• An LDP tunnel will be established between a faulty node and a PQ node, and a virtual node in the scenario where multiple nodes advertise the same route cannot transmit traffic through LDP tunnels. As a result, the virtual node cannot be selected as a PQ node.
• The destination node of Remote LFA is not selected as a PQ node. After a virtual node is added in a scenario where multiple nodes advertise the same route, the destination node becomes a virtual node. Therefore, a node directly connected to the virtual node cannot be selected as a PQ node.

OSPF SRLG FRR

A shared risk link group (SRLG) is a set of links that share a common physical resource (such as a fiber). These links share the same risk level. If one of the links fails, all the other links in the SRLG may also fail.

On the network shown in Figure 1-1494, traffic is forwarded from Device A to Device E. There are three links between Device A and Device E: Link1, Link2, and Link3. The cost of Link1 is the smallest, and the costs of Link2 and Link3 are the same. Therefore, Link1 is the primary link for traffic forwarding.

OSPF SRLG FRR can be configured in the scenario where some links have the same risk of failure. If Link1 and Link2 have the same risk of failure, you can add them to an SRLG and configure OSPF SRLG FRR so that a link outside the SRLG is preferentially selected as a backup link, which reduces the possibility of service interruptions. After Link1 and Link2 are added to the same SRLG, OSPF LFA IP FRR selects Link3, which is not in the SRLG, as the backup link to provide protection for Link1. If both Link1 and Link2 fail, traffic can be switched to Link3 for normal transmission.

Figure 1-1494 Networking diagram of OSPF SRLG FRR

Derivative Functions

If you bind a Bidirectional Forwarding Detection (BFD) session with OSPF IP FRR, the BFD session goes down if BFD detects a link fault. If the BFD session goes down, OSPF IP FRR is triggered to switch traffic from the faulty link to the backup link, which minimizes the loss of traffic.

Usage Scenario

Figure 1-1495 OSPF authentication on a broadcast network

The configuration requirements are as follows:

• The interface authentication configurations must be the same on all devices on the same network so that OSPF neighbor relationships can be established.

• The area authentication configurations must be the same on all devices in the same area.

Packet Header Format

The five types of OSPF packets have the same packet header format. The length of an OSPF packet header is 24 bytes. Figure 1-1496 shows an OSPF packet header.

Figure 1-1496 Packet header format

MD5 authentication data is added to an OSPF packet and is not included in the Authentication field.

Hello Packet

Hello packets are commonly used packets, which are periodically sent by OSPF interfaces to establish and maintain neighbor relationships. A Hello packet includes information about the designated router (DR), backup designated router (BDR), timers, and known neighbors. Figure 1-1497 shows the format of a Hello packet.

Figure 1-1497 Format of a Hello packet

Table 1-611 lists the address types, interval types, and default intervals used when Hello packets are transmitted on different networks.

Routers on the same network segment must have the same HelloInterval and RouterDeadInterval values. Otherwise, they cannot establish neighbor relationships. In addition, on an NBMA network, the PollInterval values must be the same at both ends.

DD Packet

During an adjacency initialization, two routers use DD packets to describe their own link state databases (LSDBs) for LSDB synchronization. A DD packet contains the header of each LSA in an LSDB. An LSA header uniquely identifies an LSA. The LSA header occupies only a small portion of the LSA, which reduces the amount of traffic transmitted between routers. A neighbor can use the LSA header to check whether it already has the LSA. When two routers exchange DD packets, one functions as the master, and the other functions as the slave. The master defines a start sequence number and increases the sequence number by one each time it sends a DD packet. After the slave receives a DD packet, it uses the sequence number carried in the DD packet for acknowledgment.

Figure 1-1498 shows the format of a DD packet.

Figure 1-1498 Format of a DD packet

LSR Packet

After two routers exchange DD packets, they send LSR packets to request LSAs from each other. The LSR packets contain the summaries of the requested LSAs. Figure 1-1499 shows the format of an LSR packet.

Figure 1-1499 Format of an LSR packet

The LS type, Link State ID, and Advertising Router fields can uniquely identify an LSA. If the preceding fields of two LSAs are the same, the device uses the LS sequence number, LS checksum, and LS age fields to determine which LSA is newer.

LSU Packet

A router uses an LSU packet to transmit LSAs requested by its neighbors or to flood its own updated LSAs. The LSU packet contains a set of LSAs. On networks that support multicast and broadcast, LSU packets are multicast to flood LSAs. To ensure reliable LSA flooding, a device uses an LSAck packet to acknowledge the LSAs contained in an LSU packet that is received from a neighbor. If an LSA fails to be acknowledged, the LSA is directly retransmitted to the neighbor. Figure 1-1500 shows the format of an LSU packet.

Figure 1-1500 Format of an LSU packet

LSAck Packet

A device uses an LSAck packet to acknowledge the headers of the LSAs contained in a received LSU packet. LSAck packets are transmitted in unicast or multicast mode according to the link type. Figure 1-1501 shows the format of an LSAck packet.

Figure 1-1501 Format of an LSAck packet

LSA Header Format

All LSAs have the same header. Figure 1-1502 shows an LSA header.

Figure 1-1502 LSA header

Router-LSA

A router-LSA describes the link status and cost of a router. Router-LSAs are generated by a router and advertised within the area to which the router belongs. Figure 1-1503 shows the format of a router-LSA.

Figure 1-1503 Format of a router-LSA

Network-LSA

A network-LSA describes the link status of all routers on the local network segment. Network-LSAs are generated by a DR on a broadcast or non-broadcast multiple access (NBMA) network and advertised within the area to which the DR belongs. Figure 1-1504 shows the format of a network-LSA.

Figure 1-1504 Format of a network-LSA

Summary-LSA

A network-summary-LSA describes routes on a network segment in an area. The routes are advertised to other areas.

An ASBR-summary-LSA describes routes to the ASBR in an area. The routes are advertised to all areas except the area to which the ASBR belongs.

The two types of summary-LSAs have the same format and are generated by an ABR. Figure 1-1505 shows the format of a summary-LSA.

Figure 1-1505 Format of a summary-LSA

When a default route is advertised, both the Link State ID and Network Mask fields are set to 0.0.0.0.

Table 1-620 describes ASBR-summary-LSA fields.

AS-External-LSA

An AS-external-LSA describes AS external routes. AS-external-LSAs are generated by an ASBR. Among the five types of LSAs, only AS-external-LSAs can be advertised to all areas except stub areas and not-so-stubby areas (NSSAs). Figure 1-1506 shows the format of an AS-external-LSA.

Figure 1-1506 Format of an AS-external-LSA

When AS-external-LSAs are used to advertise default routes, both the Link State ID and Network Mask fields are set to 0.0.0.0.

Related Concepts

Redistribute ID

IS-IS uses a system ID as a redistribution identifier, OSPF and OSPFv3 use a router ID + process ID as a redistribution identifier, and BGP uses a VrfID + random number as a redistribution identifier. For ease of understanding, the redistribution identifiers of different protocols are all called Redistribute IDs. When routes are distributed, the information carried in the routes contains Redistribute IDs.

Redistribute List

A Redistribute list may consist of multiple Redistribute IDs. Each Redistribute list of BGP contains a maximum of four Redistribute IDs, and each Redistribute list of any other routing protocol contains a maximum of two Redistribute IDs. When the number of Redistribute IDs exceeds the corresponding limit, the old ones are discarded according to the sequence in which Redistribute IDs are added.

Cause (OSPF Inter-Process Mutual Route Import)

In Figure 1-1507, DeviceA, DeviceB, and DeviceC run OSPF process 1; DeviceF and DeviceG run OSPF process 2; DeviceD and DeviceE run both of the processes. Route import between OSPF process 1 and OSPF process 2 is configured on DeviceD and DeviceE. The routes distributed by OSPF process 1 on DeviceE are re-distributed back to OSPF process 1 on DeviceD through OSPF process 2. As the costs of the routes newly distributed by DeviceD are smaller, they are preferentially selected by OSPF process 1, resulting in routing loops.

Figure 1-1507 Typical network diagram of OSPF inter-process mutual route import

Take the route distributed by DeviceA as an example. A stable routing loop is formed through the following process:

Phase 1

On the network shown in Figure 1-1508, OSPF process 1 on DeviceA imports the static route 10.0.0.1 and floods a Type 5 AS-External-LSA in OSPF process 1. After receiving the LSA, OSPF process 1 on DeviceD and OSPF process 1 on DeviceE each calculate a route to 10.0.0.1, with the outbound interfaces being interface1 on DeviceD and interface1 on DeviceE, respectively, and the cost being 102. At this point, the routes to 10.0.0.1 in OSPF process 1 in the routing tables of DeviceD and DeviceE are active.

Figure 1-1508 Phase 1

Phase 2

In Figure 1-1509, DeviceD and DeviceE are configured to import routes from OSPF process 1 to OSPF process 2. No route-policy is configured for the import, or the configured route-policy is improper. For example, OSPF process 2 on DeviceE imports routes from OSPF process 1 and then floods a Type 5 AS-External-LSA in OSPF process 2. After receiving the LSA, OSPF process 2 on DeviceD calculates a route to 10.0.0.1, with the cost being 2, which is smaller than that (102) of the route calculated by OSPF process 1. As a result, the active route to 10.0.0.1 in the routing table of DeviceD is switched from the one calculated by OSPF process 1 to the one calculated by OSPF process 2, and the outbound interface of the route is sub-interface2.1.

Figure 1-1509 Phase 2

Phase 3

In Figure 1-1510, DeviceD imports the route from OSPF process 2 to OSPF process 1 and floods a Type 5 AS-External LSA in OSPF process 1. After receiving the LSA, OSPF process 1 on DeviceE recalculates the route to 10.0.0.1. The cost of the route becomes 2, which is smaller than that of the previously calculated route. Therefore, the route to 10.0.0.1 in OSPF process 1 on DeviceE is changed to the route distributed by DeviceD, and the outbound interface is interface 2.

Figure 1-1510 Phase 3

Phase 4

After the route to 10.0.0.1 on DeviceE is updated, OSPF process 2 still imports the route from OSPF process 1 as the route remains active, and continues to distribute/update a Type 5 AS-External-LSA.

As a result, a stable routing loop is formed. Assuming that traffic is injected from DeviceF, Figure 1-1511 shows the traffic flow when the routing loop occurs.

Figure 1-1511 Traffic flow when a routing loop occurs

Implementation (OSPF Inter-Process Mutual Route Import)

Routing loop detection for the routes imported between OSPF processes can resolve the routing loops in the preceding scenario.

When distributing a Type 5 AS-External-LSA for an imported route, OSPF also uses a Type 11 extended prefix Opaque LSA to distribute to other devices the Redistribute ID of the device that redistributes the imported route. If the route is redistributed by different protocols through multiple devices, the Redistribute IDs of these protocols on the devices are distributed through a Type 11 extended prefix Opaque LSA. When receiving the Type 11 extended prefix Opaque LSA, a route calculation device saves the Redistribute ID and route information of the route redistribution device. When another process imports the route, the device checks whether a routing loop occurs according to the route redistribution information. If a routing loop occurs, the device attaches a large route cost to the AS-External-LSA for the imported route. This prevents other devices from selecting the route distributed by the local device, thereby resolving the routing loop.

Figure 1-1512 Typical networking of route import to OSPF

Figure 1-1512 is used to describe how a routing loop is detected and resolved.

1. DeviceA distributes its locally originated route 10.0.0.1/24 to DeviceB.
2. DeviceD learns the route distributed by DeviceB through OSPF process 1 and imports the route from OSPF process 1 to OSPF process 2. DeviceE learns the route distributed by DeviceD through OSPF process 2 and saves the Redistribute List distributed by DeviceD through OSPF process 2 to the routing table when calculating routes.
3. DeviceE imports the route from OSPF process 2 to OSPF process 1 and redistributes the route through OSPF process 1. The corresponding Type 11 extended prefix Opaque LSA contains the Redistribute ID of OSPF process 1 on DeviceE and the Redistribute ID of OSPF process 2 on DeviceD. The Redistribute ID of OSPF process 1 on DeviceB has been discarded from the LSA.
4. OSPF process 1 on DeviceD learns the Redistribute list corresponding to the route distributed by DeviceE and saves the Redistribute list in the routing table. When importing the route from OSPF process 1 to OSPF process 2, DeviceD finds that the Redistribute list of the route contains its own Redistribute ID, considers that a routing loop is detected, and reports an alarm. OSPF process 2 on DeviceD distributes a large cost when redistributing the route so that other devices preferentially select other paths after learning the route. This prevents routing loops.

   When detecting a routing loop upon route import between processes of the same protocol, the device increases the cost of the corresponding route. As the cost of the delivered route increases, the optimal route in the IP routing table changes. In this way, the routing loop is eliminated.

   In the case of inter-protocol route import, if a routing protocol with a higher preference detects a routing loop, although this protocol increases the cost of the corresponding route, the cost increase will not render the route inactive. As a result, the routing loop cannot be eliminated. If the routing protocol with a lower preference increases the cost of the corresponding route, this route competes with the originally imported route during route selection. In this case, the routing loop can be eliminated.

Cause (Mutual Route Import Between OSPF and IS-IS)

On the network shown in Figure 1-1513, DeviceA, DeviceB, and DeviceC run OSPF process 1, DeviceF and DeviceG run IS-IS process 2, and DeviceD and DeviceE run both processes. Route import between OSPF process 1 and IS-IS process 2 is configured on DeviceD and DeviceE. The routes distributed by OSPF process 1 on DeviceE are re-distributed back to OSPF process 1 on DeviceD through IS-IS process 2. As the costs of the routes newly distributed by DeviceD are smaller, they are preferentially selected by OSPF process 1, resulting in routing loops.

Figure 1-1513 Traffic flow when a routing loop occurs during route import between OSPF and IS-IS

Implementation (Mutual Route Import Between OSPF and IS-IS)

The following uses the networking shown in Figure 1-1513 as an example to describe how a routing loop is detected and resolved.

1. DeviceD learns the route distributed by DeviceB through OSPF process 1 and imports the route from OSPF process 1 to IS-IS process 2. When IS-IS process 2 on DeviceD distributes route information, it uses the extended prefix sub-TLV to distribute the Redistribute ID of IS-IS process 2 through an LSP. IS-IS process 2 on DeviceE learns the route distributed by DeviceD and saves the Redistribute ID distributed by IS-IS process 2 on DeviceD to the routing table during route calculation.
2. DeviceE imports the route from IS-IS process 2 to OSPF process 1 and uses an E-AS-External-LSA to distribute the Redistribute ID of OSPF process 1 on DeviceE when distributing route information. Similarly, after OSPF process 1 on DeviceD learns the route from DeviceE, DeviceD saves the Redistribute ID distributed by OSPF process 1 on DeviceE to the routing table during route calculation.
3. When importing the route from OSPF process 1 to IS-IS process 2, DeviceD finds that the Redistribute list of the route contains its own Redistribute ID, considers that a routing loop is detected, and reports an alarm. IS-IS process 2 on DeviceD distributes a large cost when distributing the imported route. Because IS-IS has a higher preference than OSPF ASE, this does not affect the route selection result or resolve the routing loop.
4. DeviceE imports the route from IS-IS process 2 to OSPF process 1, finds that the Redistribute list of the route contains its own Redistribute ID, considers that a routing loop is detected, and reports an alarm. OSPF process 1 on DeviceE distributes a large cost when distributing the imported route so that other devices preferentially select other paths after learning the route. This prevents routing loops.

Cause (Mutual Route Import Between OSPF and BGP)

On the network shown in Figure 1-1514, DeviceA, DeviceB, and DeviceC run a BGP process, DeviceF and DeviceG run OSPF process 2, and DeviceD and DeviceE run both processes. Route import between BGP and OSPF process 2 is configured on DeviceD and DeviceE. The routes distributed by BGP on DeviceE are redistributed back to BGP through OSPF process 2 on DeviceD. Because no route-policy is configured for the import or the configured route-policy is improper, the route newly distributed by DeviceD may be selected as the optimal route by BGP, causing a routing loop.

Figure 1-1514 Traffic flow when a routing loop occurs during route import between OSPF and BGP

Implementation (Mutual Route Import Between OSPF and BGP)

The following uses the networking shown in Figure 1-1514 as an example to describe how a routing loop is detected and resolved.

1. DeviceD learns the route distributed by DeviceB through BGP and imports the BGP route to OSPF process 2. When DeviceD distributes the imported route through OSPF process 2, it uses a Type 11 extended prefix Opaque LSA to distribute the Redistribute ID of OSPF process 2 on DeviceD. DeviceE learns the route distributed by DeviceD through OSPF process 2 and saves the Redistribute List distributed by DeviceD through OSPF process 2 to the routing table when calculating routes.
2. DeviceE imports the route from OSPF process 2 to BGP and distributes the Redistribute ID of the BGP process on DeviceE through a Type 11 extended prefix Opaque LSA when redistributing the imported route. After BGP on DeviceD learns the route distributed by DeviceE, DeviceD saves the Redistribute ID distributed by BGP on DeviceE to the routing table during route calculation.
3. When importing the route from BGP to OSPF process 2, DeviceD finds that the Redistribute list of the route contains its own Redistribute ID, considers that a routing loop is detected, and reports an alarm. OSPF process 2 on DeviceD distributes a large link cost when distributing the imported route. Because OSPF has a higher preference than BGP, this does not affect the route selection result or resolve the routing loop.
4. After learning the route distributed by OSPF on DeviceD, DeviceE imports the route to BGP. Upon finding that the Redistribute list of the route contains its own Redistribute ID, DeviceE considers that a routing loop is detected and reports an alarm. When BGP on DeviceE distributes the route, it reduces the preference of the route. In this way, other devices preferentially select other paths after learning this route, preventing routing loops.

   When detecting a routing loop upon route import between processes of the same protocol, the device increases the cost of the corresponding route. As the cost of the delivered route increases, the optimal route in the IP routing table changes. In this way, the routing loop is eliminated.

   In the case of inter-protocol route import, if a routing protocol with a higher preference detects a routing loop, although this protocol increases the cost of the corresponding route, the cost increase will not render the route inactive. As a result, the routing loop cannot be eliminated. If the routing protocol with a lower preference increases the cost of the corresponding route, this route competes with the originally imported route during route selection. In this case, the routing loop can be eliminated.

Application Scenarios

Figure 1-1515 shows a typical seamless MPLS network. If the OSPF process deployed at the access layer differs from that deployed at the aggregation layer, OSPF inter-process mutual route import is usually configured on AGGs so that routes can be leaked between the access and aggregation layers. In this case, a routing loop may occur between AGG1 and AGG2. If OSPF routing loop detection is configured on AGG1 and AGG2, routing loops can be quickly detected and resolved.

Figure 1-1515 Routing protocol deployment on the intra-AS seamless MPLS network