Think of a regular morning at work. You grab your coffee, unlock your machine and your teammate says, “Hey, can you check if that server is reachable?” Without even thinking, you open Command Prompt and type one simple word: ping. In the world of network diagnostics, there’s one tool that quietly steps forward, ready to prove its worth – ping. It’s not flashy, it doesn’t carry flashy graphics or fancy dashboards. But like a silent protagonist in a suspense thriller, it gets the job done, every single time.
You boot up your machine, open a terminal, and type a single word ping. What follows isn’t just a command. It’s the beginning of a story – packets leave your system, traverse switches, routers, and firewalls, travel to distant servers, and return with tales of success or failures.
In this blog, let’s walk through this story as fellow diagnosticians, appreciating not just the basics of ping, but the full arsenal of attributes it offers us. And more importantly how and when to use each of them in real‑world situations.
1) The Journey Begins – Continuous Monitoring with -t
Imagine you’re troubleshooting an intermittent drop to a server. It works… and then suddenly stops, only to start working again minutes later. Instead of manually pressing the up‑arrow and hitting enter a hundred times, you use:
ping -t <target> OR ping <target> -t
This tells ping to keep sending packets until you stop it. It’s like putting a stethoscope on the network and listening to its heartbeat. You leave it running in one terminal while observing the pattern of responses in real time. When packets start timing out, you know the exact moment the problem recurs; perfect for correlating with firewall logs or switch events.
C:\Users\jeeveshtechtips>ping 10.11.12.13 -t
Pinging 10.11.12.13 with 32 bytes of data:
Reply from 10.11.12.13: bytes=32 time=129ms TTL=63
Reply from 10.11.12.13: bytes=32 time=18ms TTL=63
Reply from 10.11.12.13: bytes=32 time=18ms TTL=63
Reply from 10.11.12.13: bytes=32 time=18ms TTL=63
Reply from 10.11.12.13: bytes=32 time=22ms TTL=63
Reply from 10.11.12.13: bytes=32 time=16ms TTL=63
Reply from 10.11.12.13: bytes=32 time=18ms TTL=63
Reply from 10.11.12.13: bytes=32 time=18ms TTL=63
Reply from 10.11.12.13: bytes=32 time=18ms TTL=63
Reply from 10.11.12.13: bytes=32 time=19ms TTL=63
Reply from 10.11.12.13: bytes=32 time=19ms TTL=63
.... (it continus till Ctrl+C)
2) Controlling the Number of Requests with n
Sometimes you just want a quick sample instead of an endless stream of packets. For example, when checking if a server is reachable before making a configuration change. Using
ping -n 5 <target> OR ping <target> -n 5
will send exactly five echo requests and stop. It gives you a clean snapshot of latency and packet loss without flooding the screen.
C:\Users\jeeveshtechtips>ping -n 5 10.11.12.13
Pinging 10.11.12.13 with 32 bytes of data:
Reply from 10.11.12.13: bytes=32 time=81ms TTL=63
Reply from 10.11.12.13: bytes=32 time=17ms TTL=63
Reply from 10.11.12.13: bytes=32 time=20ms TTL=63
Reply from 10.11.12.13: bytes=32 time=19ms TTL=63
Reply from 10.11.12.13: bytes=32 time=21ms TTL=63
Ping statistics for 10.11.12.13:
Packets: Sent = 5, Received = 5, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 17ms, Maximum = 81ms, Average = 31ms
3) Testing MTU Issues with l
Imagine a user complains that small web pages open fine but large file transfers keep failing. This often points to MTU or fragmentation problems. You can simulate larger packets like this:
ping -l 1472 <target>
If the packets fail, you start reducing the size until the responses succeed. This helps identify the maximum transmission size that works across the path.
4) Forcing No Fragmentation with f
To take MTU testing further, combine it with the don’t fragment flag:
ping -l 1472 -f <target>
This forces the packet to be sent without fragmentation. If the reply never arrives and you receive a fragmentation-needed message, it confirms that something in the path cannot handle that packet size.
For Example (3 & 4):
Why We Combine -l with -f (Don’t Fragment)
Think of a normal Ethernet network with an MTU of 1500 bytes.
If you send a larger packet, for example:
ping -l 2000 10.11.12.13
Pinging 10.11.12.13 with 2000 bytes of data:
Reply from 10.11.12.13: bytes=2000 time=74ms TTL=63
Reply from 10.11.12.13: bytes=2000 time=16ms TTL=63
Reply from 10.11.12.13: bytes=2000 time=16ms TTL=63
Reply from 10.11.12.13: bytes=2000 time=20ms TTL=63
Ping statistics for 10.11.12.13:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 16ms, Maximum = 74ms, Average = 31ms
…the packet becomes 2000 + 28 = 2028 bytes, which is bigger than the MTU.
Normally, the router will simply fragment the packet into smaller pieces so it can still reach the destination.
That means the test will succeed, and you won’t notice anything.
But if you add the -f flag:
ping -l 2000 -f 10.11.12.13
Pinging 10.11.12.13 with 2000 bytes of data:
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Ping statistics for 10.11.12.13:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
you are telling the network:
“Do not fragment this packet. Either deliver it in one piece, or drop it.”
So when the packet hits the first router with a 1500-byte MTU, it can’t fragment it, so it drops the packet and returns:
Packet needs to be fragmented but DF set.
This scenario is very real in some networks — for example:
- VPNs or tunnels that enforce lower MTU limits (like 1400–1460)
- Mobile ISPs with encapsulation overheads
- Cloud firewalls that discard oversized packets instead of fragmenting
In these situations, the DF bit can become a silent killer — allowing small traffic like web browsing to work, while silently dropping large uploads or video streams.
5) Controlling Time To Live with i
TTL is the number of hops a packet is allowed to travel. You can use it to find out roughly how many hops away a device is:
ping -i 5 <target>
If the ping fails, the device is more than five hops away, giving you a quick idea of its proximity.
Fun fact: different operating systems use different default TTL values (Windows typically starts with 128, Linux uses 64 and many network devices use 255). This is why sometimes you can estimate the originating device type based on the TTL value in the reply.
6) Recording the Route with r
If you need to confirm the exact path a packet is taking, record route lets you capture up to nine hops:
ping -r 9 <target>
This embeds the path in the ICMP option fields and returns it in the reply, allowing you to see each hop directly in the command output.
C:\Users\jeeveshtechtips>ping -r 9 10.11.12.13
Pinging 10.11.12.13 with 32 bytes of data:
Reply from 10.11.12.13: bytes=32 time=16ms TTL=63
Route: 10.11.12.114 ->
10.11.12.13 ->
10.11.12.13 ->
100.67.136.93
Reply from 10.11.12.13: bytes=32 time=17ms TTL=63
Route: 10.11.12.114 ->
10.11.12.13 ->
10.11.12.13 ->
100.67.136.93
Reply from 10.11.12.13: bytes=32 time=17ms TTL=63
Route: 10.11.12.114 ->
10.11.12.13 ->
10.11.12.13 ->
100.67.136.93
Reply from 10.11.12.13: bytes=32 time=15ms TTL=63
Route: 10.11.12.114 ->
10.11.12.13 ->
10.11.12.13 ->
100.67.136.93
Ping statistics for 10.11.12.13:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 15ms, Maximum = 17ms, Average = 16ms
Note: this works only if the devices along the path allow ICMP record‑route options. Many modern routers drop or ignore these options for security reasons, so it may work on internal/private networks but not on public or hardened paths.
7) Timestamping Each Hop with s
To measure how long each hop takes, use:
ping -s 4 <target>
This records the time at which the packet reaches each router in the path. It’s useful when trying to identify which hop is introducing delay.
C:\Users\jeeveshtechtips>ping -s 4 10.11.12.13
Pinging 10.11.12.13 with 32 bytes of data:
Reply from 10.11.12.13: bytes=32 time=16ms TTL=63
Timestamp: 100.67.136.93 : 37731367 ->
10.11.12.13 : 37731336 ->
10.11.12.13 : 37731336 ->
10.11.12.114 : 37731367
Reply from 10.11.12.13: bytes=32 time=17ms TTL=63
Timestamp: 100.67.136.93 : 37732394 ->
10.11.12.13 : 37732363 ->
10.11.12.13 : 37732363 ->
10.11.12.114 : 37732395
Reply from 10.11.12.13: bytes=32 time=19ms TTL=63
Timestamp: 100.67.136.93 : 37733422 ->
10.11.12.13 : 37733391 ->
10.11.12.13 : 37733391 ->
10.11.12.114 : 37733422
Reply from 10.11.12.13: bytes=32 time=17ms TTL=63
Timestamp: 100.67.136.93 : 37734452 ->
10.11.12.13 : 37734421 ->
10.11.12.13 : 37734421 ->
10.11.12.114 : 37734453
Ping statistics for 10.11.12.13:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 16ms, Maximum = 19ms, Average = 17ms
Note: timestamping relies on routers supporting the ICMP timestamp option. Many public or hardened routers ignore these requests, so this option is more effective in internal networks where devices allow it.
8) Using a Specific Source IP with S
When your machine has multiple IP addresses, you can choose which one to send the ping from:
ping -S <source-ip> <target>
C:\Users\jeeveshtechtips>ping -S 10.20.30.6 10.10.0.21
Pinging 10.10.0.21 from 10.20.30.6 with 32 bytes of data:
Reply from 10.10.0.21: bytes=32 time=88ms TTL=63
Reply from 10.10.0.21: bytes=32 time=44ms TTL=63
Reply from 10.10.0.21: bytes=32 time=42ms TTL=63
Reply from 10.10.0.21: bytes=32 time=42ms TTL=63
Ping statistics for 10.10.0.21:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 42ms, Maximum = 88ms, Average = 54ms
This helps verify connectivity from a specific interface or subnet.
9) Force IPv4 or IPv6 with 4 and 6
Depending on your network, DNS might return both A and AAAA records. To force a particular protocol:
ping -4 <hostname>
C:\Users\jeeveshtechtips>ping -4 google.com
Pinging google.com [142.251.43.110] with 32 bytes of data:
Reply from 142.251.43.110: bytes=32 time=5ms TTL=119
Reply from 142.251.43.110: bytes=32 time=7ms TTL=119
Reply from 142.251.43.110: bytes=32 time=7ms TTL=119
Reply from 142.251.43.110: bytes=32 time=8ms TTL=119
Ping statistics for 142.251.43.110:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 5ms, Maximum = 8ms, Average = 6ms
ping -6 <hostname>
C:\Users\jeeveshtechtips>ping -6 google.com
Pinging google.com [2404:6800:4002:81d::200e] with 32 bytes of data:
Reply from 2404:6800:4002:81d::200e: time=8ms
Reply from 2404:6800:4002:81d::200e: time=7ms
Reply from 2404:6800:4002:81d::200e: time=8ms
Reply from 2404:6800:4002:81d::200e: time=7ms
Ping statistics for 2404:6800:4002:81d::200e:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 7ms, Maximum = 8ms, Average = 7ms
This is especially useful in dual-stack environments when you want to test only one protocol.
10) Measuring Timeout with w
There are situations where the default timeout is too short, especially over slow links or during temporary network congestion. You can increase the wait time like this:
ping -w 5000 <target>
This allows each echo request to wait up to five seconds for a reply, giving slower paths a chance to respond.
Wrap Up!
Every option of the ping command tells a different story. Sometimes it’s a quick check. Other times it’s a deep dive into path characteristics and if this post did one thing, I hope it reminded you that even the simplest tools in networking have depth; we just need to look a little closer.
Next time someone says “it’s just ping”, smile softly – because you know it’s much more than that.
In case I missed any ping attribute or you use a different combination in your day to day work, feel free to share it in the comments – I’d love to learn from your experiences too.
Jeevesh Tech Tips 
Leave a comment