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.

Note	Following are the number of routes supported in NCS 4000 : 32K with NCS4K-2H10T-OP-KS line card 32K with NCS4K-4H-OPW-QC2 line card

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 non broadcast 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.

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.

Cisco IOS XR Software introduces new OSPF configuration fundamentals consisting of hierarchical CLI and CLI inheritance.

Hierarchical CLI is the grouping of related network component information at defined hierarchical levels such as at the router, area, and interface levels. Hierarchical CLI allows for easier configuration, maintenance, and troubleshooting of OSPF configurations. When configuration commands are displayed together in their hierarchical context, visual inspections are simplified. Hierarchical CLI is intrinsic for CLI inheritance to be supported.

With CLI inheritance support, you need not explicitly configure a parameter for an area or interface. In Cisco IOS XR Software, the parameters of interfaces in the same area can be exclusively configured with a single command, or parameter values can be inherited from a higher hierarchical level—such as from the area configuration level or the router ospf configuration levels.

For example, the hello interval value for an interface is determined by this precedence “IF” statement:

If the hello interval command is configured at the interface configuration level, then use the interface configured value, else

If the hello interval command is configured at the area configuration level, then use the area configured value, else

If the hello interval command is configured at the router ospf configuration level, then use the router ospf configured value, else

Use the default value of the command.

Tip

Understanding hierarchical CLI and CLI inheritance saves you considerable configuration time. See Configuring Authentication at Different Hierarchical Levels for OSPF Version 2 to understand how to implement these fundamentals. In addition, Cisco IOS XR Software examples are provided in Configuration Examples for Implementing OSPF.

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.

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 (Ten Gigabit Ethernet and Hundred Gigabit Ethernet)

• Point-to-multipoint

You can configure your Cisco IOS XR network as either a broadcast or an NBMA network.

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

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

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.

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.

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.

The OSPFv2 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 OSPFv2 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 OSPFv2 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 Timer Intervals Reset After Topology Change Eventthat a topology change event was received after the start of the maximum wait time interval and that the SPF intervals have been reset.

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.

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.

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 would stop 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/RP0:hostname# configure
   RP/0/RP0:hostname(config)# interface TenGigE0/6/0/2.10
   RP/0/RP0:hostname(config-if)# ipv4 address 10.1.1.1 255.255.255.0
   RP/0/RP0:hostname(config-if)# no shut
   RP/0/RP0:hostname(config-if)# exit
   RP/0/RP0:hostname(config)# interface Loopback 0
   RP/0/RP0:hostname(config-if)# ipv4 address 10.10.10.10 255.255.255.255
   RP/0/RP0:hostname(config-if)# no shut
   RP/0/RP0:hostname(config-if)# exit

2. Configure the OSPF process with prefix suppression.

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

3. Add the configured interfaces to the OSPF area.

   RP/0/RP0:hostname(config-ospf)# area 0
   RP/0/RP0:hostname(config-ospf-ar)# interface Loopback 0 
   RP/0/RP0:hostname(config-ospf-ar-if)# exit 
   RP/0/RP0:hostname(config-ospf-ar)# interface TenGigE0/6/0/2.10
   RP/0/RP0:hostname(config-ospf-ar-if)# network point-to-point

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

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

5. Confirm your configuration.

   RP/0/RP0:hostname# show running-configuration 
   ...
   interface Loopback0
    ipv4 address 10.10.10.10 255.255.255.255
   !
   interface TenGigE0/6/0/2.10
    ipv4 address 10.1.1.1 255.255.255.0
   !
   router ospf pfx
    router-id 10.10.10.10
    prefix-suppression
    area 0
     interface TenGigE0/6/0/2.10
      network point-to-point
     !
    !
   !

6. Verify if prefix suppression is enabled.

   RP/0/RP0:hostname# show ospf interface
   Fri Jun 17 15:13:08.470 IST
   
   Interfaces for OSPF 1
   
   TenGigE0/6/0/2.10 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/RP0:hostname# configure
   RP/0/RP0:hostname(config)# interface TenGigE0/6/0/2.10
   RP/0/RP0:hostname(config-if)# ipv4 address 10.1.1.1 255.255.255.0
   RP/0/RP0:hostname(config-if)# no shut
   RP/0/RP0:hostname(config-if)# exit
   RP/0/RP0:hostname(config)# interface Loopback 0
   RP/0/RP0:hostname(config-if)# ipv4 address 10.10.10.10 255.255.255.255
   RP/0/RP0:hostname(config-if)# no shut
   RP/0/RP0:hostname(config-if)# exit

2. Configure the OSPF area with prefix suppression.

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

3. Add the configured interfaces to the OSPF area.

   RP/0/RP0:hostname(config-ospf-ar)# interface Loopback 0 
   RP/0/RP0:hostname(config-ospf-ar-if)# exit 
   RP/0/RP0:hostname(config-ospf-ar)# interface TenGigE0/6/0/2.10
   RP/0/RP0:hostname(config-ospf-ar-if)# network point-to-point

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

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

5. Confirm your configuration.

   RP/0/RP0:hostname# show running-configuration 
   ...
   interface Loopback0
    ipv4 address 10.10.10.10 255.255.255.255
   !
   interface TenGigE0/6/0/2.10
    ipv4 address 10.1.1.1 255.255.255.0
   !
   router ospf pfx
    router-id 10.10.10.10
    area 0
     prefix-suppression
     interface TenGigE0/6/0/2.10
      network point-to-point
     !
    !
   !

6. Verify if prefix suppression is enabled.

   RP/0/RP0:hostname# show ospf interface
   Fri Jun 17 15:13:08.470 IST
   
   Interfaces for OSPF 1
   
   TenGigE0/6/0/2.10 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/RP0:hostname# configure
   RP/0/RP0:hostname(config)# interface TenGigE0/6/0/2.10
   RP/0/RP0:hostname(config-if)# ipv4 address 10.1.1.1 255.255.255.0
   RP/0/RP0:hostname(config-if)# no shut
   RP/0/RP0:hostname(config-if)# exit
   RP/0/RP0:hostname(config)# interface Loopback 0
   RP/0/RP0:hostname(config-if)# ipv4 address 10.10.10.10 255.255.255.255
   RP/0/RP0:hostname(config-if)# no shut
   RP/0/RP0:hostname(config-if)# exit

2. Configure the OSPF area.

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

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

   RP/0/RP0:hostname(config-ospf-ar)# interface Loopback 0 
   RP/0/RP0:hostname(config-ospf-ar-if)# exit 
   RP/0/RP0:hostname(config-ospf-ar)# interface TenGigE0/6/0/2.10
   RP/0/RP0:hostname(config-ospf-ar-if)# network point-to-point
   RP/0/RP0:hostname(config-ospf-ar-if)# prefix-suppression

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

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

5. Confirm your configuration.

   RP/0/RP0:hostname# show running-configuration 
   ...
   interface Loopback0
    ipv4 address 10.10.10.10 255.255.255.255
   !
   interface TenGigE0/6/0/2.10
    ipv4 address 10.1.1.1 255.255.255.0
   !
   router ospf pfx
    router-id 10.10.10.10
    area 0
     interface TenGigE0/6/0/2.10
      network point-to-point
      prefix-suppression
     !
    !
   !

6. Verify if prefix suppression is enabled.

   RP/0/RP0:hostname# show ospf interface
   Fri Jun 17 15:13:08.470 IST
   
   Interfaces for OSPF 1
   
   TenGigE0/6/0/2.10 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.

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/RP0:hostname(config-ospf-ar)# multi-area-interface TenGigE0/3/0/9.21
RP/0/RP0:hostname(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/RP0:hostname(config-ospf-ar-mif)#
  

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

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 software provides the capability to run OSPF protocols over Generic Routing Encapsulation (GRE) tunnel interfaces.

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.

Unequal Cost Load Balancing feature in Cisco IOS XR OSPFv2 feature enables Unequal Cost Multipath (UCMP) calculation based on configured prefix-list and based on variance factor. UCMP path can be calculated for all prefixes or only for selected prefixes based on the configuration. Selected interfaces can be excluded to be used as a candidate for UCMP paths. The calculated UCMP paths are then installed in the routing information base (RIB) subject to the max-path limit.

The OSPFv2 interior gateway protocol is used to calculate paths to prefixes inside an autonomous system. OSPF calculates up to maximum paths (max-path) equal cost multi-paths (ECMPs) for each prefix, where max-path is either limited by the router support or is configured by the user.

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.

This task describes how to enable the IP fast reroute (IPFRR) per-link loop-free alternate (LFA) computation to converge traffic flows around link failures.

To enable protection on broadcast links, IPFRR and bidirectional forwarding detection (BFD) must be enabled on the interface under OSPF.