Route filter effects. Link-State vs Distance-Vector

You may think that setting up a route filter would be pretty much the same, no matter what the actual routing protocol is, but you’d be wrong. The main difference is essentially the main difference with these 2 types of protocols to begin with.

A distance-vector protocol exchanges routes with it’s neighbours. A link-state protocol exchanges link states, not routes. You can’t filter link states from a neighbour when that neighbour is in the same area. Why? If you remember your OSPF and IS-Is studies, you’ll remember that in order to function and converge, all routers in the same area need to have identical link-state databases.

So what exactly does a route filter do for different protocols? Let’s do a simple test to find out.

Let’s use the following topology:

The routers BUDA and PEST are separated by the router named DANUBE. Both BUDA and PEST with both be redistributing routes into the routing domain. DANUBE will have route filters configured. We will then check to see which routes were actually seen.

Let’s do a DV protocol first, EIGRP. Let’s first do the basic configuration.

Buda:

interface Loopback0
ip address 192.168.1.1 255.255.255.0
!
interface FastEthernet0/0
ip address 10.1.1.0 255.255.255.254
!
router eigrp 1
network 10.1.1.0
network 192.168.1.0
no auto-summary

Danube:

interface FastEthernet0/0
 ip address 10.1.1.1 255.255.255.254
!
interface FastEthernet1/0
 ip address 10.1.1.2 255.255.255.254
!
router eigrp 1
 network 10.1.1.1
 network 10.1.1.2
 no auto-summary

Pest:

interface Loopback0
 ip address 172.16.1.1 255.255.255.0
!
interface FastEthernet0/0
 ip address 10.1.1.3 255.255.255.254
!
router eigrp 1
 network 10.1.1.3
 network 172.16.0.0
 no auto-summary

I now want to create a route-filter on Danube that blocks 172.16.1.0/24 from being advertised into Danube. This should also prevent the route from getting to Buda. Before I do that I want to ensure that Buda and Danube actually do see the 172.16.1.0/24 network:

Buda#sh ip route |  include 172.16
     172.16.0.0/24 is subnetted, 1 subnets
D       172.16.1.0 [90/158720] via 10.1.1.1, 00:01:31, FastEthernet0/0
!
!
Danube#sh ip route |  include 172.16
     172.16.0.0/24 is subnetted, 1 subnets
D       172.16.1.0 [90/156160] via 10.1.1.3, 00:01:53, FastEthernet1/0

Danube:

access-list 1 deny   172.16.1.0 0.0.0.255
access-list 1 permit any
!
router eigrp 1
 distribute-list 1 in

Now do we see the routes?

Danube#sh ip route |  include 172.16
Danube#
!
!
Buda#sh ip route |  include 172.16
Buda#

Pest of course still sees everything:

Pest#sh ip route | include 192.168
D    192.168.1.0/24 [90/158720] via 10.1.1.2, 00:05:14, FastEthernet0/0

Let’s now change everything to OSPF and see what happens. I’m only going to show Danube’s configuration as the others are almost identical:

router ospf 1
 log-adjacency-changes
 network 10.1.1.1 0.0.0.0 area 0
 network 10.1.1.2 0.0.0.0 area 0

Does Buda and Danube see the routes?

Buda#sh ip route |  include 172.16
     172.16.0.0/32 is subnetted, 1 subnets
O       172.16.1.1 [110/3] via 10.1.1.1, 00:01:03, FastEthernet0/0
!
Danube#sh ip route |  include 172.16
     172.16.0.0/32 is subnetted, 1 subnets
O       172.16.1.1 [110/2] via 10.1.1.3, 00:01:01, FastEthernet1/0

Indeed they do. The same access-list is still on Danube, so I’ll now apply a distribute list on Danube.

router ospf 1
  distribute-list 1 in

What routes do we see on Buda and Danube?

Danube#sh ip route |  include 172.16
Danube#
!
Buda#sh ip route |  include 172.16
     172.16.0.0/32 is subnetted, 1 subnets
O       172.16.1.1 [110/3] via 10.1.1.1, 00:00:39, FastEthernet0/0

On Danube the route is gone, but Buda has the route! Why is this?
The explanation is really simple in fact. In a DV protocol like EIGRP, a router learns how to get to routes from it’s direct neighbours. Danube says to Buda that “I’ve learnt how to get to Pest’s loopback from Pest, so I can now advertise reachability to that network through me” – This is why when that route was filtered out, Danube no longer advertised that route out as it could not get there itself.

With a LS protocol like OSPF, the rules change. Remember that one of the rules of OSPF is that ALL routers in an area with have identical link-state databases. Let’s check this on Danube:

Danube#sh ip ospf database

            OSPF Router with ID (10.1.1.2) (Process ID 1)

                Router Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum Link count
10.1.1.2        10.1.1.2        361         0x80000005 0x006666 2
172.16.1.1      172.16.1.1      369         0x80000003 0x000CB9 2
192.168.1.1     192.168.1.1     545         0x80000003 0x00279E 2
!
truncated

Danube has the 172.16.1.1 LSA in it’s database. The only thing the distribute-list is doing on Danube is preventing that LSA being entered into the RIB (routing-table)

Buda also has the same link-state database as it’s also in area 0.

The above though does actually create a problem. If I try and send a ping from Buda to Pest’s loopback, it’ll send that packet off to Danube. Danube however won’t have the route so it’ll drop the packet. Let’s test this:

Buda#ping 172.16.1.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.1.1, timeout is 2 seconds:
U.U.U
Success rate is 0 percent (0/5)

The only time a distribute-list or LSA filter has any effect, is when you’re going from one area to another. If you’re filtering intra-area you’re only going to run into routing problems.

© 2009-2020 Darren O'Connor All Rights Reserved -- Copyright notice by Blog Copyright