Small Network Traffic Flow

Following One Packet Path

From the user's chair a small network looks trivial: plug in or join Wi-Fi, open a browser, load a site. Underneath, a fixed sequence of services cooperates, and following that order keeps you from guessing.

Step 1 — Join and get an address

The link must come up: on wired Ethernet the NIC and switch port negotiate; on wireless the client associates to the SSID and passes security. The client then needs IP settings. Using DHCP, it broadcasts a Discover in its VLAN, and the server returns address, mask, default gateway, DNS server, and lease (the DORA exchange). If no lease arrives, the client falls back to an APIPA 169.254.x.x address and the path stops here.

Step 2 — Resolve the name

The user types www.example.com. The client asks its configured DNS resolver for the IP. If DNS fails, the user reports "the site is down" even though raw IP connectivity is fine. If it succeeds, the client compares the destination IP to its own IP and mask and finds the public site is remote, so the next hop is the gateway.

Step 3 — Find the gateway MAC with ARP

Before the first frame can leave, the client needs the gateway's MAC. It checks its ARP cache and, if empty, broadcasts an ARP request inside the VLAN. The gateway replies; the client frames the IP packet (destination still the public site) to the gateway's MAC. The switch forwards the frame using its MAC table — to one port if the gateway MAC is known, flooding the VLAN if not.

Step 4 — Route, translate, and connect

The router/firewall strips the Ethernet header, reads the IP packet, and consults its routing table. In a small office it also performs NAT/PAT, swapping the private source for a public address. The transport layer opens the conversation — for HTTPS, a TCP connection to destination port 443 via the three-way handshake. Replies return to the public address; NAT maps them back; the switch delivers the local frame to the client's MAC.

Local Versus Remote, and a Troubleshooting Order

Local traffic takes a shorter path. If a PC prints to a printer in the same VLAN and subnet, it does not use the gateway at all — it ARPs for the printer's MAC and the switch forwards the frames directly. If the printer is in another VLAN, inter-VLAN routing is required and firewall policy may decide whether that traffic is allowed.

Who uses what

Bottom-up troubleshooting order

Following the flow gives a repeatable order that proves each dependency before moving on:

1. Physical / wireless — link light, Wi-Fi association.
2. IP settings — valid address and mask, not APIPA.
3. Default gateway — ping it; success proves local Layer 2/3.
4. DNS — resolve a name (nslookup); compare name versus IP.
5. Application / port — test the specific service (e.g., HTTPS 443).

Then scope the fault: does it affect one host, one VLAN, one service, or the whole site? That scope points straight at the cause — one host suggests the endpoint, one VLAN suggests an access-port or trunk problem, one service suggests DNS/NAT/firewall, and a site-wide outage suggests the gateway or upstream link.

A worked scenario

A user says "no Internet." You find a valid 192.168.10.x address (DHCP fine), a successful ping to 192.168.10.1 (gateway fine), but nslookup www.example.com times out while ping 8.8.8.8 succeeds. The path is healthy through Layer 3; the failure is DNS. Fix or repoint the resolver and the user is back online — no router swap, no cable replacement.

Common traps

• Jumping to the application before proving the link and gateway.
• Replacing hardware before scoping the fault.
• Treating a single-service failure as a whole-network outage.
• Forgetting that same-subnet traffic never touches the gateway.

A Full Dependency Walk and Failure Map

Think of one web request as a chain of dependencies, each of which must succeed before the next is even relevant. If any link breaks, everything downstream appears broken to the user even though it is innocent.

The power of the table is that each row's failure has a distinct signature, so the user's exact complaint usually narrows the cause before you touch a tool. 'No connection' is rows 1-2; 'works locally but no Internet' is row 3; 'sites are down' is almost always row 4; 'just this one app' is row 5.

Top-down versus bottom-up

Two valid strategies exist. Bottom-up starts at the physical link and climbs — best when the problem is total or hardware is suspect. Top-down starts at the application and descends — best when most things work and only one app fails. Divide-and-conquer jumps to the middle (ping the gateway) and goes up or down based on the result; it is often the fastest. CCST favors a structured approach over swapping parts at random.

Same-site, cross-VLAN example

A finance PC in VLAN 10 must print to a shared printer in VLAN 30. Same-subnet logic does not apply: the PC sends the job to its default gateway, the router routes between 192.168.10.0/24 and 192.168.30.0/24, and a firewall rule decides whether VLAN 10 may reach VLAN 30. If printing to same-VLAN printers works but the cross-VLAN printer fails, you have isolated the issue to inter-VLAN routing or policy, not the PC, the printer, or DNS.

Scope before you act

Always answer 'one host, one VLAN, one service, or whole site?' before changing anything. One host points at the endpoint; one VLAN at an access port or trunk; one service at DNS, NAT, or a firewall rule; the whole site at the gateway or the upstream ISP link. This single question, aligned with the traffic-flow chain above, is the core competency the 100-150 exam measures.