3. OSPF

This chapter provides information about configuring the Open Shortest Path First (OSPF) protocol.

Note:

  1. OSPFv3 is not supported for use as a PE-CE routing protocol on any of the platforms as described in this document.
  2. The platforms as described in this document allow for the configuration of a single instance at any time. The instance ID can be any number other than 0. This enables these platforms to be used in a network where multi-instance OSPF is deployed, and the node needs to use an instance ID other than the default instance ID of 0.
  3. On the 7210 SAS-K 2F6C4T, scaling is designed so that the platforms can fit into an OSPF stub area or NSSA area.

3.1. Configuring OSPF

OSPF (Open Shortest Path First) is a hierarchical link state protocol. OSPF is an interior gateway protocol (IGP) used within large autonomous systems (ASs). OSPF routers exchange state, cost, and other relevant interface information with neighbors. The information exchange enables all participating routers to establish a network topology map. Each router applies the Dijkstra algorithm to calculate the shortest path to each destination in the network. The resulting OSPF forwarding table is submitted to the routing table manager to calculate the routing table.

When a router is started with OSPF configured, OSPF, along with the routing-protocol data structures, is initialized and waits for indications from lower-layer protocols that its interfaces are functional. -Nokia’s implementation of OSPF conforms to OSPF Version 2 specifications presented in RFC 2328, OSPF Version 2. Routers running OSPF can be enabled with minimal configuration. All default and command parameters can be modified.

Key OSPF features are:

  1. backbone areas
  2. stub areas
  3. Not-So-Stubby areas (NSSAs)
  4. virtual links
  5. authentication
  6. route redistribution
  7. routing interface parameters
  8. OSPF-TE extensions (-Nokia’s implementation allows MPLS fast reroute)
  9. addressing semantics have been removed from OSPF packets and the basic link-state advertisements (LSAs). New LSAs have been created to carry IPv6 addresses and prefixes.
  10. OSPF3 runs on a per-link basis, instead of on a per-IP-subnet basis.
  11. unlike OSPFv2, OSPFv3 authentication relies on IPV6's authentication header and encapsulating security payload.
  12. Most packets in OSPF for IPv6 are almost as compact as those in OSPF for IPv4, even with the larger IPv6 addresses.

The 7210 SAS-K 2F6C4T and the 7210 SAS-K 3SFP+ 8C support IGP-LDP synchronization on OSPF routes. Refer to the “IGP-LDP and Static Route-LDP Synchronization on the 7210 SAS-K 2F6C4T and 7210 SAS-K 3SFP+ 8C” in the 7210 SAS-D, Dxp, K 2F1C2T, K 2F6C4T, K 3SFP+ 8C Router Configuration Guide for more information.

3.1.1. OSPF Areas

The hierarchical design of OSPF allows a collection of networks to be grouped into a logical area. An area’s topology is concealed from the rest of the AS which significantly reduces OSPF protocol traffic. With the proper network design and area route aggregation, the size of the route-table can be drastically reduced which results in decreased OSPF route calculation time and topological database size.

Routing in the AS takes place on two levels, depending on whether the source and destination of a packet reside in the same area (intra-area routing) or different areas (inter-area routing). In intra-area routing, the packet is routed solely on information obtained within the area; no routing information obtained from outside the area is used.

Routers that belong to more than one area are called area border routers (ABRs). An ABR maintains a separate topological database for each area it is connected to. Every router that belongs to the same area has an identical topological database for that area.

3.1.1.1. Backbone Area

The OSPF backbone area, area 0.0.0.0, must be contiguous and all other areas must be connected to the backbone area. The backbone distributes routing information between areas. If it is not practical to connect an area to the backbone (see area 0.0.0.5 in Figure 2), the ABRs (such as routers Y and Z) must be connected via a virtual link. The two ABRs form a point-to-point-like adjacency across the transit area (see area 0.0.0.4).

Figure 2:  Backbone Area 

3.1.1.2. Stub Area

A stub area is a designated area that does not allow external route advertisements. Routers in a stub area do not maintain external routes. A single default route to an ABR replaces all external routes. This OSPF implementation supports the optional summary route (type-3) advertisement suppression from other areas into a stub area. This feature further reduces topological database sizes and OSPF protocol traffic, memory usage, and CPU route calculation time.

In Figure 2, areas 0.0.0.1, 0.0.0.2 and 0.0.0.5 could be configured as stub areas. A stub area cannot be designated as the transit area of a virtual link and a stub area cannot contain an AS boundary router. An AS boundary router exchanges routing information with routers in other ASs.

3.1.1.3. Not-So-Stubby Area

Another OSPF area type is called a Not-So-Stubby area (NSSA). NSSAs are similar to stub areas in that no external routes are imported into the area from other OSPF areas. External routes learned by OSPF routers in the NSSA area are advertised as type-7 LSAs within the NSSA area and are translated by ABRs into type-5 external route advertisements for distribution into other areas of the OSPF domain. An NSSA area cannot be designated as the transit area of a virtual link.

In Figure 2, area 0.0.0.3 could be configured as a NSSA area.

3.1.1.3.1. OSPF Super Backbone

The 7210 SAS PE routers have implemented a version of the BGP/OSPF interaction procedures as defined in RFC 4577, OSPF as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs). The features included in this RFC are:

  1. Loop prevention
  2. Handling LSAs received from the CE
  3. Sham links
  4. Managing VPN-IPv4 routes received by BGP

VPRN routes can be distributed among the PE routers by BGP. If the PE uses OSPF to distribute routes to the CE router, the standard procedures governing BGP/OSPF interactions causes routes from one site to be delivered to another in type 5 LSAs, as AS-external routes.

The MPLS VPN super backbone behaves like an additional layer of hierarchy in OSPF. The PE-routers that connect the respective OSPF areas to the super backbone function as OSPF Area Border Routers (ABR) in the OSPF areas to which they are attached. To achieve full compatibility, they can also behave as AS Boundary Routers (ASBR) in non-stub areas.

The PE-routers insert inter-area routes from other areas into the area in which the CE-router is present. The CE-routers are not involved at any level nor are they aware of the super backbone or of other OSPF areas present beyond the MPLS VPN super backbone.

The CE always assumes the PE is an ABR:

  1. If the CE is in the backbone then the CE router assumes that the PE is an ABR linking one or more areas to the backbone.
  2. If the CE in not in the backbone, then the CE believes that the backbone is on the other side of the PE.
  3. As such, the super backbone looks like another area to the CE.
    In Figure 3, the PEs are connected to the MPLS-VPN super backbone. To be able to distinguish if two OSPF instances are in fact the same and require Type 3 LSAs to be generated or are two separate routing instances where type 5 external LSAs need to be generated the concept of a domain-id is introduced.
    Figure 3:  PEs Connected to an MPLS-VPN Super Backbone 

The domain ID is carried with the MP-BGP update and indicates the source OSPF Domain. When the routes are being redistributed into the same OSPF Domain, the concepts of previously described super backbone apply and Type 3 LSAs should be generated. If the OSPF domain does not match, then the route type will be external.

Configuring the super backbone (not the sham links) makes all destinations learned by PEs with matching domain IDs inter-area routes.

When configuring sham links, these links become intra-area routes if they are present in the same area.

3.1.1.3.2. Sham Links

Figure 4 shows the red link between CE-3 and CE-4 could be a low speed OC-3/STM-1 link but because it establishes a intra-area route connection between the CE-3 and CE-4 the potentially high-speed PE-1 to PE-2 connection will not be utilized. Even with a super backbone configuration it is regarded as a inter-area connection.

Figure 4:  Sham Links 

The establishment of the (green) sham-link is also constructed as an intra-area link between PE routers, a normal OSPF adjacency is formed and the link-state database is exchanged across the MPLS-VPRN. As a result, the desired intra-area connectivity is created, at this time the cost of the green and red links can be managed such that the red link becomes a standby link only in case the VPN fails.

A sham link is only required if a back door link (shown as the red link in Figure 4) is present; otherwise, configuring an OSPF super backbone will probably suffice.

3.1.1.3.3. Implementing the OSPF Super Backbone

With the OSPF super backbone architecture, the continuity of OSPF routing is preserved:

  1. The OSPF intra-area LSAs (type-1 and type-2) advertised bye the CE are inserted into the MPLS-VPRN super backbone by redistributing the OSPF route into MP-BGP by the PE adjacent to the CE.
  2. The MP-BGP route is propagated to other PE-routers and inserted as an OSPF route into other OSPF areas. Considering the PEs across the super backbone always act as ABRs they will generate inter area route OSPF summary LSAs, Type 3.
  3. The inter-area route can now be propagated into other OSPF areas by other customer owned ABRs within the customer site.
  4. Customer Area 0 (backbone) routes when carried across the MPLS-VPRN using MPBGP will appear as Type 3 LSAs even if the customer area remains area 0 (backbone).

A BGP extended community (OSPF domain ID) provides the source domain of the route. This domain ID is not carried by OSPF but carried by MP-BGP as an extended community attribute.

If the configured extended community value matches the receiving OSPF domain, then the OSPF super backbone is implemented.

From a BGP perspective, the cost is copied into the MED attribute.

3.1.1.3.4. Loop Avoidance

If a route sent from a PE router to a CE router could then be received by another PE router from one of its own CE routers then it is possible for routing loops to occur. RFC 4577 specifies several methods of loop avoidance.

3.1.1.3.5. DN-BIT

When a Type 3 LSA is sent from a PE router to a CE router, the DN bit in the LSA options field is set. This is used to ensure that if any CE router sends this Type 3 LSA to a PE router, the PE router will not redistribute it further.

When a PE router needs to distribute to a CE router a route that comes from a site outside the latter's OSPF domain, the PE router presents itself as an ASBR (Autonomous System Border Router), and distributes the route in a type 5 LSA. The DN bit MUST be set in these LSAs to ensure that they will be ignored by any other PE routers that receive them.

DN-BIT loop avoidance is also supported.

3.1.1.3.6. Route Tag

If a particular VRF in a PE is associated with an instance of OSPF, then by default it is configured with a special OSPF route tag value called the VPN route tag. This route tag is included in the Type 5 LSAs that the PE originates and sends to any of the attached CEs. The configuration and inclusion of the VPN Route Tag is required for backward compatibility with deployed implementations that do not set the DN bit in Type 5 LSAs.

3.1.2. OSPFv3 Authentication

OSPFv3 authentication requires IPv6 IPSec and supports the following:

  1. IPSec transport mode
  2. AH and ESP
  3. Manual keyed IPSec Security Association (SA)
  4. Authentication Algorithms MD5 and SHA1

To pass OSPFv3 authentication, OSPFv3 peers must have matching inbound and outbound SAs configured using the same SA parameters such as SPI, keys and related parameters. The implementation must allow the use of one SA for both inbound and outbound directions.

The re-keying procedure defined in RFC 4552, Authentication/Confidentiality for OSPFv3, supports the following:

  1. For every router on the link, create an additional inbound SA for the interface being re-keyed using a new SPI and the new key.
  2. For every router on the link, replace the original outbound SA with one using the new SPI and key values. The SA replacement operation must be atomic with respect to sending OSPFv3 packet on the link, so that no OSPFv3 packets are sent without authentication or encryption.
  3. For every router on the link, remove the original inbound SA.

The key rollover procedure automatically starts when the operator changes the configuration of the inbound static-SA or bidirectional static-SA under an interface or virtual link. Within the KeyRolloverInterval time period, OSPF3 accepts packets with both the previous inbound static-SA and the new inbound static-SA, and the previous outbound static-SA should continue to be used. When the timer expires, OSPF3 only accepts packets with the new inbound static-SA and for outgoing OSPF3 packets, the new outbound static-SA is used instead.

3.1.3. OSPFv3 Graceful Restart Helper

This feature extends the Graceful Restart helper function supported on OSPFv2 protocols to OSPFv3:

The primary difference between graceful restart helper for OSPFv2 and OSPFv3 is in OSPFv3 a different grace-LSA format is used.

The graceful restart helper mode allows SR OS-based systems to provide a grace period to other routers which have requested it, during which the SR OS systems will continue to use routes authored by or transiting the router requesting the grace period. This is typically used when another router is rebooting the control plane but the forwarding plane is expected to continue to forward traffic based on the previously available FIB.

The grace-LSA format for OSPF restart (GRACE) LSA format is:

0                   1                   2                   3 
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
|          LS age              |0|0|0|          11              | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
|                      Link State ID                            | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
|                     Advertising Router                        | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
|                     LS sequence number                        | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
|      LS checksum            |              Length             | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
|                                                               | 
+-                           TLVs                              -+ 
|                            ...                                | 

The Link State ID of a grace-LSA in OSPFv3 is the Interface ID of the interface originating the LSA.The format of each TLV is:

0                   1                   2                   3 
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
|             Type             |            Length              | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
|                           Value...                            | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
                         
                          TLV Format 

3.1.4. Virtual Links

The backbone area in an OSPF AS must be contiguous and all other areas must be connected to the backbone area. Sometimes, this is not possible. You can use virtual links to connect to the backbone through a non-backbone area.

Figure 2 shows routers Y and Z as the start and end points of the virtual link while area 0.0.0.4 is the transit area. To configure virtual links, the router must be an ABR. Virtual links are identified by the router ID of the other endpoint, another ABR. These two endpoint routers must be attached to a common area, called the transit area. The area through which you configure the virtual link must have full routing information.

Transit areas pass traffic from an area adjacent to the backbone or to another area. The traffic does not originate in, nor is it destined for, the transit area. The transit area cannot be a stub area or a NSSA area.

Virtual links are part of the backbone, and behave as if they were unnumbered point-to-point networks between the two routers. A virtual link uses the intra-area routing of its transit area to forward packets. Virtual links are brought up and down through the building of the shortest-path trees for the transit area.

3.1.5. Neighbors and Adjacencies

A router uses the OSPF Hello protocol to discover neighbors. A neighbor is a router configured with an interface to a common network. The router sends hello packets to a multicast address and receives hello packets in return.

In broadcast networks, a designated router and a backup designated router are elected. The designated router is responsible for sending link-state advertisements (LSAs) describing the network, which reduces the amount of network traffic.

The routers attempt to form adjacencies. An adjacency is a relationship formed between a router and the designated or backup designated router. For point-to-point networks, no designated or backup designated router is elected. An adjacency must be formed with the neighbor.

To significantly improve adjacency forming and network convergence, a network should be configured as point-to-point if only two routers are connected, even if the network is a broadcast media such as Ethernet.

When the link-state databases of two neighbors are synchronized, the routers are considered to be fully adjacent. When adjacencies are established, pairs of adjacent routers synchronize their topological databases. Not every neighboring router forms an adjacency. Routing protocol updates are only sent to and received from adjacencies. Routers that do not become fully adjacent remain in the two-way neighbor state.

3.1.6. Link-State Advertisements

Link-state advertisements (LSAs) describe the state of a router or network, including router interfaces and adjacency states. Each LSA is flooded throughout an area. The collection of LSAs from all routers and networks form the protocol's topological database.

The distribution of topology database updates take place along adjacencies. A router sends LSAs to advertise its state according to the configured interval and when the router's state changes. These packets include information about the router's adjacencies, which allows detection of non-operational routers.

When a router discovers a routing table change or detects a change in the network, link state information is advertised to other routers to maintain identical routing tables. Router adjacencies are reflected in the contents of its link state advertisements. The relationship between adjacencies and the link states allow the protocol to detect non-operating routers. Link state advertisements flood the area. The flooding mechanism ensures that all routers in an area have the same topological database. The database consists of the collection of LSAs received from each router belonging to the area.

OSPF sends only the part that has changed and only when a change has taken place. From the topological database, each router constructs a tree of shortest paths with itself as root. OSPF distributes routing information between routers belonging to a single AS.

3.1.7. Metrics

In OSPF, all interfaces have a cost value or routing metric used in the OSPF link-state calculation. OSPF uses cost values to determine the best path to a particular destination: the lower the cost value, the more likely the interface will be used to forward data traffic.

3.1.8. Authentication

All OSPF protocol exchanges can be authenticated. This means that only trusted routers can participate in autonomous system routing. Nokia’s implementation of OSPF supports plain text and Message Digest 5 (MD5) authentication (also called simple password).

MD5 allows an authentication key to be configured per network. Routers in the same routing domain must be configured with the same key. When the MD5 hashing algorithm is used for authentication, MD5 is used to verify data integrity by creating a 128-bit message digest from the data input. It is unique to that data. Nokia’s implementation of MD5 allows the migration of an MD5 key by using a key ID for each unique key.

By default, authentication is not enabled on an interface.

3.1.9. Multiple OSPF Instances

Note:

Nokia recommends using only a single instance of OSPFv2. This allows for the use of different instance IDs, if required by the customer.

3.1.9.1. Route Export Policies for OSPF

Route policies allow specification of the source OSPF process ID in the from and to parameters in the config>router>policy-options>policy-statement>entry>from context, for example from protocol ospf instance-id.

If an instance-id is specified, only routes installed by that instance are picked up for announcement. If no instance-id is specified, then only routes installed by the base instance is will be announced. The all keyword announces routes installed by all instances of OSPF.

When announcing internal (intra/inter-area) OSPF routes from another process, the default type should be type-1, and metric set to the route metric in RTM. For AS-external routes, by default the route type (type-1/2) should be preserved in the originated LSA, and metric set to the route metric in RTM. By default, the tag value should be preserved when an external OSPF route is announced by another process. All these can be changed with explicit action statements.

Export policy should allow a match criteria based on the OSPF route hierarchy, e.g. only intra-area, only inter-area, only external, only internal (intra/inter-area). There must also be a possibility to filter based on existing tag values.

3.1.9.2. Preventing Route Redistribution Loops

The legacy method for this was to assign a tag value to each OSPF process and mark each external route originated within that domain with that value. However, since the tag value must be preserved throughout different OSPF domains, this only catches loops that go back to the originating domain and not where looping occurs in a remote set of domains. To prevent this type of loop, the route propagation information in the LSA must be accumulative. The following method has been implemented:

  1. The OSPF tag field in the AS-external LSAs is treated as a bit mask, rather than a scalar value. That is, each bit in the tag value can be independently checked, set or reset as part of the routing policy.
  2. When a set of OSPF domains are provisioned in a network, each domain is assigned a specific bit value in the 32-bit tag mask. When an external route is originated by an ASBR using an internal OSPF route in a specific domain, a corresponding bit is set in the AS-external LSA. As the route gets redistributed from one domain to another, more bits are set in the tag mask, each corresponding to the OSPF domain the route visited. Route redistribution looping is prevented by checking the corresponding bit as part of the export policy--if the bit corresponding to the announcing OSPF process is already set, the route is not exported there.
    From the CLI perspective, this involves adding a set of from tag and action tag commands that allow for bit operations.

3.1.10. IP Subnets

OSPF enables the flexible configuration of IP subnets. Each distributed OSPF route has a destination and mask. A network mask is a 32-bit number that indicates the range of IP addresses residing on a single IP network/subnet. This specification displays network masks as hexadecimal numbers; for example, the network mask for a class C IP network is displayed as 0xffffff00. Such a mask is often displayed as 255.255.255.0.

Two different subnets with same IP network number have different masks, called variable length subnets. A packet is routed to the longest or most specific match. Host routes are considered to be subnets whose masks are all ones (0xffffffff).

3.1.11. Preconfiguration Recommendations

Before configuring OSPF, the router ID must be available. The router ID is a 32-bit number assigned to each router running OSPF. This number uniquely identifies the router within an AS. OSPF routers use the router IDs of the neighbor routers to establish adjacencies. Neighbor IDs are learned when Hello packets are received from the neighbor.

Before configuring OSPF parameters, ensure that the router ID is derived by one of the following methods:

  1. Define the value in the config>router router-id context.
  2. Define the system interface in the config>router>interface ip-int-name context (used if the router ID is not specified in the config>router router-id context).
    A system interface must have an IP address with a 32-bit subnet mask. The system interface is used as the router identifier by higher-level protocols such as OSPF and IS-IS. The system interface is assigned during the primary router configuration process when the interface is created in the logical IP interface context.
  3. If you do not specify a router ID, then the last four bytes of the MAC address are used.

3.2. IP Fast-reroute (IP FRR) For OSPF and IS-IS Prefixes

Note:

Only LDP FRR is supported. LDP FRR uses the LFA computed for IP prefixes to determine the backup path to use for LDP FEC that are installed in the MPLS tables. This section is here only for completeness of description for this feature.

This feature provides for the use of the Loop-Free Alternate (LFA) backup next-hop for forwarding in-transit and CPM generated IP packets when the primary next-hop is not available. This means that a node resumes forwarding IP packets to a destination prefix without waiting for the routing convergence.

When any of the following events occurs, IGP instructs in the fast path the IOM, the forwarding engine to enable the LFA backup next-hop:

  1. OSPF/IS-IS interface goes operationally down: physical or local admin shutdown.
  2. Timeout of a BFD session to a next-hop when BFD is enabled on the OSPF/IS-IS interface.

IP FRR is supported on IPv4 and IPv6 OSPF/IS-IS prefixes forwarded in the base router instance to a network IP interface or to an IES SAP interface or spoke interface. It is also supported for VPRN VPN-IPv4 OSPF prefixes and VPN-IPv6 OSPF prefixes forwarded to a VPRN SAP interface or spoke interface.

The LFA next-hop precomputation by IGP is described in RFC 5286, Basic Specification for IP Fast Reroute: Loop-Free Alternates.

3.2.1. IP FRR/LFA Configuration

Note:

IP FRR is not supported on 7210 SAS nodes. LFA is supported on 7210 SAS nodes that support LDP FRR.

The user first enables Loop-Free Alternate (LFA) computation by SPF under the IS-IS routing protocol level or under the OSPF routing protocol instance level:

config>router>isis>loopfree-alternate config>router>ospf>loopfree-alternate

The preceding commands instruct the IGP SPF to attempt to precompute both a primary next-hop and an LFA next-hop for every learned prefix. When found, the LFA next-hop is populated into the RTM along with the primary next-hop for the prefix.

3.2.1.1. Reducing the Scope of the LFA Calculation by SPF

The user can instruct IGP to not include all interfaces participating in a specific IS-IS level or OSPF area in the SPF LFA computation. This provides a way of reducing the LFA SPF calculation where it is not needed.

config>router>isis>level>loopfree-alternate-exclude

config>router>ospf>area>loopfree-alternate-exclude

The user can also exclude a specific IP interface from being included in the LFA SPF computation by IS-IS or OSPF:

config>router>isis>interface>loopfree-alternate-exclude

config>router>ospf>area>interface>loopfree-alternate-exclude

Note that when an interface is excluded from the LFA SPF in IS-IS, it is excluded in both level 1 and level 2. When the user excludes an interface from the LFA SPF in OSPF, it is excluded in all areas. However, the preceding OSPF command can only be executed under the area in which the specified interface is primary and after enabled, the interface is excluded in that area and in all other areas where the interface is secondary. If the user attempts to apply it to an area where the interface is secondary, the command fails.

3.2.2. ECMP Considerations

Whenever the SPF computation determined there is more than one primary next-hop for a prefix, it will not program any LFA next-hop in RTM. Therefore, IP prefixes will resolve to the multiple primary next-hops in this case which provides the required protection.

3.2.3. IP FRR and RSVP Shortcut (IGP Shortcut)

When both IGP shortcut and LFA are enabled in IS-IS or OSPF, and IP FRR is also enabled, then the following additional IP FRR capabilities are supported:

  1. A prefix which is resolved to a direct primary next-hop can be backed up by a tunneled LFA next-hop.
  2. A prefix which is resolved to a tunneled primary next-hop will not have an LFA next-hop. It will rely on RSVP FRR for protection.

The LFA SPF is extended to use IGP shortcuts as LFA next-hops as explained in OSPF and IS-IS Support for Loop-Free Alternate Calculation.

3.2.4. IP FRR and BGP Next-Hop Resolution

An LFA backup next-hop will be able to protect the primary next-hop to reach a prefix advertised by a BGP neighbor. The BGP next-hop will therefore remain up when the FIB switches from the primary IGP next-hop to the LFA IGP next-hop.

3.2.5. OSPF and IS-IS Support for Loop-Free Alternate Calculation

SPF computation in IS-IS and OSPF is enhanced to compute LFA alternate routes for each learned prefix and populate it in RTM.

Figure 5 shows a simple network topology with point-to-point (P2P) interfaces and highlights three routes to reach router R5 from router R1.

Figure 5:  Topology Example with Primary and LFA Routes 

The primary route is via R3. The LFA route via R2 has two equal cost paths to reach R5. The path by way of R3 protects against failure of link R1-R3. This route is computed by R1 by checking that the cost for R2 to reach R5 by way of R3 is lower than the cost by way of routes R1 and R3. This condition is referred to as the “loop-free criterion”.

The path by way of R2 and R4 can be used to protect against the failure of router R3. However, with the link R2-R3 metric set to 5, R2 sees the same cost to forward a packet to R5 by way of R3 and R4. Therefore R1 cannot guarantee that enabling the LFA next-hop R2 will protect against R3 node failure. This means that the LFA next-hop R2 provides link-protection only for prefix R5. If the metric of link R2-R3 is changed to 8, then the LFA next-hop R2 provides node protection since a packet to R5 will always go over R4.That is, it is required that R2 becomes loop-free with respect to both the source node R1 and the protected node R3.

Consider now the case where the primary next-hop uses a broadcast interface as shown in Figure 6.

Figure 6:  Topology Example with Broadcast Interfaces 

In order for next-hop R2 to be a link-protect LFA for route R5 from R1, it must be loop-free with respect to the R1-R3 link Pseudo-Node (PN). However, since R2 has also a link to that PN, its cost to reach R5 by way of the PN or router R4 are the same. Therefore R1 cannot guarantee that enabling the LFA next-hop R2 will protect against a failure impacting link R1-PN since this may cause the entire subnet represented by the PN to go down. If the metric of link R2-PN is changed to 8, then R2 next-hop will be an LFA providing link protection.

The following are the detailed equations for this criterion as provided in RFC 5286, Basic Specification for IP Fast Reroute: Loop-Free Alternates:

  1. Rule 1: Link-protect LFA backup next-hop (primary next-hop R1-R3 is a P2P interface):
    Distance_opt(R2, R5) < Distance_opt(R2, R1) + Distance_opt(R1, R5)
    and,
    Distance_opt(R2, R5) >= Distance_opt(R2, R3) + Distance_opt(R3, R5)
  2. Rule 2: Node-protect LFA backup next-hop (primary next-hop R1-R3 is a P2P interface):
    Distance_opt(R2, R5) < Distance_opt(R2, R1) + Distance_opt(R1, R5)
    and,
    Distance_opt(R2, R5) < Distance_opt(R2, R3) + Distance_opt(R3, R5)
  3. Rule 3: Link-protect LFA backup next-hop (primary next-hop R1-R3 is a broadcast interface):
    Distance_opt(R2, R5) < Distance_opt(R2, R1) + Distance_opt(R1, R5)
    and,
    Distance_opt(R2, R5) < Distance_opt(R2, PN) + Distance_opt(PN, R5)
    where; PN stands for the R1-R3 link Pseudo-Node.

For the case of P2P interface, if SPF finds multiple LFA next-hops for a specific primary next-hop, it follows the following selection algorithm:

  1. It will pick the node-protect type in favor of the link-protect type.
  2. If there is more than one LFA next-hop within the selected type, then it will pick one based on the least cost.
  3. If more than one LFA next-hop with the same cost results from step (b), then SPF will select the first one. This is not a deterministic selection and will vary following each SPF calculation.

For the case of a broadcast interface, a node-protect LFA is not necessarily a link protect LFA if the path to the LFA next-hop goes over the same PN as the primary next-hop. Similarly, a link protect LFA may not guarantee link protection if it goes over the same PN as the primary next-hop. The selection algorithm when SPF finds multiple LFA next-hops for a specific primary next-hop is modified as follows:

  1. The algorithm splits the LFA next-hops into two sets:
    1. The first set consists of LFA next-hops which do not go over the PN used by primary next-hop.
    2. The second set consists of LFA next-hops which do go over the PN used by the primary next-hop.
  2. If there is more than one LFA next-hop in the first set, it will pick the node-protect type in favor of the link-protect type.
  3. If there is more than one LFA next-hop within the selected type, then it will pick one based on the least cost.
  4. If more than one LFA next-hop with equal cost results from Step C, SPF will select the first one from the remaining set. This is not a deterministic selection and will vary following each SPF calculation.
  5. If no LFA next-hop results from Step D, SPF will rerun Steps B-D using the second set.

Note this algorithm is more flexible than strictly applying Rule 3; i.e., the link protect rule in the presence of a PN and specified in RFC 5286. A node-protect LFA which does not avoid the PN; i.e., does not guarantee link protection, can still be selected as a last resort. The same thing, a link-protect LFA which does not avoid the PN may still be selected as a last resort.

Both the computed primary next-hop and LFA next-hop for a specific prefix are programmed into RTM.

3.2.5.1. Loop-Free Alternate Calculation in the Presence of IGP shortcuts

To expand the coverage of the LFA backup protection in a network, RSVP LSP based IGP shortcuts can be placed selectively in parts of the network and be used as an LFA backup next-hop.

When IGP shortcut is enabled in IS-IS or OSPF on a specific node, all RSVP LSP originating on this node and with a destination address matching the router-id of any other node in the network are included in the main SPF by default.

To limit the time it takes to compute the LFA SPF, the user must explicitly enable the use of an IGP shortcut as LFA backup next-hop using one of a couple of new optional argument for the existing LSP level IGP shortcut command:

config router mpls lsp igp-shortcut [lfa-only]

The lfa-only option allows an LSP to be included in the LFA SPFs only such that the introduction of IGP shortcuts does not impact the main SPF decision. For a specific prefix, the main SPF always selects a direct primary next-hop. The LFA SPF will select a an LFA next-hop for this prefix but will prefer a direct LFA next-hop over a tunneled LFA next-hop.

Therefore the selection algorithm in Section 1.3 when SPF finds multiple LFA next-hops for a specific primary next-hop is modified as follows:

  1. The algorithm splits the LFA next-hops into two sets:
    1. the first set consists of direct LFA next-hops
    2. the second set consists of tunneled LFA next-hops. after excluding the LSPs which use the same outgoing interface as the primary next-hop.
  2. The algorithms continues with first set if not empty, otherwise it continues with second set.
  3. If the second set is used, the algorithm selects the tunneled LFA next-hop which endpoint corresponds to the node advertising the prefix.
    1. If more than one tunneled next-hop exists, it selects the one with the lowest LSP metric.
    2. If still more than one tunneled next-hop exists, it selects the one with the lowest tunnel-id.
    3. If none is available, it continues with rest of the tunneled LFAs in second set.
  4. Within the selected set, the algorithm splits the LFA next-hops into two sets:
    1. The first set consists of LFA next-hops which do not go over the PN used by primary next-hop.
    2. The second set consists of LFA next-hops which go over the PN used by the primary next-hop.
  5. If there is more than one LFA next-hop in the selected set, it will pick the node-protect type in favor of the link-protect type.
  6. If there is more than one LFA next-hop within the selected type, then it will pick one based on the least total cost for the prefix. For a tunneled next-hop, it means the LSP metric plus the cost of the LSP endpoint to the destination of the prefix.
  7. If there is more than one LFA next-hop within the selected type (ecmp-case) in the first set, it will select the first direct next-hop from the remaining set. This is not a deterministic selection and will vary following each SPF calculation.
  8. If there is more than one LFA next-hop within the selected type (ecmp-case) in the second set, it will pick the tunneled next-hop with the lowest cost from the endpoint of the LSP to the destination prefix. If there remains more than one, it will pick the tunneled next-hop with the lowest tunnel-id.

3.2.5.2. Loop-Free Alternate Calculation for Inter-Area/inter-Level Prefixes

When SPF resolves OSPF inter-area prefixes or IS-IS inter-level prefixes, it will compute an LFA backup next-hop to the same exit area/border router as used by the primary next-hop.

3.3. Loop-Free Alternate Shortest Path First (LFA SPF) Policies

An LFA SPF policy allows the user to apply specific criteria, such as admin group and SRLG constraints, to the selection of a LFA backup next-hop for a subset of prefixes that resolve to a specific primary next-hop. The feature introduces the concept of route next-hop template to influence LFA backup next-hop selection.

3.3.1. Configuration of Route Next-Hop Policy Template

The LFA SPF policy consists of applying a route next-hop policy template to a set of prefixes.

The user first creates a route next-hop policy template under the global router context:

configure>router>route-next-hop-policy>template template-name

A policy template can be used in both IS-IS and OSPF to apply the specific criteria described in the next subsections to prefixes protected by LFA. Each instance of IS-IS or OSPF can apply the same policy template to one or more prefix lists and to one or more interfaces.

The commands within the route next-hop policy use the begin-commit-abort model introduced with BFD templates. The following are the steps to create and modify the template:

  1. To create a template, the user enters the name of the new template directly under route-next-hop-policy context.
  2. To delete a template which is not in use, the user enters the no form for the template name under the route-next-hop-policy context.
  3. The user enters the editing mode by executing the begin command under route-next-hop-policy context. The user can then edit and change any number of route next-hop policy templates. However, the parameter value will still be stored temporarily in the template module until the commit is executed under the route-next-hop-policy context. Any temporary parameter changes will be lost if the user enters the abort command before the commit command.
  4. The user is allowed to create or delete a template instantly when in the editing mode without the need to enter the commit command. Also, the abort command if entered will have no effect on the prior deletion or creation of a template.

When the commit command is issued, IS-IS or OSPF will reevaluate the templates and if there are any net changes, it will schedule a new LFA SPF to recompute the LFA next-hop for the prefixes associated with these templates.

3.3.1.1. Configuring Affinity or Admin Group Constraint in Route Next-Hop Policy

Administrative groups (admin groups), also known as affinity, are used to tag IP interfaces which share a specific characteristic with the same identifier. For example, an admin group identifier could represent all links which connect to core routers, or all links which have bandwidth higher than 10G, or all links which are dedicated to a specific service.

The user first configures locally on each router the name and identifier of each admin group:

config>router>if-attribute>admin-group group-name value group-value

A maximum of 32 admin groups can be configured per system.

Next the user configures the admin group membership of the IP interfaces used in LFA. The user can apply admin groups to a network IP interface.

config>router> interface>if-attribute>admin-group group-name [group-name...(up to 5 max)]

The user can add as many admin groups as configured to a specific IP interface. The preceding command can be applied multiple times.

Note that the configured admin-group membership will be applied in all levels/areas the interface is participating in. The same interface cannot have different memberships in different levels/areas.

The no form of the admin-group command under the interface deletes one or more of the admin-group memberships of the interface. It deletes all memberships if no group name is specified.

Finally, the user adds the admin group constraint into the route next-hop policy template:

configure router route-next-hop-template template template-name

include-group group-name [pref 1]

include-group group-name [pref 2]

exclude-group group-name

Each group is entered individually. The include-group statement instructs the LFA SPF selection algorithm to pick up a subset of LFA next-hops among the links which belong to one or more of the specified admin groups. A link which does not belong to at least one of the admin-groups is excluded. However, a link can still be selected if it belongs to one of the groups in a include-group statement but also belongs to other groups which are not part of any include-group statement in the route next-hop policy.

The pref option is used to provide a relative preference for the admin group to select. A lower preference value means that LFA SPF will first attempt to select a LFA backup next-hop which is a member of the corresponding admin group. If none is found, then the admin group with the next higher preference value is evaluated. If no preference is configured for a specific admin group name, then it is supposed to be the least preferred, i.e., numerically the highest preference value.

When evaluating multiple include-group statements within the same preference, any link which belongs to one or more of the included admin groups can be selected as an LFA next-hop. There is no relative preference based on how many of those included admin groups the link is a member of.

The exclude-group statement prunes all links belonging to the specified admin group before making the LFA backup next-hop selection for a prefix.

If the same group name is part of both include and exclude statements, the exclude statement will win. It other words, the exclude statement can be viewed as having an implicit preference value of 0.

Note the admin-group criterion is applied before running the LFA next-hop selection algorithm. The modified LFA next-hop selection algorithm is shown in Section 7.5.

3.3.1.2. Configuring SRLG Group Constraint in Route Next-Hop Policy

Shared Risk Loss Group (SRLG) is used to tag IP interfaces which share a specific fate with the same identifier. For example, an SRLG group identifier could represent all links which use separate fibers but are carried in the same fiber conduit. If the conduit is accidentally cut, all the fiber links are cut which means all IP interfaces using these fiber links will fail. Therefore the user can enable the SRLG constraint to select a LFA next-hop for a prefix which avoids all interfaces that share fate with the primary next.

The user first configures locally on each router the name and identifier of each SRLG group:

configure>router>if-attribute>srlg-group group-name value group-value

A maximum of 1024 SRLGs can be configured per system.

Next the user configures the admin group membership of the IP interfaces used in LFA. The user can apply SRLG groups to a network IP interface.

config>router>interface>if-attribute>srlg-group group-name [group-name...(up to 5 max)]

The user can add a maximum of 64 SRLG groups to a specific IP interface. The same preceding command can be applied multiple times.

Note that the configured SRLG membership will be applied in all levels/areas the interface is participating in. The same interface cannot have different memberships in different levels/areas.

The no form of the srlg-group command under the interface deletes one or more of the SRLG memberships of the interface. It deletes all SRLG memberships if no group name is specified.

Finally, the user adds the SRLG constraint into the route next-hop policy template:

configure router route-next-hop-template template template-name

srlg-enable

When this command is applied to a prefix, the LFA SPF will select a LFA next-hop, among the computed ones, which uses an outgoing interface that does not participate in any of the SLRGs of the outgoing interface used by the primary next-hop.

Note the SRLG and admin-group criteria are applied before running the LFA next-hop selection algorithm. The modified LFA next-hop selection algorithm is shown in Section 7.5.

3.3.1.3. Interaction of IP and MPLS Admin Group and SRLG

The LFA SPF policy feature generalizes the use of admin-group and SRLG to other types of interfaces. To that end, it is important that the new IP admin groups and SRLGs be compatible with the ones already supported in MPLS. The following rules are implemented:

  1. The definition of admin groups and SRLGs are moved under the new config>router>if-attribute context. When upgrading customers to the release which supports the feature, all user configured admin groups and SRLGs under config>router>mpls context will automatically be moved into the new context. The configuration of admin groups and SRLGs under the config>router>mpls context in CLI is deprecated.
  2. The binding of an MPLS interface to a group, i.e., configuring membership of an MPLS interface in a group, continues to be performed under config>router>mpls>interface context.
  3. The binding of a local or remote MPLS interface to an SRLG in the SRLG database continues to be performed under the config>router>mpls>srlg-database context.
  4. The binding of an ISIS/OSPF interface to a group is performed in the config>router>interface>if-attribute context. This is used by ISIS or OSPF in route next-hop policies.
  5. Only the admin groups and SRLGs bound to an MPLS interface context or the SRLG database context are advertised in TE link TLVs and sub-TLVs when the traffic-engineering option is enabled in IS-IS or OSPF.

3.3.1.4. Configuring Protection Type and Next-Hop Type Preference in Route next-hop policy template

The user can select if link protection or node protection is preferred in the selection of a LFA next-hop for all IP prefixes and LDP FEC prefixes to which a route next-hop policy template is applied. The default in SROS implementation is node protection. The implementation will fall back to the other type if no LFA next-hop of the preferred type is found.

The user can also select if IP backup next-hop. The default in SROS implementation is to prefer IP next-hop as only IP backup nexthop is supported on 7210.

The following options are therefore added into the Route next-hop policy template:

configure router route-nh-template template template-name

protection-type {link | node}

nh-type {ip | tunnel}

When the route next-hop policy template is applied to an IP interface, all prefixes using this interface as a primary next-hop will follow the protection type and next-hop type preference specified in the template.

3.3.2. Application of Route Next-Hop Policy Template to an Interface

After the route next-hop policy template is configured with the desired policies, the user can apply it to all prefixes which primary next-hop uses a specific interface name. The following command is achieves that:

config>router>isis>interface>lfa-policy-map route-nh-template template-name

config>router>ospf>area>interface>lfa-policy-map route-nh-template template-name

When a route next-hop policy template is applied to an interface in IS-IS, it is applied in both level 1 and level 2. When a route next-hop policy template is applied to an interface in OSPF, it is applied in all areas. However, the preceding CLI command in an OSPF interface context can only be executed under the area in which the specified interface is primary and then applied in that area and in all other areas where the interface is secondary. If the user attempts to apply it to an area where the interface is secondary, the command will fail.

If the user excluded the interface from LFA using the command loopfree-alternate-exclude, the LFA policy if applied to the interface has no effect.

Finally, if the user applied a route next-hop policy template to a loopback interface or to the system interface, the command will not be rejected but it will result in no action taken.

3.3.3. Excluding Prefixes from LFA SPF

In the current 7210 SAS implementation, the user can exclude an interface in IS-IS or OSPF, an OSPF area, or an IS-IS level from the LFA SPF.

This feature adds the ability to exclude prefixes from a prefix policy which matches on prefixes or on IS-IS tags:

config>router>isis>loopfree-alternate-exclude prefix-policy prefix-policy [prefix-policy.. up to 5]

config>router>ospf>loopfree-alternate-exclude prefix-policy prefix-policy [prefix-policy.. up to 5]

The prefix policy is configured as in the existing SR OS implementation:

config
          router
                    policy-options
                              [no] prefix-list prefix-list1 
                                        prefix 10.225.16.0/24 prefix-length-
range 32-32
                              [no] policy-statements prefix-policy1
                                                  entry 10
                                                  from
                                                            prefix-list "prefix-
list1"
                                                  exit
                                                            action accept
                                                  exit
                              exit
                              default-action reject
exit

The default action of the preceding loopfree-alternate-exclude command when not explicitly specified by the user in the prefix policy is a “reject”. Therefore, regardless of whether the user explicitly added the statement “default-action reject” to the prefix policy, a prefix that did not match an entry in the policy is accepted into LFA SPF.

3.3.4. Modification to LFA Next-Hop Selection Algorithm

This feature modifies the LFA next-hop selection algorithm. The SRLG and admingroup criteria are applied before running the LFA next-hop selection algorithm. That is, links which do not include one or more of the admin-groups in the include-group statements and links which belong to admin-groups which have been explicitly excluded using the exclude-group statement, and the links which belong to the SRLGs used by the primary next-hop of a prefix are first pruned.

This pruning applies only to IP next-hops. Tunnel next-hops can have the admin group or SRLG constraint applied to them under MPLS. For example, if a tunnel next-hop is using an outgoing interface which belongs to a specific SRLG ID, the user can enable the srlg-frr option under the config>router>mpls context to be sure the RSVP LSP FRR backup LSP will not use an outgoing interface with the same SRLG ID. A prefix which is resolved to a tunnel next-hop is protected by the RSVP FRR mechanism and not by the IP FRR mechanism. Similarly, the user can include or exclude admin-groups for the RSVP LSP and its FRR bypass backup LSP in MPLS context. The admin-group constraints will, however, be applied to the selection of the outgoing interface of both the LSP primary path and its FRR bypass backup path.

The following is the modified LFA selection algorithm which is applied to prefixes resolving to a primary next-hop which uses a specific route next-hop policy template.

  1. Split the LFA next-hops into two sets:
    1. IP or direct next-hops.
    2. Tunnel next-hops after excluding the LSPs which use the same outgoing interface as the primary next-hop.
  2. Prune the IP LFA next-hops which use the following links:
    1. links which do not include one or more of the admin-groups in the include group statements in the route next-hop policy template.
    2. links which belong to admin-groups which have been explicitly excluded using the exclude-group statement in the route next-hop policy template.
    3. links which belong to the SRLGs used by the primary next-hop of a prefix.
  3. Continue with the set indicated in the nh-type value in the route next-hop policy template if not empty, otherwise continue with the other set.
  4. Within IP next-hop set:
    1. prefer LFA next-hops which do not go over the Pseudo-Node (PN) used by the primary next-hop
    2. Within selected subset prefer the node-protect type or the link-protect type according to the value of the protection-type option in the route next-hop policy template.
    3. Within the selected subset, select the best admin-group(s) according to the preference specified in the value of the include-group option in the route next-hop policy template.
    4. Within selected subset, select lowest total cost of a prefix.
    5. If same total cost, select lowest router-id.
    6. If same router-id, select lowest interface-index.
  5. Within tunnel next-hop set:
    1. Select tunnel next-hops which endpoint corresponds to the node owning or advertising the prefix.
  6. Within selected subset, select the one with the lowest cost (lowest LSP metric).
  7. If same lowest cost, select tunnel with lowest tunnel-index.
    1. If none is available, continue with rest of the tunnel LFA next-hop set.
    2. Prefer LFA next-hops which do not go over the Pseudo-Node (PN) used by the primary next-hop.
    3. Within selected subset prefer the node-protect type or the link-protect type according to the value of the protection-type in the route next-hop policy template.
    4. Within selected subset, select lowest total cost of a prefix. For a tunnel next-hop, it means the LSP metric plus the cost of the LSP endpoint to the destination of the prefix.
    5. If same total cost, select lowest endpoint to destination cost.
    6. If same endpoint to destination cost, select lowest router-id.

3.4. Segment Routing in Shortest Path Forwarding

OSPF can be configured with segment routing in shortest path forwarding using the same procedures as those used to configure IS-IS. See Segment Routing in Shortest Path Forwarding in the IS-IS section for more information.

3.4.1. LFA Protection Using Segment Routing Backup Node SID

Note:

Backup node SID configuration is not supported on the 7210 SAS-K 2F6C4T or 7210 SAS-K 3SFP+ 8C. The 7210 SAS operates as the AGN node, and the 7750 SR router must be configured as the ABR with the backup node SID configured on it.

In MPLS deployments across multiple IGP areas or domains, such as in seamless MPLS design, it is challenging to provision FRR local protection in access and metro domains that use a ring, square, or partial mesh topology. To implement IP, LDP, or SR FRR in these topologies, the remote LFA feature must be implemented. Remote LFA provides a segment routing (SR) tunneled LFA next hop for an IP prefix, an LDP tunnel, or an SR tunnel. For prefixes outside of the area or domain, the access or aggregation router must push four labels: service label, BGP label for the destination PE, LDP/RSVP/SR label to reach the exit ABR/ASBR, and one label for the remote LFA next hop. Small routers deployed in these parts of the network have limited MPLS label stack size support.

Figure 7 shows the label stack required for the primary next hop and the remote LFA next hop computed by aggregation node AGN2 for the inter-area prefix of a remote PE. For an inter-area BGP label unicast route prefix for which ABR1 is the primary exit ABR, AGN2 resolves the prefix to the transport tunnel of ABR1 and therefore, uses the remote LFA next hop of ABR1 for protection. The primary next hop uses two transport labels plus a service label. The remote LFA next hop for ABR1 uses PQ node AGN5 and pushes three transport labels plus a service label.

Seamless MPLS with Fast Restoration requires up to four labels to be pushed by AGN2, as shown in Figure 7.

Figure 7:  Label Stack for Remote LFA in Ring Topology 

The objective of the LFA protection with a backup node SID feature is to reduce the label stack pushed by AGN2 for BGP label unicast inter-area prefixes. If link AGN2-AGN1 fails, packets are directed away from the failure and forwarded toward ABR2, which acts as the backup for ABR1 (and vice-versa when ABR2 is the primary exit ABR for the BGP label unicast inter-area prefix). This requires ABR2 to advertise a special label for the loopback of ABR1 that will attract packets normally destined for ABR1. These packets are forwarded by ABR2 to ABR1 via the inter-ABR link.

As a result, AGN2 will push the label advertised by ABR2 to back up ABR1 in addition to the BGP label for the remote PE and the service label. This ensures that the label stack size for the LFA next hop is the same as that of the primary next hop. It is also the same size as the remote LFA next hop for the local prefix within the ring.

3.4.1.1. Detailed Operation of LFA Protection Using Backup Node SID

As shown in Figure 8, LFA for seamless MPLS supports environments where the boundary routers are either:

  1. ABR nodes that connect with iBGP multiple domains, each using a different area of the same IGP instance
  2. ASBR nodes that connect domains running different IGP instances and use iBGP within a domain and eBGP to the other domains
Figure 8:  Backup ABR Node SID 

The following steps describe the configuration and behavior of LFA Protection using Backup Node SID, as shown in Figure 8:

  1. The user configures node SID 100 in ABR1 for its loopback prefix 1.1.1.1/32. This is the regular node SID. ABR1 advertises the prefix SID sub-TLV for this node SID in the IGP and installs the ILM using a unique label.
  2. Each router receiving the prefix sub-TLV for node SID 100 resolves it as described in Segment Routing in Shortest Path Forwarding. Changes to the programming of the backup NHLFE of node SID 100 based on receiving the backup node SID for prefix 1.1.1.1/32 are defined in Duplicate SID Handling.
  3. The user configures a backup node SID 200 in ABR2 for the loopback 1.1.1.1/32 of ABR1. The SID value must be different from that assigned by ABR1 for the same prefix. ABR2 installs the ILM, which performs a swap operation from the label of SID 200 to that of SID 100. The ILM must point to a direct link and next hop to reach 1.1.1.1/32 of ABR1 as its primary next hop. The IGP examines all adjacencies established in the same area as that of prefix 1.1.1.1/32 and determines which ones have ABR1 as a direct neighbor and with the best cost. If more than one adjacency has the best cost, the IGP selects the one with the lowest interface index. If there is no adjacency to reach ABR2, the prefix SID for the backup node is flushed and is not resolved. This prevents the use of any non-direct path to reach ABR1. As a result, any received traffic on the ILM of SID 200 traffic will be blackholed.
  4. If resolved, ABR2 advertises the prefix SID sub-TLV for this backup node SID 200 and indicates in the SR Algorithm field that a modified SPF algorithm, referred to as “Backup-constrained-SPF”, is required to resolve this node SID.
  5. Each router receiving the prefix sub-TLV for the backup node SID 200 performs the following resolution steps. These steps do not require a CLI command to be enabled.
    1. The router determines which router is being backed up. This is achieved by checking the router ID owner of the prefix sub-TLV that was advertised with the same prefix but without the backup flag and which is used as the best route for the prefix. In this case, it should be ABR1. Then the router runs a modified SPF by removing node ABR1 from the topology to resolve the backup node SID 200. The primary next hop should point to the path to ABR2 in the counter clockwise direction of the ring.
      The router will not compute an LFA or a remote LFA for node SID 200 because the main SPF used a modified topology.
    2. The router installs the ILM and primary NHLFE for the backup node SID.
      Only a swap label operation is configured by all routers for the backup node SID. There is no push operation, and no tunnel for the backup node SID is added into the TTM.
    3. The router programs the backup node SID as the LFA backup for the SR tunnel to node SID of 1.1.1.1/32 of ABR1. In other words, each router overrides the remote LFA backup for prefix 1.1.1.1/32, which is normally PQ node AGN5.
    4. If the router is adjacent to ABR1, for example AGN1, it also programs the backup node SID as the LFA backup for the protection of any adjacency SID to ABR1.
  6. When node AGN2 resolves a BGP label route for an inter-area prefix for which the primary ABR exit router is ABR1, it will use the backup node SID of ABR1 as the remote LFA backup instead of the SID to the PQ node (AGN5 in this example) to save on the pushed label stack.
    AGN2 continues to resolve the prefix SID for any remote PE prefix that is summarized into the local area of AGN2 as usual. AGN2 programs a primary next hop and a remote LFA next hop. Remote LFA will use AGN5 as the PQ node and will push two labels, as it would for an intra-area prefix SID. There is no need to use the backup node SID for this prefix SID and force its backup path to go to ABR1. The backup path may exit from ABR2 if the cost from ABR2 to the destination prefix is shorter.
  7. If the user excludes a link from LFA in the IGP instance (config>router>ospf>area>interface>loopfree-alternate-exclude), a backup node SID that resolves to that interface will not be used as a remote LFA backup in the same way as regular LFA or PQ remote LFA next hop behavior.
  8. If the OSPF neighbor of a router is put into overload or if the metric of an OSPF interface to that neighbor is set to LSInfinity (0xFFFF), a backup node SID that resolves to that neighbor will not be used as a remote LFA backup in the same way as regular LFA or PQ remote LFA next hop behavior.
  9. LFA policy is supported for IP next hops only. It is not supported with tunnel next hops such as IGP shortcuts or remote LFA tunnels. A backup node SID is also a tunnel next hop and, therefore, a user-configured LFA policy is not applied to check constraints such as admin-groups and SRLG against the outgoing interface of the selected backup node SID.

3.4.1.2. Duplicate SID Handling

If the IGP issues or receives an LSA/LSP containing a prefix SID sub-TLV for a node SID or a backup node SID with a SID value that is a duplicate of an existing SID or backup node SID, the resolution in Table 24 is followed.

Table 24:  Handling of Duplicate SIDs 

Old LSA/LSP

New LSA/LSP

Backup Node SID

Local Backup Node SID

Node SID

Local Node SID

Backup Node SID

Old

New

New

New

Local Backup Node SID

Old

Equal

New

New

Node SID

Old

Old

Equal/Old 1

Equal/New 2

Local Node SID

Old

Old

Equal/Old 1

Equal/Old 1

    Notes:

  1. Equal/Old means the following.
    1. If the prefix is duplicate, it is equal and no change is needed. Keep the old LSA/LSP.
    2. If the prefix is not duplicate, still keep the old LSA/LSP.
  2. Equal/New means the following.
    1. If the prefix is duplicate, it is equal and no change is needed. Keep the old LSA/LSP.
    2. If the prefix is not duplicate, pick a new prefix and use the new LSA/LSP.

3.4.1.3. OSPF Control Plane Extensions

All routers supporting OSPF control plane extensions must advertise support of the new algorithm “Backup-constrained-SPF” of value 2 in the SR-Algorithm TLV, which is advertised in the Router Information Opaque LSA. This is in addition to the default supported algorithm “IGP-metric-based-SPF” of value 0. The following shows the encoding of the prefix SID sub-TLV to indicate a node SID of type backup and to indicate the modified SPF algorithm in the SR Algorithm field. The values used in the Flags field and in the Algorithm field are SR OS proprietary.

The new Algorithm (0x2) field and values are used by this feature.

0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              Type             |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Flags     |   Reserved    |      MT-ID    |Algorithm (0x2)|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     SID/Index/Label (variable)                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Table 25 lists OSPF control plane extension flag values.

Table 25:  OSPF Control Plane Extension Fields 

Field

Value

Type

2

Length

variable

Flags

1 octet field

The following flags are defined; the “B” flag is new:

     0  1  2  3  4  5  6  7
   +--+--+--+--+--+--+--+--+
   |  |NP|M |E |V |L | B|  |
   +--+--+--+--+--+--+--+--+

Table 26 describes OSPF control plane extension flags.

Table 26:  OSPF Control Plane Extension Flags 

Flag

Description

NP-Flag

No-PHP flag

If set, the penultimate hop must not pop the prefix SID before delivering the packet to the node that advertised the prefix SID.

M-Flag

Mapping Server Flag

If set, the SID is advertised from the Segment Routing Mapping Server functionality as described in I-D.filsfils-spring-segment-routing-ldp-interop.

E-Flag

Explicit-Null Flag

If set, any upstream neighbor of the prefix SID originator must replace the prefix SID with a prefix SID having an Explicit-NULL value (0 for IPv4) before forwarding the packet.

V-Flag

Value/Index Flag

If set, the prefix SID carries an absolute value. If not set, the prefix SID carries an index.

L-Flag

Local/Global Flag

If set, the value/index carried by the prefix SID has local significance. If not set, then the value/index carried by this sub-TLV has global significance.

B-Flag

This flag is used by the Protection using backup node SID feature. If set, the SID is a backup SID for the prefix. This value is SR OS proprietary.

Other bits

Reserved

These must be zero when sent and are ignored when received.

MT-ID

Multi-Topology ID, as defined in RFC 4915

Algorithm

One octet identifying the algorithm the prefix SID is associated with. A value of (0x2) indicates the modified SPF algorithm, which removes from the topology the node that is backed up by the backup node SID. This value is SR OS proprietary.

SID/Index/Label

Based on the V and L flags, it contains either:

  1. a 32-bit index defining the offset in the SID/Label space advertised by this router
  2. a 24-bit label where the 20 rightmost bits are used for encoding the label value

3.5. OSPF Configuration Process Overview

Figure 9 shows the process to provision basic OSPF parameters.

Figure 9:  OSPF Configuration and Implementation Flow 

3.6. Configuration Notes

This section describes OSPF configuration caveats.

3.6.1. General

  1. Before OSPF can be configured, the router ID must be configured.
  2. The basic OSPF configuration includes at least one area and an associated interface.
  3. All default and command parameters can be modified.

3.6.1.1. OSPF Defaults

The following list summarizes the OSPF configuration defaults:

  1. By default, a router has no configured areas.
  2. An OSPF instance is created in the administratively enabled state.