Network Performance Problems

Network performance problems are problems that cause your network to respond slowly. Because TCP/IP protocols commonly use TTL (Time to Live) settings limiting the age of a packet on the network, slow performance can cause lost packets and therefore loss of connectivity. Even if you don't lose connectivity, slow network performance can be an irritation and a source of lost productivity. A common cause for poor network performance is excessive traffic. Your network might be experiencing heavy traffic because there are too many computers on the network, or the cause might be a malfunctioning device such as a network adapter creating unnecessary traffic on the network in what is known as a broadcast storm. Sometimes the cause for poor network performance is a downed router that has stopped forwarding traffic and caused a bottleneck somewhere else in the network.

TCP/IP offers a number of utilities that let you see where packets are going and display statistics related to network performance. The following sections discuss these utilities, which will help you find answers to problems related to network performance.

Traceroute

The traceroute utility is used to trace the path taken by datagrams as they travel from your computer through multiple gateways to their destinations. The path traced by this utility is just one path between the source and destination; there is no guarantee or assumption that datagrams will always follow this path. If you are configured to use DNS, you can often determine the names of cities, regions, and common carriers from the responses. traceroute is a slow command; you need to give it approximately 10–15 seconds per router.

Traceroute (or tracert if you are using Windows NT/2000/XP) makes use of the ICMP protocol to locate each router that stands between your client computer and the destination computer. The TTL value tells you the number of routers or gateways that a packet has passed through. By manipulating the TTL value that is used in the original outgoing ICMP Echo message, traceroute is able to find each router along the path, as follows:

In addition to locating each router or gateway the datagram travels through, the traceroute utility also records the round-trip time that it takes to reach each router. Depending on the implementation, traceroute might actually send more than a single Echo message to each router. For example, in the Windows 2000 version of this utility (tracert), two additional Echo messages are sent to each router so that it can better judge the round-trip time. However, you shouldn't use this round-trip time value to judge your network's performance precisely. Many routers simply give a lower priority to ICMP traffic and spend most of their processing time forwarding more important datagrams.

The syntax for the traceroute command is simply traceroute followed by an IP address, a DNS name, or even a URL:

traceroute 198.137.240. 91
traceroute www.whitehouse.gov.

Traceroute is useful for showing you the path a datagram traverses on the way to its destination. Traceroute can also provide some diagnostic capabilities.

route

As you learned in Hours 9, "Network Hardware," and 10, "Routing," each computer and each router contains a routing table. Most routers use special routing protocols to exchange routing information and dynamically update their tables periodically. However, there are many times when it is necessary to add entries manually to route tables on routers and host computers.

The route command has many uses in TCP/IP networking. You can use route to display the routing table in cases where packets from a host are not being routed efficiently. If the traceroute command reveals an abnormal or inefficient path, you might be able to use route to determine why that path is being used and possibly to configure a more efficient route.

The route command is also used to add, delete, and change entries in routing tables manually. Some options include the following:

• route print— This form of the route command displays the current entries in the routing table. See Figure 13.4 for an example of output from a route print command. As you can see, several entries refer to various networks, for example 0.0.0.0, 127.0.0.0, and 192.59.66.0; some are used for broadcasting 255.255.255.255 and 207.168.243.255, and others are for multicasting 224.0.0.0. All of these entries were added automatically as a result of configuring network adapters with IP addresses.

  Figure 13.4. A route print command displays the current information in the routing table.

  

• route add— Use this form of the route command to add a new routing entry to a routing table. For example, to specify a route to a destination network 207.34.17.0 that is five router hops away and passing first through a router with an IP address on the local network of 192.59.66.5 and the subnet mask of 255.255.255.224, you would enter the following command:

  route add 207.34.17.0 mask 255.255.255.224 192.59.66.5 metric 5
  

  By the Way

  The route information added in this way is volatile, and is lost if the computer or router reboots. Often a series of route add commands is contained in startup scripts so that it is reapplied every time the computer or router boots.

  
  

• route change— You can use this syntax to change entries in the routing table. The following example changes the routing of the data to a different router that has a more direct three-hop path to the destination:

  route change 207.34.17.0 mask 255.255.255.224 192.59.66.7 metric 3
  

• route delete— Use this command syntax to delete an entry from the routing table:

  route delete 207.34.17.0
  

Netstat

The netstat utility displays statistics related to the IP, TCP, UDP, and ICMP protocols. The statistics display numerical counts for items such as datagrams sent, datagrams received, and a wide variety of errors that could have occurred.

You should not be surprised if your computer occasionally receives datagrams that cause errors, discards, or failures. TCP/IP is tolerant of these types of errors and automatically resends the datagram. Discards occur when a datagram is delivered to the wrong location. If your computer acts as a router, it will also discard datagrams when TTL reaches zero on a routed datagram. Reassembly failures occur when all the fragments fail to arrive within a time period based on the TTL value in received fragments. Again, like errors and discards, occasional reassembly failures should not be a reason for concern. In all three cases, accumulated counts that are a significant percentage of the total IP packets received or that rapidly accumulate should cause you to investigate why this is occurring.

The following list describes various netstat command options:

• netstat -s— This option displays statistics on a protocol-by-protocol basis. If user applications such as Web browsers seem unusually slow or are incapable of displaying data such as Web pages, you might want to use this option to see what information is displayed. You can look through the rows of statistics for the words error, discard, or failure. If the counts in these rows are significant relative to the IP packets received, this should prompt further investigation.

• netstat -e— This option displays statistics about ethernet. Items listed include total bytes, errors, discards, number of directed datagrams, and number of broadcasts. These statistics are provided for datagrams both sent and received.

• netstat -r— This option displays routing table information similar to what is seen with the route print command. In addition to the active routes, current active connections are also displayed.

• netstat -a— This option displays the list of all active connections, including both established connections and those that are listening for a connection request.

The following three options provide subset information of what is displayed with the -a option:

• netstat -n— This option displays all established active connections.

• netstat -p TCP— This option displays established TCP connections.

• netstat -p UDP— This option displays established UDP connections.

See Figure 13.5 for an example of the statistics displayed by netstat -s.

Nbtstat

The nbtstat (NetBIOS over TCP/IP statistics) utility provides statistics about NetBIOS over TCP/IP (see Hour 11). Nbtstat allows you to view the NetBIOS name table on the local computer or on a remote computer.

The following command options are used in relation to the local computer:

• nbtstat -r— This command causes the NetBIOS name cache to be purged and reloaded. This is done to load recently added entries from the LMHosts file. (LMHosts entries are covered in Hour 11.)

• nbtstat -n— This command displays the names and services registered on the local computer.

• nbtstat -c— This command displays the contents of the NetBIOS name cache that holds the NetBIOS names to IP address pairs of other computers with which this computer has had recent communication.

• nbtstat -r— This command lists the count of registrations and resolved names of other computers and whether they were registered or resolved by broadcast or by a name server.

See Figure 13.6 for examples of these outputs.

The nbtstat command can also be used to view the NetBIOS name table of remote computers. The output is similar to nbtstat -n on the local computer.

• nbtstat -A <IP address>— Displays the name table including physical addresses from another computer by using its IP address.

• nbtstat -a <NetBIOS name>— Displays the name table including physical addresses from another computer by using its NetBIOS name.

Similarly, two other nbtstat command options enable you to view the list of NetBIOS connections that a remote computer has open. This list is called a connections table:

• nbtstat -S <IP address>— Displays the NetBIOS connections table of another computer using its IP address.

• nbtstat -s <NetBIOS name>— Displays the NetBIOS session table of another computer using its NetBIOS name.

Packet Sniffers

Utilities known as sniffers capture data from the network into a buffer or a file. After the data is captured, you can display the contents one frame or datagram at a time. Packet sniffers are useful for analyzing subtle network-excessing traffic. You can also use sniffers to find the source of corrupt packets that might have come from a malfunctioning device. You can trace an ethernet frame by its physical address. You can analyze header information from any protocol level (see Hours 3, "The Network Access Layer," 4, and 6) to look for clues.

Figure 13.7 shows the sequence of 10 datagrams that was initiated by entering a ping command. The top window shows the 10 datagrams starting with an ARP request and an ARP reply followed by four ICMP request/reply pairs. The middle window decodes the ICMP header, and in the bottom frame you can see the 32 bytes of data in the datagram. The data includes the complete alphabet followed by the letters abcdef, for a total of 32 bytes of data.