Linux Networking Fundamentals

What Handles Networking on Linux?

Networking is implemented inside the kernel’s network stack; user-space tools (ip, curl, ss) just configure it or open sockets through it via system calls.

Interfaces & IP Addressing

ip addr show           # modern replacement for ifconfig
ip a                    # short form

ip link show            # interface state (up/down), MAC address
ip route show            # routing table
ip route get 8.8.8.8      # which route/interface would be used to reach a destination

sudo ip addr add 192.168.1.50/24 dev eth0   # assign an IP (temporary, non-persistent)
sudo ip link set eth0 up

DNS Resolution

cat /etc/resolv.conf      # configured DNS servers
cat /etc/hosts             # static hostname → IP overrides, checked BEFORE DNS
cat /etc/nsswitch.conf     # order of resolution sources (files, dns, etc.)

dig example.com             # detailed DNS query
nslookup example.com
getent hosts example.com    # resolve exactly as the system's resolver would

/etc/hosts is checked first for most tools — a stale entry there silently overrides real DNS, a classic source of “it works on my machine, not in the container.”

Sockets & Ports

ss -tulnp                 # modern replacement for netstat: TCP/UDP listeners, with PIDs
ss -tan state established  # established TCP connections

# Which process is listening on port 8080?
sudo ss -ltnp | grep :8080
sudo lsof -i :8080

Routing Basics

ip route show default        # default gateway
traceroute example.com        # hop-by-hop path to a destination
mtr example.com                # continuous traceroute + packet loss stats (great for flaky links)

Firewalls: iptables / nftables / firewalld

sudo iptables -L -n -v              # list current rules (legacy but still common)
sudo nft list ruleset                # nftables (modern replacement) equivalent
sudo firewall-cmd --list-all         # firewalld (RHEL/CentOS front-end)

# Allow inbound traffic on port 443
sudo iptables -A INPUT -p tcp --dport 443 -j ACCEPT

Docker and Kubernetes manipulate iptables/nftables rules directly to implement container networking (NAT, port publishing) — this is why “my container port is published but unreachable” is often a firewall/iptables ordering issue, not an application bug.

Testing Connectivity

ping -c 4 8.8.8.8                 # ICMP reachability (often blocked by firewalls — absence isn't proof of an outage)
curl -v https://api.example.com   # full request/response with connection details
curl -o /dev/null -s -w "%{http_code} %{time_total}\n" https://example.com
nc -zv host 443                    # quick TCP port-open check
telnet host 443                     # older alternative to nc for the same check

Production Considerations

• Always check /etc/hosts before assuming a DNS problem — stale entries there are invisible to dig but affect real application traffic.
• ping failing doesn’t prove an outage — ICMP is frequently blocked while TCP/UDP application traffic flows fine; use curl/nc for real service checks.
• On container hosts, iptables/nftables rule ordering managed by Docker/Kubernetes can conflict with manually-added firewall rules — prefer the orchestrator’s native network policy mechanisms over manual iptables edits.

Quick Interview Answer

“Linux networking is implemented in the kernel’s network stack, with tools like ip and ss used to configure interfaces/routes and inspect sockets. DNS resolution checks /etc/hosts before actual DNS per /etc/nsswitch.conf. ss -tulnp shows listening ports and owning processes, and ping isn’t a reliable service-health check since ICMP is often blocked — curl or nc against the actual port is more reliable.”

Common Mistakes

• Diagnosing “site down” purely with ping, when ICMP is blocked but HTTP works fine (or vice versa).
• Forgetting /etc/hosts can override DNS silently, especially inside containers where a base image sometimes ships a stray entry.
• Using deprecated ifconfig/netstat instead of their modern replacements ip and ss, which are now standard on most distros.