OSPF is one of the most popular routing protocols around. As a link state protocol however, when it comes to route filtering, it has some quirks that should be considered when deploying it. Unlike its distant cousins EIGRP and RIP, OSPF routes can only be filtered at the border of an OSPF area.

In this article, we’ll dig deeper into this somewhat limiting behavior to see why, by design, this is the case. We’ll also examine ways in which we can still achieve the “filtering” requirements needed using a nifty workaround.
OSPF Design
The limitation of route filtering that OSPF exhibits is due to its design. In order to understand this, let’s briefly review how OSPF works. For a more detailed configuration of OSPF, take a look at our article on the topic.
Link State Advertisements
OSPF routers share their routing information with other OSPF routers via what are known as Link State Advertisements, or LSAs.
These are data packets that contain information about the state of all links in the network. LSAs are exchanged between OSPF routers to ensure they all have a consistent view of the network topology, which is used to calculate the shortest paths.
There are different types of LSAs that are defined by how they are generated, and the type of information they carry.
Link-state routing protocol
EIGRP and RIP are distance vector routing protocols, and as such, they maintain only a partial map of the whole network topology.
In contrast, OSPF is a link state routing protocol, and by definition, an OSPF router must learn about the whole network topology, and must maintain a complete map of the network.
All OSPF routers must maintain the same OSPF map, otherwise the protocol will not operate correctly. In an OSPF router, this map is maintained within the Link State Database or LSDB.
Hierarchical design
As an OSPF topology becomes larger, so do the contents of the LSAs that are exchanged. In order to limit the size of LSAs, and to limit their propagation within a topology, OSPF is hierarchical by design.
This hierarchy is primarily demonstrated in the rules governing OSPF areas. Areas can be created within an OSPF topology to improve scalability, and to maintain greater control over the propagation of OSPF routes, especially throughout larger networks.
Now the requirement of all OSPF routers in a topology to maintain the same “map” of the network is only confined to a particular area.
OSPF routers don’t need to maintain this map of areas other than their own. To understand this further, take look at this topology:

Routers in Area 1 are required only to have a full map of the routes found within Area 1. Similarly, those in Areas 0, 2, and 3. Any information that comes from other areas does not need to be known.
The only information that routers in Area 1 may receive about routes in other areas comes from the Area Border Router or ABR. And we can configure the ABR to deliver only the information we choose about the rest of the network, thus making the distribution of routes throughout the topology more efficient.
OSPF – Filtering Routes
So based on the above information, you can see that by its very design, routes that are exchanged between OSPF routers within an area cannot be filtered. If you were to be able to do this, then the routers within an area would not be able to maintain the LSDB of the network.
Filtering, however, can take place at the ABR, and indeed it is best practice to do so. By default, if you don’t configure any filtering, then all the routes from a neighboring OSPF area will explicitly appear in the OSPF database of routers within an area.
But filtering at the ABR is still not as intuitive as it sounds.
Configuring the ABR
There are various mechanisms that can be used at the ABR to alleviate excessive and often unnecessary information from being disseminated from one area to another. Although these are not strictly filtering, they do affect what information is injected into a particular area.
These include:
- Creating stub networks – OSPF areas can be configured as various types of stub networks which only allow certain types of LSAs to enter those areas, while disallowing others. In a stub area network, the ABR will play the role of the default route, since it is typically the only exit point to other networks.
- Summarization – Instead of advertising all of the individual routes that exist in one area into another, it is possible to configure summarization at the ABR. This way, multiple routes can be represented by a single summarized route, making LSAs much smaller.
Filtering at the ABR
True filtering for OSPF takes place at the ABR. Unlike with EIGRP where you filter specific routes, in OSPF you filter specific LSAs.
And as mentioned before, this filtering can only be applied at the ABR. At the ABR, it is possible to filter Type 3 and Type 5 LSAs. Thus, you cannot filter routes between OSPF routers in the same area.
Filtering Routes within an area?
Now having said all of this, there is a “workaround” that can be used to remove a particular network from a specific OSPF router. Now remember, OSPF requires that the internal “map” of the network that is maintained by OSPF routers, that is the LSDB, be the same for all routers within an area.
The workaround involves blocking a particular route from being installed in the routing table. So, you can still have the route within the OSPF LSDB, but you can disallow it from being installed in the routing table, thus making it seem as if that router did not learn about that network destination.
This can be achieved by using what is known as distribute-list filtering. Here is an example of how this can be configured.
Distribution List Filtering Example:
Take a look at this network topology:

Let’s assume that OSPF has been configured on R1 and R2, and that the 10.10.10.0/24 network is being advertised by R1 to R2. The routing table on R2 should look something like this:
R2#show ip route ospf
O 192.168.1.0/24 [110/2] via 192.168.12.1, 00:00:27, FastEthernet0/0
In order to remove this entry from the routing table, we can use the following commands:
Let’s start by creating an access list to match our route:
R2(config)#ip access-list standard my_acl
R2(config-std-nacl)#deny ip 192.168.1.0 0.0.0.255
R2(config-std-nacl)#permit any
Next, we can apply the ACL using a distribute list in an inward direction like so:
R2(config)#router ospf 1
R2(config-router)#distribute-list my_acl in
Note that when we want to disallow something from entering the routing table, we must apply it inbound. The outbound distribute-list is used for LSA type 5 filtering.
If we look at R2’s routing table, the route should be gone:
R2#show ip route 192.168.1.0
% Network not in table
At this point, the route may not be in the routing table, but it is still in the OSPF LSDB, thus fulfilling the requirement of OSPF routers in the same area maintaining the same network map.
Conclusion
OSPF is a very powerful and scalable routing protocol, but it can get difficult to configure sometimes because it is not always intuitive.
Understanding LSA filtering at the ABRs and distribute-list filtering at individual OSPF routers will help you to fine tune your OSPF topology to fulfil your network requirements.