OSPF uses Link State Advertisement packets (LSA’s) to ‘inform’ local link connected neighbouring devices of OSPF messages. The messages include information like who is the DR (Designated router), routing information and area type.


There are six main types you will see in the OSPF database which are essential for the routing and switching lab:


This LSA type is called the ‘Router LSA’ and basically is the IP address (OSPF router-id) or the OSPF speaker. It is local link only, is generated by all OSPF devices and could be any type of OSPF speaker like a Windows box, Zebra, Vyatta, Cisco or Juniper.


This LSA type is called the ‘Network LSA’ and are only advertised by the DR or Designated router for that segment (local link).


This LSA type is also called the ‘Summary LSA’ and is generated by ABR’s or Area Border Routers. These routers sit in between two or more areas e.g. Imagine a router with two interfaces fa0/0 and fa0/1. The administrator may have placed network interface fa0/0 into OSPF area 0 and fa0/1 into area 1. This router is now an ABR. The ABR can choose (it is not the default) to summarise routes which may have been learnt from routers in area 1 back into area 0.

These ‘summary’ routes are given the LSA designation of Type 3. This type of summary is for internal routes or in other words routes for networks in the OSPF database which have originated using the network keyword not redistributed.


This type of LSA is the ‘ASBR Summary LSA’. When we have an OSPF aware router also connected to another autonomous system running on another routing process (e.g. EIGRP) and we redistribute routes from the EIGRP process into OSPF this router becomes an ASBR. The Type 4 LSA is special and is injected into a normal area from an ABR (this is NOT a typo!) as a reference or reference for the ASBR. The ABR generates the Type 4 to provide area’s beyond the ‘next-hop’ reachability information for the external route.


This type of LSA is the ‘External Route LSA’. This type of LSA is generated by redistributing routes into OSPF. The redistribution can be from another routing protocol, a static route or a connected route and the route within the OSPF database gets a type 5. There are two flavours of Type 5 however. The E1 route can perform like a normal route within OSPF whereby it can gain metric as it goes around the network. By default however redistributes routes are given the type E2. The E2 external route is given the default metric of 20 and that metric never changes no matter how many hops it takes around a network.


This type of LSA is the ’NSSA LSA’. This type of LSA is generated by the ABR for a Not-so-stubby-area. The Type 5 route is not permitted inside an NSSA so when inside an NSSA the ASBR converts the Type 5 (which would normally be generated for an external route in a normal area) into a Type 7.


OSPF has a number of area ‘types’. Each of the LSA’s we have seen so far are only allowed to exist in certain areas so lets have a look at who can go where.

Standard Area

This is the default OSPF area type. For a single OSPF area network where you have one area for your entire site you should use area number 0. This is a type of ‘standard area’ designated as the ‘backbone area’ e.g. network x.x.x.x y.y.y.y area 0’ will put network interfaces in network ‘x.x.x.x’ with netmask ‘y.y.y.y’ into area 0.

Area 0 or the 'Backbone Area', like all OSPF areas uses a 32bit field. Normally the area ID is represented as a decimal number like 0 or 100 or 1020. It should be remembered however that the area ID is actually a 32 bit number. Other vendors, unlike Cisco, can represent the area ID in a standard IP address format like which is the same as just 0. It doesn't matter how which you use but be aware that the software will convert an IP address formatted are back into a 32bit decimal number between 0 and 4.2 billion. For example is not area 12311231.

LSA Allowed 1, 2, 3, 4, 5

Stub Area

This type of area has usually only one way in and out which makes it the ‘stub’ of the network. Inside a stub because you only have one exit you can ask why you would need to know about all the routes the rest of the network uses because really, you just need to know how to get out and thats usually done using just a default route. The stub ABR converts type 4 and 5 LSA’s into a default route summary and injects that into the Stub. Type 3 summaries of routes are allowed into and out of a stub area.

LSA Allowed 1, 2, 3 + Default

Not-So-Stubby Area (NSSA)

The NSSA is a stub network which also has connectivity to another autonomous system via another routing protocol e.g. a router with an OSPF and EIGRP process. Like the Stub, external routes are not allowed into the NSSA. External routes learnt by the ASBR (autonomous System Border Router) within the NSSA are converted from Type-7 to Type-5 at the ABR to move out of the NSSA. Unlike the Stub area however the NSSA will NOT inject a default route by default. To send in the default route you need to add the ‘default-information originate’ command at the end of the area statement.

LSA Allowed 1, 2, 3, 7

Totally NSSA

This are type was a Cisco only invention which has now been picked up by other vendors. the Totally NSSA area is configured exactly like the normal NSSA except we add the ‘no-summary’ keyword to the area statement. This essentially disallows the Type-3 LSA from entering the area and simply sends in a default route.

LSA Allowed 1, 2, 7, Default

View Comments
  • Using the OSPF default-information originate command in its raw form allows us to send a route into the OSPF database for our neighbors to put into their
  • active routing tables. One problem with default routes however is they can soon become traffic black holes.

Imagine a router connected to the internet (R1). To ‘help out’ all the other internal routers it advertises a default route in saying “Hey you guys, I know how to get to the internet so don’t worry about all the routes I know about, here is one route to rule them all, send all your traffic to me” The command that router might use would look like this:

Screen shot 2011-06-01 at 00.13.32

The statement ‘default-information originate’ is truncated with the ‘always’ keyword to signify that OSPF should ‘always’ advertise the default route no matter whether the router has an active default route in it;s routing table.

Lets have a look at the active routing table for the neighbor connected to R1 for the new default route advertisement:

Screen shot 2011-06-01 at 00.15.20

We see the default route has an OSPF type of E2 as it is a ‘redistributed’ route brought into OSPF from an external process.

Screen shot 2011-06-01 at 00.15.53

So thats great, but what if we wanted the default route to be conditionally advertised based on the advertising router already having a default route in it’s active routing table? Well thats easy enough we can remove the ‘always’ keyword. Lets go back to R1 and take that out:

Screen shot 2011-06-01 at 00.18.16

Now lets put the originate statement back in - notice no ‘always’

Screen shot 2011-06-01 at 00.18.28

Now on the neighbor we have no route to

Screen shot 2011-06-01 at 00.19.20

As we explained before, this is because R1 (the originator) didn’t have a default route in it’s routing table...as shown here:

Screen shot 2011-06-01 at 00.20.16

Right. so without the ‘always’ keyword we need a default route to be present therefore making the presence of the default route a condition of the further advertisement of that route. Lets pop in a static route on R1 to meet this condition and hopefully then advertise the route to R2:

First R1, the first command adds a static route to via interface null0 (effectively blackholing data destined for any route not known by R1. the second statement is simple showing the routing table entry.

Screen shot 2011-06-01 at 00.21.54

Now R2, we see the route is now in the table due to R1 meeting the pre-condition of having a default route in it’s active routing table.

So thats great of course. But what if our internet router has a full internet routing table BUT crucially has no default route? Well we could add a static route as we’ve seen but if those internet routes go down (neighbor failure etc) then the static default will never fail and traffic will keep routing toward R1. Wouldn’t it be better if we matched for a BGP route int he table and based on the presence or ‘non-presence’ of that route stop advertising the default route.

To do this we need a route-map. A route map can be configured in this case to match either an access-list or a prefix list for the route in the table. Lets advertise based on access list entry first of all. We’re going to look for an active route for network If it exists then we advertise the route, if not don’t advertise it.

First lets make sure the route is in our routing table on R1:

Screen shot 2011-06-01 at 00.26.44

Great now lets setup the default-originate statement and route map to match the existence of this route.

Screen shot 2011-06-01 at 00.27.51

We need to create the route-map called BGPEXIST now to match the route entry.

Screen shot 2011-06-01 at 00.29.14

Now we need to create the access-list ‘1’ as we have described it. Notice we use a wildcard mask to match exactly the first three octets so as to catch the /24 mask in the routing entry.

Screen shot 2011-06-01 at 00.29.56

Now lets check R2 to make sure we are getting the route:

Screen shot 2011-06-01 at 00.31.11

All good. Now lets prove out the conditional configuration works by taking out the network from the R1 routing table - we’re going to do this by denying the route on the internet peer. Lets check that route is no longer in the R1 active routing table:

Screen shot 2011-06-01 at 00.32.28

OK so without the route we should no longer be advertising the default to R2 - lets check R2’s routing table:

Screen shot 2011-06-01 at 00.33.01

Perfect - conditional advertising works.

To cover the full story we’ll do the same thing using a prefix list now. We’ll chose a different network this time, will be fine. Lets make sure this network is in the R1 routing table:

Screen shot 2011-06-01 at 00.37.12

So we only need to change the route-map since the default-information command still stands. First we access the route-map sub-command then we take out the access-list and add in the new prefix list line. NOTE that you cannot have both access-list and prefix-list matches at the same time.

Screen shot 2011-06-01 at 00.34.30

So now we need to setup the prefix list ‘1’ (the sequence number is personal preference and can be ignored)

Screen shot 2011-06-01 at 00.35.49

Now lets have a look at R2’s routing table to make sure that now we are matching a prefix list looking for the active route we are now advertising the default route again...

Screen shot 2011-06-01 at 00.37.59


This topic is covered in more detail on our technical video at youtube

Thanks for reading.
View Comments
© 2011 defaultrouteuk.com

Cisco, IOS, CCNA, CCNP, CCIE are trademarks of Cisco Systems Inc.
JunOS, JNCIA, JNCIP, JNCIE are registered trademark of Juniper Networks Inc.