Linux CLI Cheat Sheet for Advanced Network Engineers and Architects

Linux is no longer only a server operating system in the corner of the network.

It is the control plane for load balancers, firewalls, Kubernetes nodes, virtual routers, observability collectors, jump hosts, appliances, and cloud instances.

For a network engineer or architect, Linux CLI fluency is not about remembering every flag.

It is about proving how traffic actually behaves from the source that is sending it.

---

Start With the Question

Do not begin with a favorite command.

Begin with the failure boundary.

The fastest engineers do not run more commands.

They ask better questions in the right order.

---

Route Selection

Start with the route Linux will actually choose.

ip route get 203.0.113.10
ip route get 203.0.113.10 from 10.20.30.40
ip route show table main
ip rule show

Read the output carefully.

Use this before traceroute, MTR, packet capture, or firewall review.

If route selection is wrong, every later test is explaining the wrong path.

---

Interfaces, Addresses, and Neighbors

Use ip, not legacy ifconfig and route, as the operational baseline.

ip -br link
ip -br addr
ip -s link show dev eth0
ip neigh show
ip neigh show dev eth0

What to check:

• interface state: UP, LOWER_UP, carrier, errors, drops
• address ownership: expected IPv4, IPv6, secondary IPs, virtual IPs
• neighbor state: REACHABLE, STALE, FAILED, incomplete ARP/ND
• interface counters before and after a test

For same-segment IPv4 checks:

arping -I eth0 192.0.2.1
ip neigh flush 192.0.2.1
ip neigh get 192.0.2.1 dev eth0

For IPv6 neighbor discovery:

ip -6 neigh show
ping -6 ff02::1%eth0

When ARP or Neighbor Discovery is unstable, higher-layer tests become noisy.

Fix adjacency before judging routing or applications.

---

Namespaces, VRFs, and Containers

Modern Linux systems often have more than one network stack.

Kubernetes, containers, service meshes, virtual appliances, and lab routers may all hide the real test point behind a namespace or Virtual Routing and Forwarding (VRF) instance.

ip netns list
ip netns exec blue ip route get 203.0.113.10
ip netns exec blue ss -lntup
ip netns exec blue tcpdump -ni any host 203.0.113.10

For VRF-aware systems:

ip link show type vrf
ip route show vrf CUSTOMER_A
ip vrf exec CUSTOMER_A ip route get 203.0.113.10
ip vrf exec CUSTOMER_A ping 203.0.113.10

Architectural mistake to avoid:

Testing from the host namespace and assuming the container, appliance, or VRF sees the same route table.

That assumption wastes hours in multi-tenant and cloud-edge environments.

---

Sockets and Local Services

Before blaming the network, verify whether the application is listening on the expected address and port.

ss -lntup
ss -ntp state established
ss -s
lsof -nP -iTCP -sTCP:LISTEN

Useful patterns:

For a port test:

nc -vz 203.0.113.10 443
curl -vk --connect-timeout 3 https://example.com/
openssl s_client -connect example.com:443 -servername example.com

Use nc for quick TCP reachability, curl for HTTP behavior, and openssl for Transport Layer Security (TLS) certificate and handshake evidence.

---

DNS and Resolver Path

DNS failure often looks like application failure.

Check both the answer and the resolver path.

resolvectl status
resolvectl query app.example.com
dig app.example.com
dig @8.8.8.8 app.example.com
dig +trace app.example.com
getent hosts app.example.com

Use getent when you need to test what the operating system resolver sees, including /etc/hosts, Name Service Switch (NSS), systemd-resolved, LDAP, or other local resolver behavior.

Use dig when you need DNS protocol detail.

Packet capture can confirm whether the host is asking the resolver you think it is asking.

tcpdump -ni any port 53

---

Path, Latency, and MTU

Use path tools to answer path questions, not as generic rituals.

traceroute 203.0.113.10
traceroute -T -p 443 203.0.113.10
tracepath 203.0.113.10
mtr -rwzc 100 203.0.113.10

Interpretation rules:

• ICMP loss on an intermediate hop does not prove forwarding loss.
• TCP traceroute is often more relevant than ICMP when firewalls treat protocols differently.
• tracepath is useful for path Maximum Transmission Unit (MTU) hints.
• MTR is useful for time-based evidence, not a single snapshot.

MTU checks:

ip link show dev eth0
tracepath 203.0.113.10
ping -M do -s 1472 203.0.113.10
ping -M do -s 8972 203.0.113.10

For Ethernet, a 1500-byte IP path usually corresponds to ping -M do -s 1472 for IPv4 because the ICMP payload plus headers must fit inside the MTU.

For jumbo paths, validate every segment.

One 9000-byte interface does not make the path jumbo-safe.

---

Packet Capture That Answers Something

tcpdump should be tied to a claim.

Are packets leaving?

Are replies returning?

Is the source address correct?

Is the firewall resetting?

Is TLS negotiation failing after TCP succeeds?

tcpdump -ni any host 203.0.113.10
tcpdump -ni eth0 'host 203.0.113.10 and tcp port 443'
tcpdump -ni eth0 'tcp[tcpflags] & (tcp-syn|tcp-ack|tcp-rst) != 0'
tcpdump -ni eth0 -s 0 -w change-window.pcap 'host 203.0.113.10'

Capture checklist:

Use ring buffers for longer captures:

tcpdump -ni eth0 -s 0 -C 100 -W 10 -w net.pcap host 203.0.113.10

Do not capture everything on a busy host unless you have a reason and enough disk.

---

Firewall, NAT, and Connection State

On current Linux systems, expect nftables; on older systems, you may still see iptables.

Check what is actually active.

nft list ruleset
iptables-save
ip6tables-save
conntrack -S
conntrack -L | grep 203.0.113.10

For Network Address Translation (NAT) and stateful filtering, packet capture alone may not be enough.

Use connection tracking to confirm state.

conntrack -E
conntrack -L -p tcp --dport 443

Useful questions:

• Was a flow created?
• Was it marked UNREPLIED?
• Was the translated source or destination correct?
• Did the return packet match the existing state?
• Did asymmetric routing bypass the stateful device?

Architectural rule:

If the design depends on stateful inspection, the forward and return path must agree with that state boundary.

Linux will show you when they do not.

---

Logs and Kernel Signals

When the network path looks correct but behavior is still wrong, inspect kernel and service signals.

journalctl -k --since "10 minutes ago"
journalctl -u NetworkManager --since "10 minutes ago"
journalctl -u systemd-networkd --since "10 minutes ago"
dmesg -T | tail -100

For packet drops and kernel network counters:

ip -s link show dev eth0
nstat -az
netstat -s
ethtool -S eth0

For device and driver state:

ethtool eth0
ethtool -k eth0
ethtool -i eth0

Offload features can affect packet capture interpretation.

If a capture looks impossible, check checksum offload, Generic Segmentation Offload (GSO), Generic Receive Offload (GRO), and Large Receive Offload (LRO) before assuming the wire looks the same as the capture.

---

Change Validation Chains

For real operations, a cheat sheet is only useful when it becomes a repeatable validation chain.

New route or firewall path

ip route get 203.0.113.10
ip rule show
nc -vz 203.0.113.10 443
tcpdump -ni any 'host 203.0.113.10 and tcp port 443'
conntrack -L | grep 203.0.113.10

DNS cutover

dig old.example.com
dig new.example.com
dig @authoritative.example.net new.example.com
getent hosts new.example.com
curl -vk --resolve new.example.com:443:203.0.113.10 https://new.example.com/

MTU-sensitive application

ip link show dev eth0
tracepath 203.0.113.10
ping -M do -s 1472 203.0.113.10
tcpdump -ni eth0 'icmp or host 203.0.113.10'

Suspected asymmetric routing

ip route get 203.0.113.10
tcpdump -ni eth0 host 203.0.113.10
tcpdump -ni eth1 host 203.0.113.10
conntrack -L | grep 203.0.113.10

You are trying to prove the path, state, and protocol from the exact point of failure.

That is what turns Linux from a command shell into an architecture validation tool.

---

Production Safety

Advanced CLI work can create outages if it is careless.

Use these guardrails:

• Prefer read-only inspection commands during incident triage.
• Capture with filters, size limits, and rotation.
• Avoid flushing neighbors, routes, connection tracking, or firewall rules without a rollback path.
• Record the source namespace, VRF, interface, timestamp, and command used.
• Save before-and-after evidence for change windows.
• Treat one host's view as evidence, not universal truth.

For destructive or disruptive commands, write the rollback first.

This applies to route changes, firewall changes, namespace changes, interface resets, and connection-state clearing.

---

The Bottom Line

For advanced network engineers and architects, Linux CLI skill is not command trivia.

It is the ability to prove route selection, resolver behavior, socket state, packet movement, firewall state, and application behavior from the host that is actually participating in the flow.

That evidence is what separates a clean diagnosis from a confident guess.