This module provides information on the fundamentals of Routing Information Protocol (RIP).

It is
accompanied by a series of labs designed to enhance the concepts being explained. These labs give you
the opportunity to apply what is being taught by using a simulated Cisco IOS® environment.

In the labs, you play the role of a network administrator in charge of maintaining the IP routing portion of
your company's network. The labs will vary and grow in complexity as the concepts build upon each other.
Each lab is designed to demonstrate the specific concept or task explained in the corresponding lesson.
(Note: Although each lab builds on the results of the previous labs, there is no prerequisite of finishing a
specific lab before starting another.)

The goals of this module are to make you proficient in the basic concepts of RIP, and to enable you to
identify and troubleshoot problems in the Cisco IOS software. Throughout the labs are various "tips and
tricks" specific to the Cisco IOS software that have been learned from Cisco support engineers and Cisco
Certified Internetwork Expert (CCIEs™) professionals while troubleshooting literally tens of thousands of
customer networking problems.

After you have reviewed the material and successfully completed each Pop Quiz in this introductory section,
proceed to the Configuration and Troubleshooting sections, which include hands-on lab exercises.

Remember: Use the Pop Quiz feature to test your understanding throughout this course.

At the end of this tutorial, you will be able to:

• Describe a RIP routing table.

• Describe the RIP metric and discuss its advantages and disadvantages.
• Discuss RIP timers and describe the function of each one.
• Understand and discuss the stability features of RIP.
• Identify the differences between RIP Version 1 and RIP Version 2.
• Describe the RIP packet format (for both versions of RIP) and discuss the packet fields and their
purposes.
• Use the basic commands necessary to maintain and troubleshoot RIP in Cisco IOS software.

Begin with Understanding RIP.

Routing Information Protocol ( RIP) is an Interior Gateway Protocol (IGP), meaning it is used within an
autonomous system. A distance-vector protocol, RIP was designed to work with small to medium-sized
networks.

The original version of RIP is based on the program routed (pronounced "route dee"), distributed with the 4.3
Berkeley Software Distribution. RIP was in widespread use as a routing protocol before it was formally
defined in RFC 1058. RIP Version 2, defined in RFC 2453, added some additional features and functionality
to the original version. Both versions of RIP are discussed in this module. RFC 2091 specified additional
extensions for RIP to allow support for demand circuits (Triggered RIP). Support for Triggered RIP was
added in 12.0(1)T and will not be discussed here.

Some advantages of using RIP, especially in small networks, is that there is very little overhead, in terms of
bandwidth used and configuration and management time. RIP is also easy to implement, compared to
newer IGPs, and has been implemented in networks around the world.

RIP is a distance-vector protocol. As you learned in the "Cisco Interactive Mentor: Basic IP Routing
Concepts" module, a distance-vector protocol is based on the exchange of routing-table information. Each
router using a distance-vector protocol maintains information about all the destinations within the system. In
general, the information about all the entities connected to one network (or subnet) is summarized within a
single entry. This entry includes the next destination to which datagrams are destined, a metric measuring
the total distance to the entity, the time delay in sending the messages, and the cost of sending the
messages. Distance-vector protocols compute the optimal routes from this information and then share that
information with adjacent entities on the same network. Routers running RIP may participate as either active
or passive devices. A device running in active mode will advertise its routes, while a passive device will
silently listen to advertisements. For obvious reasons, routers generally run in active mode while hosts often
run in passive mode when running RIP.

RIP is used to convey information about routes to destinations. RIP relies on access to information about its
directly connected networks. An active RIP device accomplishes this access by periodically advertising its
routing information. The information that RIP uses to construct these updates is taken from the routing table
(or the RIP database in Cisco IOS® 12.0T and later). The routing table contains one entry for every
destination that is reachable within the system. Each entry has the following information:

• IP address of the destination

• A metric that represents the total cost of getting a datagram from the host to the destination
• The IP address of the next router along the path to the destination
• Timers associated with the router
 • The route change flag that indicates that the information about the route has changed recently

The following is an example of a RIP routing table:

RIP maintains only the best route to a destination. In order to prevent routing information from oscillating
between two or more equal-cost paths, the RFC specifies that updates from different next hops should be
used only if the reported metric is less than the currently installed route. Metric changes received from the
existing gateway are installed immediately. The Cisco implementation allows routes with identical metrics for
the same network to be simultaneously installed for load balancing.
Network topology changes can cause changes in routes. These changes can result in a new route becoming
the best route to a particular destination. When network topology changes occur, they are reflected in
routing update messages. For example, when a router detects a link or router failure, it recalculates its
routes and sends routing update messages. Each router receiving a routing update message that includes a
change updates its tables and propagates the change.

RIP uses a single routing metric, hop count, to measure the distance between the source and destination
networks. Each hop in this path is assigned a hop-count value, which with RIP is usually 1. When a router
receives a routing update that contains a new or changed destination-network entry, the router adds one to
the metric value indicated in the update and enters the network in the routing table. The IP address of the
sender is used as the next hop. This method for incrementing the routing metric will theoretically provide
loop-free routing information in a perfectly stable environment, but when the topology changes or when
networks become inaccessible, it can lead to two classic problems faced by traditional distance-vector
routing algorithms: slow convergence or count to infinity.
Routing information about topology changes propagates slowly throughout a network because of
inconsistencies between the routing tables of the routers in the network. Limiting the number of hops in a
network helps to improve this convergence problem. Limiting the number of hops allowed also prevents
routing loops from continuing indefinitely. RIP is limited to networks whose longest path involves 15 hops.
With RIP, if a router receives a routing update that contains a new or changed entry, and if increasing the
metric by one causes the metric to be 16, the network destination is considered unreachable. In other words,
16 is equivalent to "infinity" in a RIP network. If a network becomes completely inaccessible, then routers
could mutually deceive each other and "count to infinity," as shown in the following example:
Router_C is advertising the network 192.100.10.x with a cost of one. Router_A is advertising the network
192.100.10.x with a cost of two. If the connection between Router_C and the network 192.100.10.x is lost,
then Router_C will advertise it with a cost of 16 (infinity). If Router_A advertises the network 192.100.10.x
back to Router_C before the "infinite" metric is received, then Router_C may incorrectly believe that
Router_A can still reach the target network with a cost of two. Router_C will advertise the network
192.100.10.x back to Router_A with a cost of three. This routing loop will continue until both routers
eventually "count to infinity." RIP designers chose 16 to be infinity because they wanted the number to be
small enough that when networks become completely inaccessible, the counting would stop as soon as
possible. The choice of 16 as infinity is a tradeoff between network size and the speed of convergence. The
designers of RIP believed that it would be impractical to implement RIP in networks with diameters larger
than 15.

RIP also uses timers both to regulate its performance and to help prevent routing loops like those shown
above. All routers that use RIP send an update message to all of their neighbors approximately every 30
seconds; this process is termed advertising. The RFC specifies that advertisements should be randomized
by up to +/– five seconds in order to prevent synchronization of routing updates. The Cisco implementation
sends updates every 30 seconds minus up to 15 percent, or 4.5 seconds.
If a neighbor has not responded in 180 seconds, it is assumed that the neighboring router is unavailable or
the network connecting it to the router has become unusable. When the neighbor has not responded for 180
seconds, the route is marked invalid; 180 seconds is long enough that a route won't be invalidated by a
single missed update message. The neighbor is shown to be unreachable by sending a normal update
message with a metric of "infinity;" in the case of RIP, this number is 16. If an advertisement is received from
a neighbor with a metric of infinity, then the route is placed into holddown state, advertised with a distance of
16, and kept in the routing table. No updates from other neighbors for the same route are accepted while the
route is in holddown state. If other neighbors are still advertising the same route when the holddown timer
expires, then their updates will then be accepted. The route will be advertised with an infinity metric for a
period of time after the holddown state if no alternate paths are found.
The actual timers used to accomplish the above tasks are a routing-update timer, a route-invalid timer, a
route-holddown timer, and a route-flush timer. The RIP routing-update timer is generally set to 30 seconds,
ensuring that each router will send a complete copy of its routing table to all neighbors every 30 seconds.
The route-invalid timer determines how much time must expire without a router having heard about a
particular route before that route is considered invalid. When a route is marked invalid or put in holddown
state, neighbors are notified of this fact. This notification must occur prior to expiration of the route-flush
timer. When the route flush-timer expires, the route is removed from the routing table. Typical initial values
for these timers are 180 seconds for the route-invalid and route-holddown timers and 240 seconds for the
route-flush timer.
The values for each of these timers can be adjusted with the timers basic router configuration command.
Information concerning the RIP process, including the timers, can be seen with the show ip protocol
command. A sample output from this command is shown in the following example:

Router-1#show ip protocol
Routing Protocol is "rip"
Sending updates every 30 seconds, next due in 18 seconds
Invalid after 180 seconds, hold down 180, flushed after 240
Outgoing update filter list for all interfaces is
Incoming update filter list for all interfaces is
Outgoing routes will have 10 added to metric if on list 1
Redistributing: rip
Default version control: send version 1, receive any version
Interface Send Recv Triggered RIP Key-chain
Ethernet0/0 1 1 2
Routing for Networks:
172.16.0.0
Routing Information Sources:
Gateway Distance Last Update
172.16.4.1 120 00:00:20
Distance: (default is 120)
Router-1#

To adjust for rapid network-topology changes, RIP specifies numerous stability features that are common to
many routing protocols. RIP implements split horizon with poison-reverse and holddown mechanisms to
prevent incorrect routing information from being propagated. Split horizon prevents incorrect messages from
being propagated by not advertising routes over an interface that the router is using to reach the route.
Implementing split horizon helps avoid routing loops. Poison reverse operates by advertising routes that are
unreachable with a metric of infinity back to the original source of the route. Holddown is a method of
marking routes invalid (expired). As discussed above, no updates from other neighbors for the same route
are accepted while the route is in holddown state.
Triggered updates are also an included convergence and stability feature. Updates are triggered whenever a
metric for a route changes. Triggered updates may also contain only information regarding routes that have
changed, unlike scheduled updates. There is a minimum delay of five seconds between triggered updates to
prevent update storms.

RIP is a User Datagram Protocol (UDP)-based protocol. Each router that uses RIP has a routing process
that sends and receives datagrams on UDP port number 520, the RIP port. All communications for the RIP
process of the router use this port. All routing update messages are sent from the RIP port and unsolicited
routing update messages have both the source and destination port equal to this port. RIP V1 traffic is sent
as a broadcast to the 255.255.255.255 IP address by default.
The following is the packet format for the original version of RIP, defined in RFC 1058:

The Command field indicates whether the packet is a request or a response. The request asks a router to
send all or part of its routing table. The response can be an unsolicited update message or a reply to a
request. Responses contain routing-table entries. Multiple RIP packets are used to contain information for
large routing tables.
The Version Number field specifies the RIP version used. This field can signal potentially incompatible
versions.
The Zero field is not used.
The Address-Family Identifier (AFI) specifies the address family used. RIP is designed to carry routing
information for several different protocols. Each entry has an AFI to indicate the type of address being
specified. The AFI for IP is 2.
The Metric, as stated earlier, indicates how many hops have been traversed in the trip to the destination.
The value is between 1 and 15 for a valid route, or 16 for an unreachable route.
The RIP V1 packet format does not distinguish among different types of addresses. Fields that are labeled
"address" can contain any of the following:

• Host address
• Subnet number
• Network number
• Zero (default route)

Entities that use RIP V.1 are supposed to use the most specific information available
when routing a datagram. First, the destination address of the datagram is checked
against the list of node addresses. Then it is checked to determine whether it matches
any known subnet or network number. If none of these match, the default route is used.
Note: All routes received on an interface are assumed to have the subnet mask of that interface. Because of
this, if the subnet masking is different on interfaces within the same major network, updates will not be
exchanged between these interfaces because of the possible resulting ambiguity. Updates that do not fit
with the assumed subnet mask are considered to be host routes. If an update including a route from a
different major network is received on an interface, the router must assume that the update is for the entire
major network. For this reason, there is no way to disable autosummarization with RIP V.1.
Default Routes in RIP
As mentioned above, a default route will be used to route packets if a longer match is not found in the
routing table. When RIP is used to advertise the default route, the address field in the packet contains zero,
referring to the 0.0.0.0 IP network address. Unlike other protocols, RIP will automatically advertise the
default route as long as a default route from any source is installed in the routing table on the router; no
additional redistribution commands are necessary. In versions prior to 12.0(1)T, a default can be forcibly
advertised using the default-information originate command even though no default route is known by the
router.

RIP Version 2, or RIP V.2, was created to add additional functionality to the original RIP and also cope with
some new issues that arose after RIP was defined. RIP V.2 uses the same basic algorithms as RIP V.1, but
supports external route tags, subnet masks, next-hop addresses, and authentication. RIP V.2 is backward
compatible with RIP V.1.

External Route Tags

RIP V.2 includes a Route Tag field, which is an attribute assigned to a route that must be preserved and
readvertised with a route. This field provides a mechanism to separate "internal" RIP routes (routes for
networks within the RIP routing domain) from "external" RIP routes, which may have been imported from an
Exterior Gateway Protocol (EGP) or another IGP.

Subnet Mask
RIP V.2 allows the use of variable subnet masks on the network. In RIP V.1, there is a subnet/host
ambiguity because nodes do not know the subnet masks, so evaluating the address can be ambiguous. In
RIP V.2 there is a Subnet Mask field, which is applied to the IP address to yield the nonhost portion of the
address. If this field is zero, then no subnet mask has been applied.

Next-Hop Addresses
RIP V.2 supports next-hop addresses; this setup allows for optimization of routes in an environment that
uses multiple routing protocols. For example, if RIP V.2 was running on a network with Enhanced Interior
Gateway Routing Protocol (EIGRP) and one router ran both protocols, then the router could indicate if a
better next hop than itself exists for a given destination. This setup eliminates packets from being routed
through extra hops in the system.
The Next-Hop field is an "advisory" field, and if the provided information is ignored, another suboptimal route
may be taken. If the received next hop is not directly reachable, it should be treated as 0.0.0.0.

Authentication
RIP V.2 offers an authentication mechanism, which is a per-message function. With RIP V.2, there is only a
2-octet field available in the message header and since 2 octets are obviously not enough, the
authentication scheme uses the space of an entire RIP entry.
To identify if the entry contains authentication, check to see if the AFI of the first entry is 0xFFFF. If it is,
there can be a maximum of 24 RIP entries in the remainder of the message. The AFI or 0xFFFF should not
be used if authentication is not being used.
The authentication type for RIP V.2 is a simple password, and it is type 2. The remaining 16 octets contain a
plaintext password. If the password is under 16 octets, it must be left-justified to the right with nulls (0x00).

Multicasting
RIP V.2 packets may be multicast instead of being broadcast. The multicast address is 224.0.0.9.
Multicasting reduces the load on hosts that do not support routing protocols, and also allows RIP V.2 routers
to share information that RIP V.1 routers cannot hear. This feature is useful since a router running the
original version of RIP may misinterpret route information because it cannot apply the subnet mask.
The RIP V.2 specification, described in RFC 2453, allows for the above functionality to be incorporated as
information into the packet. The following shows a RIP V.2 packet:

The Command field indicates whether the packet is a request or a response. The request asks that a router
send all or part of its routing table. The response can be an unsolicited regular routing update or a reply to a
request. Responses contain routing-table entries. Multiple RIP packets are used to convey information from
large routing tables.
The Version field specifies the RIP version used. In a RIP packet implementing any of the RIP V.2 fields or
using authentication, the value is set to 2.
The Unused field has a value set to zero.
The Address Format Identifier (AFI) field specifies the address family used. RIP is designed to carry routing
information for several different protocols. Each entry has an AFI to indicate the type of address specified.
The AFI for IP is 2. If the AFI for the first entry in the message is 0xFFFF, the remainder of the entry
contains authentication information.
The Route Tag field provides a method for distinguishing between internal routes, learned by RIP, and
external routes that were learned from other protocols.
The IP Address field specifies the IP address for the entry.
The Subnet Mask contains the subnet mask for the entry. If this field is zero, no subnet mask has been
specified for the entry.
The Next-Hop field indicates the number of hops that have been traversed in the trip to the destination. This
value is between 1 and 15 for a valid route, or 16 for an unreachable route.
Note: Up to 25 occurrences of the AFI, address, and metric fields are permitted in a single RIP packet. In
other words, up to 25 destinations may be listed in any single RIP packet. Multiple RIP packets are used to
convey information from larger routing tables.

Interaction between RIP V.1 and RIP V.2

Since RIP V.1 packets do not contain subnet mask information, routers on networks that contain both RIP
V.1 and RIP V.2 should use the semantics employed by RIP V.1 only. If not, there is the possibility of routes
for networks that do not exist or excessive routing information in a Version 1 environment.
By default, Cisco IOS software receives RIP V.1 and RIP V.2 packets, but sends only RIP V.1 packets. You
can configure the software to receive and send only Version 1 packets. Alternatively, you can configure the
software to receive and send only Version 2 packets.
In some RIP implementations, autosummarization is used. Autosummarization is an attempt to summarize
groups of adjacent routes into single entries in order to reduce the number of entries in routing tables.
Summarization is done on major network boundaries. When using RIP V.2, autosummarization can be
disabled.

You have now learned the fundamentals of the RIP routing protocol. This protocol incorporates many of the
basic concepts taught in the "Cisco Interactive Mentor: Basic IP Routing Concepts" module. Now, you can
gain hands-on experience by configuring RIP in the RIP Configuration Labs and use your troubleshooting
knowledge in the RIP Challenge Lab.

Now proceed with the RIP Lab Project.

This tutorial provides information on the fundamentals of the Open Shortest Path First (OSPF) routing
protocol. After you have reviewed the material in this introductory section, proceed to the Configuration and
Troubleshooting sections, which include hands-on lab exercises.

Remember: Use the Pop Quiz feature to test your understanding throughout this course.

At the end of this tutorial, you will be able to:

• Describe the differences between link-state and distance-vector routing protocols.

• Visualize how OSPF operates.
• Understand the hello protocol and its role in forming neighbors and adjacencies.
• Display an OSPF link-state database and interpret its contents.
• Understand various OSPF extensions, such as stub areas, totally stubby areas, not-so stubby
areas, and on-demand circuits.
• Configure OSPF.
• Redistribute external routes into OSPF, and configure an ASBR to advertise a default route into an
OSPF domain.
• Monitor OSPF processes with show commands.
• Use debugging commands to monitor and debug OSPF processes.
• Configure OSPF over NBMA networks.
• Configure stub, totally stubby, and not-so stubby areas.
• Configure virtual links.
• Propagate multiple routes into external areas.

Begin with Understanding Open Shortest Path First.

The Open Shortest Path First (OSPF) routing protocol is based on link-state technology, as opposed to
distance-vector protocols such as Interior Gateway Routing Protocol (IGRP) and Routing Information
Protocol (RIP). OSPF offers several advantages over distance-vector protocols. It has faster convergence,
supports larger internetworks, and is less susceptible to bad routing information. Some of the features of
OSPF follow:

• Hierarchical routing
• Classless behavior, allowing support of variable-length subnet masks (VLSMs) and discontiguous
networks
• The use of multicast addresses in order to reduce the effect of non-OSPF routing devices
• Authentication for secure routing

OSPF is a routing protocol that calls for the sending of link-state advertisements (LSAs) to all other routers
within the same hierarchical area. An area is a group of contiguous networks and attached hosts. OSPF
LSAs include information on attached interfaces, metrics used, and other variables. As OSPF routers
accumulate information, the routers use the SPF algorithm to calculate the shortest path to each node. This
is different from the way distance-vector protocols work. Distance-vector protocols send all or a portion of
their routing tables in routing-update messages to their neighbors. Configuring and troubleshooting OSPF
networks is more complex than with its distance-vector counterparts.

The following is an overview on how OSPF operates:

• Routers running OSPF will send OSPF hello packets to all OSPF-enabled interfaces.
• Routers sharing a common data link will become OSPF neighbors if their hello packets contain
certain information that is mutually agreed upon.
• OSPF neighboring routers may form an OSPF adjacency if it is determined that there are certain
commonalties between the routers exchanging hellos and the network over which the hellos are
exchanged. Not all neighboring routers will form adjacencies.
• Routers will send (flood) LSAs over all adjacencies.
• All routers will build identical databases the LSAs.
• Shortest-path trees are calculated from the newly assembled routing tables.

Hellos
OSPF neighbors are identified by their router IDs. A router ID is an IP address by which the router is
uniquely identified within the OSPF domain. A Cisco router selects its router ID as the highest IP address on
any loopback interfaces configured on the router. If no loopback interfaces are configured on the router, the
router chooses the highest IP address of any of its physical interfaces.
Routers that share a common segment may become neighbors on that segment. Neighbors are discovered
via the OSPF Hello protocol and are recorded in a neighbor table.
The Hello protocol:

• Provides a way to discover OSPF neighbors

• Acts as a keepalive between neighbors
• Ensures bi-directional communication between neighbors
 • Is used for designated router (DR) and backup designated router (BDR) election on certain types of
networks

Hello packets are sent out all OSPF-enabled interfaces. They are sent out periodically with a special
multicast address as the destination. Routers will become neighbors when they see themselves (their own
router ID) in their neighbor’s hello packets and they agree upon certain parameters included in the hello
packets. Neighbor negotiation will take place on the primary IP address only, not over secondary addresses.
If secondary addresses are configured on the interface, they are restricted to be in the same OSPF area as
the primary address.
Two routers will become neighbors if the following parameters are agreed upon:

• Area ID — The two routers sharing a common network segment must have their interfaces
configured to be in the same area.
• Authentication — OSPF allows for configuration of a password for a specified area. Routers that
want to become neighbors must exchange the same password over the common segment.
• Hello and Dead intervals — The hello interval is the amount of time between hello packets that a
router sends out on an OSPF-enabled interface. The dead interval is the amount of time, in
seconds, that a router will wait for a hello packet from a neighbor before declaring the neighbor
down. These interval times are included in the hello packet and must be agreed upon by neighbors.
• Stub area flag — Two neighboring routers must also agree on the stub area flag in the hello
packets in order to become neighbors. (Stub areas will also be discussed later.)

All of the above parameters are included in hello packets. Also included in hello packets are the following:

• The router ID of the originating router

• The address and mask of the originating interface
• Router priority, which is used for DR election (discussed later)
• The DR and BDR
• Flag bits for option capabilities; one of these is the stub area flag mentioned above
• Router IDs of the originating router neighbors

Network Types
After two-way communication between neighbors is established, OSPF routers move on to the next step,
which is building adjacencies. Adjacent routers are routers that go beyond the hello protocol exchange and
proceed into the database exchange process.
As previously mentioned, not all neighboring routers become adjacent. Whether or not an adjacency is
formed depends on the type of network to which the neighboring routers are connected.
The types of networks that OSPF defines follow:

• Point-to-point networks
• Broadcast networks
• Non-Broadcast Multi-Access networks (NBMA)
• Point-to-multipoint networks

Point-to-point networks, such as serial lines, connect a single pair of routers. OSPF will always form an
adjacency with the neighbor on the other side of a point-to-point interface. There is no concept of DR or
BDR on point-to-point networks. The destination address of OSPF packets on these networks will always be
sent to 224.0.0.5, otherwise known as the ALLSPFRouters multicast address.
Broadcast networks, such as Ethernet, Token Ring, and Fiber Distributed Data Interface (FDDI), are multi-
access, meaning they are able to connect more than two devices; a packet sent by one router will be
received by all connected routers. On broadcast networks, OSPF will elect a DR and a BDR. Hello packets
on broadcast networks are sent to the destination address of 224.0.0.5. All packet originated by the DR and
BDR are also sent to the this address. All other non-DR and non-BDR routers will send link-state updates to
the address 224.0.0.6, also known as AllDRouters.
NBMA networks, such as Frame Relay, ATM, and X.25, can connect multiple devices, but they have no
broadcast capability. (For more information on Frame Relay, please read the Frame Relay document.) A
packet sent by a router will not be received by all the other routers attached to the network. Special care
should be taken when configuring OSPF over NBMA networks. OSPF considers these media to be just like
any other broadcast media such as Ethernet or Token Ring. As a result, extra configuration may be required
for NBMA networks. OSPF routers elect a DR and BDR, and all OSPF packets are unicast.
Point-to-multipoint networks are NBMA networks in which the networks are treated as a collection of point-
to-point links. Routers on these networks do not elect a DR and BDR because the network is seen as point-
to-point links. OSPF packets are multicast on these networks.
Designated Router and Backup Designated Router
The DR and BDR are elected on broadcast networks in order to prevent certain problems. First, if every
router attached to a broadcast network formed an adjacency with every other router attached to the network,
there would be n(n - 1)/2 adjacencies. Second, if a router flooded its LSAs to all of the router neighbors and
all routers in turn flooded the LSA to their neighbors, there would be multiple copies of the same LSA on the
same network.
The idea behind the DR is that every router attached to the network would form an adjacency with the DR.
Only the DR would send LSA to the rest of the attached network. OSPF also elects a BDR in the event that
the DR fails. This prevents routers from having to reelect a DR and reforming adjacencies with the new DR.
Instead, the routers attached to the network form an adjacency with both the DR and BDR. If the DR goes
down, the BDR becomes the DR; since the other routers already have a formed adjacency with the BDR,
there is little, if any, network unavailability.
DR and BDR election is done via the Hello protocol. Hello packets are exchanged via IP multicast packets
on each segment. The router with the highest OSPF priority on the segment will become the DR. Default
priority is one for Cisco router interfaces. This process is repeated for the BDR. If the priorities are the same,
the router with the highest router ID will become the DR. A single DR/BDR pair is elected on each attached
segment. A router that is the DR of one segment may not be the DR or BDR of another attached segment.
Setting the OSPF priority of an interface can be done with the interface subcommand:
ip ospf priority [value]
A priority value of zero indicates that the interface will not be elected as the DR or BDR.
Note that once a DR and a BDR have been elected, a new router coming on line that has a higher priority
will not override the DR and BDR. When the new OSPF router becomes active and discovers its neighbors,
it checks for valid DR and BDR. If the DR and BDR exist, the new router will accept them. Routers that are
not the DR or BDR are known as DRother.

In the diagram above, the router that will be elected DR for Segment 1 will be Router_F. This is because the
priorities of all the router interfaces are equal (P = 1 on all the interfaces). This results in the router with the
highest router ID (RID) as being elected the designated router. Router_F has the highest RID and is,
therefore, the DR.
On segment 2, Router_C does not have the highest RID, but it still is elected the DR because its OSPF
interface priority, which is 2, is higher than all the rest.
The diagram below shows the resulting adjacencies that will be formed on segment 1 of the diagram above.
Note that the routers that are not DR will form adjacencies only with the DR. In this illustration, the BDR is
not shown, but adjacencies would also be formed with the BDR.
Building Adjacencies
After neighbor discovery takes place and bi-directional communication is established (a router sees its own
router ID in neighbor hello packet), neighboring routers attempt to synchronize their link-state databases.
When database synchronization in successful, the neighbors are fully adjacent.
Neighbors on point-to-point and point-to-multipoint networks always become adjacent unless the parameters
of the hello packets are not agreed upon. On broadcast networks and NBMA networks, the DR and BDR
become adjacent with all neighbors. No adjacencies will be formed between the DRothers.
The following are states through which OSPF routers will transition neighbors before being considered fully
adjacent:

• Down –— This is the initial state of the neighbor, indicating no information has been received from
any router on the segment.
• Attempt –— On NBMA networks, where neighbors are manually configured, this state indicates that
no recent information has been received from the neighbor. An effort is made to contact the
neighbor by sending hello packets.
• Init –— This state indicates that a hello is received from a neighbor; however, bi-directional
communication is not yet established.
• Two-way –— The router has seen itself in the neighbor hello packets. Bi-directional communication
is now established. On broadcast networks DR and BDR are elected at the end of this state. When
this state ends, a decision is made whether or not to proceed in building an adjacency. The
decision is based on whether the neighbor is a DR or BDR or the network link is point-to-point.
• ExStart –— The router and its neighbor establish a master/slave relationship and determine the
initial sequence number that is going to be used in the exchange of database description packets.
• Exchange –— Routers will describe their entire link-state database by sending database
description packet to neighbors that are in the exchange state.
• Loading –— Routers build a link-state request list and retransmission list. Any information that
looks outdated or incomplete will be put on the request list. Any update that has not been
acknowledged will be put on the retransmission list.
• Full –— The adjacency is now complete. Adjacent routers will have identical link-state databases.

Flooding
The OSPF link-state database consists of all the LSAs the router has received. Each node in the network
maintains an identical link-state database. A change in the topology means a change in one or more of the
LSAs. Flooding is the process by which these new LSAs are sent throughout the network in order to ensure
that the databases in all routers remain identical.
Areas
Because of its complexity with multiple databases and flooding algorithms, OSPF can be memory and
processor intensive. The demand for memory and processor utilization grows as the network grows.
OSPF uses areas to reduce the strain on router memory and processor utilization. An area is a logical
grouping of routers that break the OSPF network into subdomains. Routers must share identical databases
with routers in its area only, not with the entire network. This reduces the memory demand. The smaller
database results in a smaller number of LSAs to process, thereby reducing the demand of processing
power. Most flooding is also limited within an area.
Areas are interface specific and are identified with an area ID. The introduction of areas also introduces a
different type of traffic. Intra-area traffic consists of packets that are contained within an area; inter-area
packets travel between routers in different areas. External traffic consists of packets that travel between
routers belonging to an OSPF domain and another autonomous system.
Backbone
If more than one area is configured, one of these areas must be defined as area 0. Area 0 is known as the
backbone area. All other areas must be logically connected to area 0 either physically or through a virtual-
link. Virtual-links are explained below. Each area gives routing information to area 0 which in turn
disseminates that information to all other connected areas. For this reason, all inter-area traffic must pass
through area 0. Non-backbone areas cannot exchange packets directly with one another.
Virtual Links
As mentioned above, all other areas must be physically connected to the backbone area, area 0. In some
cases where this is not possible, a virtual link can be used. The virtual link will provide a link to the backbone
through a nonbackbone area. Virtual links are also used to connect two parts of a partitioned backbone
through a nonbackbone area.

As shown in the above diagram, virtual links can be established between two area border routers (ABRs)
that have a common area, with one ABR connected to the backbone.
The transit area is defined as the area between two ends of a virtual link. The transit area must be
connected to area 0 to have full routing information and cannot be a stub area.
OSPF classifies virtual links as point-to-point networks with no IP subnets associated with them.
Router Types
As mentioned above, areas are interface specific, meaning that a router can have one interface configured
in one area and a second interface configured in a second area. Therefore, routers can be categorized in
relation to areas. There are three types of OSPF routers.

• Internal routers (IRs) –— An internal router is a router with all of its interfaces in the same area.
• Area border routers (ABRs) –— An ABR is a router that has interfaces in multiple areas. An ABR
must always have at least one interface in the backbone area.
• Autonomous system boundary routers (ASBRs) –— ASBRs are routers that act as gateways
between OSPF and other routing protocols or other OSPF routing processes. In other words,
redistribution takes place on the ASBRs.
All valid LSAs received by a router are stored in a link-state database. These LSAs describe the topology of
an area. Routers use the LSAs to calculate the shortest path tree.
The list of LSAs in the database can be viewed with the command show ip ospf database. This list shows
only the information in the LSA header, but it also contains LSAs from multiple areas if the router were an
ABR. More detailed information of each LSA can be viewed with different commands, which will be
explained later. An example output of the show ip ospf database command follows:
Router_B#show ip ospf database
OSPF Router with ID (170.170.3.2) (Process ID 7)

Router Link States (Area 0)

Link ID ADV Router Age Seq# Checksum Link count
170.170.3.2 170.170.3.2 17 0x80000002 0x8B6 1
170.170.8.4 170.170.8.4 217 0x80000003 0xAA02 1
170.170.13.3 170.170.13.3 218 0x80000002 0x5156 1
Net Link States (Area 0)
Link ID ADV Router Age Seq# Checksum
170.170.3.3 170.170.13.3 18 0x80000002 0xA0B2
Summary Net Link States (Area 0)
Link ID ADV Router Age Seq# Checksum
170.170.7.0 170.170.8.4 240 0x80000001 0x6ED0
Summary ASB Link States (Area 0)
Link ID ADV Router Age Seq# Checksum
170.170.11.6 170.170.8.4 129 0x80000001 0xF73C
Type-5 AS External Link States
Link ID ADV Router Age Seq# Checksum Tag
200.200.200.0 170.170.11.6 135 0x80000001 0xE4FA 0
Router_B#
As can be seen from the information in the database in the above diagram, there are different types of LSAs
defined by OSPF. Each type describes a different portion of the OSPF network. The table below lists the
different LSA types and type codes and how the link-state is identified. Following the table is a description of
the LSAs.
Different LSA Types
Type Code LSA Link-State ID
1 Router LSA Originating router ID of the router

2 Network LSA Interface IP address of the DR

3 Network summary LSA Destination network number

4 ASBR summary LSA Router ID of AS boundary router

5 AS external LSA External network number

7 NSSA external LSA External network number

Router LSAs are generated by every router. The router LSA is a list of links attached to the router, as well as
the state of the link and the outgoing OSPF cost associated with the link. To view details of the router LSA,
use the show ip ospf database router command.
Router LSA

Network LSAs are generated by the DR on a multi-access segment. They are the representation of the
multi-access segment and all the routers attached to the segment. Segments that do not have a DR, such
as point-to-point, will not have a network LSA. To view detailed information of the network LSA, use the
show ip ospf database network command.
Network LSA

Network summary LSAs are generated by ABRs. This is how network reachability information is advertised.
ABRs are responsible for injecting information into the backbone and the backbone will pass the information
on to other areas. The show ip ospf database summary command can be used to view detailed
information of the summary LSA.
Network Summary LSA
ASBR summary LSAs are also generated by the ABR. This LSA describes the location of an ASBR, not a
network. The details can be viewed with the show ip ospf database asbr-summary command.
ASBR Summary LSA

Autonomous System (AS) External LSAs are originated by the ASBRs and describe a network outside of the
AS. They can be viewed with the show ip ospf database external command.
AS External LSA

Not-So-Stubby Area (NSSA) external LSAs are originated by the ASBR within the NSSA. These types of
LSAs are flooded only throughout the NSSA. These are unlike external LSAs, which are flooded throughout
the entire network.
Stub Areas
ASBR routers will flood external routes throughout the OSPF domain. For this reason, OSPF allows certain
areas to be configured as stub areas. Stub areas are areas into which external LSAs are not flooded.
Routing from these areas to other parts of the OSPF network is done via the default route. The advantage to
using stub areas is that the reduction of the link-state database reduces the requirements for memory.
All OSPF routers inside a stub area must be configured as stub routers. Since all interfaces belonging to the
area will start exchanging hello packets, the stub flag must be set in order to successfully form a neighbor
relationship.
Also, virtual links cannot be configured within or transit a stub area.
Examples of stub areas and how to configure them will be shown in the "Configuring OSPF" section.
Totally Stubby Areas
Totally stubby areas are areas into which external LSAs and summary LSAs (inter-area routes) are not
flooded. The only thing injected into the totally stubby area are intra-area routes and the default route
(0.0.0.0). The default route is the only type 3 (summary) LSA that the ABR will allow into the totally stubby
area.
An example of totally stubby areas and their configuration is discussed in the "Configuring OSPF" section.
Not-So Stubby Areas
In some cases, it may be necessary to connect a stub area to an external AS and redistribute the external
routes into OSPF. Unfortunately, this means that the stub area router will become an ASBR, meaning the
area can no longer be a stub area.
NSSAs allow external routers to be advertised into the OSPF AS while retaining the characteristics of a stub
area. The ASBR in the NSSA will originate type 7 LSAs. These external NSSA LSAs are flooded throughout
the NSSA but are blocked at the ABR. The ABR will translate this into a type 5 LSA and flood it into the
other areas.
An example of NSSAs and their configuration is discussed in the "Configuring OSPF" section.
OSPF On-Demand Circuits
OSPF demand circuit is an enhancement to the OSPF protocol that allows efficient operation over on-
demand circuits such as ISDN and dial-up lines. Prior to this feature, periodic hellos and LSA updates would
be exchanged between routers that connected the on-demand link, even when there were no changes in the
Hello or LSA information.
With this feature, periodic Hellos are suppressed and periodic refresh of LSAs are not flooded over demand
circuits. These packets bring up the link only when they are exchanged for the first time, or when there is a
change in the information they contain.

You have now learned the fundamentals of the OSPF routing protocol. This protocol incorporates many of
the basic concepts taught in the "Cisco Interactive Mentor: Basic IP Routing Concepts" module. Next you
will learn the basic steps involved in configuring OSPF.

Now proceed to Configuring OSPF.