Week 9 - Single-Area OSPF Module PDF
Week 9 - Single-Area OSPF Module PDF
1
Week 9: Single-Area OSPF
OSPF Characteristics
Objectives
After completing this course, students will be able to
Explain how single-area OSPF operates.
• Explain the features and characteristics of the OSPF routing protocol.
• Describe the types of packets used to establish and maintain an OSPF neighbor
relationship.
• Explain how OSPF achieves convergence.
• Explain how OSPF uses cost to determine best path.
Introduction
Open Shortest Path First (OSPF) is a link-state routing protocol that was developed as an
alternative for the distance vector routing protocol, RIP. RIP was an acceptable routing
protocol in the early days of networking and the Internet. However, RIP's reliance on hop
count as the only metric for determining best route quickly became problematic. Using hop
count does not scale well in larger networks with multiple paths of varying speeds. OSPF has
significant advantages over RIP in that it offers faster convergence and scales to much larger
network implementations.
OSPF is a classless routing protocol that uses the concept of areas for scalability. This chapter
covers basic, single-area OSPF implementations and configurations.
Evolution of OSPF
The initial development of OSPF began in 1987 by the Internet Engineering Task Force
(IETF) OSPF Working Group. At that time, the Internet was largely an academic and research
network funded by the U.S. government.
In 1989, the specification for OSPFv1 was published in RFC 1131. Two implementations
were written. One implementation was developed to run on routers and the other to run on
UNIX workstations. The latter implementation became a widespread UNIX process known
as GATED. OSPFv1 was an experimental routing protocol and was never deployed.
In 1991, OSPFv2 was introduced in RFC 1247 by John Moy. OSPFv2 offered significant
technical improvements over OSPFv1. It is classless by design; therefore, it supports VLSM
and CIDR.
At the same time the OSPF was introduced, ISO was working on a link-state routing protocol
of their own, Intermediate System-to-Intermediate System (IS-IS). IETF chose OSPF as their
recommended Interior Gateway Protocol (IGP).
In 1998, the OSPFv2 specification was updated in RFC 2328, which remains the current RFC
for OSPF.
Features of OSPF
Administrative distance (AD) is the trustworthiness (or preference) of the route source.
OSPF has a default administrative distance of 110. As shown in Figure 9.2, OSPF has a lower
number (making it a preferred routing protocol over IS-IS and RIP) on Cisco devices.
Components of OSPF
All routing protocols share similar components. They all use routing protocol messages to
exchange route information. The messages help build data structures, which are then
processed using a routing algorithm.
Layer 3 devices (such as routers) running OSPF exchange messages to convey routing
information using five types of packets. These packets, as shown in Figure 9.4, are:
Hello packet
Database description packet
Link-state request packet
Link-state update packet
Link-state acknowledgment packet
These packets are used to discover neighboring routers and also to exchange routing
information to maintain accurate information about the network.
Algorithm
The router builds the topology table using results of calculations based on the Dijkstra SPF
algorithm. The SPF algorithm is based on the cumulative cost to reach a destination.
The SPF algorithm creates an SPF tree by placing each router at the root of the tree and
calculating the shortest path to each node. The SPF tree is then used to calculate the best
routes. OSPF places the best routes into the forwarding database, which is used to make the
routing table.
Link-State Operation
To maintain routing information, OSPF routers complete the following generic link-state
routing process to reach a state of convergence:
1. Establish Neighbor Adjacencies (Figure 9.5) - OSPF-enabled routers must recognize each
other on the network before they can share information. An OSPF-enabled router sends Hello
packets out all OSPF-enabled interfaces to determine if neighbors are present on those links.
If a neighbor is present, the OSPF-enabled router attempts to establish a neighbor adjacency
with that neighbor.
3. Build the Topology Table (Figure 9.7) - After LSAs are received, OSPF-enabled routers
build the topology table (LSDB) based on the received LSAs. This database eventually holds
all the information about the topology of the network.
4. Execute the SPF Algorithm (Figures 9.8 and 9.9) - Routers then execute the SPF algorithm.
The gears in the figure are used to indicate the execution of the SPF algorithm. The SPF
algorithm creates the SPF tree.
From the SPF tree, the best paths are offered to the IP routing table. The route will be inserted
into the routing table unless there is a route source to the same network with a lower
administrative distance, such as a static route. Routing decisions are made based on the
entries in the routing table.
To make OSPF more efficient and scalable, OSPF supports hierarchical routing using areas.
An OSPF area is a group of routers that share the same link-state information in their LSDBs.
Single-Area OSPF - In Figure 9.11, all routers are in one area called the backbone area (area
0).
Multiarea OSPF - In Figure 9.12, OSPF is implemented using multiple areas, in a hierarchal
fashion. All areas must connect to the backbone area (area 0). Routers interconnecting the
areas are referred to as Area Border Routers (ABRs).
With multiarea OSPF, OSPF can divide one large routing domain into smaller areas, to
support hierarchical routing. With hierarchical routing, routing still occurs between the
areas (interarea routing), while many of the processor intensive routing operations, such as
recalculating the database, are kept within an area.
Note: Routers in other areas receive messages regarding topology changes, but these routers
only update the routing table, not rerun the SPF algorithm.
Too many routers in one area would make the LSDBs very large and increase the load on the
CPU. Therefore, arranging routers into areas effectively partitions a potentially large
database into smaller and more manageable databases.
The hierarchical-topology design options with multiarea OSPF can offer these advantages:
Smaller routing tables - Fewer routing table entries because network addresses can be
summarized between areas. Route summarization is not enabled by default.
Reduced link-state update overhead - Designing multiarea OSPF with smaller areas
minimizes processing and memory requirements.
Reduced frequency of SPF calculations - Localizes the impact of a topology change within an
area. For instance, it minimizes routing update impact because LSA flooding stops at the area
boundary.
Figure 9.13 illustrates these advantages.
For example, R2 is an ABR for area 51. As an ABR, it would summarize the area 51 routes
into area 0. When one of the summarized links fails, LSAs are exchanged within area 51 only.
Routers in area 51 must rerun the SPF algorithm to identify the best routes. However, the
routers in area 0 and area 1 do not receive any updates; therefore, they do not execute the
SPF algorithm.
Data Link Ethernet Frame Header - Identifies the destination multicast MAC
addresses 01-00-5E-00-00-05 or 01-00-5E-00-00-06 when encapsulating an OSPFv2
message. (Figure 9.14)
IPv4 Packet Header -Identifies the IP source address and destination address. The
destination address is one of two OSPFv2 multicast addresses, 224.0.0.5 or 224.0.0.6.
The header also contains a protocol field which will contain the code of 89 for OSPF.
(Figure 9.15)
OSPF Packet Header - Identifies the OSPF packet type, the router ID and the area ID.
(Figure 9.16)
OSPF Packet Type Specific Data - Contains the OSPF packet type information. The
content differs depending on the packet type. (Figure 9.17)
OSPF uses link-state packets (LSPs) to establish and maintain neighbor adjacencies and
exchange routing updates.
The figure shows the five different types of LSPs used by OSPFv2. OSPFv3 has similar packet
types. Each packet serves a specific purpose in the OSPF routing process:
Type 1: Hello packet - Used to establish and maintain adjacency with other OSPF routers.
Type 2: Database Description (DBD) packet - Contains an abbreviated list of the sending
router’s LSDB and is used by receiving routers to check against the local LSDB. The LSDB
must be identical on all link-state routers within an area to construct an accurate SPF tree.
Type 3: Link-State Request (LSR) packet - Receiving routers can then request more
information about any entry in the DBD by sending an LSR.
Type 4: Link-State Update (LSU) packet - Used to reply to LSRs and to announce new
information. LSUs contain seven different types of LSAs.
Type 5: Link-State Acknowledgment (LSAck) packet - When an LSU is received, the router
sends an LSAck to confirm receipt of the LSU. The LSAck data field is empty.
Hello Packet
The OSPF Type 1 packet is the Hello packet. Hello packets are used to:
The figure 9.18 displays the fields contained in the OSPFv2 Type 1 Hello packet. Important
fields shown in the figure include:
Type - Identifies the type of packet. A one (1) indicates a Hello packet. A value 2 identifies a
DBD packet, 3 an LSR packet, 4 an LSU packet, and 5 an LSAck packet.
Router ID - A 32-bit value expressed in dotted decimal notation (like an IPv4 address) used
to uniquely identify the originating router.
Area ID – Number of the area from which the packet originated.
Network Mask - Subnet mask associated with the sending interface.
Hello Interval - Specifies the frequency, in seconds, at which a router sends Hello packets.
The default Hello interval on multiaccess networks is 10 seconds. This timer must be the
same on neighboring routers; otherwise, an adjacency is not established.
Router Priority - Used in a DR/BDR election. The default priority for all OSPF routers is 1,
but can be manually altered from 0 to 255. The higher the value, the more likely the router
becomes the DR on the link.
Dead Interval - Is the time in seconds that a router waits to hear from a neighbor before
declaring the neighboring router out of service. By default, the router Dead Interval is four
times the Hello interval. This timer must be the same on neighboring routers; otherwise, an
adjacency is not established.
Designated Router (DR) - Router ID of the DR.
As shown in the figure 9.19, OSPF Hello packets are transmitted to multicast address
224.0.0.5 in IPv4 and FF02::5 in IPv6 (all OSPF routers) every:
The Dead interval is the period that the router waits to receive a Hello packet before
declaring the neighbor down. If the Dead interval expires before the routers receive a Hello
packet, OSPF removes that neighbor from its LSDB. The router floods the LSDB with
information about the down neighbor out all OSPF-enabled interfaces.
Link-State Updates
Routers initially exchange Type 2 DBD packets, which is an abbreviated list of the sending
router’s LSDB and is used by receiving routers to check against the local LSDB.
A Type 3 LSR packet is used by the receiving routers to request more information about an
entry in the DBD.
LSUs are also used to forward OSPF routing updates, such as link changes. Specifically, an
LSU packet can contain 11 different types of OSPFv2 LSAs, as shown in the figure. OSPFv3
renamed several of these LSAs and also contains two additional LSAs.
Note: The difference between the LSU and LSA terms can sometimes be confusing because
these terms are often used interchangeably. However, an LSU contains one or more LSAs.
Down state
Init state
Two-Way state
ExStart state
Exchange state
Loading state
Full state
When OSPF is enabled on an interface, the router must determine if there is another OSPF
neighbor on the link. To accomplish this, the router forwards a Hello packet that contains its
router ID out all OSPF-enabled interfaces. The OSPF router ID is used by the OSPF process to
uniquely identify each router in the OSPF area. A router ID is a 32-bit number formatted like
an IP address and assigned to uniquely identify a router among OSPF peers.
When a neighboring OSPF-enabled router receives a Hello packet with a router ID that is not
within its neighbor list, the receiving router attempts to establish an adjacency with the
initiating router.
Refer to R1 in Figure 9.20. When OSPFv2 is enabled, the enabled Gigabit Ethernet 0/0
interface transitions from the Down state to the Init state. R1 starts sending Hello packets
out all OSPF-enabled interfaces to discover OSPF neighbors to develop adjacencies with.
In Figure 9.21, R2 receives the Hello packet from R1 and adds the R1 router ID to its neighbor
list. R2 then sends a Hello packet to R1. The packet contains the R2 Router ID and the R1
Router ID in its list of neighbors on the same interface.
In Figure 9.22, R1 receives the Hello and adds the R2 Router ID in its list of OSPF neighbors.
It also notices its own Router ID in the Hello packet’s list of neighbors. When a router receives
a Hello packet with its Router ID listed in the list of neighbors, the router transitions from
the Init state to the Two-Way state.
The action performed in Two-Way state depends on the type of inter-connection between
the adjacent routers:
If the two adjacent neighbors are interconnected over a point-to-point link, then they
immediately transition from the Two-Way state to the database synchronization phase.
If the routers are interconnected over a common Ethernet network, then a designated
router DR and a BDR must be elected.
Because R1 and R2 are interconnected over an Ethernet network, a DR and BDR election
takes place. As shown in Figure 9.23, R2 becomes the DR and R1 is the BDR. This process
only occurs on multi-access networks such as Ethernet LANs.
Multiaccess networks can create two challenges for OSPF regarding the flooding of LSAs:
Extensive flooding of LSAs - Link-state routers flood their LSAs any time OSPF is
initialized, or when there is a change in the topology. This flooding can become
excessive.
Figure 9.24 shows a simple topology of five routers, all of which are attached to the same
multiaccess Ethernet network. Without some type of mechanism to reduce the number of
adjacencies, collectively these routers would form 10 adjacencies:
5 (5 – 1) / 2 = 10
This may not seem like much, but as routers are added to the network, the number of
adjacencies increases dramatically, as shown in Figure 9.25.
To understand the problem of extensive flooding of LSAs, play the animation in Figure 9.26.
In the animation, R2 sends out an LSA. This event triggers every other router to also send
out an LSA. Not shown in the animation are the required acknowledgments sent for every
LSA received. If every router in a multiaccess network had to flood and acknowledge all
received LSAs to all other routers on that same multiaccess network, the network traffic
would become quite chaotic.
The solution to managing the number of adjacencies and the flooding of LSAs on a
multiaccess network is the DR. On multiaccess networks, OSPF elects a DR to be the
collection and distribution point for LSAs sent and received. A BDR is also elected in case the
DR fails. All other routers become DROTHERs. A DROTHER is a router that is neither the DR
nor the BDR.
Note: The DR is only used for the dissemination of LSAs. The router will still use the best
next-hop router indicated in the routing table for the forwarding of all other packets.
After the Two-Way state, routers transition to database synchronization states. While the
Hello packet was used to establish neighbor adjacencies, the other four types of OSPF packets
are used during the process of exchanging and synchronizing LSDBs.
In the ExStart state, the two routers decide which router will send the DBD packets first. The
router with the higher router ID will be the first router to send DBD packets during the
Exchange state. In Figure 9.27, R2 has the higher router ID and sends it’s DBD packets first.
In the Exchange state, the two routers exchange one or more DBD packets. A DBD packet
includes information about the LSA entry header that appears in the router’s LSDB. The
entries can be about a link or about a network. Each LSA entry header includes information
about the link-state type, the address of the advertising router, the link’s cost, and the
sequence number. The router uses the sequence number to determine the newness of the
received link-state information.
In Figure 9.28, R2 sends a DBD packet to R1. When R1 receives the DBD, it performs the
following actions:
R1 compares the information received with the information it has in its own LSDB. If the DBD
packet has a more current link-state entry, the router transitions to the Loading state.
For example, in Figure 9.29, R1 sends an LSR regarding network 172.16.6.0 to R2. R2
responds with the complete information about 172.16.6.0 in an LSU packet. Again, when R1
receives an LSU, it sends an LSAck. R1 then adds the new link-state entries into its LSDB.
After all LSRs have been satisfied for a given router, the adjacent routers are considered
synchronized and in a full state.
As long as the neighboring routers continue receiving Hello packets, the network in the
transmitted LSAs remain in the topology database. After the topological databases are
synchronized, updates (LSUs) are sent only to neighbors:
Single-Area OSPFv2
OSPF Network Topology
Introduced in 1991, OSPFv2 is a link-state routing protocol for IPv4. OSPF was designed as
an alternative to another IPv4 routing protocol, RIP.
The figure 9.30 shows the topology used for configuring OSPFv2 in this section. The types of
serial interfaces and their associated bandwidths may not necessarily reflect the more
common types of connections found in networks today. The bandwidths of the serial links
used in this topology were chosen to help explain the calculation of the routing protocol
metrics and the process of best path selection.
The routers in the topology have a starting configuration, including interface addresses.
There is currently no static routing or dynamic routing configured on any of the routers. All
interfaces on routers R1, R2, and R3 (except the loopback on R2) are within the OSPF
backbone area. The ISP router is used as the routing domain’s gateway to the Internet.
Note: In this topology the loopback interface is used to simulate the WAN link to the Internet.
Figure 9.31 is the reference topology for this topic. OSPFv2 is enabled using the router
ospf process-id global configuration mode command. The process-id value represents a
number between 1 and 65,535 and is selected by the network administrator. The process-
id value is locally significant, which means that it does not have to be the same value on the
other OSPF routers to establish adjacencies with those neighbors.
Figure 9.32 provides an example of entering router OSPFv2 configuration mode on R1.
Note: The list of commands has been altered to display only the commands that are used in
this chapter.
Router IDs
Every router requires a router ID to participate in an OSPF domain. The router ID can be
defined by an administrator or automatically assigned by the router. The router ID is used
by the OSPF-enabled router to:
Uniquely identify the router - The router ID is used by other routers to uniquely
identify each router within the OSPF domain and all packets that originate from them.
But how does the router determine the router ID? As illustrated in the figure 9.33, Cisco
routers derive the router ID based on one of three criteria, in the following preferential
order:
The router ID is explicitly configured using the OSPF router-id rid router
configuration mode command. The rid value is any 32-bit value expressed as an IPv4
address. This is the recommended method to assign a router ID.
If the router ID is not explicitly configured, the router chooses the highest IPv4
address of any of configured loopback interfaces. This is the next best alternative to
assigning a router ID.
If no loopback interfaces are configured, then the router chooses the highest active
IPv4 address of any of its physical interfaces. This is the least recommended method
because it makes it more difficult for administrators to distinguish between specific
routers.
If the router uses the highest IPv4 address for the router ID, the interface does not need to
be OSPF-enabled. This means that the interface address does not need to be included in one
of the OSPFnetwork commands for the router to use that IPv4 address as the router ID. The
only requirement is that the interface is active and in the up state.
Note: The router ID looks like an IPv4 address, but it is not routable and, therefore, is not
included in the routing table, unless the OSPF routing process chooses an interface
(physical or loopback) that is appropriately defined by a network command.
Use the router-id rid router configuration mode command to manually assign a 32-bit
value expressed as an IPv4 address to a router. An OSPF router identifies itself to other
routers using this router ID.
As shown in Figure 9.34, R1 is configured with a router ID of 1.1.1.1, R2 with 2.2.2.2, and R3
with 3.3.3.3.
In Figure 9.35, the router ID 1.1.1.1 is assigned to R1. Use the show ip protocols command
to verify the router ID.
Note: R1 had never been configured with an OSPF router ID. If it had, then the router ID
would have to be modified.
If the router ID is the same on two neighboring routers, the router displays an error
message similar to the one below:
To correct this problem, configure all routers so that they have unique OSPF router IDs.
Modifying a Router ID
Sometimes a router ID needs to be changed, for example, when a network administrator
establishes a new router ID scheme for the network. However, after a router selects a
router ID, an active OSPFv2 router does not allow the router ID to be changed until the
router is reloaded or the OSPFv2 process cleared.
In Figure 9.36, notice that the current router ID is 192.168.10.5. The router ID should be
1.1.1.1.
In Figure 9.37, the router ID 1.1.1.1 is being assigned to R1. Notice how an informational
message appears stating that the OSPFv2 process must be cleared or that the router must
be reloaded. The reason is because R1 already has adjacencies with other neighbors using
the router ID 192.168.10.5. Those adjacencies must be renegotiated using the new router
ID 1.1.1.1.
Clearing the OSPF process is the preferred method to reset the router ID.
In Figure 9.38, the OSPFv2 routing process is cleared using the clear ip ospf
process privileged EXEC mode command. This forces OSPFv2 on R1 to transition to the
Down and Init states. Notice the adjacency change messages from full to down and then
from loading to full. The show ip protocols command verifies that the router ID has
changed.
The IPv4 address of the loopback interface should be configured using a 32-bit subnet mask
(255.255.255.255). This effectively creates a host route. A 32-bit host route does not get
advertised as a route to other OSPF routers.
The example in the figure displays how to configure a loopback interface with a host route
on R1. R1 uses the host route as its router ID, assuming there is no router ID explicitly
configured or previously learned.
Note: The router-id command is the preferred method. However, some older versions of the
IOS do not recognize the router-id command; therefore, the best way to set the router ID on
those routers is by using a loopback interface.
The area area-id syntax refers to the OSPF area. When configuring single-area OSPFv2,
the network command must be configured with the same area-id value on all routers.
Although any area ID can be used, it is good practice to use an area ID of 0 with single-area
OSPFv2. This convention makes it easier if the network is later altered to support multiarea
OSPFv2.
Wildcard Mask
A wildcard mask is a string of 32 binary digits used by the router to determine which bits of
the address to examine for a match. In a subnet mask, binary 1 is equal to a match and binary
0 is not a match. In a wildcard mask, the reverse is true:
Wildcard mask bit 0 - Matches the corresponding bit value in the address.
Wildcard mask bit 1 - Ignores the corresponding bit value in the address.
The easiest method for calculating a wildcard mask is to subtract the network subnet mask
from 255.255.255.255.
The example in Figure 9.41 calculates the wildcard mask from the network address of
192.168.10.0/24. To do so, the subnet mask 255.255.255.0 is subtracted from
255.255.255.255, providing a result of 0.0.0.255. Therefore, 192.168.10.0/24 is
192.168.10.0 with a wildcard mask of 0.0.0.255.
The example in Figure 9.42 calculates the wildcard mask from the network address of
192.168.10.64/26. Again, the subnet mask 255.255.255.192 is subtracted from
255.255.255.255 providing a result of 0.0.0.63. Therefore, 192.168.10.0/26 is 192.168.10.0
with a wildcard mask of 0.0.0.63.
There are several ways to identify the interfaces that will participate in the OSPFv2 routing
process.
Figure 9.43 displays the required commands to determine which interfaces on R1 participate
in the OSPFv2 routing process for an area. Notice the use of wildcard masks to identify the
respective interfaces based on their network addresses. Because this is a single-area OSPF
network, all area IDs are set to 0.
Figure 9.44 provides an example of specifying the interface IPv4 address with a quad 0
wildcard mask. Entering network 172.16.3.1 0.0.0.0 area 0 on R1 tells the router to enable
interface Serial0/0/0 for the routing process. As a result, the OSPFv2 process will advertise
the network that is on this interface (172.16.3.0/30).
The advantage of specifying the interface is that the wildcard mask calculation is not
necessary. OSPFv2 uses the interface address and subnet mask to determine the network to
advertise.
Some IOS versions allow the subnet mask to be entered instead of the wildcard mask. The
IOS then converts the subnet mask to the wildcard mask format.
Passive Interface
By default, OSPF messages are forwarded out all OSPF-enabled interfaces. However, these
messages really only need to be sent out interfaces connecting to other OSPF-enabled
routers.
Refer to the topology in the figure9.45 . OSPFv2 messages are forwarded out of all three
routers G0/0 interface even though no OSPFv2 neighbor exists on that LAN. Sending out
unneeded messages on a LAN affects the network in three ways:
Inefficient Use of Resources - All devices on the LAN must process the message and
eventually discard the message.
Use the passive-interface router configuration mode command to prevent the transmission
of routing messages through a router interface, but still allow that network to be advertised
to other routers, as shown in Figure 9.46. Specifically, the command stops routing messages
from being sent out the specified interface. However, the network that the specified interface
belongs to is still advertised in routing messages that are sent out other interfaces.
For instance, there is no need for R1, R2, and R3 to forward OSPF messages out of their LAN
interfaces. The configuration identifies the R1 G0/0 interface as passive.
It is important to know that a neighbor adjacency cannot be formed over a passive interface.
This is because link-state packets cannot be sent or acknowledged.
The show ip protocols command is then used to verify that the Gigabit Ethernet interface
was passive, as shown in Figure 9.47. Notice that the G0/0 interface is now listed under the
Passive Interface(s) section. The network 172.16.1.0 is still listed under Routing for
Networks, which means that this network is still included as a route entry in OSPFv2 updates
that are sent to R2 and R3.
Note: While completing the syntax checker, notice the OSPFv2 informational state messages
as the interfaces are all rendered passive and then the two serial interfaces are made non-
passive.
Recall that a routing protocol uses a metric to determine the best path of a packet across a
network. A metric gives indication of the overhead that is required to send packets across a
certain interface. OSPF uses cost as a metric. A lower cost indicates a better path than a
higher cost.
The default reference bandwidth is 10^8 (100,000,000); therefore, the formula is:
Refer to the table in the figure 9.48 for a breakdown of the cost calculation. Notice that
FastEthernet, Gigabit Ethernet, and 10 GigE interfaces share the same cost, because the OSPF
cost value must be an integer. Consequently, because the default reference bandwidth is set
to 100 Mb/s, all links that are faster than Fast Ethernet also have a cost of 1.
The cost of an OSPF route is the accumulated value from one router to the destination
network.
For example, in Figure 9.49, the cost to reach the R2 LAN 172.16.2.0/24 from R1 should be
as follows:
The routing table of R1 in Figure 9.50 confirms that the metric to reach the R2 LAN is a cost
of 65.
OSPF uses a reference bandwidth of 100 Mb/s for any links that are equal to or faster than
a fast Ethernet connection. Therefore, the cost assigned to a fast Ethernet interface with an
interface bandwidth of 100 Mb/s would equal 1.
While this calculation works for fast Ethernet interfaces, it is problematic for links that are
faster than 100 Mb/s; because the OSPF metric only uses integers as its final cost of a link.
If something less than an integer is calculated, OSPF rounds up to the nearest integer. For
this reason, from the OSPF perspective, an interface with an interface bandwidth of 100
Mb/s (a cost of 1) has the same cost as an interface with a bandwidth of 100 Gb/s (a cost of
1).
To assist OSPF in making the correct path determination, the reference bandwidth must be
changed to a higher value to accommodate networks with links faster than 100 Mb/s.
Changing the reference bandwidth does not actually affect the bandwidth capacity on the
link; rather, it simply affects the calculation used to determine the metric. To adjust the
reference bandwidth, use the auto-cost reference-bandwidth Mb/s router configuration
command. This command must be configured on every router in the OSPF domain. Notice
that the value is expressed in Mb/s; therefore, to adjust the costs for:
The table in Figure 9.51 displays the OSPF cost if the reference bandwidth is set to Gigabit
Ethernet. Although the metric values increase, OSPF makes better choices because it can
now distinguish between FastEthernet and Gigabit Ethernet links.
Figure 9.52 displays the OSPF cost if the reference bandwidth is adjusted to accommodate
10 Gigabit Ethernet links. The reference bandwidth should be adjusted anytime there are
links faster than FastEthernet (100 Mb/s).
Note: The costs represent whole numbers that have been rounded down.
In Figure 9.53, all routers have been configured to accommodate the Gigabit Ethernet link
with the auto-cost reference-bandwidth 1000 router configuration command. The new
accumulated cost to reach the R2 LAN 172.16.2.0/24 from R1:
Use the show ip ospf interface s0/0/0 command to verify the current OSPFv2 cost
assigned to the R1 serial 0/0/0 interface, as shown in Figure 9.54. Notice how it displays a
cost of 647.
The routing table of R1 in Figure 9.55 confirms that the metric to reach the R2 LAN is a cost
of 648.
All interfaces have default bandwidth values assigned to them. As with reference bandwidth,
interface bandwidth values do not actually affect the speed or capacity of the link. Instead,
they are used by some routing protocols, like OSPF, to compute the routing metric. Therefore,
it is important that the bandwidth value reflect the actual speed of the link so that the routing
table has accurate best path information.
Although the bandwidth values of Ethernet interfaces usually match the link speed, some
other interfaces may not. For instance, the actual speed of serial interfaces is often different
than the default bandwidth. On Cisco routers, the default bandwidth on most serial interfaces
is set to 1.544 Mb/s.
Refer to the example in Figure 9.56. Notice that the link between:
Figure 9.58 displays the serial interface 0/0/1 settings for R1. It also confirms that the
interface is using the default interface bandwidth 1,544 kb/s. According to the reference
topology, this should be set to 64 kb/s. Therefore, the R1 serial 0/0/1 interface must be
adjusted.
Figure 9.59 displays the resulting cost metric of 647, which is based on the reference
bandwidth set to 1,000,000,000 bps and the default interface bandwidth of 1,544 kb/s
(1,000,000,000 / 1,544,000).
To adjust the interface bandwidth use the bandwidth kilobits interface configuration
command. Use the no bandwidth command to restore the default value.
The example in Figure 9.60 adjusts the R1 Serial 0/0/1 interface bandwidth to 64 kb/s. A
quick verification confirms that the interface bandwidth setting is now 64 kb/s.
The bandwidth must be adjusted at each end of the serial links, therefore:
Note: A common misconception for students who are new to networking and the Cisco IOS
is to assume that the bandwidth command changes the physical bandwidth of the link. The
command only modifies the bandwidth metric used by EIGRP and OSPF. The command does
not modify the actual bandwidth on the link.
As an alternative to setting the default interface bandwidth, the cost can be manually
configured on an interface using the ip ospf cost value interface configuration command.
An advantage of configuring a cost over setting the interface bandwidth is that the router
does not have to calculate the metric when the cost is manually configured. In contrast, when
the interface bandwidth is configured, the router must calculate the OSPF cost based on the
bandwidth. The ip ospf cost command is useful in multi-vendor environments where non-
Cisco routers may use a metric other than bandwidth to calculate the OSPFv2 costs.
Both the bandwidth interface command and the ip ospf cost interface command achieve
the same result, which is to provide an accurate value for use by OSPFv2 in determining the
best route.
For instance, in the example in Figure 9.61, the interface bandwidth of serial 0/0/1 is reset
to the default value and the OSPF cost is manually set to 15,625. Although the interface
bandwidth is reset to the default value, the OSPFv2 cost is set as if the bandwidth was still
calculated.
Figure 9.62 shows the two alternatives that can be used in modifying the costs of the serial
links in the topology. The right side of the figure shows the ip ospf cost command
equivalents of the bandwidth commands on the left.
Use the show ip ospf neighbor command to verify that the router has formed an adjacency
with its neighboring routers. If the router ID of the neighboring router is not displayed, or if
it does not show as being in a state of FULL, the two routers have not formed an OSPFv2
adjacency.
Figure 9.64 displays the neighbor adjacency of R1. For each neighbor, this command displays
the following output:
Neighbor ID - The router ID of the neighboring router.
Pri - The OSPFv2 priority of the interface. This value is used in the DR and BDR election.
State - The OSPFv2 state of the interface. FULL state means that the router and its
neighbor have identical OSPFv2 LSDBs. On multiaccess networks, such as Ethernet, two
routers that are adjacent may have their states displayed as 2WAY. The dash indicates
that no DR or BDR is required because of the network type.
Dead Time - The amount of time remaining that the router waits to receive an OSPFv2
Hello packet from the neighbor before declaring the neighbor down. This value is reset
when the interface receives a Hello packet.
Address - The IPv4 address of the neighbor’s interface to which this router is directly
connected.
Interface - The interface on which this router has formed adjacency with the neighbor.
Two routers may not form an OSPFv2 adjacency if:
The subnet masks do not match, causing the routers to be on separate networks.
OSPFv2 Hello or Dead Timers do not match.
OSPFv2 Network Types do not match.
There is a missing or incorrect OSPFv2 network command.
As shown in Figure 9.65, the show ip protocols command is a quick way to verify vital OSPF
configuration information. This includes the OSPFv2 process ID, the router ID, networks the
router is advertising, the neighbors the router is receiving updates from, and the default
administrative distance, which is 110 for OSPF.
The show ip ospf command can also be used to examine the OSPFv2 process ID and router
ID, as shown in Figure 9.66. This command displays the OSPFv2 area information and the
last time the SPF algorithm was calculated.