In today’s post, we will continue discovering the different ways we can perform filtering in OSPF.

Previously we depict two common ways to filter routes in OSPF, the first one using LSA Type-3 filtering and the second was filtering NSSA external routes directly to the redistribution process in OSPF.   Worth mentioning that for the second example in the previous post (Goal 2) I did a change in the original configuration.   This was done just to illustrate a way to instruct OSPF to not to impose the P-bit into the redistributed routes.   However this effect could be achieved by doing a simpler change which will help us to introduce the third OSPF filtering type:

Filtering with Summarization

This type of filtering as its name implies works in conjunction with OSPF Summarization.  The idea behind this type of filtering is done by grouping a set of prefixes by using summarization and then suppress the newly generated LSA propagation adding the not-advertise keyword.

Let’s use the previous network topology for the examples.   (Please note the addition of Loopbacks 16 to 18 in R6).

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

Let’s take a look to the routing table from the perspective of R4, but let’s focus on the routes coming from the EIGRP domain:

Ok, so far we know the prefixes 172.16.1.0/24 to 172.16.10.0/24 and 172.16.16.0/24 to 172.16.18.0/24 are being redistributed from R6 (EIGRP domain) into OSPF in R1 and then Summarized into a single /16 supernet.  This redistribution makes R1 an ASBR.  We also know R1 is placed into an NSSA area.   This means the routes were originally advertised as Type-7 LSAs by R1 and then translated into Type-5 LSAs by one of the ABRs connecting the NSSA and flooded into Area 0 and from there to the rest of the OSPF domain.

Having this information on hand, let’s play a little bit with Filtering with summarization.

Goal 1:

Summarize the routes coming from the EIGRP domain into two /20 supernets (172.16.0.0/20 and 172.16.16.0/20).  Apply filtering in such way that the network 172.16.0.0/20 only be accessible from R1, the second segment can be reached from anywhere in the network.

Ok, the task is very straightforward.  What we should do is remove the previous summarization and generate two summary routes; however one of the summary routes should not be advertised.  This can be achieved by adding the not-advertise keyword to the summary route at which we want to apply the filter.    Now, I would like to demonstrate the effect in the LSDB of adding the keyword after the summary route was created.   So, let’s do it.

In R1 (ASBR):

!
router ospf 1
no summary-address 172.16.0.0 255.255.0.0
summary-address 172.16.0.0 255.255.240.0
summary-address 172.16.16.0 255.255.240.0
exit
!

Let’s take a look at the Link-State Database (LSDB) in R1, specifically the Type-7 AS External LSAs:

As can be seen in the above output, now we have two summary Type-7 LSAs.   Also, note the LSAs have the P-Bit set (In blue).   This will trigger the translation between Type-7 into Type-5 LSAs in the ABR.   Both summary routes will be advertised to the OSPF domain.

The last part of the goal requires filtering the first range.   So, to apply the filter, just add the not-advertise keyword to the desired summary-address command.

Before adding the filter let’s debug the ospf lsa-generation and observe the changes:

I never get tired of repeating that the use of any debug must be done with extreme caution.

As can be seen in the above output, after the changes were applied R1 generated an external LSA for the network 172.16.0.0/20 with LS age set to 3600 seconds which is the max age.  The LSA metric was set to 16777215 or (max-metric for routes in the OSPF database) LSInfinity.  When the max age timer on an LSA reaches 60 minutes, the LSA is discarded.    The result is: Yes, the filtering of the summary network 172.16.0.0/20.

As seen in the above output, the filter worked as expected.   This solution is suitable for this particular situation, where only the network in R1 needs the access.   They will use the EIGRP routes for this purpose.

However, these routes will not be reachable from anywhere else in the OSPF domain as can be seen next.

As can be seen in the above output, the networks are reachable from the desired points of the network, the traffic flows accordingly; the network is stable, and the goal was achieved.

After a few days, we have received the following information:

“Within the following weeks, some new network segments will be created in R2 and R3 for Servers connected to Area 30.   This change will require allowing access to the network 172.16.0.0/20 in the EIGRP domain from Area 30.”

In this case, the filtering solution provided before will not work.  To achieve this will be required to allow the advertisement of the summary networks to R2 and R3 respectively and stop the advertisement there.

This requirement is similar to Goal 2 of the previous post.  So, let’s do it.

Goal 2

Apply OSPF filtering to the summary route 172.16.0.0/20 in such way this network only be accessible from AREA 30.  The second segment can be reached from anywhere in the network.

Let’s recap a bit what we did to solve it in the last post.   What it was done was removing the summarization of the route in question, and then apply filtering directly into the redistribution process using the keyword NSSA-only.

In this case, the given solution in the previous post won’t work.  This is because we have two summary routes from which only one has to be filtered.

Luckily OSPF provides the same functionality when summarizing external routes in Not-so-Stubby-Areas, meaning that we can use the keyword NSSA-only, and at the same time suppress the P-bit from being imposed.    The direct result will be the no translation from Type-7 to Type-5 LSAs in the ABR, thus, the desired summary route won’t be advertised beyond Area 30.

Let’s make the change and take a look to the external type-7 LSAs in R1:

In R1 (ASBR):

!
router ospf 1
no summary-address 172.16.0.0 255.255.240.0 not-advertise
summary-address 172.16.0.0 255.255.240.0 nssa-only
exit
!

As can be seen in the above output, now R1 has generated Type-7 LSAs for both summary routes.   But if you look (in blue) the options field for each one, the first LSA has the Type7/5 bit imposed while the other says No Type 7/6 translation.    In other words, only the LSA with the P-bit set will be translated to Type-5 LSA in the ABR and flooded into Area 0.

Let’s take a look from the perspective of R2:

As shown in the above output, in R2 we can find Type-7 LSAs for both prefixes but note (in blue) there is only one Type-5 LSA.   This confirms the change.   Only the LSA corresponding to the prefix 172.16.16.0/20 was translated into Type-5.    For brevity, I’m showing only R2, but it is the same output from both ABRs.  (If you look closer to the Type-5 LSAs, the advertising router is R3.   This is because the Type-7/5 translator is R3.  Thus, R3 was the one advertising the generated Type-5 LSAs to R2.)

Now, from R2 and R3 we can find both routes as “O N2” or OSPF NSSA external type 2 routes, meaning that both summary routes can be reached from Area 30 as shown in the next output:

Finally, let’s check the changes from R4’s perspective:

As can be seen, the goal was achieved, only the subnet 172.16.16.0/20 from the EIGRP is reachable from there.   What about the routers in Area 40?  They don’t have individual routes for external networks.   Stub areas generate the default route in OSPF by default, being the ABR the next-hop to reach external networks, thus they rely on R4 to route the traffic.  Therefore, they won’t be able to reach the filtered routes either.

After a few weeks a new request is received:

“The traffic from Area 30 and the EIGRP domain to the segments 10.4.1.0/24 to 10.4.3.0/24 must be filtered.”

Ok, let’s get started.

Goal 3

Apply OSPF filtering in such way that eastbound traffic from R1 towards 10.4.1.0/24 to 10.4.3.0/24 be unreachable; all other networks must work as usual.

Let’s start looking at the traffic path from R1’s perspective:

As can be seen in the above output, the desired traffic is been load-balanced via R2 and R3.

We know that R2 and R3 are ABRs, and we also know that we can summarize the desired networks into 10.4.0.0/22.   Then OSPF filtering with summarization can be a suitable solution.

So in order to achieve the goal, we have to apply the filter into both ABRs.   If we apply it to only one of them, the result will be…  Yes, you got it, some sort of Traffic Engineering.

So let’s start by applying the filter into the first ABR.

Remember, to filter the summary route, just add the not-advertise keyword to the summarization command.   Also remember, when doing summarization, in ABRs the command area {area-source} range {network-id} {subnet-mask} OSPF process command is used; where {area-source} as its name implies, is from which area is the router receiving the desired LSAs.

In R2 (ABR):

!
router ospf 1
area 0 range 10.4.0.0 255.255.252.0 not-advertise
exit
!

With this change applied only in R2, the summary route 10.4.0.0/21 won’t be advertised to R1, but the individual routes will by reachable via R3 as shown below:  (Traffic Engineering effect.)

Finally, the only missing part of achieving the goal is applying the same filter into R3 ABR.

In R3 (ABR):

!
router ospf 1
area 0 range 10.4.0.0 255.255.252.0 not-advertise
exit
!

Let’s take a look now to the routing table in R1 and R6 (EIGRP domain):

As can be seen, now only the routes to 10.4.4.0/24 and 10.4.5.0/24 from R4 are present in the routing tables of R1 and R6.

Let me explain why:

When we apply the command area 0 range 10.4.0.0 255.255.252.0 not-advertise on both ABRs, they have generated and flooded a Type-3 LSA corresponding to the summary address with the LS age set to its max value (3600 seconds) and the metric set LSInfinity.  Therefore, these LSAs were discarded within Area 30.   Subsequently, the routes were no longer redistributed into the EIGRP domain.

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

Thank you for visiting.