4. OSPF

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

Topics in this chapter include:

  1. Overview of OSPF
  2. Bidirectional Forwarding Detection (BFD) for OSPF
  3. Graceful Restart Helper
  4. LDP and IP Fast Reroute (FRR) for OSPF Prefixes
  5. Preconfiguration Requirements
  6. OSPF Configuration Process Overview
  7. Configuration Notes
  8. Configuring OSPF with CLI
  9. OSPF Command Reference

4.1. Overview of OSPF

OSPF (Open Shortest Path First) is an interior gateway protocol (IGP) that is used within large autonomous systems (ASs). An autonomous system is a group of networks and network equipment under a common administration. OSPF is a link-state protocol; each router maintains an identical database (called the link-state database, topological database, or routing information database [RIB]) of the AS, including information about the local state of each router (for example, its usable interfaces and reachable neighbors).

OSPF-TE (OSPF with traffic engineering extensions) is used to advertise reachability information and traffic engineering information such as bandwidth. OSPF routers exchange status, cost, and other relevant interface information with neighboring routers. The information exchange enables all participating routers to establish their link-state database.

OSPF uses a cost metric that represents the status of the link and the bandwidth of the interface in an algorithm to determine the best route to a destination. The algorithm used is called the SPF (shortest path first) or Dijkstra algorithm. Path selection is based on lowest cost, which might not necessarily be the shortest route but is the best route in regards to bandwidth. Each router applies the algorithm to calculate the shortest path to each destination in the network.

When the best route to a particular destination is determined, the route information is sent to the routing table manager (RTM). The RTM may contain more than one best route to a destination from multiple protocols. Because metrics from different protocols are not comparable, the RTM uses preference to select the best route. The route with the lowest preference value is selected. For more information, see Configuring Route Preferences.

The best routes from the RTM are then added to the forwarding table (also known as the forwarding database [or FIB]). All forwarding decisions are based on the information in the forwarding database.

The forwarding (or dropping) of packets is controlled by filters applied to the interface and route policies applied to the OSPF protocol. Refer to the 7705 SAR Router Configuration Guide for information on filters and route policies.

The 7705 SAR implementation of OSPF conforms to OSPF Version 2 specifications presented in RFC 2328, OSPF Version 2 and OSPF Version 3 specifications presented in RFC 2740, OSPF for IPv6. Routers running OSPF can be enabled with minimal configuration. All default and command parameters can be modified.

Changes between OSPF for IPv4 and OSPFv3 for IPv6 include the following.

  1. 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.
  2. OSPFv3 runs on a per-link basis, instead of on a per-IP-subnet basis.
  3. Flooding scope for LSAs has been generalized.
  4. Unlike OSPFv2, OSPFv3 authentication relies on IPV6's authentication header and encapsulating security payload.
  5. Most packets in OSPF for IPv6 are almost as compact as those in OSPF for IPv4, even with the larger IPv6 addresses.
  6. Most field and packet-size limitations present in OSPF for IPv4 have been relaxed.
  7. Option handling has been made more flexible.

The following major OSPF features are supported:

  1. areas – backbone, stub, and not-so-stubby areas (NSSAs)
  2. virtual links
  3. neighbors and adjacencies
  4. link-state advertisements (LSAs)
  5. metrics
  6. authentication (OSPFv2 only)
  7. route redistribution and summarization
  8. OSPF traffic engineering (TE) extensions (to track and advertise available bandwidth (OSPFv2 only)– used by MPLS traffic engineering; that is, RSVP-TE)

4.1.1. OSPF Areas

An autonomous system can be divided into areas, with each area containing a group of networks. An area’s topology is concealed from the rest of the AS, which significantly reduces OSPF protocol traffic (LSA updates), simplifies the network topology, and simplifies the routing table by populating it with summarized routes rather than exact routes on each router. This decrease in LSA updates, link-state database size, and CPU time, all required for OSPF route calculations, results in a decrease in route calculation time.

All routers in an area have identical link-state databases for that area.

Areas within the same AS are linked to each other via area border routers (ABRs). An ABR is a router that belongs to, and passes reachability information between, more than one OSPF area. An ABR maintains a separate topological database for each area it is connected to.

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; that is, routing updates are only passed within the area. In inter-area routing, routing updates are passed between areas.

External routes refer to routing updates passed from another routing protocol into the OSPF domain.

Routers that pass information between an OSPF routing domain and a non-OSPF network are called autonomous system boundary routers (ASBRs).

4.1.1.1. Backbone Area

Every OSPF system requires a backbone area. The OSPF backbone area is uniquely identified as area 0 and uses the area ID 0.0.0.0. All other areas must be connected to the backbone area, either physically or logically. The backbone distributes routing information between areas. If it is not practical or possible to connect an area to the backbone (see area 0.0.0.5 in Figure 6), the ABRs (routers Y and Z in the figure) must be connected via a virtual link. The two ABRs form a point-to-point-like adjacency across the transit area (area 0.0.0.4).

Figure 6:  Backbone Area 

4.1.1.2. Area Border Router

Areas within the same AS are linked to each other via ABRs. An ABR is a router that belongs to, and passes reachability information between, more than one area. An ABR maintains a separate topological database for each area it is connected to.

A base router OSPF instance assumes an ABR role if it is actively attached to two or more different areas with at least one operationally up interface, and one of the attached areas is area 0.

If an ABR has an area 0 adjacency, it always calculates inter-area routes using only backbone summary LSAs. A router connected to multiple areas without an area 0 adjacency calculates inter-area routes using summary LSAs from all actively attached areas. This functionality helps to avoid packet loss in some inter-area scenarios.

4.1.1.3. Stub Area

A stub area is a designated area that does not allow external route advertisements and cannot contain ASBRs. Virtual links cannot pass through stub areas.

To route to external destinations, the ABR of the stub area advertises a single default route into the stub area (0.0.0.0). A default route is the network route used by a router when no other known route exists for a given IP packet’s destination address. All packets for destinations not known by the router’s routing table are sent to the default route and thus out to the network.

This feature reduces the size of the router’s database and reduces OSPF protocol traffic, memory usage, and CPU route calculation time.

In Figure 6, areas 0.0.0.1, 0.0.0.2 and 0.0.0.5 could be configured as stub areas.

4.1.1.4. Not-So-Stubby Area

Another OSPF area type is called a not-so-stubby area (NSSA). NSSAs are similar to stub areas except that limited importing of external routes is allowed. Only routes within the AS are advertised. External routes learned by OSPF routers in the NSSA area are advertised as type 7 LSAs (external route advertisements only within the NSSA area) and are translated by ABRs into type 5 external route advertisements for distribution into other areas of the OSPF domain.

For information on LSA types, see Link-State Advertisements.

An NSSA area cannot be designated as the transit area of a virtual link.

In Figure 6, area 0.0.0.3 could be configured as an NSSA area.

4.1.2. Virtual Links

The backbone area in an OSPF AS must be contiguous and all other areas must be directly connected to the backbone area via an ABR. If it is not practical or possible to physically connect an area to the backbone, virtual links can be used to connect to the backbone through a non-backbone area.

A virtual link functions as a point-to-point link that passes through a transit area. Figure 6 depicts routers Y and Z as the start and end points of the virtual link while area 0.0.0.4 is the transit area. In order to configure virtual links, the router must be an ABR. Virtual links are identified by the router ID of the other endpoint, which is another ABR.

These two endpoint routers must be attached to a common area, called the transit area. The area through which the virtual link passes 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 or terminate in the transit area. The transit area cannot be a stub area or an 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.

4.1.3. Neighbors and Adjacencies

A router uses the OSPF Hello protocol to discover neighbors. Neighbors are routers that interface to a common network. In a broadcast-supported topology, one router sends Hello packets to a multicast address and receives Hello packets in return. Unicast Hello packets are used in non-broadcast topologies.

The neighbors then attempt to form adjacencies by exchanging link-state information with the goal of having identical link-state databases. When the link-state databases of two neighbors are synchronized, they are considered to be adjacent.

4.1.3.1. Designated Routers and Backup Designated Routers

In multi-access broadcast networks, such as Ethernet networks, with at least two attached routers, a designated router and a backup designated router can be elected. The concept of a designated router was developed in order to avoid the formation of adjacencies between all attached routers. Without a designated router, the area would be flooded with LSAs – a router would send LSAs to all its adjacent neighbors, and each in turn would send LSAs to all their neighbors, and so on. This would create multiple copies of the same LSA on the same link.

The designated router reduces the number of adjacencies required because each router forms an adjacency only with the designated router and backup designated router. Only the designated router sends LSAs in multicast format to the rest of the network, reducing the amount of routing protocol traffic and the size of the link-state database. If the designated router fails, the backup designated router becomes active.

The designated router is automatically elected based on priority – the router with the highest priority becomes the designated router and the router with the second-highest priority becomes the backup. If two routers have the same priority, the one with the highest router ID wins.

A router with a priority set to 0 can never become a designated router.

After a designated router is elected, it begins sending Hello packets to all other attached routers in order to form adjacencies.

Note:

  1. In point-to-point networks, where a single pair of routers are connected, no designated or backup designated router is elected. An adjacency must be formed with the neighbor router.
  2. 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.

4.1.4. 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 link-state (or topological) database.

The distribution of topology database updates takes 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 routes.

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 changed information, not the whole topology information or whole link-state database, when a change takes place. From the topological database, each router constructs a tree of shortest paths with itself as root (that is, runs the Dijkstra algorithm). OSPF distributes routing information between routers belonging to a single AS.

Table 30 lists the types of LSAs generated by routers.

Table 30:  LSA Types 

LSA

Definition

Type 1 - Router

Router link advertisements generated by each internal router for each area it belongs to

LSAs are flooded only in the area in which they were originated

Router LSAs list all the router’s links and the state and cost of the links

Type 2 - Network

Network link advertisements generated by designated routers describing the set of routers attached to a particular network

LSAs are flooded only in the area of the router that originated them

Network LSAs list all attached routers, including the designated router

Type 3 - Network Summary

Summary link advertisements generated by ABRs describing inter-area routes (areas within the AS but outside the area they are sent into)

LSAs let internal routers know which destinations can be reached by the ABR

LSAs are sent in both directions – into a non-zero area and into the backbone area

Type 4 - ASBR Summary

Summary link advertisements generated by ABRs indicating the location of ASBRs

An ABR generates a type 4 LSA after receiving a type 5 LSA from an ASBR

Type 5 - AS External

Generated by an ASBR and describes destinations external to the AS or a default route external to the AS

LSAs are flooded to all areas except stub areas

Type 6 - Group membership

Group membership link entry generated by multicast OSPF routers

Not applicable in this release

Type 7 - NSSA External

NSSA external routes generated by an ASBR and used by the NSSA to import external routes into a stub area

LSAs are flooded only to the NSSA

The ABR converts type 7 LSAs into type 5 LSAs before flooding them into the backbone, where they are then flooded to all areas except stub areas

4.1.5. Metrics

In OSPF, all interfaces have a cost value or routing metric used in the OSPF link-state calculation. A metric value is configured based on hop count, bandwidth, or other parameters, to compare different paths through an AS. 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.

Costs are also associated with externally derived routing data, such as those routes learned from an Exterior Gateway Protocol (EGP), for example, BGP, and are passed transparently throughout the AS. This data is kept separate from the OSPF protocol’s link-state data. Each external route can be tagged by the advertising router, enabling the passing of additional information between routers on the boundaries of the AS.

4.1.6. Authentication

Protocol authentication protects against malicious attacks on the communications between routing protocol neighbors. These attacks could either disrupt communications or inject incorrect routing information into the system’s routing table. The use of authentication keys can help to protect routing protocols from these types of attacks.

All OSPF protocol exchanges can be authenticated. This guarantees that only trusted routers can participate in autonomous system routing.

Authentication must be explicitly configured and can be done using two separate mechanisms:

  1. configuration of an explicit authentication key and algorithm using the authentication-key and authentication-type commands
  2. configuration of an authentication keychain using the auth-keychain command

Either the authentication-key command or the auth-keychain command can be used by OSPF, but both cannot be supported at the same time. If both commands are configured, the auth-keychain configuration will be applied and the authentication-key command will be ignored.

By default, authentication is not enabled on an interface.

4.1.6.1. Authentication Key

For explicit authentication keys, OSPF supports plain text (simple password) and Message Digest 5 (MD5) authentication.

When authentication is enabled on a link, a text string password must be configured. Neighbor OSPF routers must supply the password in all OSPF packets they send to an interface.

Plain text authentication includes the password in each OSPF packet sent on a link.

MD5 authentication is more secure than plain text authentication. MD5 authentication uses the password as an encryption key. 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 that is included in each packet. The packet is transmitted to the router neighbor and can only be decrypted if the neighbor has the correct password.

The following authentication commands can be configured at the interface level and the virtual link level:

  1. authentication-key – configures the password used by the OSPF interface or virtual link to verify OSPF protocol packets
  2. authentication-type – enables authentication and specifies the type of authentication to be used on the interface or virtual link, either password or message digest
  3. message-digest-key – used when the message-digest keyword is selected in the authentication-type command.

4.1.6.2. Authentication Keychains

The keychain mechanism allows for the creation of keys used to authenticate OSPF communications. Each keychain entry defines the authentication attributes to be used in authenticating OSPF messages from remote peers or neighbors; the entry must include at least one key entry to be valid. The keychain mechanism also allows authentication keys to be changed without affecting the state of the OSPF adjacencies and supports stronger authentication algorithms than plain text and MD5.

Keychains are configured in the config>system>security>keychain context. For more information about configuring keychains, refer to the 7705 SAR System Management Guide, “TCP Enhanced Authentication and Keychain Authentication”.

The keychain is then associated with an OSPF interface or virtual link with the auth-keychain command.

For a key entry to be valid, it must include a valid key, the current system clock value must be within the begin and end time of the key entry, and the algorithm specified must be supported by OSPF.

OSPF supports the following authentication algorithms:

  1. clear text password
  2. MD5
  3. HMAC-SHA-1-96
  4. HMAC-SHA-1
  5. HMAC-SHA-256

Keychain errors are handled as follows.

  1. If a keychain exists but there are no active key entries with an authentication type that matches the type supported by OSPF, inbound OSPF packets will not be authenticated and will be discarded and no outbound OSPF packets will be sent.
  2. If a keychain exists but the last key entry has expired, a log entry will be raised indicating that all keychain entries have expired.
    OSPF requires that the protocol continue to authenticate inbound and outbound traffic using the last valid authentication key.

4.1.7. Route Redistribution and Summarization

Route redistribution is the taking of routes from one protocol and sending them to another protocol. The 7705 SAR supports the redistribution of static routes into OSPF. These routes are advertised as type 5 or type 7 LSAs (external routes) and are included in each router’s link-state database.

Route redistribution involves the use of routing policies. For information on routing policies, refer to the 7705 SAR Router Configuration Guide, “Route Policies”.

Route summarization allows an ABR or ASBR to summarize routes with the same prefix into a single route and distribute it to other areas. Routes redistributed into OSPF from static routes can also be summarized.

Route summarization reduces the amount of routing information across areas and the size of routing tables on the routers, thus improving the calculation speed of the routers.

4.1.8. OSPF-TE Extensions

OSPF traffic engineering (TE) extensions enable the 7705 SAR to include traffic engineering information in the algorithm in order to calculate the best route to a destination. The traffic information includes:

  1. maximum reservable bandwidth
  2. unreserved bandwidth
  3. available bandwidth

4.1.9. Unnumbered Interfaces

OSPF supports unnumbered point-to-point interfaces with both Ethernet and PPP encapsulations.

Unnumbered interfaces borrow the address from other interfaces such as system, loopback, or another numbered interface, and use it as the source IP address for packets originated from the interface.

This feature supports both dynamic and static ARP for unnumbered interfaces to allow interworking with unnumbered interfaces that may not support dynamic ARP.

An unnumbered interface has IPv4 capability and is used only in cases where IPv4 is active (IPv4-only and mixed IPv4/IPv6 environments). When configuring an unnumbered interface, the interface specified for the unnumbered interface (system or other) must have an IPv4 address. As well, the interface type for the unnumbered interface will automatically be point-to-point.

The unnumbered option can be used in IES and VPRN access interfaces, as well as in a network interface with MPLS support.

4.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. This mask is often displayed as 255.255.255.0.

Two different subnets with the same IP network number might 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).

For example, for a packet destined for IP address 10.1.1.1, 10.1.1.0/24 is a longer (better) match than 10.1.1.0/16. If both entries are in the routing table, the route designated by 10.1.1.0/24 will be used.

4.1.11. OSPF Instances

A routing instance is a routing entity for a router. The 7705 SAR supports the default routing instance only; it does not support multiple instances. The default routing instance is associated with the global routing table.

4.2. Bidirectional Forwarding Detection (BFD) for OSPF

BFD is a simple protocol for detecting failures in a network. BFD uses a “hello” mechanism that sends control messages periodically to the far end and receives periodic control messages from the far end. BFD can detect device, link, and protocol failures.

BFD can be enabled using OSPFv2 (for IPv4) or OSPFv3 (for IPv6). Additionally, a network can be configured to use both OSPFv2 and OSPFv3.

When BFD is enabled on an OSPF interface, the state of the interface is tied to the state of the BFD session between the local node and remote (far-end) node. BFD is implemented in asynchronous mode only, meaning that neither end responds to control messages; rather, the messages are sent in the time period configured at each end.

If the configured number of consecutive BFD missed messages is reached, the link is declared down and OSPF takes the appropriate action (for example, generates an LSA update against the failed link or reroutes around the failed link).

Due to the lightweight nature of BFD, it can detect failures faster than other detection protocols, making it ideal for use in applications such as mobile transport.

4.3. Graceful Restart Helper

Graceful Restart and non-stop routing (NSR) both provide mechanisms that allow neighbor routers to handle a service interruption due to a CSM switchover. Data packets continue to be forwarded along known routes while the OSPF information is being restored or refreshed following the switchover.

With Graceful Restart, a router undergoing a switchover informs its adjacent neighbors and requests a grace period whereby traffic is still forwarded based on the last known good FIB while the router restarts. The neighbor must cooperate with the requesting router in order for the traffic to be forwarded. After the switchover, the neighbor relationships must be re-established.

With NSR (or high-availability service), routing neighbors are unaware of any event on the router performing a switchover. All activity switches to the inactive CSM, which maintains up-to-date routing information, so that routing topology and reachability are not affected. NSR is a more reliable and robust way of handling service interruptions than Graceful Restart.

The 7705 SAR supports NSR; therefore, Graceful Restart is not implemented on the router. However, to support neighbor routers that do not have high-availability service, the 7705 SAR supports Graceful Restart Helper. In Graceful Restart Helper mode, the 7705 SAR never requests graceful restart support. However, if a grace LSA is received from an OSPF neighbor, the 7705 SAR keeps the link toward that neighbor up and operational until the specified grace period in the grace LSA expires or the graceful restart is successful, whichever comes first.

4.4. LDP and IP Fast Reroute (FRR) for OSPF Prefixes

LDP Fast Reroute (FRR) provides local protection for an LDP FEC by precalculating and downloading a primary and a backup NHLFE for the FEC to the LDP FIB. The primary NHLFE corresponds to the label of the FEC received from the primary next hop as per the standard LDP resolution of the FEC prefix in the RTM. The backup NHLFE corresponds to the label received for the same FEC from a Loop-Free Alternate (LFA) next hop.

LDP FRR improves convergence in case of a local link or node failure in the network, by using the label-FEC binding received from the LFA next hop to forward traffic for a given prefix as soon as the primary next hop is not available. This means that a router resumes forwarding LDP packets to a destination prefix using the backup path without waiting for the routing convergence.

IP Fast Reroute (FRR) protects against link or node failures in an IP network by precalculating a backup route to use when the primary next hop is not available. Both routes are populated in the RTM. IP FRR uses an LFA backup next hop to forward in-transit IP packets as soon as the primary next-hop failure is detected and the backup is invoked. This means that a node resumes forwarding IP packets to a destination prefix without waiting for the routing convergence.

Refer to RFC 5286, Basic Specification for IP Fast Reroute: Loop-Free Alternates, for more information on LFAs.

Refer to the 7705 SAR MPLS Guide “LDP Fast Reroute (FRR)” for more information on LDP FRR and to the 7705 SAR Router Configuration Guide, “IP Fast Reroute (FRR)” for more information on IP FRR.

LFAs are supported on IPv4 and IPv6 OSPF prefixes, VPN IPv4 OSPF prefixes, and on inter-area OSPF prefixes. LFAs are also supported on IPv4 IS-IS prefixes and on inter-level IS-IS prefixes. For information on LFA support for IS-IS prefixes, see LDP and IP Fast Reroute (FRR) for IS-IS Prefixes.

IP FRR also provides an LFA backup next hop for the destination prefix of a GRE tunnel used in an SDP or in VPRN auto-bind.

4.4.1. LFA Calculations

In addition to performing the Shortest Path First (SPF) calculation of the primary next hop, OSPF must calculate a backup next hop for all prefixes used by LDP to resolve FECs and for all prefixes used by IP to forward packets. The backup next hops are calculated to provide single link or node protection and to guarantee that when a failure occurs, forwarding traffic through the backup next hop will not result in a loop. These backup next hops are called Loop-Free Alternates (LFAs).

In general, in order to calculate LFAs for a specific destination (D), a router must know the following information:

  1. the shortest-path distance from the calculating router (source) to the destination (SP(S,D))
  2. the shortest-path distance from the router’s OSPF neighbors to the destination (SP(N,D))
  3. the shortest-path distance from the router’s OSPF neighbors to itself (SP(N,S))

A neighbor (N) can provide an LFA only if:

SP(N,D) < SP(N,S) + SP(S,D)

This is known as loop-free criterion.

Figure 7 shows an example of a backup route resulting in a micro-loop. In the example, PE-1 uses PE-2 as its next hop to reach PE-3. The total cost to reach PE-3 via PE-2 is 9. If the link between PE-1 and PE-2 fails, PE-1 can try to use PE-4 as its next hop to reach PE-3. However, the metric between PE-4 and PE-3 is 30. From the perspective of PE-4, forwarding traffic via the PE-1 and PE-2 path to PE-3 is more viable, as the cost is 17 (8 + 5 + 4) versus the direct link cost of 30. Therefore, if PE-1 forwards the traffic to PE-4 in order to reach PE-3, PE-4 forwards it back to PE-1, creating a micro-loop, until the routing protocols converge and declare the link between PE-1 and PE-2 to be down. PE-4 would then be forced to take the direct PE-3 link to reach PE-3 as there is no other alternative. Because PE-4 does not meet the loop-free criterion, it cannot be used as a valid LFA.

Figure 7:  Backup Routes Resulting in Micro-loops 

Figure 8 shows an example of an LFA backup route. In this example, PE-1 again uses PE-2 as its next hop to reach PE-3. The total cost to reach PE-3 via PE-2 is 9. If the link between PE-1 and PE-2 fails, PE-1 can use PE-4 to reach PE-3. From the perspective of PE-4, the direct route to PE-3 is a viable route, as the cost is 3 versus the cost of forwarding traffic via PE-1 (17). Using the direct route does not cause micro-loops and meets the loop-free criterion; therefore, PE-4 can be used as a valid LFA.

Figure 8:  LFA Backup Route 

4.4.1.1. Selection Algorithm

For a point-to-point interface, if SPF finds multiple LFA next hops for a given primary next hop, the selection algorithm is as follows:

  1. SPF will pick the node-protect type over the link-protect type.
  2. If there is more than one LFA next hop within the selected type, it will pick one based on the least cost.
  3. If there is more than one LFA next hop with the same cost, SPF will select the first one. This is not a deterministic selection and will vary for each SPF calculation.

For 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 pseudonode as the primary next hop. Similarly, a link-protect LFA may not guarantee link protection if it goes over the same pseudonode as the primary next hop.

When SPF finds multiple LFA next hops for a given primary next hop, the selection algorithm is as follows:

  1. The algorithm splits the LFA next hops into two sets:
    1. the first set consists of LFA next hops that do not go over the pseudonode used by the primary next hop
    2. the second set consists of LFA next hops that do go over the pseudonode 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 over the link-protect type.
  3. If there is more than one LFA next hop within the selected type, it will pick one based on the least cost.
  4. If there is more than one LFA next hop with the same cost, SPF will select the first one from the remaining set. This is not a deterministic selection and will vary for each SPF calculation.
  5. If no LFA next hop results from step 4, SPF will rerun steps 2 to 4 using the second set.
Note:

A node-protect LFA that does not guarantee link protection can still be selected as a last resort; as well, a link-protect LFA that does not guarantee node protection can still be selected as a last resort.

Both the calculated primary next hop and LFA next hop for a given prefix are programmed into the RTM.

4.4.1.2. LFA Configuration

To enable LFA for OSPF prefixes, enter the following command at the OSPF instance level:

config>router>ospf>loopfree-alternate

or

config>router>ospf3>loopfree-alternate

Next, enable FRR for LDP and/or IP by entering the following commands:

config>router>ldp>fast-reroute

config>router>ip-fast-reroute

These commands instruct the OSPF SPF algorithm to precalculate a primary next hop and LFA next hop for every learned prefix, in order to provide FRR to LDP FEC packets and/or IP packets.

To exclude all interfaces within a specific OSPF area or to exclude a specific IP interface from being included in the LFA SPF calculation, enter the following commands:

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

or

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

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

or

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

If IGP shortcuts are also enabled, any LSPs with a destination address in that OSPF area are not included in the LFA SPF calculation.

If an interface is excluded from the LFA SPF in OSPF, it is excluded in all areas.

Note:

The loopfree-alternate and loopfree-alternate-exclude commands are also supported for OSPF and OSPFv3 within a VPRN service.

4.4.2. IGP Shortcuts (RSVP-TE Tunnels)

Micro-loops, especially in ring topologies, are typically unavoidable. As the number of nodes in a ring increases, the chance of micro-loops occurring also increases. In cases where a valid directly connected next hop cannot be ensured, remote LFAs can be used. Remote LFAs are non-directly connected LFA next hops that are reached via IGP shortcuts.

IGP shortcuts are an MPLS functionality where LSPs are treated like physical links within IGPs; that is, LSPs can be used for next-hop reachability. If an RSVP-TE LSP is used as a shortcut by OSPF or IS-IS, it is included in the SPF calculation as a point-to-point link for both primary and LFA next hops. It can also be advertised to neighbors so that the neighboring nodes can also use the links to reach a destination via the advertised next hop.

IGP shortcuts can be used to simplify remote LFA support and simplify the number of LSPs required in a ring topology.

IGP shortcut functionality provides two options:

  1. LFA-protect option
    This option allows an LSP to be included in both the main SPF and the Loop-Free Alternate (LFA) SPF algorithm. For a given prefix, the LSP can be used either as a primary next hop or as an LFA next hop, but not both.
    If the main SPF calculation selects a tunneled primary next hop for a prefix, the LFA SPF calculation will not select an LFA next hop for this prefix and the protection of this prefix will rely on the RSVP LSP FRR protection.
    If the main SPF calculation selects a direct primary next hop, the LFA SPF calculation will select an LFA next hop for this prefix but will prefer a direct LFA next hop over a tunneled LFA next hop.
  2. LFA-only option
    This option allows an LSP to be included in the LFA SPF algorithm only, which means that the introduction of IGP shortcuts does not affect the main SPF decision. For a given prefix, the main SPF calculation always selects a direct primary next hop. The LFA SPF calculation will select an LFA next hop for this prefix but will prefer a direct LFA next hop over a tunneled LFA next hop.

4.4.2.1. Selection Algorithm

If there are multiple LFA next hops for a primary next hop, the selection algorithm is 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 that use the same outgoing interface as the primary next hop
  2. The algorithm continues with the first set if it is not empty; otherwise, it continues with the second set.
  3. If the second set is used, the algorithm selects the tunneled LFA next hop whose 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 more than one tunneled next hop still exists, it selects the one with the lowest tunnel ID
    3. if none is available, it continues with rest of the tunneled LFAs in the 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 that do not go over the pseudonode used by the primary next hop
    2. the second set consists of LFA next hops that go over the pseudonode 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 over the link-protect type.
  6. If there is more than one LFA next hop within the selected type, it will pick one based on the least total cost for the prefix. For a tunneled next hop, that 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 in the first set (ECMP is configured), it will select the first direct next hop from the remaining set. This is not a deterministic selection and will vary for each SPF calculation.
  8. If there is more than one LFA next hop within the selected type in the second set (ECMP is configured), 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 next hop, it will pick the tunneled next hop with the lowest tunnel ID.

4.4.2.2. Forwarding Adjacency

The forwarding adjacency feature allows OSPF to advertise an RSVP-TE LSP as a link so that other routers in the network can include it in the SPF calculations. The RSVP-TE is advertised as an unnumbered point-to-point link and the link-state advertisement (LSA) has no traffic engineering opaque sub-TLVs as per RFC 3906, Calculating Interior Gateway Protocol (IGP) Routes Over Traffic Engineering Tunnels.

The forwarding adjacency feature can be enabled independently from the IGP shortcut feature. If both features are enabled for a given OSPF instance, forwarding adjacency takes precedence.

When forwarding adjacency is enabled, each node advertises a point-to-point unnumbered link for each best-metric tunnel to the router ID of any endpoint node. The node does not include the tunnels as IGP shortcuts in the SPF calculation directly. Instead, when the LSA advertising the corresponding point-to-point unnumbered link is installed in the local routing database, the node performs an SPF calculation using the link like any other link LSA. The link bidirectional check requires that a regular link or tunnel link exist in the reverse direction for the tunnel to be used in SPF calculations.

4.4.2.3. IGP Shortcut Configuration

To enable the use of IGP shortcuts by OSPF, enter the following command at the OSPF instance level:

config>router>ospf>rsvp-shortcut

To enable forwarding adjacency, enter the following command at the OSPF instance level:

config>router>ospf>advertise-tunnel-link

To enable the use of an RSVP-TE LSP by OSPF as a shortcut or as a forwarding adjacency for resolving IGP routes, enter the following command:

config>router>mpls>lsp>igp-shortcut

When the rsvp-shortcut or advertise-tunnel-link option is enabled at the OSPF instance level, all RSVP-TE LSPs originating on this node are eligible by default as long as the destination address of the LSP, as configured with the config>router> mpls>lsp>to command, corresponds to a router ID of a remote node. A specific LSP can be excluded from being used as a shortcut or forwarding adjacency with the no form of the igp-shortcut command.

4.4.3. LFA SPF Policies

An LFA SPF policy allows the user to apply specific criteria to the selection of a LFA backup next hop for a subset of prefixes that resolve to a specific primary next hop. The 7705 SAR supports the following LFA SPF policy constraints:

  1. admin group
  2. shared risk link group (SRLG)
  3. protection type
  4. next-hop type

A route next-hop policy template must first be created under the global router context. The template contains criteria for the policies in the preceding list.

The template is then applied to prefixes protected by LFA. Each instance of OSPF can apply the same policy template to one or more prefixes and interfaces. If a template is modified, OSPF re-evaluates it for any changes and, if necessary, schedules a new LFA SPF to recalculate the LFA next hop for any prefixes associated with the template.

As a related feature, prefixes that match a prefix entry in a prefix policy can be excluded from the LFA SPF calculation. If a prefix is excluded, it is not included in the LFA SPF calculation, regardless of its priority. Prefix policies are created with the config>router>policy-options>prefix-list command (for information on prefix lists, refer to the 7705 SAR Router Configuration Guide, “Route Policies”.

4.4.3.1. LFA SPF Policy Configuration

To create a route next-hop policy template, enter the following command:

config>router>route-next-hop-policy template

Configure the template with policy constraints for the items in the preceding list.

Note:

To configure constraints for admin groups and SRLG groups, these groups must already be created in the config>router>if-attribute>admin-group and config>router>if-attribute>srlg-group contexts.

Next, apply the template to OSPF interfaces by entering the following command:

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

or

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

The template is applied to all prefixes using the specified interface name.

Optionally, exclude prefixes in a prefix policy from the LFA SPF calculation by entering the following command:

config>router>ospf>loopfree-alternate-exclude prefix-policy

or

config>router>ospf3>loopfree-alternate-exclude prefix-policy

Note:

The lfa-policy-map and loopfree-alternate-exclude commands are also supported for OSPF within a VPRN service.

4.5. Preconfiguration Requirements

The router ID must be available before OSPF can be configured. The router ID is a 32-bit IP address 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 using the config>router>router-id ip-address command
  2. define the system interface using the config>router>interface ip-int-name command (used if the router ID is not specified with the config>router>router-id ip-address command)
    A system interface must have an IP address with a 32-bit subnet mask. 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, the last 4 bytes of the MAC address are used

4.6. OSPF Configuration Process Overview

Figure 9 displays the process to provision basic OSPF parameters.

Figure 9:  OSPF Configuration Process 

4.7. Configuration Notes

4.7.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.
  4. By default, a router has no configured areas.
  5. The base OSPF instance is created in the administratively enabled state.

4.7.2. Reference Sources

For information on supported IETF drafts and standards, as well as standard and proprietary MIBs, refer to Standards and Protocol Support.