The sections in this chapter describe common features of TCP/IP and provide solutions to some of the most common TCP/IP problems. The following items will be covered:
•
TCP/IP Introduction
•
Tools for Troubleshooting IP Problems
•
General IP Troubleshooting Theory and Suggestions
•
Troubleshooting Basic IP Connectivity
•
Troubleshooting Physical Connectivity Problems
•
Troubleshooting Layer 3 Problems
•
Troubleshooting Hot Standby Router Protocol (HSRP)
TCP/IP Introduction
In the mid-1970s, the Defense Advanced Research Projects Agency (DARPA) became interested in establishing a packet-switched network to provide communications between research institutions in the United States. DARPA and other government organizations understood the potential of packet-switched technology and were just beginning to face the problem that virtually all companies with networks now have—communication between dissimilar computer systems.
With the goal of heterogeneous connectivity in mind, DARPA funded research by Stanford University and Bolt, Beranek, and Newman (BBN) to create a series of communication protocols. The result of this development effort, completed in the late 1970s, was the Internet Protocol suite, of which the Transmission Control Protocol (TCP) and the Internet Protocol (IP) are the two best-known protocols.
The most widespread implementation of TCP/IP is IPv4 (or IP version 4). In 1995, a new standard, RFC 1883—which addressed some of the problems with IPv4, including address space limitations—was proposed. This new version is called IPv6. Although a lot of work has gone into developing IPv6, no wide-scale deployment has occurred; because of this, IPv6 has been excluded from this text.
Internet Protocols
Internet protocols can be used to communicate across any set of interconnected networks. They are equally well suited for local-area network (LAN) and wide-area network (WAN) communications. The Internet suite includes not only lower-layer specifications (such as TCP and IP), but also specifications for such common applications as e-mail, terminal emulation, and file transfer. Figure 7-1 shows some of the most important Internet protocols and their relationships to the OSI reference model.
As an interesting side note, the seven-layer model actually came about after TCP/IP. DARPA used a four-layer model instead, which the OSI later expanded to seven layers. This is why TCP/IP doesn't generally fit all that well into the seven-layer OSI model.
Figure 7-1 The Internet Protocol Suite and the OSI Reference Model
Creation and documentation of the Internet Protocol suite closely resemble an academic research project. The protocols are specified and refined in documents called Requests For Comments (RFCs), which are published, reviewed, and analyzed by the Internet community. Taken together, the RFCs provide a colorful history of the people, companies, and trends that have shaped the development of what is today the world's most popular open-system protocol suite.
The Network Layer
IP is the primary Layer 3 protocol in the TCP/IP suite. IP provides the logical addressing that enables communication across diverse networks. IP also provides fragmentation and reassembly of datagrams and error reporting. Along with TCP, IP represents the heart of the Internet Protocol suite. The IP packet format is shown in Figure 7-2.
Figure 7-2 The IP Packet Format
The fields of the IP packet are as follows:
•
Version—Indicates the version of this IP datagram.
•
IP Header Length (IHL)—Indicates the datagram header length in 32-bit words.
•
Type-of-Service—Specifies how a particular upper-layer protocol would like the current datagram to be handled. Datagrams can be assigned various levels of importance using this field.
Today this field is used primarily to provide quality of service (QoS) capabilities to TCP/IP for applications requiring predictable bandwidth or delay. RFC 2474 describes a method by which the TOS field is replaced by a DS field that is used to provide differentiated services (DiffServ) on networks. This field is split into two parts. The first 6 bits are used for the DSCP codepoint, which is used to differentiate traffic. The last 2 bits, or CU, are ignored by DiffServ-compliant nodes.
•
Total Length—Specifies the length of the entire IP packet, including data and header, in bytes.
•
Identification—Consists of an integer identifying this datagram. This field is used to help piece together datagram fragments.
•
Flags—Consists of 3 bits, of which the low-order 2 bits control fragmentation. One bit specifies whether the packet can be fragmented; the second bit specifies whether the packet is the last fragment in a series of fragmented packets.
•
Time-to-Live—Maintains a counter that gradually decrements down to zero, at which point the datagram is discarded. This keeps packets from looping endlessly.
•
Protocol—Indicates which upper-layer protocol receives incoming packets after IP processing is complete.
•
Header Checksum—Helps ensure IP header integrity.
•
Source Address—Specifies the sending node.
•
Destination Address—Specifies the receiving node.
•
Options—Allows IP to support various options, such as security.
•
Data—Contains upper-layer information.
Addressing
As with all network layer protocols, the addressing scheme is integral to the process of routing IP datagrams through an internetwork. An IP address is 32 bits in length, divided into either two or three parts. The first part designates the network address, the second part (if present) designates the subnet address, and the final part designates the host address. Subnet addresses are present only if the network administrator has decided that the network should be divided into subnetworks. The lengths of the network, subnet, and host fields are all variable.
Today's Internet does not segment addresses along classful bounds—it is almost entirely classless. The separation between networks and subnets has been effectively eliminated. The requirement to understand network classes and the difference between a network and a subnet remains solely because of configuration and behavioral issues with network devices.
IP addressing supports five different network classes, and the high-order—far-left—bits indicate the network class:
•
Class A networks provide 8 bits for the Network Address field. The high-order bit (at far left) is 0.
•
Class B networks allocate 16 bits for the Network Address field and 16 bits for the Host Address field. This address class offers a good compromise between network and host address space. The first 2 high-order bits are 10.
•
Class C networks allocate 24 bits for the Network Address field. Class C networks provide only 8 bits for the Host field, however, so the number of hosts per network may be a limiting factor. The first 3 high-order bits are 110.
•
Class D addresses are reserved for multicast groups, as described formally in RFC 1112. The first 4 high-order bits are 1110.
•
Class E addresses are also defined by IP but are reserved for future use. The first 4 high-order bits are 1111.
IP addresses are written in dotted decimal format (for example, 34.10.2.1). Figure 7-3 shows the address formats for Class A, B, and C IP networks.
Figure 7-3 Class A, B, and C Address Formats
IP networks can also be divided into smaller units called subnets. Subnets provide extra flexibility for network 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. Then assume that the dotted decimal representation of this network's address is 172.16.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 7-4.
Figure 7-4 Subnet Addresses
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 172.16.1.0 refers to network 172.16, subnet 1; address 172.16.2.0 refers to network 172.16, subnet 2; and so on. In today's world, the difference between subnet bits and the natural mask has become blurred, and you will often see only a prefix length that specifies the length of the entire mask (natural mask plus subnet bits). It is still important to understand the difference between the natural network mask, which is determined by the network class, and the subnet mask, because routers sometimes make assumptions based on the natural mask of an address. For example, the natural mask of 10.1.1.1/24 is 8 bits because this is a class A network, even though the subnet mask is 24 bits.
Subnet masks can be expressed in two forms: prefix length (as in /24), or dotted-decimal notation (As in 255.255.255.0). Both forms mean exactly the same thing and can easily be converted to the other, as seen in Example 7-1.
Example 7-1 Subnet Mask Expressed in Prefix Length and Dotted Decimal
255.255.255.0 = 11111111 11111111 11111111 00000000 = /24 bits (count the
ones).
|
On some media (such as IEEE 802 LANs), the correlation between media addresses and IP addresses is dynamically discovered through the use of two other members of the Internet Protocol suite: the Address Resolution Protocol (ARP) and the Reverse Address Resolution Protocol (RARP). ARP uses broadcast messages to determine the hardware Media Access Control (MAC)-layer address corresponding to a particular IP address. ARP is sufficiently generic to allow use of IP with virtually any type of underlying media-access mechanism. RARP uses broadcast messages to determine the Internet address associated with a particular hardware address. RARP is particularly important to diskless nodes, which may not know their IP address when they boot.
Internet Routing
Routing devices in the Internet have traditionally been called gateways—an unfortunate term because elsewhere in the industry, the term gateway applies to a device with somewhat different functionality. Gateways (which we will call routers from this point on) within the Internet are organized hierarchically.
Dynamic routing protocols, such as RIP and OSPF, provide a means by which routers can communicate and share information about routes that they have learned or are connected to. This contrasts with static routing, in which routes are established by the network administrator and do not change unless they are manually altered. An IP routing table consists of destination address/next-hop pairs. A sample entry, shown in Figure 7-5, is interpreted as meaning, "To get to network 34.1.0.0 (subnet 1 on network 34), the next stop is the node at address 54.34.23.12."
Figure 7-5 An Example of an IP Routing Table
IP routing specifies that IP datagrams travel through internetworks one hop at a time; the entire route is not known at the outset of the journey. Instead, at each stop, the next destination is calculated by matching the destination address within the datagram with an entry in the current node's routing table. Each node's involvement in the routing process consists only of forwarding packets based on internal information, regardless of whether the packets get to their final destination. In other words, IP does not provide for error reporting back to the source when routing anomalies occur. This task is left to other Internet protocols, such as the Internet Control Message Protocol (ICMP) and TCP protocol.
ICMP
ICMP performs a number of tasks within an IP internetwork, the principal of which is reporting routing failures back to the source of a datagram. In addition, ICMP provides helpful messages such as the following:
•
Echo and reply messages to test node reachability across an internetwork
•
Redirect messages to stimulate more efficient routing
•
Time exceeded messages to inform sources that a datagram has exceeded its allocated time to exist within the internetwork
•
Router advertisement and router solicitation messages to determine the addresses of routers on directly attached subnetworks
The Transport Layer
The Internet transport layer is implemented by Transport Control Protocol (TCP) and the User Datagram Protocol (UDP). TCP provides connection-oriented data transport, whereas UDP operation is connectionless.
TCP
TCP provides full-duplex, acknowledged, and flow-controlled service to upper-layer protocols. It moves data in a continuous, unstructured byte stream in which bytes are identified by sequence numbers. TCP can support numerous simultaneous upper-layer conversations. The TCP packet format is shown in Figure 7-6.
Figure 7-6 The TCP Packet Format
The fields of the TCP packet are described here:
•
Source port and destination port—Identify the points (sockets) at which upper-layer source and destination processes receive TCP services.
•
Sequence number—Usually specifies the number assigned to the first byte of data in the current message. Under certain circumstances, it can also be used to identify an initial sequence number to be used in the upcoming transmission.
•
Acknowledgment number—Contains the sequence number of the next byte of data that the sender of the packet expects to receive.
•
Data offset—Indicates the number of 32-bit words in the TCP header.
•
Reserved—Is reserved for future use.
•
Flags—Carries a variety of control information.
•
Window—Specifies the size of the sender's receive window (buffer space available for incoming data).
•
Checksum—Provides information used to determine whether the header was damaged in transit.
•
Urgent pointer—Points to the first urgent data byte in the packet.
•
Options—Specifies various TCP options.
•
Data—Contains upper-layer information.
UDP
UDP is a much simpler protocol than TCP and is useful in situations in which the reliability mechanisms of TCP are not necessary. The UDP header has only four fields: Source Port, Destination Port, Length, and UDP Checksum. The Source and Destination Port fields serve the same functions as they do in the TCP header. The Length field specifies the length of the UDP header and data, and the UDP Checksum field allows packet integrity checking. The UDP checksum is optional.
Upper-Layer Protocols
The Internet Protocol suite includes many upper-layer protocols representing a wide variety of applications, including network management, file transfer, distributed file services, terminal emulation, and electronic mail. Table 7-1 maps the best-known Internet upper-layer protocols to the applications that they support.
Table 7-1 Internet Protocol/Application Mapping (with Common Port Numbers)
Application | Protocols |
WWW browser | HTTP (TCP port 80) |
The Hypertext Transfer Protocol (HTTP) is used by Web browsers and servers to transfer the files that make up web pages. |
File transfer | FTP (TCP ports 20 and 21) |
The File Transfer Protocol (FTP) provides a way to move files between computer systems. Telnet allows virtual terminal emulation. |
Terminal emulation | Telnet (TCP port 23) |
The Telnet protocol provides terminal emulation services over a reliable TCP stream. The Telnet protocol also specifies how a client and server should negotiate the use of certain features and options. |
Electronic mail | SMTP (TCP port 25), POP3 (TCP port 110), IMAP4 (TCP port 143) |
The Simple Mail Transfer Protocol (SMTP) is used to transfer electronic mail between mail servers, and is used by mail clients to send mail. Mail clients do not generally use SMTP to receive mail. Instead, they use either the Post Office Protocol version 3 (POP3) or the Internet Message Access Protocol (IMAP); this will be discussed in greater detail later in this chapter. |
Network management | SNMP (UDP port 161) |
The Simple Network Management Protocol (SNMP) is a network management protocol used for reporting anomalous network conditions and setting network threshold values. |
Distributed file services | NFS, XDR, RPC (UDP port 111), X Windows (UDP ports 6000-6063) |
X Windows is a popular protocol that permits intelligent terminals to communicate with remote computers as if they were directly attached. Network file system (NFS), external data representation (XDR), and remote-procedure call (RPC) combine to allow transparent access to remote network resources. |
These and other network applications use the services of TCP/IP and other lower-layer Internet protocols to provide users with basic network services.
Domain Name System
TCP/IP uses a numeric addressing scheme in which each node is assigned an IP address that is used to route packets to a node on the network. Because it is much easier for people to remember names such as www.somedomain.com instead of 10.1.1.1, a protocol called Domain Name System (DNS) is used to map numbers to names, and vice versa. Most web pages refer to other web pages or links using these names instead of their IP addresses. This provides many advantages; for example, the address can change without breaking any links to a web page if the DNS table is also changed to point to the new address.
Tools for Troubleshooting IP Problems
The tools ping and traceroute, both in the TCP/IP protocol suite, will greatly assist in troubleshooting IP connectivity. Most operating systems and IP implementations come with these tools installed by default. On some UNIX platforms, however, you may need to download and install a traceroute package.
Cisco routers provide a basic method of viewing IP traffic switched through the router called packet debugging. Packet debugging enables a user to determine whether traffic is travelling along an expected path in the network or whether there are errors in a particular TCP stream. Although in some cases packet debugging can eliminate the need for a packet analyzer, it should not be considered a replacement for this important tool.
Packet debugging can be very intrusive—in some cases, it can cause a router to become inoperable until physically reset. In other instances, packets that are present on the network and switched through the router may not be reported by packet debugging. Thus, a firm conclusion cannot be drawn that a packet was not sent solely from the output of packet debugging; a network analyzer must be used to accurately make this assessment. Packet debugging should be used with extreme caution by only advanced operators because it can cause the router to lock up and stop routing traffic, if not used carefully. The risks of using packet debugging may be compounded by the necessity of disabling fast switching for packet debugging to be effective. As a general rule, packet debugging should not be used on a production router unless you have physical access to the router and are willing to risk it going down.
Solitaire: Instant Win
FreeCell: Instant Win
Hearts: Show All Card
Minesweeper: Stop The Timer
Pinball
