Ping Question 1

[NicBurns]

Hello all,

Could someone please tell me what a good ping reply and a great ping reply from one workstation to another may be,
I not having issues but I can never find anywhere that say pinging between two workstations on an LAN should be.

Time=x
TTL=y

I get:

Reply from 10.1.1.7: bytes=32 time<10ms TTL=128
Reply from 10.1.1.7: bytes=32 time<10ms TTL=128
Reply from 10.1.1.7: bytes=32 time<10ms TTL=128
Reply from 10.1.1.7: bytes=32 time<10ms TTL=128

Ping statistics for 10.1.1.7:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms

 

[KiscoKid]

Personally I feel most LANs of moderate sizes should aim to achieve less than 10 ms delay end to end. I base this on the fact that LAN bandwidth is typically plentiful and, on well-designed LANs, there should be no bottlenecks.

All this goes out of the window of course if the LAN in question is suffering from detrimental issues such as high collisions/CRC errors or if there is low bandwidth availability/bottlenecks in effect.

 

[robertjo24]

NicBurns,

The replies you received are normal for a ping between two nodes on a LAN.
You can also add some parameters to your ping:
Usage: ping [-t] [-a] [-n count] [-l size] [-f] [-i TTL] [-v TOS]
[-r count] [-s count] [[-j host-list] | [-k host-list]]
[-w timeout] target name

Options:
-t Ping the specified host until stopped.
To see statistics and continue - type Control-Break;
To stop - type Control-C.
-a Resolve addresses to hostnames.
-n count Number of echo requests to send.
-l size Send buffer size.
-f Set Don't Fragment flag in packet.
-i TTL Time To Live.
-v TOS Type Of Service.
-r count Record route for count hops.
-s count Timestamp for count hops.
-j host-list Loose source route along host-list.
-k host-list Strict source route along host-list.
-w timeout Timeout in milliseconds to wait for each reply.

“Ping 10.1.1.7 –t –l 1500” for example will ping the subject node with 1500 byte packets, continuously until you hit “Ctrl C”.

Pinging with larger packets will help diagnose bottlenecks that the standard 32 byte packet will not.

Is your network on a 10/100 hub or is it a switched network?
Is there a central switch/hub that all your devices traverse through or is it distributed?
Is the problem between two work stations or one device to many others?

You can try a freeware program called Ethereal, and sniff the network traffic between the devices having the issue. You can filter by address so you just see the affecting traffic. This may show if there is a large amount of retries, a flood of broadcasts, or errant traffic coming from your workstation that is not supposed to be there.

 

[DaveGoTech]

Perhaps you haven't seen any 'recommended' times listed, because these can vary widely depending on many factors. Typically, you will see anywhere from 1 to 15 ms for a LAN. This is normal. The thing I always look at is packets sent/received/lost. Loses usually indicate a problem somewhere, although only 4 tries during a ping command is not enough sometimes. You can sit there and run ping many times, but an easier way, if you suspect a problem, is install a ping monitor program. You can set this up to run for a specified amount of time, pinging at regular intervals, then come back and view the statistics. We used this technique recently at a large installation where an employee ran the cables (to save money, of course). We found several workstations with 'operating', but bad cables and replaced them. This corrected an ongoing data corruption problem that was occuring intermitantly on the server.

 

[chieftan]

TTL = Time to live.
This is purely dependant on the network you are traversing and the OS running on the far endpoint.

If you have a layer 3 device between the nodes then the TTL will reduce by 1 (layer 3 device is router or firewall).

An example could be as follows:-

node--->switch--->router--->router--->switch--->node

If you were pinging a Windows OS node at the far end then the default TTL is 128 (for Windows based OS systems - You can test this by pinging your own loopback on a Windows system and you should get a TTL of 128). However, in the scenario listed above the following happens:-

Ping uses ICMP, this in turn uses echoing as it's response back. So, the ping goes through the switch (only layer 2 so does not reduce the TTL by 1) then it goes through the first router (layer 3 so reduces TTL by 1) then it traverses the second router (also layer 3 so reduces the TTL by 1) and then goes through the far end switch and to the end node which is running windows, so you will get a TTL of 126.
The main reason for the TTL is for loop avoidance within a WAN environment. When the TTL reaches 0 the packet is dropped.

Default TTLs that I know of:-

Windows based OS - 128
Unix based (linux) systems - 255
Firewalls - 55

This is also a way that a hacker can work out what type of OS the system has running...... Not good when known.

 

[cyberspace]

that's an excellent post chieftan, I did not know that! I'm going to do some experimenting myself now lol.

On the hacker subject - if a packet passes through many firewalls/routers, how can he know for sure of the OS? Would this be a case of tracing the route to the desination node/network, and subtrating this value from the common figures?

'When all else fails.......read the manual'

 

[cyberspace]

I have just pinged our one and only linux based system, it had a TTL of 64.

'When all else fails.......read the manual'

 

[chieftan]

That is exactly what a hacker would do.

tracert (on windows) to the destination will show every hop between the end points. This figure, taken away from either a TTL of 128, 255 or 55 should equal the ping'ed TTL.

If you want to see what your default TTL is just ping your loopback address of 127.0.0.1 or your IP address, then you can try different ones on the internet.

 

[cyberspace]

thanks, thats my new bit of knowledge for today

'When all else fails.......read the manual'

 

[chieftan]

255 must be Unix based then.....

I have tested here and all of our Unix systems are giving a TTL of 55.

If you ping a known firewall (typically Nokia) it should give a TTL of 255.

Please accept my apologies. I got it the wrong way around.