Networking Mental Model: How a Packet Reaches Production
Build the end-to-end networking mental model a DevOps, SRE, and cloud engineer uses to reason about application traffic and failures.
বাংলা অনুবাদ এখনো নেই, ইংরেজি দেখানো হচ্ছে।
Computer networking becomes easier when you stop memorizing protocols and start following one packet from a client to a service and back.
A production request rarely travels directly from a browser to an application process. It may cross DNS, local routing, NAT, internet routers, a CDN, a firewall, a load balancer, Kubernetes networking, a Service, a Pod, and finally an application socket.
Text
User / Client
↓ DNS lookup
Resolved IP / CDN / Edge
↓
Internet / private WAN
↓
Firewall / WAF / Load Balancer
↓
VPC / VNet routing
↓
VM / Kubernetes Node
↓
Container / Pod network
↓
Application socket :PORT
↓
Database / cache / API dependency
The five questions behind most incidents
When something says "network error", ask these in order:
Name: Did the client resolve the right destination?
Think DNS, search domains, service discovery, stale records, split-horizon DNS.
Route: Does a path exist to the destination?
Think subnet, route table, gateway, VPN, peering, NAT, default route.
Listener: Is something listening on the expected IP and port?
Think ss, application bind address, container port, Service targetPort.
Protocol: Can both sides complete the expected protocol?
Think TCP handshake, TLS certificate/SNI, HTTP host/path, database protocol.
Control plane vs data plane
Cloud and Kubernetes networking become much clearer when you distinguish two planes:
Control plane: APIs and controllers define intended networking state: routes, load-balancer listeners, firewall rules, Services, EndpointSlices, DNS records.
Data plane: actual packets traverse NICs, virtual switches, routers, NAT, proxies, kernel networking, CNI datapaths and application sockets.
A control-plane object can look correct while the data plane is broken. That is why production debugging requires both API inspection and packet-path verification.
North-south and east-west traffic
North-south traffic crosses a system boundary, such as internet → application or application → SaaS API. East-west traffic moves between internal workloads, such as API → Redis or frontend → backend.
Modern platforms usually need different controls for each path:
Traffic
Typical controls
Internet → app
DNS, CDN, WAF, LB, ingress/gateway, TLS
App → app
service discovery, routing, NetworkPolicy, service mesh
App → database
private network, firewall, DNS, connection pool
App → internet
default route, NAT/egress gateway, proxy
First commands to build situational awareness
Bash
ip addr
ip route
ss -lntup
cat /etc/resolv.conf
These answer four foundational questions: what addresses do I have, where will packets go, what is listening, and which DNS resolver will I ask?