Troubleshooting Tools and Method — Networking

TL;DR

A fixed method — identify, theorize, test, plan, implement, verify, document — finds causes faster than trying random fixes.
The Open Systems Interconnection (OSI) model is a checklist: confirm each layer works before you blame the one above it, or split the problem in the middle.
Ping tests reachability, traceroute shows the path, and ip/ipconfig, nslookup/dig and ss show a host's own addressing, name resolution and open ports.
On Cisco devices, show ip interface brief, show interfaces and show ip route answer most first questions.
A packet capture shows what actually crossed the wire when every other tool leaves doubt.

Why a method beats guessing

A ticket says "the Internet is down". The tempting reaction is to restart something and see what happens. Sometimes that works, but you learn nothing, you may cause a second outage, and when the problem returns you are back at the start. Worse, when you change three things at once and the problem disappears, nobody knows which change fixed it.

A structured approach turns troubleshooting into a series of small experiments: collect facts, form one explanation, test it, and only then change something. It also makes your work easy to hand over — a colleague on the next shift, or the second-line team you escalate to, can see exactly what you have already ruled out.

A structured methodology

A troubleshooting methodology is a fixed sequence of steps for going from a symptom to a verified, documented fix. The best known is the one in CompTIA Network+:

Identify the problem. Gather information, question users, identify symptoms, determine whether anything has changed, duplicate the problem if possible, and approach multiple problems individually.
Establish a theory of probable cause. Question the obvious, and consider multiple approaches: top-to-bottom or bottom-to-top through the Open Systems Interconnection (OSI) model, or divide and conquer.
Test the theory to determine the cause. If the theory is confirmed, determine the next steps to resolve the problem; if not, establish a new theory or escalate.
Establish a plan of action to resolve the problem and identify potential effects — for example, a change that needs a maintenance window because it interrupts other users.
Implement the solution or escalate as necessary.
Verify full system functionality and, if applicable, implement preventive measures.
Document findings, actions, outcomes, and lessons learned throughout the process.

Cisco's material describes the same idea in slightly different words (gather information, analyze, eliminate possible causes, propose and test a hypothesis, solve and document). The exact wording matters less than the discipline: facts before changes, one change at a time, and always verify and document.

Approaches

Step 2 asks where to start looking. Five approaches cover almost every case:

Bottom-up: start at the physical layer (cable, link light, interface status) and work up. Thorough, and best when you suspect hardware or cabling, but slow for application problems.
Top-down: start at the application (does the web page load, what error does it show?) and work down. Good when the network probably works and one application does not.
Divide and conquer: start in the middle, usually with a ping (layer 3). If it succeeds, layers 1–3 work along that path and you look up; if it fails, you look down. This is the fastest approach once you have some experience.
Follow the path: trace the route the traffic takes — PC, access switch, distribution switch, router, firewall, server — and check each device in turn until you find where it stops.
Compare with a known good: compare the broken device with a working one — a colleague's PC in the same virtual local area network (VLAN), a switch port that works, last week's saved configuration. The difference often is the answer.

The OSI model as a checklist

The OSI model gives each approach a structure. Each layer has its own typical questions:

Three ways through the same stack. Divide and conquer starts in the middle, usually with a ping, and goes up or down depending on the result.

Layer	Questions to ask	Tools
1 Physical	Is the cable plugged in? Link light? Interface up? Errors on the port?	Eyes, cable tester, `show interfaces`
2 Data link	Right VLAN? Is the MAC address learned? Is the port error-disabled? Does Address Resolution Protocol (ARP) resolve the gateway?	`show vlan brief`, `show mac address-table`, `arp -a`, `ip neigh`
3 Network	Correct IP address, mask and gateway? Is there a route both ways?	`ip addr`, `ipconfig`, `ping`, `traceroute`, `show ip route`
4 Transport	Is the service listening on the right port? Is a firewall or ACL blocking the port?	`ss`, `netstat`, `show access-lists`
5–7 Upper layers	Does the name resolve? Is the certificate valid? What does the application answer?	`nslookup`, `dig`, `curl -v`, browser developer tools

Tools on the host

Most tickets start at an end user's device. These are the tools you will run there, with the output they typically produce. Commands are shown for Linux (the modern iproute2 tools) and Windows 11.

ping

Ping sends Internet Control Message Protocol (ICMP) echo requests to a target and waits for echo replies. A reply proves that packets can travel to the target and back at layer 3; the output also shows the round-trip time (RTT) and how many packets were lost.

ping -c 4 192.0.2.10

PING 192.0.2.10 (192.0.2.10) 56(84) bytes of data.
64 bytes from 192.0.2.10: icmp_seq=1 ttl=57 time=12.4 ms
64 bytes from 192.0.2.10: icmp_seq=2 ttl=57 time=11.9 ms
64 bytes from 192.0.2.10: icmp_seq=4 ttl=57 time=12.1 ms

--- 192.0.2.10 ping statistics ---
4 packets transmitted, 3 received, 25% packet loss, time 3005ms
rtt min/avg/max/mdev = 11.900/12.133/12.400/0.205 ms

On Linux, ping runs until you press Ctrl+C; -c 4 stops after four. Read it like this: icmp_seq=3 is missing, so one of four packets got no answer (25% loss). time is the RTT per packet, and mdev shows how much it varies (jitter). ttl=57 is the remaining time-to-live of the reply; since most systems start at 64, the reply crossed about seven routers. Windows sends four packets by default:

ping 192.0.2.10

Pinging 192.0.2.10 with 32 bytes of data:
Reply from 192.0.2.10: bytes=32 time=12ms TTL=57
Reply from 192.0.2.10: bytes=32 time=11ms TTL=57
Request timed out.
Reply from 192.0.2.10: bytes=32 time=13ms TTL=57

Ping statistics for 192.0.2.10:
    Packets: Sent = 4, Received = 3, Lost = 1 (25% loss),
Approximate round trip times in milli-seconds:
    Minimum = 11ms, Maximum = 13ms, Average = 12ms

Request timed out. means no reply arrived in time. A line such as Reply from 192.168.1.1: Destination host unreachable. is different: a router (or your own PC) reports that it could not deliver the packet — often because ARP for the final host failed. On a Cisco router, each ! is a reply, . a timeout and U an unreachable message:

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

The first dot is normal on a first ping: the router had to resolve the target's MAC address with ARP before it could send, and the first echo request timed out meanwhile. The ARP and ICMP page explains both protocols.

traceroute and tracert

Traceroute lists the routers (hops) on the path to a destination. It sends probes with a time-to-live (TTL) of 1, then 2, then 3, and so on. Each router decrements the TTL; the router where it reaches 0 drops the probe and sends back an ICMP Time Exceeded message, which reveals its address. Linux traceroute sends UDP probes by default; Windows tracert sends ICMP echo requests.

traceroute www.example.com

traceroute to www.example.com (203.0.113.80), 30 hops max, 60 byte packets
 1  _gateway (192.168.1.1)  0.512 ms  0.478 ms  0.455 ms
 2  198.51.100.1 (198.51.100.1)  8.931 ms  8.902 ms  8.874 ms
 3  * * *
 4  198.51.100.45 (198.51.100.45)  11.207 ms  11.180 ms  11.152 ms
 5  203.0.113.80 (203.0.113.80)  12.034 ms  11.998 ms  12.011 ms

tracert www.example.com

Tracing route to www.example.com [203.0.113.80]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  192.168.1.1
  2     9 ms     8 ms     9 ms  198.51.100.1
  3     *        *        *     Request timed out.
  4    11 ms    11 ms    12 ms  198.51.100.45
  5    12 ms    12 ms    12 ms  203.0.113.80

Trace complete.

Each hop is probed three times, hence three times per line. What the output does and does not prove:

* * * at hop 3 means that router sent no Time Exceeded message in time. Because hops 4 and 5 answer, traffic clearly passes through it — the router is simply configured not to reply, or rate-limits its replies. Stars are only meaningful when every hop after a point stays silent.
Traceroute shows only the path to the destination. The return path may be different, and a problem there is invisible.
A high time at one hop that does not carry on to later hops is not a problem: routers answer traceroute with low priority, after forwarding real traffic.
A firewall that blocks UDP or ICMP can make the trace stop even though the service port (for example Transmission Control Protocol (TCP) port 443) works. On Linux, traceroute -I uses ICMP and traceroute -T -p 443 uses TCP (both need root).

Addresses, routes and neighbors

Before blaming the network, check what the host itself thinks. On Linux, three ip commands show the address, the routing table and the neighbor (ARP) cache:

ip addr show enp1s0
ip route
ip neigh

2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 00:00:5e:00:53:21 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.50/24 brd 192.168.1.255 scope global dynamic noprefixroute enp1s0
       valid_lft 82345sec preferred_lft 82345sec
    inet6 fe80::200:5eff:fe00:5321/64 scope link noprefixroute
       valid_lft forever preferred_lft forever
default via 192.168.1.1 dev enp1s0 proto dhcp src 192.168.1.50 metric 100
192.168.1.0/24 dev enp1s0 proto kernel scope link src 192.168.1.50 metric 100
192.168.1.1 dev enp1s0 lladdr 00:00:5e:00:53:01 REACHABLE
192.168.1.20 dev enp1s0 lladdr 00:00:5e:00:53:14 STALE
192.168.1.77 dev enp1s0 FAILED

state UP and LOWER_UP: the interface is enabled and has a link (layer 1 is fine).
inet 192.168.1.50/24 … dynamic: an IPv4 address with a /24 prefix, received from DHCP. An address in 169.254.0.0/16 instead would mean DHCP failed and the host fell back to a self-assigned (Automatic Private IP Addressing, APIPA) address.
default via 192.168.1.1: the default gateway. No default route means the host can reach only its own subnet.
In ip neigh, REACHABLE and STALE entries have a known MAC address; FAILED means ARP got no answer — that host is off, in another VLAN, or has a wrong address.

On Windows, ipconfig /all shows the same facts plus the DNS servers, and route print and arp -a show the routing table and ARP cache:

ipconfig /all

Ethernet adapter Ethernet:

   Connection-specific DNS Suffix  . : corp.example.com
   …
   Physical Address. . . . . . . . . : 00-00-5E-00-53-21
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes
   Link-local IPv6 Address . . . . . : fe80::200:5eff:fe00:5321%12(Preferred)
   IPv4 Address. . . . . . . . . . . : 192.168.1.50(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   …
   Default Gateway . . . . . . . . . : 192.168.1.1
   DHCP Server . . . . . . . . . . . : 192.168.1.1
   DNS Servers . . . . . . . . . . . : 192.168.1.1

route print -4
arp -a

…
IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0      192.168.1.1     192.168.1.50     25
      192.168.1.0    255.255.255.0         On-link      192.168.1.50    281
…

Interface: 192.168.1.50 --- 0xc
  Internet Address      Physical Address      Type
  192.168.1.1           00-00-5e-00-53-01     dynamic
  192.168.1.255         ff-ff-ff-ff-ff-ff     static

Two classic clues: an IPv4 Address of 169.254.x.x(Preferred) with no default gateway (DHCP failed), and a gateway in a different subnet than the host's address (typo in a static configuration). ipconfig /release, /renew and /flushdns are the usual follow-up commands.

Name resolution: nslookup and dig

When an address works but a name does not, the problem is DNS. nslookup exists on both Windows and Linux; dig (Linux and macOS) shows more detail.

nslookup www.example.com

Server:  UnKnown
Address:  192.168.1.1

Non-authoritative answer:
Name:    www.example.com
Address:  203.0.113.80

Server is the DNS server that answered (it shows UnKnown when that server has no reverse DNS name — not an error). Non-authoritative means the answer came from a recursive resolver (from its cache or a fresh lookup), not from the zone's own authoritative name server.

dig www.example.com A

; <<>> DiG 9.18.33 <<>> www.example.com A
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41872
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
…
;; ANSWER SECTION:
www.example.com.        3600    IN      A       203.0.113.80

;; Query time: 14 msec
;; SERVER: 192.168.1.1#53(192.168.1.1) (UDP)
…

status: NOERROR with an answer section is success. NXDOMAIN means the name does not exist (often a typo); SERVFAIL means the resolver could not get an answer; a timeout means no DNS server answered at all. The 3600 is the record's TTL in seconds: how long caches may keep it. dig @192.0.2.53 www.example.com asks a specific server, which is how you compare two servers.

Ports and services: ss, netstat and curl

If the network path works but a service does not answer, check on the server whether anything is listening on the port. ss replaced netstat on Linux; Windows still uses netstat.

ss -tln

State   Recv-Q  Send-Q   Local Address:Port    Peer Address:Port  Process
LISTEN  0       128            0.0.0.0:22           0.0.0.0:*
LISTEN  0       511          127.0.0.1:8080         0.0.0.0:*
LISTEN  0       128               [::]:22              [::]:*

-t shows TCP, -l listening sockets only, -n numbers instead of names (add -p with sudo to see the process). SSH listens on every IPv4 and IPv6 address. The application on port 8080 listens only on 127.0.0.1, so it is reachable from the server itself but not from the network — a very common cause of "it works on the server but not from my PC". On Windows, netstat -ano lists connections and listening ports with the owning process ID.

For web services, curl -v shows every stage — name resolution, TCP connection, Transport Layer Security (TLS) handshake, Hypertext Transfer Protocol (HTTP) request and response — so you see exactly where it stops:

curl -v https://www.example.com/

* Host www.example.com:443 was resolved.
* IPv6: (none)
* IPv4: 203.0.113.80
*   Trying 203.0.113.80:443...
* Connected to www.example.com (203.0.113.80) port 443
…
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 / X25519 / RSASSA-PSS
…
> GET / HTTP/2
> Host: www.example.com
> User-Agent: curl/8.14.1
> Accept: */*
…
< HTTP/2 200
< content-type: text/html; charset=UTF-8
…

Lines with * are curl's own notes, > is what it sent and < what the server answered. Connected to proves TCP port 443 is open; a hang at Trying suggests a firewall dropping packets, and Connection refused means the host answered but nothing listens on that port (though a firewall that rejects instead of dropping gives No route to host — firewalld's default — or even Connection refused). A status such as HTTP/2 200 means the network is fine and any remaining problem is in the application.

Cisco show commands every starter needs

On the network devices, a handful of show commands answer most first questions. They are read-only, so they are safe to run on a production device.

show ip interface brief

R1# show ip interface brief
Interface              IP-Address      OK? Method Status                Protocol
GigabitEthernet0/0     192.168.1.1     YES manual up                    up
GigabitEthernet0/1     198.51.100.2    YES manual up                    up
GigabitEthernet0/2     unassigned      YES unset  administratively down down
GigabitEthernet0/3     10.0.12.1       YES manual up                    up
GigabitEthernet0/4     10.0.13.1       YES manual down                  down

One line per interface: its IP address and two status columns. Status is layer 1, Protocol is layer 2.

up / up: working.
administratively down / down: someone configured shutdown; fix with no shutdown.
down / down: no physical link — cable, far-end device off or shut down, or a wrong transceiver.
up / down: the link is there but the data link protocol is not working, for example mismatched encapsulation on a serial link.

show interfaces

Switch1# show interfaces GigabitEthernet0/7
GigabitEthernet0/7 is up, line protocol is up (connected)
  Hardware is Gigabit Ethernet, address is 0000.5e00.5307 (bia 0000.5e00.5307)
  …
  Full-duplex, 1000Mb/s, media type is 10/100/1000BaseTX
  …
     1520488 packets input, 204331890 bytes, 0 no buffer
     Received 12033 broadcasts (8120 multicasts)
     0 runts, 0 giants, 0 throttles
     1843 input errors, 1843 CRC, 0 frame, 0 overrun, 0 ignored
  …
     0 output errors, 0 collisions, 1 interface resets
     0 late collision, 0 deferred

The detailed view shows duplex, speed and error counters. Cyclic redundancy check (CRC) errors are frames that arrived damaged: usually a bad cable, connector or interference — or, together with late collisions on the far end, a duplex mismatch. Late collisions on a full-duplex network point to a duplex mismatch. Counters grow over time, so compare two readings a few minutes apart (or reset them with clear counters) rather than judging a total collected since the last reboot.

Other essentials

Switch1# show vlan brief
VLAN Name                             Status    Ports
---- -------------------------------- --------- -------------------------------
1    default                          active    Gi0/3, Gi0/4
10   USERS                            active    Gi0/1, Gi0/2, Gi0/5, Gi0/7
20   VOICE                            active
…

show vlan brief shows which access ports are in which VLAN. A user port in VLAN 1 instead of VLAN 10 is a frequent finding. Trunk ports are not listed here; use show interfaces trunk for those.

R1# show ip route
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
       …
Gateway of last resort is 198.51.100.1 to network 0.0.0.0

S*    0.0.0.0/0 [1/0] via 198.51.100.1
      10.0.0.0/8 is variably subnetted, 3 subnets, 3 masks
C        10.0.12.0/30 is directly connected, GigabitEthernet0/3
L        10.0.12.1/32 is directly connected, GigabitEthernet0/3
O        10.20.0.0/16 [110/2] via 10.0.12.2, 00:14:02, GigabitEthernet0/3
      192.168.1.0/24 is variably subnetted, 2 subnets, 2 masks
C        192.168.1.0/24 is directly connected, GigabitEthernet0/0
L        192.168.1.1/32 is directly connected, GigabitEthernet0/0
      198.51.100.0/24 is variably subnetted, 2 subnets, 2 masks
C        198.51.100.0/30 is directly connected, GigabitEthernet0/1
L        198.51.100.2/32 is directly connected, GigabitEthernet0/1

show ip route answers "does this router know where to send the packet?" The letter in front is the source of the route (C connected, L local, S static, O OSPF, * candidate default). If neither a specific route nor a default route matches the destination, the router drops the packet. See Routing Basics.

Switch1# show cdp neighbors
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
                  S - Switch, H - Host, I - IGMP, r - Repeater, P - Phone,
                  D - Remote, C - CVTA, M - Two-port Mac Relay

Device ID        Local Intrfce     Holdtme    Capability  Platform  Port ID
R1               Gig 0/24          143              R B   CISCO2911 Gig 0/0
Switch2          Gig 0/23          171              S I   WS-C2960X Gig 1/0/1

show cdp neighbors lists the directly connected Cisco devices and on which ports they connect — invaluable when the network diagram is out of date. CDP (Cisco Discovery Protocol) is Cisco-only; the vendor-neutral LLDP (Link Layer Discovery Protocol, IEEE 802.1AB) gives the same view with show lldp neighbors, after enabling it with lldp run.

Switch1# show logging
…
*Sep 30 09:14:07.123: %LINK-3-UPDOWN: Interface GigabitEthernet0/7, changed state to down
*Sep 30 09:14:08.127: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/7, changed state to down
*Sep 30 09:14:12.402: %LINK-3-UPDOWN: Interface GigabitEthernet0/7, changed state to up
*Sep 30 09:14:13.405: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/7, changed state to up

show logging shows the device's recent log messages. A port going down and up again (flapping) often explains a short outage a user reported. The number after the facility (3, 5) is the severity level; the leading * means the clock is not synchronized, which makes it hard to correlate events across devices — see NTP, SNMP and syslog.

Packet capture

A packet capture records the actual frames passing an interface, so you can inspect every header field afterward. It settles arguments that other tools cannot: did the client send the request, did the server answer, and what exactly was in it? Wireshark is the graphical tool; tcpdump is its command-line counterpart on Linux, ideal on servers without a desktop. Both save .pcap/.pcapng files that the other can open.

sudo tcpdump -i enp1s0 -n icmp and host 192.168.1.1

tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on enp1s0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
09:21:04.112233 IP 192.168.1.50 > 192.168.1.1: ICMP echo request, id 5, seq 1, length 64
09:21:04.112701 IP 192.168.1.1 > 192.168.1.50: ICMP echo reply, id 5, seq 1, length 64

There are two kinds of filter, with different syntax:

A capture filter (Berkeley Packet Filter syntax, as in the tcpdump command above: host 192.168.1.1 and port 53) decides what is recorded at all. It keeps files small but cannot be undone: what was not captured is gone.
A display filter (Wireshark syntax, such as ip.addr == 192.168.1.1 && dns or tcp.flags.syn == 1) only hides packets in the view and can be changed at any time.

Where you capture matters. A capture on the client shows what the client sent and received; to see traffic between two other devices, you configure a switch to copy it to your port (port mirroring, called Switched Port Analyzer (SPAN) on Cisco switches).

Worked scenario: a user cannot reach a website

A ticket: "I can't open www.example.com since this morning." Here is the method in practice.

Identify the problem. Asking questions reveals: the colleague at the next desk can open the site; this user cannot open any website, but a network drive mapped by IP address still works. The user installed a VPN client for a customer yesterday. You reproduce the problem on the PC.
Theory, bottom-up. ipconfig /all shows a normal address (192.168.1.50/24) and gateway, so layers 1–3 look fine locally. ping 192.168.1.1 and ping 203.0.113.80 (the site's address, taken from the colleague's PC) both succeed. Addresses work, names do not: the theory is a DNS problem.
Test the theory. ipconfig /all lists DNS server 192.168.1.53, while the colleague has 192.168.1.1. nslookup www.example.com times out against 192.168.1.53; nslookup www.example.com 192.168.1.1 answers immediately. Confirmed: the PC uses a wrong, manually set DNS server, probably left behind by the VPN client installation.
Plan of action. Set the adapter's DNS back to "obtain automatically" (from DHCP). Potential effects: none for other users; the customer VPN may need its own DNS setting, which its client configures when it connects.
Implement the change and run ipconfig /flushdns to clear cached failures.
Verify full functionality. The site loads, other sites load, nslookup uses 192.168.1.1, and the user confirms. Connecting and disconnecting the customer VPN once more shows the setting stays correct.
Document in the ticket, as below.

Symptom:  User PC-042 cannot open any website by name; other users OK.
Findings: IP config OK (192.168.1.50/24, gw 192.168.1.1). Ping gw and
          203.0.113.80 OK. DNS server manually set to 192.168.1.53
          (not in use); nslookup times out. nslookup via 192.168.1.1 OK.
Cause:    Static DNS entry, probably from customer VPN client install.
Action:   DNS set to automatic (DHCP), ipconfig /flushdns.
Verified: Websites load, nslookup uses 192.168.1.1, VPN connect/
          disconnect tested. User confirmed.
Follow-up: Check whether other VPN client installs did the same.

Documentation and baselines

Good ticket notes list the symptom, what you tested with the result, the cause, the change you made and how you verified it. They make the next similar ticket a five-minute job, show patterns (the same switch port failing every month) and protect you when someone asks later what was changed and why.

A baseline is a record of what "normal" looks like: typical latency to key servers, link utilization during office hours, normal CPU load on the core switch, the usual error counters. Without it, "the network is slow" cannot be checked — 40 ms to a branch office is bad if it is normally 8 ms and perfectly normal if it has always been 40 ms. Monitoring systems build baselines automatically from SNMP and flow data; the operational services page covers how.

Tool output is also data you can process. This example extracts loss, round-trip times and the missing sequence numbers from a block of Linux ping output with regular expressions — the kind of small script that turns a log file into a quick summary. The output text is included in the code, so nothing is sent on the network.

import re

PING_OUTPUT = """\
PING 192.0.2.10 (192.0.2.10) 56(84) bytes of data.
64 bytes from 192.0.2.10: icmp_seq=1 ttl=57 time=12.4 ms
64 bytes from 192.0.2.10: icmp_seq=2 ttl=57 time=11.9 ms
64 bytes from 192.0.2.10: icmp_seq=4 ttl=57 time=12.1 ms
64 bytes from 192.0.2.10: icmp_seq=5 ttl=57 time=48.8 ms

--- 192.0.2.10 ping statistics ---
5 packets transmitted, 4 received, 20% packet loss, time 4006ms
"""

REPLY = re.compile(r"icmp_seq=(\d+) ttl=(\d+) time=([\d.]+) ms")
SENT = re.compile(r"(\d+) packets transmitted")

replies = [(int(seq), float(ms)) for seq, _, ms in REPLY.findall(PING_OUTPUT)]
sent = int(SENT.search(PING_OUTPUT).group(1))

received = len(replies)
loss = (sent - received) / sent * 100
times = [ms for _, ms in replies]
answered = {seq for seq, _ in replies}
missing = [seq for seq in range(1, sent + 1) if seq not in answered]
slow = [seq for seq, ms in replies if ms > 2 * min(times)]

print(f"Sent {sent}, received {received}, loss {loss:.0f}%")
print(f"RTT min/avg/max: {min(times)}/{sum(times) / len(times):.1f}/{max(times)} ms")
print("No reply for icmp_seq:", missing)
print("More than twice the fastest RTT:", slow)

Sent 5, received 4, loss 20%
RTT min/avg/max: 11.9/21.3/48.8 ms
No reply for icmp_seq: [3]
More than twice the fastest RTT: [5]

Regular expressions and f-strings are explained in the Python strings page. Note the average: one slow reply pulls it far above the typical 12 ms, which is why the minimum and maximum are worth reading too.