Dive into Network Monitor

Reading Packet Captures
As you know, network traffic is broken up into packets before it's sent across the network. Most packets on your network are typically TCP; however, you can also have other types of packets, such as DNS, ICMP, NetBIOS over TCPIP (NBT), and UDP. Each packet contains a TCP flag in the packet's header section as well as other flags, which are listed below in the order in which they appear in the header.

• U (URG)—urgent; data is sent out of sequence.
• A (ACK)—acknowledgment that lets the sender know the packet was received. The packet receiver sends an ACK packet that includes the sender's sequence number plus the length of the data packet to verify that the packet information was properly received.
• P (PSH)—forces data delivery before the buffer is full. This flag is used primarily for interactive traffic.
• R (RST)—reset; the session was terminated abnormally. The presence of many packets with the RST flag could indicate a problem on your network.
• S (SYN)—used to start a session and agree on an initial sequence number; often used for Denial of Service (DoS) attacks. Hackers can attempt to initialize numerous sessions from an invalid IP address, thereby causing the server to respond with an ACK packet that's destined for the invalid IP address. Most firewalls implement countermeasures to guard against this type of attack.
• F (FIN)—graceful end to a TCP session. A FIN packet indicates that the sender is finished sending data.

Flags to watch. Most networks should have traffic that consists mostly of ACK and PSH packets. Unless the server is constantly establishing new sessions, you should see relatively few SYN packets. Servers that experience a large number of SYN packets could be under some type of DoS attack (aka a SYN flood). The number of FIN packets should be roughly equal to the number of SYN packets. You should see few RST packets. A high number of RST packets is a possible symptom of an intermittent network connection, beaconing NIC, high network traffic, faulty network switch or hub, or another type of hardware failure.

Port numbers. As you know, most TCP/IP packets identify a source and a destination port. When you read the packet information, make a note of the source and destination ports on the server. You should also become familiar with well-known ports and the ports that Windows uses. If you notice an unfamiliar port in a capture, it could be a symptom of hacking activity. Table 2 lists some commonly used ports.

After you run a packet capture, you can use the display filter to filter the packet capture for a specific protocol. For example, if you're troubleshooting an HTTP connection problem, use Network Monitor to capture the network packets, then set a filter only on HTTP packets (port 80) to troubleshoot specific HTTP communication problems.

Retransmissions. You can use Network Monitor to troubleshoot connectivity problems. Look for reset, or retransmission, packets (i.e., packets that contain the R flag in the packet header) that have increasing timeout lengths, with static sequence numbers in multiple packets. Retransmissions occur when a transmission between two computers is interrupted for any reason—for example, because of failed hardware or WAN delays. When a retransmission occurs, the timeout value is doubled until the retransmission is attempted 5 times (the default value). Figure 4 shows a capture that occurred when a network cable on the client was disconnected during an FTP file transfer. Frame numbers 834­992 (left column in the top pane) have the same sequence value in each packet, which indicates a connectivity problem. Frames 1172­1385 also share the same sequence number. With normal FTP traffic, the sequence number in each packet should increase, not stay the same. Notice that it took a total of 10 packets to abort the FTP transmission—5 retransmission attempts on the FTP transfer itself, and 5 retransmission attempts to close the connection. Look at the timestamp of 77.012668 in frame 834. The time difference between packet 834 and 845 (77.668893 - 77.012668) is 0.656225. The time difference between packets 845 and 868 is 1.312449, which is twice as long as 0.656225. For each successive packet, the time values double until the maximum retry value (in this case, 5) is reached.

On a slow WAN link or other line with a large variance in connection speed, you might have to increase the maximum retry number. To change this value, on the server running Network Monitor, navigate to the registry subkey HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters and add the DWORD entry TcpMaxDataRetransmissions. Set the value to decimal and change the value to a number larger than 5.

A packet trace can tell you the "best" value for your environment. For example, if you're experiencing a timeout problem caused by multiple retransmissions, increase TcpMaxDataRetransmissions to a fairly high value (e.g., 20) and see how many connections can recover from retransmission packets. If you notice that most FTP sessions can recover within, say, 8 packet retransmissions, you can set TcpMaxDataRetransmissions on your server to 9. This value lets the server time out if the WAN is down but attempt a reconnection with the client if the connection is still alive.

The timeout value for any session is initially set to 3 seconds, then is adjusted based on the connection speed. Our sample connection was on a LAN, so the first connection retry time was relatively short—0.65 seconds. On a slow WAN link, increasing the maximum retransmissions can cause the server to take a long time before it times out. For a slow WAN connection that starts with an initial retry value of 5 seconds, how long would it take for a connection to time out, assuming that the maximum-retransmissions value was 6? The answer is 315 seconds (5 + 10 + 20 + 40 + 80 + 160), or more than 5 minutes.