NSSA External

OSPF Filtering with Summarization

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).

OSPF-FILTERING-2-01

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:

OSPF-FILTERING-2-02

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:

OSPF-FILTERING-2-03

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:

OSPF-FILTERING-2-04

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.

OSPF-FILTERING-2-05

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.

OSPF-FILTERING-2-06

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

OSPF-FILTERING-2-07

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.”

OSPF-FILTERING-2-08

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
!

OSPF-FILTERING-2-09

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:

OSPF-FILTERING-2-10

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:

OSPF-FILTERING-2-11

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

OSPF-FILTERING-2-12

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:

OSPF-FILTERING-2-13

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.

OSPF-FILTERING-2-14

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.)

OSPF-FILTERING-2-15

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

OSPF-FILTERING-2-16

OSPF-FILTERING-2-17

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.

OSPF Filtering (LSA Type-3 & NSSA External)

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

OSPF is a Link-State protocol; hence, we can foresee that filtering is a little more difficult to perform than with any other IGP.   The reason is that link-state protocols do not advertise routes per se, they advertise topology information.   We have to keep in mind that routers in the same area have or share an identical copy of the Link-State Database (LSDB) for that particular area, this implies that OSPF filtering can only be applied at certain points of the network, being these the ABRs or ASBRs.

OSPF route filtering types:

In Cisco OSPF implementation there are three major types of OSPF filtering:

  • LSA Type-3 Filtering: This type of filtering prevents the ABR from creating particular Type-3 summary LSAs.
  • NSSA External Routes Filtering: This type of filtering prevents the P-bit (Propagate Bit) being imposed to the Type-7 LSAs, thus the Type-7 to Type-5 translation does not take place in the ABR.
  • Filtering with Summarization: This type of filtering work in conjunction with OSPF summarization, adding the not-advertise keyword.

Now, there are some cases when we can apply filtering to the router’s routing table itself, preventing routes learned from the OSPF RIB to be installed into the global RIB.  This scenario, in particular, may result into traffic blackholing because it doesn’t filter the LSA, only the route.

The OSPF RIB filtering can be applied anywhere.

LSA Type-3 Filtering

This type of filtering allows ABRs to filter Type-3 LSAs.   Remember, the ABRs do not forward Type-1 or Type-2 LSAs; instead, they create Type-3 LSAs with the values corresponding to the subnets and the cost from the ABR to these subnets.  This feature filter the type-3 LSA before is injected into another area.  Thus, the requirement of identical LSDB within the area is still met.

To configure LSA Type-3 filtering, use the area {area-source} filter-list prefix {prefix-list-name} in|out OSPF process command.   Worth mentioning that when filtering routes into the backbone area (Area 0) will filter the advertisement within all areas in the routing domain while filtering into a non-backbone area will filter the advertisement of routes only within the targeted area.

Let’s use the same topology we have been using so far but with a few changes for the examples:

OSPF-FILTERING-01

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

Among the changes done with respect to the topology used in the previous post, I can mention the advertisement of networks in R1, R4, R5 and R7 using sub-interfaces instead loopbacks, all routers have loopback0 configured (Not shown in the diagram). Another change is the renumbering of the transit networks and the renumbering of Area 20 to Area 40 only as Stub.

Let’s take a look to the routing table from the perspective of R1:

OSPF-FILTERING-02

As can be seen in the above output, R1 is routing the eastbound traffic towards the networks in R5 and R7 through R2 and R3 (load-balancing).    The routes are being advertised as “O IA” or OSPF inter-area, meaning advertised from the ABRs as Type-3 LSAs.

OSPF-FILTERING-03

Let’s apply LSA Type-3 filtering to these routes.

Goal 1:

Eastbound traffic from R1 destined to the networks 10.5.0.0/20 in R5 must be advertised only from R3 and the networks 10.7.0.0/20 in R7 must be only advertised only from R2.

OSPF-FILTERING-04

To have a clear vision of how it works, I will describe the advertisement process.

The source of the routes to be filtered passes from Area 40 through R4 (ABR) which has OSPF summarization configured.  R4 which has the interface E0/0 into Area 40 summarize the Type-1 LSAs received from R5 and R7 and generate two Type-3 summary LSA for the summary routes (10.5.0.0/20 and 10.7.0.0/20), R4 set itself as the advertising router for the summary LSAs in Area Zero (Backbone Area) and set the cost to reach the networks. Then this Type-3 LSAs are flooded within the area.

Next, R2 and R3 which are also ABRs generates and flood their own Type-3 LSAs for Area 30, setting themselves as the advertising router for both summary routes and adding the cost advertised from R4 to the cost from each ABR to R4.

From the perspective of R1, the Type-3 LSAs were advertised from R2 and R3 respectively and the AREA SOURCE of the advertisements is Area 0.      This means the prefix-list to be used to filter the LSAs must go out of area zero (outbound).

So, for the first part: Traffic destined to 10.5.0.0/20 through R3, let’s apply filtering in R2 denying the summary 10.5.0.0/20 in the outbound direction from Area 0.

Let’s take a look to the Summary LSAs of 10.5.0.0/20 from R1’s perspective before applying the change:

OSPF-FILTERING-05

As can be seen in the above output, we have two summary LSAs in R1 (Area 30) corresponding to the summary network 10.5.0.0/20, one LSA advertising the network from R2 (ABR), and the other from R3 (ABR) with identical cost (metric),  thus the network is load-balanced between both ABRs.   We had already established this; you may wonder why are we seeing this again?

The answer is:   To show you the effect of apply Type-3 LSA filtering in the LSDB.

Ok, let’s apply the following change in R2:

In R2 (ABR):

!
ip prefix-list Filter-Net-10-5 seq  5 deny 10.5.0.0/20
ip prefix-list Filter-Net-10-5 seq 10 permit 0.0.0.0/0 le 32
!
router ospf 1
area 0 filter-list prefix Filter-Net-10-5 out
exit
!

Let me explain the filter:

  1. The prefix-list Filter-Net-10-5 sequence 5 will deny the specific subnet 10.5.0.0/20
  2. The prefix-list Filter-Net-10-5 sequence 10 will permit any other subnet. The syntax 0.0.0.0/0 matches any network and the le (less-or-equal) set the range of subnets lower or equal to /32.   This is the equivalent to permit any.    It is important to remember at the end of prefix-lists, access-lists or even route-maps there is an implicit deny.   Therefore without this particular entry, all subnets will be denied by default.
  3. The OSPF process command area 0 filter-list prefix Filter-Net-10-5 out, set the filter for traffic sourced from Area 0 which match the prefix-list Filter-Net-10-5 in the outbound direction.

Let’s take a look to the Summary LSAs of 10.5.0.0/20 in R1 after we applied the change:

OSPF-FILTERING-06

As can be seen in the above output, now the LSA advertised from R2 (ABR) has the delete flag set.   The LS age was changed in R2 to 3600 seconds which is the max age and the metric also was set to the max-metric for routes in the OSPF in decimal.  This is also known as LSInfinity.  Remember: When the max age timer on an LSA reaches 60 minutes, the LSA will be discarded.

Let’s take a look to the routing table in R1:

OSPF-FILTERING-07

As can be seen in the output, now eastbound traffic towards R5 is following the desired path.  We still have pending the rest of the goal.    To force the traffic from R1 to R7 through R2, we have to make basically the same change, but in R3 (ABR).

So, let’s do it.

In R3 (ABR):

!
ip prefix-list Filter-Net-10-7 seq  5 deny 10.7.0.0/20
ip prefix-list Filter-Net-10-7 seq 10 permit 0.0.0.0/0 le 32
!
router ospf 1
area 0 filter-list prefix Filter-Net-10-7 out
exit
!

Again, let’s take a look to the routing table in R1:

OSPF-FILTERING-08

Ok, as can be seen in the above output, now the eastbound traffic towards R7 is following the desired path.   With this last change, the goal 1 was achieved.

Let’s move on to the next type of filtering.

NSSA External Route Filtering

This type of filtering is applied in ASBRs.   What it does is preventing the P-bit or Propagate-Bit being imposed to the Type-7 LSAs.    Let’s recall a little bit.    NSSA generate Type-7 LSAs to advertise external routes to the ABR.  The ABR then translate the Type-7 LSAs into Type-5 LSAs.    For the translation takes place, the ABR check every Type-7 LSA looking for the P-bit (Propagate-Bit), which is imposed by default in NSSA when redistributing in ASBRs.    Now, if the P-bit is not set, then the translation does not take place.    Remember, the flooding scope of Type-7 LSAs is NSSA areas only.

We can apply this filter to the redistribution itself with the keyword nssa-only at the redistribution OSPF process command.

I will not explain mutual redistribution in this post; however I want to show you the effect on the LSDB when applying the filtering into the redistribution in OSPF.

Let’s apply NSSA external route filtering to the routes coming from the EIGRP domain.

Goal 2:

Filter the routes coming from the EIGRP domain in such way the routes will only be accessible from Area 30.

To achieve this goal, first, I would make a small change required for this requirement.   I will remove the summarization in R1.    The reason to do this is because when using summarization in conjunction with filtering applied to the redistribution process, the summarization will override the P-bit suppression.   The summarized Type-7 LSA will be generated by the ASBR with the P-bit set.

So, let’s remove the summarization and check the NSSA external database in R1.

In R1 (ASBR):

!
router ospf 1
no summary-address 172.16.0.0 255.255.0.0
!

OSPF-FILTERING-09

OSPF-FILTERING-10

As can be seen in the above outputs, now the LSDB has individual Type-7 LSAs per network redistributed from the EIGRP domain with the P-bit set.   The direct result of this change is that the elected Type-5/Type-7 translator (R3 ABR in this case) will generate Type-5 LSAs for each Type-7 LSA advertised by R1 and will flood them to the Backbone area, and from there to the other areas as shown in the next output from R4.   This is an expected behavior.

OSPF-FILTERING-11

Now, let’s apply the NSSA external filtering adding the keyword nssa-only at the redistribution OSPF process command and observe the changes in the LSAs.

In R1 (ASBR):

!
router ospf 1
redistribute eigrp 100 subnets nssa-only
!

OSPF-FILTERING-12

As can be seen in the above output, now the LSAs were generated without the P-bit.    This will prevent the translation from Type-7 to Type-5 LSAs in the ABR.   The direct result will be that the EIGRP domain will be reachable only from Area 30.

Let’s take a look to the routing table in R4 for example.

OSPF-FILTERING-13

As can be seen, the routes for the EIGRP domain are not present therefore they are unreachable.

What about from routers in Area 30?   Let’s take a look to the routing table in R2 for example:

OSPF-FILTERING-14

The routes are there.     In the case of R2 and R3, they are ABRs; therefore, they have an interface connecting to the NSSA area.   Both ABRs have an LSDB for Area 0 and Area 30 respectively.  Note the routes are represented as “O N2” or OSPF NSSA external routes (Type-7 LSAs) instead “O E2” or OSPF external routes (Type-5 LSAs).   This means that if we had more routers only in Area 30, they will have reachability to the EIGRP domain via OSPF as “O N2” OSPF NSSA external routes.

It is time to close this long post.  In the next one, we will continue discussing OSPF filtering with summarization and other filtering options out there.

Thank you for visiting.