Welcome back to section 4 of the OSPF Configuration overview series of articles. We will continue working on the following network and pick up from where we left off. Note that I augmented the diagram by adding a couple of networks that R6 will be advertising to R1.


The first thing that we will do is configure the link between R1 and R6 which will be running EIGRP. On R1 and R6 we will configure the IP addressing information on those two interfaces like usual. See below for R1s configuration

R1(config)#interface Serial1/0

R1(config-if)#ip address

R1(config-if)# clock rate 128000

We will now configure EIGRP following some of the guidelines from my previous article. See below for the commands used on R6.

R6(config)#router eigrp 16

R6(config-router)#passive-interface Loopback0

R6(config-router)#passive-interface Loopback1



R6(config-router)#no auto-summary

R6(config-router)#eigrp router-id

Let’s take a look at R1’s routing table to see what it currently has for routes:


Our two EIGRP routes advertised by R6 are being learned and they are marked by the letter D. Let’s suppose that R6 is our ISP and that it is our gateway of last resort. This means that if R1 gets a packet to a destination that is not in its routing table then we will forward it to R6. We want to configure R1 to have R6 listed as the gateway of last resort and then advertised this information to the other routers in our OSPF network so that they also know that R6 is the last option available should everything else fail. We will configure a default route on R1 that points to R6 via the following command

R1(config)#ip route

The specifies all networks and should our router doing a lookup on its routing table not find a match for a destination network then it will fall back to this address.

If we take a look at the routing table for R1 we see that this route is listed as static and candidate default. Note that it has also been set as the gateway of last resort at the top.


The other routers in our OSPF network do not know about this default route and if we look at R5’s routing table we won’t be able to see it.


In order to advertise this route throughout our OSPF network we will go back into R1 and under the OSPF process use the following command.

R1(config-router)#default-information originate metric 25 metric-type 1

The command above will distribute default routes to our OSPF neighbors. When we distribute default routes into the OSPF routing process we can specify the metric and the metric-type. We have already talked about the OSPF metric in a previous article and how it is calculated. The metric type on the other hand is a new concept that requires some explanation. OSPF defines two values for metric type and it can either be E1 or E2. E1 and E2 routes will both have an initial(external) cost that we define via the metric parameter in the above command. The difference is that E1 routes will have the internal cost added to the initial value that we define. As the E1 route gets advertised from one router to the next that cost of the links will get added to the initial cost. E2 routes on the other hand will always have the static cost that we initially define as it gets advertised from one router to the next.

Note that if we just type in “default-information originate” without specifying a metric or metric-type then the default metric is 1 and the metric-type is 2. Let’s take a look at R4’s routing table to see if it is picking up the external route.


Notice the OSPF external type 1 route at the bottom with a cost 1025. Since we specify an initial value of 25 for this route then this means that the link between R1 and R4 has a cost of 1000 since this is what would have been added to arrive at that cost. Don’t forget to notice that it has also being marked as a candidate default with R1 being the gateway of last resort. Let’s take a look at R5 to see how it looks.


We see the same results as above with the default gateway being R4 instead and a different value for the cost of the route. E1 and E2 external route types make more sense when we are talking in the context of having multiple routers with each having a connection to an ISP. In this case we can advertise the external routes as E1 into our enterprise and each router will then base on the lowest cost pick one of the two paths as their gateway of last resort which leads to an ISP. We can also configure it in such a way that only one ISP is active at all times if for example we have a faster link with them. In this case we can advertise the preferred ISP route as a type E2 with a lower cost than the other E2 route. This means that we will use the better link to get outside and if this ISP goes down then the other E2 route with a higher E2 cost will get utilize.

When an ASBR injects routes into OSPF it will do so using a type 5 LSA. If we take a Wireshark packet capture of R1’s Fastethernet0/0 interface we can see it advertise it.


The packet capture above tells us that this is an AS-External-LSA advertised by an ASBR. The link state ID is the external network number. In our case this network number is because we created a static route that we are advertising into our environment. The advertising router is self-explanatory and list the ASBR or R1 in our example. Notice that the Netmask matches our /0 mask that we are using in the static route. It also tells us whether it is an E1 or E2 external type route and the initial metric that we are using when we advertise it into our network.

When an ABR(R3 or R4) in our example gets the type 5 LSA it will advertise it into their respective area(32 and 45) via a type 4 LSA. ABRs will generate type 4 LSA instead of the type 5 LSA into their respective areas because routers within those areas have no clue about the ASBR router id that is advertised in the type 5 LSA. If they were to advertise the type 5 LSA into their respective area(32 and 45) then the routers within those areas will not know about R1’s router ID and won’t know how to reach it. In Wireshark we can see this information:


This LSA is officially known as the Summary-LSA and has a link state ID that matches the Router ID of R1. The advertising router in this case matches R2 since it is the ABR that is advertising it into area 32. With this information R3 now knows that it should use R2 for the OSPF external route.


Now is a good time to review some OSPF informational commands. One of the most important commands that will give you information about the different types of LSA in an OSPF router database is the “show ip ospf database” command.


This command will lists all LSAs for all connected areas for the router where the command was executed. LSA Types 1-5 are the most common and will be the majority of LSAs that you will encounter.  Below is a table that I created that matches the LSA type to how they are named here.

LSA Type LSA Name
1 Router Link State
2 Net Link State
3 Summary Net Link State
4 Summary ASB Link State
5 AS External Link State

Each entry in this list has an advertising router and the link ID that the router is advertising. If you want to view a summary of your database without much detail the “show ip ospf database-summary” command will give you some quick numbers:


The command above will give you a total of the different LSAs for all the connected areas of this router. The next command will tells us detailed information about the OSPF routing process in a router.


There is a lot of information that this command has and some of it is very useful. From the top we have the Router ID and OSPF process #. We have the time elapsed since the OSPF routing process was started. The number of areas that this router has interfaces in and the type of those areas. We will cover area types next so we won’t go into detail here. We then have a list of areas and each area has some detail information related to it. The information that we see for an area is the number of interfaces that we have there. Whether we have configured authentication or not. The last time that the shortest path algorithm was executed and number of times it has executed. We also have area ranges if we are doing summarization and the number of LSAs within the area that we know about.

The last OSPF topic that we will cover is area types. There are four area types that we will look into:


Totally Stubby

Not-So-Stubby Area

Totally Not-So-Stubby Area

We will start with the stub area first and work our way from there. The purpose of a stub area is to help minimize the size of a routing table for routers that are not located in the backbone area. The concept of areas in OSPF allows us to localize updates so that changes in other areas don’t affect a neighboring area. Looking at R3’s routing table


We see inter area routes and external routes listed here. Note that I redistributed the EIGRP learned routes into OSPF for this example. Redistribution is an advanced topic that I won’t cover in this article but if you want to achieve the same results as me then in R1 under the OSPF routing process you must type in the following:

R1(config-router)#redistribute eigrp 16 metric 100 metric-type 2 subnets

Where 16 is my EIGRP Autonomous System number.

R3 next hop address for these external and inter area routes is its ABR which is R2 and if we had other routers in area 32 then they would also point to the ABR since it is the only way for them to leave the area. Since R3 has all its interfaces in area 32, then all it should care about is other routes within its area. There is no need for R3 or any other routers that have all their interfaces in area 32 to care about other area networks and their status. The only router that should have this information is R2 since R2 is the ABR and it must know about the status of other networks in other areas and how to get there.

When we make an area into a Stub what we will achieve is the filtering of external routes from being advertised into the area. When we configure an area as a stub, all routers in the area must be configured to be stubs. For area 32 we will configure both R3 and R2 as stubs via the following command.

R2(config-router)#area 32 stub

The command is applied under the OSPF routing process which is 25 in our example.


Notice that when we configured R2 as a stub that the neighbor relationship came down since there is a mismatch with R3. This is why all routers within an area must have matching stub parameters or else the adjacency will not come up. Let’s look at R3’s routing table after we made the change:


Notice how all of our E1 and E2 external routes have been replaced by one default inter area route. If we do a trace route to one of those external networks we can see that it is still reachable.


In a stub area we can see that the ABR will not flood external routes. Instead all of these routes are advertised as a type 3 LSA with a default route of “”. This is what it looks like on Wireshark.


Notice that the default metric is 1 by default as it gets advertised and this matches the cost of 1001 that we see on R3 for this route since the link itself has a cost of 1000. We can modify the default metric of 1 using the following OSPF process command:

R2(config-router)#area 32 default-cost 10

And verify that it works by looking at the route on R3:


Note that this command applies to the ABR. The next area type that we will look at is the totally stubby area. The totally stubby area will filter external and inter area routes from being advertised to routers within an area. Let’s configure it on R2 so that we can see the changes that it causes on the routing table for R3.

R2(config-router)#area 32 stub no-summary

Checking over on R3 we see that the routing table has gotten smaller:


All the intra area and external routes are now gone. They have all been replace by a single route that leads to R2. R2 still has entry for these routes since it has to know where to forward packets that are destined for those networks. R2 replaces the external and inter area routes by using a single type 3 LSA with a default route of “” that it advertises into area 32.


Note that the totally stubby feature is Cisco proprietary. Even though this feature is proprietary, if you have a router from another vendor and a Cisco router acting as an ABR then you can still take advantage of the totally stubby feature. Notice that in my example above when we configured the totally stubby area that we did not have to touch R3. R3 did not have to be configured with the totally stubby flag and our neighbor relationship never went down. This is due to R3 already being configured as a stub which won’t cause problems if the ABR is configured for a totally stubby area. What this means for us is that we can use a Cisco router as an ABR and configure it for a totally stubby area. We can then create neighbor relationships with non Cisco routers and configure those as a stub for the area to get the benefits of filtering inter area and external routes.

I will end this article here as it is getting quite long and will cover the remaining two area types in a separate section. I will also cover some miscellaneous commands and then wrap up the entire OSPF routing article series. Thank you for reading this article.

Leave a Reply