Cisco IOS Access Lists

Alternatives to access lists

As I have mentioned, the CPU costs imposed by access lists can be significant. In addition, access lists take time to administer. Some alternatives to access lists can reduce CPU costs, while others simply limit the number of access lists you need to manage. I cover these alternatives in this section.

Static routing

One common technique for replacing access lists is to use static routes. You can set route preferences on routers that you administer by explicitly configuring routes. Since static routes by default have a more preferable administrative distance than any dynamic routing protocol, configuring a static route to a network can cause a router to ignore any dynamic routing protocol’s routing update to that network.

The simplest way to eliminate access lists for routing policies is to completely remove the dynamic routing protocols and use static routes everywhere. This may be possible in simple networks like the one shown in Figure 4.2. You can configure static routes on the central router and define fixed routes to all of the networks in a central location. Static routes explicitly define routing policies, so you do not need to use access lists to filter routing updates.

As a network becomes more complex, a purely static routed network might become difficult to manage. Still, to reduce the use of access lists a combination of dynamic and static routes is possible. With stub networks, for example, connections between the stub networks and the transit or default network can be static routed, eliminating the need for dynamic routing protocols and routing access lists. Let’s revisit Figure 4.9 and see how we can use static routes instead of access lists. Recall that a key issue in this network was making sure the site networks did not advertise a network they did not own. To see how this occurs with static routes, let’s say that Router 1’s serial interface uses IP address 192.168.12.1 and Router 3’s serial interface has IP address 192.168.12.2. Router 4’s serial interface to Site E has IP address 192.168.13.1, and Router 6’s serial interface has IP address 192.168.13.2. Router 1 would use the following configuration to define its routing:

default-network 172.28.0.0 192.168.12.2
ip route 172.28.0.0 255.255.0.0
router rip 
network 19.0.0.0
redistribute static

Since 172.28.0.0/16 is the central transit network for this intranet, we define it as the default network and set up a default route to Router 3. We then redistribute our default network within Site D. We define network 19.0.0.0 in the routing statement, but not network 192.168.12.0/24. This causes the RIP routing process to send and listen to RIP routing updates only on interfaces that are on network 19.0.0.0. Therefore, Router 1 does not send routing updates out of its serial link to Router 3 or listen to any updates on that interface. This configuration saves considerable CPU resources on the router, since there are fewer router updates to process, and no route filtering to be done.

Router 3 would use the following configuration:

ip route 19.0.0.0 255.0.0.0 192.168.12.1
router rip
network 172.28.0.0
redistribute static

The route to network 19.0.0.0 is hardcoded into the router’s configuration, so no route update can change it. As with Router 1, there is no network 192.168.12.0 statement. This means that Router 3 does not send updates out of its serial interface to Site D or listen to any updates from it. Our policy to maintain network robustness is enforced by the static routes and careful redistribution, instead of an access list and a distribute-list statement.

Continuing with our example, Router 6 has a configuration very similar to Router 1:

default-network 172.28.0.0 
ip route 172.28.0.0 255.255.0.0 192.168.13.1
router rip 
network 10.0.0.0
redistribute static

while Router 4 is configured like Router 3, with a static route replacing the access list and distribute-list statement:

ip route 10.0.0.0 255.0.0.0 192.168.13.2
router rip
network 172.28.0.0
redistribute static

Implementing route preference with static routes

We can also use static routes to implement routing preferences through route elimination. In the example associated with Figure 4.14, we used distribute-list statements and an access list to force traffic between network 10.0.0.0/8 and 172.20.0.0/16 over an encrypted path. If the serial interface on Router 2 connecting to Router 3 uses IP address 192.168.10.2, then the following static route on Router 3 will force traffic to network 10.0.0.0/8 over the encrypted network path:

ip route 10.0.0.0 255.0.0.0 192.168.10.2

We would also have to put in a similar static route from Router 1 to Router 2 for the traffic from network 10.0.0.0/8 to use the encrypted path. Note that this use of static routes to implement a routing policy only works if we have administrative control or influence over Router 1 and Router 3. If we can’t have Router 1 configured with a static route, we’ll have to use distribute-list statements as we did originally.

Floating static routes

You can change the administrative distance of a static route to create what is called a floating static route. Floating static routes can be used to define a backup route and thus to implement routing preferences. Let’s revisit Figure 4.14. In this figure, we prefer that traffic between network 10.0.0.0/8 and 172.20.0.0/16 go through the larger bandwidth path. Let’s say that the 56-Kb serial line between networks 10.0.0.0/8 and 172.20.0.0/16 has IP addresses 192.168.15.2 at the network 10.0.0.0/8 side and 192.168.15.3 at Router 2. The IP address of serial 1 on Router 2 is 192.168.16.3, and the IP address of the serial interface on Router 1 leading to Router 2 is 192.168.11.2. We can define the following static route and router configuration on Router 2:

ip route 172.20.0.0 255.255.0.0 192.168.15.2 121
router rip
network 192.168.16.0

The static route is set to have an administrative distance of 121. Only network 192.168.16.0 is defined to send and receive RIP routing updates. The result is that Router 2 will hear a route to network 10.0.0.0/8 via RIP only through the higher bandwidth path. Since we set administrative distance of the static route to be higher than that of default RIP updates, the RIP update takes precedence. If the 1.544-Mb line goes down, then the static route over the smaller bandwidth path is used. To take care of traffic in the other direction, from network 10.0.0.0/8 to network 172.28.0.0/16, a similar setup needs to be done on the router connecting network 10.0.0.0/8 to Router 1.

Compared to our earlier policy implementation, the floating static route is much simpler. So why would we use the first implementation? Again, the issue is administrative control. The first implementation works if the network administrator of Router 2 does not have administrative control over network 10.0.0.0/8 routers. The floating static route technique works only if a floating static route is set up at network 10.0.0.0/8.

Static routes to the null device

Another simple way to deny routing updates from a given network is to route the network to the null interface. For example, if we wanted to deny all routing updates to network 192.168.30.0/24, we could set up the following static route:

ip route 192.168.30.0 255.255.255.0 Null0

Using this technique can conserve router resources since the router no longer needs to use access lists to filter route updates containing this network.

You have to be careful about redistributing the static route for a network routed to Null0. You can easily advertise a route that will cause all of the traffic to a network to be dropped. For if we redistributed the previous static route into another routing protocol, all packets destined for network 192.168.30.0/24 could get sent to a router that would simply drop them.

Denying all route updates in or out of an interface

Denying all routing updates through an interface is such a common operation that there are Cisco configuration commands designed to provide these functions.

Often you may not want to send routing updates out of an interface. This may be because there are no systems that need to listen to your routing broadcasts, or you may not want routers on that interface to send traffic through. Whatever the reason, you can use the passive-interface command to stop sending routing updates out of a specific interface. Let’s look once again at the network in Figure 4.10. In this network, we don’t need to broadcast routing updates on the host segments. In the original policy implementation, I created a policy set with nothing in it and used that policy set to stop route advertisements. passive-interface can have the same effect:

access-list 1 deny any
access-list 2 permit 192.168.29.0
access-list 2 permit 192.168.30.0 0.0.1.0
!
router eigrp 10
 network 192.168.20.0
 network 192.168.29.0
 network 192.168.30.0
 network 192.168.31.0
! no routes to the host segments
passive-interface Ethernet 1/0
passive-interface Ethernet 1/1
passive-interface Ethernet 1/2
! no routes from the host segments
 distribute-list 1 in Ethernet 1/0
 distribute-list 1 in Ethernet 1/1
 distribute-list 1 in Ethernet 1/2
! advertise only connected routes 
 distribute-list 2 out fast 0/0

The passive-interface command saves significant CPU resources when compared with the way I previously implemented this policy. Instead of examining all of the routes it knows about and then not sending any of them out, the router simply doesn’t try to send any routes out of the three Ethernet interfaces at all.

Using distance to ignore updates

In this example, we also do not want to receive any updates from the host segments. A more elegant way to do that is to use the distance statement. If we set the administrative distance of any routing update from the host segments to 255, then any routing update from those segments is ignored. The complete configuration then becomes:

access-list 2 permit 192.168.29.0
access-list 2 permit 192.168.30.0 0.0.1.0
!
router eigrp 10
network 192.168.20.0
network 192.168.29.0
network 192.168.30.0
network 192.168.31.0
! no routes to the host segments
passive-interface Ethernet 1/0
passive-interface Ethernet 1/1
passive-interface Ethernet 1/2
! no routes from the host segments
distance 192.168.29.0 0.0.0.0 255
distance 192.168.30.0 0.0.0.1 255
! advertise only connected routes 
distribute-list 2 out fast 0/0

Using distance doesn’t save as much CPU as the previous change. If there are route updates from the host segments, the router still must look at them in order to assign the administrative distance of 255. It does simplify and reduce the size of the configuration, however, which can be a significant improvement in some situations.

Omitting network statements

Notice that we don’t want to send or receive routing updates from the host segments. For segments like these, there is one more access list alternative that is more elegant and can save even more router CPU cycles. Recall that in a routing process definition, the network statement is used to indicate which interfaces will send and receive routing updates. Since we don’t want any routing update activity on the host segments, we can omit the network statements of host segments:

access-list 2 permit 192.168.29.0
access-list 2 permit 192.168.30.0 0.0.1.0
router eigrp 10
network 192.168.20.0
! advertise only connected routes 
distribute-list 2 out fast 0/0

Omitting the network statements saves the router a lot of processing because the interfaces for the host segments are not involved in routing activity at all.