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…
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…
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…
However, if we look at the OSPF link state DB, we see the LSA still exists…
What does this mean? It means that if we look at router3 (or any other router for that matter)…
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…
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…
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…
Now, let’s clear the process and see what happens…
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…
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…
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…
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.
If we look at the router LSAs on router3, we can see that it thinks router4 is an ABR…
But it doesn’t think that router5 is…
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.
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…
As expected, router3 now think router 5 is once again an ABR…
And has all of the routers from all of the areas…
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…
On router 3, we configure the auth ‘type’ on the router process and the key on the interface…
The base configuration sends the keys in clear text. We can modify the configuration to use MD5 instead…
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.
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…
Nothing crazy, but something to keep in mind.
Pingback: OSPF Features – skminhaj