Wouldn't it be great if everyone that supported messaging didn't have to worry about the underlying infrastructure?
"If you can't PING it, it isn't my problem."
The PING utility sends out a communication packet. The communication packet is called an Internet Control Message Protocol (ICMP) Echo Request packet (echo request being the most notable portion of the name). These communication packets are special messages that are used to send network information between two devices, usually a workstation and a service provider like a server. When a machine receives an echo request, it responds with an echo reply. When the PING program gets an echo reply back from the remote device it writes/displays the response, which then provides the originator some information that can be used to troubleshoot.
Okay was that too complex? Think of it this way. When you call someone on the phone, you punch in the digits and make a phone ring on the other end. This is similar to the echo request. Then someone picks up the phone on the other end and says "hello", which is the echo reply. This whole process seems simple enough, but there are some important additions that the PING utility provides on top of this. First, is the measure of line quality on which the conversation is taking place. That is the portion that is displayed on the screen and is often ignored.
Okay, let's be practical for a minute and try a ping test. In order to PING you need to bring up a DOS session or command prompt. From the command prompt, type ping and the destination address (for example; ping 10.0.9.200 or ping an associated DNS name).
A PING looks like this:
C:>
C:> Ping MAIL1
Pinging mailserver1.mydomain.com [10.0.9.200] with 32 bytes of data:
Reply from 10.0.9.200: bytes=32 time<10ms TTL=127
Reply from 10.0.9.200: bytes=32 time<10ms TTL=127
Reply from 10.0.9.200: bytes=32 time<10ms TTL=127
Reply from 10.0.9.200: bytes=32 time<10ms TTL=127
Ping statistics for 10.0.9.200:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms
Okay, now let's dig into what we've seen in this conversation. If you used PING against a DNS name, you'll see that you get the IP Address resolved, which is one way you can rule out DNS problems. What you may not be aware of is that there is a lot of detail here that can be used for troubleshooting. PING provides the following information:
- The first thing PING provides is the IP Address of the remote device that has responded to the request. This can be verified for troubleshooting; if the wrong device responds, this can be identified here.
- The second thing that PING provides is the "Time To Live" number, which is usually ignored as "trivial information". What you should understand is the detail behind this number. For every IP packet on a network that gets sent a specific time to live is attached in the header. This time to live (TTL) is set to a specific number (in this case, ping packets get a TTL of 128).
So who cares right? Well, let me explain what happens to the TTL and how it can help you.
As the PING communication packet travels across the network, whenever the packet passes through a router or other network device, it decreases by one. (NOTE: it is possible, in the most severe cases, for the TTL to drop to a value of zero and then the packet is discarded by the router). In most cases, you can see that the TTL information can be used to determine approximately how many router hops the packet has gone through. (NOTE: TTL does not count the same device twice in standard traffic flow. This is not the case with routing loops). So the example I've provided shows that this packet only went through one device on the network before getting to the destination. - The third thing the PING utility provides is the number of milliseconds it takes to get a reply. What does this mean to us as average people? Well, what this actually represents is an indication of the round-trip time to get a packet to/from the remote device. Again, the response is shown/written in milliseconds. As a rule of thumb, for most networks, it's best if round-trip times are under 200 milliseconds. Now if you're seeing the number change, and the variance in the round-trip times is seen to be all over the board (for example if your response times show something like 128ms, 10ms, 59ms), you are going to see poor performance talking to the host. This would indicate some type of communication problem). So, if your users are saying GroupWise performance is bad and they are getting bumped off, this can be a good way to identify something outside of GroupWise and it shouldn't be ignored. (See "variations in the PING utility" for more information on gathering response times over and extended period).
- The last thing the PING utility provides is a summary of the statistics. This information can also be used to identify network issues. A standard rule of thumb here is that if the summary reports a loss over 1%, this is indicative of a communication problem ONLY when there is no "Response timed out" reply written/displayed.
Other echo replies
- Response timed out. This indicates that a device has not responded within the specified number of milliseconds. A standard echo reply is generated by the initiating workstation; "Response timed out" indicating that the device is not functioning or not reachable by the initiator.
NOTE: Many times when using PING to communicate to devices outside of your network via DNS the first response will timeout. This is because the PING utility looks at the local network's DNS server first. If the local DNS server does not have the information/address it sends a response back based on the fact it received a request but the standard response is the "timed out" as it is not the destination. The DNS server will then go out to the next designated site (such as DNS hosted by your corporate ISP) to gather the information/address, once the DNS server has the information, it hands the proper address back the initiator and the reply will begin to display with statistical information. This entire process takes only a few milliseconds when communication is functioning properly but you do see it.
When and where to use the PING utility:
Now here's something that is important to understand and a lot of support people overlook this. Let's say a user calls into your support desk and you take the call–
The end user says they are having difficulty accessing a device/service/application on the network. You can run through the following mental questions (1.) Can I ping the device? And (2.) Can the end user PING the device?
NOTE: A PING test is NOT very useful if a support area is the only one who initiates the PING, this is mainly because all of the information that is written is representative of the support area's communication pathway to the device, which does not provide any information about the end user's physical network pathway (who may not be able to access the device).
Variations in the PING utility:
Ping address/name - T
This will start a PING session that will not stop until it is interrupted by the initiator using the CNTRL + C combination. This is often useful when monitoring a device for a long period of time to gather statistics (TTL) or when watching to see if a server restart has completed properly. When a server is restarted, the PING will show "request timed out" when the server is completely down, once the server begins to load up again, the responses will re-initiate.
Ping - A ipaddress
By typing the "dash A" before the IP address of the device it will write/display the DNS name that the address responds to. Many times this will respond with the server name, or other DNS records that are designated for the server or service.
CNTRL + C
By hitting these two keys during a PING session, the PING utility will stop and return a command prompt.
"Loopback"
By typing the below ping address, this will test the workstation or originating device's NIC. If this fails, it would indicate an issue with the initiation device, possibly related to the IP stack on the initiating device being improperly installed or potentially mis-configured.
Ping 127.0.0.1
Gathering the ping response
The entire ping process can be captured to a text file that can then be transferred to whatever other system (email, tracking system, etc.). In order to do this, the following format is required:
PING IP_Address space > space C:\pingtest.txt
(For example the following statement would create a text file on the root of the c drive called "loopback.txt" ping 127.0.0.1 > C:\loopback.txt)
NOTE: Any file already located in the same directory with the same name will automatically be overwritten without prompting the PING initiator. It is also important to note that when this process is used, the screen will not have any responses written to it, all data is written to the file. When the command prompt ( C:> ) reappears, this indicates the data has finished writing to the text file that was specified.
A full example of this process is shown below:
C:>
C:>ping gcs1 > C:\pingtest.txt
C:>
Pinging with packets larger than 32 bytes
At times it's necessary to test communication with more data than the standard #@ bytes that PING uses. In order to do this, you can add a "dash L" and then the size you require after the ping command. For example; ping 127.0.0.1 -L 1024
Note the response below and the change in byte size recorded for this conversation.
Pinging 127.0.0.1 with 1024 bytes of data:
Reply from 127.0.0.1: bytes=1024 time<1ms TTL=128
Reply from 127.0.0.1: bytes=1024 time<1ms TTL=128
Reply from 127.0.0.1: bytes=1024 time<1ms TTL=128
Reply from 127.0.0.1: bytes=1024 time<1ms TTL=128
Ping statistics for 127.0.0.1:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms
More Advanced Ping Options:
I'll briefly cover some additional options you may wish to experiment with, as there are so many, I don't think you want a detailed explanation of each, but I'd like to give you some ideas on what else can be done with the PING utility.
"Dash R"
By adding a "dash R" and a number between 1 and 9, the PING will record the route between the initiator and the address, identifying all hops by IP address up to the number that was specified.
"Dash N"
By adding the "dash N" and any number, you will tell the PING utility how many echo requests to initiate. Meaning if you add a "- N 8 ", there will be 8 echo requests and that means there should be 8 echo replies written to the screen.
"Dash F"
This option tells the Ping Utility not to fragment the packet. That's something you should use with caution. My theory: "Don't play if you don't want to pay."
For those of you who are now completely enthralled with this utility (like me), you can also find other options if you type ping -h at the command prompt. You'll get a brief description, and most likely have to experiment to get the options working. My suggestion - don't do this on a production network– it's always safest to experiment in a lab.
0 comments:
Post a Comment