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 8), 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 8:  Backbone Area 

4.1.1.2. Super Backbone Area

Note: The super backbone is only supported under the VPRN OSPF context.

The 7705 SAR supports 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) (support for basic OSPF at PE-CE links), to provide an MPLS VPN super backbone area. The BGP/OSPF interaction procedures that are supported as part of the super backbone include the following:

1. loop prevention
2. handling LSAs received from the CE
3. sham links
4. managing VPN-IPv4 routes received by BGP

The MPLS VPN super backbone functions like an additional layer of hierarchy in OSPF. The PE routers that connect the OSPF areas to the super backbone function as OSPF ABRs in the OSPF areas to which they are attached. In order to achieve full compatibility, the PE routers can also function as ASBRs in NSSAs.

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

The PE routers insert inter-area routes from other areas into the area where a 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 that the PE is an ABR.

1. If the CE is in the backbone, then the CE assumes that the PE is an ABR linking one or more areas to the backbone.
2. If the CE is not in the backbone, the CE assumes that the backbone is on the other side of the PE.
3. Therefore, the super backbone looks like another area to the CE.

Figure 9:  PE Routers Connected to an MPLS VPN Super Backbone 

In Figure 9, the PE routers are connected to the MPLS VPN super backbone. In order to be able to distinguish if two OSPF instances are the same and require type 3 LSAs to be generated or if they are two separate routing instances that require type 5 external LSAs to be generated, the concept of a domain ID is used.

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

When configuring the super backbone, all destinations learned by PEs with matching domain IDs become inter-area routes.

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

4.1.1.2.1. Sham Link

A sham link is a logical PE-to-PE unnumbered point-to-point interface that rides over the PE-to-PE transport tunnel. A sham link can be associated with any area and can appear as an intra-area link to CE routers attached to different PEs in a VPN.

Figure 10:  Sham Link 

In Figure 10, the link between CE routers CE-3 and CE-4 (shown in red) is a low-speed OC-3/STM-1 link. Because the link establishes an intra-area route connection (backdoor link) between the CE-3 and CE-4 routers, a potential high-speed connection between PE routers PE-1 and PE-2 will not be utilized because OSPF always prefers intra-area links over inter-area links. Even as part of a super backbone configuration, the link between the PE routers is regarded as an inter-area connection.

To prevent the backdoor link from always being the preferred path, a sham link (shown in green) is also constructed as an inter-area link between PE routers. A normal OSPF adjacency is formed and the link-state database is exchanged across the MPLS VPN. As a result, the desired intra-area connectivity is created, and the cost of the sham link and backdoor link can be managed such that the backdoor link becomes a standby link and is used only if the sham link fails.

Note: A sham link is only required with an MPLS VPN configuration if a backdoor link is present.

4.1.1.2.2. Implementing the OSPF Super Backbone

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

1. The OSPF intra-area type 1 and type 2 LSAs advertised by the CE are inserted into the MPLS VPN 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. Because the PEs across the super backbone always act as ABRs, they will generate inter-area route OSPF summary type 3 LSAs.
3. The inter-area route can now be propagated to other OSPF areas by other customer-owned ABRs within the customer site.
4. Customer area 0 (backbone) routes appear as type 3 LSAs when carried across the MPLS VRN using MP-BGP even if the customer area remains area 0.

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

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

From a BGP perspective, the cost is copied into the MED attribute. For information on the MED attribute, see MED Attribute.

4.1.1.2.3. Loop Avoidance

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

4.1.1.2.4. 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 ensures that if any CE router sends the type 3 LSA to a PE router, the PE router does not redistribute it.

4.1.1.2.5. VPN Route Tag

If a particular VRF in a PE is associated with an OSPF instance, then by default the VRF 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 implementations that do not set the DN bit in type 5 LSAs.

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 8 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 function 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: 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. 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 31 lists the types of LSAs generated by routers.

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:

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.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:

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.1.12. Multi-area Adjacencies

By default, an IP interface can belong to one OSPF area only. However, there may be situations in which the user wants to configure an interface to belong to more than one area. This configuration allows the corresponding link to be considered an intra-area link in multiple areas and to be preferred over other higher-cost intra-area links.

For example, as shown in Figure 11, a high-speed backbone link (in area 0) is established between two ABRs (R1 and R2). The user wants traffic between R1 and R2 in area 1 to use that high-speed link as well. Because intra-area paths are preferred over inter-area paths, by default, R1 will always use the lower-speed links in area 1 to route the traffic. To enable area 1 to use the high-speed link, the user can configure the high-speed interface to belong to both area 0 and area 1.

Figure 11:  Multi-area Adjacency 

The 7705 SAR supports the use of a single IP interface in multiple areas as defined in RFC 5185, OSPF Multi-Area Adjacency. With multi-area adjacency, OSPF routers establish multiple adjacencies for different areas over a single logical interface. Each multi-area adjacency is announced as an unnumbered point-to-point link in the configured area by the routers connected to the link. For each area, one logical interface is treated as the primary interface and the other interfaces configured for the area are designated as secondary interfaces.

A logical interface can be configured as the primary interface for one area only. For any other area for which that interface is configured, the interface must be specified as secondary with the command config>router>ospf (ospf3)>area>interface ip-int-name secondary. It is recommended that area 0 (backbone area) be used for the primary interface association.

Multi-area adjacency is supported for OSPF and OSPFv3. It is also supported under the VPRN context.

4.1.13. OSPF Import Policies

By default, OSPF imports all the routes advertised via LSAs. Import policies allow routes that match a certain criteria, such as neighbor IP addresses, to be rejected. Users must use caution when applying import policies, since not using certain routes may result in network stability issues.

Import policies are supported within the base router context and the VPRN context. Import policies are not supported on OSPFv3.

4.4.1. Configuring LFA Using Backup Node SID

LFA using a backup node SID is enabled by configuring a backup node SID at an ABR/ASBR that acts as a backup to the primary exit ABR/ASBR of inter-area/inter-as routes learned as BGP labeled routes.

The user can enter either a label or an index for the backup node SID.

Note: This feature only allows the configuration of a single backup node SID per IGP instance and per ABR/ASBR. In other words, only a pair of ABR/ASBR nodes can back up each other in an IGP domain. Each time the user invokes the above command within the same IGP instance, it overrides any previous configuration of the backup node SID. The same ABR/ASBR can, however, participate in multiple IGP instances and provide backup support within each instance.

4.4.2. Detailed Operation of LFA Protection Using Backup Node SID

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

Figure 13:  Backup ABR Node SID 

The following steps describe the configuration and behavior of LFA Protection using backup node SID:

4.4.3. Duplicate SID Handling

When 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 32 is followed.

4.4.4. 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.

Table 33 lists OSPF control plane extension field values.

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

Table 34 lists OSPF control plane extension flag values.

4.4.5. Topology-Independent LFA for OSPF

OSPFv2 supports topology-independent LFA (TI-LFA), which improves the protection coverage of a network topology by computing and automatically instantiating a repair tunnel to a Q node that is not in the shortest path from the computing node. See Topology-Independent LFA for more information. The information in this section refers to IS-IS but also applies to OSPF.

4.5.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:

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 14 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 14:  Backup Routes Resulting in Micro-loops 

Figure 15 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 15:  LFA Backup Route 

4.5.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.5.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, it is excluded in all areas. However, the loopfree-alternate-exclude command can only be executed under the area in which the specified interface is primary. When the command is executed, the interface is excluded in that area and in all other areas where the interface is secondary. If the user attempts to execute the command under an area where the interface is secondary, the command will fail.

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

4.5.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:

4.5.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:

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.5.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.

When a route next hop policy template is applied to an interface, it is applied in all areas. However, the route-nh-template command can only be executed under the area in which the specified interface is primary. When the command is executed, the template is applied in that area and in all other areas where the interface is secondary. If the user attempts to execute the command under an area where the interface is secondary, the command will fail.

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.8.1. General

4.8.2. Reference Sources

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