Backend Engineering · Field guide 07
Networking and Packet Routing
Follow a packet from local signals to routed delivery, and explain the evidence behind every next-hop decision. This chapter connects protocol behavior to the decisions a production service must make.
01 / Networking
From a signal to a frame
A cable carries changing signals. A network interface turns those signals into a message it can accept or discard.
Our fictional client is 192.0.2.10/24. Its request for https://docs.example/networking starts as application data, but one local transmission requires a link-layer envelope. The documentation addresses in this chapter are reserved examples, not destinations to probe.
For Ethernet, the destination MAC identifies a recipient on this link. The receiver checks the frame and its destination before delivering the enclosed protocol payload. A valid frame is evidence of one local delivery, not proof that an application received a request.
- 01Signal
A medium carries encoded bits.
- 02Frame
The link envelope identifies local recipients.
- 03NIC check
Integrity and destination decide acceptance.
- 04Payload
IP receives the accepted network packet.
Read diagram as text
A physical signal is decoded into frame bits. The NIC checks the envelope. A valid accepted frame delivers its payload to the indicated protocol.
| Observation | Interpretation |
|---|---|
| Signal | Electrical, optical, or radio encoding on a medium |
| Frame | Destination MAC, source MAC, protocol identifier, payload, integrity check |
| NIC decision | Accept a relevant unicast, subscribed multicast, or broadcast frame; discard invalid or unrelated traffic |
02 / Networking
Hubs flood; switches learn
A switch learns where a sender lives by observing the source address of an arriving frame.
Imagine the client on port A, a peer on port B, and a gateway on port C. A hub repeats incoming signaling toward the other ports. A learning bridge instead records the source MAC and ingress port, then consults its forwarding database for the destination.
Known unicast can go to one port. An unknown unicast destination is flooded within the applicable VLAN, excluding the ingress port. Learning reduces unnecessary delivery, but it does not turn a MAC address into an Internet-wide location.
| Observation | Interpretation |
|---|---|
| Client sends on A | Learn client MAC → A |
| Peer replies on B | Learn peer MAC → B |
| Known peer destination | Forward toward B |
| Unknown destination or broadcast | Flood eligible ports in this broadcast domain |
| Hubs and switches · 1. Two interfaces can exchange one local frame | A frame carries a source MAC, a destination MAC, and payload across one physical or wireless link. In this unicast example, B accepts a valid frame addressed to B; interfaces can also accept relevant multicast and broadcast frames. Layer 2 delivers between adjacent interfaces; it does not promise a global path. Frame: A → B; Decision: B accepts |
| Hubs and switches · 2. A hub repeats the signal to every other port | The hub has no destination table. It reproduces the incoming signal on every port except the one where it arrived. Every attached interface sees the frame, even though only B needs it. Forwarding: Flood all ports; Useful copies: 1 of 3 |
| Hubs and switches · 3. A switch learns from the source of arriving frames | When A sends a frame into port 1, the switch records that source MAC A is reachable through port 1. Learning uses the source, not the destination. The forwarding table is learned evidence and can age out. Learned: MAC A → port 1; Destination: Still unknown |
| Hubs and switches · 4. A known destination uses one switch port | After B has also transmitted, the switch knows B is on port 5. A frame for B is forwarded only to that port. Selective forwarding reduces unnecessary local traffic. Lookup: MAC B → port 5; Forward: Port 5 only |
| Hubs and switches · 5. An unknown destination is flooded within the LAN | If the destination MAC is absent from the table, the switch temporarily behaves like a hub and floods the frame inside that broadcast domain. Switching scales a LAN, but unknown destinations still expose the limit of flat addressing. Lookup: No entry; Fallback: Flood local ports |
Design questions
- What changes after the first reply, and what happens when a learned entry ages out?
Primary references
03 / Networking
Why MAC addresses do not describe a global route
A flat identifier tells you which interface, but does not describe a hierarchy of reachable networks.
If every new machine required every distant switch to learn one more individual location, both table state and flooded discovery would grow with the population. Dividing links into broadcast domains limits that local work.
IP prefixes describe sets of destinations. A router can use one aggregate route for many addresses, provided the aggregate correctly represents reachability. More-specific exceptions remain possible; summarization is a routing claim, not a promise that every address inside it is currently alive.
| Observation | Interpretation |
|---|---|
| Flat MAC learning | Per-address location learned from local traffic |
| Broadcast boundary | Discovery stays inside its link or VLAN |
| IP prefix | A leading-bit pattern represents a destination set |
| Aggregation | Several compatible destination sets can share one announcement |
Primary references
04 / Networking
Read an IPv4 prefix as a bit boundary
192.0.2.10/24 means that the first 24 bits identify the configured network prefix.
For this /24 example, the mask is 255.255.255.0. Applying it to both 192.0.2.10 and 192.0.2.20 produces 192.0.2.0. Applying it to 203.0.113.42 produces a different network value.
The dot between octets is formatting, not a routing boundary. A /25 splits the final octet too. Always compare masked unsigned values rather than comparing address strings or assuming all subnets are /24.
| Observation | Interpretation |
|---|---|
| Address | 192.0.2.10 = 11000000 00000000 00000010 00001010 |
| /24 mask | 11111111 11111111 11111111 00000000 |
| Address AND mask | 11000000 00000000 00000010 00000000 |
| Host bits | The remaining eight bits vary within this prefix |
| Subnets and next hops · 1. An IP prefix groups destinations into a network | The prefix length says how many leading bits identify the network. In 192.0.2.0/24, the first 24 bits describe the destination group. Hierarchical prefixes let one route stand for many hosts. Network: 192.0.2.0/24; Host bits: 8 |
| Subnets and next hops · 2. The mask exposes the network portion | Apply 255.255.255.0 to 192.0.2.10 and the result is 192.0.2.0. Apply it to 192.0.2.42 and the result is the same. Equal masked networks mean the destination is directly reachable on this link. 192.0.2.10 AND /24: 192.0.2.0; 192.0.2.42 AND /24: 192.0.2.0 |
| Subnets and next hops · 3. A different prefix requires a next hop | The destination 203.0.113.42 does not belong to 192.0.2.0/24, so the client cannot resolve the server directly on its local link. Remote delivery begins by finding an adjacent router. Client network: 192.0.2.0/24; Server network: 203.0.113.0/24 |
| Subnets and next hops · 4. The default gateway is a local neighbor | The client selects 192.0.2.1 as its next hop. That gateway must itself be reachable on the client's local subnet. A host chooses the next hop, not every router in the path. Destination: 203.0.113.42; Next hop: 192.0.2.1 |
Design questions
- Would 192.0.2.10/25 and 192.0.2.200 fall in the same prefix?
Primary references
05 / Networking
Choose direct delivery or a next hop
The host chooses a route before it decides which neighbor MAC to resolve.
A connected route covers 192.0.2.0/24. A packet for 192.0.2.20 can therefore be delivered directly on that link. The remote documentation server, 203.0.113.42, requires another route; in this example the default sends it through 192.0.2.1.
The gateway must itself be reachable on the selected link. Sending toward a next hop does not change the IP destination into the gateway address. It changes the recipient of the local envelope.
| Observation | Interpretation |
|---|---|
| 192.0.2.20 | Connected route; resolve the peer |
| 203.0.113.42 | Default route; resolve 192.0.2.1 |
| No connected or default match | No route; do not invent a next hop |
Primary references
06 / Networking
ARP resolves the local neighbor
For the remote request, the client asks for the gateway’s MAC, not the documentation server’s MAC.
A valid neighbor-cache entry can avoid an exchange. On a miss, the client broadcasts an ARP request on its link. The owner of the requested IPv4 address replies with its link-layer address, allowing the client to update its neighbor mapping and send the waiting frame.
The broadcast does not cross an ordinary router. A router repeats resolution on its own outgoing link when necessary. ARP belongs to this IPv4 Ethernet example; IPv6 uses Neighbor Discovery rather than ARP.
| Observation | Interpretation |
|---|---|
| Cache hit | Use the existing neighbor mapping |
| Cache miss | Who has 192.0.2.1? Tell 192.0.2.10 |
| Reply | 192.0.2.1 identifies its MAC |
| Remote destination | IP destination remains 203.0.113.42 |
| ARP and neighbors · 1. The neighbor cache has no gateway entry | The route points at 192.0.2.1, but Ethernet still needs a destination MAC. The client checks its neighbor cache first. Routing selects an IP next hop; ARP supplies the local-link address. Neighbor: 192.0.2.1; Cache: Miss |
| ARP and neighbors · 2. ARP asks every device on the local broadcast link | The client broadcasts: who has 192.0.2.1? Switches keep that request inside the LAN and routers do not forward it as an Internet query. ARP is local by design. Destination MAC: ff:ff:ff:ff:ff:ff; Question: Who has 192.0.2.1? |
| ARP and neighbors · 3. The gateway replies in this trusted example | The gateway answers with its MAC address and directs the reply back to the client. The reply supplies a claimed neighbor mapping. ARP does not authenticate its sender. 192.0.2.1: 02:00:00:00:01:01; Delivery: Unicast reply |
| ARP and neighbors · 4. The client stores the mapping temporarily | The neighbor entry lets later frames avoid another broadcast until the entry ages or becomes invalid. Neighbor state is a cache, not permanent truth. State: Reachable; Entry: 192.0.2.1 → 02:…:01:01 |
| ARP and neighbors · 5. A remote server never receives this ARP request | For 203.0.113.42, the client uses the gateway's MAC in the Ethernet frame while keeping the server's IP in the enclosed packet. Resolve the next hop on this link, not the final destination across the Internet. Frame destination: Gateway MAC; Packet destination: 203.0.113.42 |
07 / Networking
Keep the layers separate
One application intent can travel through different transport choices while routers still forward IP packets.
HTTP/1.1 and HTTP/2 commonly use TCP; HTTP/3 uses QUIC over UDP. Encryption and transport add their own structure. The diagram is a boundary model, not a claim that readable HTTP headers appear inside every observed packet.
Explore the lab below to compare link delivery, prefix decisions, neighbor resolution, protocol layers, routed delivery, route repair, Internet reachability, and operational evidence. Every state is fictional and deterministic; nothing inspects your machine.
| Observation | Interpretation |
|---|---|
| Application | Document request bytes and application meaning |
| Transport | TCP stream segments or UDP datagrams |
| Network | IP source, destination, and lifetime |
| Link | Ethernet addresses for this hop |
| Physical | Signals carrying encoded frame bits |
| Protocol layers · 1. Application data starts without network envelopes | The application produces bytes for a request. Lower layers have not yet added ports, IP addresses, MAC addresses, or link signals. Application meaning and delivery mechanics are separate concerns. Payload: GET /networking; Layer: Application |
| Protocol layers · 2. TCP can carry a reliable byte-stream conversation | TCP adds ports, sequence information, acknowledgements, and connection state before IP carries the segment. TCP is one transport choice, not the definition of networking. Transport: TCP; Unit: Segment |
| Protocol layers · 3. UDP can carry a message without TCP connection state | UDP adds source and destination ports with a compact header. IP routing works the same way whether the payload is TCP, UDP, or another supported protocol. Routers forward IP packets; they do not require every packet to contain TCP. Transport: UDP; Unit: Datagram |
| Protocol layers · 4. IP adds network-layer source, destination, and lifetime | The network layer wraps the transport unit with 192.0.2.10, 203.0.113.42, a protocol identifier, and TTL 64. The protocol field tells the destination which upper layer should receive the payload. Source IP: 192.0.2.10; Destination IP: 203.0.113.42 |
| Protocol layers · 5. Ethernet wraps the packet for one local link | The frame uses the client's MAC as its source and the gateway's MAC as its destination. The remote server IP remains inside. Each envelope answers a different delivery question. Frame destination: Gateway MAC; Packet destination: Server IP |
08 / Networking
Follow a same-subnet delivery
A packet from 192.0.2.10 to 192.0.2.20 does not need the default gateway in this topology.
The connected route selects the local interface. The sender uses its neighbor cache or ARP to learn the peer’s MAC, then sends an Ethernet frame whose IP destination and link destination both identify the peer at their respective layers.
The switch may forward a known unicast directly or flood an unknown one. It does not decrement the IP TTL merely for switching the frame. The peer removes the frame envelope and passes the IP payload to the appropriate transport implementation.
| Observation | Interpretation |
|---|---|
| Host route lookup | 192.0.2.0/24 is connected |
| Neighbor resolution | Resolve 192.0.2.20 |
| Switch forwarding | Use the MAC table or flood eligible ports |
| Destination host | Validate and deliver to the IP/transport stack |
09 / Networking
Replace the envelope at each routed link
The destination IP remains 203.0.113.42 while the Ethernet destination changes from one neighbor to the next.
The first frame targets 192.0.2.1’s MAC. That router receives the frame, removes its link envelope, and selects an outgoing route. In our example it sends toward the adjacent 198.51.100.1 next hop using a new link-layer envelope.
This is ordinary forwarding without NAT or tunneling. Those mechanisms can change addresses or add envelopes and require separate reasoning. A reverse path may follow different routers, so a successful forward lookup alone cannot prove a working conversation.
- Link 1Client to gateway
Resolve 192.0.2.1 and send the local envelope.
- Link 2Router to transit
Decrement TTL and use the next link’s MAC addresses.
- Link 3Last hop to server
Resolve the destination neighbor on its own link.
Read diagram as text
The client frames toward the gateway; the router reframes toward transit; the last router frames toward the server. Without NAT, the remote IP destination remains 203.0.113.42.
| Observation | Interpretation |
|---|---|
| Client link | Source MAC: client; destination MAC: gateway |
| Transit link | Source MAC: outgoing router interface; destination MAC: next hop |
| IP endpoints | 192.0.2.10 → 203.0.113.42, absent translation |
| Lifetime | A router forwarding the packet reduces TTL |
| Routed packet journey · 1. The client targets a server on another subnet | The application has produced a request for 203.0.113.42. The client route table determines that the destination is remote. The packet does not contain a precomputed Internet path. Source: 192.0.2.10; Destination: 203.0.113.42 |
| Routed packet journey · 2. The client selects its local gateway | The default route chooses 192.0.2.1 because no more-specific route exists on the client. The selected next hop is adjacent and can be resolved locally. Route: 0.0.0.0/0; Next hop: 192.0.2.1 |
| Routed packet journey · 3. ARP supplies the gateway's MAC address | The neighbor cache resolves 192.0.2.1 to the router interface's link-layer address. The server's MAC is neither requested nor visible on this link. Neighbor IP: 192.0.2.1; Resolved MAC: 02:…:01:01 |
| Routed packet journey · 4. The first frame reaches the router | The frame targets the gateway MAC while the enclosed packet continues to target 203.0.113.42. One frame ends at the router; the packet journey continues. Frame: Client MAC → gateway MAC; Packet: 192.0.2.10 → 203.0.113.42 |
| Routed packet journey · 5. The router removes the frame and looks up the destination | The router validates the packet and compares the destination with its candidate prefixes. The most-specific matching route chooses the outbound interface. Forwarding is a local table decision repeated at each router. Selected route: 203.0.113.0/24; Interface: eth1 |
| Routed packet journey · 6. The router decrements TTL before transmission | TTL changes from 64 to 63. A zero value causes a discard, preventing a routing loop from continuing forever. TTL is a hop limit, not elapsed time. Before: TTL 64; After: TTL 63 |
| Routed packet journey · 7. A new frame carries the packet across the next link | The router resolves the next neighbor, uses new source and destination MAC addresses, and transmits the packet without changing its destination IP. MAC addresses change by link; the destination IP remains stable. New frame: Outgoing router MAC → next-hop MAC; Destination IP: 203.0.113.42 |
| Routed packet journey · 8. The destination removes each envelope | The server interface accepts the frame, IP selects the upper-layer protocol, and the transport layer delivers the application bytes to the listening process. Decapsulation reverses the sender's wrapping order. Destination: Reached; Application: Request delivered |
10 / Networking
Treat forwarding as a sequence of checks
A router does not need to understand the document request to select the next link.
An incoming IPv4 packet must survive header and forwarding checks. A packet whose lifetime expires cannot be forwarded indefinitely. The router uses destination reachability, resolves the outgoing neighbor if necessary, and constructs the next frame.
The IP header checksum changes when TTL changes. A missing route, neighbor-resolution failure, or policy rejection can stop delivery at different boundaries. These are different failures even if the application eventually reports the same timeout.
| Observation | Interpretation |
|---|---|
| Receive | Validate frame and IPv4 header |
| Lifetime | Drop when forwarding would expire TTL |
| Lookup | Select an eligible destination route |
| Neighbor | Resolve the selected adjacent recipient |
| Transmit | Create a fresh link envelope |
11 / Networking
Read the route fields before guessing
The route table describes what this node will try next, not a complete map of the Internet.
A route identifies a destination prefix and forwarding information. Connected entries describe attached networks. Static configuration or routing protocols can supply other entries. A host route describes one address; a default is the least-specific fallback.
The worked selector below compares prefix length and then metric among equally specific eligible routes. Real systems also apply policy and route-source preference. Do not compare metrics from unrelated protocols as though they were one universal distance.
| Observation | Interpretation |
|---|---|
| 192.0.2.0/24 · connected | Directly attached, eth0, metric 0 |
| 203.0.0.0/16 · learned | Via adjacent transit neighbor, eth1, metric 20 |
| 203.0.113.0/24 · static | More-specific destination set, eth1, metric 50 |
| 203.0.113.42/32 · host | One destination; most specific |
| 0.0.0.0/0 · default | Fallback only when no more-specific route applies |
12 / Networking
Longest matching prefix wins
A /32 host route beats a matching /24, even when the /24 has a lower metric.
Mask the destination and each route prefix, keep matching candidates, and select the greatest prefix length. If equally specific candidates remain, this educational selector chooses the smallest metric. With no candidate, it returns a typed no-route result.
The executable model validates canonical IPv4 input, rejects invalid masks, bounds the route count, and uses unsigned arithmetic. Tests cover /0, /32, high-bit addresses, overlap, ties, and no-route outcomes.
// Educational selection over already validated routes
const matches = routes.filter(route => matchesPrefix(destination, route));
const selected = matches.sort((a, b) =>
b.prefixLength - a.prefixLength || a.metric - b.metric
)[0];
// No selected route means no-route; never invent a default.| Observation | Interpretation |
|---|---|
| Destination | 203.0.113.42 |
| Matching lengths | /0, /16, /24, /32 |
| Selected | /32, regardless of a less-specific route’s metric |
| Two /32 entries | Use the smaller metric in this simplified model |
Primary references
13 / Networking
Repair a missing specific route
A default route can be valid for Internet traffic and wrong for a local container network.
Our second topology places an application host at 192.0.2.20 and a database behind its 198.51.100.0/24 bridge. The workstation’s ordinary gateway is 192.0.2.1. Without a specific route, database traffic goes to that ordinary gateway instead of the application host.
A route for 198.51.100.0/24 via 192.0.2.20 repairs this next-hop choice. It does not automatically enable forwarding, open a firewall, or create a return path. Verify those boundaries separately before calling the repair complete.
| Observation | Interpretation |
|---|---|
| Before | 198.51.100.42 follows default via 192.0.2.1 |
| Specific route | 198.51.100.0/24 via 192.0.2.20 |
| Forwarding host | 192.0.2.20 must forward between its interfaces |
| Return path | The database must be able to reach 192.0.2.10 |
| Route repair · 1. Start with the routes the host already knows | The workstation knows its connected 192.0.2.0/24 network and an ordinary default route. It has no specific knowledge of the application host's 198.51.100.0/24 container bridge. Read the table before changing it. Target network: 198.51.100.0/24; Specific route: Missing |
| Route repair · 2. The default route sends the packet the wrong way | Because no specific route matches, the workstation sends the packet to 192.0.2.1. That gateway has no path to the private lab network, so the packet is dropped. A reachable host does not imply that every network behind it is reachable. Selected: 0.0.0.0/0; Outcome: No route beyond gateway |
| Route repair · 3. Add a specific route through the dual-homed host | The intended route sends 198.51.100.0/24 through 192.0.2.20, an adjacent host that has an interface on both networks and forwarding enabled. The next hop must be locally reachable. Destination: 198.51.100.0/24; Via: 192.0.2.20 |
| Route repair · 4. The new route reaches the container network | The workstation sends the packet to the application host, which looks up 198.51.100.42 on its connected bridge and forwards it to the database container. A specific route outranks the default route. Selected: 198.51.100.0/24; Outcome: Forwarded to database |
| Route repair · 5. The return path must also be valid | The database uses 198.51.100.1 as its gateway. The application host already knows 192.0.2.0/24 through its other interface, so the reply can return to the workstation. Always validate both directions; routing state need not be symmetric. Reply route: 192.0.2.0/24 connected; Result: Return verified |
Design questions
- Which observation would distinguish a missing route from a blocked forwarding policy?
Primary references
14 / Networking
Separate reachability learning from forwarding
BGP exchanges reachability information; it does not accompany each application packet through the network.
DHCP supplies host configuration such as an address lease. OSPF distributes intra-domain link-state information used to compute routes. BGP exchanges inter-domain reachability and path attributes under routing policy. These systems affect the state from which forwarding decisions are made.
Imagine documentation prefix 203.0.113.0/24 advertised by one fictional autonomous system through a transit domain to another. Once suitable routes are installed, each router chooses its local next hop. Policy can prefer a path that is not the shortest physical route.
| Observation | Interpretation |
|---|---|
| DHCP | Host configuration |
| OSPF | Link-state routing within a domain |
| BGP | Reachability and policy between routing domains |
| Forwarding plane | Per-packet decision using installed state |
| Internet reachability · 1. A home route starts the journey | The client sends a remote destination to its home gateway. DHCP may have supplied the address, prefix, and default gateway, but it does not forward this packet. Configuration protocols contribute state; forwarding consumes it. Installed by: DHCP or static config; Used by: Local forwarding lookup |
| Internet reachability · 2. An interior protocol shares paths within one organization | An ISP can use OSPF to calculate paths between its own routers and install the resulting routes in their tables. OSPF updates routing state inside an autonomous system. Scope: Inside one AS; Result: Routes installed |
| Internet reachability · 3. BGP advertises reachability between autonomous systems | One AS advertises the prefixes it can reach. A neighboring AS applies policy and may install a route with an adjacent next hop. BGP exchanges reachability; it does not carry each application packet. Scope: Between ASes; Evidence: Prefix advertisement |
| Internet reachability · 4. Every router still makes its own local decision | When traffic arrives, each router performs a local lookup and forwards to one adjacent next hop. The packet does not know the complete AS path. The control plane builds tables; the forwarding plane uses them packet by packet. Decision: Local next hop; Repeated: At every router |
15 / Networking
Compare a route repair before and after
Use the fictional transcript to explain the change before attempting anything on a real system.
The commands below are documentation only. They are not executed by the site. They describe routed access to a bridge subnet; publishing a container port on a host is a different access path and may involve translation.
After the specific route changes, inspect the application host’s forwarding policy and the database’s return route. A source-preserving routed design and a masqueraded design can produce different packet captures while both appearing to reach the same service.
# Fictional Linux lab: preview only
ip route get 198.51.100.42
# Before: via 192.0.2.1 dev eth0
# Proposed change inside the isolated fictional lab:
ip route add 198.51.100.0/24 via 192.0.2.20
ip route get 198.51.100.42
# After: via 192.0.2.20 dev eth0
# On the database, inspect the reverse path too:
ip route get 192.0.2.10| Observation | Interpretation |
|---|---|
| Workstation | 192.0.2.10/24 |
| Application host | 192.0.2.20/24 and 198.51.100.1/24 |
| Database | 198.51.100.42/24, gateway 198.51.100.1 |
| Required evidence | Forward route, forwarding enabled, permitted policy, reply route |
Primary references
16 / Networking
Ask one question of each observation
A timeout is an application symptom. Work backward to the first boundary with missing evidence.
Capture both directions at a known interface in an authorized lab. A SYN leaving one interface proves that observation point saw it; it does not prove the peer accepted it. No packet in a capture may mean the capture filter or interface is wrong. Separate absence of evidence from a demonstrated drop.
Likewise, a successful ping does not prove that a TCP port, TLS negotiation, or HTTP route works. Traceroute depends on replies that routers may filter or rate-limit. Record the question, observation point, expected evidence, and remaining uncertainty.
# Fictional capture at the workstation, before route repair
12:00:00 eth0 OUT Ethernet dst=gateway MAC
IPv4 192.0.2.10 → 198.51.100.42 TTL=64 TCP 51000 → 5432 SYN
# The IP destination is correct, but the local frame targets the wrong gateway.
# After selecting the specific route via 192.0.2.20:
12:01:00 eth0 OUT Ethernet dst=application-host MAC
IPv4 192.0.2.10 → 198.51.100.42 TTL=64 TCP 51000 → 5432 SYN
# A capture on the forwarding host's bridge sees TTL=63 and a new frame.
# SYN-ACK returning to the workstation supports a working TCP return path.
# It does not establish database authentication or query success.| Observation | Interpretation |
|---|---|
| ip address / ip link | Address configuration and link state |
| ip route get DEST | Selected next hop and outgoing interface |
| ip neigh | Neighbor resolution state |
| ping / traceroute | Reachability or responding hops, with filtering caveats |
| ss | Local sockets and their state |
| curl | Application-level response and transport/TLS symptoms |
| Packet capture | Packets visible at this interface and filter |
| Observe and debug · 1. Begin with interface and address state | Use `ip link` to inspect interface state and `ip address` to inspect assigned addresses and prefixes. Prove the local foundation before blaming a remote network. Question: Is the interface up and addressed?; Commands: ip link · ip address |
| Observe and debug · 2. Inspect local neighbor resolution | Use `ip neigh` when a route is correct but the adjacent next hop cannot be reached on the link. A neighbor failure and a route failure are different boundaries. Question: Can the next hop resolve?; Command: ip neigh |
| Observe and debug · 3. Ask which route the kernel would select | Use `ip route` and a destination-specific route lookup to inspect the chosen prefix, next hop, source address, and interface. The selected route is stronger evidence than assumptions about the default gateway. Question: Where will this destination go?; Command: ip route get 203.0.113.42 |
| Observe and debug · 4. Escalate from local state to path and application evidence | Use ping carefully for reachability, traceroute for TTL-limited path observations, `ss` for local sockets, `curl` for HTTP behavior, and packet capture to correlate headers with the model. Each tool answers a narrower question; none alone proves the whole network. Path: traceroute · capture; Application: ss · curl |
Design questions
- A request leaves the workstation but no reply returns. What would you inspect on the forwarding host and database before changing the application?