IGP

You are currently browsing articles tagged IGP.

There are a few versions of RIP out there…

RIPv1 – The original standard

RIPv2 – The original standard with a few additions that include…
-Support for classless routing
-Authentication
-Next hop address in route update
-Multicast route updates
-External tagging

RIPng – RIPv2 with the addition of support for IPv6

Since we haven’t talked about IPv6 yet, we are going to focus on RIPv2 in this post. 

RIP Updates
One of the huge improvements in RIPv2 is how the RIP updates are sent.  In RIPv1, the updates were broadcast across the network.  This meant that all routers ,even those not concerned with RIP, had to take the time to look at the packet before deciding not to use it.  In RIPv2, updates are multicast to the address 224.0.0.9. 

RIP Basic configuration
The configuration of RIP is brilliantly easy.  Much like any other IGP that we’ve examined, you simply define the routing protocol, set the version, and pick the networks you want to be advertised…

image

There are quite a few other RIP configuration items available…

image 

However, we should be pretty comfortable with most of these by now.  Rather than showing the configuration of these items, I’d like to talk about the RIP database followed by a basic redistribution example.

Unlike OSPF and EIGRP, the RIP database doesn’t have much to it.  In fact, there really aren’t many ‘show’ command for RIP at all…

image

As you can see, the only ‘show’ command it the ‘show ip rip database’ command.  On top of that, the only extension to that command allows you to look at a specific prefix.   And even when you do that, there isn’t anything more to look at…

image

RIP Updates
If we take a look at our topology again…

image

We can examine the multicast route updates occurring between switch1 and router4…

image

Here we see router4 advertising out it’s updates to switch1.  Note the multicast destination address and that router4 is only advertising the prefixes 10.0.0.20/30 and 10.0.0.0/24 prefix.  On the other hand, if we look at switch1’s update…

image

We see it advertising quite a few prefixes down to router4.  Why the difference in prefix count?  Basic split-horizon rules are applying here.  Switch1 is telling router4 about prefixes that it did NOT hear about directly from router4.  Those would include the following highlighted links…

image

On the other hand, router4 can really only tell switch1 about the prefixes that it isn’t hearing directly from switch1…

image

Keep in mind, that this really only applies to the ‘winning’ route here.  RIP uses the hop count as the metric and considers 16 to be ‘infinite’.  That is, a router that is 16 hops away wont be considered by RIP.  So in this case, router4’s best path to 10.0.0.24/30 is through router2 which implies that it heard the update from router2.  We can confirm that by looking at the communication between router2 and router4…

image

Above, router2 tells router4 about the path to 10.0.0.24/30. 

Below, since router4 is using that path for the prefix 10.0.0.24/30, there is no need to tell router2 about that prefix in it’s reply.

image

Switch1’s best path to 10.0.0.24/30 is through router1 so it obviously heard that update through router1.  This being said, since the best path to the 10.0.0.24/30 prefix for each device is through a different device, the devices can safely tell each other about the best path they have to 10.0.0.24/30.  If the link between router2 and router4 broke, router4 would stop sending switch1 the update for 10.0.0.24/30 since router4’s best path to that prefix would be through switch1. Don’t tell a device about the pest path to a prefix if it’s back through the same device.

It should be obvious at this point that RIP is just periodically sending it’s entire route table as an update to it’s neighbors.  There is no concept of a initial full update and then just minor updates afterwards.

RIP Redistribution
Let’s take a look at redistributing out 192.168.0.0/16 prefix from switch3 into RIP on switch2.  Recall that switch2 and 3 area talking EIGRP.  That being said, we want to redistribute EIGRP into RIP.  Let’s give that a try on switch2 and see what happens…

image

Now let’s check out our RIP database and see what we have…

image

Odd, it isn’t there.  Checking the FIB we see that the prefix is present on the EIGRP side of things…

image

So what could the problem be?  Recall above that I said the max metric for RIP was 16?  Take a look at the EIGRP route metric in the FIB…

image

There’s our problem!  To fix this, we need to tell RIP what metric to use when redistributing the EIGRP routes…

image

Now, since we set it to 13, the prefix will only appear on routers 6, 5, and 3.  Once it gets to router3 the metric will be 15 and switch1 will reject the route…

image

Router3 shows that it has the route with a metric of 15…

image

So there you have it, a quick and dirty look at RIP!

Tags: , ,

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: , ,

« Older entries