The premiere source of truth powering network automation. Open and extensible, trusted by thousands.

NetBox is now available as a managed cloud solution! Stop worrying about your tooling and get back to building networks.

OSPF filtering: inter-area versus intra-area

By stretch | Wednesday, February 10, 2010 at 4:07 a.m. UTC

There are two points at which OSPF routes can be filtered: within an area, or between areas on an area border router (ABR). This article discusses the differences between the two and the considerations which should be made when implementing OSPF filtering. The following topology is provided for illustration of both cases:

topology1.png

Inter-area Filtering

The 192.0.2.0/24 network has been implemented on R1 for testing. The route is intended only to be propagated throughout the local area, but is currently being advertised to the entire OSPF domain (as indicated by the green arrows in the topology):

R4# show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

O IA 192.168.10.0/24 [110/20] via 192.168.0.3, 00:11:06, FastEthernet0/1
C    192.168.0.0/24 is directly connected, FastEthernet0/1
O IA 192.0.2.0/24 [110/21] via 192.168.0.3, 00:06:33, FastEthernet0/1

We can implement inter-area filtering (filtering between areas) on R3 to prevent the route from being advertised outside of area 10. First, we define a prefix list on R3 to deny the 192.0.2.0/24 prefix and allow all others:

R3(config)# ip prefix-list Deny_Test_Route deny 192.0.2.0/24 le 32
R3(config)# ip prefix-list Deny_Test_Route permit 0.0.0.0/0 le 32

Appending le 32 to the first prefix list entry ensures that any more-specific routes within 192.0.2.0/24 are denied as well (as opposed to only the exact /24 route).

Next we reference it as an area filter within OSPF configuration. The area filter-list statement below tells the router to apply our prefix list to routes being distributed out of area 10. (Don't forget to re-establish neighbor adjacencies afterward so that the new policy takes effect.)

R3(config)# router ospf 1
R3(config-router)# area 10 filter-list prefix Deny_Test_Route out
R3(config-router)# ^Z
R3#clear ip ospf 1 process 
Reset OSPF process? [no]: y

We can verify that R3 is still receiving the 192.0.2.0/24 route from R1, but is not distributing it out of the local area into the backbone (area 0):

R3# show ip route
...
C    192.168.10.0/24 is directly connected, FastEthernet0/0
C    192.168.0.0/24 is directly connected, FastEthernet0/1
O    192.0.2.0/24 [110/11] via 192.168.10.1, 00:03:03, FastEthernet0/0
R4# show ip route
...
O IA 192.168.10.0/24 [110/20] via 192.168.0.3, 00:04:25, FastEthernet0/1
C    192.168.0.0/24 is directly connected, FastEthernet0/1

topology2.png

Intra-area Filtering

Now assume that we need to move the filtering point closer toward the source of the route; specifically, we want to advertise 192.0.2.0/24 from R1 to R2, but not to R3. To accomplish this, we'll need to implement intra-area filtering using the distribute-list command under OSPF configuration.

Intra-area filtering can reference an ACL, prefix list, or route-map; for simplicity's sake, we'll reuse the same prefix-list Deny_Test_Route that was implemented in the prior example. We'll implement inbound filtering on R3 for area 10 since we want to prevent R3 from receiving the route:

R3(config)# router ospf 1
R3(config-router)# distribute-list prefix Deny_Test_Route in
R3(config-router)# ^Z
R3#clear ip ospf 1 process 
Reset OSPF process? [no]: y

Again, don't forget to reset neighbor adjacencies after applying the change.

We can verify that R2 is still receiving the 192.0.2.0/24 route from R1 but R3 is not:

R2# show ip route
C    192.168.10.0/24 is directly connected, FastEthernet0/0
O IA 192.168.0.0/24 [110/20] via 192.168.10.3, 00:00:40, FastEthernet0/0
O    192.0.2.0/24 [110/11] via 192.168.10.1, 00:33:00, FastEthernet0/0
R3# show ip route
C    192.168.10.0/24 is directly connected, FastEthernet0/0
C    192.168.0.0/24 is directly connected, FastEthernet0/1

topology3.png

Note that distribute-lists do not work for outbound OSPF filtering (even though the CLI may accept the command) as OSPF is a link-state protocol and thus all routers within an area must flood all LSAs. Although unidirectional LSA database filtering can be enabled with the database-filter parameter, it is not appropriate in this scenario (and is typically best avoided altogether).

Posted in Routing

Comments


scarface
February 10, 2010 at 8:08 a.m. UTC

So the only solution for outbound route filtering is using OSPF Areas?

I did not know that the command "distribute-list out" does not work on link-state protocols.


Gordon
February 10, 2010 at 9:34 a.m. UTC

The route will still be in the LSA Database, however it will not be installed into the local routing table on R3.

If there was another router hanging of R3 (in the same area). R3 would still share the 192.0.2.0/24 route with it.


Ivan Pepelnjak
February 10, 2010 at 1:44 p.m. UTC

You forgot to mention that intra-area filter really works between OSPF topology database and RIB, creating nice black holes.


Rofi Neron
February 10, 2010 at 2:17 p.m. UTC

I'm working on OSPF for my BSCI exam and this is a great easy to understand explanation. a good example is better than a long book. thanks!


Ysaad
February 10, 2010 at 5:22 p.m. UTC

The out direction works for E1 & E2 routes only for OSPF


Marco Rizzi
February 11, 2010 at 4:15 p.m. UTC

I agree with Ivan, in the second scenario your R4 will have the R3's filtered routes in the ospf database and it will also install it into the RIB, in fact your R3 is "blackholing" the filtered prefix. (try to traceroute/ping the filtered prefix from R4...).

Anyway, ospf filtering is a tricky topic, nice to test it a lot in the lab! keep it up! Marco


LBSources
February 19, 2011 at 6:18 p.m. UTC

@Gordon I actually had other routers in Area 0 with the ABR where I applied the filtering and they did not receive the routes. Is this what you meant by your comment?


cwreece
August 19, 2011 at 12:32 p.m. UTC

This is a late comment, but following up on Ivan's and Marco's comments, with multiple areas, both types of OSPF LSA filters are needed to suppress LSAs - one in bound intra-area, and one outbound inter-area from the ABR. If you forget to implement the inter-area filter at ABR, you will get blackholing when the routes that were filtered from one area's routing tables are including in the Area 0 routing table.

Carole

fwiw, I just wrote up an article on this: http://www.netcraftsmen.net/resources/blogs/filtering-ospf-areas-in-ospf.html/

Comments have closed for this article due to its age.