The point of this post is to show some examples of what I’ve been talking about in the last two posts. Namely, I’d like to show an example of each kind of area and each kind of router ‘role’. My hope is that we’ll be able to see each kind of LSA in action along the way.
First off, let’s reconfigure the lab to look like this…
Here we have a total of 3 OSPF areas as well as a link to an external AS through OSPF area 1. Let’s take a look at the OSPF database on router2 to get an idea of where we are at…
Let’s examine this router and see if it’s following the LSA rules we discussed in the last post.
For router LSAs (LSA type 1) we see that we are only picking up the routers within our given area. That includes router1 (1.1.1.1), router2 (2.2.2.2), and router4 (4.4.4.4). However, look at the LSA for router 2.2.2.2 (the local router). Notice how it says it has 4 links? What’s that all about? We clearly only have 2 physical interfaces. The answer lies in how OSPF interprets point to point links. In this lab configuration, I manually configured each /30 link to be a point to point OSPF network type. This is done by configuring the interfaces as follows…
If you don’t do this, OSPF will treat each /30 link as a broadcast network since it really actually is Ethernet (Broadcast). OSPF treats each point to point link as two ‘links’. As the RFC states…
If the neighboring router is fully adjacent, add a Type 1 link (point-to-point). The Link ID should be set to the Router ID of the neighboring router. For numbered point-to-point networks, the Link Data should specify the IP interface address. For unnumbered point-to-point networks, the Link Data field should specify the interface’s MIB-II [Ref8] Index value. The cost should be set to the output cost of the point-to-point interface.
In addition, as long as the state of the interface is “Point-to-Point” (and regardless of the neighboring router state), a Type 3 link (stub network) should be added.
What that boils down to is that OSPF treats each point to point link as two ‘links’ in regards to the router LSAs. If we take a look at the router LSAs that router2 generates we can see that it’s generating two router LSAs for each physical link, one for the router and one for the actual subnet…
Hence, we end up with 4 links. But wait a second…
Why is router1 and router4 reporting only 2 links? They have the same physical configuration as router2. Routers 1 and 4 show a link count of two because as far as area 2 is concerned, they really only have one physical (point to point) interface in area 2. The other physical interface lives in the backbone area.
The next type of LSA that we have in the database is a network summary LSA (LSA type 3). The rule for network summary LSAs is that they area generated by ABRs to tell routers within a given area about prefixes that can be reached by going through a particular ABR. In this case, since we are dual homed to the backbone area (area 0) we see that we are receiving these LSAs from both router1(1.1.1.1) as well as router4 (4.4.4.4)….
It should be apparent by this point, but the output of the ‘show ip ospf database’ command breaks down the LSAs you see by type…
The green box shows the router LSAs and the orange box shows the network summary LSAs. Are you wondering why we don’t see any network LSAs (type 2 LSAs)? After all, there are two networks that are totally within area 2 (10.0.0.20 and 10.0.0.24). Why wouldn’t we have LSA’s generated for these links?
The answer is rather simple. Router’s do not generate network (Type 2) LSAs for point to point links. Only NBMA and broadcast type OSPF networks will generate the network LSAs and they will be originated from the designated router of that segment. Not only is this handy to know, but it’s a good tip for reducing the size of the OSPF topology table. I we briefly reconfigure all of the intra-area 2 links as broadcast segments we can see the network LSAs…
Before we move on to look at the other routers OSPF topology tables, let’s look at what ends up in router2’s FIB…
As you can see, we have paths to all 6 segments which are external to area2. The segments inside of area 2 are showing up as directly connected routes. Note the metric for each route and how it essentially equates to hop count. Keep in mind that router5’s interface facing router6 still has the ‘ip ospf cost 70’ command on it which is why we see the cost increase for route’s beyond router5.
Let’s now look at router 1, an ABR that borders area 0 and area 2…
Note that on router1, the OSPF database is split into LSAs for each specific area. You can see that for area 0, we have router LSAs for the all 5 router’s that have interfaces bordering or in the backbone area. Again, we don’t have any network LSAs since the links are all configured as point to point. We do have 6 network summary LSAs though, one for each link existing outside of the backbone area (in the case of 10.0.0.24/30 and 10.0.0.20/30 we have two since we have two paths through ABRs router1 and router4).
Let’s take a quick look at switch1’s OSPF database before we examine redistribution…
There shouldn’t be anything new or alarming in this output, but I did want to put it up now so that we can compare the output after we look at redistribution.
Before we look at actual route redistribution, let’s talk about how to distribute a route that isn’t one of these /30s into the OSPF topology. Let’s say that we want to start sourcing two summary routes from the backbone area. Specifically, we want to source a 0’s route as well as a 192.168.0.0 /16 route from router3.
Let’s start with this configuration on router3 and see what we get…
This seems to be pretty straight forward. We are adding the routes on the local router pointing them at null0. Next, we tell OSPF to redistribute the static routes into OSPF. The only ‘odd’ thing here is the addition of the word ‘subnets’ to the end of the redistribute command. If you don’t include that key word, OSPF will only redistribute classful networks. Let’s see what we get on router2…
It looks like we got the 192.168.0.0/16 network, but we didn’t get the 0’s route. Note that the 192 route shows up as being an ‘E2’ route. E2 (External type 2) route’s are the default route type for routes redistributed into OSPF by an ASBR. The router prefers OSPF routes in this order…
intra-area routes, O
interarea routes, O IA
external routes type 1, O E1
external routes type 2, O E2
So that seems to make sense at this point but where’s out 0’s route? The fact of the matter is that OSPF doesn’t just inject a 0’s route unless it’s specifically told to do so. This is done by using the ‘default-information originate’ command. Let’s try that out on router3 and see what happens…
Now router2 sees the default route…
There’s an interesting option to the ‘default-information originate’ command called ‘always’. Let’s see what it does by removing the default route pointing to null0 and then configuring the ‘always’ option on router3…
If we wait a couple of minutes, and then look at router2, we still see that it has the 0’s route…
The always flag tells the OSPF router to ,you guessed it, always redistribute a 0’s route regardless of whether or not it actually has one. Ivan has a nice write up on when and where to use the ‘always’ version of the command here.
Now, let’s spice things up a bit by advertising the same route (192.168.0.0/16) into OSPF from EIGRP through switch2. Assuming that we already setup the advertisement, we’d expect to see that switch2 is preferring the route from switch3 to 192.168.0.0/16 since the EIGRP admin distance is 90. We would also assume that router6 would still be preferring the 192.168.0.0/16 up to router5 since switch2 is not yet redistributing the route from EIGRP into OSPF. Let’s take a look and see if we are right…
Looks like we were right about switch2. Now let’s check out router6…
Dead on! Now, let’s redistribute the route into OSPF from EIGRP, but let’s redistribute it as a E1 type route…
Note the addition of the ‘metric-type 1’ command which tells OSPF to treat the route as type E1 rather than the default of E2. A quick stare and compare of the route on router6 before and after the redistribution shows the E2 route from OSPF (redistributed from router3) and the E1 route now being redistributed from switch2…
Looking at the OSPF database on router2 again, we can now see several AS External LSAs…
In addition, we now see ASB summary LSAs on router2…
Recall that this LSA type identifies the ASBRs in the network. In this case, both router3 (RID 3.3.3.3) and Switch2 (RID 10.10.10.10) are advertising external networks into OSPF.
Before we close out this post, I want to take a look at some of the area types we can configure. Let’s show a quick example of a stub area, a totally stubby area, and a not so stubby area…
One last peak at the diagram so you don’t have to scroll all the way to the top…
Stub Area
Let’s convert area 2 to a stub area and see what impact it has on the link state database.
Router 2 Link State DB before conversion…
Now let’s configure all of the routers in area 2 so that they know area 2 is a stub area…
This example from router 2 shows the syntax. Now let’s take a look at router2’s link state DB after conversion to a stub area…
Notice that we lost all of the AS external LSAs as well as the ASB LSAs. The 0’s route has now moved up to be a summary link state and is being advertised by both of area 2’s ABRs (routers 1 and 4). Let’s remove the summary 0’s advertisement out of router3 that we created earlier to prove a further point. Once removed from router3, we see that router 2 still has a 0’s route pointing both ABRs…
However, a look at routers 1 and 4 show that they themselves do not have a 0’s route any longer…
Recall that with stub areas it’s the ABRs job to inject a summary 0’s LSA into the area so that the ABRs themselves can handle further, more specific, prefix routing.
Totally Stubby Area
Now that we have configured area 2 as a stub area, let’s configure it as a totally stubby area. Recall that a stub area uses type 1 (router), 2 (network), and 3 (network summary) LSAs. A totally stubby area takes that one step further by only allowing type 1,2, and a single type 3 LSA for the default route. The configuration for the totally stubby area is pretty similar…
Note that its the same as the stub configuration with the addition of the ‘no-summary’ command at the end of the stub configuration. Note here that I show the configuration occurring on router1. The totally stubby and configuration commands ONLY need to occur on the border routers. It doesn’t make any sense to configure intra-area routers since they aren’t going to see any of the LSAs that need to be filtered anyway. Let’s reconfigure router4 to make area 2 a totally stubby area and then check out the OSPF link state DB on router2 again…
As you can see, we now only have a single 0’s LSA from each of the ABRs.
Not so stubby Areas
The concept of not so stubby areas used to sort of baffle me. But once you see one in action, it isn’t that hard to understand. Recall that NSSAs can have type 1,2,3, 4 (ASBR), and 7 (NSSA External) LSAs. Let’s configure area 1 as a not so stubby area.
If we configure all of the routers in area 1 to be NSSAs with the following syntax, we can pretty easily see what’s going on…
Once the NSSA configuration has been applied to switch2 and router5, we can see the results in the OSPF database on router6…
Note that we have 2 type 7 SLAs to cover the two prefixes we are learning via the redistribution occurring on switch2. However, if we look at the OSPF database in the backbone on switch1, we see those LSAs a little differently…
Here they show up as type 5 (AS External) LSAs. That is, router 5 is translating them from type 7 to type 5. This is the normal behavior for a NSSA and was what I described in the earlier post about the action of the ‘P-bit’…
Not so Stubby Areas (NSSAs)
NSSAs allow a stub areas to have an ASBR inside of them. This would allow a stub area to learn routes from an external source and then advertise them into the OSPF domain. The NSSA LSA has something called the “P bit’ inside of it. The P bit determines whether or not the actual type 7 LSA gets distributed out of the stub area. If set to 0 the ABR will not advertise it out into OSPF. If set to 1 the ABR will translate the LSA to a type 5 and flood throughout the OSPF domain. This option allows you to learn external prefixes only within a given area.
So in this case, the P bit is set to 1. Unfortunately, it appears that the P Bit can not be changed to 0 on the NSSA ASBR through normal configuration. It looks like there are some workarounds to get similar behavior, but nothing straight forward.
I hope this post gave you some more confidence with OSPF. In the next post, I really want to dig into the OSPF RIB so that should be fun.
Stay tuned!