OSPF is a routing protocol for IP. It is a link-state protocol, as opposed to a distance-vector protocol. A link-state protocol makes its routing decisions based on the states of the links that connect source and destination machines. The state of the link is a description of that interface and its relationship to its neighboring networking devices. The interface information includes the IP address of the interface, network mask, type of network to which it is connected, routers connected to that network, and so on. This information is propagated in various types of link-state advertisements (LSAs).

A router stores the collection of received LSA data in a link-state database. This database includes LSA data for the links of the router. The contents of the database, when subjected to the Dijkstra algorithm, extract data to create an OSPF routing table. The difference between the database and the routing table is that the database contains a complete collection of raw data; the routing table contains a list of shortest paths to known destinations through specific router interface ports.

OSPF is the IGP of choice because it scales to large networks. It uses areas to partition the network into more manageable sizes and to introduce hierarchy in the network. A router is attached to one or more areas in a network. All of the networking devices in an area maintain the same complete database information about the link states in their area only. They do not know about all link states in the network. The agreement of the database information among the routers in the area is called convergence.

At the intradomain level, OSPF can import routes learned using Intermediate System-to-Intermediate System (IS-IS). OSPF routes can also be exported into IS-IS. At the interdomain level, OSPF can import routes learned using Border Gateway Protocol (BGP). OSPF routes can be exported into BGP.

Unlike Routing Information Protocol (RIP), OSPF does not provide periodic routing updates. On becoming neighbors, OSPF routers establish an adjacency by exchanging and synchronizing their databases. After that, only changed routing information is propagated. Every router in an area advertises the costs and states of its links, sending this information in an LSA. This state information is sent to all OSPF neighbors one hop away. All the OSPF neighbors, in turn, send the state information unchanged. This flooding process continues until all devices in the area have the same link-state database.

To determine the best route to a destination, the software sums all of the costs of the links in a route to a destination. After each router has received routing information from the other networking devices, it runs the shortest path first (SPF) algorithm to calculate the best path to each destination network in the database.

The networking devices running OSPF detect topological changes in the network, flood link-state updates to neighbors, and quickly converge on a new view of the topology. Each OSPF router in the network soon has the same topological view again. OSPF allows multiple equal-cost paths to the same destination. Since all link-state information is flooded and used in the SPF calculation, multiple equal cost paths can be computed and used for routing.

On broadcast and nonbroadcast multiaccess (NBMA) networks, the designated router (DR) or backup DR performs the LSA flooding. On point-to-point networks, flooding simply exits an interface directly to a neighbor.

OSPF runs directly on top of IP; it does not use TCP or User Datagram Protocol (UDP). OSPF performs its own error correction by means of checksums in its packet header and LSAs.

In OSPFv3, the fundamental concepts are the same as OSPF Version 2, except that support is added for the increased address size of IPv6. New LSA types are created to carry IPv6 addresses and prefixes, and the protocol runs on an individual link basis rather than on an individual IP-subnet basis.

OSPF typically requires coordination among many internal routers: Area Border Routers (ABRs), which are routers attached to multiple areas, and Autonomous System Border Routers (ASBRs) that export reroutes from other sources (for example, IS-IS, BGP, or static routes) into the OSPF topology. At a minimum, OSPF-based routers or access servers can be configured with all default parameter values, no authentication, and interfaces assigned to areas. If you intend to customize your environment, you must ensure coordinated configurations of all routers.

The Cisco IOS XR Software implementation of OSPF conforms to the OSPF Version 2 and OSPF Version 3 specifications detailed in the Internet RFC 2328 and RFC 2740, respectively.

The following key features are supported in the Cisco IOS XR Software implementation:

• Hierarchy—CLI hierarchy is supported.

• Inheritance—CLI inheritance is supported.

• Stub areas—Definition of stub areas is supported.

• NSF—Nonstop forwarding is supported.

• SPF throttling—Shortest path first throttling feature is supported.

• LSA throttling—LSA throttling feature is supported.

• Fast convergence—SPF and LSA throttle timers are set, configuring fast convergence. The OSPF LSA throttling feature provides a dynamic mechanism to slow down LSA updates in OSPF during network instability. LSA throttling also allows faster OSPF convergence by providing LSA rate limiting in milliseconds.

• Route redistribution—Routes learned using any IP routing protocol can be redistributed into any other IP routing protocol.

• Authentication—Plain text and MD5 authentication among neighboring routers within an area is supported.

• Routing interface parameters—Configurable parameters supported include interface output cost, retransmission interval, interface transmit delay, router priority, router “dead” and hello intervals, and authentication key.

• Virtual links—Virtual links are supported.

• Not-so-stubby area (NSSA)—RFC 1587 is supported.

• OSPF over demand circuit—RFC 1793 is supported.

Much of the OSPFv3 protocol is the same as in OSPFv2. OSPFv3 is described in RFC 2740.

The key differences between the Cisco IOS XR Software OSPFv3 and OSPFv2 protocols are as follows:

• OSPFv3 expands on OSPFv2 to provide support for IPv6 routing prefixes and the larger size of IPv6 addresses.

• When using an NBMA interface in OSPFv3, users must manually configure the router with the list of neighbors. Neighboring routers are identified by the link local address of the attached interface of the neighbor.

• Unlike in OSPFv2, multiple OSPFv3 processes can be run on a link.

• LSAs in OSPFv3 are expressed as “prefix and prefix length” instead of “address and mask.”

• The router ID is a 32-bit number with no relationship to an IPv6 address.

Before implementing OSPF, you must know what the routing components are and what purpose they serve. They consist of the autonomous system, area types, interior routers, ABRs, and ASBRs.

The OSPF network is composed of ABRs, ASBRs, and interior routers.

An OSPF process is a logical routing entity running OSPF in a physical router. This logical routing entity should not be confused with the logical routing feature that allows a system administrator (known as the Cisco IOS XR Software Owner) to partition the physical box into separate routers.

A physical router can run multiple OSPF processes, although the only reason to do so would be to connect two or more OSPF domains. Each process has its own link-state database. The routes in the routing table are calculated from the link-state database. One OSPF process does not share routes with another OSPF process unless the routes are redistributed.

Each OSPF process is identified by a router ID. The router ID must be unique across the entire routing domain. OSPF obtains a router ID from the following sources, in order of decreasing preference:

• By default, when the OSPF process initializes, it checks if there is a router-id in the checkpointing database.

• The 32-bit numeric value specified by the OSPF router-id command in router configuration mode. (This value can be any 32-bit value. It is not restricted to the IPv4 addresses assigned to interfaces on this router, and need not be a routable IPv4 address.)

• The ITAL selected router-id.

• The primary IPv4 address of an interface over which this OSPF process is running. The first interface address in the OSPF interface is selected.

We recommend that the router ID be set by the router-id command in router configuration mode. Separate OSPF processes could share the same router ID, in which case they cannot reside in the same OSPF routing domain.

OSPF classifies different media into the following types of networks:

• NBMA networks

• Point-to-point networks (POS)

• Broadcast networks (Gigabit Ethernet)

• Point-to-multipoint

You can configure your Cisco IOS XR network as either a broadcast or an NBMA network. Using this feature, you can configure broadcast networks as NBMA networks when, for example, you have routers in your network that do not support multicast addressing.

OSPF Version 2 supports two types of authentication: plain text authentication and MD5 authentication. By default, no authentication is enabled (referred to as null authentication in RFC 2178).

OSPF Version 3 supports all types of authentication except key rollover.

Routers that share a segment (Layer 2 link between two interfaces) become neighbors on that segment. OSPF uses the hello protocol as a neighbor discovery and keep alive mechanism. The hello protocol involves receiving and periodically sending hello packets out each interface. The hello packets list all known OSPF neighbors on the interface. Routers become neighbors when they see themselves listed in the hello packet of the neighbor. After two routers are neighbors, they may proceed to exchange and synchronize their databases, which creates an adjacency. On broadcast and NBMA networks all neighboring routers have an adjacency.

Strict-mode is an OSPF BFD operation mode which keeps the neighbor in a down state until the BFD session is up. The status of the neighbor node shows as awaiting BFD session up in the output of the show ospf neighbor command. This will ensure that client protocols do not operate independent of the declared state of BFD.

OSPF FIB Download Notification feature minimizes the ingress traffic drop for a prolonged period of time after the line card reloads and this feature is enabled by default.

Open Shortest Path First (OSPF) registers with Routing Information Base (RIB) through Interface Table Attribute Library (ITAL) which keeps the interface down until all the routes are downloaded to Forwarding Information Base (FIB). OSPF gets the Interface Up notification when all the routes on the reloaded line card are downloaded through RIB/FIB.

RIB provides notification to registered clients when a:

• Node is lost.

• Node is created.

• Node's FIB upload is completed.

On point-to-point and point-to-multipoint networks, the Cisco IOS XR software floods routing updates to immediate neighbors. No DR or backup DR (BDR) exists; all routing information is flooded to each router.

On broadcast or NBMA segments only, OSPF minimizes the amount of information being exchanged on a segment by choosing one router to be a DR and one router to be a BDR. Thus, the routers on the segment have a central point of contact for information exchange. Instead of each router exchanging routing updates with every other router on the segment, each router exchanges information with the DR and BDR. The DR and BDR relay the information to the other routers. On broadcast network segments the number of OSPF packets is further reduced by the DR and BDR sending such OSPF updates to a multicast IP address that all OSPF routers on the network segment are listening on.

The software looks at the priority of the routers on the segment to determine which routers are the DR and BDR. The router with the highest priority is elected the DR. If there is a tie, then the router with the higher router ID takes precedence. After the DR is elected, the BDR is elected the same way. A router with a router priority set to zero is ineligible to become the DR or BDR.

Type 5 (ASE) LSAs are generated and flooded to all areas except stub areas. For the routers in a stub area to be able to route packets to destinations outside the stub area, a default route is injected by the ABR attached to the stub area.

The cost of the default route is 1 (default) or is determined by the value specified in the default-cost command.

Each of the following LSA types has a different purpose:

• Router LSA (Type 1)—Describes the links that the router has within a single area, and the cost of each link. These LSAs are flooded within an area only. The LSA indicates if the router can compute paths based on quality of service (QoS), whether it is an ABR or ASBR, and if it is one end of a virtual link. Type 1 LSAs are also used to advertise stub networks.

• Network LSA (Type 2)—Describes the link state and cost information for all routers attached to a multiaccess network segment. This LSA lists all the routers that have interfaces attached to the network segment. It is the job of the designated router of a network segment to generate and track the contents of this LSA.

• Summary LSA for ABRs (Type 3)—Advertises internal networks to routers in other areas (interarea routes). Type 3 LSAs may represent a single network or a set of networks aggregated into one prefix. Only ABRs generate summary LSAs.

• Summary LSA for ASBRs (Type 4)—Advertises an ASBR and the cost to reach it. Routers that are trying to reach an external network use these advertisements to determine the best path to the next hop. ABRs generate Type 4 LSAs.

• Autonomous system external LSA (Type 5)—Redistributes routes from another autonomous system, usually from a different routing protocol into OSPF.

• Autonomous system external LSA (Type 7)—Provides for carrying external route information within an NSSA. Type 7 LSAs may be originated by and advertised throughout an NSSA. NSSAs do not receive or originate Type 5 LSAs. Type 7 LSAs are advertised only within a single NSSA. They are not flooded into the backbone area or into any other area by border routers.

• Intra-area-prefix LSAs (Type 9)—A router can originate multiple intra-area-prefix LSAs for every router or transit network, each with a unique link-state ID. The link-state ID for each intra-area-prefix LSA describes its association to either the router LSA or network LSA and contains prefixes for stub and transit networks.

• Area local scope (Type 10)—Opaque LSAs are not flooded past the borders of their associated area.

• Link-state (Type 11)—The LSA is flooded throughout the AS. The flooding scope of Type 11 LSAs are equivalent to the flooding scope of AS-external (Type 5) LSAs. Similar to Type 5 LSAs, the LSA is rejected if a Type 11 opaque LSA is received in a stub area from a neighboring router within the stub area. Type 11 opaque LSAs have these attributes:

  • LSAs are flooded throughout all transit areas.

  • LSAs are not flooded into stub areas from the backbone.

  • LSAs are not originated by routers into their connected stub areas.

Each of the following LSA types has a different purpose:

• Router LSA (Type 1)—Describes the link state and costs of a the router link to the area. These LSAs are flooded within an area only. The LSA indicates whether the router is an ABR or ASBR and if it is one end of a virtual link. Type 1 LSAs are also used to advertise stub networks. In OSPFv3, these LSAs have no address information and are network protocol independent. In OSPFv3, router interface information may be spread across multiple router LSAs. Receivers must concatenate all router LSAs originated by a given router before running the SPF calculation.

• Network LSA (Type 2)—Describes the link state and cost information for all routers attached to a multiaccess network segment. This LSA lists all OSPF routers that have interfaces attached to the network segment. Only the elected designated router for the network segment can generate and track the network LSA for the segment. In OSPFv3, network LSAs have no address information and are network-protocol-independent.

• Interarea-prefix LSA for ABRs (Type 3)—Advertises internal networks to routers in other areas (interarea routes). Type 3 LSAs may represent a single network or set of networks aggregated into one prefix. Only ABRs generate Type 3 LSAs. In OSPFv3, addresses for these LSAs are expressed as “prefix and prefix length” instead of “address and mask.” The default route is expressed as a prefix with length 0.

• Interarea-router LSA for ASBRs (Type 4)—Advertises an ASBR and the cost to reach it. Routers that are trying to reach an external network use these advertisements to determine the best path to the next hop. ABRs generate Type 4 LSAs.

• Autonomous system external LSA (Type 5)—Redistributes routes from another autonomous system, usually from a different routing protocol into OSPF. In OSPFv3, addresses for these LSAs are expressed as “prefix and prefix length” instead of “address and mask.” The default route is expressed as a prefix with length 0.

• Autonomous system external LSA (Type 7)—Provides for carrying external route information within an NSSA. Type 7 LSAs may be originated by and advertised throughout an NSSA. NSSAs do not receive or originate Type 5 LSAs. Type 7 LSAs are advertised only within a single NSSA. They are not flooded into the backbone area or into any other area by border routers.

• Link LSA (Type 8)—Has link-local flooding scope and is never flooded beyond the link with which it is associated. Link LSAs provide the link-local address of the router to all other routers attached to the link or network segment, inform other routers attached to the link of a list of IPv6 prefixes to associate with the link, and allow the router to assert a collection of Options bits to associate with the network LSA that is originated for the link.

• Intra-area-prefix LSAs (Type 9)—A router can originate multiple intra-area-prefix LSAs for every router or transit network, each with a unique link-state ID. The link-state ID for each intra-area-prefix LSA describes its association to either the router LSA or network LSA and contains prefixes for stub and transit networks.

An address prefix occurs in almost all newly defined LSAs. The prefix is represented by three fields: Prefix Length, Prefix Options, and Address Prefix. In OSPFv3, addresses for these LSAs are expressed as “prefix and prefix length” instead of “address and mask.” The default route is expressed as a prefix with length 0.

Inter-area-prefix and intra-area-prefix LSAs carry all IPv6 prefix information that, in IPv4, is included in router LSAs and network LSAs. The Options field in certain LSAs (router LSAs, network LSAs, interarea-router LSAs, and link LSAs) has been expanded to 24 bits to provide support for OSPF in IPv6.

In OSPFv3, the sole function of link-state ID in interarea-prefix LSAs, interarea-router LSAs, and autonomous system external LSAs is to identify individual pieces of the link-state database. All addresses or router IDs that are expressed by the link-state ID in OSPF Version 2 are carried in the body of the LSA in OSPFv3.

In OSPF, routing information from all areas is first summarized to the backbone area by ABRs. The same ABRs, in turn, propagate such received information to their attached areas. Such hierarchical distribution of routing information requires that all areas be connected to the backbone area (Area 0). Occasions might exist for which an area must be defined, but it cannot be physically connected to Area 0. Examples of such an occasion might be if your company makes a new acquisition that includes an OSPF area, or if Area 0 itself is partitioned.

In the case in which an area cannot be connected to Area 0, you must configure a virtual link between that area and Area 0. The two endpoints of a virtual link are ABRs, and the virtual link must be configured in both routers. The common nonbackbone area to which the two routers belong is called a transit area. A virtual link specifies the transit area and the router ID of the other virtual endpoint (the other ABR).

A virtual link cannot be configured through a stub area or NSSA.

Setting an interface as passive disables the sending of routing updates for the neighbors, hence adjacencies will not be formed in OSPF. However, the particular subnet will continue to be advertised to OSPF neighbors. Use the passive command in appropriate mode to suppress the sending of OSPF protocol operation on an interface.

It is recommended to use passive configuration on interfaces that are connecting LAN segments with hosts to the rest of the network, but are not meant to be transit links between routers.

In an MPLS VPN environment, several VPN client sites can be connected in the same OSPF area. If these sites are connected over a backdoor link (intra-area link) and connected over the VPN backbone, all traffic passes over the backdoor link instead of over the VPN backbone, because provider edge routers advertise OSPF routes learned over the VPN backbone as inter-area or external routes that are less preferred than intra-area routes advertised over backdoor links.

To correct this default OSPF behavior in an MPLS VPN, configure a sham link between two provider edge (PE) routers to connect the sites through the MPLS VPN backbone. A sham link represents an intra-area (unnumbered point-to-point) connection between PE routers. All other routers in the area see the sham link and use it to calculate intra-area shortest path first (SPF) routes to the remote site. A cost must be configured with each sham link to determine whether traffic is sent over the backdoor link or sham link.

Configured source and destination addresses serve as the endpoints of the sham link. The source and destination IP addresses must belong to the VRF and must be advertised by Border Gateway Protocol (BGP) as host routes to remote PE routers. The sham-link endpoint addresses should not be advertised by OSPF.

For example, the figure above shows three client sites, each with backdoor links. Because each site runs OSPF within Area 1 configuration, all routing between the sites follows the intra-area path across the backdoor links instead of over the MPLS VPN backbone.

If the backdoor links between the sites are used only for backup purposes, default route selection over the backbone link is not acceptable as it creates undesirable traffic flow. To establish the desired path selection over the MPLS backbone, an additional OSPF intra-area (sham link) link between the ingress and egress PErouters must be created.

A sham link is required between any two VPN sites that belong to the same OSPF area and share an OSPF backdoor link. If no backdoor link exists between sites, no sham link is required.

The figure above shows an MPLS VPN topology where a sham link configuration is necessary. A VPN client has three sites, each with a backdoor link. Two sham links are configured, one between PE-1 and PE-2 and another between PE-2 and PE-3. A sham link is not required between PE-1 and PE-3, because there is no backdoor link between these sites.

When a sham link is configured between the PE routers, the PE routers can populate the virtual routing and forwarding (VRF) table with the OSPF routes learned over the sham link. These OSPF routes have a larger administrative distance than BGP routes. If BGP routes are available, they are preferred over these OSPF routes with the high administrative distance.

OSPFv3 sham link represents the VPN backbone as a single point-to-point connection between the two PEs. OSPFv3 treats the sham link as a point-to-point unnumbered interface, similar to virtual-link. When OSPFv3 sham link is configured, ensure that the route to the remote endpoint of the sham-link exists in the VRF RIB.

If the route to the remote endpoint exists, sham link interface is brought up. If the route to the remote endpoint of the sham-link is removed from the VRF RIB, OSPFv3 receives redistribution callback and brings the sham link down.

The OSPFv2 OSPF SPF Prefix Prioritization feature enables an administrator to converge, in a faster mode, important prefixes during route installation.

When a large number of prefixes must be installed in the Routing Information Base (RIB) and the Forwarding Information Base (FIB), the update duration between the first and last prefix, during SPF, can be significant.

In networks where time-sensitive traffic (for example, VoIP) may transit to the same router along with other traffic flows, it is important to prioritize RIB and FIB updates during SPF for these time-sensitive prefixes.

The OSPFv2OSPF SPF Prefix Prioritization feature provides the administrator with the ability to prioritize important prefixes to be installed, into the RIB during SPF calculations. Important prefixes converge faster among prefixes of the same route type per area. Before RIB and FIB installation, routes and prefixes are assigned to various priority batch queues in the OSPF local RIB, based on specified route policy. The RIB priority batch queues are classified as "critical," "high," "medium," and "low," in the order of decreasing priority.

When enabled, prefix alters the sequence of updating the RIB with this prefix priority:

Critical > High > Medium > Low

As soon as prefix priority is configured, /32 prefixes are no longer preferred by default; they are placed in the low-priority queue, if they are not matched with higher-priority policies. Route policies must be devised to retain /32s in the higher-priority queues (high-priority or medium-priority queues).

Priority is specified using route policy, which can be matched based on IP addresses or route tags. During SPF, a prefix is checked against the specified route policy and is assigned to the appropriate RIB batch priority queue.

These are examples of this scenario:

• If only high-priority route policy is specified, and no route policy is configured for a medium priority:

  • Permitted prefixes are assigned to a high-priority queue.

  • Unmatched prefixes, including /32s, are placed in a low-priority queue.

• If both high-priority and medium-priority route policies are specified, and no maps are specified for critical priority:

  • Permitted prefixes matching high-priority route policy are assigned to a high-priority queue.

  • Permitted prefixes matching medium-priority route policy are placed in a medium-priority queue.

  • Unmatched prefixes, including /32s, are moved to a low-priority queue.

• If both critical-priority and high-priority route policies are specified, and no maps are specified for medium priority:

  • Permitted prefixes matching critical-priority route policy are assigned to a critical-priority queue.

  • Permitted prefixes matching high-priority route policy are assigned to a high-priority queue.

  • Unmatched prefixes, including /32s, are placed in a low-priority queue.

• If only medium-priority route policy is specified and no maps are specified for high priority or critical priority:

  • Permitted prefixes matching medium-priority route policy are assigned to a medium-priority queue.

  • Unmatched prefixes, including /32s, are placed in a low-priority queue.

  Use the [no] spf prefix-priority route-policy rpl command to prioritize OSPFv2OSPF prefix installation into the global RIB during SPF.

  SPF prefix prioritization is disabled by default. In disabled mode, /32 prefixes are installed into the global RIB, before other prefixes. If SPF prioritization is enabled, routes are matched against the route-policy criteria and are assigned to the appropriate priority queue based on the SPF priority set. Unmatched prefixes, including /32s, are placed in the low-priority queue.

  If all /32s are desired in the high-priority queue or medium-priority queue, configure this single route map:

prefix-set ospf-medium-prefixes
  0.0.0.0/0 ge 32
  end-set
  

Redistribution allows different routing protocols to exchange routing information. This technique can be used to allow connectivity to span multiple routing protocols. It is important to remember that the redistribute command controls redistribution into an OSPF process and not from OSPF. See Configuration Examples for Implementing OSPF for an example of route redistribution for OSPF.

OSPF SPF throttling makes it possible to configure SPF scheduling in millisecond intervals and to potentially delay SPF calculations during network instability. SPF is scheduled to calculate the Shortest Path Tree (SPT) when there is a change in topology. One SPF run may include multiple topology change events.

The interval at which the SPF calculations occur is chosen dynamically and based on the frequency of topology changes in the network. The chosen interval is within the boundary of the user-specified value ranges. If network topology is unstable, SPF throttling calculates SPF scheduling intervals to be longer until topology becomes stable.

SPF calculations occur at the interval set by the timers throttle spf command. The wait interval indicates the amount of time to wait until the next SPF calculation occurs. Each wait interval after that calculation is twice as long as the previous interval until the interval reaches the maximum wait time specified.

The SPF timing can be better explained using an example. In this example, the start interval is set at 5 milliseconds (ms), initial wait interval at 1000 ms, and maximum wait time at 90,000 ms.

  timers spf 5 1000 90000
  
  

Notice that the wait interval between SPF calculations doubles when at least one topology change event is received during the previous wait interval. After the maximum wait time is reached, the wait interval remains the same until the topology stabilizes and no event is received in that interval.

If the first topology change event is received after the current wait interval, the SPF calculation is delayed by the amount of time specified as the start interval. The subsequent wait intervals continue to follow the dynamic pattern.

If the first topology change event occurs after the maximum wait interval begins, the SPF calculation is again scheduled at the start interval and subsequent wait intervals are reset according to the parameters specified in the timers throttle spf command. Notice in the following figure that a topology change event was received after the start of the maximum wait time interval and that the SPF intervals have been reset.

Cisco IOS XR Software NSF for OSPF Version 2 allows for the forwarding of data packets to continue along known routes while the routing protocol information is being restored following a process restart or failover. With NSF, peer networking devices do not experience routing flaps. During process restart or failover, data traffic is forwarded through intelligent line cards while the standby Route Processor (RP) assumes control from the failed RP. The ability of line cards to remain up through a process restart, and to be kept current with the Forwarding Information Base (FIB) on the active RP is key to Cisco IOS XR Software NSF operation.

Routing protocols, such as OSPF, run only on the active RP or DRP and receive routing updates from their neighbor routers. When an OSPF NSF-capable router performs a process restart, it must perform two tasks to resynchronize its link-state database with its OSPF neighbors. First, it must relearn the available OSPF neighbors on the network without causing a reset of the neighbor relationship. Second, it must reacquire the contents of the link-state database for the network.

As quickly as possible after an RP failover or process restart, the NSF-capable router sends an OSPF NSF signal to neighboring NSF-aware devices. This signal is in the form of a link-local LSA generated by the failed-over router. Neighbor networking devices recognize this signal as a cue that the neighbor relationship with this router should not be reset. As the NSF-capable router receives signals from other routers on the network, it can begin to rebuild its neighbor list.

After neighbor relationships are reestablished, the NSF-capable router begins to resynchronize its database with all of its NSF-aware neighbors. At this point, the routing information is exchanged between the OSPF neighbors. After this exchange is completed, the NSF-capable device uses the routing information to remove stale routes, update the RIB, and update the FIB with the new forwarding information. OSPF on the router and the OSPF neighbors are now fully converged.

The OSPFv3 Graceful Shutdown feature preserves the data plane capability in these circumstances:

• RP failure resulting in a switch-over to the backup processor

• Planned OSPFv3 process restart, such as a restart resulting from a software upgrade or downgrade

• Unplanned OSPFv3 process restart, such as a restart resulting from a process crash

In addition, OSPFv3 will unilaterally shutdown and enter the exited state when a critical memory event, indicating the processor is critically low on available memory, is received from the sysmon watch dog process.

This feature supports nonstop data forwarding on established routes while the OSPFv3 routing protocol restarts. Therefore, this feature enhances high availability of IPv6 forwarding.

OSPFv2 warm standby provides high availability across RP switchovers. With warm standby extensions, each process running on the active RP has a corresponding standby process started on the standby RP. A standby OSPF process can send and receive OSPF packets with no performance impact to the active OSPF process.

Nonstop routing (NSR) allows an RP failover, process restart, or in-service upgrade to be invisible to peer routers and ensures that there is minimal performance or processing impact. Routing protocol interactions between routers are not impacted by NSR. NSR is built on the warm standby extensions. NSR alleviates the requirement for Cisco NSF and IETF graceful restart protocol extensions.

Note	It is recommended to set the hello timer interval to the default of 10 seconds. OSPF sessions may flap during switchover if hello-interval timer configured is less then default value.

This feature helps OSPFv3 to initialize itself prior to Fail over (FO) and be ready to function before the failure occurs. It reduces the downtime during switchover. By default, the router sends hello packets every 40 seconds.

With warm standby process for each OSPF process running on the Active Route Processor, the corresponding OSPF process must start on the Standby RP. There are no changes in configuration for this feature.

Warm-Standby is always enabled. This is an advantage for the systems running OSPFv3 as their IGP when they do RP failover.

The multicast-intact feature provides the ability to run multicast routing (PIM) when IGP shortcuts are configured and active on the router. Both OSPFv2 and IS-IS support the multicast-intact feature.

You can enable multicast-intact in the IGP when multicast routing protocols (PIM) are configured and IGP shortcuts are configured on the router. IGP shortcuts are MPLS tunnels that are exposed to IGP. The IGP routes IP traffic over these tunnels to destinations that are downstream from the egress router of the tunnel (from an SPF perspective). PIM cannot use IGP shortcuts for propagating PIM joins, because reverse path forwarding (RPF) cannot work across a unidirectional tunnel.

When you enable multicast-intact on an IGP, the IGP publishes a parallel or alternate set of equal-cost next hops for use by PIM. These next hops are called mcast-intact next hops. The mcast-intact next hops have the following attributes:

• They are guaranteed not to contain any IGP shortcuts.

• They are not used for unicast routing but are used only by PIM to look up an IPv4 next-hop to a PIM source.

• They are not published to the FIB.

• When multicast-intact is enabled on an IGP, all IPv4 destinations that were learned through link-state advertisements are published with a set equal-cost mcast-intact next hops to the RIB. This attribute applies even when the native next hops have no IGP shortcuts.

In OSPF, the max-paths (number of equal-cost next hops) limit is applied separately to the native and mcast-intact next hops. The number of equal cost mcast-intact next hops is the same as that configured for the native next hops.

When a router learns multiple routes to a specific network by using multiple routing processes (or routing protocols), it installs the route with the lowest administrative distance in the routing table. Sometimes the router must select a route from among many learned by using the same routing process with the same administrative distance. In this case, the router chooses the path with the lowest cost (or metric) to the destination. Each routing process calculates its cost differently; the costs may need to be manipulated to achieve load balancing.

OSPF performs load balancing automatically. If OSPF finds that it can reach a destination through more than one interface and each path has the same cost, it installs each path in the routing table. The only restriction on the number of paths to the same destination is controlled by the maximum-paths (OSPF) command.

The range for maximum paths is from 1 to 8 and the default number of maximum paths is 8.

Transit-only networks that connect two routers are usually configured with routing IP addresses that are advertised in the Links State Advertisements (LSAs). However, these prefixes are not needed for data traffic. Suppressing these prefixes would reduce the number of links in LSAs, thereby improving convergence and also reducing the vulnerability of potential remote attacks.

Prefixes can be suppressed for an OSPF process, an OSPF area, or for specific interfaces of a router.

Configure Prefix Suppression for a Router Running OSPF

Use the procedure in this section to configure prefix suppression for an OSPF process on a router.

Note

If you suppress prefixes for an OSPF process on a router, the suppression is valid for all interfaces and areas associated with the router. When prefix suppression is configured on an NSSA ASBR, all interfaces on the routers have their prefixes suppressed, and the Type 7 LSAs have a forwarding address of 0. This stops the translation of Type 7 LSAs to Type 5 by the NSSA ABR. The workaround for this is to configure at least one loopback interface in the NSSA area, or one interface with prefix suppression disabled, so that the interface address is selected as the forwarding address for all the Type 7 LSAs.

1. Enter the global configuration mode and configure the interfaces of the router.

   RP/0/# configure
   RP/0/(config)# interface GigabitEthernet 0/0/0/1
   RP/0/(config-if)# ipv4 address 10.1.1.1 255.255.255.0
   RP/0/(config-if)# no shut
   RP/0/(config-if)# exit
   RP/0/(config)# interface Loopback 0
   RP/0/(config-if)# ipv4 address 10.10.10.10 255.255.255.255
   RP/0/(config-if)# no shut
   RP/0/(config-if)# exit

2. Configure the OSPF process with prefix suppression.

   RP/0/# configure
   RP/0/(config)# router ospf pfx
   RP/0/(config-ospf)# router-id 10.10.10.10
   RP/0/(config-ospf)# prefix-suppression

3. Add the configured interfaces to the OSPF area.

   RP/0/(config-ospf)# area 0
   RP/0/(config-ospf-ar)# interface Loopback 0 
   RP/0/(config-ospf-ar-if)# exit 
   RP/0/(config-ospf-ar)# interface GigabitEthernet 0/0/0/1
   RP/0/(config-ospf-ar-if)# network point-to-point

4. Exit the OSPF area configuration mode and commit your configuration.

   RP/0/(config-ospf-ar-if)# exit
   RP/0/(config-ospf-ar)# exit
   RP/0/(config-ospf)# exit
   RP/0/(config)# commit
   RP/0/(config)# exit

5. Confirm your configuration.

   RP/0/# show running-configuration 
   ...
   interface Loopback0
    ipv4 address 10.10.10.10 255.255.255.255
   !
   interface GigabitEthernet0/0/0/1
    ipv4 address 10.1.1.1 255.255.255.0
   !
   router ospf pfx
    router-id 10.10.10.10
    prefix-suppression
    area 0
     interface GigabitEthernet0/0/0/1
      network point-to-point
     !
    !
   !

6. Verify whether prefix suppression is enabled.

   RP/0/# show ospf interface
   Fri Jun 17 15:13:08.470 IST
   
   Interfaces for OSPF 1
   
   GigabitEthernet0/0/0/1 is up, line protocol is up 
     Internet Address 10.1.1.1/24, Area 0
     Process ID 1, Router ID 10.10.10.10, Network Type BROADCAST, Cost: 1
     Transmit Delay is 1 sec, State BDR, Priority 1, MTU 1500, MaxPktSz 1500
     Designated Router (ID) 10.10.10.20, Interface address 10.1.1.2
     Backup Designated router (ID) 10.10.10.30, Interface address 10.1.1.3
     Primary addresses not advertised
     Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
       Hello due in 00:00:06:898
     Index 2/2, flood queue length 0
     Next 0(0)/0(0)
     Last flood scan length is 2, maximum is 2
     Last flood scan time is 0 msec, maximum is 0 msec
     LS Ack List: current length 0, high water mark 2
     Neighbor Count is 1, Adjacent neighbor count is 1
       Adjacent with neighbor 10.10.10.30  (Designated Router)
     Suppress hello for 0 neighbor(s)
     Multi-area interface Count is 0
   

   If your output verifies that primary addresses are not advertised, then you have successfully configured prefix suppression for the OSPF process on the router.

Configure Prefix Suppression for an OSPF Area

Use the procedure in this section to configure prefix suppression for an OSPF area.

Note	If you suppress prefixes on an area, the suppression is valid for all interfaces associated with the area.

1. Enter the global configuration mode and configure the interfaces of the router.

   RP/0/# configure
   RP/0/(config)# interface GigabitEthernet 0/0/0/1
   RP/0/(config-if)# ipv4 address 10.1.1.1 255.255.255.0
   RP/0/(config-if)# no shut
   RP/0/(config-if)# exit
   RP/0/(config)# interface Loopback 0
   RP/0/(config-if)# ipv4 address 10.10.10.10 255.255.255.255
   RP/0/(config-if)# no shut
   RP/0/(config-if)# exit

2. Configure the OSPF area with prefix suppression.

   RP/0/# configure
   RP/0/(config)# router ospf pfx
   RP/0/(config-ospf)# router-id 10.10.10.10
   RP/0/(config-ospf)# area 0
   RP/0/(config-ospf-ar)# prefix-suppression

3. Add the configured interfaces to the OSPF area.

   RP/0/(config-ospf-ar)# interface Loopback 0 
   RP/0/(config-ospf-ar-if)# exit 
   RP/0/(config-ospf-ar)# interface GigabitEthernet 0/0/0/1
   RP/0/(config-ospf-ar-if)# network point-to-point

4. Exit the OSPF area configuration mode and commit your configuration.

   RP/0/(config-ospf-ar-if)# exit
   RP/0/(config-ospf-ar)# exit
   RP/0/(config-ospf)# exit
   RP/0/(config)# commit
   RP/0/(config)# exit

5. Confirm your configuration.

   RP/0/# show running-configuration 
   ...
   interface Loopback0
    ipv4 address 10.10.10.10 255.255.255.255
   !
   interface GigabitEthernet0/0/0/1
    ipv4 address 10.1.1.1 255.255.255.0
   !
   router ospf pfx
    router-id 10.10.10.10
    area 0
     prefix-suppression
     interface GigabitEthernet0/0/0/1
      network point-to-point
     !
    !
   !

6. Verify if prefix suppression is enabled.

   RP/0/# show ospf interface
   Fri Jun 17 15:13:08.470 IST
   
   Interfaces for OSPF 1
   
   GigabitEthernet0/0/0/1 is up, line protocol is up 
     Internet Address 10.1.1.1/24, Area 0
     Process ID 1, Router ID 10.10.10.10, Network Type BROADCAST, Cost: 1
     Transmit Delay is 1 sec, State BDR, Priority 1, MTU 1500, MaxPktSz 1500
     Designated Router (ID) 10.10.10.20, Interface address 10.1.1.2
     Backup Designated router (ID) 10.10.10.30, Interface address 10.1.1.3
     Primary addresses not advertised
     Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
       Hello due in 00:00:06:898
     Index 2/2, flood queue length 0
     Next 0(0)/0(0)
     Last flood scan length is 2, maximum is 2
     Last flood scan time is 0 msec, maximum is 0 msec
     LS Ack List: current length 0, high water mark 2
     Neighbor Count is 1, Adjacent neighbor count is 1
       Adjacent with neighbor 10.10.10.30  (Designated Router)
     Suppress hello for 0 neighbor(s)
     Multi-area interface Count is 0
   

   If your output verifies that primary addresses are not advertised, then you have successfully configured prefix suppression for the OSPF area.

Configure Prefix Suppression for an OSPF Interface

Use the procedure in this section to configure prefix suppression for an OSPF interface.

Note	If you suppress prefixes on an interface, suppression is valid only on that interface, and all other interfaces must be configured separately with prefix suppression.

1. Enter the global configuration mode and configure the interfaces of the router.

   RP/0/# configure
   RP/0/(config)# interface GigabitEthernet 0/0/0/1
   RP/0/(config-if)# ipv4 address 10.1.1.1 255.255.255.0
   RP/0/(config-if)# no shut
   RP/0/(config-if)# exit
   RP/0/(config)# interface Loopback 0
   RP/0/(config-if)# ipv4 address 10.10.10.10 255.255.255.255
   RP/0/(config-if)# no shut
   RP/0/(config-if)# exit

2. Configure the OSPF area.

   RP/0/# configure
   RP/0/(config)# router ospf pfx
   RP/0/(config-ospf)# router-id 10.10.10.10
   RP/0/(config-ospf)# area 0

3. Add the configured interfaces to the OSPF area, and configure prefix suppression on the required interface.

   RP/0/(config-ospf-ar)# interface Loopback 0 
   RP/0/(config-ospf-ar-if)# exit 
   RP/0/(config-ospf-ar)# interface GigabitEthernet 0/0/0/1
   RP/0/(config-ospf-ar-if)# network point-to-point
   RP/0/(config-ospf-ar-if)# prefix-suppression

4. Exit the OSPF area configuration mode and commit your configuration.

   RP/0/(config-ospf-ar-if)# exit
   RP/0/(config-ospf-ar)# exit
   RP/0/(config-ospf)# exit
   RP/0/(config)# commit
   RP/0/(config)# exit

5. Confirm your configuration.

   RP/0/# show running-configuration 
   ...
   interface Loopback0
    ipv4 address 10.10.10.10 255.255.255.255
   !
   interface GigabitEthernet0/0/0/1
    ipv4 address 10.1.1.1 255.255.255.0
   !
   router ospf pfx
    router-id 10.10.10.10
    area 0
     interface GigabitEthernet0/0/0/1
      network point-to-point
      prefix-suppression
     !
    !
   !

6. Verify if prefix suppression is enabled.

   RP/0/# show ospf interface
   Fri Jun 17 15:13:08.470 IST
   
   Interfaces for OSPF 1
   
   GigabitEthernet0/0/0/1 is up, line protocol is up 
     Internet Address 10.1.1.1/24, Area 0
     Process ID 1, Router ID 10.10.10.10, Network Type BROADCAST, Cost: 1
     Transmit Delay is 1 sec, State BDR, Priority 1, MTU 1500, MaxPktSz 1500
     Designated Router (ID) 10.10.10.20, Interface address 10.1.1.2
     Backup Designated router (ID) 10.10.10.30, Interface address 10.1.1.3
     Primary addresses not advertised
     Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
       Hello due in 00:00:06:898
     Index 2/2, flood queue length 0
     Next 0(0)/0(0)
     Last flood scan length is 2, maximum is 2
     Last flood scan time is 0 msec, maximum is 0 msec
     LS Ack List: current length 0, high water mark 2
     Neighbor Count is 1, Adjacent neighbor count is 1
       Adjacent with neighbor 10.10.10.30  (Designated Router)
     Suppress hello for 0 neighbor(s)
     Multi-area interface Count is 0
   

   If your output verifies that primary addresses are not advertised, then you have successfully configured prefix suppression on the interface.

Transit-only networks that connect two routers are usually configured with routing IP addresses that are advertised in the Links State Advertisements (LSAs). However, these prefixes are not needed for data traffic. Suppressing these prefixes would reduce the number of links in LSAs, thereby improving convergence and also reducing the vulnerability of potential remote attacks.

Prefixes can be suppressed for an OSPF process, an OSPF area, or for specific interfaces of a router.

Configure Prefix Suppression for a Router Running OSPFv3

Use the procedure in this section to configure prefix suppression for an OSPFv3 process on a router.

Note

If you suppress prefixes for an OSPF process on a router, the suppression is valid for all interfaces and areas associated with the router. When prefix suppression is configured on an NSSA ASBR, all interfaces on the routers have their prefixes suppressed, and the Type 7 LSAs have a forwarding address of 0. This stops the translation of Type 7 LSAs to Type 5 by the NSSA ABR. The workaround for this is to configure at least one loopback interface in the NSSA area, or one interface with prefix suppression disabled, so that the interface address is selected as the forwarding address for all the Type 7 LSAs.

1. Enter the global configuration mode and configure the interfaces of the router.

   RP/0/# configure
   RP/0/(config)# interface GigabitEthernet 0/0/0/1
   RP/0/(config-if)# ipv6 address 2008:DB8::1/64
   RP/0/(config-if)# no shut
   RP/0/(config-if)# exit
   RP/0/(config)# interface Loopback 0
   RP/0/(config-if)# ipv6 address ::1/128
   RP/0/(config-if)# no shut
   RP/0/(config-if)# exit

2. Configure the OSPFv3 process with prefix suppression.

   RP/0/# configure
   RP/0/(config)# router ospfv3 pfx
   RP/0/(config-ospfv3)# router-id 10.10.10.10
   RP/0/(config-ospfv3)# prefix-suppression

3. Add the configured interfaces to the OSPFv3 area.

   RP/0/(config-ospfv3)# area 0
   RP/0/(config-ospfv3-ar)# interface Loopback 0 
   RP/0/(config-ospfv3-ar-if)# exit 
   RP/0/(config-ospfv3-ar)# interface GigabitEthernet 0/0/0/1
   RP/0/(config-ospfv3-ar-if)# network point-to-point

4. Exit the OSPFv3 area configuration mode and commit your configuration.

   RP/0/(config-ospfv3-ar-if)# exit
   RP/0/(config-ospfv3-ar)# exit
   RP/0/(config-ospfv3)# exit
   RP/0/(config)# commit
   RP/0/(config)# exit

5. Confirm your configuration.

   RP/0/# show running-configuration 
   ...
   interface Loopback0
    ipv6 address ::1/128
   !
   interface GigabitEthernet0/0/0/1
    ipv6 address 2008:DB8::1/64
   !
   router ospfv3 pfx
    router-id 10.10.10.10
    prefix-suppression
    area 0
     interface GigabitEthernet0/0/0/1
      network point-to-point
     !
    !
   !

6. Verify whether prefix suppression is enabled.

   RP/0/# show ospfv3 interface
   Fri Jun 17 15:13:08.470 IST
   GigabitEthernet0/0/0/2 is up, line protocol is up
     Link Local address fe80::45:caff:feaf:72af, Interface ID 5
     Area 0, Process ID pfx, Instance ID 0, Router ID 10.10.10.10
     Network Type BROADCAST, Cost: 1
     Transmit Delay is 1 sec, State DOWN, Priority 1 
     No designated router on this network
     No backup designated router on this network
     Addresses not advertised
     Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
     Index 0/1/1, flood queue length 0
     Next 0(0)/0(0)/0(0)
     Last flood scan length is 0, maximum is 0
     Last flood scan time is 0 msec, maximum is 0 msec
     Neighbor Count is 0, Adjacent neighbor count is 0
     Suppress hello for 0 neighbor(s)
     Reference count is 0 
   

   If your output verifies that primary addresses are not advertised, then you have successfully configured prefix suppression for the OSPFv3 process on the router.

Configure Prefix Suppression for an OSPFv3 Area

Use the procedure in this section to configure prefix suppression for an OSPFv3 area.

Note	If you suppress prefixes on an area, the suppression is valid for all interfaces associated with the area.

1. Enter the global configuration mode and configure the interfaces of the router.

   RP/0/# configure
   RP/0/(config)# interface GigabitEthernet 0/0/0/1
   RP/0/(config-if)# ipv6 address 2008:DB8::1/64
   RP/0/(config-if)# no shut
   RP/0/(config-if)# exit
   RP/0/(config)# interface Loopback 0
   RP/0/(config-if)# ipv6 address ::1/128
   RP/0/(config-if)# no shut
   RP/0/(config-if)# exit

2. Configure the OSPFv3 area with prefix suppression.

   RP/0/# configure
   RP/0/(config)# router ospfv3 pfx
   RP/0/(config-ospfv3)# router-id 10.10.10.10
   RP/0/(config-ospfv3)# area 0
   RP/0/(config-ospfv3-ar)# prefix-suppression

3. Add the configured interfaces to the OSPFv3 area.

   RP/0/(config-ospfv3-ar)# interface Loopback 0 
   RP/0/(config-ospfv3-ar-if)# exit 
   RP/0/(config-ospfv3-ar)# interface GigabitEthernet 0/0/0/1
   RP/0/(config-ospfv3-ar-if)# network point-to-point

4. Exit the OSPFv3 area configuration mode and commit your configuration.

   RP/0/(config-ospfv3-ar-if)# exit
   RP/0/(config-ospfv3-ar)# exit
   RP/0/(config-ospfv3)# exit
   RP/0/(config)# commit
   RP/0/(config)# exit

5. Confirm your configuration.

   RP/0/# show running-configuration
   ...
   interface Loopback0
    ipv6 address ::1/128
   !
   interface GigabitEthernet0/0/0/1
    ipv6 address 2008:DB8::1/64
   !
   router ospfv3 pfx
    router-id 10.10.10.10
    area 0
     prefix-suppression
     interface GigabitEthernet0/0/0/1
      network point-to-point
     !
    !
   !

6. Verify if prefix suppression is enabled.

   RP/0/# show ospfv3 interface
   Fri Jun 17 15:13:08.470 IST
   GigabitEthernet0/0/0/2 is up, line protocol is up
     Link Local address fe80::45:caff:feaf:72af, Interface ID 5
     Area 0, Process ID pfx, Instance ID 0, Router ID 10.10.10.10
     Network Type BROADCAST, Cost: 1
     Transmit Delay is 1 sec, State DOWN, Priority 1 
     No designated router on this network
     No backup designated router on this network
     Addresses not advertised
     Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
     Index 0/1/1, flood queue length 0
     Next 0(0)/0(0)/0(0)
     Last flood scan length is 0, maximum is 0
     Last flood scan time is 0 msec, maximum is 0 msec
     Neighbor Count is 0, Adjacent neighbor count is 0
     Suppress hello for 0 neighbor(s)
     Reference count is 0 
   

   If your output verifies that primary addresses are not advertised, then you have successfully configured prefix suppression for the OSPFv3 area.

Configure Prefix Suppression for an OSPFv3 Interface

Use the procedure in this section to configure prefix suppression for an OSPFv3 interface.

Note	If you suppress prefixes on an interface, suppression is valid only on that interface, and all other interfaces must be configured separately with prefix suppression.

1. Enter the global configuration mode and configure the interfaces of the router.

   RP/0/# configure
   RP/0/(config)# interface GigabitEthernet 0/0/0/1
   RP/0/(config-if)# ipv6 address 2008:DB8::1/64
   RP/0/(config-if)# no shut
   RP/0/(config-if)# exit
   RP/0/(config)# interface loopback 0
   RP/0/(config-if)# ipv6 address ::1/128
   RP/0/(config-if)# no shut
   RP/0/(config-if)# exit

2. Configure the OSPFv3 area.

   RP/0/# configure
   RP/0/(config)# router ospfv3 pfx
   RP/0/(config-ospfv3)# router-id 10.10.10.10
   RP/0/(config-ospfv3)# area 0

3. Add the configured interfaces to the OSPFv3 area, and configure prefix suppression on the required interface.

   RP/0/(config-ospfv3-ar)# interface Loopback 0 
   RP/0/(config-ospfv3-ar-if)# exit 
   RP/0/(config-ospfv3-ar)# interface GigabitEthernet 0/0/0/1
   RP/0/(config-ospfv3-ar-if)# network point-to-point
   RP/0/(config-ospfv3-ar-if)# prefix-suppression

4. Exit the OSPFv3 area configuration mode and commit your configuration.

   RP/0/(config-ospfv3-ar-if)# exit
   RP/0/(config-ospfv3-ar)# exit
   RP/0/(config-ospfv3)# exit
   RP/0/(config)# commit
   RP/0/(config)# exit

5. Confirm your configuration.

   RP/0/# show running-configuration
   ...
   interface Loopback0
    ipv4 address 10.10.10.10 255.255.255.255
   !
   interface GigabitEthernet0/0/0/1
    ipv4 address 10.1.1.1 255.255.255.0
   !
   router ospfv3 pfx
    router-id 10.10.10.10
    area 0
     interface GigabitEthernet0/0/0/1
      network point-to-point
      prefix-suppression
     !
    !
   !

6. Verify if prefix suppression is enabled.

   RP/0/# show ospfv3 interface
   Fri Jun 17 15:13:08.470 IST
   GigabitEthernet0/0/0/2 is up, line protocol is up
     Link Local address fe80::45:caff:feaf:72af, Interface ID 5
     Area 0, Process ID pfx, Instance ID 0, Router ID 10.10.10.10
     Network Type BROADCAST, Cost: 1
     Transmit Delay is 1 sec, State DOWN, Priority 1 
     No designated router on this network
     No backup designated router on this network
     Addresses not advertised
     Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
     Index 0/1/1, flood queue length 0
     Next 0(0)/0(0)/0(0)
     Last flood scan length is 0, maximum is 0
     Last flood scan time is 0 msec, maximum is 0 msec
     Neighbor Count is 0, Adjacent neighbor count is 0
     Suppress hello for 0 neighbor(s)
     Reference count is 0 
   

   If your output verifies that primary addresses are not advertised, then you have successfully configured prefix suppression on the interface.

The multi-area adjacency feature for OSPFv2 allows a link to be configured on the primary interface in more than one area so that the link could be considered as an intra-area link in those areas and configured as a preference over more expensive paths.

This feature establishes a point-to-point unnumbered link in an OSPF area. A point-to-point link provides a topological path for that area, and the primary adjacency uses the link to advertise the link consistent with draft-ietf-ospf-multi-area-adj-06.

The following are multi-area interface attributes and limitations:

• Exists as a logical construct over an existing primary interface for OSPF; however, the neighbor state on the primary interface is independent of the multi-area interface.

• Establishes a neighbor relationship with the corresponding multi-area interface on the neighboring router. A mixture of multi-area and primary interfaces is not supported.

• Advertises an unnumbered point-to-point link in the router link state advertisement (LSA) for the corresponding area when the neighbor state is full.

• Created as a point-to-point network type. You can configure multi-area adjacency on any interface where only two OSF speakers are attached. In the case of native broadcast networks, the interface must be configured as an OPSF point-to-point type using the network point-to-point command to enable the interface for a multi-area adjacency.

• Inherits the Bidirectional Forwarding Detection (BFD) characteristics from its primary interface. BFD is not configurable under a multi-area interface; however, it is configurable under the primary interface.

The multi-area interface inherits the interface characteristics from its primary interface, but some interface characteristics can be configured under the multi-area interface configuration mode as shown below:

RP/0/(config-ospf-ar)# multi-area-interface GigabitEthernet 0/1/0/3
RP/0/(config-ospf-ar-mif)# ?
  authentication       Enable authentication
  authentication-key   Authentication password (key)
  cost                 Interface cost
  cost-fallback        Cost when cumulative bandwidth goes below the theshold
  database-filter      Filter OSPF LSA during synchronization and flooding
  dead-interval        Interval after which a neighbor is declared dead
  distribute-list      Filter networks in routing updates
  hello-interval       Time between HELLO packets
  message-digest-key   Message digest authentication password (key)
  mtu-ignore           Enable/Disable ignoring of MTU in DBD packets
  packet-size          Customize size of OSPF packets upto MTU
  retransmit-interval  Time between retransmitting lost link state advertisements
  transmit-delay       Estimated time needed to send link-state update packet
  
RP/0/(config-ospf-ar-mif)#
  

Label Distribution Protocol (LDP) Interior Gateway Protocol (IGP) auto-configuration simplifies the procedure to enable LDP on a set of interfaces used by an IGP instance, such as OSPF. LDP IGP auto-configuration can be used on a large number of interfaces (for example, when LDP is used for transport in the core) and on multiple OSPF instances simultaneously.

This feature supports the IPv4 unicast address family for the default VPN routing and forwarding (VRF) instance.

LDP IGP auto-configuration can also be explicitly disabled on an individual interface basis under LDP using the igp auto-config disable command. This allows LDP to receive all OSPF interfaces minus the ones explicitly disabled.

See for information on configuring LDP IGP auto-configuration.

All OSPF routing protocol exchanges are authenticated and the method used can vary depending on how authentication is configured. When using cryptographic authentication, the OSPF routing protocol uses the Message Digest 5 (MD5) authentication algorithm to authenticate packets transmitted between neighbors in the network. For each OSPF protocol packet, a key is used to generate and verify a message digest that is appended to the end of the OSPF packet. The message digest is a one-way function of the OSPF protocol packet and the secret key. Each key is identified by the combination of interface used and the key identification. An interface may have multiple keys active at any time.

To manage the rollover of keys and enhance MD5 authentication for OSPF, you can configure a container of keys called a keychain with each key comprising the following attributes: generate/accept time, key identification, and authentication algorithm.

OSPF is a link state protocol that requires networking devices to detect topological changes in the network, flood Link State Advertisement (LSA) updates to neighbors, and quickly converge on a new view of the topology. However, during the act of receiving LSAs from neighbors, network attacks can occur, because there are no checks that unicastor multicast packets are originating from a neighbor that is one hop away or multiple hops away over virtual links.

For virtual links, OSPF packets travel multiple hops across the network; hence, the TTL value can be decremented several times. For these type of links, a minimum TTL value must be allowed and accepted for multiple-hop packets.

To filter network attacks originating from invalid sources traveling over multiple hops, the Generalized TTL Security Mechanism (GTSM), RFC 3682, is used to prevent the attacks. GTSM filters link-local addresses and allows for only one-hop neighbor adjacencies through the configuration of TTL value 255. The TTL value in the IP header is set to 255 when OSPF packets are originated, and checked on the received OSPF packets against the default GTSM TTL value 255 or the user configured GTSM TTL value, blocking unauthorized OSPF packets originated from TTL hops away.

A PCE is an entity (component, application, or network node) that is capable of computing a network path or route based on a network graph and applying computational constraints.

PCE is accomplished when a PCE address and client is configured for MPLS-TE. PCE communicates its PCE address and capabilities to OSPF then OSPF packages this information in the PCE Discovery type-length-value (TLV) (Type 2) and reoriginates the RI LSA. OSPF also includes the Router Capabilities TLV (Type 1) in all its RI LSAs. The PCE Discovery TLV contains the PCE address sub-TLV (Type 1) and the Path Scope Sub-TLV (Type 2).

The PCE Address Sub-TLV specifies the IP address that must be used to reach the PCE. It should be a loop-back address that is always reachable, this TLV is mandatory, and must be present within the PCE Discovery TLV. The Path Scope Sub-TLV indicates the PCE path computation scopes, which refers to the PCE ability to compute or participate in the computation of intra-area, inter-area, inter-AS or inter-layer TE LSPs.

PCE extensions to OSPFv2 include support for the Router Information Link State Advertisement (RI LSA). OSPFv2 is extended to receive all area scopes (LSA Types 9, 10, and 11). However, OSPFv2 originates only area scope Type 10.

For detailed information for the Path Computation Element feature see the Implementing MPLS Traffic Engineering on module of the and the following IETF drafts:

• draft-ietf-ospf-cap-09

• draft-ietf-pce-disco-proto-ospf-00

The OSPF IP Fast Reroute (FRR) Loop Free Alternate (LFA) computation supports these:

• Fast rerouting capability by using IP forwarding and routing

• Handles failure in the line cards in minimum time

Cisco IOS XR supports full MIBs and traps for OSPFv3, as defined in RFC 5643. The RFC 5643 defines objects of the Management Information Base (MIB) for use with the Open Shortest Path First (OSPF) Routing Protocol for IPv6 ( OSPF version 3).

The OSPFv3 MIB implementation is based on the IETF draft Management Information Base for OSPFv3 ( draft-ietf-ospf-ospfv3-mib-8). Users need to update the NMS application to pick up the new MIB when upgraded to RFC 5643.

Refer to the Cisco ASR 9000 Series Aggregation Services Router MIB Specification Guide for more information on Cisco IOS XR MIB support.

Cisco IOS XR supports full MIBs and traps for OSPFv2, as defined in RFC 4750. The RFC 4750 defines objects of the Management Information Base (MIB) for use with the Open Shortest Path First (OSPF) Routing Protocol for IPv4 (OSPF version 2).

The OSPFv2 MIB implementation is based on the IETF draft Management Information Base for OSPFv2 (draft-ietf-ospf-mib (ospf WG)).

To know more about MIBS, use the MIB Locator.

VRF-lite capability is enabled for OSPF version 2 (OSPFv2). VRF-lite is the virtual routing and forwarding (VRF) deployment without the BGP/MPLS based backbone. In VRF-lite, individual provider edge (PE) routers are directly connected using VRF interfaces. To enable VRF-lite in OSPFv2, configure the capability vrf-lite command in VRF configuration mode. When VRF-lite is configured, the DN bit processing and the automatic Area Border Router (ABR) status setting are disabled.

The Open Shortest Path First version 3 (OSPFv3) timers link-state advertisements (LSAs) and shortest path first (SPF) throttle default values are updated to:

• timers throttle lsa all —start-interval : 50 milliseconds and hold-interval : 200 milliseconds

• timers throttle spf —spf-start : 50 milliseconds, spf-hold : 200 milliseconds, spf-max-wait : 5000 milliseconds

The unequal cost multipath (UCMP) load-balancing adds the capability with Open Shortest Path First (OSPF) to load-balance traffic proportionally across multiple paths, with different cost. Without UCMP enabled, only the best cost paths are discovered by OSPF (ECMP) and alternate higher cost paths are not computed.

Generally, higher bandwidth links have lower IGP metrics configured, so that they form the shortest IGP paths. With the UCMP load-balancing enabled, IGP can use even lower bandwidth links or higher cost links for traffic, and can install these paths to the forwarding information base (FIB). OSPF installs multiple paths to the same destination in FIB, but each path will have a 'load metric/weight' associated with it. FIB uses this load metric/weight to decide the amount of traffic that needs to be sent on a higher bandwidth path and the amount of traffic that needs to be sent on a lower bandwidth path.

The UCMP computation is provided under OSPF VRF context, enabling UCMP computation for a particular VRF. For default VRF the configuration is done under the OSPF global mode. The UCMP configuration is also provided with a prefix-list option, which would limit the UCMP computation only for the prefixes present in the prefix-list. If prefix-list option is not provided, UCMP computation is done for the reachable prefixes in OSPF. The number of UCMP paths to be considered and installed is controlled using the variance configuration. Variance value identifies the range for the UCMP path metric to be considered for installation into routing information base (RIB/FIB) and is defined in terms of a percentage of the primary path metric. Total number of paths, including ECMP and UCMP paths together is limited by the max-path configuration or by the max-path capability of the platform.

There is an option to exclude an interface from being used for UCMP computation. If it is desired that a particular interface should not be considered as a UCMP nexthop, for any prefix, then use the UCMP exclude interface command to configure the interface to be excluded from UCMP computation.

Enabling the UCMP configuration indicates that OSPF should perform UCMP computation for the all the reachable OSPF prefixes or all the prefixes permitted by the prefix-list, if the prefix-list option is used. The UCMP computation happens only after the primary SPF and route calculation is completed. There would be a configurable delay (default delay is 100 ms) from the time primary route calculation is completed and UCMP computation is started. Use the UCMP delay-interval command to configure the delay between primary SPF completion and start of UCMP computation. UCMP computation will be done during the fast re-route computation (IPFRR does not need to be enabled for UCMP computation to be performed). If IPFRR is enabled, the fast re-route backup paths will be calculated for both the primary equal cost multipath ( ECMP) paths and the UCMP paths.