|
|
This chapter describes IP protocols and suggests ways to handle problems associated with IP. This chapter contains the following sections:
There are two main types of Internet protocols:
The transport layer is implemented by the following two protocols:
TCP moves data in a continuous, unstructured byte stream where bytes are identified by sequence numbers. By using sequence numbers and acknowledgment messages, TCP can provide a sending node with delivery information about packets transmitted to a destination node. Where data has been lost in transit from source to destination, TCP can retransmit the data until a timeout condition is reached or until successful delivery has been achieved. TCP can also recognize duplicate messages and discards them appropriately. If the sending device is transmitting too fast for the receiving device, TCP can employ flow control mechanisms to slow data transfer. TCP can also communicate delivery information to the upper-layer protocols and applications it supports.
User Datagram Protocol (UDP) provides connectionless data transport. UDP is a much simpler protocol than TCP and is useful in situations where the reliability mechanisms of TCP are not necessary.
UDP, which is datagram-based (or connectionless), is well-suited for voice traffic, for the following reasons:
Many routing protocols exist. The following are among the most common:
RIP uses a single routing metric (hop count) to measure the distance to a destination network. This means that if multiple paths to a destination exist, RIP only maintains the path with the fewest hops, even if other paths have a higher aggregate bandwidth, lower aggregate delay, less congestion, and so on.
Enhanced Interior Gateway Routing Protocol (EIGRP) uses significantly less bandwidth than IGRP or other distance-vector protocols. A router using this algorithm develops its routing table using the concept of a feasible successor. A feasible successor is a neighboring router that has the least-cost path to a destination.
When a router detects that a link has failed, if a feasible successor has an alternate route, the router switches to the alternate route immediately, without causing any network traffic. If there is no successor, the router sends a query to neighbors. The query propagates across the network until a new route is found.
An Enhanced IGRP router develops a topology table that contains all destinations advertised by neighboring routers. Each entry in the table contains a destination and a list of neighbors that have advertised the destination. For each neighbor, the entry includes the metric that the neighbor advertised for that destination. A router computes its own metric for the destination by using each neighbor's metric in combination with the local metric the router uses to reach the neighbor. The router compares metrics and determines the lowest-cost path to a destination and a feasible successor to use in case the lowest-cost path fails.
An OSPF router multicasts link-state advertisements (LSAs) to all other routers within the same hierarchical area. The LSA advertises the status of attached interfaces and the cost of sending a data packet on the interface. (Cost is the OSPF metric.)
OSPF routers accumulate link-state information to calculate the shortest path to a destination network. The result of the calculation is a database of the topology, called the link-state database. Each router in an area has an identical database.
All routers run the same algorithm, in parallel. From the link-state database, each router constructs a tree of shortest paths, with itself as the root of the tree. The shortest-path tree provides the route to each destination. Externally derived routing information appears on the tree as leaves. When several equal-cost routes to a destination exist, traffic is distributed equally among them.
IP addresses are globally unique, 32-bit numbers assigned by the Network Information Center. Globally unique addresses permit IP networks anywhere in the world to communicate with each other.
An IP address is divided into three parts. The first part designates the network address, the second part designates the subnet address, and the third part designates the host address. Subnet addresses are present only if the administrator has decided that the network should be divided into subnetworks. (See "Dividing Networks with Subnets" later in this chapter.) The lengths of the network, subnet, and host fields all vary.
IP addressing supports three different network classes. Class A networks are intended mainly for use with a few very large networks, because they provide only 8 bits for the network address field. Class B networks allocate 16 bits, and Class C networks allocate 24 bits for the network address field. Class C networks only provide 8 bits for the host field, however, so the number of hosts per network may be a limiting factor. In all three cases, the leftmost bit(s) indicate the network class.
IP addresses are written in dotted decimal format; for example, 34.0.0.1. Figure 8-1 shows the address formats for Class A, B, and C IP networks.
IP networks can also be divided into smaller units, called subnets. Subnets provide extra flexibility for administrators. For example, assume that a network has been assigned a Class B address, and all the nodes on the network currently conform to a Class B address format. Further assume that the dotted decimal representation of this network's address is 128.10.0.0. (All zeros in the host field of an address specifies the entire network.) Rather than change all the addresses to some other basic network number, the administrator can subdivide the network using subnetting. This is done by borrowing bits from the host portion of the address and using them as a subnet field, as shown in Figure 8-2.
If a network administrator has chosen to use 8 bits of subnetting, the third octet of a Class B IP address provides the subnet number. For example, address 128.10.1.0 refers to network 128.10, subnet 1; address 128.10.2.0 refers to network 128.10, subnet 2; and so on.
The number of bits borrowed for the subnet address varies. To specify how many bits are used, IP provides the subnet mask. Subnet masks use the same format and representation technique as IP addresses. Subnet masks have ones in all bits except those bits that specify the host field. For example, the subnet mask that specifies 8 bits of subnetting for Class A address 34.0.0.0 is 255.255.0.0. The subnet mask that specifies 16 bits of subnetting for Class A address 34.0.0.0 is 255.255.255.0. Both of these subnet masks are shown in Figure 8-3.
All subnets of the same network number typically use the same subnet mask, enabling an administrator to choose an eight-bit mask for all network subnets. Though this strategy is easy to implement and manage, it wastes address space in some networks. Some subnets have many hosts and some have only a few, but each consumes an entire subnet number. Serial lines are the most extreme example, because each has only two hosts that can be connected via a serial line subnet.
As IP subnets have grown, administrators have looked for ways to use their address space more efficiently. One of the techniques that has resulted is called the Variable Length Subnet Mask (VLSM). With VLSM, an administrator can use a long mask on networks with few hosts and a short mask on subnets with many hosts. However, this technique is more complex than making them all one size, and addresses must be assigned carefully. OSPF and EIGRP support VLSM.
This section presents protocol-related troubleshooting information for TCP/IP connectivity and performance problems. This section focuses on general TCP/IP problems and on routing problems related to RIP, EIGRP, and OSPF.
Each of the following sections describes a specific symptom, the problems that are likely to cause each symptom, and the solutions to those problems.
Symptom A new interface is added to a router, but when routing is configured, it does not function properly on the new interface.
Table 8-1 outlines the problems that might cause this symptom and describes solutions to those problems.
| Possible Problem | Solution | |||
|---|---|---|---|---|
Interface or LAN protocol is down | Step 1 | Enter the show interfaces privileged EXEC command to determine whether the interface is "administratively down": C7750#show interface serial 0 Serial0 is administratively down, | ||
| Step 2 | If the interface is administratively down, bring up the interface using the no shutdown interface configuration command. The following is an example of the no shutdown command: C7750(config)#int serial0 C7750(config-if)#no shutdown C7750(config-if)# | ||
| Step 3 | Enter the show interfaces command again to see whether the interface is now up. | ||
| Step 4 | If the interface is still down, there might be a hardware or media problem. For hardware problems, see "Solving Hardware Problems." For serial problems, see "Solving Serial Connection Problems." For Ethernet problems, see "Solving Ethernet Problems." | ||
Misconfigured or missing MRP or router configuration command | Step 1 | Enter the show running-config privileged EXEC command to view the device configuration. | ||
| Step 2 | Ensure that there is a configuration command specified for the network to which the interface belongs. For example, if you assign the IP address 192.168.52.42 to the new interface, enter the following commands to enable OSPF on the interface: c7750(config)#router OSPF c7750(config-router)#network 192.168.52.0 Also ensure that process IDs, addresses, and other variables are properly specified for the routing protocol you are using. For more information, refer to the Cisco IOS IP and IP Routing Command Reference. | ||
No active interfaces are configured with an IP address (OSPF only) |
|
C7750(config)#router ospf 100 C7750(config)# OSPF: Could not allocate router id | ||
| Step 1 | Enter the show ip interfaces privileged EXEC command on the device to ensure there is an interface that is up and configured with an IP address. | ||
| Step 2 | If there is no active interface with an IP address, configure an interface with the ip address interface configuration command. If necessary, use the no shutdown interface configuration command to bring up an interface. The following example shows the steps to enter configuration mode, assign an IP address to serial 0, and perform a no shutdown command on the interface: C7750#conf t Enter configuration commands, one per line. |
Symptom Connection attempts using some applications are successful, but attempts using other applications fail. For instance, you might be able to ping a host successfully, but Telnet connections fail.
Table 8-2 outlines the problems that might cause this symptom and describes solutions to those problems.
| Possible Problem | Solution | |||
|---|---|---|---|---|
Misconfigured access control lists (ACLs) or other filters | Step 1 | Enter the show running-config command to check each MRP and router in the path. Determine whether there are IP ACLs configured on each device. | ||
| Step 2 | If there are IP ACLs enabled on a device, disable them by entering the appropriate commands. An ACL may be filtering traffic from a TCP or UDP port. For example, to disable input ACL 80, enter the following command: C7750(config-if)#no ip access-group 80 in | ||
| Step 3 | After disabling all the ACLs on the device, determine whether the application operates normally. | ||
| Step 4 | If the application operates normally, an ACL was probably blocking traffic. | ||
| Step 5 | To isolate the problematic ACL, enable ACLs one at a time until the application no longer functions. Check the misconfigured ACL to determine whether it is filtering traffic from any TCP or UDP ports. | ||
| Step 6 | If the misconfigured ACL denies specific TCP or UDP ports, make sure that it does not deny the port used by the application in question (such as TCP port 23 for Telnet). Enter explicit permit statements for those ports used by applications you want to have functional. The following commands allow DNS1 and NTP2 requests and replies: access-list 101 permit udp 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255 eq 53 | ||
| Step 7 | If you altered an ACL, enable it to determine whether the application can still operate normally. | ||
| Step 8 | If the application operates normally, perform the preceding steps to isolate any other misconfigured ACLs until the application operates correctly with all ACLs enabled.
|
| 1DNS = Domain Naming System 2NTP = Network Time Protocol |
Misconfigured ACLs can cause connectivity and performance problems. Suppose that there are three interconnected routers (X, Y, and Z). When an administrator attempts to trace the route using the trace command, the connection fails, despite the fact that telnet and ping commands successfully reach Router Z from Router X.
When examining the configuration of Router Y (the middle router), the administrator finds the following extended ACL configured on the router:
C7750#show ip access-lists
Extended IP access list 101
permit tcp any any eq telnet
permit icmp any any
C7750#show running-config
[...]
interface Serial0
ip address 192.168.54.92 255.255.255.0
ip access-group 101 out
[...]
The ACL permits only Internet Control Message Protocol (ICMP) traffic (used by the ping application) and TCP traffic (used by the Telnet application) to pass serial interface0 on Router Y. Any traffic sent to UDP ports, including the default ports used by the trace application (UDP ports 33434 and above), is implicitly denied.
To allow trace traffic to pass through Router Y, the administrator makes the following change to the ACL:
C7750#configure terminal
C7750(config)#access-list 101 permit udp any any gt 33433
C7750(config)#^Z
C7750#
%SYS-5-CONFIG_I: Configured from console by console
C7750#show ip access-lists
Extended IP access list 101
permit tcp any any eq telnet
permit icmp any any
permit udp any any gt 33433
C7750#
Symptom Problems occur when forwarding BOOTP or other UDP broadcast packets. UDP broadcasts sent from network hosts are not forwarded by MRPs or routers. Diskless workstations cannot boot.
Table 8-3 outlines the problems that might cause this symptom and describes solutions to those problems.
| Possible Problem | Solution | |||
|---|---|---|---|---|
Missing or misconfigured ip helper-address specification | Step 1 | Enter the debug ip udp privileged EXEC command on the device that should be receiving packets from the host. Check the output of the command to see whether packets are being received from the host.
| ||
| Step 2 | If the device does not receive packets from the host, there is a problem with the host or the application. Consult the documentation for the host or application. If the device receives packets from the host, enter the show running-config privileged EXEC command to check the configuration of the device interface that first receives the packet from the host. | ||
| Step 3 | Look for an ip helper-address address interface configuration command entry for that interface. Make sure that the specified address is correct (it should be the IP address of a server application such as a BOOTP server). If there is no command entry, then no helper address is configured. | ||
| Step 4 | If there is no IP helper address configured, or if the wrong address is specified, add or change the helper address by entering the ip helper-address address interface configuration command. For example, to configure the IP address 192.168.192.6 as the helper address on Ethernet interface 0, enter the following commands: C7750(config)#interface e0 C7750(config-if)#ip helper-address 192.168.192.6 | ||
UDP broadcasts are being forwarded out nondefault ports | Step 1 | Specifying an IP helper address ensures that broadcasts from only a certain default set of UDP ports are forwarded. UDP broadcasts forwarded out other ports require further configuration. Enter an ip forward-protocol udp port global configuration command on the device for each applicable port. For example, to forward UDP broadcasts from port 200, enter the following command: C7750(config)#ip forward-protocol udp 200 | ||
| Step 2 | To allow forwarding of all UDP broadcasts, enter the following command: C7750(config)#ip forward-protocol udp | ||
UDP broadcast forwarding is disabled on UDP ports | Step 1 | Use the show running-config privileged EXEC command on the device and look for any no ip forward-protocol udp global configuration command entries. Such entries disable the forwarding of UDP traffic out specific ports. For example, entering the no ip forward-protocol udp 53 global configuration command disables the forwarding of all UDP traffic out port 53, which is the default port for DNS broadcasts. The following entry is shown in the configuration: no ip forward-protocol udp domain | ||
| Step 2 | If UDP broadcasts are disabled at specific UDP ports, enter the ip forward-protocol udp port global configuration command (you can also specify a keyword, such as domain, rather than the port number). For example, to reenable DNS broadcasts, enter the following command: C7750(config)#ip forward-protocol udp domain To allow forwarding of BOOTP broadcasts, enter the following command: C7750(config)#ip forward-protocol udp bootp To allow forwarding of all UDP broadcasts, enter the following command: C7750(config)#ip forward-protocol udp | ||
ACLs or other lists are misconfigured | Step 1 | Enter the show running-config command to check the configuration of each MRP or router in the path. See if there are ACLs configured on the device. | ||
| Step 2 | If there are ACLs enabled on the device, disable them using the appropriate commands. For example, to disable input ACL 10, enter the following command: C7750(config-if)#no ip access-group 10 in | ||
| Step 3 | After disabling all ACLs, determine whether BOOTP or other UDP broadcasts are forwarded normally. If broadcasts are forwarded normally, a misconfigured ACL was probably blocking traffic. | ||
| Step 4 | To isolate the misconfigured ACL, enable ACLs one at a time until broadcasts are no longer forwarded. | ||
| Step 5 | Check the misconfigured ACL to determine whether it is filtering traffic from any UDP ports. If an ACL denies specific UDP ports, make sure that it does not deny ports used to forward the broadcast traffic in question (such as port 67 for BOOTP transmissions or port 68 for BOOTP replies). Enter explicit permit statements for those ports used to forward broadcasts that you want to have forwarded. The following is an example of using a permit statement in an ACL: C7750(config)#access-list 101 permit udp any any eq | ||
| Step 6 | If you altered an ACL, enable it to see whether broadcasts are still forwarded normally. | ||
| Step 7 | If problems persist, perform the preceding steps on MRPs and routers in the path until broadcast traffic is forwarded correctly.
|
Posted: Mon Oct 2 13:50:33 PDT 2000
Copyright 1989-2000©Cisco Systems Inc.