CompTIA XK0-006: Linux Networking from ip to ss

Linux networking becomes much easier to troubleshoot when the administrator stops treating the network stack as one black box. The `ip` family of commands exposes interfaces, addresses, routes, and neighbors; `ss` exposes sockets and the processes using them. Together they answer the first questions that matter when a service cannot communicate: does the host have the expected interface and address, is there a route to the destination, can the kernel resolve the next hop, and is the application actually listening where the client expects it?

For administrators following XK0-006, these tools are useful because they map directly to ordinary system behavior. The broader Linux administration approach is to inspect state before changing it. A working network path is a chain of independent decisions—link, address, route, neighbor, firewall, socket, name resolution, and remote service—and each can be verified with evidence.

Begin with interface state and addressing

Start with `ip link` and `ip addr` rather than assuming that a configured interface is usable. Link state tells you whether the kernel sees the interface as up, while address output shows which IPv4 and IPv6 addresses are actually assigned. A configuration file can be correct and still not represent current runtime state if a service failed, a device name changed, a cable is disconnected, or a network manager has not applied the expected profile.

Look at prefix length as well as the address. A host with the right-looking IP but the wrong prefix can treat a remote system as local, issue neighbor discovery or ARP instead of using a gateway, and fail in ways that resemble a routing problem. The same reasoning behind subnetting applies on Linux: the prefix determines which destinations are considered directly connected.

If an interface has several addresses, identify which one the kernel is likely to use as a source for the destination you are testing. Multi-homed hosts, VPNs, containers, and management interfaces can create valid addresses that are wrong for a particular path. That is why interface inspection should come before a generic `ping` test.

Read routes as forwarding decisions

`ip route` shows the kernel’s routing table. Connected routes normally appear when addresses are assigned, while default and more-specific routes come from static configuration, DHCP, routing software, VPN clients, or other network components. The best way to read the table is to ask which route has the most specific matching prefix for the destination. The default route is only used when no more-specific route applies.

`ip route get` is especially useful because it asks the kernel how it would reach a particular destination. The result can show the selected interface, next hop, and source address without sending traffic. On a server with multiple interfaces, policy routing, or tunnels, that single command can expose why the actual path differs from what the administrator assumed.

The companion explanation of routing tables is useful when troubleshooting Linux because the operating system is making the same longest-prefix decisions as a router. If the selected route is wrong, fix the route or the configuration that produced it rather than attempting to repair the application.

Check neighbor resolution before blaming the gateway

For destinations on a directly connected subnet, the host still needs a link-layer neighbor entry. `ip neigh` shows ARP state for IPv4 and neighbor-discovery state for IPv6. Entries can be reachable, stale, incomplete, failed, or in other states depending on recent traffic and kernel behavior. An incomplete or failed neighbor for the default gateway is a very different problem from a valid gateway entry followed by remote packet loss.

If a neighbor cannot be resolved, investigate local link and VLAN placement, switch configuration, duplicate addressing, or the remote device itself. Repeatedly adding static routes will not solve a Layer 2 reachability problem. In virtualized and containerized systems, also make sure you are looking at the correct network namespace because each namespace can have its own interfaces, routes, and neighbors.

A packet capture can make this stage obvious. If the host repeatedly sends ARP requests or IPv6 neighbor solicitations and receives nothing, the failure is local to the link or adjacent device. The broader guide to packet captures shows how to use that evidence without collecting more traffic than the question requires.

Use ss to prove what applications are doing

Once the network path looks plausible, inspect sockets. `ss -lntup` is a common starting point for listening TCP and UDP sockets because it shows local addresses, ports, and—when permissions allow—process information. A service can be running yet listen only on `127.0.0.1`, which makes it unavailable from the network. Another service may listen on IPv6 only, on one interface address, or on a different port than the client expects.

Established sockets reveal whether traffic is making it through. If the server shows a TCP connection from the client, the network path is at least partially working and the investigation can move upward to the application. If SYN packets arrive but no socket is listening, the kernel may reply with a reset. If nothing arrives, continue looking at routing, firewall policy, or upstream forwarding rather than restarting the service blindly.

`ss` also helps distinguish a port conflict from a service failure. When a daemon cannot start because another process already owns the port, the listening socket provides direct evidence. The important habit is to verify the actual socket state rather than trusting what a configuration file says the service should be doing.

Keep DNS separate from basic reachability

Name resolution failures often make a healthy IP path look broken. Check `/etc/resolv.conf`, the system resolver configuration, and the active network manager or resolved service as appropriate for the distribution. Verify which resolver is being queried and whether the name should come from public DNS, an internal zone, a search domain, or a local hosts file. Do not treat `ping hostname` as a pure network test because it includes resolution before any packets are sent.

The article on DNS troubleshooting provides a useful layer-by-layer approach. Test the IP destination directly, then query the expected resolver, then compare the returned records with the application requirement. A server can have perfect routing and still fail to connect because the name resolves to an old address or the wrong address family.

Caching can complicate tests. Applications, local resolver services, browsers, and upstream DNS servers may all retain answers for some period. When evidence appears inconsistent, identify which component is caching and whether the record’s TTL explains the behavior before forcing broad restarts.

Account for firewalls, namespaces, and containers

Linux hosts may enforce packet policy through nftables, iptables compatibility layers, firewalld, or service-specific mechanisms. A route can be correct and a socket can be listening while a firewall still drops the flow. Check counters and rules that actually apply to the interface and direction in question. Avoid disabling the firewall as the first troubleshooting step; that removes evidence and can create a larger problem than the one being investigated.

Containers add more namespaces, bridges, virtual Ethernet pairs, and network-address translation. The guide to container networking explains why host and container views differ. When a service inside a container is unreachable, verify the socket inside the namespace, the container’s route, the host-side bridge or user-space network, and any published-port rule.

VPN clients and policy routing can also send selected traffic through tables other than the ordinary main table. If a route appears correct but `ip route get` returns an unexpected path, inspect `ip rule` and the tables referenced by those rules. The objective is to understand the kernel’s decision rather than forcing another default route into an already complex policy.

Build a repeatable troubleshooting order

A useful sequence is: interface state, address and prefix, selected route, neighbor state, local firewall, listening socket, DNS, then application-specific behavior. The order is not sacred, but it prevents random changes. At each step, form a small question and use the tool that can answer it. If the interface is down, DNS is not the next problem. If the application is not listening, changing the default route is not a meaningful test.

Routine evidence collection can be automated with Bash. A diagnostic script can capture `ip addr`, `ip route`, selected `ip route get` results, `ip neigh`, relevant `ss` output, resolver state, and recent service logs. The script should collect facts rather than make destructive changes, so it remains safe to run during an incident.

The real skill is not memorizing command switches. It is learning what layer each command observes. `ip` explains the kernel’s network configuration and forwarding choices; `ss` explains socket state; resolver tools explain name service; packet captures show what actually crossed an interface. When those views are combined deliberately, Linux networking problems become much more predictable.

Keep a known-good comparison when possible. On a cluster or fleet, compare the failing host’s address, route, neighbor, resolver, firewall, and socket state with a peer that serves the same role. Differences often identify the fault faster than reading configuration in isolation. The comparison is most useful when systems are intentionally standardized, which is another reason to keep network configuration under controlled change rather than one-off manual edits.