OSPF

You are currently browsing articles tagged OSPF.

Now that we have OSPF running and are pretty comfortable with how it does what it does, we can look at some of the more advanced features of OSPF.  Namely, I’d like to talk about route filtering methods, virtual links, OSPF authentication, and one other fact about defining networks for OSPF to use.

Route filtering
Route filtering in OSPF is sort of a ‘weird’ concept.  Recall that OSPF relies on each router in a given area having an identical link state database.  If you start filtering certain LSAs, you could have all sorts of problems. 

The route and switch cert guide identifies 3 ways to filter routes being advertised through OSPF.  Let’s take one example, and try to filter the routes  in each way…

image

Let’s say that switch3 is still advertising the 192.168.0.0/16 network through EIGRP to switch2.  Switch 2 is redistributing it, as well as the 10.0.0.32/30 network into OSPF.  For these examples, the goal will be to prevent the route 10.0.0.32 /30 from entering the backbone area.  To do this, we’ll first use the distribute list feature to filter the route ingress on router5.

A couple of quick notes before we start.  Unlike EIGRP that can use the distribute list command to filter routes inbound or outbound, OSPF can only use it in the ingress direction.  Additionally, the command doesn’t impact the distribution of LSAs, it just filters what the router will put into its FIB.

Let’s start be configuring a distribute list on router5 and see what happens…

image

A simple prefix list to deny the prefix we are trying to block followed be an ‘any’ entry will allow all of the other routes to still come in.  Taking a look at the routing table on router5, we see that the prefix is now gone…

image

However, if we look at the OSPF link state DB, we see the LSA still exists…

image

What does this mean?  It means that if we look at router3 (or any other router for that matter)…

image

We still see the prefix we blocked on router3.  So the distribute list really only works on individual routers.  Not a great option for route filtering in my opinion.

The second option for filtering routes is to use an area filter list.  This configuration makes more sense for what we are trying to accomplish.  In this method, we can use the same prefix list from above, but apply it with a slightly different configuration…

image

Here we apply the ‘filter-list’ command to filter the LSA entirely from even entering the backbone area.  Then we clear the process to refresh the LSAs.  Now, let’s check router3…

image

What gives?  It’s still there.  Here’s the catch, the filter-list command ONLY works with type 3 LSAs.  10.0.0.32/30 is being redistributed, so it’s a type 5 LSA.  Type 5 LSAs need to be flooded through all areas to allow for OSPF to work correctly.  Let’s prove our point here by slightly modifying the prefix list and filtering the network 10.0.0.36/30 from entering the backbone area…

image

Now, let’s clear the process and see what happens…

image

As you can see, 10.0.0.36/30 is gone, but the 10.0.0.32/30 (type 5) route is still present.  The important fact to remember about filtering in this manner is that the LSA itself is prevented from being sent into area 0.  If we look at router2…

image

We see that the LSA for 10.0.0.36 isn’t even present. 

The last option for filtering in OSPF is very similar to the filter-list command.  In fact, it practically does the same thing but it’s sort of a ‘hack’ on the use of the command. 

Using the ‘area range’ command, you can prevent type 3 LSAs from being advertised out of a specific area.  For instance, let’s look at blocking the 10.0.0.36 prefix from going into the backbone area again…

image

The ‘range’ command is used to tell the ABR to summarize all smaller networks and just advertise the one larger summary.  Tacking on the ‘not-advertise’ command allows you to tell the router to not only cease advertising the smaller prefixes, but the summary as well.

Virtual Links
As you should know by now, OSPF requires that all non-backbone areas connect to the backbone.  If, for some reason, you are not able to accommodate this requirement, a virtual links can be used to solve this problem.  So if we reconfigure out topology to look like this…

image

We can see that we have a problem.  Area 1 is not connected to the backbone area.  Surprisingly, the router’s don’t appear to be complaining about their new configuration, but there are some rather apparent issues.  For instance, router5 is not redistributing any of it’s area 1 routes into area 2. 

image

If we look at the router LSAs on router3, we can see that it thinks router4 is an ABR…

image 
But it doesn’t think that router5 is…

image
The requirement for an ABR to be an ABR is that it has at least one interface in area 0.  Since router5 doesn’t meet that requirement, it is no longer an ABR meaning that it will no longer redistribute type 3 LSAs from area 1 into area2. 

Enter the virtual link.  The configuration is pretty straight forward.  

image

image

Basically you pick the two routers that will ‘terminate’ the virtual link, and configure one another to point to the other router’s RID for the virtual link. 

After that’s configured, the virtual link loads.  We can examine the virtual link by executing the following show command…

image

As expected, router3 now think router 5 is once again an ABR…

image 
And has all of the routers from all of the areas…

image

OSPF Authentication
OSPF authentication is generally done on the interfaces but you can also set a default authentication ‘type’ under the OSPF process and then just configure the keys on the interfaces.  Let’s take a look at doing it both ways…

On router 5, we do the entire config on the interface…
image

On router 3, we configure the auth ‘type’ on the router process and the key on the interface…
image

The base configuration sends the keys in clear text.  We can modify the configuration to use MD5 instead…

image

image

To configure or not configure networks
An interesting option exists in OSPF that allows you to not have to manually configure each ‘network’ underneath the OSPF process.  Rather, you can simply configure an interface to be part of a particular OSPF area. 

image

In this example, I’m configuring the ‘ip ospf <process ID> area <area ID>’ command under each of router3’s interfaces.  I then remove the network statements from the router OSPF configuration.  Once I clear the process, everything loads just the way it was…

image

Nothing crazy, but something to keep in mind.

Tags: , ,

Out of all of the IGPs we’ve examined so far, OSPF has one of the most complicated RIBs.  Many times, engineers that setup OSPF just configure the default settings, verify the routes are in the FIB, and consider the job done.  Then, later, they have a hard time troubleshooting it once its running because the RIB can be hard to interpret if you aren’t accustomed to it.  The goal of this post is to familiarize yourself with ways to examine the RIB and become better at troubleshooting OSPF issues.

Let’s be clear, I’m not the first one to do this, there are lots of other similar posts to this one out there.  I’ll list them here so that if my explanation doesn’t make sense, you can have another ‘go’ at it somewhere else. 

Darren’s Blog – Demystifying the OSPF Database

IPExpert – Quick look into the OSPF Database: Router LSA

IPExpert – Quick look into the OSPF Database: Summary LSA

IPExpert – Quick look into the OSPF Database: External and ASBR-Summary LSA

So let’s take a look at our topology again…

image

I’ve modified things slightly from a config perspective.  Router3 is advertising a 0’s route into OSPF and switch2 is still receiving the 192.168.0.0/16 advertisement through EIGRP and redistributing it into OSPF.  In addition I’ve converted the link between router1 and router2 to be a normal (non point-to-point) OSPF network type.  All of the areas have been reverted to normal areas as well. 

So let’s now imagine that we are router2.  Recall that the strength of OSPF is that each router (for the most part) knows the entire topology.  For instance, let’s take a look at the database summary on router2…

image 
Here we can see all of the LSAs that router2 has received.  In this case we have type 1 (Router), type 2 (Network), type 3 (Network Summary), type 4 (ASBR), and type 5 (AS External) LSAs.  While we’ve spent most of the time up until now looking at the entire database, we can view specific LSA types by extending the ‘show ip ospf database’ command.  For instance…

image

When you execute one of these more specific commands, you get the detailed LSA information.  Let’s start by looking at the router LSAs (type 1). 

Router LSAs (Type 1)
As stated, when looking at specific LSA types, you get the detailed information about the LSAs.  It’s useful (required in most cases) to filter this down to a more manageable output.  The router LSAs have an easy way of doing that by adding additional commands to the show command…

image

These are really handy!  Imagine an area with tens or maybe even hundreds of routers.  The output of ‘show ip ospf database router’ would be overwhelming.  That being said, I want to focus on two specific commands. 

show ip ospf router self-originate

and

show ip ospf router <Router ID>

The self-originate command gives us information about the LSA that the local router is originating.  For instance…

image
As you can see, this router LSA is for router2 (RID 2.2.2.2).   This is a real wealth of information!  You can see the 4 links that router2 has (4 because the links are point-to-point), the IP interfaces and mask of each of the links, and the neighboring router’s RID.  Likewise, we can examine router LSAs we received from other routers…

image
Same sort of information here, but it shows the information relevant router1.  Recall that type 1 LSAs are flooded only within a certain area.  That being said, we only see router1’s link that exists in area 2.   Examining the router LSAs that a router has gives you a good idea of what router’s exist in a given area as well as the networks attached to those interfaces.  Using these LSAs alone you could build a pretty decent network diagram of a given area.

Network LSAs (Type 2)
The type 2 LSA shares information with us about intra area broadcast network segments that have more than 1 OSPF router attached to them.  Recall that these LSAs are only generated by a segments designated router.  Once again, we can use the following show commands to look at more specific network LSAs…

show ip ospf database network self-originate

and

show ip ospf database network <Router ID>

image

The most valuable piece of information found in a network LSA (in my opinion) is the list of attached routers.  Since the DR is the only device originating this LSA, it’s good to know what other router’s live on that segment.  

Network Summary LSAs (Type 3)
The network summary LSAs get viewed slightly differently than the router or network LSAs.  Here are out options for viewing them…

image

If we are on an ABR, we would be interested in the self-originate command.  Since router2 isn’t an ABR, we wont see any output with that command.  If we want to see the summaries that are being advertised by a particular ABR on rotuer2, we can use the ‘adv-router’ command.  For instance…

image
Here’s a sample of the output we see.  These are all the summaries that router4 is advertising into area 2.   

When I started working with OSPF, one of the main areas of confusion I had with OSPF was how OSPF shows the actual network prefix in the database.  As you can see in the above output, the network itself get’s advertised as a ‘Link State ID’.  So for instance, the LSAs listed above are for the networks 10.0.0.0 /30 and 10.0.0.8/30.  However, with the network LSAs (type 2), the link state ID is the IP address of the advertising router, not the network itself.  In the case of the network LSA, you’d have to look at the mask and figure out based on the IP of the designated router what the subnet actually is. 

ASBR Summary LSA (Type 4)
I think the type 4 LSAs are pretty neat.  On a normal OSPF router looking at the type 4 LSAs can tell you exactly which OSPF routers are advertising ‘external’ route into your network.  For instance…

image
One quick look at this output and I can tell you that routers 3 (3.3.3.3)  and switch2 (10.10.10.10) are advertising external routes into OSPF.  Don’t get confused by the advertising router piece of this output.  That just tells you that routers (1.1.1.1) and router4 (4.4.4.4) are the ABRs advertising these LSAs into this area.  Recall that these LSA types are just used to identify the actual ASBRs, not tell you about the prefixes they are advertising.

AS External LSA (Type 5)
The type 5 LSAs describe to us exactly which prefixes the ASBRs are advertising into OSPF.  A quick output will give us a lot of information…

image
Note that the output could be delimited further with the ‘adv-router’ flag which in this case would be the router ID of the actual ASBR, not the ABR that advertised the LSA into the area.   This LSA type also tells us the ASBR that’s advertising the router with the link state ID in this case being the actual network prefix. 

Note that the metric for the two routes coming from 10.10.10.10 is 20.  20 is the default cost for routes advertised into OSPF.  Also note that the metric type if type2.  Recall from the earlier OSPF post that we saw that E1 (type 1) routers were preferred over E2 (type 2) routes.  I never really explained the differences so here it is. 

Type 2 routes only include the cost of the redistributed route.  That is, the cost that the ASBR has for the route upon redistribution (20 in this case) is the same cost that a router 10 hops away will see for the route.  Basically, the metric for E2 routes is the same across the entire OSPF network. 

Type 1 routes include the cost of the redistributed route, PLUS the cost to get to the ASBR.  For instance, let’s change the routes being advertised by switch2 to be type 1 routes so you can see the difference…

image

Now let’s look at the OSPF database again for external routes being advertised by switch2…

image
So we can see the LSA is now a type 1 LSA, but the metric is still listed as 20.  What gives? 

This my friends is the point in this post I’ve been waiting to get to.  This is where it all comes together in a glorious moment where everything clicks.  So here we go…

Let’s take a look at the route for 192.168.0.0/16 in the FIB.  Recall that we’ve been looking at the OSPF database (RIB) up until this point.  This is just where OSPF keeps all of it’s info.  Just because we see something in the OSPF RIB doesn’t mean that we’ll see it in the FIB…

image

Aha!  So the metric really isn’t 20, it’s 95.  But where did that come from?  The OSPF RIB shows 20 for that LSA.  Here’s what happens…

Since it’s a type 1 (E1) route, we need to account for not only the redistributed metric (20), but also the path to get to the ASBR.  The type 5 LSA doesn’t tell us that, so we need to look at the other LSAs to figure this out.

Find the cost to the area ABR 
In our case, that cost is 1 since we are one hop away from the ABRs router1 and router4…

image

Find the cost to the ASBR advertising the type 5 LSA
To do this, we can look at the type 4 (ASBR) LSA…

image

Here we can see the metric 74 to get to that ASBR.  Recall that router 5 still has the manual cost of 70 configured on it’s interface.  We can verify this by looking at the diagram as well…

image

Find the external cost of the metric 
We already saw this in the type 5 LSA…

image

But the cost in this LSA is 20.  Add it all together and what do we get?

image

95!  I guess I was hoping that this would be an ahah! moment for you.  I know it was for me when I finally grasped the concept that route metrics and path determination in OSPF are a accumulation of multiple LSAs, not just specific ones. 

It should also be noted here that the default route (from 3.3.3.3) showed as a metric of 1 in the type 5 LSA above.  That’s the default metric for the 0’s route being advertised in via the ‘default information originate’ command. 

That wraps up this post, thanks for reading!

Tags: , ,

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…

image

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…

image

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…

image

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…

image 
Hence, we end up with 4 links.  But wait a second… 

image

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.  

image

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)….

image 
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…

image

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…

image

Before we move on to look at the other routers OSPF topology tables, let’s look at what ends up in router2’s FIB…

image

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…

image

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…

image

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…

image

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…

image

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…

image

Now router2 sees the default route…

image

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…

image

If we wait a couple of minutes, and then look at router2, we still see that it has the 0’s route…

image

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…

image

Looks like we were right about switch2.  Now let’s check out router6…

image

Dead on!  Now, let’s redistribute the route into OSPF from EIGRP, but let’s redistribute it as a E1 type route…

image

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…

image

Looking at the OSPF database on router2 again, we can now see several AS External LSAs…

image

In addition, we now see ASB summary LSAs on router2…

image

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…

image

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…

image
Now let’s configure all of the routers in area 2 so that they know area 2 is a stub area…

image

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…

image

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…

image

However, a look at routers 1 and 4 show that they themselves do not have a 0’s route any longer…

image

image

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…

image

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…

image

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…

image

Once the NSSA configuration has been applied to switch2 and router5, we can see the results in the OSPF database on router6…

image

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…

image

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!

Tags: , ,

« Older entries