Using Extended Ping For Checking WAN Links
Bill Alderson, Technology Consulting Officer, NetQoS, Inc.

This is not something we would typically expect to see on a network. Each time a certain packet is sent, it results in a CRC error being generated. In looking at the packet, we noticed that the data portion was comprised of almost entirely zeros. This should not be a problem for the WAN link. On T-1 links such as the one being used in this case, the CSU/DSU will replace multiple zeros in a row with a code. The purpose of this is to keep transitions in the signal so that the devices on each end of the circuit do not lose synchronization with each other. In the case of this WAN link, B8ZS (Bipolar 8-bit Zero Substitution) was the method being used to ensure that every time there was a byte of all zeros, it was replaced with the appropriate code.

In resolving this problem, we found a command on the Cisco router that allowed us to determine what range of packets were having this problem. The following contains the parameters used with the extended ping command to conduct the test:

router#ping

Protocol [ip]: ip

Target IP address: IP Address of router on other end of WAN link

Repeat count [5]: 1

Datagram size [100]:

Timeout in seconds [2]: 1

Extended commands [n]: y

Source address or interface:

Type of service [0]: 0

Set DF bit in IP header? [no]: no

Validate reply data? [no]: no

Data pattern [0xABCD]: 0x0000

Loose, Strict, Record, Timestamp, Verbose[none]: none

Sweep range of sizes [n]: y

Sweep min size [36]: 36

Sweep max size [18024]: 1460

Sweep interval [1]: 1

Type escape sequence to abort.

Sending 1425, [36..1460]-byte ICMP Echos to 207.141.76.86, timeout is 1 second

Packet has data pattern 0x0000

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!..............................

....................................................

....................................................

........................!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!

Success rate is 100 percent (1425/1425), round-trip min/avg/max = 1/3/12 ms

router#

For this test the most important parameter is the Data Pattern. By default a pattern of Hex ABCD is used. In our case we changed the Data Pattern to Hex 0000. Another important parameter to consider is the Repeat Count field. We changed the default from 5 to a value of 1. This indicates how many times the ping will be performed for each size. Using the default value would have resulted in over 7,000 pings being sent! The results are shown as either an exclamation point or a period, periods indicating that the ping was not successful.

The multiple missed pings indicated that we were having a problem sending packets containing all zeros for a range of frame sizes. In this case, we first did what we could do ourselves and that was to replace the patch cable between the jack installed by the telco and the CSU/DSU. We re-ran the ping test and found that all of the ping packets made it through successfully. The application was then tested and it also worked.

Since identifying this problem using the extended ping command, I have found at least two other cases where the command has helped pinpoint the problem to the WAN link itself. In both of these cases, we had to work through the telco to get the local loop repaired. It also gave us a tool to verify that the telco had actually fixed the problem.

While a protocol analyzer is a very useful tool in troubleshooting network problems, other tools play an important role in isolating and resolving problems. In this case we were able to use a command that comes as a part of every Cisco router to paint a clear picture of those packet sizes that were experiencing this problem. Without this tool, we would have had to create a packet of each different size and transmit it across the WAN link. Successful troubleshooting is often a result of a thorough understanding of the tools you have in your network analysis toolbox.