Tip of the Month

Tip of the Month Archive - 1999 & 1998

December 1999

When analyzing application problems over a network, consider the underlying transport layer in use. For example, the User Datagram Protocol (UDP) does not have the sequencing, flow control, or error recovery found in TCP. UDP simply adds port numbers to identify the end application and a checksum to protect its payload (one could argue that UDP is not really a true transport layer protocol). Thus, applications such as DNS, SNMP, and NFS over UDP, are more prone to failure in the event of network problems, and must have their own error recovery procedures. They also tend to be less efficient in terms of throughput and are more prone to packet loss due to lack of flow control.

November 1999

Experiencing a large amount of CRC or framing errors across your WAN? Set up a test to continually ping across the circuit using large packets (that have a higher probability of experiencing a CRC error), while capturing with your analyzer or observing your router's interface error statistics. At a minimum, check your CSU/DSU for timing problems that may be caused by a misconfiguration (such as the clock source), poor patch connections, several serially connected cables, or total cable lengths in excess of 50 feet. You may also want to repeat the ping test with the CSU/DSU in loopback mode. If all else fails, it could be a noisy serial line that your telco or service provider will need to test.

October 1999

Firewalls typically include intrusion detection (i.e. hacking) and malicious intent detection (e.g. a TCP SYN attack that can chew up a server’s ports, momentarily disrupting the service). Using a protocol analyzer can help augment the firewall’s logging of such events by capturing packets for tracing and auditing the evidence.

For example, setting a capture pattern match filter on the application layer FTP command of ‘PASS’ ORed with a pattern match of the FTP error code of '530' will capture all FTP login attempts and rejections. As another example, setting a pattern match on the IP protocol field for ‘06’ (TCP) ANDed a pattern match on the TCP flag field of ‘02’ will capture all of the TCP SYN packets for further study (such as the frequency of SYN packets). Depending on your protocol analyzer, you may be able to combine these two filters (using the OR condition) and more, allowing you to capture packets from the Internet side of your firewall for further intrusion detection analysis.

September 1999

When working with UTP (unshielded twisted pair) wiring it’s important to realize that the raw data rate rarely corresponds to the bandwidth actually utilized on the cable. It depends on the encoding technique used to transmit the binary information. For example, 10 Mbps Ethernet with Manchester encoding has a fundamental cable frequency of 10 MHz. 100 Mbps Ethernet uses 4B5B/MLT-3 encoding and has a fundamental frequency of 31.25 MHz. To further complicate matters, cable certification may require testing at higher frequencies due to the accompanying harmonic frequencies. Although 10 Mbps Ethernet only requires testing at 10 MHz, 100 Mbps Ethernet requires testing at 80 MHz (not 31.25 MHz) and Gigabit Ethernet requires testing at 100 MHz across all four pair. Check that your cable tester is “TSB67 Accuracy Level II” certified and that your Category 5 cable is tested to 100 MHz across all four pair.

August 1999

When using the traffic generation features that comes with many protocol analyzers, exercise extreme caution! You can design your own packet or replay one or more packets from a previous capture. The safest use for this feature is to simply replay a trace on an isolated, stand-alone segment for training purposes. Generating traffic for the sake of testing response time under additional load is usually not a good idea. Otherwise you may flood your network with broadcast packets if you don’t have router or VLAN containment, corrupt routing tables with IP RIP packets, attempt to setup bogus TCP connections with servers, and so on.

Also keep in mind that while you can replay a packet such as an ICMP PING and receive a response, editing that packet and changing information such as the destination IP address will cause it to be rejected by the destination. Why? You will also need to recalculate the 16-bit IP header checksum, a more complex proposition. An IPX host on the other hand, will usually accept an edited IPX packet since unlike IP, the checksum is disabled by default.

July 1999

Need to analyze remote WAN and LAN segments from the comfort of your cubicle? Fortunately you can, but with a few caveats.

Some remote probes or analyzers require you to effectively transfer all of the packets captured (imagine having to transfer a multi-megabyte capture over a unreliable or low throughput connection.) Another approach is to keep traffic to a minimum by emulating the screen and keyboard of the remote analyzer. The analysis and the packets stay on the remote machine. Yet a third approach is keep packet transfer to a minimum to only the packets we are currently viewing. Some products also combine the above methods with a second interface for "out of band" control and packet transfer. Carefully consider the impact of each approach on your ability to gather and analyze packets efficiently.

June 1999

Checking for an active link LED on the back of an Ethernet network interface card (NIC) means that only the receive side of the link is good. In other words, the NIC is receiving a link pulse from the hub. Since the NIC sends a link pulse on the transmit pair back to the hub, you will also need to check the other end for an active link LED. Chances are pretty good that if the link is okay on one end, it will be okay at the other end too, but why take the chance? Checking the LED at both ends is a simple continuity check for the UTP cable. For more extensive testing including distance, crosstalk, and Category 5 certification, use a high quality cable tester.

May 1999

When watching for problems or hacking attempts with NetWare or NT servers, use a protocol analyzer attached a server segment and set a pattern match filter to capture packets containing a non-zero NetWare Core Protocol (NCP) completion code and connection status or Server Message Block (SMB) error code and error status. Your analyzer should provide a detailed decode of the result codes so you can determine the nature of the problem such as "invalid password" or "access denied." Interesting error patterns may emerge as you analyze over a period of several hours.

April 1999

Some session layer protocols do not have built-in recovery mechanisms in the event of a lost connection, requiring the user to re-logon to that resource, or even completely re-boot their workstation. With NetWare for example, only the NetWare Client 32 driver has auto- reconnect in the event of a lost connection with a NetWare server. On the other hand, most IP applications that use TCP will recover, provided the end-resource or the path to the end-resource is not down. TCP recovery can be quite long, due to the exponential back-off timing of TCP packet retransmissions.

March 1999

Long term baselining is critical when short term problems arise. Why? Think about the user the says "the network is slow" and you discover that the current network utilization on your backbone is averaging 60%. Would you consider the backbone as part of the problem if you had no historical data? What if the backbone has been averaging 60% during during this time for weeks and no one had been complaining? Chances are, your problem is elsewhere. On the other hand, if the backbone had been averaging, say 20% in the past, then you should definitely give it a look. Having historical data can help you become a more effective troubleshooter.

February 1999

Troubleshooting problems associated with session layer functionality (naming services and establishing connections) can be tricky. When troubleshooting a problem, you may need to have the user disconnect (or even reboot their workstation) and reconnect with the service (such as an FTP, HTTP, or file server) to see how the session was established to begin with. Don't just take a protocol trace "midstream" after a session is already established—go back and collect the whole sample!

January 1999

When troubleshooting an application using a protocol such as HTTP that operates over TCP, you may want to have your protocol analyzer filter more than just the client and server IP addresses. Since HTTP will set up several independent TCP connections for every image file, audio file, Java applet, etc., you may want to capture on a particular client/server IP pair, then set a display filter on a particular TCP port pair such as TCP port 80 (HTTP) and dynamic port 1538. That way, you can more easily follow the TCP sequencing and acknowledgments. This trick also comes in handy when analyzing FTP, to separate commands from data.

December 1998

Analyzing full duplex Ethernet, Token Ring, WAN, and ATM segments, is like requiring two protocol analyzers in one. Make sure that the analyzer has simultaneous capture from both the send and receive sides, full duplex pass through monitoring ports, and a decode display that merges the two captures together into a single view.

Also keep in mind that higher data rates can quickly fill a capture buffer. For instance, a 100 Mbps Ethernet or 155 Mbps ATM can fill a 64 Megabyte buffer in close to five seconds. Gigabit Ethernet? Less than half a second! Look for good filtering capability while capturing as well as frame slicing to utilize more of your buffer.