Like EIGRP, OSPF also supports distribute lists. However, as will be described in the following section, distribute lists do not operate in the same manner when used in conjunction with OSPF as they would when used in conjunction with EIGRP. In addition to distribute lists, OSPF also supports additional route filtering tools that are unique to the protocol. These different tools are also described in detail in the following sections.
Filtering OSPF Routes Using Distribute Lists
The same options available with EIGRP are also supported when configuring OSPF distribute lists. Following is the list of supported keywords for the distribute-list command:
| R2(config)#router ospf 2 R2(config-router)#distribute-list ? <1-199> IP access list number <1300-2699> IP expanded access list number WORD Access-list name gateway Filtering incoming updates based on gateway prefix Filter prefixes in routing updates route-map Filter prefixes based on the route-map |
OSPF is a Link State routing protocol. OSPF routers build their LSDBs based on LSAs flooded into the area by other routers. This same information is ultimately used to build the SPF Tree. For this reason, outbound distribute lists are not permitted by the CLI when using OSPF as the routing protocol. Although outbound distribute lists are not supported, OSPF does support inbound distribute lists. As is the case with EIGRP, inbound OSPF distribute lists can be used in conjunction with ACLs, prefix lists, route-maps, and can also filter prefixes based on the specified gateway (router).
When filtering inbound prefixes, route maps provide the most flexibility. Route maps are used to filter inbound prefixes and can be configured to match prefixes using the following:
- Based on Route Tag
- Based on Next-Hop
- Based on Interface
- Based on Route Source
- Based on Route Type
- Based on Prefix List
- Based on Access List
A route tag can be assigned to a group of external prefixes during redistribution into OSPF. The distribute list can then be used in conjunction with a route map to filter prefixes based on the route tag. The following example shows how to configure a distribute list that permits only the routes that have been assigned the route tag 888:
| R1(config)#route-map MATCH-TAG permit 10 R1(config-route-map)#match tag 888 R1(config-route-map)#exit R1(config)#router ospf 1 R1(config-router)#distribute-list route-map MATCH-TAG in R1(config-router)#exit |
Route maps can be used to match on the next hop interface, which represents the next IP hop for the route that OSPF is attempting to install into the routing table. The following configuration example illustrates how to filter inbound prefixes and allow only those prefixes with next hop IP address of 150.1.1.1 to be installed into the routing table:
| R1(config)#access-list 5 permit 150.1.1.1 R1(config)#route-map MATCH-NEXT-HOP permit 10 R1(config-route-map)#match ip next-hop 5 R1(config-route-map)#exit R1(config)#router ospf 1 R1(config-router)#distribute-list route-map MATCH-NEXT-HOP in |
Interface matching is based on the outgoing interface for the route that OSPF is attempting to install into the routing table, i.e. the interface towards the destination network. The following example illustrates how to filter inbound prefixes whose outgoing interface is Serial0/0. This configuration effectively filters all routes received via Serial0/0:
| R1(config-router)#route-map FROM-INTERFACE-SERIAL-0/0 deny 10 R1(config-route-map)#match interface serial 0/0 R1(config-route-map)#exit R1(config)#router ospf 1 R1(config-router)#distribute-list route-map FROM-INTERFACE-SERIAL-0/0 in R1(config-router)#exit |
A route map can also be used to filter routes based on the route source. The route source is the OSPF router ID of the LSA originator for the specified prefix(es). The following example illustrates how to filter all of the routes that were advertised by a router with the RID 1.1.1.1:
| R2(config)#ip prefix-list R1-RID seq 5 permit 1.1.1.1/32 R2(config)#route-map R1-FILTER deny 10 R2(config-route-map)#match ip route-source prefix-list R1-RID R2(config-route-map)#exit R2(config)#router ospf 1 R2(config-router)#distribute-list route-map R1-FILTER in |
The route type can also be used for route filtering when distribute lists are used in conjunction with route maps. Route maps can be used to match internal (intra-area and inter-area) routes and external (Type 1, Type 2, and NSSA External) routes. The following configuration illustrates how to configure the router to deny all Type 1 and Type 2 external routes but allow all others:
| R2(config)#route-map EXTERNAL-ROUTES deny 10 R2(config-route-map)#match route-type external type-1 external type-2 R2(config-route-map)#exit R2(config)#route-map EXTERNAL-ROUTES permit 20 R2(config-route-map)#exit R2(config)#router ospf 2 R2(config-router)#distribute-list route-map EXTERNAL-ROUTES in R2(config-router)#exit |
NOTE: Because the second route map statement has no match clauses, it matches everything. In addition to this, because it is a permit statement, it allows all other routes.
Route maps can also filter based on matched prefix lists and ACLs. A prefix list is matched in a route map using the match ip address prefix [name] route map configuration command, while an ACL is matched using the match ip address [name | number] route map configuration command. The configuration of prefix lists and ACLs was illustrated in previous configuration examples.
It is important to remember that when filtering inbound prefixes, the denied (filtered) prefixes are not installed into the routing table; however, the LSAs for those prefixes will continue to exist in the Link State Database. In other words, inbound filtering with the distribute lists filters only the actual prefix itself and not the specific LSA. To both demonstrate and reinforce this statement, we will reference the OSPF network illustrated in Figure 4-4:
Fig. 4-4. OSPF Distribute List Filtering
Figure 4-4 illustrates a basic OSPF network. R1 and R2 are both ABRs and are connected to the backbone and areas 5 and 1, respectively. R1 is advertising the 192.168 prefixes via OSPF. Assuming basic OSPF configuration, the routing table on R2 shows the following route entries:
| R2#show ip route ospf O 192.168.4.0/24 [110/2] via 150.254.1.1, 00:04:43, FastEthernet0/0 O 192.168.0.0/24 [110/2] via 150.254.1.1, 00:04:43, FastEthernet0/0 O 192.168.1.0/24 [110/2] via 150.254.1.1, 00:04:43, FastEthernet0/0 O 192.168.2.0/24 [110/2] via 150.254.1.1, 00:04:43, FastEthernet0/0 O 192.168.3.0/24 [110/2] via 150.254.1.1, 00:04:43, FastEthernet0/0 |
As an example, assume we wanted to filter odd subnets, i.e. 192.168.1.0/24 and 192.168.3.0/24, the following configuration would be implemented on R2:
| R2(config)#ip access-list standard FILTER-ODD-SUBNETS R2(config-std-nacl)#deny 0.0.1.0 255.255.254.255 R2(config-std-nacl)#permit any R2(config-std-nacl)#exit R2(config)#router ospf 2 R2(config-router)# distribute-list FILTER-ODD-SUBNETS in fastethernet 0/0 R2(config-router)#exit |
Based on this distribute list configuration, the routing table on R2 shows the following entries:
| R2#show ip route ospf O IA 192.168.4.0/24 [110/2] via 150.254.1.1, 00:00:41, FastEthernet0/0 O IA 192.168.0.0/24 [110/2] via 150.254.1.1, 00:00:41, FastEthernet0/0 O IA 192.168.2.0/24 [110/2] via 150.254.1.1, 00:00:41, FastEthernet0/0 |
As was stated earlier, although the odd prefixes have been filtered from the routing table, it is important to remember that the Type 3 LSAs for these prefixes are not filtered by the inbound distribute list. This can be validated by looking at the LSDB on R2 as follows:
| R2#show ip ospf databaseOSPF Router with ID (2.2.2.2) (Process ID 2)Router Link States (Area 0)
Link ID ADV Router Age Seq# Checksum Link count Summary Net Link States (Area 0) Link ID ADV Router Age Seq# Checksum Router Link States (Area 1) Link ID ADV Router Age Seq# Checksum Link count Summary Net Link States (Area 1) Link ID ADV Router Age Seq# Checksum |
Referencing the output above, although the prefixes have been filtered on R2, R1 will still flood LSAs for the 192.168.1.0/24 and 192.168.3.0/24 networks into area 1. Because of the fact that the LSAs have been flooded into area 1, R3 still shows them in both its LSDB and routing table. The routing table on R3 shows the following entries:
| R3#show ip route ospf O IA 192.168.4.0/24 [110/66] via 10.99.99.2, 00:12:31, Serial0/0 O IA 192.168.0.0/24 [110/66] via 10.99.99.2, 00:12:31, Serial0/0 O IA 192.168.1.0/24 [110/66] via 10.99.99.2, 00:12:35, Serial0/0 O IA 192.168.2.0/24 [110/66] via 10.99.99.2, 00:12:31, Serial0/0 150.254.0.0/24 is subnetted, 1 subnets O IA 150.254.1.0 [110/65] via 10.99.99.2, 00:25:31, Serial0/0 O IA 192.168.3.0/24 [110/66] via 10.99.99.2, 00:12:36, Serial0/0 |
This is misleading because it appears that R3 is able to reach the odd subnets even though they have been filtered on R2. However, confirmation that the subnets are actually not reachable is given by executing a simple ping to one of the subnet addresses as illustrated below:
| R3#ping 192.168.1.1Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds: U.U.U Success rate is 0 percent (0/5) |
Filtering Type 3 LSAs at the Area Border Router
Continuing with the previous example, the use of distribute lists presents a dilemma in that while the prefixes are filtered, the ABR still floods Summary LSAs to adjacent areas. Fortunately, in Cisco IOS software, the area [area ID] filter-list prefix [prefix-list-name][in | out] router configuration command can be used on the ABR to filter prefixes advertised in Network Summary LSAs between OSPF areas.
When applied inbound, the prefix list is applied to prefixes advertised to the specified area from other areas. When applied outbound, the prefix list is applied to prefixes advertised out of the specified area to other areas. Referencing the topology in Figure 4-4, R2, the ABR, can be configured to filter Type 3 LSAs for the odd subnets from the backbone from being advertised to other areas by applying the following configuration on the router:
| R2(config)#ip prefix-list DENY-ODD-ONLY seq 5 deny 192.168.1.0/24 R2(config)#ip prefix-list DENY-ODD-ONLY seq 7 deny 192.168.3.0/24 R2(config)#ip prefix-list DENY-ODD-ONLY seq 9 permit 0.0.0.0/0 le 32 R2(config)#router ospf 2 R2(config-router)#area 0 filter-list prefix DENY-ODD-ONLY out R2(config-router)#exit |
This configuration can be validated using the show ip ospf command as illustrated below:
| R2#show ip ospf 2 | section Area Area BACKBONE(0) Area has no authentication Area ranges are Area-filter DENY-ODD-ONLY out Area 1 Area has no authentication Area ranges are |
It is important to remember that unlike distribute lists, the area…filter-list command does not filter the prefixes R2 receives from R1 as can be seen in the following output:
| R2#show ip route ospf O 192.168.4.0/24 [110/2] via 150.254.1.1, 00:10:08, FastEthernet0/0 O 192.168.0.0/24 [110/2] via 150.254.1.1, 00:10:08, FastEthernet0/0 O 192.168.1.0/24 [110/2] via 150.254.1.1, 00:10:08, FastEthernet0/0 O 192.168.2.0/24 [110/2] via 150.254.1.1, 00:10:08, FastEthernet0/0 O 192.168.3.0/24 [110/2] via 150.254.1.1, 00:10:08, FastEthernet0/0 |
Instead, all the command does is that it prevents the ABR, which is R2, from flooding Summary LSAs for the prefixes that are filtered to other areas. This means that all Type 3 LSAs that are advertised by R2, based on information from area 0, are filtered by the prefix list before they are flooded to adjacent areas. R2 will therefore not flood Type 3 LSAs for the 192.168.1.0/24 and 192.168.3.0/24 prefixes to area 1 as can be seen in the LSDB on R2:
| R2#show ip ospf database | begin Area 1 Router Link States (Area 1)Link ID ADV Router Age Seq# Checksum Link count 2.2.2.2 2.2.2.2 579 0x8000000F 0x00E3F1 2 3.3.3.3 3.3.3.3 1099 0x80000008 0x008E4A 2 Summary Net Link States (Area 1) Link ID ADV Router Age Seq# Checksum |
Because the Type 3 LSAs are not flooded to area 1, R3 will not receive these LSAs and they will not be stored in the LSDB as illustrated in the following output:
| R3#show ip ospf database | begin Summary Summary Net Link States (Area 1)Link ID ADV Router Age Seq# Checksum 150.254.1.0 2.2.2.2 1093 0x80000003 0x00AEEC 192.168.0.0 2.2.2.2 1093 0x80000003 0x00AB1C 192.168.2.0 2.2.2.2 1093 0x80000003 0x009530 192.168.4.0 2.2.2.2 1093 0x80000003 0x007F44 |
And finally, because the LSAs are not in the LSBD, they will also not be in the routing table on R3. This too is validated in the following output:
| R3#show ip route ospf O IA 192.168.4.0/24 [110/66] via 10.99.99.2, 00:19:03, Serial0/0 O IA 192.168.0.0/24 [110/66] via 10.99.99.2, 00:19:03, Serial0/0 O IA 192.168.2.0/24 [110/66] via 10.99.99.2, 00:19:03, Serial0/0 150.254.0.0/24 is subnetted, 1 subnets O IA 150.254.1.0 [110/65] via 10.99.99.2, 00:19:03, Serial0/0 |
Filtering Outgoing LSAs
In addition to distribute lists and Summary LSA filtering, OSPF also supports the filtering of all LSAs out of an outgoing interface, or for NBMA networks, to a specific neighbor. The ip ospf database-filter all out interface configuration command filters all outgoing LSAs on the interface on which it is implemented. For OSPF implementations in NBMA network environments, the neighbor [address] database-filter router configuration command performs the same function on a per-neighbor basis. Unlike distribute lists, these commands will actually filter LSAs and do prevent specified neighbors or neighbor routers discovered off the interface from having a full Link State Database, which ultimately means that those neighbors would not be able to build a complete routing table.
The filtering of LSAs is typically performed to reduce the effects LSA flooding over congested links. The assumption is that the specified neighbor router or routers known off that interface have another means of receiving LSAs, e.g. via a redundant link to another OSPF router. Because the filtering of LSAs can result in serious problems in the OSPF network, the recommended solution would be to use the ip ospf flood-reduction interface configuration command to suppress the unnecessary flooding of LSAs in stable topologies.