Cisco IOS Access Lists

Implementing route preferences

Earlier in this chapter, I talked about the strategy of implementing route preferences. In this section, I discuss and show examples of how to implement them. I start with the basic example of simply eliminating routes and move on to more complex examples of using offset-list statements to alter routing metrics and altering route administrative distances based on the sources of routing updates.

Eliminating undesired routes

The simplest way to prefer routes is to prevent the routes that are not preferred from being accepted by a router at all. Let’s look at Figure 4.13 for an example.

Figure 4-13. Ignoring routes through an unencrypted path

In this part of an intranet, Routers 1 and 2 send routing updates for the networks 172.18.0.0/16, 172.19.0.0/16, and 10.0.0.0/8 to Router 3 through Router 3’s serial interfaces 0 and 1. Both Router 1 and Router 2 have routes to network 10.0.0.0/8, Router 1 via Path A and Router 2 via Path B. In this intranet, the network administrators try to encrypt all of the serial links between networks wherever they can to safeguard their intranet from eavesdropping. They generally succeed except for the paths leading to network 172.18.0.0/16, such as Path A, which is in one of a number of countries where encryption is heavily controlled. The network administrators accept this fact by setting the following policy:

Only traffic to and from 172.18.0.0/16 should go through Router 1

Traffic between networks 10.0.0.0/8 and 172.20.0.0/16 should not go through Router 1. Traffic between network 10.0.0.0/8 and network 172.19.0.0/16 (in case Path B goes down) also should not go through Router 1. What are the implications for Router 3? Router 3 needs to make sure that traffic to networks 10.0.0.0/8 and 172.19.0.0/16 does not go over the unencrypted Path A. Thus, traffic from Router 3 to network 10.0.0.0/8 should use Path B, and traffic to network 172.19.0.0/16 should never go out of serial 0.

We can implement this policy on Router 3 by making sure that it never learns a route to network 10.0.0.0/8 via Router 1. Since routing updates from Router 1 come in through serial interface 0, we can build a policy set of everything except networks 10.0.0.0/8 and 172.19.0.0/16 and apply it to serial interface 0. Access list 1 creates such a policy set:

access-list 1 deny 10.0.0.0
access-list 1 deny 172.19.0.0
access-list 1 permit any

However, we can shorten this particular access list since we know that only traffic to 172.18.0.0/16 should go through serial 0:

access-list 1 permit 172.18.0.0

Traffic to networks 10.0.0.0/8, 172.18.0.0/16, and 172.19.0.0/16 are acceptable through serial 1. Access list 2 defines the appropriate policy set:

access-list 2 permit 10.0.0.0
access-list 2 permit 172.18.0.0 0.1.0.0

We then apply both access lists with the following, assuming we are using routing protocol EIGRP with autonomous system 10:

router eigrp 10
distribute-list 1 in Serial 0
distribute-list 2 in Serial 1

With this configuration, traffic between networks connected to Router 3 and network 10 never travel over unencrypted paths. We achieved this by ignoring routing updates leading to the path that we did not prefer, accepting only updates for routes using the preferred path. Our usage of distribute-list statements is similar to how we implemented routing modularity earlier but differs in that we received routing updates for network 10 through serial 0. This is not incorrect; we have simply set up an arbitrary policy that prevents all traffic flowing that way.

Local and global distribute-list interactions

I have shown examples of the local distribute-list statement, one that is assigned to a specific interface, and the global distribute-list statement, one that is used for all routing updates. You may wonder how global and local distribute-list statements interact if both are defined. They are applied sequentially, with the local distribute-list applied first and the global applied after. That means that if a network is in a policy set defined by a local distribute-list statement, it also needs to be in the policy set defined by the global distribute-list before it is accepted by the routing process. As an example, consider the following configuration:

access-list 1 permit 192.168.10.0
access-list 1 permit 192.168.13.0
access-list 2 permit 192.168.10.0
router rip
distribute-list 1 in Ethernet 0
distribute-list 2 in

Routes for network 192.168.10.0/24 would be accepted in Ethernet because it is in each of the policy sets defined by access lists 1 and 2. Routes for 192.168.13.0/24 would be rejected, since although it is in the local distribute-list policy set, it is not in the global one.

Route preferences through offset-list

Often, a network administrator wants to prefer certain routes but not eliminate the possible use of the less-preferred routes. One technique for doing this uses the offset-list statement. In this section, I’ll discuss why using distribute-list statements can be problematic for implementing certain kinds route preferences, followed by sections on how you can use offset-list statements to prefer routes and how to select the metric offsets.

Limitations of using distribute-list for preferring routes

Using distribute-list to prefer routes has limitations. Figure 4.14 shows an example of this.

Figure 4-14. Preferring routes without eliminating routes

In this figure, there are two paths between network 172.20.0.0/16 and network 10.0.0.0/8. One path goes directly between the two networks over a 56 kilobits per second (Kb) link. The second path has one router hop through Router 1 but goes over two 1.544 megabits per second (Mb) links. In this network, the RIP routing protocol is used. RIP uses one metric for routing: router hops. Given this particular property of RIP, the routers calculate that the routing metric through the 56-Kb path is 1 (one router hop away) while the path through the 1.544-Mb link has a routing metric of 2 (two router hops away). The router then decides that the best path between network 172.20.0.0/16 and network 10.0.0.0/8 is the 56-Kb link, even though the other path has 30 times the bandwidth. A reasonable policy for this intranet might be the following:

Prefer the 1.544-Mb path first.

If the 1.544-Mb path is down, use the 56-Kb path as a backup link.

Let’s first try to implement this policy with distribute-list statements, as we did in the previous section. On Router 2, we define three access lists, two with only one network in it, and one that has no networks in it:

access-list 1 permit 10.0.0.0
access-list 2 permit 172.20.0.0
access-list 3 deny any

We use the policy sets defined to accept only network 10.0.0.0/8 in through serial 1 and advertise only network 172.20.0.0/16. We then refuse to advertise or accept routes out of serial interface 0, so traffic isn’t sent through that interface:

router rip
 distribute-list 1 in Serial 1
 distribute-list 2 out Serial 1
 distribute-list 3 in Serial 0
 distribute-list 3 out Serial 0

Since no routing advertisements for network 172.20.0.0/16 are sent over the 56-Kb path, no traffic from network 10.0.0.0/8 to network 172.20.0.0/16 is sent out that way. Since no route advertisements for network 10.0.0.0/8 are received over the 56-Kb path, no traffic from network 172.20.0.0/16 to network 10.0.0.0/8 is sent through that path. Routes are sent and received only through serial interface 1, so all traffic between the two networks goes only over the higher-speed path.

This implements the first part of the policy, but what happens if the 1.544-Mb path goes down? Since there are no route updates through the slow path, traffic will not go over that link if the faster path goes down. Using distribute-list for route preference only allows or disallows routes. There is no way to specify a sequence of preferences: Path A preferred first, then Path B, then Path C.

Using offset-list statements to prefer routes

In the previous section on routing theory, I showed that the way to implement routing preferences is by changing the metrics in routing updates coming in or out of the router. One way that Cisco routers can do this is through offset-list statements. These statements modify the value of routing metrics for some policy set of routes when routers send or receive route updates. Let’s see how we would use them in our example. First, let’s define a policy set with network 10.0.0.0/8 and another with network 172.20.0.0/8 in it:

access-list 1 permit 10.0.0.0
access-list 2 permit 172.20.0.0

We then use offset-list in the following way:

router rip
offset-list 1 in 3 Serial0 
offset-list 2 out 3 Serial0

The first offset-list statement says that when updates for the routes in the policy set defined by access list 1 are heard through serial interface 0, 3 will be added to the metric of those routes. When routing updates for network 10.0.0.0/8 come into Router 2 over the 56-Kb link, the route metric to network 10.0.0.0/8 over that path becomes 4. Since the route metric coming in over serial interface 1 remains 2, the “best” path for the packets becomes the 1.544-Mb path, since it has the lower routing metric. Now if the 1.544-Mb path fails for some reason, routing updates are still being received through the other path, so traffic to network 10.0.0.0/8 can go that way.

The second offset-list statement takes care of traffic in the other direction, from network 10.0.0.0/8 to network 172.20.0.0/16. Routing updates for network 172.20.0.0/16 get 3 added to them, so network 10.0.0.0/8 sees that the route metric for the path to 172.20.0.0/16 over the 56-Kb link is 4. The route metric over the 1.544-Mb path remains 2, so that path becomes preferred. If the higher bandwidth path is unavailable, traffic from 172.20.0.0/16 to 10.0.0.0/8 will go over the 56-Kb link.

offset-list statements are useful with default networks in implementing the preferred order of default paths. Figure 4.15 shows a stub network with a number of possible routes to a default network.

Figure 4-15. Stub network with multiple paths to a default network

Network 10.0.0.0/8 is a stub network that sends all of its traffic to other networks through a default network of 172.20.0.0/16. The three paths between the two networks have equal routing metric values, and the network uses the IGRP routing protocol in AS 172. Network administrators want network 10.0.0.0/8 offsite traffic to first go through Router 1, then Router 2, and then Router 3. To implement this, let’s build policy sets that contain each route:

access-list 1 permit 10.0.0.0
access-list 2 permit 172.20.0.0

On Router 1, which is the most preferred, we can define the routing as follows:

default-network 172.20.0.0
router igrp 172

The first statement defines the default network. For the IGRP process, since Router 1 is on the preferred path, we don’t have to add any bias to routing metrics.

On Router 2, we define routing with the following:

! build policy sets
access-list 1 permit 10.0.0.0
access-list 2 permit 172.20.0.0
default-network 172.20.0.0
! router definition
router igrp 172
offset-list 2 out 1000 Serial 0
offset-list 1 out 1000 Ethernet 1

The first offset-list adds a bias of 1000 to the route advertisements for network 172.20.0.0/16. The second offset-list statement adds 1000 to the route advertisements for network 10.0.0.0/8, making it less attractive then the path through 1. In this way, we make the path through Router 2 to and from network 10.0.0.0/8 less attractive then the path through Router 1. Note that with IGRP, the possible range of metric values is much larger than with RIP, so we have used the larger offset of 1000 here. I will talk more about selecting offset values later.

On Router 3, we define routing as follows:

! build policy sets 
access-list 1 permit 10.0.0.0
access-list 2 permit 172.20.0.0
default-network 172.20.0.0
! router definition
router igrp 172
offset-list 2 out 2000 Serial 0
offset-list 1 out 2000 Ethernet 1

The biases added with these offset-list statements are bigger than the biases added on Router 2. That makes the path through Router 3 less preferred than the one through Router 2, and even less preferred than the one through Router 1.

Selecting metric offsets

While extremely useful,offset-list statements need to be applied with care. It is easy to make networks unreachable if you select metric offsets that are too large. What would happen if, to be extra certain that traffic uses the faster path, we added an even bigger bias to the example in Figure 4.14, like this:

router rip
 offset-list 1 in 15 Serial 0 
 offset-list 2 out 15 Serial 0

The effect of this application of offset-list would be to make the 56-Kb path unused even if they the 1.544-Mb line went down. Why? RIP has a maximum metric size of 15. If you add 15 to the metric value, it exceeds the maximum metric limit, and any routes with a metric like this is considered unreachable. In general, you have to make sure that the bias value you select is not so large that it makes the route unreachable in parts of the network. For this example, using an offset of 8 would be okay as long as there are no more than seven router hops in network 172.20.0.0/16 and other networks using RIP. In the example we used with Figure 4.15, we cannot use a metric greater than 65536, since the maximum metric size in IGRP is 65536. Table 4.1 contains a list of some routing protocols and the maximum possible values of their routing metrics.

Table 4-1. Routing protocols and their maximum metric values

Routing protocol	Maximum metric value
RIP	15
IGRP	65535
EIGRP	4294967295

The dynamic nature of routing protocols needs to be considered when you use offset-list statements. A topology change can make the route you are trying to have preferred become unpreferred. Let’s look again at Figure 4.15. Router 1 connects to network 10.0.0.0/8 at some point in that network, but at a different point than Router 2 or Router 3. If there is a network topology change so the route within network 10.0.0.0/8 to Router 1’s connection point becomes much longer, then the path through Router 1 may no longer be the most preferred path. This kind of problem can happen when you add biases to route advertisements you send into organizations you don’t control. Some routing protocols, like IGRP and EIGRP, change routing metrics based on network delays and bandwidth utilization. Transient changes in traffic can affect routing metrics to the point where any biases you place may be overcome, so you need to make sure that any bias you use is high enough to override any increases in metrics caused by any possible change in network topology or traffic flow.

Routing policies and OSPF

You may have noticed that there are no examples of using the distribute-list, offset-list, or distance statements with the OSPF routing protocol. In general, these commands are intended for distance vector routing protocols such as RIP, IGRP, and EIGRP and not for Shortest Path First protocols such as OSPF. You can use distribute-list statements to filter routes between OSPF areas (on Area Border Routers, or ABRs), between different OSPF autonomous systems (on Autonomous System Border Routers, or ASBRs), or when redistributing routes between OSPF and other routing protocols. Using the distribute-list statement within an OSPF area will not work, and the other policy statements should not be used. Instead, use the access list alternatives described at the end of the chapter.

Route preferences through administrative distance

So far, offset-list and distribute-list statements have allowed us to implement all of the policies that we have proposed so far. Let’s see how these commands fare with the network shown in Figure 4.16.

Figure 4-16. Preferring routes from a particular router

In this network, the paths through Router A are more reliable than the routes through Router B or C. The network administrator for this network knows that this is the situation, so despite the fact that some routes from Routers B and C have better metrics, he wants the following policy on Router D:

Use routes through Router A unless Router A is down

If Router A is down, use routes through Router B

If Router A and B are down, use routes through Router C

Can we use distribute-list statements to implement this? We cannot, since there is no way to prefer route updates from a single router among many from the same interface with distribute-list. Can we use offset-list to implement this policy? Again, offset-list statements can only build policy sets of routes mentioned in routing updates. To implement this policy, we need a way to build a policy set that is not based on the network numbers in routing updates, but on some other feature of a route update, in this case the next hop or source of the routing update.

This leads us to a whole new category of policy tools that I have not yet covered: controlling routes based on characteristics of routes. All of the previous policies that we have looked at built policy sets based on the destination networks. With this set of tools, we will build policy sets based on characteristics of routes.

So how do we implement the policy preferring traffic through Router A? First, we need a way to prefer routes based on their source of routing updates. To do that, we use the concept of administrative distance. In Cisco routers, all routing updates have an additional metric assigned to them called administrative distance. Each routing source has a default administrative distance, as shown in Table 4.2.

Table 4-2. Default administrative distance for routing protocols

Routing protocol	Default distance
Connected Interface	0
Static Route	1
EIGRP Summary	5
EIGRP Internal	90
IGRP	100
OSPF	110
RIP	120
EIGRP External	170
Unknown	255

When a router gets routing information about a route from different sources, the router uses the routing information from the source with the lowest administrative distance. This means that static routes take precedence over EIGRP routes if a route has been statically routed and also learned from EIGRP. Another way to think of administrative distance is to consider it another metric assigned to route updates. This metric takes priority over any other metric that the route updates may have. Like other metrics, the lowest value is preferred. An administrative distance of 255, the maximum distance possible, means that a route is unreachable.

How do we use administrative distance to prefer routes from a particular routing source? The distance directive for routing protocols can change the administrative distance for particular routing updates. Here is how we would use distance to implement the policy defined previously:

router rip
network 192.168.14.0
distance 121 192.168.14.2 0.0.0.0
distance 122 192.168.14.3 0.0.0.0

The first number after the distance keyword is the new administrative distance for the IP address and mask that follow. The IP address and mask used in the distance statements have the same format and behavior as the IP address mask used in access lists. The first distance directive in this example sets all routing updates from 192.168.14.2 (Router B) to an administrative distance of 121. The second distance directive sets all routing updates from 192.168.14.3 (Router C) to an administrative distance of 122. Since RIP protocol updates have a default administrative distance of 120, all routes from Router A will have a lower administrative distance of 120. Thus Router D will prefer routes from Router A for any route heard from each of Routers A, B, and C. If Router A does not send out a route update for a particular network but Router B does, then Router D will use the routes from Router B unless it hears a routing update from another source with a lower administrative distance.

The distance directive allows tremendous flexibility in implementing routing preferences. Let’s implement a variation of the policy that we defined earlier:

Use routes through Router A unless Router A is down

If Router A is down, use routes through Router B or Router C

This policy differs from the former in that there is no preference between routes through B or C. We implement this policy as follows:

router rip
network 192.168.14.0
distance 121 192.168.14.2 0.0.0.1

Since route updates from Router A have the RIP default administrative distance of 120, they are preferred first. If Router A is down, both Router B and C’s updates have distance 121, so that Router D uses the route from the two routers that has the best metrics.

Let’s implement the following policy on Router D with distance:

Use routes through Router A unless Router A is down

If Router A is down, use routes through Router B

Never use routes through Router C

We can implement this with the following configuration:

router rip
network 192.168.14.0
distance 121 192.168.14.2 0.0.0.0
distance 255 192.168.14.3 0.0.0.0

As in the previous example, route updates from Router A get the default RIP distance of 120. Route updates from Router B get a distance of 121, making them less preferred than the route updates from A. Route updates from Router C receive the distance of 255. Routes with an administrative distance of 255 are considered unreachable and are thus ignored.

Here is another way to implement the policy:

router rip
network 192.168.14.0
distance 255
distance 120 192.168.14.1 0.0.0.0
distance 121 192.168.14.2 0.0.0.0

The first distance statement sets the default administrative distance for RIP to 255. That means that all routing updates from routers that do not have an explicitly set administrative distance are ignored. The next distance statement sets the administrative distance of Router A’s routes to 120 while the final distance statement sets Router B’s routes to a distance of 121. This configuration works because Router A has the lowest administrative distance, followed by Router B. All other routing updates are considered unreachable.

Using distance 255 in this manner has a number of tradeoffs that you need to consider. By ignoring all updates without explicitly set distances, the router will also ignore updates from a router that is put on the network without authorization or notification to the network administrators. This can be a good thing, since a network administrator will not have to worry about some rogue router being put on the network and suddenly accepting traffic. It can also be an annoyance, though, as the network administrator needs to explicitly define a distance for every subnet or router that sends routing updates.

So far, I’ve set all routing updates from a source to have the same administrative distance. You can also set specific routes from a source to have specific administrative distances. In Figure 4.17, network 192.168.18.0/16 contains servers dedicated to an application critical to users on networks 10.0.0.0/8 and 172.28.0.0/16.

Figure 4-17. Dedicating bandwidth to an application

The application is so critical that the path leading to network 192.168.18.0/24, from Router 1 via Router 3 to Router 4, should be dedicated to traffic to and from 192.168.18.0/24 in order to maximize the application’s performance. Transit traffic between networks 10.0.0.0/8 and 172.28.0.0/16 should not slow down the application. The only time that traffic between these networks should use the dedicated bandwidth is if another path between the networks through Router 2 is unavailable. Let’s summarize the policy that we need to implement:

The connections to Router 3 should only see traffic to and from network 192.168.18.0 unless the path through Router 2 is unavailable

We implement this policy by making the routes for 192.168.18.0/24 from Router 3 have a lower administrative distance than any other routes that it advertises. On Router 1, we use the following configuration fragment:

access-list 1 permit 192.168.18.0
access-list 2 permit any
router rip
 network 192.168.11.0
 network 192.168.12.0
 distance 119 192.168.12.1 1
 distance 121 192.168.12.1 2

Access list 1 creates a policy set with the application server’s network, 192.168.18.0/24. The first distance statement sets the routes in the policy set defined by access list 1 (the server network) that are advertised from Router 3 to an administrative distance of 119. The second distance statement sets all other routes from Router 3 to an administrative distance of 121. Route advertisements for the networks other than the application network are preferred through Router 2. Route advertisements for the application server network have a distance set lower than the default. If a route to 192.168.18.0/24 is heard from another router, the route via Router 3 is the preferred route unless the direct link to Router 3 is down.

The configuration on Router 4 is very similar:

access-list 1 permit 192.168.18.0
access-list 2 permit any
router rip
 network 192.168.13.0
 network 192.168.14.0
 distance 119 192.168.14.1 1
 distance 121 192.168.14.1 2

The IP address for the serial link to Router 3 and the connected networks are different, but the use of distance is the same.

You may have noticed that we could have implemented the routing policy by using offset-list statements instead of distance. We could have used the following on Router 3:

access-list 1 deny 192.168.18.0
access-list 1 permit any
router rip
network 192.168.12.0
network 192.168.14.0
network 192.168.18.0
offset-list 1 out Serial 0 2
offset-list 1 out Serial 1 2

This configuration works because we add a metric bias to everything but the application server network to our route advertisements, making advertisements for those routes look better through paths other than through Router 3.

Since I’ve shown two different ways to implement this policy, you may be wondering when you should use offset-list and when to use distance. To know which technique is most appropriate, you need to know about the strengths and weaknesses of each technique. I have talked about the limitations of offset-list statements already, so let’s talk about the tradeoffs of using the distance statement. As you may have already noticed, distance works only on incoming route advertisements. You cannot send another router the distance you want them to use when considering routes. If you want to influence the route preferences of routers to which you send updates, you need to use offset-list statements.

One important characteristic about administrative distance is that it overrides any other metric values that a route update may have. Let’s say that in our previous example we were using EIGRP instead of RIP. Remember that routing protocols such as EIGRP take into consideration factors like bandwidth and network loading to calculate routing metrics. If you use the offset-list approach to implement policy, a change in network traffic could change routing metrics so drastically that your policy could become undone. You could also set bias values so high that the networks you advertise are advertised as unreachable. Manipulating administrative distance, in contrast, works no matter the value of routing metrics, instead working by affecting the order in which you consider route updates for inclusion into the routing table.