Filtering Routes in OSPF

2017-11-03 09:05:04

Problem

You want to apply a filter so that OSPF populates only certain routes into the routing table.

Solution

You can filter inbound routes to prevent the router from putting them in its routing table:

Router5#configure terminal Enter configuration commands, one per line. End with CNTL/Z. Router5(config)#access-list 1 deny 172.20.10.0 Router5(config)#access-list 1 permit any Router5(config)#router ospf 87 Router5(config-router)#distribute-list 1 in Ethernet0/0 Router5(config-router)#exit Router5(config)#end Router5#

The OSPF algorithm requires that every router in an area receives all of the LSAs for that area, so you cannot filter outbound routing information in the same way:

Router5#configure terminal Enter configuration commands, one per line. End with CNTL/Z. Router5(config)#router ospf 87 Router5(config-router)#distribute-list 1 out Ethernet0/0 % Interface not allowed with OUT for OSPF Router5(config-router)#exit Router5(config)#end Router5#

Filtering outbound LSAs is possible only if you filter out all of the LSAs. There are two ways to do this. For point-to-multipoint media, you can filter LSAs by going to a particular neighbor:

Router1#configure terminal Enter configuration commands, one per line. End with CNTL/Z. Router1(config)#router ospf 87 Router1(config-router)#neighbor 192.168.1.3 database-filter all out Router1(config-router)#exit Router1(config)#end Router1#

And on broadcast, nonbroadcast, and point-to-point media, you can prevent the router from sending any LSAs out a particular interface.

Router1#configure terminal Enter configuration commands, one per line. End with CNTL/Z. Router1(config)#interface Serial0/0 Router1(config-if)#encapsulation frame-relay Router1(config-if)#exit Router1(config)#interface Serial0/0.10 multipoint Router1(config-subif)#ip address 192.168.1.1 255.255.255.0 Router1(config-subif)#ip ospf network broadcast Router1(config-subif)#ip ospf database-filter all out Router1(config-subif)#frame-relay map ip 192.168.1.3 101 broadcast Router1(config-subif)#frame-relay map ip 192.168.1.5 109 broadcast Router1(config-subif)#exit Router1(config)#router ospf 1 Router1(config-router)#network 0.0.0.0 255.255.255.255 area 10 Router1(config-router)#exit Router1(config)#end Router1#

Discussion

It's important to remember that unlike EIGRP and RIP, OSPF uses a link state rather than a distance vector algorithm. One place where this difference becomes clear is in route filtering. At a minimum, every router in an area must see the LSAs for every other router in the same area. Depending on the type of area, it may also see summary LSAs representing routing information from other areas or other autonomous systems. These LSA packets are flooded throughout the area, with each router forwarding LSA information on to any downstream devices. Every router then separately computes the best routing table based on this link state information.

If you prevented a router from forwarding some of the LSA information, its downstream routers would not have a full link state database, and consequently wouldn't be able to generate an accurate routing table. When you try to do this kind of outbound filtering, the router gives you an error message:

Router5(config) #router ospf 87 Router5(config-router) #distribute-list 1 out Ethernet0/0 % Interface not allowed with OUT for OSPF

So it is not possible to do the kind of route filtering that we discussed for RIP and EIGRP in Chapters 6 and 7, respectively. The only filtering we can do is to prevent a router from installing a route learned via OSPF into its routing table. This way the link state database remains intact on every router in the area. If you really want to break up the forwarding of LSA information, then you should subdivide the area.

You can see the effect of the inbound distribute list by looking at the routing table both before and after applying the filter. Before the inbound filter is enabled, you can see that the route is there:

Router5#show ip route 172.20.10.0 Routing entry for 172.20.10.0/24 Known via "ospf 87", distance 110, metric 74, type inter area Last update from 172.18.5.3 on Ethernet0/0, 00:00:09 ago Routing Descriptor Blocks: * 172.18.5.3, from 172.19.2.1, 00:00:09 ago, via Ethernet0/0 Route metric is 74, traffic share count is 1 Router5#

Then, after we apply the filter, the route is gone:

Router5#show ip route 172.20.10.0 % Subnet not in table Router5#

However, the show ip ospf database command shows this LSA is still in the database:

Router5#show ip ospf database OSPF Router with ID (172.18.6.1) (Process ID 87) Router Link States (Area 10) Link ID ADV Router Age Seq# Checksum Link count 172.18.6.1 172.18.6.1 108 0x80000005 0x008367 4 172.19.2.1 172.19.2.1 144 0x80000004 0x00C25B 1 192.168.2.3 192.168.2.3 109 0x80000006 0x001DDE 4 192.168.2.5 192.168.2.5 109 0x80000006 0x007CFD 3 Net Link States (Area 10) Link ID ADV Router Age Seq# Checksum 172.18.5.3 172.19.2.1 144 0x80000003 0x001612 192.168.1.1 172.18.6.1 208 0x80000001 0x007CE5 192.168.2.1 172.18.6.1 208 0x80000001 0x0071EF Summary Net Link States (Area 10) Link ID ADV Router Age Seq# Checksum 0.0.0.0 172.19.2.1 978 0x80000001 0x00F288 2.2.2.2 172.19.2.1 973 0x80000001 0x0096DC 2.2.2.3 172.19.2.1 973 0x80000001 0x008CE5 2.2.2.4 172.19.2.1 973 0x80000001 0x0082EE 172.19.2.1 172.19.2.1 973 0x80000001 0x00298F 172.20.10.0 172.19.2.1 397 0x80000001 0x00472A Router5#

As you can see, the inbound distribute-list method doesn't filter LSAs; it just tells the router not to install certain routes in the routing table.

This router floods the LSA for this route normally through all of its OSPF interfaces. As a result, the route appears in the routing tables of any downstream routers:

Router3#show ip route 172.20.10.0 Routing entry for 172.20.10.0/24 Known via "ospf 1", distance 110, metric 138, type inter area Last update from 192.168.1.1 on Serial0/0.1, 00:04:51 ago Routing Descriptor Blocks: * 192.168.2.1, from 172.19.2.1, 00:04:51 ago, via Serial0/0.2 Route metric is 138, traffic share count is 1 192.168.1.1, from 172.19.2.1, 00:04:51 ago, via Serial0/0.1 Route metric is 138, traffic share count is 1 Router3#

The database-filter commands shown in the Solution section above have an entirely different result from the distribute-list commands because they actually do filter the LSAs, and therefore affect downstream routers. This can be rather confusing and have potentially dangerous results, so we should look at it in some detail. These commands both are intended for use in highly redundant meshed environments that are also relatively stable. And it is important to note what these commands do and do not block. They do not block OSPF Hello packets, so the routers will still form full and normal adjacencies. Also, they only block the sending of LSA packets. The router will receive routes normally.

The intent of these commands is to reduce traffic due to flooding, particularly over congested WAN links. The assumption is that if you are going to use these commands, the neighboring routers must have another way of receiving the required LSAs. To see how this works, suppose that you have a network with two redundant connections between two adjacent OSPF routers. We will construct a slightly artificial example network by using redundant Frame Relay PVCs so we can easily break individual neighbor relationships for demonstration purposes. For more information on Frame Relay, please refer to Chapter 10. And for more information on the ip ospf network command and its options, please refer to Recipe 8.14:

Router1(config)#interface Serial0/0.10 multipoint Router1(config-if)#ip address 192.168.1.1 255.255.255.0 Router1(config-if)#ip ospf network broadcast Router1(config-if)#ip ospf database-filter all out Router1(config-if)#frame-relay map ip 192.168.1.3 101 broadcast Router1(config-if)#frame-relay map ip 192.168.1.5 109 broadcast Router1(config-if)#exit Router1(config)#interface Serial0/0.11 multipoint Router1(config-if)#ip address 192.168.2.1 255.255.255.0 Router1(config-if)#ip ospf network broadcast Router1(config-if)#frame-relay map ip 192.168.2.3 201 broadcast Router1(config-if)#frame-relay map ip 192.168.2.5 209 broadcast Router1(config-if)#exit Router1(config)#end

Now we want to verify that the LSA filtering is working. First we will list all of the neighbors:

Router1#show ip ospf neighbor Neighbor ID Pri State Dead Time Address Interface 192.168.2.3 0 FULL/DROTHER 00:00:34 192.168.1.3 Serial0/0.10 192.168.2.5 0 FULL/DROTHER 00:00:31 192.168.1.5 Serial0/0.10 192.168.2.3 0 FULL/DROTHER 00:00:33 192.168.2.3 Serial0/0.11 192.168.2.5 0 FULL/DROTHER 00:00:30 192.168.2.5 Serial0/0.11 172.19.2.1 1 FULL/DR 00:00:36 172.18.5.3 Ethernet0/0

Then we will look at one particular neighbor with the show ip ospf neighbor detail command:

Router1#show ip ospf neighbor detail 192.168.2.3 Neighbor 192.168.2.3, interface address 192.168.1.3 In the area 10 via interface Serial0/0.10 Neighbor priority is 0, State is FULL, 6 state changes Database-filter all out DR is 192.168.1.1 BDR is 0.0.0.0 Options is 0x40 Dead timer due in 00:00:39 Neighbor is up for 00:13:20 Index 4/4, retransmission queue length 0, number of retransmission 0 First 0x0(0)/0x0(0) Next 0x0(0)/0x0(0) Last retransmission scan length is 0, maximum is 0 Last retransmission scan time is 0 msec, maximum is 0 msec Neighbor 192.168.2.3, interface address 192.168.2.3 In the area 10 via interface Serial0/0.11 Neighbor priority is 0, State is FULL, 6 state changes DR is 192.168.2.1 BDR is 0.0.0.0 Options is 0x40 Dead timer due in 00:00:39 Neighbor is up for 00:05:52 Index 2/2, retransmission queue length 0, number of retransmission 1 First 0x0(0)/0x0(0) Next 0x0(0)/0x0(0) Last retransmission scan length is 1, maximum is 1 Last retransmission scan time is 0 msec, maximum is 0 msec Router1#

If we then go to the neighboring router and look at the routing table, it looks normal. Notice in particular that both paths appear as valid in the routing table:

Router3#show ip route ospf 2.0.0.0/32 is subnetted, 2 subnets O IA 2.2.2.2 [110/75] via 192.168.1.1, 00:08:47, Serial0/0.1 [110/75] via 192.168.2.1, 00:08:47, Serial0/0.2 O IA 2.2.2.3 [110/75] via 192.168.1.1, 00:08:47, Serial0/0.1 [110/75] via 192.168.2.1, 00:08:47, Serial0/0.2 Router3#

If we then take down the Frame Relay PVC that does not have the database-filter command on it, we lose the corresponding neighbor relationship, but we keep the neighbor that is filtering LSAs:

On the neighboring router, the routing table has lost the corresponding routes:

Router3#show ip route ospf 2.0.0.0/32 is subnetted, 2 subnets O IA 2.2.2.2 [110/75] via 192.168.1.1, 00:02:31, Serial0/0.1 O IA 2.2.2.3 [110/75] via 192.168.1.1, 00:02:31, Serial0/0.1 Router3#

And this is where the database-filter feature becomes both visible and dangerous. Suppose we add another route for 2.2.2.4/32 on an upstream router. Router1 learns about the new route:

Router1#show ip route 2.0.0.0 Routing entry for 2.0.0.0/32, 3 known subnets O IA 2.2.2.2 [110/11] via 172.18.5.3, 00:05:22, Ethernet0/0 O IA 2.2.2.3 [110/11] via 172.18.5.3, 00:05:22, Ethernet0/0 O IA 2.2.2.4 [110/11] via 172.18.5.3, 00:00:08, Ethernet0/0 Router1#

But, because Router1 is filtering LSAs for Router3, the downstream router is not notified of the change to the routing table:

Router3#show ip route 2.0.0.0 Routing entry for 2.0.0.0/32, 2 known subnets O IA 2.2.2.2 [110/75] via 192.168.1.1, 00:08:25, Serial0/0.1 O IA 2.2.2.3 [110/75] via 192.168.1.1, 00:08:25, Serial0/0.1 Router3#

Then, as soon as the failed Frame-Relay PVC is restored, Router3 finally learns about all of the changes to the routing table:

Router3#show ip route 2.0.0.0 Routing entry for 2.0.0.0/32, 3 known subnets O IA 2.2.2.2 [110/75] via 192.168.1.1, 00:00:08, Serial0/0.1 [110/75] via 192.168.2.1, 00:00:08, Serial0/0.2 O IA 2.2.2.3 [110/75] via 192.168.1.1, 00:00:08, Serial0/0.1 [110/75] via 192.168.2.1, 00:00:08, Serial0/0.2 O IA 2.2.2.4 [110/75] via 192.168.1.1, 00:00:08, Serial0/0.1 [110/75] via 192.168.2.1, 00:00:08, Serial0/0.2 Router3#

Clearly, this is an extremely dangerous feature because it is possible for routing tables to get completely out of sync across your network. We don't recommend using it unless you are absolutely certain that you understand the consequences. However, this feature can be useful in situations where you have very low bandwidth links to isolated network regions, allowing you to create a sort of stub area within a larger area.

Категории