FF-02: Linux connectivity & tracing

All faultfinding roadmaps · FF-02 · Deployed / workshop / training

A Linux device cannot reach a network, hostname or application.

Have to hand

Terminal access, intended interface / addressing / route, destination hostname and service details.

Before you start

Replace uppercase placeholders with approved values; do not paste them literally. IFACE is the interface, NEXT_HOP_IP is the actual next hop, DEST_IP is the destination, HOSTNAME is its name, and SERVICE is the service unit. Start with “ip link show” to find interfaces.

Follow the equipment manual and local procedure. If a tool, permission, safe test setup or required measurement is unavailable, record the result as unknown and escalate with the available evidence. Change one item at a time.

For offline use, print or save this page as a PDF using your browser’s Print command. Include any linked roadmaps you expect to need.

Checks on this page

1. Does the local interface have a usable link?
2. Check the address and the route actually selected
3. Establish the local next-hop boundary
4. Trace toward the destination
5. Does the hostname resolve correctly?
6. Check the listener and application health
7. Test the intended application
V. Verify recovery
E. Escalate

1. Does the local interface have a usable link?

Read interface state and counters. For wired Ethernet, check carrier and “Link detected”. Administrative UP does not prove carrier; a virtual interface may legitimately show UNKNOWN.
For an intermittent fault, compare error-counter changes during a repeatable test. Historical totals alone do not show an active fault. Optional “ethtool -S IFACE” statistics depend on the driver.
If the interface is missing or the link is faulty, inspect device / peer power, driver, cable and port. Within the approved procedure, substitute one compatible known-good cable / port and repeat the check. Record each result.

ip link show
ip -s link show dev IFACE
ethtool IFACE

Is the expected interface present, with usable carrier and no unexplained increase in errors?

Yes

Check the selected source address and route.

Next: FF-02 · Check 2: Check the address and the route actually selected.

No; radio measurements indicate degradation

Follow the RF evidence and retain the interface-counter results.

Next: FF-03 · Check 1: Record signal and quality together.

No after local checks / substitution unavailable

Record carrier, driver, peer state and before / after counters. Escalate the persistent link fault without repeating unchanged checks.

Next: E · Escalate with evidence.

2. Check the address and the route actually selected

Compare the address and prefix with the network plan. Route lookup identifies the selected interface, source address and next hop; the presence of a route does not prove delivery.
For IPv6 use the appropriate -6 forms, including “ip -6 route show” and “ip -6 route get DEST_IP”. Link-local destinations require the correct interface scope.

ip address show dev IFACE
ip route show
ip route get DEST_IP

Do the address, source interface and next hop match the intended path?

Yes

Test the actual next hop. On an on-link route, use the destination as the neighbour target.

Next: FF-02 · Check 3: Establish the local next-hop boundary.

No

Investigate DHCP / static configuration, VLAN, VPN and policy routing. Record the mismatch and agree a correction that preserves management access.

Next: E · Escalate with evidence.

3. Establish the local next-hop boundary

For Ethernet-like links, repeated INCOMPLETE or FAILED for the actual next hop points to neighbour-resolution trouble. STALE by itself is normal; an empty table may mean no recent traffic.
An unanswered ping can be filtering or rate limiting. Compare with an approved responding peer or the intended service. Point-to-point / tunnel links may not use neighbour resolution.

ping -c 4 -W 3 NEXT_HOP_IP
ip neigh show dev IFACE

Is local delivery established, or does the result identify a local fault?

Local delivery established / neighbour checks not applicable

Test the destination and path. Keep any unanswered ICMP probe recorded as inconclusive.

Next: FF-02 · Check 4: Trace toward the destination.

Repeated neighbour-resolution failure

Check local addressing, VLAN, peer power and the physical segment. Record the failing boundary.

Next: E · Escalate with evidence.

Inconclusive / unanswered ping without resolution failure

Keep the local boundary unconfirmed and continue to destination and application tests. Do not label STALE or an empty table as a fault.

Next: FF-02 · Check 4: Trace toward the destination.

4. Trace toward the destination

Use a small number of probes against an approved destination. A reply demonstrates reachability at that moment; no reply does not prove the host is offline.
Use tracepath, or “traceroute -n DEST_IP” if installed. An isolated timeout or asterisk is not proof of a broken hop. Compare end-to-end results and repeatable changes with a working baseline; paths and return paths can differ.

ping -c 4 -W 3 DEST_IP
tracepath -n DEST_IP

What does the end-to-end result show?

Destination responds / trace is inconclusive

Continue to name and application checks. Do not stop at ping or trace results.

Next: FF-02 · Check 5: Does the hostname resolve correctly?.

Repeatable path error and destination service fails

Capture the route, trace, source and destination. Investigate upstream routing, policy or the remote endpoint with the network team.

Next: E · Escalate with evidence.

5. Does the hostname resolve correctly?

getent uses the host’s configured name-service path, which can include local files. If systemd-resolved is used, inspect resolvectl status and query output.
Compare answers with the approved service configuration, including legitimate multiple addresses. If testing an IP-only service, proceed to the service check.

getent ahosts HOSTNAME
# Only where systemd-resolved is used:
resolvectl status
resolvectl query HOSTNAME

Is the expected name-resolution result available?

Yes / name resolution not needed

Check the requested application and its listener.

Next: FF-02 · Check 6: Check the listener and application health.

No / unexpected answer

Check resolver reachability, search domains, local hosts entries and split-DNS / VPN settings. Record the failed query and configured resolver.

Next: E · Escalate with evidence.

6. Check the listener and application health

Run listener and service commands on the service host. ss describes the machine where it runs; it does not inspect a remote host. Check the expected port, bind address and protocol. A loopback-only listener cannot directly serve remote clients.
systemctl and journalctl apply to systemd systems; use the platform’s equivalent otherwise. “Active” is not proof the user operation works. Capture relevant logs without restarting first.

ss -lntup
# On a systemd service host:
systemctl --no-pager --full status SERVICE
journalctl -u SERVICE --since "-30 min" -n 100 --no-pager

Is the expected service available, or can it be tested from the client?

Listener looks correct / no server access

Run the original client operation. Use the bounded HTTP test below only for HTTP(S) services.

Next: FF-02 · Check 7: Test the intended application.

Missing listener / failed service

Record the bind address, port, service state and relevant log errors. Investigate configuration and dependencies before an agreed recovery action.

Next: E · Escalate with evidence.

7. Test the intended application

Repeat the original user operation. For an HTTP(S) endpoint that permits HEAD requests, this optional probe tests connection, TLS and HTTP response. Adjust the illustrative timeouts to the normal link latency.
401 / 403 / 404 / 405 responses show that a server or intermediary answered; they do not prove application success. A 405 may mean HEAD is unsupported. Record TLS errors without disabling certificate validation. For other protocols use the approved client.

# Optional, for the approved HTTPS endpoint:
curl --head --connect-timeout 5 --max-time 15 https://HOSTNAME/

Does the original user operation meet the service requirement?

Yes

Record the recovery and verify stability over the agreed period.

Next: V · Verify recovery.

No

Capture application errors and the working network boundary. Investigate access policy, proxy, TLS, server health and dependencies.

Next: E · Escalate with evidence.

Command availability and interpretation

Example only: for interface enp1s0, “ip -s link show dev enp1s0” displays its counters. Obtain addresses and service names from the network plan.

ip and ss come from iproute2; ping / tracepath commonly come from iputils. ethtool, traceroute and curl may need separate packages. Missing tools and permission errors are unknown results, not evidence of a network fault. Some process details, logs and hardware statistics require elevated access.

The commands shown display state or send diagnostic probes. Resets, route changes, forced speed / duplex and offline hardware tests need a separate agreed change procedure.

V. Prove the service is restored

Restore the approved configuration, connections, covers and weather seals. Remove test equipment and temporary changes using the equipment procedure.
Repeat the original failing user operation and the relevant measurements. Check both ends where applicable; ping success or a good RF reading alone is insufficient.
Compare before / after readings with the equipment limits, required service level and baseline under representative traffic.
Observe for the agreed period, record remaining limits and return the equipment to the responsible operator. A brief pass does not establish long-term availability.

Meets the agreed requirements: record the evidence and corrective action in the fault record. Close the fault through the normal reporting process.

Fails / no correction / still uncertain: keep the fault open. Record the last confirmed working boundary and remaining symptoms; avoid repeating unchanged checks. Escalate with evidence.

E. Escalate with evidence

Send the record through the approved support channel. Exclude credentials, tokens and unnecessary sensitive details.

System / location, UTC time, impact, exact failing operation, last working state and recent changes.
Roadmap code and check reached, expected result, actual readings, instrument / command used, units and measurement reference point.
Relevant interface counters, addressing / route, neighbour state, bounded path tests, resolver results and service logs.
For RF: measurements at both ends, band / bandwidth / mode, baseline, cable type / length, calibration settings, traces and installation observations.
Changes and substitutions tried, their results, current configuration, working boundary, missing tools / access and the next support action needed.

Fault record

Use your incident log, or print this space for field notes. This page does not store incident details.

UTC date / time and operator

System / location and incident reference

Symptom and last working state

Check reached and expected result

Before / after readings, units and test setup

Change / substitution and result

Verification operation and observation period

Open / resolved, handover owner and next action

Technical references

The decision sequence combines the references below. Product examples explain the method; use the manual for your deployed equipment to set acceptance limits.

Reference content: revision 1, 15 September 2026. Generic source-reviewed guidance; use site and equipment-specific procedures for actual work.