Cisco IOS Access Lists | O'Reilly Media

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

In the best of all possible worlds, network administrators would never need network policies. Crackers would never break into a router to invade a network, routers would never pass bad routing information, and packets would never take network paths that network administrators did not intend. Sadly, we live in a hostile, imperfect world. Consider the following scenarios:

Crackers penetrate Company A's public web site. The intruders replace the company's web content with pornography. Company A's management and public relations are consumed with dealing with the resulting negative publicity, much to the detriment of the company's core business.
A network administrator works at Site O, one of many sites within a large, geographically dispersed intranet. Instead of typing "19", he types "10" ("9" and "0" are next to each other on the keyboard) when configuring a local router. As a result, Site O begins to advertise a route to network 10.0.0.0/8 instead of network 19.0.0.0/8. Since network 10.0.0.0/8 belongs to Site P, users on network 10 are unable to access the rest of the intranet. Network 19.0.0.0/8 users are also isolated because their route in Site P is also not getting advertised. Users at Sites O and P can't do any work requiring access to network resources outside their respective sites.
A company has two connections to the Internet through different Internet service providers (ISPs), both at the same bandwidth. This has been implemented to provide backup routing in case one connection goes down. One of the ISPs has traffic-based prices while the other has a fixed price. To reduce costs, the company wants to use the fixed-price ISP unless the line to it goes down, in which case it will use the traffic-based Internet connection. Because a routing policy has not been implemented to enforce this preference, all Internet IP traffic passes through the usage-based connection, forcing the company to incur higher than necessary costs.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Now that you know why you should have policies, how do you implement them in Cisco router networks? How are Cisco access lists involved with policy at all? In this section, I describe a conceptual framework that can help with the design and implementation of policies. The key concept in this framework is the policy set.

If you think about policies in general (not just network access policy), every policy has two parts, what and how. "What" designates the objects included in a policy. "How" describes how those objects are affected by the policy. When a policy is enforced, some set of objects or is evaluated against whether it is affected by that policy. Let's look at policies in a department store. The store has a policy on business hours. Employees may come in during a specific range of hours, and customers are allowed in during another range. How is this policy divided into the two parts? The affected objects (the "what") are the store's employees and customers. The "how" is that employees are allowed in during certain hours, and customers are permitted to shop during certain hours. Of course, people other than employees, such as delivery workers, also go into stores. As each person goes in, the policy is enforced, and we check to see whether they are employees, deliverers, or customers. If they are customers, they may enter only during certain hours.

Let's look at other policies a store might have. Many stores do not permit customers to bring in knapsacks or large bags. The "what" in the policy are the knapsacks and large bags brought by people coming to a store. The "how" is a rule forbidding customers from bringing them into the store and forcing them to check those items into lockers or drop them off in some area. Also, stores typically have a policy that only employees may enter certain areas. The "what" in this policy is employees. The "how" is that only employees are permitted in some area.

When implementing traffic policies in Cisco router networks, we have to partition them in a similar way. The "what" of a policy, the set of objects affected, is what I will call the

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

What do we do with our policy sets once we define them? How can we use those policy sets to prevent the described scenarios from happening? This section talks about the "policy toolkit," a set of four "tools" that are general techniques for manipulating policy sets.

As we know, policy sets can be described as the "what" of a policy. The policy tools fit into our conceptual framework as the "how." Once we define a policy set, we must do something with it to implement a policy. There are four kinds of tools we can use with policy sets to implement network policy. These tools control the following:

Router resources
Packets passing through the router
Routes accepted and distributed
Routes based on characteristics of those routes

It may not be obvious why a network administrator would use these tools. To understand this, think about the functions that a router performs in a network. First, in many ways, a router functions like a host in that there are certain services it provides—logins, network time, SNMP MIB data. These are router resources that a network administrator can control. Secondly, a router's key function is to forward packets from one network interface to another. Hence the network administrator can do packet filtering, i.e., can control the packets passing through the router. The last key function of a router is to accept and distribute routing information. Thus, there must be a way to control routes that are accepted and distributed. The most common way to do this is with the routes themselves: by filtering routes based on their network numbers. A second, more complex way to filter routes is to use another characteristic of the routes, like last hop or some other arbitrary route attribute. It can be argued that all route filtering is done based on some route characteristic, be it the network number or some other attribute, but we keep them in separate categories because route filtering based on route characteristics tends to be much more complex than filtering using network numbers. Controlling routes based on route properties also tends to use radically different access list constructs.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

In Chapter 1, I talked about the need for network policies. I also described how to build policy sets, how policy sets map to access lists, and how to manipulate policy sets. However, before actually implementing any policies, we must first understand how to create and manipulate access lists. This chapter covers the two basic access list types and how to build and maintain them. The first kind of access list is the standard access list, used to build policy sets of IP addresses or IP networks. In describing the standard access list, we will examine the basic syntax used in all Cisco access lists, including the basic permit/deny operation for including or excluding network objects from a policy set, address specification and masking, and the sequence used in processing access lists. The standard access list cannot cover all the policies we may wish to specify, particularly when we want to do packet filtering, which leads us to the second type of access list: the extended access list. This kind of list extends the format of the standard access list to specify packet filtering policies. Once we have learned to build the basic access list types, the chapter covers how to optimize, build, and maintain access lists.

Also in Chapter 1, we discussed the motivations for implementing access policies. All three motivations—security, robustness, and business drivers—are reasons to use the standard access list. With these reasons in mind, a network administrator typically uses standard access lists to implement three types of policy controls:

Access to router resources
Route distribution
Packets passing through a router

These policy controls require policy sets of IP addresses or network numbers, so the standard access list is used to build policy sets of either IP addresses or network numbers. Once policy sets are defined with standard access lists, the access list can restrict access to network resources, determine which routes are accepted and distributed, and change routing metrics to influence traffic behavior. To illustrate how the standard access list is used, let's look again at the first example from Chapter 1, which deals with controlling router resources. Recall that Figure 1.1 showed a router that we control and the hosts that are allowed to access its resources. We defined Policy Set #1, consisting of the hosts allowed to log into the router, as follows:

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Also in Chapter 1, we discussed the motivations for implementing access policies. All three motivations—security, robustness, and business drivers—are reasons to use the standard access list. With these reasons in mind, a network administrator typically uses standard access lists to implement three types of policy controls:

Access to router resources
Route distribution
Packets passing through a router

These policy controls require policy sets of IP addresses or network numbers, so the standard access list is used to build policy sets of either IP addresses or network numbers. Once policy sets are defined with standard access lists, the access list can restrict access to network resources, determine which routes are accepted and distributed, and change routing metrics to influence traffic behavior. To illustrate how the standard access list is used, let's look again at the first example from Chapter 1, which deals with controlling router resources. Recall that Figure 1.1 showed a router that we control and the hosts that are allowed to access its resources. We defined Policy Set #1, consisting of the hosts allowed to log into the router, as follows:

Policy Set #1: IP address 192.168.30.1

Policy Set #1: IP address 192.168.33.5

Policy Set #1: No other IP addresses

How does this policy set map to actual access lists? Here is the mapping:

access-list 1 permit 192.168.30.1
access-list 1 permit 192.168.33.5
access-list 1 deny 0.0.0.0 255.255.255.255

The number after the access-list keyword is the access list number, so in this example, we define access list 1. The number also specifies what kind of access list it is. Different types of access lists for different network protocols use different ranges of access list numbers (e.g., IP uses 1-99 for standard access lists and 100-199 for extended access lists; IPX uses 800-899 for its standard access lists, while DECnet uses 300-399). The first two entries use the keyword

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

I mentioned in Chapter 1 that one policy tool network administrators have at their disposal is control over the type of packets that flow through a router. We looked at examples where it was necessary to restrict the kinds of packets passing through a router to specific protocols such as HTTP (web) or SSL packets. To implement this, we need to build a policy set that includes a variety of different kinds of IP packets. We can't do this with standard access lists because they deal with only IP addresses, sets of IP addresses, or network numbers, and not with the nature of the packets themselves. Although we saw how to use standard access lists to do packet filtering in the last example, there too we could only specify the hosts that are allowed to send IP traffic through a specific interface. There was no way to narrow down the kind of packets in a policy set to specific protocols such as TCP or UDP, specific protocol port numbers, or specific relationships between sets of IP addresses. Standard access lists allow all or nothing. To do packet filtering at a finer level of granularity, we need a way to extend the standard access list to include things like protocol, port number, and destination IP addresses .

Understanding TCP and UDP port numbers is fundamental to using extended access lists. To understand port number usage, you have to look at how hosts function together in networks. In a network environment, client processes on client hosts make requests to server processes on server hosts, which service the request and send back a response to the client process. With TCP, a connection is set up with the request, while with UDP, there is no connection setup. Many different services, such as Telnet or the Domain Name System (DNS), may reside on the server host. In order for a client to specify the service it wants to use, it addresses its request to a previously defined destination port number associated with the desired service. Ports are specified as 16-bit numbers. For example, the standard port for Telnet service is 23, the port usually used by HTTP (the World Wide Web protocol) is 80, and the standard port number for DNS service is 53. While there are standard port numbers, it is important to note that these services can use nonstandard ports. A client processes can use any of these services on other ports as long as it knows which port to use.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Proper use of matching and masks can reduce the number of access list entries that a network administrator must write. As we discussed before, matching sets of IP addresses, whether for networks or hosts in standard access lists or for the source and destination definitions for an extended access list, always involves defining an IP address and a mask. Masks are bit masks that apply to the corresponding bit of the IP address. Remember that a 1 in a access list wildcard mask is a wildcard, meaning that the corresponding bit in the IP address is a match no matter what the value is in the IP address being compared. A 0 indicates that the corresponding bit must match the IP address exactly.

So far we have used only 1's in the last portion of a mask to match all the hosts in that network, like this:

192.168.30.0 0.0.0.255

In this and all previous examples, the 1's in a mask were on the right while the 0's were on the left, but we can mask on other portions of an IP address to consolidate access list entries, as we'll see here. Let's include four networks in a policy set: 192.168.32.0/24, 192.168.33.0/24, 192.168.34.0/24, and 192.168.35.0/24. The following access list entries accomplish this:

access-list 1 permit 192.168.32.0
access-list 1 permit 192.168.33.0 
access-list 1 permit 192.168.34.0 
access-list 1 permit 192.168.35.0

We can reduce the number of entries by looking at the network numbers and asking what these networks have in common. Clearly, the first two octets are the same: 192.168. Let's look at bit patterns for the third octet of the address in Table 2.1.

Table 2.1: Bit patterns for 32 through 35
Third octet decimal value	Binary equivalent
32

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

So far, we have seen many examples of access lists, but I have not shown how standard and extended access lists are entered into the router and maintained.

Access lists are part of the router's configuration; they are not some register values that we can set from the router's command line. That being the case, we enter access lists in the top level of configuration mode, and must have fully enabled access in order to do so. Access list entries are appended to the existing list in the order in which they are entered. For example, here is how to enter the access lists implementing the first example in Chapter 1 on a router called RouterA:

RouterA# conf term
RouterA(config)# access-list 1 permit 192.168.30.1
RouterA(config)# access-list 1 permit 192.168.33.5

This creates the following access list with two entries:

access-list 1 permit 192.168.30.1
access-list 1 permit 192.168.33.5

If we exit the router's configuration mode and then reenter and type the following access list entries:

RouterA# conf term
RouterA(config)# access-list 1 permit 192.168.30.2
RouterA(config)# access-list 1 deny 192.168.30.1

we end up with the following access list:

access-list 1 permit 192.168.30.1
access-list 1 permit 192.168.33.5
access-list 1 permit 192.168.30.2
access-list 1 deny 192.168.30.1

It is critical to understand how new access list entries affect an access list. If you want to delete or change an individual access list entry, you have to delete the entire access list and reenter it with the changed or deleted access list entry. Again, this is because any new access list entries are appended to the list. In our example, we entered deny 192.168.30.1 after permit 192.168.30.1. The deny entry does not "cancel" the permit entry; it only makes the access list bigger. Moreover, it is never even evaluated. As I mentioned earlier in the chapter, access lists are evaluated sequentially. The permit entry for host 192.168.30.1 is always evaluated before the

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

In the examples so far, access lists are identified and classified by numbers. I mentioned that there are limits on the number of standard and extended access lists available for use in a router configuration. In addition, a number is not a very descriptive way to illustrate an access list's function, as compared to a generic string like "network-management-hosts" or "valid-company-routes." To increase the number of access lists available and to provide better, more descriptive names, more recent versions of the Cisco IOS provide a facility called named access lists. Named access lists use character strings instead of numbers as identifiers.

Named access lists are usable only under more recent versions of IOS (11.2 and later), and not under all possible applications of access lists. Under some versions, using a named ACL will stop forwarding on an interface. Test your use of named access lists before using them in any kind of production environment.

They are used exactly the same way as numbered, standard, and extended access lists. For example, here is a named access list called network-admin-hosts used to restrict router logins:

line vty 0 4
 access-class network-admin-hosts in

Here's a named access list called incoming-web-traffic used for packet filtering:

interface Ethernet0
 Ip access-group incoming-web-traffic in

Named access lists differ from numbered access lists in how they are created. When creating a named access list, you first need to declare the name and type. After that, individual entries are put in. Unlike numbered access lists, you don't need the access list name with every entry. Here is an example of a standard access list being configured:

RouterA# conf terminal
RouterA(config)#  ip access-list standard network-admin-hosts 
RouterA(config-std-nacl)#  permit 192.168.30.1
RouterA(config-std-nacl)#  permit 192.168.33.5

There are a few key features of named access lists to note here. First, the keyword

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

In Chapter 1, you learned that security, robustness, and business drivers are the primary motivations for implementing network traffic policies, and in Chapter 2 you learned how to format, build, and maintain standard and extended access lists. With this background, you are now ready to implement policies for the first key motivation: security. There are three sections in this chapter. Since security policies most often use two different tools in the network administrator's policy tool kit—router resource control and packet filtering—there is a section on each. These router resources include services on the router, such as Telnet or SNMP access that should be closely managed by any network administrator. Packet filtering, or regulating what kind of packets can flow through the router, is commonly used in firewall applications. Since access lists consume resources on the router, I have included Section 3.3 in this chapter, which describes some alternatives to access lists you might want to consider when implementing security policies.

As I have said, creating router resource policies requires building policy sets of host IP addresses and giving those policy sets permission to use a router resource. The most common examples, discussed later in this chapter, are policy sets of hosts allowed to log into a router, but other examples might include controlling SNMP access to router information or permission to use the router as a network time server. To implement router resources, we will create sets of IP addresses using the standard access list described in Chapter 2.

As you may know, Cisco routers can have different levels of login access, each with different security privileges. You can configure the router to have user accounts with different levels of privilege. The default configuration provides a general restricted login, known as

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

As I have said, creating router resource policies requires building policy sets of host IP addresses and giving those policy sets permission to use a router resource. The most common examples, discussed later in this chapter, are policy sets of hosts allowed to log into a router, but other examples might include controlling SNMP access to router information or permission to use the router as a network time server. To implement router resources, we will create sets of IP addresses using the standard access list described in Chapter 2.

As you may know, Cisco routers can have different levels of login access, each with different security privileges. You can configure the router to have user accounts with different levels of privilege. The default configuration provides a general restricted login, known as user EXEC level access, with a specific login password used for initial entry. Once logged in, a user can look at router statistics, such as routing tables and interface traffic counts, and telnet to other hosts (if permitted; we'll talk about how to control this later), but he or she can't configure the router or examine its configuration. Router configuration commands do not exist at that initial login level of privilege. If someone who has gained login access to the router wants to configure the router, he must reques t to do so. At that point, another password is required to gain the necessary privilege level, known as privileged EXEC.

While it may seem that the initial login mode is not particularly useful, this is not true. Having multiple levels of privilege can be very useful. From basic login access, a network technician or administrator can still debug problems and monitor key router information, such as interface statistics, without risking critical services or the security of the router and the organization and business needs it serves. Particularly in large organizations, this separation of function and responsibility can be a key component of a smoothly operating network infrastructure, all the more so when different groups manage different parts of it. This is shown in Figure 3.1.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Firewalls are systems that regulate and monitor services passing between two networks, usually one that is trusted and the other untrusted. Extended access lists are the typical method of implementing firewalls with Cisco routers, since they are the preferred mechanism for filtering packets through the interfaces of two networks. In this section, we start with our simple example that controls access to a web server by packet filtering with an extended access list. We then continually expand the example, gradually including functionality and features to our small firewall to demonstrate how to build robust security policies.

The first example of packet filtering demonstrates how to limit access to a web server to prevent the kinds of attacks described in Chapter 1. Before deciding what access lists are needed, it is often helpful to draw a diagram of network connectivity. Figure 3.4 shows the layout of the web server's connectivity.

Figure 3.4: Restricting packets to a web server

We have a serial line to the Internet on the router interface serial 0. The web server lives on segment 192.168.35.0/24, with IP address 192.168.35.1 and uses the well-known web port, 80, and the well-known SSL port, 443, for delivering web services. Other hosts within the organization are connected to the router through interface Ethernet 1.

The policy set we need here, as with all extended access lists, contains the type of packets that can pass through the interface of a router. The policy that needs to be applied in this case limits access to the web server to just web protocols:

access-list 101 permit tcp any host 192.168.35.1 eq www
access-list 101 permit tcp any host 192.168.35.1 eq 443

The policy set specified by access list 101 is then applied to the interface Ethernet 2, the interface used to connect the web server to the router:

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The CPU costs incurred by access lists can be quite high. For this reason, Cisco routers offer a number of alternatives to using access lists for security. I'll discuss them here.

Occasionally, you may encounter a network or a single host that you absolutely do not trust. In a company, this could be a segment where known outsiders and potentially hostile people are working, or perhaps a lab network that has different Internet access. It could also be a DMZ or a system on the DMZ such as a dial-in terminal server, where you may have some doubts about the security on that network or who is on that system. In any case, the systems and data that you want to protect may be so sensitive that you don't want to take any chances with traffic or data flowing to the untrustworthy network or host. One tactic you can use for absolute certainty is to route all traffic to a null device with a static route. Here, I use a static route to drop all traffic going to network 192.168.29.0/24:

ip route 192.168.29.0 255.255.255.0 null0

This static route configuration command sends all traffic to network 192.168.29.0 on to a null device, effectively throwing away all packets going to that network. This is a succinct way to completely eliminate traffic going to a given network. Dropping all traffic to a host is much more common. If we were to drop all traffic going to host 192.168.29.1, we would use the route command:

ip route 192.168.29.1 255.255.255.255 null0

You need to be careful of a number of things when using the null route as an access list replacement. All of the router is affected by such a command, not just particular interfaces. With this technique, you can't drop traffic from some hosts or network to the hosts while permitting others; all traffic going out of the router to this host is dropped. Also, just because you can't send traffic to a network or a host doesn't mean they can't send traffic to you.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

A key policy decision that network administrators need to make is how to route packets. Application performance, security, and cost can all be affected by these decisions. Routers, in addition to forwarding and receiving data packets, send routing messages that describe where to send those packets. Network administrators use two policy tools to manipulate these routing messages: route filtering and filtering based on characteristics of routes. The first section of this chapter talks about the general issues of implementing routing policies—how filtering the routes distributed by routing protocols can affect network stability and business goals, and the following section goes into the details of making networks robust. After that, we discuss how to implement traffic preferences according to specific objectives and look at the costs incurred when implementing routing policies. Finally, we briefly examine some alternatives to using access lists. This chapter focuses mainly on routing within smaller networks and intranets, but the concepts discussed here are applicable to routing in the Internet and in very large networks, which we'll talk about in Chapter 6.

In Chapter 3, we saw how access lists can be used to filter packets moving through a router. Packets are not the only types of information that can be monitored by access lists. Routing information, which instructs routers how to forward data packets to their proper destination, are often critical to control. Let's talk a little about routing basics and the reasons for building router filtering policies for our networks and organizations, which will prepare us for implementing access lists to control the flow of routing information later in the chapter.

When networks grow past a certain size, there is no way that administrators can manually update every router with information about the best way to route packets. Network links change capacity, routers go up and down, and traffic conditions vary. To ensure that all of the routers in a network know about changing network conditions, routers pass routing information between each other in a series of packets called routing updates or route advertisements.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

In Chapter 3, we saw how access lists can be used to filter packets moving through a router. Packets are not the only types of information that can be monitored by access lists. Routing information, which instructs routers how to forward data packets to their proper destination, are often critical to control. Let's talk a little about routing basics and the reasons for building router filtering policies for our networks and organizations, which will prepare us for implementing access lists to control the flow of routing information later in the chapter.

When networks grow past a certain size, there is no way that administrators can manually update every router with information about the best way to route packets. Network links change capacity, routers go up and down, and traffic conditions vary. To ensure that all of the routers in a network know about changing network conditions, routers pass routing information between each other in a series of packets called routing updates or route advertisements. Routing updates provide information about the paths going to individual networks so that routers can decide how to forward packets to those networks. Routing information can include the number of router hops to a network, path delay, network congestion, or other information such as flags that routers attached to the routing information. With this information, routers make decisions about the best path to a given network.

In a similar manner to the control of packets we examined in Chapter 3, a router can forward and filter routing information, as shown in Figure 4.1.

Figure 4.1: Routing information is forwarded and filtered through a router

Routing information comes into the router from several different interfaces, using a routing protocol with a single metric whose values are shown. Routing updates about Networks 1 and 2 come into Interfaces 1 and 2. The updates from Interface 1 have

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

So far, we have been looking at the concepts of implementing routing policies. In this section, we'll start implementing real routing policies using access lists, focusing on routing policies that implement routing modularity.

Let's revisit the scenario we saw in the first chapter, where a typographical error caused a route to be incorrectly advertised, making two sites unreachable on an organization's intranet. Figure 4.9 shows a network topology for that scenario.

Figure 4.9: Routing modularity in a large intranet

In Figure 4.9, we see a network where four sites, L, N, O, and P, connect to each other through a central hub Site M. Network 19.0.0.0/8 belongs to Site O, and network site 10.0.0.0/8 belongs to Site P. Network 172.28.0.0/16 belongs to Site M. In our failure scenario, a typographical error causes Site O to advertise a route to network 10.0.0.0/8 from Router 1 instead of network 19.0.0.0/8. (This is an easy typo to make since the number 9 is close to the number on the computer keyboard.) The typo causes Sites L, M, and N to see two routes to network 10.0.0.0/8 and no routes to network 19.0.0.0/8. Just to make things interesting, let's also say that the serial link between Routers 1 and 3 has much greater bandwidth than the serial link between Routers 4 and 6. That makes the route from Router 3 to Site O the preferred route to network 10.0.0.0/8 for Sites L, M, and O because of the more favorable network.

This scenario is a problem because network 19.0.0.0/8 is no longer advertised in the intranet, and no one in Sites L, M, N, or P can reach Site O. Conversely, no one in Site O can use the services of any other network since the return packets for a connection (or for server responses) have no route back to Site O. In addition, since the preferred route to Site P's network 10.0.0.0/8 goes to Site O, no packets ever reach Site P either.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

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.

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.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

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.

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:

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Once you've formatted access lists and used them to implement policies, how do you know if your access lists are correct? How can you find problems with them? We'll look at these questions in this chapter, first verifying that your access lists are working correctly in the areas of router resource control, packet filtering, and route filtering. More generally, I will talk about how access lists can go wrong and what are the typical failure modes of access lists. Finally, we'll look at some tips and tricks for debugging access lists in detail.

In this section, I discuss how to debug router resource access lists. The first part describes how to check them for correctness since it doesn't make sense to debug a list that is configured properly. The second part discusses what generally happens when access lists go wrong, and the last part goes over specifically how to debug router resource access lists.

In Chapter 3 we configured the router to control resources such as Telnet and time services. The approach to verifying if these access lists function correctly is very basic: test if access works correctly for those who are permitted, and test if access does not work for those who are not permitted. Let's look at one of our early examples of router resource policies and look at how we can test it. In the first example in Chapter 2, we had a policy like the following:

Only the hosts at IP addresses 192.168.30.1 and 192.168.33.5 may telnet into the router

The access list that defines the policy set for this policy is:

access-list 1 permit 192.168.30.1
access-list 1 permit 192.168.33.5

We use the policy set as follows:

line vty 0 4
 access-class 1 in

In order to verify that the access list actually implements the policy, we need to check that what we defined in the policy set matches what is in the policy definition. There are two ways to do this. The first is by inspection: we manually check whether the access list matches our policy. While this method can work for small access lists, it becomes much more difficult as access lists grow in size and really isn't a particularly reliable way to verify that an access list is correct. The second way is to test whether access lists actually function as desired. In this instance, we would attempt to telnet to the router from the hosts at 192.168.30.1 and 192.168.33.5. If we succeed in getting a prompt from the router, we know that the access list is allowing the correct host to connect to the router.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

In this section, I discuss how to debug router resource access lists. The first part describes how to check them for correctness since it doesn't make sense to debug a list that is configured properly. The second part discusses what generally happens when access lists go wrong, and the last part goes over specifically how to debug router resource access lists.

In Chapter 3 we configured the router to control resources such as Telnet and time services. The approach to verifying if these access lists function correctly is very basic: test if access works correctly for those who are permitted, and test if access does not work for those who are not permitted. Let's look at one of our early examples of router resource policies and look at how we can test it. In the first example in Chapter 2, we had a policy like the following:

Only the hosts at IP addresses 192.168.30.1 and 192.168.33.5 may telnet into the router

The access list that defines the policy set for this policy is:

access-list 1 permit 192.168.30.1
access-list 1 permit 192.168.33.5

We use the policy set as follows:

line vty 0 4
 access-class 1 in

In order to verify that the access list actually implements the policy, we need to check that what we defined in the policy set matches what is in the policy definition. There are two ways to do this. The first is by inspection: we manually check whether the access list matches our policy. While this method can work for small access lists, it becomes much more difficult as access lists grow in size and really isn't a particularly reliable way to verify that an access list is correct. The second way is to test whether access lists actually function as desired. In this instance, we would attempt to telnet to the router from the hosts at 192.168.30.1 and 192.168.33.5. If we succeed in getting a prompt from the router, we know that the access list is allowing the correct host to connect to the router.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Here I talk about debugging the packet filters that you implement with access control lists. Like the previous section, I first talk about how to verify that your access lists are correct, followed by a section about how to find the problems in the access lists that you find to be wrong.

One of the first things you want to do is make sure that your access lists are applied to the interfaces you intended. You or another network administrator may have removed access lists or applied other access lists in order to debug problems or temporarily enable certain functionality for a variety of reasons, such as host installations or debugging. One way to do that is to show the running configuration with the show running-confg command. If you have a large configuration, this command may take a while, and it is easy to miss the interface you want to look at when many of them are scrolling by.

Section 5.2.1.1: Using show ip interface to display applied access lists

A better way is to use the show ip interface command. This command yields output that looks like the following:

Serial 0 is up, line protocol is up 
 Internet address is 192.168.1.2/24 
 Broadcast address is 192.168.1.255 
 Address determined by non-volatile memory 
 MTU is 1500 bytes 
 Helper address is not set 
 Directed broadcast forwarding is enabled
 Outbound access list is 102 
 Inbound access list is 101 
 Proxy ARP is enabled 
 Security level is default 
 Split horizon is enabled 
 ICMP redirects are always sent 
 ICMP unreachables are always sent 
 ICMP mask replies are never sent 
 IP fast switching is enabled 
 IP fast switching on the same interface is enabled 
 IP Optimum switching is disabled IP 
 Flow switching is enabled IP 
 CEF switching is enabled IP 
 Distributed switching is enabled 
 IP LES Flow switching turbo vector IP 
 Flow CEF switching turbo vector 
 IP multicast fast switching is disabled 
 IP multicast distributed fast switching is disabled 
 Router Discovery is disabled 
 IP output packet accounting is enabled 
 IP access violation accounting is disabled 
 TCP/IP header compression is disabled 
 Probe proxy name replies are disabled 
 Gateway Discovery is disabled 
 Policy routing is disabled 
 Web Cache Redirect is disabled 
 BGP Policy Mapping is enabled (source ip-prec-map)

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

As in previous sections, I start with a discussion of verifying route-filtering access control lists for correctness and then talk about debugging.

When checking the correctness of route filtering access control lists, you cannot rely on the technique we used previously (making sure that applications run correctly). Applications can run correctly even when taking a route that does not match the policy you are trying to implement. To make sure that route filtering access lists are correct, you need to use various diagnostic tools implemented in routers and hosts. The first tool is an examination of the routing table. The command show ip route displays a Cisco router's routing table. For routing policies that affect incoming routing updates, the show ip route command can verify that your routing policy implementation is correct.

Let's look at one of our previous routing policy implementations to see how we can use show ip route to verify an implementation's correctness. The first example in Chapter 4 deals with the network shown in Figure 5.3.

Figure 5.3: Restricting routes sent and received

Router 3, located in Site B, seeks to restrict the routes it receives from Site D. Since Site D uses only network 19.0.0.0/8 and does not transit any traffic from any other sites, Site B should hear about network 19.0.0.0/8 only in the routing updates it gets from Router 1. We implement the policy with the following:

access-list 1 permit 19.0.0.0
router eigrp 1000
network 192.168.3.0
distribute-list 1 in serial 1

How can we use show ip route to verify that this is correct? We have to make sure that network 19.0.0.0/8 is the only network learned from Router 1. Here is the relevant output from executing show ip route on Router 3:

Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
       i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default
       U - per-user static route, o - ODR

Gateway of last resort is 172.28.1.5 to network 172.28.0.0
D EX 19.0.0.0/8 [170/2202624] via 192.168.3.2, 3w5d, Serial1
D EX 10.0.0.0/8 [170/2239232] via 172.28.1.5, 3w5d, FastEthernet0/0
D EX 192.168.4.0/24 [100/2174464] via 172.28.1.5, 3w5d, FastEthernet0/0
D EX 198.175.107.0/24 [100/2239232] via 143.183.152.251, 3w5d, FastEthernet1/0
C    192.168.1.0/24 is directly connected, Serial1
172.28.0.0/16 is variably subnetted, 226 subnets, 4 masks
C       172.28.1.0/26 is directly connected, FastEthernet1/0

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

For more advanced network policies, Cisco routers have a policy structure called route maps. Route maps combine policy set definition with policy application, using the access list formats discussed in previous chapters. In this chapter I talk about using route maps for intranet routing policies and for routing policies in the Internet. Along the way, I cover some new access list types, key BGP (Border Gateway Protocol, the routing protocol used on the Internet) concepts, and how to implement commonly used Internet routing policies, focusing on the needs of multihomed organizations, not ISPs.

For most configurations, standard and extended access lists are enough to specify which sets of IP addresses or networks you want to influence with a policy. When you want to set policies with BGP or manipulate sets of networks based on their prefix length (the number of bits in the network mask), these types of access lists fall short. BGP is an Exterior Gateway Protocol (EGP) routing protocol. EGPs are designed for sending routing updates between large administrative domains. As a result, BGP routes carry a lot of information. Unlike Interior Gateway Protocols (IGP) such as OSPF or EIGRP, BGP routing updates carry complete path information. The routing updates can also carry flags added by network administrators called community attributes. Both paths and communities are often the basis of Internet routing policies. In this section, I talk about three new types of access lists: the prefix lists, the AS-path list, and the community list. Understanding these types of access lists is a prerequisite to using route maps, particularly with BGP.

When working with networks of different prefix lengths, there are a number of situations where using standard access lists don't work. Let's say that you wanted to set up an access list that includes network 172.28.0.0/16 but doesn't include 172.28.0.0/24. Although you might try the following access list:

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

For most configurations, standard and extended access lists are enough to specify which sets of IP addresses or networks you want to influence with a policy. When you want to set policies with BGP or manipulate sets of networks based on their prefix length (the number of bits in the network mask), these types of access lists fall short. BGP is an Exterior Gateway Protocol (EGP) routing protocol. EGPs are designed for sending routing updates between large administrative domains. As a result, BGP routes carry a lot of information. Unlike Interior Gateway Protocols (IGP) such as OSPF or EIGRP, BGP routing updates carry complete path information. The routing updates can also carry flags added by network administrators called community attributes. Both paths and communities are often the basis of Internet routing policies. In this section, I talk about three new types of access lists: the prefix lists, the AS-path list, and the community list. Understanding these types of access lists is a prerequisite to using route maps, particularly with BGP.

When working with networks of different prefix lengths, there are a number of situations where using standard access lists don't work. Let's say that you wanted to set up an access list that includes network 172.28.0.0/16 but doesn't include 172.28.0.0/24. Although you might try the following access list:

access-list 1 permit 172.28.0.0 0.0.0.0.0
access-list 1 deny 172.28.0.0 0.0.0.0.255

172.28.0.0/24 will still be included in the policy set in the first entry.

In general, standard access lists are unwieldy (if at all workable) when you want to include and exclude networks based on prefix length into a policy set. Let's say you want to include network 192.168.32.0/19 and all possible prefixes that are a part of it, i.e., all prefix lengths of network 192.168.32.0/19 equal to or greater than 19. We would have to implement this by denying shorter length prefixes and including everything else:

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

To create generic policies for routing, we need two things: a way to identify routes to be affected by a policy and a way to set policies once those routes have been identified. Route maps are a series of entries that have exactly those two sets of elements. The name "route map" is entirely appropriate: routes are identified and mapped to a policy setting.

Each route map entry has the following format:

route-map route-map-name {permit|deny} {sequence number}
match clauses 
policy settings

The

Table of Contents

Section 5.2.1.1: Using show ip interface to display applied access lists