Debugging route-filtering access lists

Like router resource access lists and extended access lists, a route-filtering access list can go wrong in two ways: the access list denies a route that should be permitted, or it permits a route that should be denied. Just as router resource access lists and extended access lists can seem to fail because of routing problems, route filtering access lists can seem to fail because of other issues, such as packet filtering extended access lists. In this section, I discuss how to find problems with router filtering access lists. I also talk extensively about how factors other than actual route-filtering access list errors can make it look like there are problems.

In this section, I focus on the more complex debugging case in which a route you want is missing in a routing table. When a route is not present, there may be either no path or the

wrong path to a given network. Let's look at the example shown in Figure 5.5. What if the routing table of Router 2 looked like the following?

C 172.20.0.0/16 is directly connected, Ethernet0

Network 10.0.0.0/8 is not in the routing table at all, so clearly something went wrong. What could have happened? Before concluding there is an access list error, you need to rule out several other possibilities. The connectivity to network 10.0.0.0/8 could be down. If the serial lines connecting to interfaces serial and serial 1 are down, no routing information can be learned through them. In this case, the show interface command would show the following for these two interfaces:

Serial0 is down, line protocol is down Hardware is HD64570

Description: To network 10 via 56Kbit path Internet address is 192.168.1.2/24

MTU 1500 bytes, BW 56 Kbit, DLY 20000 usec, rely 255/255, load 1/255 Last input 03:25:35, output 03:25:35, output hang never

Last clearing of "show interface" counters never Queueing strategy: fifo

Output queue 0/80, 0 drops; input queue 0/100, 0 drops 5 minute input rate 0 bits/sec, 0 packets/sec

5 minute output rate 0 bits/sec, 0 packets/sec

3976767 packets input, 371394120 bytes, 0 no buffer

Received 732003 broadcasts, 120 runts, 0 giants, 0 throttles

1235 input errors, 2 CRC, 680 frame, 0 overrun, 0 ignored, 0 abort 0 input packets with dribble condition detected

3586981 packets output, 1378381771 bytes, 0 underruns 2 output errors, 0 collisions, 615 interface resets 0 babbles, 0 late collision, 0 deferred

0 lost carrier, 0 no carrier

0 output buffer failures, 0 output buffers swapped out Serial1 is administratively down, line protocol is down Hardware is HD64570

Description: To network 10 via T1 path Internet address is 192.168.2.2/24

MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec, rely 255/255, load 1/255 Encapsulation HDLC, loopback not set, keepalive set (10 sec)

Last input 03:26:05, output 03:26:05, output hang never Last clearing of "show interface" counters never

Queueing strategy: fifo

Output queue 0/80, 0 drops; input queue 0/100, 0 drops 5 minute input rate 0 bits/sec, 0 packets/sec

5 minute output rate 0 bits/sec, 0 packets/sec

89764824 packets input, 4874394145 bytes, 0 no buffer

Received 752342 broadcasts, 75 runts, 0 giants, 0 throttles 52 input errors, 1 CRC, 20 frame, 0 overrun, 0 ignored, 0 abort 0 input packets with dribble condition detected

53586321 packets output, 61278388290 bytes, 0 underruns 6 output errors, 0 collisions, 2 interface resets

0 babbles, 0 late collision, 0 deferred 0 lost carrier, 0 no carrier

0 output buffer failures, 0 output buffers swapped out

The show interface command generates a lot of output, but I'll mention only key parts that are relevant to debugging route-filtering access list problems. The first line of output for each interface is usually the most important. It tells you the interface name, whether it is up or down, and whether the line connected to the interface is down. Often, if the line protocol is

down, the interface will be listed as down as well. In the previous example, both interfaces are down. Serial interface 1 is said to be administrativelydown. This means that the interface was manually shut down. The line beginning with Description: displays whatever the person who configured the router decided to mention about the interface. It is often useful for determining the function of the interface and what it connects to.

Below the description is the interface's IP address and mask. Underneath is an important line that describes key properties of the line connected to the interface. These properties, such as bandwidth (BW) and delay, are used by some routing protocols as part of metric calculations. In the example, this line shows which interface has the 56-Kb line and which has the 1.544- Mb line. Two lines below that line are times listing the last input and output. This line is useful for listing when an interface or the line connected to it goes down.

The show interface command output reveals that what at first appeared to be a routing problem was actually caused by interfaces being down. Another clue that the interfaces are down is that the directly connected networks, 192.168.1.0/24 and 192.168.2.0/24, are not listed in the route table. If the interfaces were up, then the two networks would have been listed in the routing table.

5.3.2.1 When the wrong route is present

Another possibility is that the wrong route might be present. The show ip route command yields the following:

C 172.20.0.0/16 is directly connected, Ethernet0 C 192.168.1.0/24 is directly connected, Serial0 R 10.0.0.0/8 [120/1] via 192.168.1.1, 0:29, Serial0

There is a route to 10.0.0.0/8, but it uses the backup path through serial instead of the path through serial 1. What could have happened? In this case, it is possible that the line connected to interface serial 1 is down, and show interface serial1 would show the following:

Serial1 is down, line protocol is down

Let's now say that serial interface 1 is down, so the route to network 10.0.0.0/8 uses serial interface 0. Network 192.168.2.0/24 is not in the route table. This is additional evidence of serial interface 1 being down.

What if 192.168.2.0/24 did appear in the route table yet the route was still wrong? We'd then see the following:

C 172.20.0.0/16 is directly connected, Ethernet0 C 192.168.1.0/24 is directly connected, Serial0 C 192.168.2.0/24 is directly connected, Serial1 R 10.0.0.0/8 [120/4] via 192.168.1.1, 0:29, Serial0

Here, both serial interfaces must be up, since the directly connected networks on both interfaces are listed in the route table. However, this does not necessarily mean there are problems with our access list. Notice that the metric for network 10.0.0.0/8 is 4, which is what it should be after we increase its value with the offset-list command. This implies that the routing information coming into the serial interface is being handled correctly, so it could be

ping of router 1's 192.168.2.1 interface. If ping reveals that it is down, then this problem has prevented the preferred route from entering Router 2's routing table.

If ping reveals the interface at 192.168.2.1 is up, then there are a number of possibilities why the correct route is still not there. Router 1's connectivity to network 10 might be down. Also, Router 1's administrators may have accidentally turned off sending routes to Router 2, through the passive-interface statement. Strange as it may seem, that actually does happen occasionally and can be detected using the debug command. You would notice that Router 1 seems to send no routing updates even though it is up.

5.3.2.2 Stopping routing updates with extended access lists

Make sure that you don't cause problems yourself. One way that routing updates can be ignored is with an overzealous incoming packet filter. If Router 2 makes the following attempt at anti-spoofing:

access-list 101 deny ip 172.20.0.0 0.0.255.255 any access-list 101 deny ip 192.168.2.0 0.0.0.255 any access-list 101 permit ip any any

interface serial 1 access-group 101 in

then all incoming routing updates are suppressed. At other times you might forget static routes you have set previously. If show ip route produces the following:

C 172.20.0.0/16 is directly connected, Ethernet0 C 192.168.1.0/24 is directly connected, Serial0 C 192.168.2.0/24 is directly connected, Serial1 S 10.0.0.0/8 [1/1] via 192.168.1.1, Serial0

a static route excludes any routing advertisement of network 10.0.0.0 since static routes have a higher administrative distance then any dynamic routing protocol.

If all else fails

You may encounter a situation where your access lists don't work even though there is no obvious reason. It may seem that your access lists are being totally ignored, or that your access list stops all traffic through an interface despite clearly permitting certain types of traffic. When you encounter this type of error, there may be a problem with your particular IOS. After you have exhausted all other debugging possibilities, check the Cisco web site for bugs in your IOS.There are IOS versions in which access lists do not function correctly. The Cisco Bug Navigator™ can point out the IOS versions that have problems and the ones that have fixed those problems. If you don't find your problem, open up a case with the Cisco Technical Assistance Center (TAC). They should be able to help. Note that both of these options require a support contract, which I strongly recommend if you depend on Cisco access lists for mission critical applications.

Sometimes, access lists are correct but not used correctly. If you implement the access lists like this: access-list 1 permit 10.0.0.0 access-list 2 permit 172.20.0.0 router rip network 192.168.1.0 network 192.168.2.0 offset-list 1 in 1 serial 0 offset-list 2 out 1 serial 0 show ip route reveals the following:

C 172.20.0.0/16 is directly connected, Ethernet0 C 192.168.1.0/24 is directly connected, Serial0 C 192.168.2.0/24 is directly connected, Serial1

R 192.168.3.0/24 [120/1] via 192.168.2.1, 00:23, Serial1 R 10.0.0.0/8 [120/2] via 192.168.1.1, 00:23, Serial0 10.0.0.0/8 [120/2] via 192.168.2.1, 00:23, Serial1

Notice that there are two routes associated with network 10.0.0.0/8, one for each of two possible paths, and they both have the same route metric. This is an indication that the offset used in the offset-list line is not high enough. Since the metrics to both paths are the same, the router installs both routes.

5.3.2.4 When route-filtering access lists are wrong

I have shown how different problems can make you think there are access lists problems when there are not. Let's look at a situation where there actually are problems with the access lists themselves. If we implement our policy in the following way:

access-list 1 permit 19.0.0.0 access-list 2 permit 172.20.0.0 router rip network 192.168.1.0 network 192.168.2.0 offset-list 1 in 3 serial 0 offset-list 2 out 3 serial 0 show ip route reveals the following:

C 172.20.0.0/16 is directly connected, Ethernet0 C 192.168.1.0/24 is directly connected, Serial0 C 192.168.2.0/24 is directly connected, Serial1

R 192.168.3.0/24 [120/1] via 192.168.2.1, 00:23, Serial1 R 10.0.0.0/8 [120/1] via 192.168.1.1, 00:23, Serial0

The path to network 10.0.0.0/8 goes through serial 0, yet its metric is only 1. It looks like access list 1 has not put network 10.0.0.0 into its policy set of routes that will have its route metrics increased. A look at access list 1 reveals that network 19.0.0.0/8 is in the only entry instead of network 10.0.0.0/8. Once corrected, the proper route should be installed in the routing table.