Skip to content

OSPF discard route

December 3, 2011
By Administrator in All, Routing protocols

This article illustrates a practical usage of the OSPF discard route concept. In order to follow this article it might be useful to take a look at our previous post on the OSPF forwarding address. The diagram below shows the network topology used for the purposes of this article.

Network topology diagram

Network topology diagram

Routers R1 and R3 each have one link in area 0 and one link in area 1. Router R2 has all its links in area 2.

Before we start the real example I’ll explain two points that are of vital importance. First – how to permit a single host (subnet), while blocking the rest of the network (supernet). And second – how to install a route in the routing table, only if another route is present. The need for these prerequisites will become evident later.

Permit a single host while blocking the network

To block access to the network we split it into two subnets, write two static discard routes and redistribute them into OSPF (already described in my previous post). They will be preferred over the OSPF originated route because they are more specific. The next-hop address for these routes is a free IP address from the loopback0 address space (10.0.0.0/24). I’ve chosen the IP address 10.0.0.100. Then, we configure a host route for 10.0.0.100 on all routers directing it to Null. The commands to block access to 10.30.0.0/24 are as follows:

R1
R1#conf t
R1(config)#ip route 10.30.0.0 255.255.255.128 10.0.0.100
R1(config)#ip route 10.30.0.128 255.255.255.128 10.0.0.100
R1(config)#ip route 10.0.0.100 255.255.255.255 null0
R1(config)#router ospf 1
R1(config-router)#redistribute static subnets

On R2 and R3 we need to add a discard route for 10.0.0.100/32 and now all packets for this subnet will be discarded. Nothing new so far. To permit a single host we write a host route with next-hop the loopback0 interface of the router the subnet is attached to. In our topology this is R2 and the configuration is as follows:

R2
R2(config)#ip route 10.30.0.1 255.255.255.255 10.0.0.2

Because this route is more specific, the packets will be routed as usual while all other hosts in the subnet will be matched by the less specific routes for the subnets and eventually dropped. Let’s check R3 routing table:

R3
R3#sh ip route
Gateway of last resort is not set

     10.0.0.0/8 is variably subnetted, 10 subnets, 3 masks
C       10.0.2.0/24 is directly connected, FastEthernet0/0
C       10.0.3.0/24 is directly connected, FastEthernet0/1
C       10.0.0.0/24 is directly connected, Loopback0
O       10.0.0.1/32 [110/3] via 10.0.3.1, 00:02:50, FastEthernet0/1
O       10.0.1.0/24 [110/2] via 10.0.3.1, 00:02:50, FastEthernet0/1
O       10.30.0.1/32 [110/2] via 10.0.3.1, 00:02:50, FastEthernet0/1
O E2    10.30.0.0/25 [110/20] via 10.0.0.100, 00:00:46, Loopback0
O       10.30.0.0/24 [110/2] via 10.0.3.1, 00:02:50, FastEthernet0/1
O E2    10.30.0.1/32 [110/20] via 10.0.0.2, 00:01:54, Loopback0
O E2    10.30.0.128/25 [110/20] via 10.0.0.100, 00:00:23, Loopback0

As expected we have two E2 routes with a 25 bit mask and a next-hop address of 10.0.0.100 (discard routes) and one host route to 10.30.0.1 with a next-hop address of 10.0.0.2. If we had not added the static route, the host route for this loopback would still be present due to loopback interface behavior in OSPF. But this is of no importance for the current example.

However, there is a problem with this approach of static routes to loopback0. If the router directly connected to subnet is down, all other routers will continue to send packets to the ASBR. In turn, it will forward traffic further, congesting the network and possibly creating loops. It is time for the second point.

Static routing brush-up

Static routes are recursive by nature. The static route is kept in the routing table as long as the next-hop is reachable i.e. there is a route to it. But with classless routing the route to the next-hop may even be through the default route. In a situation where the next-hop is not on a directly connected network (and in some cases even if it is) it will always be reachable through less specific routes including the default route. As a consequence, even if the next-hop IP address is down, the static route is kept in the routing table. For instance, remember the default route configured to the ISP which is used as long as the outgoing interface is up.

Route tracking

In this scenario I wish to keep the static route only if the next-hop IP address is reachable. The next hop address is a loopback interface and is advertized by OSPF as a host route. So, before installing the static route with this next-hop address, we have to make sure that we have a valid OSPF host route. Cisco routers have a feature called enhanced object tracking which will help us to track routes. First we configure the tracking object on R1. It will check if the route to loopback0 (10.0.0.2/32) on R2 is present. We also set the delay for removal and installation in the routing table to 1 second for faster convergence:

R1
R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#track 1 ip route 10.0.0.2 255.255.255.255 reachability
R1(config-track)#delay down 1 up 1

Then, we may change the polling interval so that the routing table is checked more frequently:

R1
R1(config)#track timer ip route 2

And at last we have to rewrite the route using object tracking:

R1
R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#no ip route 10.30.0.1 255.255.255.255 10.0.0.2
R1(config)#ip route 10.30.0.1 255.255.255.255 10.0.0.2 track 1

Verification

To verify the mechanism of route tracking we go to R2 and shut down loopback0:

R2
R2#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R2(config)#int loopback 0
R2(config-if)#shut
R2(config-if)#
02:10:42: %LINK-5-CHANGED: Interface Loopback0, changed state to
administratively down
02:10:43: %LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback0,
changed state to downexit

Then we check R1 routing table:

R1
R1#sh ip route

Gateway of last resort is 10.0.2.2 to network 0.0.0.0

     10.0.0.0/8 is variably subnetted, 9 subnets, 3 masks
C       10.0.2.0/24 is directly connected, FastEthernet1/1
O       10.0.3.0/24 [110/2] via 10.0.1.2, 00:00:08, FastEthernet1/0
O       10.0.0.3/32 [110/3] via 10.0.1.2, 00:00:08, FastEthernet1/0
C       10.0.0.0/24 is directly connected, Loopback0
C       10.0.1.0/24 is directly connected, FastEthernet1/0
O       10.30.0.1/32 [110/2] via 10.0.1.2, 00:00:08, FastEthernet1/0
S       10.30.0.0/25 [1/0] via 10.0.0.100
O       10.30.0.0/24 [110/2] via 10.0.1.2, 00:00:08, FastEthernet1/0
S       10.30.0.128/25 [1/0] via 10.0.0.100
O*E2 0.0.0.0/0 [110/1] via 10.0.2.2, 00:00:08, FastEthernet1/1

Both routes to 10.0.0.2 and the static route to 10.30.0.1 are not present. And the track object:

R1
R1#sh track 1
Track 1
  IP route 10.0.0.2 255.255.255.255 reachability
  Reachability is Down (no route)
    5 changes, last change 00:01:04
  Delay up 1 sec, down 1 sec
  First-hop interface is unknown
  Tracked by:
    STATIC-IP-ROUTING 0

If we change R2 loopback0 back to up, the output of the above commands is as follows:

R1
R1#show track 1
Track 1
  IP route 10.0.0.2 255.255.255.255 reachability
  Reachability is Up (OSPF)
    4 changes, last change 00:00:09
  Delay up 1 sec, down 1 sec
  First-hop interface is FastEthernet1/0
  Tracked by:
    STATIC-IP-ROUTING 0

Now the state of object 1 has changed to up and the route to 10.0.0.2 is advertized by OSPF. And the second command:

R1
R1#show ip route
Gateway of last resort is 10.0.2.2 to network 0.0.0.0

     10.0.0.0/8 is variably subnetted, 11 subnets, 3 masks
C       10.0.2.0/24 is directly connected, FastEthernet1/1
O       10.0.0.2/32 [110/2] via 10.0.1.2, 00:02:04, FastEthernet1/0
O       10.0.3.0/24 [110/2] via 10.0.1.2, 00:02:04, FastEthernet1/0
O       10.0.0.3/32 [110/3] via 10.0.1.2, 00:02:04, FastEthernet1/0
C       10.0.0.0/24 is directly connected, Loopback0
C       10.0.1.0/24 is directly connected, FastEthernet1/0
O       10.30.0.1/32 [110/2] via 10.0.1.2, 00:02:04, FastEthernet1/0
S       10.30.0.0/25 [1/0] via 10.0.0.100
O       10.30.0.0/24 [110/2] via 10.0.1.2, 00:02:04, FastEthernet1/0
S       10.30.0.1/32 [1/0] via 10.0.0.2
S       10.30.0.128/25 [1/0] via 10.0.0.100
O*E2 0.0.0.0/0 [110/1] via 10.0.2.2, 00:01:54, FastEthernet1/1

There is a static route to 10.30.0.1/32 and an OSPF internal route to 10.0.0.2/32.

A point about redistribution

How does this route tracking prevent static route redistribution? It does because only routes present in the routing table are redistributed. Below is the command output from R3 when 10.0.0.2 is down:

R3
R3#sh ip route

Gateway of last resort is not set

     10.0.0.0/8 is variably subnetted, 10 subnets, 3 masks
C       10.0.2.0/24 is directly connected, FastEthernet0/0
C       10.0.3.0/24 is directly connected, FastEthernet0/1
C       10.0.0.0/24 is directly connected, Loopback0
O       10.0.0.1/32 [110/3] via 10.0.3.1, 00:04:41, FastEthernet0/1
O       10.0.1.0/24 [110/2] via 10.0.3.1, 00:04:41, FastEthernet0/1
O       10.30.0.1/32 [110/2] via 10.0.3.1, 00:04:41, FastEthernet0/1
O E2    10.30.0.0/25 [110/20] via 10.0.0.100, 00:04:31, Loopback0
O       10.30.0.0/24 [110/2] via 10.0.3.1, 00:04:41, FastEthernet0/1
S       10.0.0.100/32 is directly connected, Null0
O E2    10.30.0.128/25 [110/20] via 10.0.0.100, 00:04:31, Loopback0

Neither the route to 10.0.0.2 nor the route to 10.30.0.1 is present (see the first “show ip route” for R1 from above).

General implementation guidelines

One advantage of using OSPF discard routes for access restrictions is the simple procedure of adding and removing nodes to the “discard route” domain. Although static routes are advertized throughout the OSPF domain, to use them the receiving router must have a loopback interface in the 10.0.0.0/24 subnet in order to have the next-hop address on a directly connected interface. To join a router we have to do two things:

  • configure a loopback in the 10.0.0.0/24 subnet
  • configure a static host route to Null for the next-hop IP address 10.0.0.100

To unsubscribe a router:

  • shutdown/delete the loopback interface
  • delete the route for 10.0.0.100 (optional)

Having explained the two tricks about static routes, I’d like to say a few words about the preliminary considerations before implementing traffic filtering through OSPF discard routes. If we wish to use it instead of the classic ACLs, we have to be aware of several restrictions. First, we can only block destination addresses. Second, we have to substitute all permit ACL entries with deny entries. Sometimes this is not practical or even it is not feasible. And third, we have to remember that all subnets not explicitly discarded are routed the normal way e.g. “permitted”, which is just the opposite of ACLs. With these precautions in mind we go to a real word example.

A real world example

Below is a “real” ACL which I have changed a little to suite our study purposes:

ip access-list extended TEST
 remark =================HOSTS=========================
 permit ip 10.30.0.0 0.0.255.255 host 10.30.2.12
 permit ip 10.30.0.0 0.0.255.255 host 10.30.14.22
 permit ip 10.30.0.0 0.0.255.255 host 10.40.8.11
 permit ip 10.30.0.0 0.0.255.255 host 10.60.3.36
 remark =================BRANCHES==================
 permit ip 10.30.0.0 0.0.255.255 10.30.0.0 0.0.3.255
 permit ip 10.30.0.0 0.0.255.255 10.30.5.0 0.0.0.255
 permit ip 10.30.0.0 0.0.255.255 10.30.6.0 0.0.0.255
 permit ip 10.30.0.0 0.0.255.255 10.30.32.0 0.0.0.255
 permit ip 10.30.0.0 0.0.255.255 10.30.40.0 0.0.0.255
 permit ip 10.30.0.0 0.0.255.255 10.30.48.0 0.0.0.255
 permit ip 10.30.0.0 0.0.255.255 10.30.52.0 0.0.0.255
 permit ip 10.30.0.0 0.0.255.255 10.30.56.0 0.0.0.255
 permit ip 10.30.0.0 0.0.255.255 10.30.60.0 0.0.0.255
 permit ip 10.30.0.0 0.0.255.255 10.30.64.0 0.0.0.255
 permit ip 10.30.0.0 0.0.255.255 10.30.73.0 0.0.0.255
 permit ip 10.30.0.0 0.0.255.255 10.30.102.0 0.0.0.255
 permit ip 10.30.0.0 0.0.255.255 10.30.103.0 0.0.0.255
 permit ip 10.30.0.0 0.0.255.255 10.30.104.0 0.0.0.255
 permit ip 10.30.0.0 0.0.255.255 10.30.109.0 0.0.0.255
 permit ip 10.30.0.0 0.0.255.255 10.30.112.0 0.0.0.255
 permit ip 10.30.0.0 0.0.255.255 10.30.120.0 0.0.0.255
 permit ip 10.30.0.0 0.0.255.255 10.30.129.0 0.0.0.255
 permit ip 10.30.0.0 0.0.255.255 10.30.140.0 0.0.0.255
 permit ip 10.30.0.0 0.0.255.255 10.30.144.0 0.0.0.255
 permit ip 10.30.0.0 0.0.255.255 10.30.148.0 0.0.0.255
 permit ip 10.30.0.0 0.0.255.255 10.30.152.0 0.0.0.255
 permit ip 10.30.0.0 0.0.255.255 10.30.160.0 0.0.0.255
 permit ip 10.30.0.0 0.0.255.255 10.30.176.0 0.0.0.255
 permit ip 10.30.0.0 0.0.255.255 10.30.180.0 0.0.0.255
 permit ip 10.30.0.0 0.0.255.255 10.30.192.0 0.0.0.255
 permit ip 10.30.0.0 0.0.255.255 10.30.200.0 0.0.0.255
 permit ip 10.30.0.0 0.0.255.255 10.30.208.0 0.0.0.255
 permit ip 10.30.0.0 0.0.255.255 10.30.219.0 0.0.0.255
 permit ip 10.30.0.0 0.0.255.255 10.30.224.0 0.0.0.255
 permit ip 10.30.0.0 0.0.255.255 10.30.232.0 0.0.0.255
 permit ip 10.30.0.0 0.0.255.255 10.30.238.0 0.0.0.255
 permit ip 10.30.0.0 0.0.255.255 10.30.240.0 0.0.0.255
 permit ip 10.30.0.0 0.0.255.255 10.30.244.0 0.0.0.255
 permit ip 10.30.0.0 0.0.255.255 10.30.248.0 0.0.0.255
 remark =================SERVERS==============================
 permit ip 10.30.0.0 0.0.255.255 10.2.0.0 0.0.0.255
 permit ip 10.30.0.0 0.0.255.255 10.240.7.0 0.0.0.255
 permit ip 10.30.0.0 0.0.255.255 10.240.8.0 0.0.0.255
 permit ip 10.30.0.0 0.0.255.255 10.241.4.0 0.0.0.255
 remark =============INTERNET=================================
 deny   ip 10.30.0.0 0.0.255.255 10.0.0.0 0.255.255.255
 permit ip 10.30.0.0 0.0.255.255 any

It is the most unsuitable candidate for practical implementation of the method presented. Why? Because if we rewrite the ACL to contain only deny statements, we have to write a deny statement for EVERY subnet in the routing table within the 10.0.0.0/8 network except for the explicitly permitted! This is very impractical to say the least. Moreover we are not able to block by source address. But still we can take advantage and reduce the ACL to several lines. We also can take advantage of centralized management and dynamic “ACL” updates. Because the majority of permit entries are for the 10.30.0.0/16 subnet we can rewrite it as follows:

ip access-list extended TEST
 remark =============BRANCHES=======================
 permit 10.30.0.0 0.0.255.255 10.30.0.0 0.0.255.255
 remark =================SERVERS==============================
 permit ip 10.30.0.0 0.0.255.255 10.2.0.0 0.0.0.255
 permit ip 10.30.0.0 0.0.255.255 10.240.7.0 0.0.0.255
 permit ip 10.30.0.0 0.0.255.255 10.240.8.0 0.0.0.255
 permit ip 10.30.0.0 0.0.255.255 10.241.4.0 0.0.0.255
 remark =================HOSTS=========================
 permit ip 10.30.0.0 0.0.255.255 host 10.40.8.11
 permit ip 10.30.0.0 0.0.255.255 host 10.60.3.36
 remark =================INTERNET=========================
 deny ip 10.30.0.0 0.0.255.255 10.0.0.0 0.255.255.255
 permit any any

The new ACL is still applied locally on the router. The missing entries will be centrally managed and dynamically updated on an ABR router. Now, we have to add a host route for every permitted host within 10.30.0.0/16 and two discard routes for the network containing the hosts. In our scenario the hosts are 10.30.2.12 and 10.30.14.22 and the corresponding networks – 10.30.2.0/24 and 10.30.14.0/24.

Then, add two discard routes for every subnet within 10.30.0.0/16 which is not explicitly permitted and is in the routing table. A discard route for 10.30.0.0/16 will block all traffic for unknown subnets.

Suppose we have only 10.30.100.0/23 in the routing table which is not permitted by the ACL. If a new network is created, however, we have to remember that by default it will be routed normally. To block it, we have to write discard routes.

Below are the static routes to be configured on the ABR router R1 with a fictional next-hop and corresponding track objects:

track objects
track 1 ip route 10.0.0.20 255.255.255.255 reachability
track 2 ip route 10.0.0.21 255.255.255.255 reachability

conditional static host routes
ip route 10.30.2.12 255.255.255.255 10.0.0.20 track 1
ip route 10.30.14.22 255.255.255.255 10.0.0.21 track 2

discard routes for host subnets
ip route 10.30.2.0 255.255.255.128 10.0.0.100
ip route 10.30.2.128 255.255.255.128 10.0.0.100
ip route 10.30.14.0 255.255.255.128 10.0.0.100
ip route 10.30.14.128 255.255.255.128 10.0.0.100

discard routes for 10.30.100.0/23
ip route 10.30.100.0 255.255.255.0 10.0.0.100
ip route 10.30.100.0 255.255.255.0 10.0.0.100

discard route for 10.30.0.0/16
ip route 10.30.0.0 255.255.0.0 10.0.0.100

Tags: , , , , ,

Comment Feed

No Responses (yet)



Some HTML is OK

or, reply to this post via trackback.