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:
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
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
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
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
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.
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.
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.
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!
February 10, 2010 at 5:22 p.m. UTC
The out direction works for E1 & E2 routes only for OSPF
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
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?
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.
fwiw, I just wrote up an article on this: http://www.netcraftsmen.net/resources/blogs/filtering-ospf-areas-in-ospf.html/