OSPF Distribute-List Filtering

OSPF supports a number of methods to filter routes but it is more restrictive compared to distance vector routing protocols like RIP or EIGRP.

As a link-state routing protocol OSPF uses LSAs to build its LSDB (Link State Database). Routers will run the SPF algorithm to find the shortest path to each destination, the topology in the LSDB has to be the same on all routers or SPF will fail.

However OSPF routers only know what the topology looks like within the area. They don’t know what the topology looks like for other areas. For inter-area routes OSPF only knows the prefix and the ABR (Area Border Router) to reach it.

You could say that OSPF acts like a distance vector routing protocol for inter-area routes. It only knows the metric (distance) and the ABR to get there (vector).

Unlike RIP or EIGRP, OSPF doesn’t advertise routes but LSAs so if we want to filter something we’ll have to filter the advertisement of LSAs.

Since the LSDB within the area has to be the same we can’t filter LSAs within the area, we can however filter routes from entering the routing table. Filtering LSAs between areas on an ABR or ASBR is no problem.

In this lesson I’ll show you how we can filter routes from entering the routing table within the area. In other lessons I will explain how to filter type 3 LSAs and type 5 LSAs.

Here’s the topology I will use:

OSPF Three Routers Single Area

Nothing fancy, we have three routers running OSPF in the same area. R1 has a loopback interface that is advertised in OSPF, we’ll see if we can filter this network.

Configuration

Here’s the OSPF configuration:

R1#show running-config | section ospf
router ospf 1
 network 1.1.1.0 0.0.0.255 area 0
 network 192.168.12.0 0.0.0.255 area 0
R2#show running-config | section ospf
router ospf 1
 network 192.168.12.0 0.0.0.255 area 0
 network 192.168.23.0 0.0.0.255 area 0
R3#show running-config | section ospf
router ospf 1
 network 192.168.23.0 0.0.0.255 area 0

Let’s verify if R2 and R3 have learned 1.1.1.1 /32:

R2#show ip route ospf

      1.0.0.0/32 is subnetted, 1 subnets
O        1.1.1.1 [110/2] via 192.168.12.1, 00:00:27, FastEthernet0/0
R3#show ip route ospf

      1.0.0.0/32 is subnetted, 1 subnets
O        1.1.1.1 [110/3] via 192.168.23.2, 00:00:28, FastEthernet0/0
O     192.168.12.0/24 [110/2] via 192.168.23.2, 00:00:28, FastEthernet0/0

Let’s see if we can get rid of this network on R3:

R3(config)#router ospf 1
R3(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

We can use a distribute-list for this, to keep it simple I’ll combine it with an access-list;

R3(config-router)#distribute-list R1_L0 in

When we want to remove something from the routing table we have to apply it inbound. The outbound distribute-list is used for LSA type 5 filtering.

Let’s create that access-list:

R3(config)#ip access-list standard R1_L0
R3(config-std-nacl)#deny host 1.1.1.1    
R3(config-std-nacl)#permit any

It will now be gone from the routing table:

R3#show ip route 1.1.1.1
% Network not in table

As you can see it’s gone…it’s still in the LSDB though:

R3#show ip ospf database router 192.168.12.1

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

		Router Link States (Area 0)

  LS age: 664
  Options: (No TOS-capability, DC)
  LS Type: Router Links
  Link State ID: 192.168.12.1
  Advertising Router: 192.168.12.1
  LS Seq Number: 80000003
  Checksum: 0xF14F
  Length: 48
  Number of Links: 2

    Link connected to: a Stub Network
     (Link ID) Network/subnet number: 1.1.1.1
     (Link Data) Network Mask: 255.255.255.255
      Number of MTID metrics: 0
       TOS 0 Metrics: 1

    Link connected to: a Transit Network
     (Link ID) Designated Router address: 192.168.12.2
     (Link Data) Router Interface address: 192.168.12.1
      Number of MTID metrics: 0
       TOS 0 Metrics: 1

You have to be very careful if you use this command. If you are not careful you can end up in a scenario where you blackhole some traffic. For example, let’s see what happens when I filter this network on R2 instead of R3.[teaser] Let’s remove the distribute-list on R3:

R3(config)#router ospf 1
R3(config-router)#no distribute-list R1_L0 in

Now I will add it to R2:

R2(config)#ip access-list standard R1_L0
R2(config-std-nacl)#deny host 1.1.1.1
R2(config-std-nacl)#permit any

R2(config)#router ospf 1
R2(config-router)#distribute-list R1_L0 in

R2 now no longer has it in its routing table:

R2#show ip route 1.1.1.1
% Network not in table

However the LSA is still flooded to R3:

R3#show ip route ospf 

      1.0.0.0/32 is subnetted, 1 subnets
O        1.1.1.1 [110/3] via 192.168.23.2, 00:02:45, FastEthernet0/0
O     192.168.12.0/24 [110/2] via 192.168.23.2, 00:02:45, FastEthernet0/0

Once R3 tries to reach this network we will have a problem:

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

R3 will forward these packets to R2 which drops it.

Configurations

Want to take a look for yourself? Here you will find the configuration of each device.

R1

hostname R1
!
ip cef
!
interface Loopback0
 ip address 1.1.1.1 255.255.255.255
!
interface FastEthernet0/0
 ip address 192.168.12.1 255.255.255.0
!
router ospf 1
 network 1.1.1.0 0.0.0.255 area 0
 network 192.168.12.0 0.0.0.255 area 0
!
end

R2

hostname R2
!
ip cef
!
interface FastEthernet0/0
 ip address 192.168.12.2 255.255.255.0
!
interface FastEthernet1/0
 ip address 192.168.23.2 255.255.255.0
!
router ospf 1
 network 192.168.12.0 0.0.0.255 area 0
 network 192.168.23.0 0.0.0.255 area 0
 distribute-list R1_L0 in
!
ip access-list standard R1_L0
 deny   1.1.1.1
 permit any
!
end

R3

hostname R3
!
ip cef
!
interface FastEthernet0/0
 ip address 192.168.23.3 255.255.255.0
!
router ospf 1
 network 192.168.23.0 0.0.0.255 area 0
!
ip access-list standard R1_L0
 deny   1.1.1.1
 permit any
!
end


That’s all there is to it, you have now seen how you can filter routes within your OSPF area. Make sure you also check my other two lessons on OSPF filtering:

If you have any questions, feel free to leave a comment![/MM_Access_Decision]

We're Sorry, Full Content Access is for Members Only...

If you like to keep on reading, Become a Member Now! Here is why:

  • Learn any CCNA, CCNP and CCIE R&S Topic. Explained As Simple As Possible.
  • Try for Just $1. The Best Dollar You've Ever Spent on Your Cisco Career!
  • Full Access to our 651 Lessons. More Lessons Added Every Week!
  • Content created by Rene Molenaar (CCIE #41726)

567 Sign Ups in the last 30 days

satisfaction-guaranteed
100% Satisfaction Guaranteed!
You may cancel your monthly membership at any time.
No Questions Asked!

Forum Replies

  1. Hi Rene,

    Really enjoying the OSPF lessons! Just one query, the first output is what you had in the lesson and am just wondering why you chose the network statement for the loopback 0 as 1.1.1.0 0.0.0.255 area 0, instead of 1.1.1.1 0.0.0.0 area 0, as in the second output?

    R1#show running-config | section ospf
    router ospf 1
     <strong>network 1.1.1.0 0.0.0.255 area 0</strong>
     network 192.168.12.0 0.0.0.255 area 0
     
    R1#show running-config | section ospf
    router ospf 1
     network 1.1.1.1 0.0.0.0 area 0
     network 192.168.12.0 0.0.0.255 area 0
     network 192.168.12.0 0.0.0.
    ... Continue reading in our forum

  2. Hi Shannon,

    It doesn’t matter much which of the two you pick, both will work. The network command basically checks the IP addresses that you have on your interfaces and if it falls within the range of your network command, it will activate OSPF on it.

    If you use 1.1.1.0 0.0.0.255 as the network command then any interfaces that have IP address 1.1.1.X on it will run OSPF. If I have a loopback with IP address 1.1.1.1/32 then this will do the job. The problem is that a loopback with 1.1.1.2/32 will also be automatically advertised in OSPF since it matches the netw

    ... Continue reading in our forum

  3. Hello Rene,
    One quick question. I am trying to use distribute-list in OSPF in outbound direction, but the command is being rejected and the below error message is showing up. Would you please describe why? Thank you so much.

    R1(config-router)#distribute-list prefix cisco out gigabitEthernet 1/0
    **% Interface not allowed with OUT in case of OSPF**
    

    Best Regards,
    Azm

  4. Hello Rene,
    Thanks for your reply. However, I still have a confusion. How does distribute-list work? does it filter LSAs or it resists routes from being installed in the routing table? Let’s say we are looking at topology like below and they are running OSPF:

    Router A------------Router B-(inbound distribute-list)---------------Router C

    Let’s say, Router C has a loopback 1.1.1.1 and it is advertised in OSPF. So if I apply an inbound distribute-list to block 1.1.1.1 on Router B, it does not install 1.1.1.1 route in its routing table. However, it passes the 1.1.1.

    ... Continue reading in our forum

  5. Hello Azm

    Yes, you are correct. The filtering that takes place is filtering of routes from entering the routing table. The filtering does not occur at the interface, but at the mechanism of adding routes to the routing table. Rene mentions the following in the lesson:

    Since the LSDB within the area has to be the same we can’t filter LSAs within the area, we can however filter routes from entering the routing table. Filtering LSAs between areas on an ABR or ASBR is no problem.

    So it is a matter of the definition of the word filter. Filtering in this case

    ... Continue reading in our forum

12 more replies! Ask a question or join the discussion by visiting our Community Forum