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