implementing the established keyword in access lists. Uncommon protocols
Extended access lists can be used to control traffic for IP-encapsulated protocols other than TCP, UDP, and ICMP. Misconfigured access lists often cause problems for less common protocols. One group of uncommon protocols that is gaining popularity are Virtual Private Networking and encryption protocols, including Layer 2 Tunneling Protocol (L2TP), Generic Routing Encapsulation (GRE), Internet Key Exchange (IKE), Internet Security Association and Key Management Protocol (ISAKMP), and Encapsulating Security Payload (ESP). Because Virtual Private Networks (VPNs) may need to run through firewall routers, network engineers need to understand the specifics of the traffic flows required by the VPN. IPSec, for example, uses the ISAKMP protocol for connection setup. ISAKMP requires communications where the source and destination of a packet are both UDP port 500. The network engineer must take this and other unusual requirements of network traffic for uncommon protocols into account when configuring the firewall router access lists.
Content 6.2 Troubleshooting Transport Layer Issues on the Router 6.2.2 Gathering information on ACL operation One of the most useful commands for viewing access list operation is the log keyword on access list entries. This keyword instructs the router to place an entry in the system log whenever that entry condition is matched. The logged event includes details of the packet that matched the access list element. The log keyword can be especially useful for troubleshooting access list operation. It can also provide information on intrusion attempts being blocked by the access list. For example, if the last element in an extended ACL is configured as deny ip any any log, the details of any packet not matching a condition higher in the ACL is recorded in the system log. Because this element shows all packets not being matched by a statement earlier in the ACL, it can be useful both for troubleshooting when a certain traffic flow cannot communicate through the firewall router, as well as for showing when an intruder is attempting to access the network. This log output can either be buffered and viewed on the local system or forwarded to an external syslog server where it can become part of a larger network management system. Use the show logging command to view the locally buffered copy of the system log. The command show ip access-list [number | name] is particularly useful for troubleshooting IP access lists. This command displays the detailed elements of a specific access-list in the correct order and the number of packets that have been matched against each element. Alternatively, if no access list number is specified, details of all access lists are shown. Figure shows the typical output from the show ip access-list command. When viewing the number of access list matches, the hit counters should sometimes be reset using the clear ip access-list counter [number | name] command. This command resets access list counters to zero, making it easier to spot changes in the counters and heavily-matched access list elements. Like the show ip access-list command, this command can be used to clear the counters for only a specific access list by specifying its name or number. It will clear the counters for all IP access lists if no access list name or number is specified. An alternative command clear access-list counters [number | name] can also be used to clear IP access list statistics. Figure shows an example of using the clear command. The command show ip interface shows information about the configuration of interfaces running the IP protocol, including information on any access lists configured for inbound and outbound traffic on the interface. Figure shows an example of the output from this command.
Content 6.2 Troubleshooting Transport Layer Issues on the Router 6.2.3 Optimizing access list operation Routers handling a lot of traffic and multiple access lists can introduce significant latency into network communications. In order to minimize the impact that access lists have on network latency, network engineers should optimize existing access lists. The concept is quite simple, although the actual implementation can be a little more complex. Using the show ip access-list command, network administrators can gather information on which access list elements are being heavily used and which ones are not. Using this information, they can then re-write the access list such that the most heavily used elements are nearest the top. Figures and show this process for a simple access list. While this can be achieved fairly easily in simple access lists, using the approach on more complex access lists can be a bit more difficult. Consider an access list which must permit hosts 1-5 and 7-20 access to remote web servers, but block access to that remote service for hosts 6 and 21-31. Obviously, changing the order of the access list elements in this access list without regard to the overall reason of the order would ‘break’ the access list. In order to optimize complex access lists, the network administrator must identify groups of access list elements by purpose or intention. These groups can then be ordered such that the most heavily-used group of elements is nearest the top.
Content 6.2 Troubleshooting Transport Layer Issues on the Router 6.2.4 Common issues with IP NAT The biggest problem with all NAT technologies is interoperability with other network technologies, especially those that contain or derive information from host network addressing in the packet. Some of these technologies include: BootP and DHCP
DHCP was developed from BootP. Both protocols are used to manage the automatic assignment of IP addresses to clients. Recall that the first packet that a new client sends is a DHCP-Request broadcast IP packet. The DHCP-Request packet has a source IP address of 0.0.0.0. Because NAT requires both a valid destination and source IP address, BootP and DHCP can have difficulty operating over a router running either static or dynamic NAT. DNS and WINS
DNS and WINS are both name resolution services for networks. It is essential to the correct operation of a network that the information they contain be an accurate representation of the network. Because a router running dynamic NAT will be changing the relationship between inside and outside addresses regularly (as table entries expire and are re-created as required), a DNS or WINS server outside the NAT router does not have an accurate representation of the network inside the router. Additionally, DNS and WINS reply packets contain IP address information in the data payload of the packet. A DNS or WINS server on the network inside a NAT router resolves the hostname to a network address on the inside network. When the NAT router processes the reply packet, the NAT process translates the address in the packet header appropriately, but is not able to alter the contents of the data payload. The outside host is given the inside address of the inside host. Because the inside network is hidden by the router, the outside network cannot route packets directly to or from it. SNMP
SNMP traffic often contains the IP address of managed network equipment in the data payload of the packet. Similar to DNS packets, NAT is not able to alter the addressing information stored in the data payload of the packet. Because of this, an SNMP management station on one side of a NAT router may not be able to contact SNMP agents on the other side of the NAT router. Tunneling and Encryption Protocols
Tunneling and encryption protocols are concerned with both encrypting data to protect packet contents from being intercepted, as well as ensuring