3.3Network Troubleshooting

"It doesn't connect" demands very different responses depending on whether it is name resolution failing, loss somewhere along the path, or the interface itself misbehaving. Combine config files like hostname and /etc/resolv.conf, path tracing with traceroute/mtr, and corroboration from dmesg and logs to isolate the cause.

3.3.1Hostname and name resolution

• hostname displays or temporarily changes the current hostname. Persist it in /etc/hostname (on many distributions, via systemd-hostnamed and hostnamectl).
• /etc/hosts is a static IP-to-hostname table, typically consulted before DNS. A stale or wrong entry here surfaces as a name-resolution symptom.
• /etc/resolv.conf holds DNS client settings (nameserver lines list DNS servers to query). Under NetworkManager it can be auto-generated and overwritten, so manual edits may unexpectedly vanish.
• nmcli and ip also help isolate resolution issues (nmcli device show for DNS settings, ip addr for interface state).

3.3.2Path tracing and log corroboration

• traceroute/traceroute6 show each hop to the destination, pinpointing where delay or loss occurs. mtr combines traceroute and ping to continuously monitor per-hop loss rate and latency.
• dmesg shows the kernel message buffer (useful for corroborating link drops or NIC driver errors). /var/log/syslog//var/log/messages are the system log locations depending on distribution family; on systemd systems the journal (journalctl) is central.
• NetworkManager is the standard connection-management daemon on many distributions. Legacy config trees: /etc/network/ (Debian-family interfaces file) and /etc/sysconfig/network-scripts/ (RHEL-family ifcfg-* files). Note that the config location differs by distribution family.

Walk through the standard triage for "I can't reach this one site." First suspect name resolution: if ping <domain> fails but ping <the IP directly> succeeds, it is a name-resolution problem. Check /etc/hosts for a wrong entry for that domain (it is consulted first, so an entry there causes an immediate symptom); if clean, check whether /etc/resolv.conf's nameserver lines point at the right DNS server. Under NetworkManager, the DNS settings on a managed connection can drift from what actually landed in the file, so cross-check nmcli device show <if> against /etc/resolv.conf. If name resolution is fine, suspect the path: traceroute <destination> pinpoints the hop where responses stop. For suspected intermittent loss (e.g., slow only at certain times), monitor continuously with mtr, which statistically identifies the hop with the highest loss rate. Always corroborate these findings: a physical NIC issue (link flapping, etc.) shows up in the kernel log via dmesg, and on systemd systems journalctl -u NetworkManager traces NetworkManager's own behavior (reconnection attempts, failure reasons). On legacy distributions (non-systemd, not using NetworkManager), grepping /var/log/syslog or /var/log/messages plays the same role, and you must track which distro family's config location applies: /etc/network/interfaces (Debian family) or /etc/sysconfig/network-scripts/ifcfg-eth0 (RHEL family).

3.3.3Section summary

• Check name resolution in order: /etc/hosts (static, priority) → /etc/resolv.conf (DNS; may be overwritten by NetworkManager)
• Path: traceroute/traceroute6 (single-pass hop location) / mtr (continuous monitoring). Corroborate with dmesg, journalctl (systemd) / syslog, messages (non-systemd); config file location differs by distro family