Open Shortest Path First (OSPF) is an Interior Gateway Protocol (IGP) developed by the OSPF working
group of the Internet Engineering Task Force (IETF). Designed expressly for IP networks, OSPF
supports IP subnetting and tagging of externally derived routing information. OSPF also allows packet
authentication and uses IP multicast when sending and receiving packets.
Implementing OSPF version 3 (OSPFv3) expands on OSPF Version 2, to provide support for IPv6
routing prefixes.
This module describes the concepts and tasks you need to implement both versions of OSPF on your
Cisco IOS XR router. The term “OSPF” implies both versions of the routing protocol, unless otherwise
noted.
NoteFor more information about OSPF on the Cisco IOS XR software and complete descriptions of the OSPF
commands listed in this module, see the “Related Documents” section of this module. To locate
documentation for other commands that might appear during execution of a configuration task, search
online in the Cisco IOS XR software master command index.
Feature History for Implementing OSPF on Cisco IOS XR Software
ReleaseModification
Release 2.0 This feature was introduced on the Cisco CRS-1.
Release 3.0No modification.
Release 3.2Support was added for the Cisco XR 12000 Series Router.
Release 3.3.0The following tasks were added:
• Configuring OSPFv3 Graceful Restart
• Enabling Multicast-Intact for OSPFv2
• Configuring the Multi-VRF Capability for OSPF Routing
• Associating Interfaces to a VRF
• Configuring OSPF as a Provider Edge to Customer Edge (PE-CE)
Protocol
• Configuring LDP-IGP Synchronization
• Creating Multiple OSPF Instances (OSPF Process and a VRF)
Cisco IOS XR Routing Configuration Guide
RC-169
Implementing OSPF on Cisco IOS XR Software
Contents
Contents
• Prerequisites for Implementing OSPF on Cisco IOS XR Software, page RC-170
• Information About Implementing OSPF on Cisco IOS XR Software, page RC-170
• How to Implement OSPF on Cisco IOS XR Software, page RC-183
• Configuration Examples for Implementing OSPF on Cisco IOS XR Software, page RC-236
• Where to Go Next, page RC-241
• Additional References, page RC-243
Prerequisites for Implementing OSPF on Cisco IOS XR Software
The following are prerequisites for implementing OSPF on Cisco IOS XR Software:
• You must be in a user group associated with a task group that includes the proper task IDs for OSPF
commands. Task IDs for commands are listed in the Cisco IOS XR Task ID Reference Guide. For
detailed information about user groups and task IDs, see the Configuring AAA Services on Cisco IOS XR Software module of the Cisco IOS XR System Security Configuration Guide.
• Configuration tasks for OSPFv3 assume that you are familiar with IPv6 addressing and basic
configuration. See the Implementing Network Stack IPv4 and IPv6 on Cisco IOS XR Software
module of the Cisco IOS XR IP Addresses and Services Configuration Guide for information on IPv6
routing and addressing.
• Before you enable OSPFv3 on an interface, you must perform the following tasks:
–
Complete the OSPF network strategy and planning for your IPv6 network. For example, you
must decide whether multiple areas are required.
–
Enable IPv6 on the interface.
• Configuring authentication (IP Security) is an optional task. If you choose to configure
authentication, you must first decide whether to configure plain text or Message Digest 5 (MD5)
authentication, and whether the authentication applies to an entire area or specific interfaces.
Information About Implementing OSPF on Cisco IOS XR
Software
To implement OSPF you need to understand the following concepts:
• OSPF Functional Overview, page RC-171
• Key Features Supported in the Cisco IOS XR OSPF Implementation, page RC-172
• Comparison of Cisco IOS XR OSPFv3 and OSPFv2, page RC-173
• Importing Addresses into OSPFv3, page RC-173
• OSPF Hierarchical CLI and CLI Inheritance, page RC-173
• OSPF Routing Components, page RC-174
• OSPF Process and Router ID, page RC-176
• Supported OSPF Network Types, page RC-177
RC-170
Cisco IOS XR Routing Configuration Guide
Implementing OSPF on Cisco IOS XR Software
• Route Authentication Methods for OSPF Version 2, page RC-177
• Neighbors and Adjacency for OSPF, page RC-178
• Designated Router (DR) for OSPF, page RC-178
• Default Route for OSPF,, page RC-179
• Link-State Advertisement Types for OSPF Version 2, page RC-179
• Link-State Advertisement Types for OSPFv3, page RC-179
• Virtual Link and Transit Area for OSPF, page RC-180
• Route Redistribution for OSPF, page RC-181
• OSPF Shortest Path First Throttling, page RC-181
• Nonstop Forwarding for OSPF Version 2, page RC-182
• Load Balancing in OSPF Version 2 and OSPFv3, page RC-183
OSPF Functional Overview
Information About Implementing OSPF on Cisco IOS XR Software
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.
Cisco IOS XR Routing Configuration Guide
RC-171
Information About Implementing OSPF on Cisco IOS XR Software
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.
Implementing OSPF on Cisco IOS XR Software
Key Features Supported in the Cisco IOS XR OSPF Implementation
The Cisco IOS XR 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 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.
RC-172
• Virtual links—Virtual links are supported.
Cisco IOS XR Routing Configuration Guide
Implementing OSPF on Cisco IOS XR Software
Information About Implementing OSPF on Cisco IOS XR Software
• Not-so-stubby area (NSSA)—RFC 1587 is supported.
• OSPF over demand circuit—RFC 1793 is supported.
Comparison of Cisco IOS XR OSPFv3 and OSPFv2
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 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.
Importing Addresses into OSPFv3
When importing into OSPFv3 the set of addresses configured on an OSPFv3 interface, users cannot
select specific addresses to be imported. Either all addresses are imported or no addresses are imported.
OSPF Hierarchical CLI and CLI Inheritance
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, 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.
Cisco IOS XR Routing Configuration Guide
RC-173
Information About Implementing OSPF on Cisco IOS XR Software
TipUnderstanding hierarchical CLI and CLI inheritance saves you considerable configuration time. See the
“Configuring Authentication at Different Hierarchical Levels for OSPF Version 2” section on page 194
to understand how to implement these fundamentals. In addition, Cisco IOS XR examples are provided
in the “Configuration Examples for Implementing OSPF on Cisco IOS XR Software” section on
page 236.
OSPF Routing Components
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.
Figure 10 illustrates the routing components in an OSPF network topology.
Figure 10OSPF Routing Components
Implementing OSPF on Cisco IOS XR Software
OSPF Domain
(BGP autonomous
system 109)
Area 2
stub area
OSPF Domain
(BGP autonomous
system 65200)
ABR 2
Area 0
backbone
R3
R2
Area 3
ABR 1
Area 1
R1
ASBR 1
ASBR 2
88721
Autonomous Systems
The autonomous system is a collection of networks, under the same administrative control, that share
routing information with each other. An autonomous system is also referred to as a routing domain.
Figure 10 shows two autonomous systems: A and B. An autonomous system can consist of one or more
OSPF areas.
Cisco IOS XR Routing Configuration Guide
RC-174
Implementing OSPF on Cisco IOS XR Software
Areas
Areas allow the subdivision of an autonomous system into smaller, more manageable networks or sets
of adjacent networks. As shown in Figure 10, autonomous system A consists of three areas: Area 0, Area
1, and Area 2.
OSPF hides the topology of an area from the rest of the autonomous system. The network topology for
an area is visible only to routers inside that area. When OSPF routing is within an area, it is called
intra-area routing. This routing limits the amount of link-state information flood into the network,
reducing routing traffic. It also reduces the size of the topology information in each router, conserving
processing and memory requirements in each router.
Also, the routers within an area cannot see the detailed network topology outside the area. Because of
this restricted view of topological information, you can control traffic flow between areas and reduce
routing traffic when the entire autonomous system is a single routing domain.
Backbone Area
A backbone area is responsible for distributing routing information between multiple areas of an
autonomous system. OSPF routing occurring outside of an area is called interarea routing.
The backbone itself has all properties of an area. It consists of ABRs, routers, and networks only on the
backbone. As shown in Figure 10, Area 0 is an OSPF backbone area. Any OSPF backbone area has a
reserved area ID of 0.0.0.0.
Information About Implementing OSPF on Cisco IOS XR Software
Stub Area
Not-so-Stubby Area
A stub area is an area that does not accept or detailed network information external to the area. A stub
area typically has only one router that interfaces the area to the rest of the autonomous system. The stub
ABR advertises a single default route to external destinations into the stub area. Routers within a stub
area use this route for destinations outside the area and the autonomous system. This relationship
conserves LSA database space that would otherwise be used to store external LSAs flooded into the area.
In Figure 10, Area 2 is a stub area that is reached only through ABR 2. Area 0 cannot be a stub area.
A Not-so-Stubby Area (NSSA) is similar to the stub area. NSSA does not flood Type 5 external LSAs
from the core into the area, but can import autonomous system external routes in a limited fashion within
the area.
NSSA allows importing of Type 7 autonomous system external routes within an NSSA area by
redistribution. These Type 7 LSAs are translated into Type 5 LSAs by NSSA ABRs, which are flooded
throughout the whole routing domain. Summarization and filtering are supported during the translation.
Use NSSA to simplify administration if you are a network administrator that must connect a central site
using OSPF to a remote site that is using a different routing protocol.
Before NSSA, the connection between the corporate site border router and remote router could not be
run as an OSPF stub area because routes for the remote site could not be redistributed into a stub area,
and two routing protocols needed to be maintained. A simple protocol like RIP was usually run and
handled the redistribution. With NSSA, you can extend OSPF to cover the remote connection by defining
the area between the corporate router and remote router as an NSSA. Area 0 cannot be an NSSA.
Cisco IOS XR Routing Configuration Guide
RC-175
Information About Implementing OSPF on Cisco IOS XR Software
Routers
The OSPF network is composed of ABRs, ASBRs, and interior routers.
Area Border Routers
An area border routers (ABR) is a router with multiple interfaces that connect directly to networks in
two or more areas. An ABR runs a separate copy of the OSPF algorithm and maintains separate routing
data for each area that is attached to, including the backbone area. ABRs also send configuration
summaries for their attached areas to the backbone area, which then distributes this information to other
OSPF areas in the autonomous system. In Figure 10, there are two ABRs. ABR 1 interfaces Area 1 to
the backbone area. ABR 2 interfaces the backbone Area 0 to Area 2, a stub area.
Autonomous System Boundary Routers (ASBR)
An autonomous system boudary router (ASBR) provides connectivity from one autonomous system to
another system. ASBRs exchange their autonomous system routing information with boundary routers
in other autonomous systems. Every router inside an autonomous system knows how to reach the
boundary routers for its autonomous system.
ASBRs can import external routing information from other protocols like BGP and redistribute them as
AS-external (ASE) Type 5 LSAs to the OSPF network. If the Cisco IOS XR router is an ASBR, you can
configure it to advertise VIP addresses for content as autonomous system external routes. In this way,
ASBRs flood information about external networks to routers within the OSPF network.
ASBR routes can be advertised as a Type 1 or Type 2 ASE. The difference between Type 1 and Type 2
is how the cost is calculated. For a Type 2 ASE, only the external cost (metric) is considered when
multiple paths to the same destination are compared. For a Type 1 ASE, the combination of the external
cost and cost to reach the ASBR is used. Type 2 external cost is the default and is always more costly
than an OSPF route and used only if no OSPF route exists.
Implementing OSPF on Cisco IOS XR Software
Interior Routers
The interior routers (such as R1 in Figure 10) attached to one area (for example, all the interfaces reside
in the same area).
OSPF Process and Router ID
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 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. OSPFv2 obtains a router ID from the following sources, in order of decreasing preference:
OSPF attempts to obtain a router ID in the following ways (in order of preference):
• 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.)
RC-176
Cisco IOS XR Routing Configuration Guide
Implementing OSPF on Cisco IOS XR Software
• The primary IPv4 address of the interface specified by the OSPF router-id command.
• The 32-bit numeric value specified by the router-id command in global configuration mode. (This
value must be an IPv4 address assigned to an interface on this router.)
• By using the highest IPv4 address on a loopback interface in the system if the router is booted with
saved loopback address configuration.
• The primary IPv4 address of an interface over which this OSPF process is running.
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.
Supported OSPF Network Types
OSPF classifies different media into the following three types of networks by default:
• NBMA networks
• Point-to-point networks (POS)
• Broadcast networks (Gigabit Ethernet)
Information About Implementing OSPF on Cisco IOS XR Software
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.
Route Authentication Methods for OSPF Version 2
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).
Plain Text Authentication
Plain text authentication (also known as Type 1 authentication) uses a password that travels on the
physical medium and is easily visible to someone that does not have access permission and could use the
password to infiltrate a network. Therefore, plain text authentication does not provide security. It might
protect against a faulty implementation of OSPF or a misconfigured OSPF interface trying to send
erroneous OSPF packets.
MD5 Authentication
MD5 authentication provides a means of security. No password travels on the physical medium. Instead,
the router uses MD5 to produce a message digest of the OSPF packet plus the key, which is sent on the
physical medium. Using MD5 authentication prevents a router from accepting unauthorized or
deliberately malicious routing updates, which could compromise your network security by diverting
your traffic.
NoteMD5 authentication supports multiple keys, requiring that a key number be associated with a key.
Cisco IOS XR Routing Configuration Guide
RC-177
Information About Implementing OSPF on Cisco IOS XR Software
Authentication Strategies
Authentication can be specified for an entire process or area, or on an interface or a virtual link. An
interface or virtual link can be configured for only one type of authentication, not both. Authentication
configured for an interface or virtual link overrides authentication configured for the area or process.
If you intend for all interfaces in an area to use the same type of authentication, you can configure fewer
commands if you use the authentication command in the area configuration submode (and specify the
message-digest keyword if you want the entire area to use MD5 authentication). This strategy requires
fewer commands than specifying authentication for each interface.
Key Rollover
To support the changing of an MD5 key in an operational network without disrupting OSPF adjacencies
(and hence the topology), a key rollover mechanism is supported. As a network administrator configures
the new key into the multiple networking devices that communicate, some time exists when different
devices are using both a new key and an old key. If an interface is configured with a new key, the software
sends two copies of the same packet, each authenticated by the old key and new key. The software tracks
which devices start using the new key, and the software stops sending duplicate packets after it detects
that all of its neighbors are using the new key. The software then discards the old key. The network
administrator must then remove the old key from each the configuration file of each router.
Implementing OSPF on Cisco IOS XR Software
Neighbors and Adjacency for OSPF
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.
Designated Router (DR) for OSPF
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.
RC-178
Cisco IOS XR Routing Configuration Guide
Implementing OSPF on Cisco IOS XR Software
Information About Implementing OSPF on Cisco IOS XR Software
Default Route for OSPF,
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.
Link-State Advertisement Types for OSPF Version 2
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 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 and 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.
Link-State Advertisement Types for OSPFv3
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.
Cisco IOS XR Routing Configuration Guide
RC-179
Information About Implementing OSPF on Cisco IOS XR Software
• 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 the backbone area or any otehr 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.
Implementing OSPF on Cisco IOS XR Software
• 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.
Virtual Link and Transit Area for OSPF
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.
RC-180
Cisco IOS XR Routing Configuration Guide
Implementing OSPF on Cisco IOS XR Software
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.
Figure 11 illustrates a virtual link from Area 3 to Area 0.
Figure 11Virtual Link to Area 0
OSPF Domain (BGP autonomous system 109)
Backbone
Information About Implementing OSPF on Cisco IOS XR Software
Area 0
Route Redistribution for OSPF
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 the
“Configuration Examples for Implementing OSPF on Cisco IOS XR Software” section on page 236 for
an example of route redistribution for OSPF.
Area 1
ABR 1ABR 2
Transit Area
ASBR 1
Router ID 5.5.5.5Router ID 4.4.4.4
ASBR 2
ABR 3
Area 3
88722
OSPF Shortest Path First Throttling
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.
Cisco IOS XR Routing Configuration Guide
RC-181
Information About Implementing OSPF on Cisco IOS XR Software
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
Figure 12 shows the intervals at which the SPF calculations occur as long as at least one topology change
event is received in a given wait interval.
Figure 12SPF Calculation Intervals Set by the timers spf Command
Implementing OSPF on Cisco IOS XR Software
5 ms
2000 ms
1000 ms
4000 ms
8000 ms
16000 ms
32000 ms
90000 ms
64000 ms
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 Figure 13 that a topology change event was
received after the start of the maximum wait time interval and that the SPF intervals have been reset.
Figure 13Timer Intervals Reset After Topology Change Event
Topology change event
64000 ms
90000 ms
1000 ms
5 ms
SPF scheduled at
start interval
2000 ms
4000 ms
8000 ms
16000 ms
90000 ms
88279
88278
Nonstop Forwarding for OSPF Version 2
Cisco IOS XR 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 failover. With NSF,
peer networking devices do not experience routing flaps. During failover, data traffic is forwarded
Cisco IOS XR Routing Configuration Guide
RC-182
Implementing OSPF on Cisco IOS XR Software
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 failover and to be kept current with the Forwarding
Information Base (FIB) on the active RP is key to Cisco IOS XR 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 an RP failover, 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, 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 re-established, 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 as well as the OSPF neighbors are now fully converged.
How to Implement OSPF on Cisco IOS XR Software
NoteThe standardized IETF version of NSF, known as OSPF graceful restart (RFC 3623) is also supported.
Load Balancing in OSPF Version 2 and OSPFv3
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 default number of maximum paths is 32 for Cisco CRS-1 routers and 16 for
Cisco XR 12000 Series Routers. The range is from 1 to 32 for Cisco CRS-1 routers and 1 to 16 for
Cisco XR 12000 Series Routers.
How to Implement OSPF on Cisco IOS XR Software
This section contains the following procedures:
• Enabling OSPF, page RC-184 (required)
• Configuring Stub and Not-so-Stubby Area Types, page RC-186 (optional)
• Configuring Neighbors for Nonbroadcast Networks, page RC-189 (optional)
• Configuring Authentication at Different Hierarchical Levels for OSPF Version 2, page RC-194
(optional)
Cisco IOS XR Routing Configuration Guide
RC-183
How to Implement OSPF on Cisco IOS XR Software
• Controlling the Frequency that the Same LSA Is Originated or Accepted for OSPF, page RC-197
(optional)
• Creating a Virtual Link with MD5 Authentication to Area 0 for OSPF, page RC-199 (optional)
• Summarizing Subnetwork LSAs on an OSPF ABR, page RC-203 (optional)
• Redistributing Routes from One IGP into OSPF, page RC-205 (optional)
• Configuring OSPF Shortest Path First Throttling, page RC-209 (optional)
• Configuring Nonstop Forwarding for OSPF Version 2, page RC-212 (optional)
• Configuring OSPF Version 2 for MPLS Traffic Engineering, page RC-214 (optional)
• Verifying OSPF Configuration and Operation, page RC-219 (optional)
• Creating Multiple OSPF Instances (OSPF Process and a VRF), page RC-235 (optional)
This task explains how to perform the minimum OSPF configuration on your router that is to enable an
OSPF process with a router ID, configure a backbone or nonbackbone area, and then assign one or more
interfaces on which OSPF runs.
Although you can configure OSPF before you configure an IP address, no OSPF routing occurs until at
least one IP address is configured.
• The area-id argument can be entered in dotted-decimal
or IPv4 address notation, such as area 1000 or
area 0.0.3.232. However, you must choose one form or
the other for an area. We recommend using the IPv4
address notation.
(Optional) Requests notification of neighbor changes.
• By default, this feature is enabled.
• The messages generated by neighbor changes are
considered notifications, which are categorized as
severity Level 5 in the logging console command. The
logging console command controls which severity
level of messages are sent to the console. By default, all
severity level messages are sent.
Saves configuration changes.
• When you issue the end command, the system prompts
you to commit changes:
Uncommitted changes found, commit them before
exiting(yes/no/cancel)?
[cancel]:
–
Entering yes saves configuration changes to the
running configuration file, exits the configuration
session, and returns the router to EXEC mode.
–
Entering no exits the configuration session and
returns the router to EXEC mode without
committing the configuration changes.
–
Entering cancel leaves the router in the current
configuration session without exiting or
committing the configuration changes.
• Use the commit command to save the configuration
changes to the running configuration file and remain
within the configuration session.
Configuring Stub and Not-so-Stubby Area Types
This task explains how to configure the stub area and the NSSA for OSPF.
Enables OSPF routing for the specified routing process and
places the router in router configuration mode.
or
Enables OSPFv3 routing for the specified routing process
and places the router in router ospfv3 configuration mode.
NoteThe process-name argument is any alphanumeric
string no longer than 40 characters.
Configures a router ID for the OSPF process.
NoteWe recommend using a stable IP address as the
router ID.
Enters area configuration mode and configures a
nonbackbone area for the OSPF process.
• The area-id argument can be entered in dotted-decimal
or IPv4 address notation, such as area 1000 or
area 0.0.3.232. However, you must choose one form or
the other for an area. We recommend using the IPv4
address notation.
• See the “Configuring Stub and Not-so-Stubby Area
Types” section on page 186.
• Specify the no-summary keyword to further reduce the
number of LSAs sent into a stub area. This keyword
prevents the ABR from sending summary link-state
advertisements (Type 3) in the stub area.
or
Defines an area as an NSSA.
• See the “Configuring Stub and Not-so-Stubby Area
Types” section on page 186.
(Optional) Turns off the options configured for stub and
NSSA areas.
• If you configured the stub and NSSA areas using the
optional keywords (no-summary, no-redistribution,
default-information-originate, and no-summary) in
Step 5, you must now reissue the stub and nssa
commands without the keywords—rather than using
the no form of the command.
• For example, the no nssa
default-information-originate form of the command
changes the NSSA area into a normal area that
inadvertently brings down the existing adjacencies in
that area.
(Optional) Specifies a cost for the default summary route
sent into a stub area or an NSSA.
• Use this command only on ABRs attached to the NSSA.
Do not use it on any other routers in the area.
• The default cost is 1.
RC-188
Cisco IOS XR Routing Configuration Guide
Implementing OSPF on Cisco IOS XR Software
Command or ActionPurpose
Step 8
end
or
commit
Example:
RP/0/RP0/CPU0:router(config-ospf-ar)# end
or
RP/0/RP0/CPU0:router(config-ospf-ar)# commit
Step 9
Repeat this task on all other routers in the stub area or
NSSA.
How to Implement OSPF on Cisco IOS XR Software
Saves configuration changes.
• When you issue the end command, the system prompts
you to commit changes:
Uncommitted changes found, commit them before
exiting(yes/no/cancel)?
[cancel]:
–
Entering yes saves configuration changes to the
running configuration file, exits the configuration
session, and returns the router to EXEC mode.
–
Entering no exits the configuration session and
returns the router to EXEC mode without
committing the configuration changes.
–
Entering cancel leaves the router in the current
configuration session without exiting or
committing the configuration changes.
• Use the commit command to save the configuration
changes to the running configuration file and remain
within the configuration session.
—
Configuring Neighbors for Nonbroadcast Networks
This task explains how to configure neighbors for a nonbroadcast network. This task is optional.
Prerequisites
Configuring NBMA networks as either broadcast or nonbroadcast assumes that there are virtual circuits
from every router to every router or fully meshed network.
Enables OSPF routing for the specified routing process and
places the router in router configuration mode.
or
Enables OSPFv3 routing for the specified routing process
and places the router in router ospfv3 configuration mode.
NoteThe process-name argument is any alphanumeric
string no longer than 40 characters.
Configures a router ID for the OSPF process.
NoteWe recommend using a stable IP address as the
router ID.
Enters area configuration mode and configures an area for
the OSPF process.
• The example configures a backbone area.
• The area-id argument can be entered in dotted-decimal
or IPv4 address notation, such as area 1000 or
area 0.0.3.232. However, you must choose one form or
the other for an area. We recommend using the IPv4
address notation.