OSPF Route Filtering

In this article, we are going to learn how to configure OSPF route filtering. We will learn how to do that within an area first then between areas.

Network topology

We will use the following topology. Everything is done in GNS3. I am using the IOS image C3725-ADVENTERPRISEK9-M version 12.4(15)T5 on all the routers.

ospf-route-filtering--2016-01-10 10_33_23
Figure1: network topology

In order to reproduce this topology, I added the base configuration of each router in the bottom of the article. Routers R1, and R2 are in OSPF area 0. R5 is in area 3. R3 and R4 are ABRs and have LSAs from both areas.

ospf-route-filtering--2016-01-10 07_36_58
Figure 2: distinguishing the area border routers in the network topology

Intra-area OSPF route filtering using prefix lists and distribute lists

Intra-area route filtering means that we will manipulate OSPF routes within an area.

This technique prevents a router from installing a particular network prefix into the routing table. Remember that an OSPF router maintains the link state database distinct from the routing table. So all links in the LSDB are not necessarily inserted into the routing table.

We want to prevent R2 from having the prefix getting installed in its routing table. Initially, router R2 has the following routing table:

ospf-route-filtering--2016-01-10 07_06_02

As you can see, it has learned a route to through OSPF. Recall that all routers within an area have the same LSDB. So it is not possible to filter LSAs within an area to prevent other routers to learn about a specific prefix.

The way to do it is to define a prefix list on R2, and apply it to the OSPF process through a distribute list.

Here is a reminder on prefix lists.

Prefix Lists

A prefix list is a control mechanism that has sequence numbers like IOS access lists. It also has both deny and permit statements. Whether it’s a deny or a permit statement, the significance differs from one context to another. In our case, when we apply the prefix list to the OSPF process, a deny statement means “don’t allow this network”, and a permit statement means “allow this network to pass”.

Prefix lists are configured like access lists, one sequence at a time. At the end of each prefix list, there is an implicit “deny any any”.

We’ll call our prefix list no1-OSPF

First, define the prefix list sequences:

ospf-route-filtering--2016-01-10 07_06_25

Line 25 denies the prefix Notice the CIDR notation. Prefix lists use that.

Line 26 is a bit trickier. It means “anything else is allowed”.

Second, we apply the prefix list to OSPF through a distribute list. In fact, you can’t apply the prefix list directly under OSPF. There’s no IOS command to do that:

ospf-route-filtering--2016-01-10 07_06_49

So we configure a distribute list under OSPF, and link a prefix list to it:

ospf-route-filtering--2016-01-10 07_08_19

This line of command tells OSPF to apply the prefix list no1-OSPF when inserting routes in the routing table.

The prefix is not inserted in the routing table. The other prefixes are still there:

ospf-route-filtering--2016-01-10 07_09_59

What about the other routers? do they filter the prefix? No, the filter applies only to R2. This type of filtering occurs on a per-router basis. So if you had five other routers in the same OSPF area and you want all of them to not install the prefix, you need to do what you already did with R2, on all five routers.

The ABRs also still insert the prefix in their routing tables, since they have the LSA in the LSDB:

ospf-route-filtering--2016-01-10 07_10_39

What if we want to filter the prefix from going out to the world, with distribute-list prefix … out ? That’s correct from an IOS standpoint. I mean the router IOS won’t stop you if you enter “distribute-list prefix {Prefix-list-name} out” command. But conceptually speaking, that’s not possible if we are doing it on a normal router (neither ABR nor ASBR), because all routers within an area have the same LSAs and the same LSDB. So it would be a contradiction to filter LSAs in the outbound direction while having a unique LSDB per area.

Inter-area OSPF route filtering using area filters

Inter-area route filtering means that we filter routes as they enter or leave an area.

If the route we want to filter comes from a different area, then it is possible to filter it and see the changes on all routers of the local area. This is done with area filters.

An area filter filters out LSA type 3 from exiting or entering an area. It is configured at the ABR only, because it is the ABR that generates the LSA type 3.

By the way, area filters use prefix lists too.

Preventing inbound LSA type 3 from entering area 3

First, please don’t confuse LSA type 3 and area 3. The LSA type to be filtered is LSA type 3, no matter what the area number is.

To understand how this works, we will define and apply an area filter at R3 and R4, to prevent R5 router from learning the prefix.

Configuration on R3

We make sure first that R3 has the prefix in its routing table:

ospf-route-filtering--2016-01-10 07_44_30

Define the prefix list on R3 (because it is an ABR):

ospf-route-filtering--2016-01-10 07_42_24

Link the prefix list to the area filter and apply the area filter to area 3, in the indirection:

ospf-route-filtering--2016-01-10 07_43_30

Configuration on R4

Now on R4. We’ll do the same thing as with R3.

Define the prefix list:

ospf-route-filtering--2016-01-10 07_45_36

We link the prefix list to the area filter, and apply the area filter to the OSPF area:

ospf-route-filtering--2016-01-10 07_46_36

Now check the routing table on R5:

ospf-route-filtering--2016-01-10 07_47_12

The prefix no longer exists in the routing table.

Let’s check the link state database of R5:

ospf-route-filtering--2016-01-10 07_48_17

the LSA for is missing. Yes, it has been filtered out at the ABR level. Good job!

You may have asked “why configure area filtering on both R3 and R4?” That’s because :

  • they are Area Border Routers, and inter-area LSA filtering occurs only on Area Border Routers,
  • if the configuration is missing on one router, it will advertise LSA type 3 to R5.

If we had not configured area filtering on R4 for example, R5 would have learned about the LSA from R4, installed it in its LSDB and in its routing table:

ospf-route-filtering--2016-01-10 07_52_22

ospf-route-filtering--2016-01-10 07_51_54

ospf-route-filtering--2016-01-10 07_52_59

Preventing outbound LSA type 3 from exiting area 3

We’ll configure area filters, but this time we will prevent the prefix from exiting area 3 and entering the backbone area.

R2 is in area 0 and is learning about the prefix as an inter-area route:

ospf-route-filtering--2016-01-10 07_56_18

Configuration on R3

Let’s configure area filtering at router R3:

ospf-route-filtering--2016-01-10 08_02_40

and apply the area filter under OSPF, in the “out” direction:

ospf-route-filtering--2016-01-10 08_03_39

Configuration on R4

We do the same thing for R4:

ospf-route-filtering--2016-01-10 08_04_40

and check the link state database on R2:

ospf-route-filtering--2016-01-10 08_05_37

The prefix is missing from the link state. So it won’t be installed in the routing table:

ospf-route-filtering--2016-01-10 08_06_07

Filtering routes that originally were redistributed into OSPF, using access lists and distribute lists

Filtering redistributed connected subnets

What if we want to filter a route that originally entered the OSPF domain as part of a redistribution process? In the previous topology, let’s assume that R2 is redistributing the prefixes of its connected loopback interfaces into OSPF, among which is the prefix of loopback 1 interface:

ospf-route-filtering--2016-01-10 11_02_34

ospf-route-filtering--2016-01-10 10_48_05

Since R2 is redistributing connected subnets into OSPF, and R2 being in a non NSSA area (otherwise it would have injected LSA7), it sends LSA type 5 to its OSPF neighbors. And that’s exactly how router R1 sees them in his link state database; type 5 LSAs:

ospf-route-filtering--2016-01-10 11_09_13

An LSA type 5 gives an OSPF route of type External-2 (O E2). That’s confirmed in R1’s routing table. Recall that by default, redistributed routes into OSPF have the type External 2 and have the cost of 20 (except for BGP):

ospf-route-filtering--2016-01-10 11_07_15

But, imagine that R5 must not see the network prefix for some reason.

ospf-route-filtering--2016-01-10 11_10_20

So we need to filter prefix and leave the rest of the redistributed prefixes propagate in OSPF. This is done with access lists combined with distribute lists. Filtering must occur at the Autonomous System Border Router (ASBR). In our case, R2 is an ASBR because it borders two autonomous systems: OSPF and the local interfaces.

First, configure a standard access list that does the following:

  • deny the network prefix
  • permit all the rest

ospf-route-filtering--2016-01-10 11_16_08

Second, link the access list to a distribute list function, under the OSPF process:

ospf-route-filtering--2016-01-10 11_17_48

We use distribute-list … out because we’re controlling what’s going out to the world of OSPF, during redistribution. Also, we did not say distribute-list … out connected because that’s what IOS assumes by default.

This way, R2 will propagate all prefixes as LSA type 5 except the prefix. It won’t send anything about it out to the OSPF world. And that shows in R1 and R5 link state databases:

ospf-route-filtering--2016-01-10 11_20_40

ospf-route-filtering--2016-01-10 11_22_22

and in their routing tables:

ospf-route-filtering--2016-01-10 11_25_56

ospf-route-filtering--2016-01-10 11_26_32

What we just did is, redistribute connected subnets on one router, and filter one specific prefix from being learned into OSPF.

Filtering redistributed static routes

The same mechanism can be applied for redistributed static routes, using access lists and distribute lists.

Let’s suppose we have a couple of static routes on R2 that we redistribute into OSPF:

ospf-route-filtering--2016-01-10 17_09_22

ospf-route-filtering--2016-01-10 17_10_15

This command will redistribute all static subnets into OSPF. All routers in the autonomous system will learn them as OSPF type 2 routes. For example, here’s R1’s routing table:

ospf-route-filtering--2016-01-10 17_11_23

We want to:

  • allow prefix to be redistributed into OSPF,
  • filter all other redistributed prefixes.

This is done at the ASBR, which is R2. On R2, we create an access-list that fulfills the two bullet points above:

ospf-route-filtering--2016-01-10 17_14_53

Note that the permitted/denied subnet in the ACL must match the prefix in the static route. Since the prefix we are allowing is a /8 prefix, then the permitted access list entry must be a /8 subnet.

There is an explicit “deny” at the end of the ACL.

Then we link the access-list to a distribute list that we apply to OSPF:

ospf-route-filtering--2016-01-10 17_16_32

What we get is that all routers in the autonomous system no longer receive information about any redistributed prefixes other than from R2:

ospf-route-filtering--2016-01-10 17_21_28

[box type=”note” align=”aligncenter” ] A note on distribute lists: We saw two examples of using distribute lists for OSPF route filtering: with connected subnets and with static subnets. Distribute lists can be used with other routing protocols such as BGP, OSPF, RIP and EIGRP; we can control which routes are redistributed from one protocol into another at the ASBR level.

ospf-route-filtering--2016-01-10 17_24_43

OSPF route filtering configuration files

Here is the base IOS configuration of all routers. You can use these files to reproduce the topology in GNS3.


We learned in this article:

  • how to filter routes within an area, on one router, using a combination of prefix lists and distribute lists. This concept is local,
  • how to filter specific inter-area routes, inbound and outbound, using a combination of prefix lists and area filters. This concept is valid on the ABR only,
  • how to filter specific redistributed routes from being injected into OSPF, using a combination of access lists and distribute lists. This concept is valid on the ASBR only,

Filtering inbound and outbound routes is a matter of filtering some types of LSAs. And it can be done only on ABRs and ASBRs. Filtering LSAs from entering the routing table on the local router is however possible on any router.

Be First to Comment

Leave a Reply

Your email address will not be published. Required fields are marked *