Ping – ICMP, TTL, Output Interpretation, and Troubleshooting

1. What Is Ping?

Ping is the most fundamental network diagnostic tool in existence. It tests whether a specific IP address is reachable from the local host and measures the round-trip time (RTT) — how long it takes for a probe packet to travel to the destination and for the reply to return. Ping is available on virtually every operating system and on every Cisco IOS device, making it the universal first step in any network troubleshooting workflow.

Ping operates at Layer 3 (Network layer) of the OSI model using the ICMP (Internet Control Message Protocol). It sends ICMP Echo Request messages and expects ICMP Echo Reply responses in return. Because ping works at Layer 3, a successful ping confirms that IP routing between source and destination is functional — but it does not confirm that higher-layer services (TCP ports, applications) are working.

  Source (PC)                                     Destination (8.8.8.8)
  ──────────                                      ────────────────────
  Send ICMP Echo Request (Type 8, Code 0)  ──→
                                           ←──  ICMP Echo Reply (Type 5, Code 0)
  RTT = time from sending request to receiving reply

2. ICMP — The Protocol Behind Ping

ICMP (Internet Control Message Protocol, RFC 792) is a Layer 3 protocol used for diagnostic and error-reporting purposes. It is encapsulated directly in an IP packet (protocol number 1) and does not use TCP or UDP port numbers. Ping uses two specific ICMP message types:

ICMP Type	Code	Name	Direction	Sent By
8	0	Echo Request	Source → Destination	The host running ping
0	0	Echo Reply	Destination → Source	The destination host (if reachable and not blocked)

Other ICMP messages you will encounter during troubleshooting:

ICMP Type	Name	What Triggers It	What Ping Shows
3	Destination Unreachable	Router or destination cannot deliver the packet — no route, port closed, fragmentation needed but DF set, host unreachable	"Destination host unreachable" or "Destination net unreachable"
11	Time Exceeded	Packet TTL reached zero at a router — the router drops the packet and sends this back to inform the source	No specific ping message — ping shows timeout; traceroute uses this to map hops

Important: ICMP is not TCP or UDP. Firewalls that filter based on protocol numbers can block ICMP (protocol 1) without blocking any TCP/UDP traffic. This is why a ping failure does not necessarily mean the host is offline — it may mean ICMP is blocked at a firewall or ACL.

See: Firewalls | ACLs

3. TTL — Time to Live

The TTL (Time to Live) field is an 8-bit value in the IP header of every packet. It is decremented by 1 at every router hop. When TTL reaches 0, the router discards the packet and sends an ICMP Type 11 (Time Exceeded) message back to the source. TTL prevents packets from circulating forever in routing loops.

  PC (TTL=128)  →  Router 1  →  Router 2  →  Router 3  →  Server
  Sends:           TTL=128       TTL=127       TTL=126       Receives TTL=125
  (127 in transit means 3 hops from PC to server)

  Default starting TTL values by OS:
  Windows   → 128
  Linux     → 64
  Cisco IOS → 255
  macOS     → 64

  From the TTL in the reply, you can estimate distance:
  Reply TTL=117  (from a Windows target):  128 - 117 = 11 hops away
  Reply TTL=54   (from a Linux target):     64 - 54  = 10 hops away

Reply TTL Value	Approximate Meaning	Notes
Close to 128	Windows host, few hops away	128 is the default Windows starting TTL
Close to 64	Linux or macOS host, few hops away	64 is the default Linux/macOS starting TTL
Close to 255	Cisco IOS device, few hops away	255 is the default Cisco IOS starting TTL
Very low (1–5)	Many hops from source, or TTL deliberately set low	Could indicate a routing loop if TTL keeps decreasing across repeated pings to same target

4. Ping Syntax — Windows, Linux/macOS, and Cisco IOS

Platform	Basic Command	Default Behaviour	Key Options
Windows	`ping 8.8.8.8`	4 packets, 32-byte payload, then stops	`-n <count>` number of packets `-t` continuous until Ctrl+C `-l <size>` packet payload size (bytes) `-a` resolve IP to hostname `-f` set Don't Fragment (DF) bit `-i <TTL>` set TTL value `-S <srcIP>` specify source IP
Linux / macOS	`ping 8.8.8.8`	Continuous until Ctrl+C; 64-byte default packet	`-c <count>` stop after N packets `-s <size>` payload size in bytes `-i <interval>` seconds between packets `-W <timeout>` wait seconds for reply `-M do` set DF bit (MTU testing) `-f` flood ping (root only) `-I <interface>` specify source interface
Cisco IOS	`ping 8.8.8.8`	5 packets (100-byte), timeout 2 seconds, stops	Standard ping as above; extended ping available in privileged EXEC mode (see Section 5)

Quick Examples

  ! Windows — send 10 packets to 8.8.8.8:
  C:\> ping -n 10 8.8.8.8

  ! Windows — continuous ping (monitoring a link):
  C:\> ping -t 192.168.1.1
  (stop with Ctrl+C, then Ctrl+Break to see statistics)

  ! Linux — 5 packets with 1400-byte payload (MTU test):
  $ ping -c 5 -s 1400 8.8.8.8

  ! Linux — ping with DF bit set (finds path MTU):
  $ ping -c 3 -M do -s 1472 8.8.8.8

  ! Cisco IOS — standard 5-packet ping:
  Router# ping 192.168.1.10

5. Cisco IOS Extended Ping

Cisco IOS offers an extended ping mode that provides additional control not available in the basic ping command. It is accessed from privileged EXEC mode by typing ping followed by Enter without a destination — IOS then prompts for each parameter interactively.

The most important use of extended ping is specifying a source IP address. By default, Cisco IOS uses the IP address of the outgoing interface as the source — which may not test what you actually need. Extended ping lets you ping from a specific interface or IP, which is essential for verifying that a particular path or interface is reachable end-to-end.

  Router# ping
  Protocol [ip]:                    ← press Enter (default IP)
  Target IP address: 10.0.0.2       ← destination
  Repeat count [5]: 10              ← send 10 packets
  Datagram size [100]: 1500         ← 1500-byte packets (MTU test)
  Timeout in seconds [2]: 5         ← wait 5s per reply
  Extended commands [n]: y          ← say yes for source IP option
  Source address or interface: 192.168.1.1   ← ping FROM this IP
  Type of service [0]:              ← press Enter
  Set DF bit in IP header? [no]: yes         ← test for fragmentation
  ...
  Router# ping 10.0.0.2 source GigabitEthernet0/0
  ! Shortcut — single-line version using source keyword

Why Source Ping Matters

  Scenario: R1 has two interfaces — Gi0/0 (10.0.0.1) and Gi0/1 (192.168.1.1)
  R1 needs to verify that the remote host (10.0.0.2) can be reached
  specifically via the 192.168.1.0 path for a failover test.

  Without source ping: ping 10.0.0.2
  → IOS automatically uses Gi0/0 (10.0.0.1) as source
  → This tests the primary path, not the failover path

  With source ping: ping 10.0.0.2 source GigabitEthernet0/1
  → Pings from 192.168.1.1
  → Tests the failover path end-to-end ✓
  → Verifies the remote router has a return route to 192.168.1.0

6. Reading Ping Output — Full Annotation

Linux Ping Output

  $ ping -c 4 8.8.8.8
  PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
  64 bytes from 8.8.8.8: icmp_seq=1 ttl=117 time=18.2 ms
  64 bytes from 8.8.8.8: icmp_seq=2 ttl=117 time=17.8 ms
  64 bytes from 8.8.8.8: icmp_seq=3 ttl=117 time=18.5 ms
  64 bytes from 8.8.8.8: icmp_seq=4 ttl=117 time=18.1 ms

  --- 8.8.8.8 ping statistics ---
  4 packets transmitted, 4 received, 0% packet loss, time 3004ms
  rtt min/avg/max/mdev = 17.8/18.2/18.5/0.3 ms

  Field explanations:
  64 bytes          = total received packet size (56-byte payload + 8-byte ICMP header)
  from 8.8.8.8      = the IP address that sent the reply
  icmp_seq=1        = sequence number; gaps indicate packet loss (e.g., seq=3 missing)
  ttl=117           = TTL remaining in the reply; 128-117=11 hops (Windows default 128)
  time=18.2 ms      = RTT — how long from sending request to receiving reply

  Summary statistics:
  0% packet loss    = all 4 replies received (healthy)
  rtt min/avg/max   = minimum / average / maximum RTT across all replies
  mdev              = mean deviation (jitter) — low = consistent, high = variable

Windows Ping Output

  C:\> ping 8.8.8.8

  Pinging 8.8.8.8 with 32 bytes of data:
  Reply from 8.8.8.8: bytes=32 time=18ms TTL=117
  Reply from 8.8.8.8: bytes=32 time=17ms TTL=117
  Reply from 8.8.8.8: bytes=32 time=19ms TTL=117
  Reply from 8.8.8.8: bytes=32 time=18ms TTL=117

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

Cisco IOS Ping Output

  Router# ping 10.0.0.2

  Type escape sequence to abort.
  Sending 5, 100-byte ICMP Echos to 10.0.0.2, timeout is 2 seconds:
  !!!!!
  Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms

  Symbol legend:
  !  = Echo reply received (success)
  .  = Timeout — no reply within 2 seconds
  U  = Destination unreachable (ICMP Type 3 received)
  N  = Network unreachable
  P  = Protocol unreachable
  Q  = Source quench (congestion notification — obsolete)
  M  = Could not fragment (DF bit set, fragmentation needed)
  ?  = Unknown packet type

  Common patterns:
  !!!!!    = 100% success
  .....    = 0% success — no route, firewall, or host down
  !.!.!    = 60% success — intermittent loss
  U.U.U    = "Destination unreachable" from an intermediate router

7. All Ping Output Types — What Each Means

Output / Message	Platform	What It Means	Common Causes
Reply from X / !	All	ICMP Echo Reply received — destination is reachable, IP routing is working end-to-end	Normal success
Request timed out / .	All	No reply received within the timeout period — the request may have been sent but no reply came back	Firewall blocking ICMP; host offline; no return route; ACL dropping ICMP replies on return path
Destination host unreachable / U	All	A router (not the destination) sent an ICMP Type 3 "Destination Unreachable" — it cannot forward the packet toward the destination	No route to destination in the router's routing table; next-hop unreachable; wrong default gateway on source host
Destination net unreachable	Windows / Linux	The source host's own routing table has no route to the destination network — the packet never even leaves the source	Missing default gateway; incorrect subnet configuration; routing table not populated
TTL expired in transit	Windows	The packet's TTL reached zero at a router — the router discarded it and replied with ICMP Type 11	Routing loop causing packet to bounce between routers; TTL set too low; destination is more hops away than TTL allows
Partial loss (!.!.!)	Cisco IOS	Some packets succeed and some time out — intermittent reachability	Network congestion; flapping link; faulty cable or hardware; overloaded device dropping ICMP
M (could not fragment)	Cisco IOS	The DF (Don't Fragment) bit was set in the packet and a router needed to fragment it but could not — ICMP Type 3 Code 4 returned	MTU mismatch on the path; jumbo frame path issue; VPN encapsulation overhead reducing effective MTU

8. Using Ping for MTU Testing

Ping with the Don't Fragment (DF) bit set and increasing payload sizes is the standard technique for discovering the Path MTU (Maximum Transmission Unit) — the largest packet size that can traverse the entire path without fragmentation. This is critical for diagnosing VPN tunnels and GRE tunnels where encapsulation overhead reduces the effective MTU.

  Path MTU Discovery — binary search method:

  Goal: find largest packet that traverses 10.0.0.2 without fragmentation.
  Standard Ethernet MTU = 1500 bytes.
  IP header = 20 bytes, ICMP header = 8 bytes.
  Maximum ICMP payload = 1500 - 20 - 8 = 1472 bytes.

  Test 1: ping with 1472-byte payload, DF bit set:
  Linux:  ping -c 3 -M do -s 1472 10.0.0.2
  IOS:    Router# ping (extended, datagram size 1500, DF bit yes)

  Result: success → path MTU is at least 1500 bytes ✓

  Test 2: try 1473-byte payload:
  Result: M (could not fragment) or "Frag needed" → MTU is 1500 exactly

  If a VPN tunnel is in the path:
  GRE tunnel overhead = 24 bytes extra
  Effective MTU through tunnel = 1500 - 24 = 1476 bytes
  Maximum payload test size = 1476 - 20 - 8 = 1448 bytes

  Fix: set ip mtu 1476 on the tunnel interface to prevent fragmentation

9. Limitations of Ping

Limitation	Detail	What to Do Instead
ICMP may be blocked	Firewalls, security appliances, and host-based firewalls frequently block ICMP (protocol 1). A failed ping does not prove the host is offline — it may simply mean ICMP is filtered.	Try traceroute (uses UDP or ICMP); use telnet or curl to test a specific TCP port; check ACLs on devices in the path
Ping succeeds but application fails	A successful ping confirms Layer 3 IP reachability only. The application service (HTTP on port 80, SSH on port 22) may still be blocked by a firewall, not running, or misconfigured.	Use `telnet <IP> <port>` or `ncat` to test specific TCP ports; use application-level tools (curl, wget, ssh)
Ping fails but application works	Some devices respond to application traffic but silently drop ICMP. Common on Windows servers with host firewall enabled (blocks ping by default), cloud instances, and load balancers.	Test using the actual application protocol; do not rely on ping as the sole connectivity check
Only tests Layer 3	Ping confirms IP routing — it says nothing about Layer 1 (physical), Layer 2 (frame switching), or Layer 4–7 (transport and application). A switch with a bad STP port state, for example, may allow ping while blocking some application frames.	Combine with traceroute, show interfaces, ARP, and show ip route
RTT not always meaningful	Some devices deprioritise ICMP processing — the reply RTT may be much higher than the actual data-plane latency, giving a false impression of slow links.	Use traceroute with UDP for more realistic path latency; use proper monitoring tools for SLA measurement

10. Step-by-Step Troubleshooting with Ping

The inside-out methodology is the standard approach for using ping to isolate where connectivity breaks down. Start at the local host and work progressively outward toward the destination. Each step either confirms that layer is working or isolates the fault to a specific segment.

  ┌──────────────────────────────────────────────────────────────────┐
  │           PING TROUBLESHOOTING METHODOLOGY                       │
  │           (inside-out, isolate layer by layer)                   │
  └──────────────────────────────────────────────────────────────────┘

  Step 1 — Ping loopback (127.0.0.1):
  Command: ping 127.0.0.1   (or ping ::1 for IPv6)
  Tests:   Local TCP/IP stack is initialised and functional
  Pass:    OS networking is working
  Fail:    Reinstall/repair TCP/IP stack; corrupted network driver

  Step 2 — Ping own IP address:
  Command: ping 192.168.1.10   (your own IP)
  Tests:   NIC is bound to IP and responding
  Pass:    NIC and IP configuration are correct
  Fail:    IP conflict (another device has the same IP); NIC issue

  Step 3 — Ping default gateway:
  Command: ping 192.168.1.1   (your gateway)
  Tests:   Local LAN — physical link, switch, NIC, gateway router LAN port
  Pass:    Local network is healthy
  Fail:    Cable unplugged; switch port down; wrong gateway configured;
           gateway router interface down; duplex mismatch

  Step 4 — Ping a known public IP (no DNS):
  Command: ping 8.8.8.8   (Google DNS — rarely filtered)
  Tests:   Internet connectivity beyond your LAN; ISP routing; WAN link
  Pass:    Internet routing is working end-to-end
  Fail:    Gateway can't reach internet; ISP issue; WAN interface down;
           ACL blocking outbound ICMP

  Step 5 — Ping destination IP:
  Command: ping 203.0.113.50   (specific server IP)
  Tests:   Routing to the specific destination subnet
  Pass:    Path to destination is working
  Fail:    Routing problem between you and the server; firewall blocking
           ICMP from your source IP; server ICMP blocked

  Step 6 — Ping destination hostname:
  Command: ping www.example.com
  Tests:   DNS resolution — can your configured DNS server resolve names?
  Pass:    DNS is working correctly
  Fail (IP works but hostname fails): DNS misconfiguration; wrong DNS
           server; DNS server unreachable; DNS cache issue
  →  Use nslookup or dig to confirm DNS resolution separately

Complete Scenario — User Cannot Access a Web Server

  User reports: "I cannot access http://www.example.com"
  User's IP: 192.168.1.10 / Gateway: 192.168.1.1

  Test 1: ping 127.0.0.1
  Result: Reply ✓ → TCP/IP stack OK

  Test 2: ping 192.168.1.10
  Result: Reply ✓ → NIC and IP config OK

  Test 3: ping 192.168.1.1
  Result: Reply ✓ → Local LAN and gateway OK

  Test 4: ping 8.8.8.8
  Result: Reply ✓ → Internet connectivity OK

  Test 5: ping 203.0.113.50  (www.example.com resolved manually)
  Result: Request timed out ✗
  → Server or path to server may be blocking ICMP
  → Try: telnet 203.0.113.50 80  → "Connected" = server is up, HTTP works
  → If telnet also fails: server is down or TCP/80 is firewalled

  Test 6: ping www.example.com
  Result: Reply ✓ → DNS resolving correctly

  Conclusion: Server is reachable (telnet to 80 connected) but
  ICMP is blocked by the web server's host firewall — the application
  works fine. User should clear browser cache or check credentials.

11. Ping vs Traceroute — When to Use Each

Feature	Ping	Traceroute / tracert
Confirms reachability	Yes — pass/fail for the destination	Yes — shows each hop individually
Shows path (hops)	No	Yes — lists every router in the path
Locates where failure occurs	No — only shows end-to-end result	Yes — last responding hop reveals failure point
Measures latency	Yes — overall RTT	Yes — per-hop RTT
Use for	First test: "Is it reachable at all?"	Follow-up: "Where exactly does it break?"
Protocol	ICMP Echo Request/Reply	ICMP (Windows) or UDP (Linux) with TTL increments; reads ICMP Time Exceeded replies from each hop

See: traceroute / tracert Guide

12. Exam Tips & Key Points

Ping uses ICMP Echo Request (Type 8) and ICMP Echo Reply (Type 0). ICMP is protocol number 1 in the IP header — no TCP or UDP ports are used.
TTL decrements by 1 at each router hop. If it reaches 0 the packet is dropped and the router sends ICMP Type 11 (Time Exceeded) back. Default starting TTLs: Windows=128, Linux/macOS=64, Cisco IOS=255.
"Request timed out" means no reply was received — host may be down, ICMP may be blocked, or there is no return route. It does NOT prove the host is offline.
"Destination host unreachable" means a router explicitly returned ICMP Type 3 — it cannot forward the packet. This is more informative than a timeout.
The inside-out troubleshooting order is: loopback (127.0.0.1) → own IP → default gateway → public IP (8.8.8.8) → destination IP → destination hostname. Each step isolates a specific layer or segment. See: Troubleshooting Connectivity
Ping by IP works but ping by hostname fails = DNS problem. Use nslookup to confirm.
On Cisco IOS, the symbol ! = success, . = timeout, U = destination unreachable, M = could not fragment (MTU/DF issue). Know all five common symbols.
Extended ping on Cisco IOS (privileged EXEC, type ping then Enter) allows setting source IP, packet count, size, timeout, and DF bit — essential for testing specific paths and MTU.
A successful ping only confirms Layer 3 IP reachability — it says nothing about whether TCP/UDP ports are open or applications are responding. Combine with traceroute and application-layer tests.

13. Summary Reference Table

Topic	Key Detail
Protocol used	ICMP — IP protocol number 1; no TCP/UDP ports
Request message	ICMP Type 8, Code 0 — Echo Request
Reply message	ICMP Type 0, Code 0 — Echo Reply
Default TTL (Windows)	128
Default TTL (Linux/macOS)	64
Default TTL (Cisco IOS)	255
Windows default packet count	4 packets (32-byte payload)
Linux default behaviour	Continuous until Ctrl+C (use -c N to limit)
Cisco IOS default	5 packets, 100-byte payload, 2s timeout
Cisco IOS symbols	! = success, . = timeout, U = unreachable, M = can't fragment
Extended ping	Cisco IOS privileged EXEC: type `ping` then Enter
Troubleshooting order	127.0.0.1 → own IP → gateway → 8.8.8.8 → dest IP → dest hostname

Ping Quiz

1. What protocol and message types does ping use, and at which OSI layer does it operate?

A. ICMP at Layer 3 — it sends ICMP Echo Request (Type 8) and expects ICMP Echo Reply (Type 0); no TCP or UDP ports are involved B. TCP at Layer 4 — it sends TCP SYN packets to port 7 (echo) and waits for SYN-ACK replies C. UDP at Layer 4 — it sends UDP datagrams to port 33434 and listens for responses D. HTTP at Layer 7 — it sends HTTP GET requests and measures the response time

Correct answer is A. Ping uses ICMP (Internet Control Message Protocol), which operates at Layer 3 of the OSI model. ICMP is encapsulated directly in an IP packet with protocol number 1 — it does not use TCP or UDP and has no port numbers. Ping sends an ICMP Type 8, Code 0 (Echo Request) to the destination and waits for an ICMP Type 0, Code 0 (Echo Reply) in return. Because it operates at Layer 3, a successful ping confirms IP routing is working end-to-end — but says nothing about Layer 4 ports or Layer 7 applications. Traceroute also uses ICMP (on Windows), but uses incremented TTL values and reads ICMP Type 11 Time Exceeded messages from intermediate routers.

2. A ping to a remote host returns "Request timed out" on every packet. What does this confirm and what does it NOT confirm?

A. It confirms the remote host is definitely offline and powered down B. It confirms the local TCP/IP stack has an error C. It confirms the host is online but the application service is down D. It confirms no ICMP Echo Reply was received within the timeout — but does NOT confirm the host is offline; ICMP may be blocked by a firewall, ACL, or host security policy while the host remains fully operational

Correct answer is D. "Request timed out" is one of the most misunderstood ping results. It means the local host sent an ICMP Echo Request but received no reply within the timeout window. This has multiple possible explanations: (1) The host is offline or unreachable — the most obvious cause. (2) A firewall or ACL is blocking ICMP (protocol 1) in either direction — the host is online and fully operational but silently drops ping packets. Many security policies and host firewalls (Windows Firewall, iptables) block ICMP by default. (3) There is no return route — the packet reached the destination but the reply has no path back to the source. (4) The host exists but deprioritises ICMP processing. Never conclude a host is offline based solely on a ping timeout — combine with testing a specific TCP port (telnet <IP> <port>) to confirm application-level reachability.

3. Which Windows ping option sends ICMP Echo Requests continuously until manually stopped with Ctrl+C?

A. -c — this is the Linux/macOS option to set the packet count B. -t — the Windows continuous ping option; sends packets indefinitely until Ctrl+C; press Ctrl+Break to display statistics without stopping C. -n — this sets the packet count on Windows (equivalent to Linux -c) D. -s — this sets the payload size on Linux/macOS

Correct answer is B. On Windows, ping -t <destination> sends ICMP Echo Requests continuously until interrupted. By default Windows sends only 4 packets and stops. The -t option is useful for monitoring link stability over time — watching for intermittent packet loss that would not be visible in a 4-packet test. While running, press Ctrl+Break to display accumulated statistics (packets sent, received, lost, average RTT) without stopping the ping; press Ctrl+C to stop completely. The equivalent on Linux/macOS is omitting the -c option entirely (Linux pings continuously by default) or using a very large count value.

4. When following the ping troubleshooting methodology, what is the correct first test and why?

A. Ping the public DNS server (8.8.8.8) — to quickly rule out internet issues before checking the local network B. Ping the remote destination server — to determine immediately whether the target is reachable C. Ping localhost (127.0.0.1) — it tests the local TCP/IP stack without sending any traffic onto the physical network; if this fails the problem is in the OS networking, not the network infrastructure D. Ping the default gateway — to confirm the local LAN is working before checking anything else

Correct answer is C. The inside-out methodology starts with the most local possible test and works progressively outward. The loopback address 127.0.0.1 (IPv4) or ::1 (IPv6) is handled entirely within the OS networking stack — the packet never touches the NIC, the cable, the switch, or any router. If pinging 127.0.0.1 fails, the problem is definitively within the local operating system: the TCP/IP stack may be corrupted, the network driver may have failed, or the network service may not be running. This instantly rules out all external infrastructure. If the loopback succeeds, you know the OS is functional and you can proceed to test the NIC, then the local LAN, then the gateway, then internet connectivity. Starting with a remote target (options A or B) when the local stack is broken gives you no diagnostic information.

5. Pinging the default gateway fails but pinging 127.0.0.1 succeeds. What layer and component does this isolate the problem to?

A. The local network — the TCP/IP stack is healthy (loopback succeeded) but something between the host and the gateway is broken: the physical cable, switch port, NIC, duplex mismatch, wrong gateway IP configured, or the gateway router's LAN interface being down B. A remote server being down — the gateway is working but the internet path is broken C. DNS resolution failure — the hostname cannot be resolved even though IP routing works D. An internet connectivity problem beyond the ISP

Correct answer is A. This is a key diagnostic deduction from the inside-out methodology. Loopback success (127.0.0.1 replies) confirms the OS TCP/IP stack is functional. Gateway failure isolates the problem to the local network segment — the physical and Layer 2 infrastructure between the host and the gateway. Specific things to investigate: (1) physical cable — unplugged or damaged; (2) switch port — down, VLAN misconfigured, or STP blocking; (3) NIC — driver issue, duplex/speed mismatch causing collisions or CRC errors; (4) wrong default gateway IP configured on the host — the host is pinging the wrong address; (5) gateway router's LAN interface — shutdown or no IP address. Use ipconfig (Windows) or ip addr (Linux) to verify the gateway IP is correct before checking physical infrastructure.

6. A ping reply shows TTL=54. Approximately how many hops away is the destination, and what OS is it likely running?

A. 54 hops away — TTL values directly indicate hop count B. 74 hops away — Windows (starting TTL 128): 128 - 54 = 74 C. 201 hops away — Cisco IOS (starting TTL 255): 255 - 54 = 201 D. Approximately 10 hops away from a Linux or macOS host — Linux/macOS default starting TTL is 64; 64 - 54 = 10 hops traversed

Correct answer is D. The TTL value in a ping reply is the remaining hop budget when the reply reached you — the destination started with its default TTL and it decremented by 1 at each router hop. To calculate hops traversed: starting TTL - received TTL = hops. Linux and macOS default to a starting TTL of 64. A received TTL of 54 means 64 - 54 = 10 hops were traversed — the destination is approximately 10 router hops away. Windows defaults to 128 (TTL=54 from Windows would mean 74 hops — extremely unlikely for an internet host). Cisco IOS defaults to 255. This TTL-based OS fingerprinting is a commonly tested concept: received TTL close to 64 → Linux/macOS host; close to 128 → Windows host; close to 255 → Cisco IOS device.

7. An engineer pings a web server and receives replies successfully. However, users still cannot access the website in their browser. What is the most likely explanation?

A. The host is offline — ping replies prove it is online B. The network cable between the server and switch is unplugged C. Ping only confirms Layer 3 IP reachability — ICMP is permitted but TCP port 80 (HTTP) or 443 (HTTPS) may be blocked by a firewall or ACL, or the web server service itself may not be running D. DNS is failing — the server cannot be found by name

Correct answer is C. A successful ping is one of the most common false indicators in network troubleshooting. Ping uses ICMP (protocol 1) — a completely separate protocol from the TCP that HTTP/HTTPS uses. Many firewall configurations permit ICMP for management purposes while blocking TCP application ports. Possible explanations include: (1) a firewall rule that permits ICMP but blocks TCP/80 and TCP/443; (2) the web server process (Apache, nginx, IIS) has crashed or not started — the OS is up and responds to ping but the application service is not listening; (3) the web server is listening on a non-standard port. To test application-layer connectivity specifically, use telnet <server-IP> 80 from the command line — if it connects, the TCP port is open. A successful connection followed by typing GET / HTTP/1.0 and pressing Enter twice will return the server's HTTP response.

8. Which Linux ping option limits the number of echo requests to exactly 5 packets, then stops and displays statistics?

A. -t — this is the Windows continuous ping option, not valid on Linux for this purpose B. -c 5 — the count option on Linux/macOS specifies how many Echo Requests to send before stopping and printing the summary statistics C. -l 5 — this is the Windows payload size option, not the packet count D. -n 5 — this is the Windows packet count option; on Linux -n disables reverse DNS lookups

Correct answer is B. On Linux and macOS, ping runs continuously by default — it keeps sending ICMP Echo Requests until interrupted with Ctrl+C. The -c <count> option specifies exactly how many packets to send before stopping automatically and printing the summary. For example, ping -c 5 8.8.8.8 sends exactly 5 requests. This is the Linux equivalent of Windows -n. The full Linux option comparison: -c (count), -s (payload size), -i (interval between packets), -W (timeout per reply), -M do (set DF bit for MTU testing), -I (source interface). Windows uses -n (count), -l (size), -t (continuous), -f (DF bit).

9. A ping to 8.8.8.8 shows "!.!.!.!." on a Cisco IOS router — 4 successes and 4 timeouts alternating. What does this pattern indicate and what are the likely causes?

A. Intermittent packet loss (50% in this case) — likely causes are network congestion, a flapping or degraded physical link, a faulty cable or interface, or an overloaded intermediate device dropping packets under load B. The host is permanently online — the alternating pattern is normal ICMP rate limiting C. DNS is resolving correctly for half the packets D. The packet size is too small — increasing the payload would eliminate the timeouts

Correct answer is A. On Cisco IOS, ! = ICMP Echo Reply received (success) and . = timeout (no reply within the 2-second default timeout). The pattern !.!.!.!. shows 50% packet loss — 4 of 8 packets were dropped. This is intermittent connectivity, not a complete failure. Likely causes: (1) Network congestion — intermediate links are overloaded and randomly dropping ICMP when buffers fill; (2) Flapping link — an interface going up and down intermittently, with some packets traversing during the up period; (3) Faulty cable or SFP — causing periodic bit errors and packet drops; (4) ICMP rate limiting on the destination — some devices intentionally rate-limit ICMP replies to prevent ping-based network scanning. Follow up with traceroute to identify which hop is losing packets.

10. Ping to a web server's IP address (203.0.113.50) succeeds, but ping to the same server by its domain name (www.example.com) fails. What does this diagnose?

A. The web server is offline — IP ping only tests the gateway, not the server directly B. A firewall is blocking ICMP destined for the server's domain name C. Application ports are closed on the web server D. A DNS resolution problem — the host can reach the IP directly (proving routing and connectivity are fine) but cannot resolve the domain name to an IP address, indicating a DNS server issue, wrong DNS server configuration, or DNS cache corruption

Correct answer is D. This is a classic diagnostic pattern that precisely isolates a DNS problem. When ping by IP succeeds, it confirms: (1) the local TCP/IP stack is working; (2) the local LAN and gateway are functional; (3) routing to the destination subnet is working; (4) ICMP is permitted. The only thing that differs between ping 203.0.113.50 and ping www.example.com is that the second command requires DNS resolution first. If the IP ping succeeds but the name ping fails, the network path is fine — the DNS resolution is broken. Specific causes: wrong DNS server configured (check with ipconfig /all); DNS server unreachable; DNS server not responding; corrupted DNS cache (fix with ipconfig /flushdns on Windows); the DNS record for the domain points to a different IP than 203.0.113.50. Confirm with nslookup www.example.com to see what IP the DNS server returns.

← Back to Home