Basic OSPFv2 in depth

OSPF is one of the core topics of the CCIE R&S lab exam and therefore one should be an expert at it before
attending the lab exam.
In this post I would like to explore OSPFv2 and especially how OSPF uses its algorithm to find the best path to
a destination. I will try to cover most of the general OSFP topics such as basic configuration, types of LSAs,
Path selection, External path selection with LSA Type 5, Default routing, Conditional Default Routing, the
different types of Stub areas, Virtual-links, LSA Type 3 filtering and Prefix filtering with route-maps. I have to
admit that this post is quite long :-)
For this post I will use the following topology:

IGP: OSPF
Platform/IOS: Cisco 2691/12.4(15)T11 Adv IP services
Introduction
OSPF was developed by the Internet Engineering Task Force (IETF) as a replacement for the problematic RIP.
Version 2 which is still the current version for IPv4 is defined in RFC.2328 (RFC 2328). OSPF is categorized as
a link-state routing protocol. The basic concept of link-state routing is that every node constructs a map of the
1

connectivity to the network, in the form of a graph showing which nodes are connected to which other nodes.
Each node then independently calculates the next best logical path from it to every possible destination in the
network. The collection of best paths will then form the nodes routing table.
In OSPF the routers use the OSPF Link State Database (LSDB) as an input to Dijkstras Shortest Path First
(SPF) algorithm in order to find the shortest path to a destination network. That implies that all routers in the
same OSPF area have a unique LSDB in order to make correct calculation. In the other category of routing
protocol which is Distance Vector protocol like EIGRP, The routing is done by rumors. That is to say, the
nodes dont have a full picture of the network like in OSPF and base their routing on which routing information
they have learned from their neighbors. So OSPF does not advertise routes but topology information.
One of the advantages of OSPF is that it uses areas, which reduces the protocols impact on CPU and memory,
contains the flow of routing protocol traffic, and makes possible the construction of hierarchical network
topologies.
OSPF packets are encapsulated in IP with protocol number 89.
In order to build the LSDB every router must first have a Router ID (RID) and each router must have a unique
RID in the OSPF domain as this value is used to uniquely identify each router in the LSDB. Once we start the
process we have to make sure that at least one interface is running IPv4 and it is up/up state and this is the
interface which is used to generate the RID. By default the OSPF RID will prefer to use the highest loopback IP
address but if there are no loopbacks in the up/up state OSPF process will take whatever the highest IP is on
another interface. The RIB should be set manually to avoid depending on a loopback so if the previously used
loopback for RIB is shut down it doesnt alter the OSPF process.
Like in EIGRP, OSPF forms active adjacency with its neighbors and the following parameters must match in
order for two OSPF neighbors to form adjacency:
Authentication, same subnet, same area, no duplicate RIB, Hello and dead timer equal, MTU, STUB flag. In
EIGRP for example, the timer are not required to match for forming adjacency.
OSPF adjacency is going through the following steps before is fully formed between two neighbors:

send Hello(init)

send and rcv (2 way)

DR election (Exstart)

DD excahnge (exchange)

LSR/LSU/LSAck (Loading full)

The LSDB is made of LSAs (Link State Advertisements). The LSAs described all of the routers links,
interfaces, the routers neighbors and the state of the links. There are different types of LSAs because of the
varying types of link-state information. When two routers are in the exchange phase they synchronize their
LSAs which result in exact LSDB on all routers in the same area so each router can individually run the SPF
algorithm on the LSDB to find the shortest path to each destination.
2

OSPF process will behaved differently based on the network type it is configured on:
For example on broadcast network OSPF uses the concept of DR (Designated Router), BDR (Backup
Designated Router), and DROTHER (Not DR/BDR). The formation of an adjacency between every router on
a broadcast medium will create many unnecessary LSAs so flooding on the network itself would be chaotic and
excessive. A router would flood an LSA to all its adjacent neighbors, which in turn would flood to all their
adjacent neighbors creating many copies of the same LSA on the same network.
To alleviate this problem a DR is elected on multi-access networks and represents the multi-access network and
its attached routers to the rest of the OSPF area and also manage the flooding process on the multi-access
network.
All OSFP routers send Hello to 224.0.0.5 to discover eventually neighbors on a multi-access network and form
full adjacency only with the DR and BDR while staying in 2 way state between each other. So the exchange of
the LSDB is only occurring with the DR and the BDR. DROTHER are sending LSAs information to 224.0.0.6
and only the DR and BDR are listening to this multicast address as well as 224.0.0.5 while the DROTHER are
listening to 224.0.0.5.
I will cover the rest of the OSPF theory during the configuration examples. So lets start with the configuration
of OSPF!
Basic OSPF Configuration
Please refer to the topology located at the beginning of the post from now on. I will start by configuring each
router in its respective area as illustrated on the topology. IP address and loopback addresses are already
configured. Please not that for now, areas, 6,8,9,7 are not STUB or NSSA as we will talk about that later on.
Each router-ID will be configured manually under the routing process in the format X.X.X.X where X is the
route number.
So lets see what is happening as soon as we configured OSPF on R2:

From the Wireshark output above we can see that R2 is sending OSPF hello packets to the multicast address
224.0.0.5 (all OSPF routers) with a frequency of 10 sec. R2 is also identifying itself in the Hello packet with the
3

RID 2.2.2.2 (the one we manually configured). The Authentication is NULL (OSPF uses 3 type of
authentication (0,1,2) were type 0 is null, basically it means that packets are not authenticated, type 1 is clear
text and type 2 is MD5). You can notice that there is no DR or BDR yet on this segment (connecting to R8) as
the OSPF process on R8 has not been started yet. Finally we can see that the AREA number (area 8) is also
advertised in the hello packet.
To see how the DR/BDR election process works as well as how the LSDB is exchanged between two routers let
s take the case of R2 and R8 when they start discovering each other through Hello packets:

From the debug output above we can see the different phases we talked about before when OSPF neighbor
discover each other through OSPF hello multicasted to 224.0.0.5. After the 2 way state the routers on the multiaccess broadcast segment elect a DR and a BDR. The election is based on the DR priority (configured with:
(config-if)#ip ospf priority). By default the priority is 1 so if the priority is not configured the DR will be the
router with the highest RID. In the output above R2 is elected the DR although R8 has the highest RID. That is
because the DR election is not preemptive that is to say that as R2s OSPF process has been started first, R2 has
elected itself as the DR and R8 cannot preempt it. No matter who is elected the DR on Ethernet link as long as
devices have full connectivity to each other. But on partial mesh topology like Frame Relay it can be a problem
if the DR does not have full reachability to all the nodes.
Side note: Changing the OSPF priority to 0 on a router prevent it from participating in the DR/BDR election
process.
Once the DR/BDR is elected, database exchange occurs. When routers exchange the LSDB, they just send a
summary of all the LSAs they know about which is known as Database Description (DD). OSPF uses the
concept of Master/slave for the database exchange which is determined in the exstart phase. The master is the
one with highest RIB and the one initiating DD exchange as we can see in the debug output (R8 is the Master).
4

After the database exchange, routers compare their current LSA with the received LSA using sequence nbr. New
LSAs start with 0x80000001 and end with 0x7FFFFFFF. Any change in LSA increase the sequence number.
Routers request missing LSA or newer with LSR packet and are being updated with LSU packets (Loading
stage). LSR use reliability with 2 options: receiver of LSU acknowledge by sending same LSU back or send
LSA acknowledge packet with list of acknowledged LSA headers. We can see that is what is happening between
R2 and R8 in the debug output as they are requesting LSAs to each other and then updating each other LSAs
database (LSDB). Finally we can see at line 30.903 that R2 and R8 are fully synchronized which means that
they have an identical LSDB.
We can see the same result in the following Wireshark capture during database exchange between R2 and R8:

R2 is advertising its OSPF database description (DD) composed of various LSAs types. We can see the
following LSAs in the Wireshark output:

LSA type 1 which are router LSA that uniquely identify each router in the same area. LSA type 1
informs of number of links and which subnet are connected to the different links. One per router.

LSA type 3 which are summary LSA. LSA type 3 are send by ABR or Area Border Router (in this
case R2 as it is connected to area 0) to other areas as LSA 1 and 2 are not propagated from one area to
another. LSA type 3 represent each subnet/mask+ ABR cost to reach each one in one area.

Of course there are other types of LSAs which we will talk about later on.
Alright! Now that all routers have been configured for OSPF based on the topology (see beginning of the post.
Also note that Stub areas have not been configured yet) lets check what the OSPF status of R1 is and which
neighbors it can see:
5

So R1 is only seeing R7 as its neighbor. It should also see R2, R3 and R4 which are the spokes of the Frame
Relay network. Note that R1 is the DR for the Ethernet segment as its OSPF process has been started before R7
s OSPF process. Lets troubleshoot this issue:

So the Frame Relay interface of R1 is configured for OSPF and it is in area 0, good! R1 can also ping R2,R3,R4
through the Frame Relay network, good!

From the debug output above, we can see that R1 is receiving OSPF hello packets from the spokes.
Lets see if spoke R2 receive OSPF hello packet from R1, the hub:

So R2 is not receiving any OSPF hello from R1. What can be the issue.? Lets have a look at the OSPF Wan
interface of R1:

We can see that the OSPF interface type is NON_BRODCAST on R1 which is the default for Non Broadcast
multi-access network (NBMA) like Frame Relay and the default on multipoint Frame Relay interface. With this
type of network type OSPF is unicasting hello packet and not multicasting them like on broadcast multi-access
segment. So we need to add each spoke neighbor IP address on R1 in order to tell the OSPF process to start
sending Unicast Hello packets out each DLCIs. Lets configure that on R1:

After the above configuration the adjacency is still not coming up. Lets do some more debug on R1:

As you may remember from the introduction paragraph, Timers must math in OSFP in order for two routers to
form adjacency. Lets check the OSPF network type on one of the spoke, R2, for example:

So the network type differs on the spoke from the one configured on R1 which gives us the issue with the OSPF
adjacency as the timers do not match between the HUB and the spokes.
One way to solve this will be to configure the same OSPF network type on all the routers in the Frame Relay
network. So in this case we just change the network OSPF type to NBMA on all spokes. We could also
configured network type point to multipoint on the routers in the Frame Relay network which is the best
practice with NBMA as the next-hop is changed to be the HUB so you dont need Frame Relay mapping for all
the spokes. Ok, lets go ahead and configure the following on all the spokes:

Side note: We make sure that the spokes will not participate in the DR/BDR election by setting the OSPF
priority to 0.
Once the OSPF network type is configured we can assume that R1 will form adjacency with R2,R3,R4:

This is the case. R2, R3 and R4 are considered DROTHER as they are not participating in the DR/BDR
election.
Perfect! Now all routers in area 0 have formed adjacency, lets check area 1 and 6:

From the output above we can conclude that all the routers in area 1 have formed adjacency and that R3 is the
DR for area 1 and 6. Also in area 1 R5 is a DROTHER while R4 is the BDR that means that R5 will form full
adjacency with R3 and R4 (The DR and BDR for area 1).
Lets quickly check the neighbors of R2:

Good! So all the areas are synchronized as the routers have formed adjacency in their respective areas.
OSPF LSA Types
Lets have a look at the OSPF database on R2 for area 0:
8

Based on the LSA type 1 which I explained before, we can see that there are 4 routers in area 0 which are R1,
R2,R3,R4. Lets look at the LSA type 1 for R1:

This LSA type 1 from R1 informs us about R1 connected interface into area 0 which are its Frame relay
interface and its loopback interface. Also the cost associated which interface is given which will be used by the
SPF algorithm to calculate the end-to-end metric. We can also see that R1 is an ABR as it has some interfaces
participating in area 0. One of the Link of R1 is connected to a transit network that is to say that there should be
a DR on this transit network which is R1. Also note that the loopback is considered a stub network by default
and will always be advertised as /32.
Lets check the LSA type 2 which is representing a transit network. In this case R1 is the DR and represent the
transit network 10.0.0.0/24:

10

LSA type 2 are sent only on transit network by the DR which informs of attached router connected to himself.
Only one DR per transit network. OSPF consider the DR as a pseudonode which it must consult first before
computing SPF. LSA type 2 are only used for intra-area calculation whereas inter-area calculation use LSA
types 3.
In this case the DR is directly attached to all spokes as R1 is the Hub of the Frame Relay network.
Lets check LSA type 3 for area 0 LSA type 3 are only sent by an ABR. An ABR is a router connected to area 0
and one or more areas. So in our case we have 4 ABRs in area 0 which are the following:

R1 connected to area 0 and 7

R2 connected to area 0, 8 and 9

R3 connected to area 0, 1 and 6

R4 connected to area 0 and 1

The LSDB is identical per area and smaller if several areas are used which implies faster SPF calculation. LSA
1 and 2 are not passed between areas instead LSA 3 are used so the LSDB shrink. LSA 1 and 2 contain detailed
topology info and therefore are SPF intensive
As there are many LSAs type 3 in the OSPF domain we will just take the example of one LSA 3. That is
because all the ABRs in area 0 generate LSA type 3 for every network they know about in other areas. Lets
take the example of LSA type 3 for 66.66.66.66 in R2s LSDB in area 0:

We can see that this LSA 3 is advertised by R3 which is an ABR connected to area 6 where the network
66.66.66.66 is located (R6 loopback IP). As R3 has a connection to both area 0 and area 6 is advertising the
networks it knows in area 6 to area 0 and vice versa. Also note that R3 is advertising the metric to reach the
loopback of R6 from its point of view (in this case it is 11).
In turns R2 will advertise a LSA type 3 to area 8 and area 9 for the network 66.66.66.66:
11

The same LSA type 3 will be advertised to area 9. Here the metric is the cost for R2 to reach 66.66.66.66. Lets
check know how the path selection process is working from the perspective of R2 in order to reach 66.66.66.66.
OSPF Path Selection Process
Lets have a look at the routing table of R2 for the entry 66.66.66.66:

So the total metric is 75 and the route has been advertised by R3 as an LSA type 3 denoted by the type inter
area. But how this metric has been calculated? Lets demonstrate it.
As we saw before the metric from R3 to 66.66.66.66 is 11 and that has been advertised in the LSA type 3 for
this network from R3. So now R2 must run SPF on the router advertising this network which is R3 (3.3.3.3 R3
s RID).
Side note: This is why OSPF is considered partially distance vector and partially link-state. R2 does not know
the detailed information about the path selection that is occurring behind R3 for 66.66.66.66. R2 trusts R3s
calculation for the prefix, which is typically a distance vector behavior, and then calculates the shortest IntraArea path to reach R3, which is a link-state behavior. The advantage of this design inherent to OSPF is that R2
does not need to run SPF on the entire OSPF topology, which immensely increases scalability.
Now lets find out how R2 routes to get to R3:
OSPFs Intra-Area SPF determines this by finding out who R2 is directly adjacent with, and what the cost
values to these neighbors are. Once this is determined, R2 asks these neighbors who they are adjacent with, and
what their costs are to their adjacent neighbors. The process continues over and over until R2 finds the shortest
path to the ABR 3.3.3.3. This Intra-Area metric is then added to the LSA 3 metric that R3 is advertising, and
results in the end-to-end metric value that is actually installed in the routing table. We can verify this by first
finding out who R2 is adjacent with in area 0 by viewing its Router LSA (LSA 1):

12

R2 sees that it is adjacent with the DR 10.0.0.1 (R1) and that the cost is 64. Therefore R2 must ask the DR who
it is adjacent with and what its cost calculation to its adjacent neighbor is:

Since the DR is directly adjacent with R3, R2 infers the total cost to 3.3.3.3 as 64. Since R3 is advertising the
metric 11 in its LSA 3 for 66.66.66.66 and the metric from R2 to R3 is 64 we can conclude that the total cost to
66.66.66.66 from R2 perspective is: 64+11= 75 which is the metric we saw before when looking at the routing
table of R2 for 66.66.66.66.
Side note: This calculation process will be the same for all inter-area routes. The SPF is always runs against
the ABR (advertising router) and not the final destination. In the same area SPF is runs against the final
destination using LSA type 1 and LSA type 2 (if transit network) to find out the shortest path tree to the
destination network. Inter-area routing can only occur through area 0 or through a non-backbone area
(capability transit).
Side note 2: We could wonder why R4 is not injecting a LSA type 3 for 66.66.66.66 in area 0 as it learns this
LSA from R3 connected to area 6. Well, that is due to OSPF loop prevention mechanism that states that: An
ABR must not reinject a summary LSA learn inside non-backbone from other ABR into same area back into
area 0.
13

Alright so now we have seen how the OSPF process is working to calculate the shortest path selection for both
intra-area routes (O) and inter-area routes (IA). But how we could change the path that a packet is taking to a
destination by changing the OSPF cost? Lets check that.
OSPF traffic engineering with cost
Lets take the case of R5 loopback IP 55.55.55.55 from a perspective of R2:

From the output above we can observe that R2 as 2 equal paths to 55.55.55.55, one through R3 and the other
one through R4. That is because R3 and R4 are both ABR and advertise the same cost (11) to R5 loopback IP
located in area 1. Then R2 has the same cost of 64 to both R3 and R4 all connected directly to the DR, R1. The
total metric is 75. So how can we change the path to 55.55.55.55 and prefer R3 as the exit point of area 0 to
reach area 1. Well lets look first at the cost of R4 to reach R5s loopback IP:

14

We know that R5 is advertising the loopback 55.55.55.55 so from a LSA 1 lookup for 5.5.5.5 we can see that R5
is directly connected to the DR for area 1 which is R3. Lets do a LSA 2 lookup now on the DR:

So R4 is directly connected to the DR 3.3.3.3 which is directly connected to R5. So lets make a LSA 1 lookup
for R4:

So R4 metric to the DR R3 is 10. So the total metric from R4 to 55.55.55.55 is 10+1=11. So if we increase the
cost of R4 connection to the DR to be higher than 10, R2 will choose the path to R3 instead of load sharing
between R3 and R4 for the destination 55.55.55.55. Ok, lets increase the metric of R4 Ethernet interface
connected to area 1 to 20 and check the result in the routing table of R2:

15

Sure enough we now have a preferred path through R3 to reach 55.55.55.55. Just for fun and for information, as
soon as we change the metric on R4, R4 sends a unicast update to its connected OSPF neighbor in area 0 (R1)
about the change. In the output bellow we can see the new metric from R4 perspective to reach 55.55.55.55 and
it is 21:

If we were capturing the next packet from R1 we will that that R1 is acknowledging the update by sending the
same packet to R4.
Side note: The packets are unicast because the network OSPF type is NBMA. If it was in area 1 the LS update
will be multicasted.
OSPF network change reaction time
Lets check how fast OSPF is able to react in regards to network changes. For this example we will shut down
the loopback of R5 and see what is happening on R2:

16

So basically, some milliseconds after we shut the loopback of R5 down R2 received an LS update from R1
saying that the path to 55.55.55.55 via R3 doesnt exist anymore. The OSPF process of R2 translates this
change by setting the metric to 55.55.55.55 to infinite (16777215) for the LSA 3 as we can see in the Wireshark
output bellow. Setting the metric to 16777215 will force the OSPF process to remove the LSA from the LSDB.

Alright, that was interesting to see exactly how OSPF behaves in this kind of situation. It is also nice to use
Wireshark to see the format of the packets and so on. In the next section we talk about LSA Type 5.
OSPF LSA Type 5 (Autonomous System External LSA)
Ok, lets review quickly what a LSA type 5 is. This type of LSAs is created by an ASBR (Autonomous
System Border router). An ASBR is a router originating a route into OSPF which is external to the OSPF
domain. For example a route from another routing protocol domain or a default route to external destinations.
LSA types 5 are the only LSA types in the OSPF database that are not associated with a particular area and they
are flooded into all nonstub areas throughout the autonomous system.
17

There are 2 types of LSA type 5: E1(external + internal metric) and E2(only external metric). E2 are the default.
Lets generate a LSA type 5 on R4 by redistributing its loopback into the OSFP domain. From the debug output
of R2 we can see the following:

So from the output above we can see that the LSA type 5 is received by R2 from R1. The advertising router is
R4. We can also see that R2 is forwarding this update to area 8 and area 9 (no shown in the debug output). If we
look at a Wireshark capture at the same moment we can see that the LSA type 5 as an external type of 2 and that
it is announced by an ASBR which is R4. The metric is 20.

If we look further down in the OSPF domain , for example R8 in area 8 we can see the following debug output
at the same instant:

18

So R8 is receiving the LSA type 5 update from R2 and run the SPF algorithm on the LSA in order to find the
shortest path to 44.44.44.44. There is an important point here. Notice the forward address field there equal to
0.0.0.0. That means that the next-hop to reach the network 44.44.44.44 should be the advertising router which is
in this case R4 (RID:4.4.4.4). But does R8 know about R4. Letsee:

R8 doesnt know about router R3 as there are not in the same area. So how can R8 forward packet to the
loopback of R4 located in area 1 when it has no knowledge on how to reach R4?
Side note: With LSA type 3 the Advertising router is always the ABR so routers in other area knows that to
reach a LSA type 3 network they should run SPF algorithm on the ABR not on the originating router. But in the
case of LSA type 5 propagation, the advertising RID stays the same and it is not proxyed by an ABR.
Lets find how R8 can calculate the path to reach R4 from R8 perspective.
When an ABR receives a LSA Type 5 from a device in its own area, and passes it into a different area, a Type 4
ASBR Summary LSA is generated. The Type 4 LSA tells devices in the new area how to forward towards the
ASBR which in turn tells devices in the new area how to forward towards the external route.
So in our case, R2 the ABR informs router in area 8 on how to reach the ASBR R4 when flooding the LSA type
5 from area 0 to area 8. The LSA Type 4 area can be inspected in the LSDB with then following command:

As we saw before, R8 doesnt know how to reach R4 and R4 is not in the same area as R8. So R8 now knows
that it has to make a ASBR LSA Type 4 lookup in order to calculate the path to the loopback of R4
(44.44.44.44). With the LSA Type 4, R8 knows that it can reach R4 through R2 the ABR which is the same
recursive lookup that R8 will use to calculate a path to a LSA Type 3. The metric of 64 is the metric that R2 has
calculated to reach the ASBR R4.
So lets see check the routing table of R8 for 44.44.44.44:

19

The forward metric is the total metric from R8 to the ASBR R4. R8 already knows from the LSA Type 4 that
the metric to reach the ASBR R4 is 64 from R2 point of view. So now R8 just need to do a SPF calculation on
R2, the ABR to find the total metric to R4 from its point of view:

So R8 adds 10 to 64 which result in a forwarding metric of 74, which is the total metric to reach R4.
Side note: E2 routes by default dont take into account path to ASBR, but technically they do by calculating the
forward metric. As the default metric for an external type 2 route is 20, the forward metric only matters if there
are multiple ASBR originating the same external route so the router will take the path with the best forward
metric (the one closest to the ASBR).
Now lets redistribute the loopback of R4 as a E1 route (External type 1 route) and see the difference in the
routing table of R8:

So now the external route is considered a Type 1 external and there is no forward metric anymore. The total
metric is the metric we saw before (74) to reach the ASBR added to the metric of the route itself which is 20. So
the total is 94.

20

Side note: when several identical routes exist for one destination OSPF dont use cost when deciding which
route to install in the routing table but instead: 1) IA, 2) Inter-area, 3) E1, 4) E2, 5) NSSA type 1(N1), 6) NSSA
type 2 (N2). So in our case above E1 will be preferred over E2 routes for same destination.
OSPF Default Routing
Default routing for non-stub areas in OSPF is accomplished through the origination of LSA Type 5 via the
default-information originate command. If no default route is present in the routing table, OSPF will not
originate a default route which is a desirable behavior in designs with multiple exit points out of the OSPF
domain. This behavior can be changed by using the key word always after default-information originate
which skips the checking of the presence of a default route in the table.
If using a route-map added to the command default-information originate the origination of a default route
doesnt depend anymore on the presence of default route in the routing table but whether if the return code is
true from the route-map. Even if the always keyword is used as long as the route-map returns a false, the
default route wont be redistributed. So the important thing here is that when using a route-map the always
keyword is ignored if used.
So in our example, if we use the following command on R6, R6 will generate a default route coded as LSA
Type 5 E2 with a metric of 1:

Right after the configuration R6 is originating the default route:

So this LSA should have been propagated through the entire domain in all areas apart from stub areas (Prevent
entrance of LSA Type 5). Lets check if R2 has received the default-route:

21

Sure enough, R2 has received the default route which is an E2 OSPF route with a metric of 1. As we saw before
regarding the recursion process with the forward address, here it is the same. As R6 is not in the same area as
R2, R2 will do a LSA Type 4 lookup on R6 the ASBR and find out that it should route traffic for the default
route towards R3 (ABR) in this case in order to reach 6.6.6.6:

We could also have used the following command on R2:

So to reach 6.6.6.6, R2 should do a LSA 1 lookup on the ABR R3.

OSPF Reliable Conditional Default Routing
If you look at the topology you will see that R6 is connected to an ISP router. So we could design a case where
as long as R6 as connectivity to the ISP, it advertises a default route in the OSPF domain. But if R6 loses
connectivity to the ISP the default route should not be advertised into the OSPF domain. To realize this scenario
we can use Enhanced Object tracking in combination with a route-map. So lets configure the following on R6:

22

Basically we create a place holder route which existence in the routing table depends on the reachability of the
ISP router (40.0.0.1) monitored by the IP SLA. Then the route-map tracks the presence of the static route in the
routing table. AS long the route-map returns true, the OSPF process will originate a default route in the OSPF
domain. So if R6 loses connection to the ISP the IP SLA will return a false code which in turn will trigger the
tracking process to remove the route from the routing table which in turn will trigger the route-map to return a
false which will trigger the OSPF process to remove the default route from its LSDB.
Ok lets verify and shut down the interface connected to the ISP and see what happen in the debug on R6:

So as soon as R6 loses the connectivity to the ISP the OSPF process originate a default route with a metric of
16777215 which basically means that all routers in the OSPF domain should remove this route from their LSDB
which will in turn remove the route from their routing table.
OSPF Stub Areas
Alright lets generate some more external networks on R5 in the range of 50.0.0.0/8 and lets look at the OSPF
database on R8 for LSA Type 5:

23

As we can see R8 is learning all these external networks from R5 and R4 via R2 the ABR. But R8 as only one
exit path out area 8 which is via R2 so recursion for both R4 and R5 points to R2. In a design such as this, stub
areas can be used to optimize the OSPF database by replacing the redundant Type-5 External and Type-4 ASBR
routing information with default information.
Stubby areas are designed to increase OSPF performance and to limit type of LSAs allowed to enter an area.
There are different types of stub areas, all stopping LSA 5 and 4 to enter. Here are the four stub types that IOS
supports:

Stub Areas -> Suppress LSA Type 5 and LSA Type 4 and replace them with LSA 3 default route

Totally Stubby Areas -> Suppress LSA 4,5,3 and replace them with a LSA 3 default route

Not So Stubby Areas (NSSA) -> Suppress LSA 4,5 and allow LSA 7

Not So Totally Subby Areas -> Suppress LSA 4,5,3 and replace them a LSA Type 3 default route.
Allow LSA 7
Stub Areas

So lets start by configuring Area 8 as a Stub area:

Side note: Both R8 and R2 must be configured with the stub keyword for area 8 as the stub flag must match for
2 routers in same area to form adjacency. Otherwise the following log will appear in the debug:

Lets check the OSPF database of R8 now for LSA Type 5 and 4:

24

So R8 is not receiving LSA Type 5 and 4 longer. Lets check the routing table:

So all the LSAs Type 5 have been replaced by a default route, announced through a LSA Type 3 by R2. That
means that R8 will forward traffic destined to external networks through R2. Moreover the LSA Type 4
announced earlier by R2 is not present anymore in the LSDB of R8 as this LSA was related to the presence of
LSAs Type 5.
Totally Stubby Areas
The next logical step in further optimizing the database is to summarize the redundant Type 3 Summary LSAs
that represent the inter-area routes.
Where a stub area optimizes the database by removing external routes and replacing them with a default route, a
totally stubby area will optimize the database further by removing the inter-area and external routes, replacing
them both with a default route. This is accomplished by telling the area border router not to inject Type-3
Summary Network LSAs from area 0, hence the no-summary argument used in conjunction with the stub
command.
So lets configure area 9 as a Totally Stubby Area. First we can check that R9 has LSA 4,5,and 3 in its
database:

25

So R9 has LSA 3,4,5 in its OSPF database. Let s configure R2 and R9 as Totally Stubby Area for area 9:

Side note: Note that only the ABR(s) connecting the stub area to area 0 need the no-summary argument on the
stub command, since they are the only devices that are allowed to originate Type 3 LSAs. While it wont
break the OSPF design to add the command to other routers inside the totally stubby area, it is technically
incorrect to configure the option this way. As long as all devices in the area agree on the stub flag in the first
place, it is the ABR(s) duty to determine if the area is totally stubby or not.
Lets check now the routing table of R9:

R9 has only a default route now and only LSA 1 and 2 are now allowed into area 9. So inter-area traffic will
always be routed towards R2.
26

Not-So-Stubby-Area (NSSA)
Since all Type 5 LSAs are suppressed from area 9, R9 will not be able to do redistribution into area 9.
The OSPF NSSA option changes this behavior by allowing redistribution to occur within the stub area while
still blocking external routes from entering the area through the ABR. This is implemented through a new type
of LSA which is Type-7 NSSA External LSA.
Routes that are directly redistributes in a NSSA area are generated as LSA Type 7. Like with LSA Type 5, two
types of LSA Type 7 exist, type 1 (N1) and type 2 (N2). N1 similar to E1, considers the metric to reach the
ASBR. N2, similar to E2, only consider the metric that the ASBR is advertising for the external route and the
value needed to reach the ASBR is known as the forward metric as we saw before.
Let s configure area 6 as a NSSA area:

So R6 is inside a NSSA area now and doesnt receive LSA Type 5 routes anymore:

In one of the previous paragraph on OSPF Conditional Default Routing, R6 was conditionally originating a
default route based on the reachability of the ISP (router ISP on the topology). As LSA Type 5 are not permitted
in the area 6 now, the default route is not advertised anymore as LSA Type 5.
Is the conditional advertised default route being advertised as LSA Type 7?

Side note: Actually some LSA Type 7 should be present in the LSDB of R6 and specifically the networks from
R5 (50.0.0.0/8 prefix range) because R5 is in an NSSA and it is also an ASBR and by default external routes
from a NSSA connected ASBR will automatically be redistributed in the NSSA area as LSA Type 7. This
behavior can be prevented by configuring: area 6 nssa no-redistribution on R5 in order to avoid
unnecessary overhead.
There are no LSA Type 5 which is the expected behavior but what about the default route? It should be
redistributed as LSA Type 7. Well previously R6 was configured as follow in order to redistribute the default
route:
27

This command injects a default route only in regular OSPF areas (backbone area and other regular areas). To
inject a default route into an NSSA area, you have to use the area number nssa default-informationoriginate router configuration command. This command will only advertise a default route if the OSPF router
has a default route in its routing table or it if it is an ABR (having at least one OSPF interface in the backbone
area).
R6 is not an ABR so a default route must be present in the routing table in order to be propagated through
OSPF. As we are using conditional advertisement based on Enhanced object tracking we simply replace the
place holder route used in the previous example (see section OSPF Reliable Conditional Default Routing) by
a default route tracked by the same tracking number:

The presence of the default route will still be based on the reachability of the ISP monitored by the IP SLA
configured earlier.

As soon as we make the change R6 generate a LSA Type 7 for the default route and the metric type is N2 by
default.
Lets see if the route is present in the LSDB of R6:

28

Alright! That also explain why R3 and R5 did not generate any LSA Type 3 default route in area 6 as it would
have been the case if the area was a stub, totally stubby or Not-So-Totally-Stubby area (we will see an example
later on).
Because if R3 or R5 will have originated a LSA Type 3 default route into area 6 the LSA Type 3 default route
will always been preferred over the LSA Type 7 default route due to OSPF route selection. O IA are preferred
over O N2 routes because OSPF dont use cost for equal routes selection but instead OSPF route type with O
routes being the preferred routes over any types (E1,E2,N1, etc).
Ok lets check how R1 sees this default route:

R1 sees the route as LSA Type 5 E2 although the route was originated by R6 as LSA Type 7 N2. Well, that is
because when a LSA Type 7 is received by the ABR and moved into area 0, the information contained in the
LSA Type 7 is translated to a normal LSA Type 5. If multiple ABRs are connected to the NSSA area only one is
performing the translation (based on the highest RID). In this fashion OSPF devices outside of the NSSA do not
know that the NSSA exists, which is analogous to how confederation works in BGP.
That means that R3 is the translating device as it is the only ABR in the NSSA area.
If you look at the LSA in depth on R1 for the default route we get the following output:

As we may have noticed just before the Forward address is not 0.0.0.0 as with stub and totally stubby area.
Recall that a forward address of 0.0.0.0 means that the traffic to the destination network should be forwarded to
the advertising router IP address and a router outside of the area will use a LSA Type 4 pointing to the ABR in
order to route to the destination.
But with NSSA area the forward address is equal to the originating router IP. This then means whatever our
forwarding path is to reach router 6, thats the path that the traffic towards the external route is going to forward.
There could be potential cases where the ABR that is doing the advertisement of the route is not actually the one
29

that is receiving the traffic for the destination. So, with the Type-7 to Type- 5 translation, were decoupling the
control plane advertisement of the actual prefix from the data plane forwarding to the actual destination. So, in
other words, it means that we could be learning the route from router 3, but then, were actually sending the
traffic towards router 5 (if it had a connection into area 0 like a virtual link for example).
No LSA Types 4 are necessary anymore as forward address lookup replaces the need for the ASBR lookup.
Since the forward address is preserved only one router needs to do the translation while the calculation of the
final forwarding path stays independent
Side Note: The forward address is first chosen on the highest loopback that is on the ASBR (R6 in this case)
and that is also being advertised into the area. If there is no loopback, the highest interface that is running
OSPF and also advertised into the NSSA will be chosen.
So in this case, when R1 route traffic for the default route it will route towards the IP of R6 loopback
(forwarding address) which recurse to R3:

Lets now see how the forward metric for the default route is then calculated from a perspective of R1:

The metric is the one announced by R6 for the default route which is 1 by default. Recall that this route is
originally a N2 route translated into E2 route by R3. The forward metric is the metric to the ASBR in this case
R6 and it is only used to make path selection if there were several equals E2 default routes. R1 first calculate its
metric to R3 which is 64 ( LSA 1 lookup on R1):

Then to find out what is metric from R3 to R6, R1 does a LSA 3 lookup on 66.66.66.66:

So the total metric from R1 to R6 is: 64+11=75 which is the forward metric we saw in the output above.
Not-So-Totally-Stubby-Area
The Last Stub OSPF area type is the Not-So-Totally-Stubby-Area which uses also the stub flag NSSA.
Side note: There are 3 types of area: Normal area, a stub area (flag stub) and a NSSA area (flag NSSA).
30

Like in Totally stub area LSA type 3,4,5 are suppressed which means that the ABR of this area will originate a
LSA Type 3 default route. That also means that it is not possible to originate a default route is this type of area
as we saw before with NSSA, because the LSA Type 3 I OA route will always be preferred over N1 or N2
default route.
With that being said lets configure area 7 as Not-So-Totally-Stubby-Area:

Lets check the routing table of R7 now:

Only one OSPF route is now present in the routing table an LSA Type 3, 4 and 5 have been suppressed.
However is it still possible for R7 to do redistribution in this area unlike with stub and totally stubby areas. Let
s redistribute the loopback of R7 into area 7 as a N1 route.
Lets check on R1 now if the N1 route is present:

N1 route behaves the same as E1 route in terms of metric calculation. Lets check how R5 sees this route:

So the total metric is 104 which is calculated as follows:

LSA 1 lookup on R3:

LSA 5 lookup on final destination to find the forward address IP:

LSA 3 lookup on the forward address:

31

LSA 5 lookup on the final destination to find the original metric of the route redistributed:

So the total metric is: 10+74+20=104.

Virtual Links
If R6 loose its connection to R3 it will also loose connectivity to the rest of theOSPF domain as R3 is the only
ABR for area 6 which means that inter-area LSA Type 3 routes can only be advertised by R3. Ok, Lets try to
shut down the link on R3 connecting to area 6.
As soon as R6 detects that R3 is down (after dead timer expires, 40 sec) SPF will run and check all the LSA
Type 3 routes reachability:

Since the ABR, R3 is down all the LSA Type 3 routes are removed from the routing table of R6.
If we check the routing table of R6, there are no OSPF routes anymore:

The ABR, R3 is listed as not reachable in the debug because the LSA 1 for R3 has been flagged as unreachable
in the LSDB:

32

So in order to add some redundancy to this design we could make R5 to act also as an ABR. As R5 has no
directly connected link to area 0 we could add a new link to area 0 from R5, create a Tunnel or configure an
OSPF Virtual-Link. In this case we will create a Virtual-Link.
An OSPF Virtual-link allows the creation of indirect area 0 adjacency. This adjacency can be used to repair
breaks in the OSPF domain or to solve traffic engineering requirements. In this particular case R5 can virtual
link to R3 or R4 who are in area 1 and are both ABR. In this example we will create a VL (Virtual-Link)
between R5 and R3:

Side note: The first important point to note about the virtual-link is that the neighbor value specified in the
virtual-link syntax is the router-id of the neighbor in the transit area. This means that if for some reason the
router-id changes, i.e. a new higher Loopback interface is added, or the router-id command is changed, the
virtual-link will fail. The VL neighbors dont have to be directly connected as long as they can recurse to each
other LSA 1
So Now R5 has a connection to area 0 via the VL:

Which means that R5 is an ABR and that R6 will receive (I OA) route (LSA Type 3) via R5 as the link to R3 is
shut down:

Lets look at the VL on R3:

The cost value is based on the R5s cost to reach R3 which can be calculated via LSA 1 recursion.
From the perspective of R1 who is in area 0 we can see that R5 has generated a LSA Type 1 as it is considered
to be in area 0 now thanks to the VL:

33

Ok, lets turn back on R3 interface connecting to area 6 and see what is the preferred path to reach 88.88.88.88
from a R6 perspective:

Ok it is via R3 and not R5. Lets find out why?

R6 does a LSA Type 3 lookup on 88.88.88.88:

So R3 advertises a metric of 75 to 88.88.88.88 while R5 advertises a metric of 85 and this due to the fact that
R5 to R3 VL metric is 10 so R5 add 10 the metric advertised by R2 for 88.88.88.88+the metric to reach R2:

So R6 is choosing the path via R3.

One way we could change the path to go via R5 instead is to configure R4 serial connection with a lower metric
than R1 serial connection. The default OSPF metric on these serial connections is 64. Ok, lets configure R4
metric on interface s0/0.1 to 1 instead of 64 and check what the status of the LSDB is for the LSA Type 3
summary 88.88.88.88:
34

So now R6 is installing both paths for 88.88.88.88 in its routing table as the Routing Bit set on this LSA is
set. That is because now R3 and R5 are reporting the same metric to 88.88.88.88 and this because they both
route for 88.88.88.88 via R4 instead via R3 which was the shorter path before. Lets check:

OSPF loop prevention rule says that: Inter-area routing can only occur through area 0.
Per RFC 2328, non-backbone area (transit area) can be used for inter-area routing if a better path can be found
through them. In Cisco IOS implementation, this feature is controlled by the capability transit command
configured under the routing process and this feature is on by default which means that in our case inter-area
routing will occur through area 1 as the metric is better via R4 than via R3.
Capability transit will only take effect when there a virtual link in an area. If you disable capability transit on R5
and R3 the path to reach 88.88.88.88 will be through area 0 only and not area 1.
In order to make the path to 88.88.88.88 goes via R5 instead of R3 we can increase the metric on R3 LAN
interface in area 1.
35

LSAs Type 3 Filtering

We have seen so far that it is possible to filter LSAs by configuring special OSPF areas known as stub, Totally
Stubby,Not-So-Stubby and Not-So-Totally-Stubby. But it is also possible to filter LSAs Type 3 on ABR routers.
So for this example lets consider that we want to filter some LSA3 Type 3 from entering Area 6 to achieve
some traffic engineering. Right now R6 prefers to route out area 6 via R5. So by filtering some routes from
entering area 6 on R5, R6 will prefer to route through R3 for these specific routes. First lets check the RIB of
R6:

Alright! So lets say that we wanted to route through R3 for the prefix 88.88.88.88/32 which is the loopback of
R8. So lets configure the following on R5:

Side note: The in keyword means: prefix going to this area where out would have meant, prefix going out
of this area.
Lets verify on R6 if the preferred path for 88.88.88.88/32 is via R3 now instead of R5:

Side note: Note that the from in the output above is the originator ID of the LSA which is in this case R3 as
we have filtered the LSA Type 3 advertised by R5:
36

OSPF filtering with Route-Maps

As we have seen until know, with OSPF all the routers in the same area must have the same OSPF database
which is why you can only do database filtering on the ABRs. However you can filter prefixes that are elected
by OSPF to be injected in the global RIB per individual router. So lets say that we want to prevent the prefix
22.22.22.22/32 from entering the global RIB on R6, but only the one advertised by R5 in order to make sure
that we can route through R3 only for this prefix. Before we go ahead we have to make sure that the OSPF SPF
algorithm of R6 select both path in the OSPF routing database. We can check that by looking at the routing bit:

So only the path through R5 is elected as the metric advertised by R5 is better than the one advertised by R3. So
how can we make the advertised metric equal? Both R5 and R3 are connected to area 0. By looking at the
topology we know that 22.22.22.22/32 is the loopback of R2 which is in area 0. So the metric reported by R3
and R5 to R6 is their own metric to reach R2 + the metric of the loopback interface of R2. So lets look at R3 to
find out how it calculates its metric to R2:

37

So R3 knows that is connected to the DR and it has a cost of 64. Now R3 do a LSA Type lookup to see who the
DR is connected to:

The DR is directly connected to R2. So the total cost that R3 will advertise to R6 is 64 +1 (loopback OSPF cost
of R2). But if you remember from the sh ip ospf 1 database summary 22.22.22.22 above on R6, the metric
advertised by R3 is 21 and not 65. The reason of that is that R3 is routing through area 1 (R4) to reach
22.22.22.22 because area 1 is a transit area (due to the presence of the VL) and as we saw before, a transit area
can be used for inter-area routing if a shorter path is found through this area. This behavior is enabled by default
and can be turned off with the no capability transit command under the routing process. Lets leave it on for
this example. So actually R3 and R5 OSPF SPF algorithm is selecting the LSA Type 3 advertised by R4 located
in area 1 and that is due the capability feature:

38

R3 and R5 will only run partial SPF on this LSA as it is a Type 3. . Lets compare the Ethernet interface OSPF
cost on R5 and on R3:

Ok, so to get an advertised equal cost for LSA Type 3 22.22.22.22/32 from R3/R5 to R6, we just change the cost
on R3 to be 1 instead of 10. Lets check the OSPF database on R6 again:

Perfect! So now we can be sure that R6 is load sharing between R5 and R3 for the destination prefix
22.22.22.22 /32:

And it does! So now we can apply route-map filtering to achieve our result by configuring the following on R6:

39

Alright, lets check know on R6:

Perfect! The route has been filtered from the RIB but not from the OSPF database:

Side note: In the route-map when you match the route-source, you have to match the originator-ID of the LSA
which can be found in the OSPF database or in the sh ip route output looking at the from filed.

40