Routing Protocols

Tutorial: Filtering Routes in OSPF Part 1 » Filtering Within An Area

Thanks for visiting! If you're new here, you may want to subscribe to my RSS feed. This blog posts regular tutorials, news, and study tips about networking, especially about Cisco CCIE related topics. Go ahead, subscribe to the feed! You can also receive updates from this blog via email. Thanks for visiting!

In addition to knowing all the different OSPF Network Types and how they relate to Frame-Relay, a CCIE candidate must be familiar with the different methods of filtering routes in OSPF. This two part series of tutorials will focus on filtering routes in OSPF, both within an area and between areas. This tutorial will focus on filtering routes within an area using distribute-lists, access-lists and using a route-map.

We will be using the following topology for this tutorial:

Dynagen .net Configuration File:

ghostios = True
sparsemem = True
model = 3640

[localhost]

    [[3640]]
        image = \Program Files\Dynamips\images\c3640-jk9o3s-mz.124-12.bin
        # On Linux / Unix use forward slashes:
        # image = /opt/7200-images/c7200-jk9o3s-mz.124-7a.image
        ram = 128

    [[ROUTER R1]]
        model = 3640
        console = 2000
        e1/0 = LAN 13
        e1/1 = LAN 12
        autostart = False       

    [[ROUTER R2]]
        model = 3640
        console = 2001
        e1/0 = LAN 23
        e1/1 = LAN 12
        autostart = False

    [[ROUTER R3]]
        model = 3640
        console = 2002
        e1/0 = LAN 13
        e1/1 = LAN 23
        e1/2 = LAN 34
        e1/3 = LAN 35
        autostart = False

    [[ROUTER R4]]
        model = 3640
        console = 2003
        e1/0 = LAN 34
        e1/1 = LAN 45
        autostart = False

    [[ROUTER R5]]
        model = 3640
        console = 2004
        e1/0 = LAN 35
        e1/1 = LAN 45
        autostart = False

You can download the .net dynagen configuration file here.

Basic Configuration

First things first lets set up our basic topology. You can see in the diagram above R3 will be our Area Border Router (ABR) between Area 0 and Area 1. R1 and R2 will be backbone routers in Area 0, and R4 and R5 will be internal Area 1 routers.

R1:

hostname R1
!
interface Loopback0
 ip address 1.1.1.1 255.255.255.255
!
interface Ethernet1/0
 ip address 10.0.13.1 255.255.255.0
 full-duplex
!
interface Ethernet1/1
 ip address 10.0.12.1 255.255.255.0
 full-duplex
!
router ospf 1
 router-id 1.1.1.1
 log-adjacency-changes
 network 1.1.1.1 0.0.0.0 area 0
 network 10.0.12.1 0.0.0.0 area 0
 network 10.0.13.1 0.0.0.0 area 0

R2:

hostname R2
!
interface Loopback0
 ip address 2.2.2.2 255.255.255.255
!
interface Ethernet1/0
 ip address 10.0.23.2 255.255.255.0
 full-duplex
!
interface Ethernet1/1
 ip address 10.0.12.2 255.255.255.0
 full-duplex
!
router ospf 1
 router-id 2.2.2.2
 log-adjacency-changes
 network 2.2.2.2 0.0.0.0 area 0
 network 10.0.12.2 0.0.0.0 area 0
 network 10.0.23.2 0.0.0.0 area 0

R3:

hostname R3
!
interface Loopback0
 ip address 3.3.3.3 255.255.255.255
!
interface Ethernet1/0
 ip address 10.0.13.3 255.255.255.0
 full-duplex
!
interface Ethernet1/1
 ip address 10.0.23.3 255.255.255.0
 full-duplex
!
interface Ethernet1/2
 ip address 10.1.34.3 255.255.255.0
 full-duplex
!
interface Ethernet1/3
 ip address 10.1.35.3 255.255.255.0
 full-duplex
!
router ospf 1
 router-id 3.3.3.3
 log-adjacency-changes
 network 3.3.3.3 0.0.0.0 area 0
 network 10.0.13.3 0.0.0.0 area 0
 network 10.0.23.3 0.0.0.0 area 0
 network 10.1.34.3 0.0.0.0 area 1
 network 10.1.35.3 0.0.0.0 area 1

R4:

hostname R4
!
interface Loopback0
 ip address 4.4.4.4 255.255.255.255
!
interface Ethernet1/0
 ip address 10.1.34.4 255.255.255.0
 full-duplex
!
interface Ethernet1/1
 ip address 10.1.45.4 255.255.255.0
 full-duplex
!
router ospf 1
 router-id 4.4.4.4
 log-adjacency-changes
 network 4.4.4.4 0.0.0.0 area 1
 network 10.1.34.4 0.0.0.0 area 1
 network 10.1.45.4 0.0.0.0 area 1

R5:

hostname R5
!
interface Loopback0
 ip address 5.5.5.5 255.255.255.255
!
interface Ethernet1/0
 ip address 10.1.35.5 255.255.255.0
 full-duplex
!
interface Ethernet1/1
 ip address 10.1.45.5 255.255.255.0
 full-duplex
!
router ospf 1
 router-id 5.5.5.5
 log-adjacency-changes
 network 5.5.5.5 0.0.0.0 area 1
 network 10.1.35.5 0.0.0.0 area 1
 network 10.1.45.5 0.0.0.0 area 1

You can see above, we have also added a loopback interface on each device and advertised them into OSPF. R1, R2, and R3’s Loopback0 interfaces have been added to Area 0. R4 and R5’s Loopback0 interfaces have been added to Area 1.

Let’s verify the routing table on R5 and test connectivity before we start filtering routes.

R5#sh ip route | b Gateway
Gateway of last resort is not set

     1.0.0.0/32 is subnetted, 1 subnets
O IA    1.1.1.1 [110/21] via 10.1.35.3, 00:47:50, Ethernet1/0
     2.0.0.0/32 is subnetted, 1 subnets
O IA    2.2.2.2 [110/21] via 10.1.35.3, 00:47:50, Ethernet1/0
     3.0.0.0/32 is subnetted, 1 subnets
O IA    3.3.3.3 [110/11] via 10.1.35.3, 00:47:50, Ethernet1/0
     4.0.0.0/32 is subnetted, 1 subnets
O       4.4.4.4 [110/11] via 10.1.45.4, 00:47:50, Ethernet1/1
     5.0.0.0/32 is subnetted, 1 subnets
C       5.5.5.5 is directly connected, Loopback0
     10.0.0.0/24 is subnetted, 6 subnets
O IA    10.0.12.0 [110/30] via 10.1.35.3, 00:47:50, Ethernet1/0
O IA    10.0.13.0 [110/20] via 10.1.35.3, 00:47:50, Ethernet1/0
O IA    10.0.23.0 [110/20] via 10.1.35.3, 00:47:50, Ethernet1/0
C       10.1.45.0 is directly connected, Ethernet1/1
C       10.1.35.0 is directly connected, Ethernet1/0
O       10.1.34.0 [110/20] via 10.1.45.4, 00:47:50, Ethernet1/1
                  [110/20] via 10.1.35.3, 00:47:50, Ethernet1/0

The routing table looks correct. We have inter-area routes to R1, R2, and R3’s loopback0 addresses as well as to the 10.0.12.0/24, 10.0.13.0/24 and 10.0.23.0/24 networks.

R5#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:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 216/245/284 ms

Looks like we have full connectivity. Now time to filter some routes!

Filtering Routes Within An Area

OSPF is a link-state routing protocol. Routers running OSPF within an area swap state information and populate a topology database. Each router then independently calculates the best paths based on the information contained in their topology database. All routers within an area must have the same topology information so that they can accurately make routing decisions.

Let’s take a look at the current OSPF topology database on R5:

R5#sh ip ospf database 

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

                Router Link States (Area 1)

Link ID         ADV Router      Age         Seq#       Checksum Link count
3.3.3.3         3.3.3.3         473         0x80000004 0x00EC42 2
4.4.4.4         4.4.4.4         473         0x80000005 0x006887 3
5.5.5.5         5.5.5.5         454         0x80000005 0x000BD3 3

                Net Link States (Area 1)

Link ID         ADV Router      Age         Seq#       Checksum
10.1.34.4       4.4.4.4         473         0x80000003 0x0014C6
10.1.35.5       5.5.5.5         454         0x80000003 0x0003CD
10.1.45.5       5.5.5.5         454         0x80000003 0x00C6FB

                Summary Net Link States (Area 1)

Link ID         ADV Router      Age         Seq#       Checksum
1.1.1.1         3.3.3.3         473         0x80000003 0x006BB4
2.2.2.2         3.3.3.3         473         0x80000003 0x003DDE
3.3.3.3         3.3.3.3         473         0x80000003 0x00AA77
10.0.12.0       3.3.3.3         473         0x80000003 0x00EC18
10.0.13.0       3.3.3.3         474         0x80000003 0x007D90
10.0.23.0       3.3.3.3         474         0x80000003 0x000FF4

We will be filtering routes on R5 so it will be interesting to see the effect that this will have on the topology database. If we lose any of the database entries, we will have an inconsistent database in our area with some routers missing pieces of the the topology database. An inconsistent topology database might cause the Dijkstra’s shortest-path-first algorithm that OSPF uses to calculate paths that contain routing loops or routing black holes.

Herein lies the challenge. If we filter routes on a particular router, does that mean that some routers in an area will have a different topology database than the others in the same area? How will this affect the routing process? It is these questions that I want you to keep in mind when we go through our examples.

Filtering within an area - Using distribute-list

The first tool we will be using to filter routes is a distribute-list. We will first use a distribute list to filter all routes except R3’s loopback address (3.3.3.3) from R5’s routing table.

Let’s take a look at the configuration:
R5:

router ospf 1
 distribute-list 1 in
!
access-list 1 permit 3.3.3.3

You can see we have created an inbound distribute-list on the OSPF process on R5. We have used an access-list to define that we only want to permit the 3.3.3.3 address (don’t forget there is an implicit deny at the end of that access list).

Let’s verify this:

R5#sh ip route | b Gateway
Gateway of last resort is not set

     3.0.0.0/32 is subnetted, 1 subnets
O IA    3.3.3.3 [110/11] via 10.1.35.3, 00:00:14, Ethernet1/0
     5.0.0.0/32 is subnetted, 1 subnets
C       5.5.5.5 is directly connected, Loopback0
     10.0.0.0/24 is subnetted, 2 subnets
C       10.1.45.0 is directly connected, Ethernet1/1
C       10.1.35.0 is directly connected, Ethernet1/0

Looks like our distribute-list worked as anticipated. The only non-connected route that we can see is the 3.3.3.3/32 network (ie R3’s loopback0).

Let’s check out the OSPF topology database:

R5#sh ip ospf data

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

                Router Link States (Area 1)

Link ID         ADV Router      Age         Seq#       Checksum Link count
3.3.3.3         3.3.3.3         1476        0x80000005 0x00D659 2
4.4.4.4         4.4.4.4         1415        0x80000006 0x006688 3
5.5.5.5         5.5.5.5         1362        0x80000006 0x00DC03 3

                Net Link States (Area 1)

Link ID         ADV Router      Age         Seq#       Checksum
10.1.34.4       4.4.4.4         1415        0x80000002 0x0016C5
10.1.35.3       3.3.3.3         1476        0x80000002 0x007566
10.1.45.5       5.5.5.5         1362        0x80000002 0x00C8FA

                Summary Net Link States (Area 1)

Link ID         ADV Router      Age         Seq#       Checksum
1.1.1.1         3.3.3.3         1476        0x80000002 0x006DB3
2.2.2.2         3.3.3.3         1476        0x80000002 0x003FDD
3.3.3.3         3.3.3.3         1476        0x80000002 0x00AC76
10.0.12.0       3.3.3.3         1476        0x80000002 0x00EE17
10.0.13.0       3.3.3.3         1478        0x80000002 0x007F8F
10.0.23.0       3.3.3.3         1478        0x80000002 0x0011F3

Whoa! We have NO change to the OSPF topology database!

At first glance this might seem counter-intuitive but this is exactly what we want to happen. Remember OSPF is a link-state routing protocol where each router then calculates the best paths based on the information contained in their topology database. All routers within an area must have the same topology information so that they can accurately make routing decisions. If they don’t have the same topology database on the routers within an area we risk routing loops or routing black holes in that area.

So the distribute-list command doesn’t affect routes as they enter or leave the OSPF topology database. The distribute-list command affects routes as they go in and out of the routing table. It does not prevent link state packets from being propagated.

This is very important to remember. When Dijkstra’s shortest-path-first algorithm calculates the best path in OSPF it needs to have a complete view of the topology in an area. If it does not, it cannot calculate best paths that are guaranteed to be loop free.

This configuration could still result in a routing black hole if R4 decides to send packets for any other address (other than R3’s Loopback0) via R5.

Let’s check this:

R4:

R4#sh ip ospf data

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

                Router Link States (Area 1)

Link ID         ADV Router      Age         Seq#       Checksum Link count
3.3.3.3         3.3.3.3         41          0x80000003 0x00EE41 2
4.4.4.4         4.4.4.4         45          0x80000003 0x006C85 3
5.5.5.5         5.5.5.5         44          0x80000003 0x000FD1 3

                Net Link States (Area 1)

Link ID         ADV Router      Age         Seq#       Checksum
10.1.34.4       4.4.4.4         45          0x80000001 0x0018C4
10.1.35.5       5.5.5.5         43          0x80000001 0x0007CB
10.1.45.5       5.5.5.5         54          0x80000001 0x00CAF9

                Summary Net Link States (Area 1)

Link ID         ADV Router      Age         Seq#       Checksum
1.1.1.1         3.3.3.3         32          0x80000001 0x006FB2
2.2.2.2         3.3.3.3         42          0x80000001 0x0041DC
3.3.3.3         3.3.3.3         82          0x80000001 0x00AE75
10.0.12.0       3.3.3.3         42          0x80000001 0x00F016
10.0.13.0       3.3.3.3         83          0x80000001 0x00818E
10.0.23.0       3.3.3.3         83          0x80000001 0x0013F2

You can see R4’s topology database above. It has the same entries as R5’s. This is needed by OSPF to make accurate routing decisions.

R4#sh ip route | b Gateway
Gateway of last resort is not set

     1.0.0.0/32 is subnetted, 1 subnets
O IA    1.1.1.1 [110/21] via 10.1.34.3, 00:00:02, Ethernet1/0
     2.0.0.0/32 is subnetted, 1 subnets
O IA    2.2.2.2 [110/21] via 10.1.34.3, 00:00:02, Ethernet1/0
     3.0.0.0/32 is subnetted, 1 subnets
O IA    3.3.3.3 [110/11] via 10.1.34.3, 00:00:02, Ethernet1/0
     4.0.0.0/32 is subnetted, 1 subnets
C       4.4.4.4 is directly connected, Loopback0
     5.0.0.0/32 is subnetted, 1 subnets
O       5.5.5.5 [110/11] via 10.1.45.5, 00:00:02, Ethernet1/1
     10.0.0.0/24 is subnetted, 6 subnets
O IA    10.0.12.0 [110/30] via 10.1.34.3, 00:00:02, Ethernet1/0
O IA    10.0.13.0 [110/20] via 10.1.34.3, 00:00:02, Ethernet1/0
O IA    10.0.23.0 [110/20] via 10.1.34.3, 00:00:03, Ethernet1/0
C       10.1.45.0 is directly connected, Ethernet1/1
O       10.1.35.0 [110/20] via 10.1.45.5, 00:00:03, Ethernet1/1
                  [110/20] via 10.1.34.3, 00:00:03, Ethernet1/0
C       10.1.34.0 is directly connected, Ethernet1/0

R4#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:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/32/52 ms

At the moment R4 is routing everything correctly to R3. Let’s take a look what happens when we shut down R4’s e1/0 interface:

R4#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R4(config)#int e1/0
R4(config-if)#shut
R4(config-if)#end

R4#sh ip route | b Gateway
Gateway of last resort is not set

     1.0.0.0/32 is subnetted, 1 subnets
O IA    1.1.1.1 [110/31] via 10.1.45.5, 00:00:03, Ethernet1/1
     2.0.0.0/32 is subnetted, 1 subnets
O IA    2.2.2.2 [110/31] via 10.1.45.5, 00:00:03, Ethernet1/1
     3.0.0.0/32 is subnetted, 1 subnets
O IA    3.3.3.3 [110/21] via 10.1.45.5, 00:00:03, Ethernet1/1
     4.0.0.0/32 is subnetted, 1 subnets
C       4.4.4.4 is directly connected, Loopback0
     5.0.0.0/32 is subnetted, 1 subnets
O       5.5.5.5 [110/11] via 10.1.45.5, 00:00:03, Ethernet1/1
     10.0.0.0/24 is subnetted, 5 subnets
O IA    10.0.12.0 [110/40] via 10.1.45.5, 00:00:03, Ethernet1/1
O IA    10.0.13.0 [110/30] via 10.1.45.5, 00:00:03, Ethernet1/1
O IA    10.0.23.0 [110/30] via 10.1.45.5, 00:00:04, Ethernet1/1
C       10.1.45.0 is directly connected, Ethernet1/1
O       10.1.35.0 [110/20] via 10.1.45.5, 00:00:04, Ethernet1/1

Take a look at the routing table above. R4’s OSPF has noticed a topology change and Dijkstra’s shortest-path algorithm has recalculated that the new best path is via R5. Because we still have the same topology database as R5, R4 assumes that this is a valid decision. It doesn’t realise that we are filtering all routes except for 3.3.3.3 on R5.

R4#ping 3.3.3.3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 12/35/72 ms

R4#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)

This results in a routing black hole, which is exactly what we would expect. The distribute-list command doesn’t affect the topology database, only the routing table.

Let’s reset the configuration on R4 and R5 before we proceed:

R4:

R4#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R4(config)#int e1/0
R4(config-if)#no shut
R4(config-if)#end

R5:

R5#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R5(config)#no access-list 1
R5(config)#router ospf 1
R5(config-router)#no distribute-list 1 in
R5(config-router)#end

Filtering within an area - Using a distribute-list with a route-map

We can combine the distribute list command with a route-map to give us more flexibility in matching routing table entries. With a route-map on our distribute-list we can use the following options:

• match interface
• match ip address
• match ip next-hop
• match ip route-source
• match metric
• match route-type
• match tag

Let’s use the match ip address in conjunction with a prefix-list so we can be more flexible with what gets permitted into our routing table.

Let’s verify the current routing table before we proceed:

R5#sh ip route | b Gateway
Gateway of last resort is not set

     1.0.0.0/32 is subnetted, 1 subnets
O IA    1.1.1.1 [110/21] via 10.1.35.3, 00:00:07, Ethernet1/0
     2.0.0.0/32 is subnetted, 1 subnets
O IA    2.2.2.2 [110/21] via 10.1.35.3, 00:00:07, Ethernet1/0
     3.0.0.0/32 is subnetted, 1 subnets
O IA    3.3.3.3 [110/11] via 10.1.35.3, 00:00:07, Ethernet1/0
     4.0.0.0/32 is subnetted, 1 subnets
O       4.4.4.4 [110/11] via 10.1.45.4, 00:00:07, Ethernet1/1
     5.0.0.0/32 is subnetted, 1 subnets
C       5.5.5.5 is directly connected, Loopback0
     10.0.0.0/24 is subnetted, 6 subnets
O IA    10.0.12.0 [110/30] via 10.1.35.3, 00:00:07, Ethernet1/0
O IA    10.0.13.0 [110/20] via 10.1.35.3, 00:00:07, Ethernet1/0
O IA    10.0.23.0 [110/20] via 10.1.35.3, 00:00:08, Ethernet1/0
C       10.1.45.0 is directly connected, Ethernet1/1
C       10.1.35.0 is directly connected, Ethernet1/0
O       10.1.34.0 [110/20] via 10.1.45.4, 00:00:08, Ethernet1/1
                  [110/20] via 10.1.35.3, 00:00:08, Ethernet1/0

You can see in the routing table above we have complete connectivity in our little network. We will use a distribute-list, this time with a route-map to deny all the 10.0.0.0/16 networks (ie. 10.0.12.0/24, 10.0.13.0/24 and 10.0.23.0/24 networks).

R5:

router ospf 1
  distribute-list route-map NO_AREA0 in
!
ip prefix-list AREA0 seq 5 deny 10.0.0.0/16 le 32
ip prefix-list AREA0 seq 10 permit 0.0.0.0/0 le 32
!
route-map NO_AREA0 permit 10
 match ip address prefix-list AREA0

The distribute-list above uses a route-map to deny any networks in the 10.0.0.0/16 supernet. This will cover the 10.0.12.0, 10.0.13.0/24 and 10.0.23.0/24 networks that we want to filter. Everything else will be allowed into our routing table. Let’s verify this:

R5#sh ip route | b Gateway
Gateway of last resort is not set

     1.0.0.0/32 is subnetted, 1 subnets
O IA    1.1.1.1 [110/21] via 10.1.35.3, 00:00:02, Ethernet1/0
     2.0.0.0/32 is subnetted, 1 subnets
O IA    2.2.2.2 [110/21] via 10.1.35.3, 00:00:02, Ethernet1/0
     3.0.0.0/32 is subnetted, 1 subnets
O IA    3.3.3.3 [110/11] via 10.1.35.3, 00:00:02, Ethernet1/0
     4.0.0.0/32 is subnetted, 1 subnets
O       4.4.4.4 [110/11] via 10.1.45.4, 00:00:02, Ethernet1/1
     5.0.0.0/32 is subnetted, 1 subnets
C       5.5.5.5 is directly connected, Loopback0
     10.0.0.0/24 is subnetted, 3 subnets
C       10.1.45.0 is directly connected, Ethernet1/1
C       10.1.35.0 is directly connected, Ethernet1/0
O       10.1.34.0 [110/20] via 10.1.45.4, 00:00:03, Ethernet1/1
                  [110/20] via 10.1.35.3, 00:00:03, Ethernet1/0

The distribute list should not effect the topology database as it only filters routes coming into the route table.

R5#sh ip ospf data

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

                Router Link States (Area 1)

Link ID         ADV Router      Age         Seq#       Checksum Link count
3.3.3.3         3.3.3.3         1791        0x8000000D 0x00C462 2
4.4.4.4         4.4.4.4         1794        0x8000000E 0x0040A7 3
5.5.5.5         5.5.5.5         1780        0x8000000B 0x00FED9 3

                Net Link States (Area 1)

Link ID         ADV Router      Age         Seq#       Checksum
10.1.34.3       3.3.3.3         1791        0x80000009 0x004099
10.1.35.5       5.5.5.5         1780        0x80000009 0x00F6D3
10.1.45.5       5.5.5.5         1780        0x80000009 0x00BA02

                Summary Net Link States (Area 1)

Link ID         ADV Router      Age         Seq#       Checksum
1.1.1.1         3.3.3.3         1791        0x80000009 0x005FBA
2.2.2.2         3.3.3.3         1791        0x80000009 0x0031E4
3.3.3.3         3.3.3.3         1791        0x80000009 0x009E7D
10.0.12.0       3.3.3.3         1791        0x80000009 0x00E01E
10.0.13.0       3.3.3.3         1792        0x80000009 0x007196
10.0.23.0       3.3.3.3         1792        0x80000009 0x0003FA

Awesome! It worked as anticipated. We still have a complete topology database, however we have successfully filtered the 10.0.12.0/24, 10.0.13.0/24 and 10.0.23.0/24 networks from the route table.

Let’s reset the configuration on R5 before we proceed:

R5#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R5(config)#no route-map NO_AREA0 permit 10
R5(config)#no ip prefix-list AREA0
R5(config)#router ospf 1
R5(config-router)#no  distribute-list route-map NO_AREA0 in
R5(config-router)#end

Using Administrative Distance

We can also filter routes within an OSPF area by changing the the administrative distance of routes to 255 (an invalid route). We can use the distance command to do this.

Let’s take a look at an example.
R5:

router ospf 1
 distance 255 0.0.0.0 255.255.255.255 1
!
access-list 1 permit 3.3.3.3

The example above shows the use of the distance command to filter routes in an OSPF area. The command states that any routes from any router that matches the access-list 1 (ie. the 3.3.3.3/32 network) will be given a administrative distance of 255 (invalid).

The result of this is that the 3.3.3.3/32 network will be filtered from entering the routing table. Let’s verify this:

R5#clear ip route *
R5#sh ip route | b Gateway
Gateway of last resort is not set

     1.0.0.0/32 is subnetted, 1 subnets
O IA    1.1.1.1 [110/21] via 10.1.35.3, 00:00:01, Ethernet1/0
     2.0.0.0/32 is subnetted, 1 subnets
O IA    2.2.2.2 [110/21] via 10.1.35.3, 00:00:01, Ethernet1/0
     4.0.0.0/32 is subnetted, 1 subnets
O       4.4.4.4 [110/11] via 10.1.45.4, 00:00:01, Ethernet1/1
     5.0.0.0/32 is subnetted, 1 subnets
C       5.5.5.5 is directly connected, Loopback0
     10.0.0.0/24 is subnetted, 6 subnets
O IA    10.0.12.0 [110/30] via 10.1.35.3, 00:00:01, Ethernet1/0
O IA    10.0.13.0 [110/20] via 10.1.35.3, 00:00:01, Ethernet1/0
O IA    10.0.23.0 [110/20] via 10.1.35.3, 00:00:01, Ethernet1/0
C       10.1.45.0 is directly connected, Ethernet1/1
C       10.1.35.0 is directly connected, Ethernet1/0
O       10.1.34.0 [110/20] via 10.1.45.4, 00:00:01, Ethernet1/1
                      [110/20] via 10.1.35.3, 00:00:01, Ethernet1/0

Looks great! We have routes for everything except for the 3.3.3.3/32 network. This should have not affected the topology database. Lets verify this:

R5#sh ip ospf data

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

                Router Link States (Area 1)

Link ID         ADV Router      Age         Seq#       Checksum Link count
3.3.3.3         3.3.3.3         964         0x8000000E 0x00C263 2
4.4.4.4         4.4.4.4         978         0x8000000F 0x003EA8 3
5.5.5.5         5.5.5.5         985         0x8000000C 0x00FCDA 3

                Net Link States (Area 1)

Link ID         ADV Router      Age         Seq#       Checksum
10.1.34.3       3.3.3.3         964         0x8000000A 0x003E9A
10.1.35.5       5.5.5.5         985         0x8000000A 0x00F4D4
10.1.45.5       5.5.5.5         985         0x8000000A 0x00B803

                Summary Net Link States (Area 1)

Link ID         ADV Router      Age         Seq#       Checksum
1.1.1.1         3.3.3.3         964         0x8000000A 0x005DBB
2.2.2.2         3.3.3.3         964         0x8000000A 0x002FE5
3.3.3.3         3.3.3.3         964         0x8000000A 0x009C7E
10.0.12.0       3.3.3.3         964         0x8000000A 0x00DE1F
10.0.13.0       3.3.3.3         965         0x8000000A 0x006F97
10.0.23.0       3.3.3.3         965         0x8000000A 0x0001FB

Nice! It worked as anticipated. We successfully filtered the route from entering the routing table but not the topology database.

When you perform route filtering within an OSPF area with the distribute-list and distance commands you are filtering routes as they enter the route-table, not the topology database. The topology database must be consistent within an area for the Dijkstra’s shortest path first algorithm to work correctly. It does not affect LSA propagation.

That’s it for filtering with an OSPF area. In the next article we will be looking at filtering between areas. Stay tuned. Now back to labs!

Summary:

• You can use a distribute-list or distance command to filter routes within an area.
• The distribute-list and distance commands filter routes as they enter the routing-table not the topology database.
• The distribute-list and distance commands do not affect link state packet progagation

Resources:

• Dynamips/Dynagen .net configuration file

Related posts

• Tutorial: Filtering Routes in OSPF Part 2 » Filtering Between Areas Using area filter-list
• Tutorial: Time-Based ACLS
• Tutorial: OSPF Network Types and Frame Relay Part 5
• Tutorial: IPv6 Tunnels Part 2 - Automatic 6to4 Tunnels

© 2008 Arden Packeer. All rights reserved. The opinions expressed herein are my own personal opinions and do not represent my employer's view in anyway. This material is not sponsored or endorsed by Cisco Systems, Inc. Cisco, Cisco Systems, CCIE and the CCIE Logo are trademarks of Cisco Systems, Inc. and its affiliates