Filtering OSPF Routes Part 1

Filtering routes is a little more complicated when we are talking about OSPF. In EIGRP it was simple. Since EIGRP is an advanced distance vector routing protocol, each router doesn’t have a perfect picture of the routing domain, it just has an idea of what’s behind our neighbor. OSPF is of course different. Each OSPF area must have an EXACT copy of the OSPF database, and thus the network (in the area). From our basic understanding of OSPF we know it’s crucial that all routers in the area have the same Link State Database (same type 1,2 LSAs). Only then will be able to calculate a proper SPF tree. The “proper” way to filter OSPF routes is to do it on our ABRs and ASBRs. It is possible to filter routes on non ABR and ASBR routers but it gets ugly (we’ll discuss that later). For now here is our topology.

 

 

First let’s setup the network:

R1:
int g1/0
ip add 192.168.1.2 255.255.255.0
no shut
ip ospf 1 area 0

R2:
 int g1/0
ip add 192.168.1.1 255.255.255.0
no shut
ip ospf 1 area 0

int g2/0
ip add 192.168.2.1 255.255.255.0
no shut
ip ospf 1 area 1
R3:
int g2/0
ip add 192.168.2.2 255.255.255.0
no shut
ip ospf 1 area 1
int loopback 0
ip add 33.33.33.33 255.255.255.255
ip ospf 1 area 1

 

In OSPF one of the ways we can filter routes is via the “filter-list” command. The filter-list must be executed on our ABRs and ASBRs. This is because the filter-list prevents type 3 (summary) LSAs from being propagated inter-area. The filter-list tells our ABRs to NOT create the type 3 LSA to be passed to area 0.

 

Currently this is what the Type 3 LSA looks like for 33.33.33.33/32 in area 0 (the area where it is summarized)

Before we begin I need to note one thing. The LSID (Link ID) is the network that we need to filter. In my example I used a loopback interface so I made it a /32, OSPF automatically advertises loopbacks as /32 even if I gave it a /24 subnet mask. In my case the LSID is 33.33.33.33 , if this was a real network adapter, the subnet would be here NOT the interface IP. For example if this was a gig interface connected to a stub network the IP might be 33.33.33.1/24 in the LSID it would show 33.33.33.0.

Now let’s begin. Since R2 is our ABR, we will do the filtering there.

R2:
conf t
ip prefix-list R3_LOOPBACK deny 33.33.33.33/32
ip prefix-list R3_LOOPBACK permit 0.0.0.0/0 le 32
router ospf 1
area 1 filter-list prefix R3_LOOPBACK out

note: If you are not comfortable with prefix-lists, check out my post about it

Now let’s go over those commands real quick. First of all my prefix-list denies the LSID of 33.33.33.33, then it passes everything else. Prefix-lists, just like access-lists have a implicit deny statement at the end that we need to be mindful of. This is why I added the permit everything else statement. If I didn’t, well I would lose all my type 3 LSAs going into area 0.

Secondly, you need to make sure you understand filter list logic. So let’s break it down. There are a couple of ways we can accomplish this. In my case I chose to filter type 3 LSAs LEAVING area 1. My prefix-list results that are denied are passed to the filter-list for processing. Its helpful to use context sensitive help in this case after the prefix-list name to get a better idea of how it works.

Notice here how it says OUT does the following “Filter networks sent from this area”. If we wanted to do it another way we could have used this command.

area 0 filter-list prefix R3_LOOPBACK in

What actually happens here is that R2 sets the type 3 LSA age to 3600 seconds (60 minutes) which causes it to age out and eventually disappear.

Let’s look from R1’s perspective RIGHT after I run the filter-list command on R2.

Then a few seconds later it disappears.

We can see the Link State Update (LSU being sent from R2 to R1)

Then R1 acknowledges it.

Perfect, the only type 3 LSA we have is of the 192.168.2.0/24 network we did not filter out.

 

Now that you understand this logic you can move onto part 2 of filtering OSPF routes.