I85PREP
⌘ K
CTLA study materials
CTLA study resources

CTLA: Networking Fundamentals and Configuration

CTLA · Work through your exam, one topic at a time.

All guide sections

Networking Fundamentals and Configuration

The networking domain tests layered reasoning: can you tell whether a failure is link, address, route, name resolution, listening socket, or policy? CTLA expects fluency with IPv4 addressing and CIDR, the iproute2 toolset, DNS resolution order, and host firewall concepts on current Linux distributions.

Layers and addressing

Encapsulation runs link → internet (IP) → transport (TCP/UDP) → application. IPv4 CIDR: a /24 gives 254 usable hosts (network .0, broadcast .255); private space is 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16. A 169.254.x.x address is link-local and almost always means DHCP failed. A host's gateway must sit inside one of its own configured subnets.

Tools that answer specific questions

  • ip link - is the interface up, does it have carrier?
  • ip addr - is the address present? (ifconfig is deprecated and not installed by default)
  • ip route - is there a default gateway?
  • ip neigh - has ARP/NDP resolved the next hop?
  • ss -lntp - which process listens on which port (replaces netstat).

Name resolution

/etc/nsswitch.conf sets the order - normally files then dns. /etc/hosts is consulted first. /etc/resolv.conf lists nameservers; on systemd-resolved hosts it points at the stub 127.0.0.53, and resolvectl query is the correct diagnostic. dig bypasses nsswitch entirely, so it can succeed while applications still fail.

Configuration and policy

NetworkManager (nmcli connection show, nmcli device status), netplan, or legacy network-scripts depending on distribution. Firewalling is nftables/iptables behind firewalld zones or ufw; a service can be listening locally and still be unreachable because of policy.

Worked example

A server pings 8.8.8.8 successfully but curl https://example.com fails with name resolution errors. Reasoning: ICMP to a literal address proves link, address, and default route are healthy, and that NAT egress works. The failure is above IP, in DNS. Check /etc/resolv.conf for a reachable nameserver, confirm with resolvectl query example.com, then getent hosts example.com (which honours nsswitch) rather than dig. If the nameserver is 127.0.0.53, verify systemd-resolved is running; if resolv.conf is being overwritten, look at the managing service rather than editing the file by hand.

Traps

  • Treating a failed ping as proof the host is down - ICMP is frequently filtered.
  • Editing /etc/resolv.conf on a NetworkManager or resolved host, where it is regenerated.
  • Reasoning from ifconfig output only, missing secondary addresses.
  • Confusing a listening port with an allowed port; the firewall can still drop it.
  • Adding a route with a gateway that is not on-link.