In the first installments of the OSPF filtering series, we were able to discuss the three major filtering techniques in OSPF: LSA Type-3 Filtering, NSSA External Routes Filtering and Filtering with Summarization.   I have also mentioned in the first Post of the series some “Corner Cases” where is necessary apply filtering in places other than ABRs or ASBRs.   This is achieved by applying filtering to the OSPF RIB using Distribute-Lists.

Well, time has come to talk about using Distribute-Lists to filter “Routes”.

Please note that I have quoted the word “Routes”.   We must be clear that OSPF is a link-state protocol.   OSPF don’t advertise routes per se, OSPF advertises topology information.   The routers participating in OSPF share an identical copy of the Link-State Database (LSDB) for the areas where are participating.    So far we have been achieving filtering but not by actually filtering routes perse, we have been “modifying” some LSAs in such way OSPF will simply end up discarding the LSA from the LSDB.

When we applied LSA Type-3 filtering, what we have done is modifying the LSA generated by the ABR with the LSA AGE set to its max-age value. Therefore, the LSA is eventually withdrawn from the topology.  We didn’t actually prevent the LSA from being formed.   It’s the same effect when we apply OSPF Filtering with Summarization.   In this case, we have summarized a group of prefixes before generating the LSA with the max-age value set.

For NSSA external route filtering, the only thing we did was just instructing the ASBR to generate the Type-7 LSA without the P-Bit set.   When ASBRs generates Type-7 LSAs, they do it with the P-Bit set by default.   The P-Bit or Propagate-Bit instructs ABRs connecting the area to perform Type-7 to Type-5 translation.   In other words, LSAs without the P-Bit set won’t be advertised beyond the NSSA.

Now, since the Link-State Database (LSDB) must be the identical within areas, what can be done to filter the required routes?

The solution here is filtering the routes from entering the routing table by using the distribute-list {access-list-number|name} {gateway} {prefix-list} {route-map} in|out OSPF process command.

Now, there are some rules to be considered when using distribute-lists:

• The distribute-list command is used to filter routes from being installed in the routing table or redistributed into another routing protocol, it does not filter LSAs.
• Using the distribute-list command in the inbound direction is used to filter routes to be installed in the routing table.
• Using the distribute-list command in the outbound direction filters only the desired redistributed routes. Meaning that is used only on ASBR’s.

We must be careful when using this command, as mentioned before this applies filtering to the Global RIB; it doesn’t prevent the LSAs from being advertised.   Therefore, it may cause a traffic black hole.

Let’s use the following topology for the examples:

Here you can download the diagram and configuration files:  OSPF-Filtering – Part III

Using the distribute-list command in the inbound direction:

Goal 1:

Filter the route to 2.2.2.2 in R4.

First, let’s take a look to the routing table in R4:

As can be seen in the above output, the route 2.2.2.2/32 is in the routing table.  It is displayed as an “O” OSPF route, meaning that it was advertised from another OSPF-enabled router within the same area (intra-area).   From this output, we can conclude that the prefix was advertised via a Type-1 (Router) LSA.

Just as a reference, let’s take a look to the Type-1 (Router) LSA:

As can be seen in the output, the LSA has 3 link advertisements enclosed.  One LSA corresponds to the Stub Network 2.2.2.2/32 and the last two corresponds to the Transit Networks.

Ok, because the advertising router 0.0.0.2 (R2) is placed in the same area, the only possible filtering option is by using distribute-list in the inbound direction.

So, let’s apply the filter using a simple ACL.

In R4:

!
access-list 2 deny   2.2.2.2
access-list 2 permit any
!
router ospf 1
distribute-list 2 in
exit
!

Now, let’s take a look at the routing table of R4:

As can be seen in the output, the route is no longer present.  What about the LSDB?  What was the effect of the filter in there?

As can be seen, the Type-1 LSA is still there.   There was no effect on the LSDB.   Now let’s take a look to the OSPF RIB:

Have you noticed the difference?  Yes, the “greater than symbol” next to the route.  This means the route is present but it wasn’t marked as Best.   Thus, the route is not installed in the Router’s RIB.

Now, we could achieve the same result by using extended ACLS.

Let me show you a trick.    Not long ago I was requested to filter a specific route, the same way it was done before.   However, the request also has included one very specific requirement as well.  The filter must apply only over business hours, Monday thru Friday from 7:00 am to 7:00 pm.

Here goes how to do it:   (This requires time synchronization.)

1. Create a Time-Based ACL.
2. Apply the distribute-list referencing the Time-Based ACL.

In R4:

!
time-range NO-ACCESS
periodic weekdays 7:00 to 19:00
!
access-list 102 deny   ip any host 2.2.2.2 time-range NO-ACCESS
access-list 102 permit ip any any
!
router ospf 1
distribute-list 102 in
exit
!

Another way to do it is by using prefix-lists:

In R4:

!
ip prefix-list NO-LO-R2 seq 10 deny 2.2.2.2/32
ip prefix-list NO-LO-R2 seq 20 permit 0.0.0.0/0 le 32
!
router ospf 1
distribute-list prefix NO-LO-R2 in
exit
!

Another possible thing we can do with distribute-list is matching the source of the route.  To clarify this, by the source of the route I mean the gateway used to reach the route to be filtered.

Let’s make a small change to the topology for this:

Let’s add the link in red and remove any configured filtering.

The link configurations are as follows:

In R3:

!
interface Ethernet0/2
ip address 192.168.34.3 255.255.255.0
ip ospf 1 area 0
!

In R4:

!
interface Ethernet0/2
ip address 192.168.34.4 255.255.255.0
ip ospf 1 area 0
!

Ok, now let’s take a look at the routing table in R4:

As can be seen in the above output, by adding this link, R4 has now two equal cost paths to reach networks beyond the transit network 192.168.123.0/24.

Goal 2:

Apply filtering in such way that the Loopback0 in R1 be can be reached from R4 only thru R2.

Ok, so far we know the route to 1.1.1.1/32 (Loopback 0 in R1) is being load-balanced.   This is because OSPF is doing ECMP (Equal Cost Multi-Path) between R2 and R3.   What we must do is filtering only the route through R3.

There are two ways to achieve this.   One applying the distribute-list using one of the different ways we have learned so far (access-list, extended ACL, named ACL or prefix-list) and specify the interface from where is learning the route.

Let’s try it this way:

For this example, I would use a named ACL.

In R4:

!
ip access-list standard R1_Loopback0
deny   1.1.1.1
permit any
!
router ospf 1
distribute-list R1_Loopback0 in Ethernet0/2
!

Now, let’s take a look at the routing table in R4 and to the details of the OSPF RIB for that particular route:

As can be seen in the above output, the route to 1.1.1.1/32 is now reachable only via R2.  The rest of the routes remain to be load-balanced.    Also, take a look to the OSPF RIB.   Both routes are present.   However, the one with the arrow in blue through R3 has no RIB flag, while the other route, thru R2, has it.    Only the route in green was installed into the Router’s routing table.

The other way to achieve this goal is by using Route-Maps.   Route-Maps provide more flexibility than ACLS or Prefix-Lists.   With route-maps we can match multiple options such:

• match interface
• match ip {address|next-hop|route-source}
• match metric
• match route-type {internal|external [type-1|type-2] | nssa-external [type-1|type-2]}
• match tag

We could achieve the same result by using the following configuration:

In R4:

!
ip prefix-list Filter-R1-L0 seq 5 permit 1.1.1.1/32
!
route-map FILTER->RIB deny 10
match ip address prefix-list Filter-R1-L0
match interface Ethernet0/2
!
route-map FILTER->RIB permit 100
!
router ospf 1
distribute-list route-map FILTER->RIB in
exit
!

I think that you get the idea.

Now, why have I mentioned that we must be careful when using this command?

I will use another example to illustrate why.  Let’s use the original topology, without any filtering.

Goal 3:

Filter the route to 1.1.1.1 only in R2.

It seems a fairly simple task now that we know how to do it.   So let’s apply the filter in R2.

In R2:

!
access-list 1 deny   1.1.1.1
access-list 1 permit any
!
router ospf 1
distribute-list 1 in
exit
!

Now let’s take a look at the routing table in R2:

Ok, as shown in the above output, seems that it worked.  The route to 1.1.1.1 is no longer in the routing table of R2.

Let’s say it’s the last trouble ticket of the day.  Then we proceed to turn off the computer and drive back home.   That’s it for the day.

An hour later, we receive a phone call reporting problems to reach 1.1.1.1 from R4.

But, wait a minute!  We did not make any change to R4.  Do we?

As a matter of fact, yes indirectly we did it. We have created a black hole in the network.

Let me explain this.

When we apply the filter to the route 1.1.1.1, it was applied directly to the routing table.  The LSDB was not altered.  R4 has received an LSA from R2 containing information how to reach 1.1.1.1, thus, R4 has installed the route in its routing table.

Guess what is the next-hop to reach 1.1.1.1 from R4?   Yes.  It’s the same next-hop used to reach any other network, R2.

Now you know why OSPF RIB filtering must be used carefully.   This was just an example, but what if we make the same mistake to a high sensitive area of the production network?   This could be a Resume Generating Event.

Using the distribute-list command in the outbound direction:

As mentioned before, using the distribute-list command in the outbound direction filters only the redistributed routes.   Meaning that is used only on ASBR’s.

Goal 4:

Prevent the route to 55.55.55.55/32 from being advertised beyond R1.

Let’s turn on the debug ip ospf lsa-generation for this example.

In R1:

!
debug ip ospf lsa-generation
!
configure terminal
!
access-list 55 deny   55.55.55.55
access-list 55 permit any
!
router ospf 1
distribute-list 55 out
exit
!

Let’s take a look at the output of the debug.

Immediately after applying the filter, R1 generated a Type-5 LSA with the max-age set (3600 seconds).  Remember, LSAs with max age set are discarded.  Also, note the metric was set to 16777215.  This is the maximum metric for routes in the OSPF database in decimal.  A route with this metric is inaccessible therefore is discarded from the OSPF database.  This metric is also known as LSInfinity.   The result is the filtering of the desired route from the OSPF domain.

Let’s confirm this by looking the routing table in R4:

As can be seen in the above output, the filtering worked as expected.   The route to 55.55.55.55/32 is not present in the routing table.

There is one last thing to mention in regards to filtering.  It has to do with NSSA areas.

Let’s modify a little bit the topology:

Let’s put R4 into an NSSA area and create loopback1, let’s redistribute it into the process.  Let’s also remove any filtering in R2.

In R2:

!
router ospf 1
area 24 nssa
!
interface Ethernet0/1
ip ospf 1 area 24
!

In R4:

!
interface Loopback0
ip ospf 1 area 24
!
interface Loopback1
ip address 44.44.44.44 255.255.255.255
!
route-map CONN-LOOPBACKS->OSPF permit 10
match interface Loopback1
!
router ospf 1
area 24 nssa
redistribute connected subnets route-map CONN-LOOPBACKS->OSPF
exit
!

With this configuration applied, R4 has generated and flooded a Type-7 LSA within the area, corresponding to the redistributed route. R2 (ABR) received the Type-7 LSA with the P-bit set; R2 then has generated a Type-5 LSA and start advertising the redistributed route on behalf of R4.

Let’s take a look at the routing table in R2, just to confirm that the route is there.

Ok, the route was installed. Now, let’s apply filtering to 4.4.4.4 (Loopback0) in R2.

In R2:

!
ip access-list standard R4_L0
deny   4.4.4.4
permit any
!
router ospf 1
distribute-list R4_L0 in
exit
!

Finally, let’s take a look at the routing table in R2 and take a look at the results:

Ok, the filtering didn’t work as expected.   The route to 4.4.4.4/32 was filtered, but also, the route to the redistributed 44.44.44.44/32 was removed from the routing table.

So, what happened here?

First, let’s take a look to the LSDB and then to the OSPF RIB in R2:

Ok, as can be seen in the above output, the Type-7 LSA is there, the route 4.4.4.4/32 was filtered in the OSPF RIB (It doesn’t have the greater than symbol or RIB flag).  Also, the route 44.44.44.44/32 is not present in the OSPF RIB.

Now, let’s take a look to the Type-7 LSA and try to figure out what the problem is.

Ok, did you find the problem?

The P-bit is there.  Meaning the translation from Type-7 to Type-5 must take place.   That is not the problem.   What about the forward address?   Yup, you got it.   At the moment we filter 4.4.4.4, the route finds itself without next-hop.  Thus, the LSA was discarded.

The problem has to do with the way NSSA advertise redistributed routes.  NSSA choose the forwarding address as follows:

It chooses the highest IP address of an internal address; if an internal address is not available, it will prefer the higher found OSPF stub network.

It is good to emphasize that although filtering the OSPF RIB sometimes seems a good idea, in some cases; it may lead to undesired behaviors and in extreme cases may end in self-inflicted denial of service.   So, use it carefully.

It is time to close this long post. In the next one, we will continue discussing OSPF Filtering but, this time, using Administrative Distance.

Thank you for visiting.