Good network engineers don't memorize symptoms and guess at the fix. They know what a host, switch and router should do, then collect evidence when reality differs. This path assumes the fundamentals and starts with the evidence that proves how traffic actually moved.
We assume prior IP, switching and network services knowledge, then apply it to packet-path analysis, campus verification, routing, operations and a multi-system incident. Each phase has a purpose; none should be a collection of unrelated lessons.
Multi-layer packet-path evidence: route and neighbor state, link boundaries, name/transport verification, and IPv6 reachability.
Correlate MAC and trunk forwarding evidence, STP topology, EtherChannel state, and approved change validation across a campus.
Static routes, longest-prefix matching, inter-VLAN routing, OSPF fundamentals, NAT, DHCP relay, and service dependencies.
ACL decisions, wireless architecture, monitoring, configuration backups, change windows, and rollback planning.
A multi-site Northstar incident spanning switches, VLANs, routers, DNS, and a business application.
Networking Foundations explains IP, gateways, DNS and Ethernet forwarding. Here you will use those concepts to interpret real-looking route, neighbor, transport and application evidence—then identify exactly where further testing belongs.
Rather than memorizing encapsulation again, use it to decide what each observation can establish. A host's route table explains the intended next hop; an ARP or neighbor entry describes local address resolution; a switch MAC table identifies an observed source; and a firewall session can indicate permitted transport. None of those observations alone proves that the application worked.
When a router forwards a packet onto another Ethernet link, it uses a new link-layer frame. That means a MAC address-table observation on one VLAN cannot be used as proof of the next hop on another network. Correlate evidence across device and layer boundaries.
Your evidence must follow the same boundaries as the traffic: local MAC learning, the next-hop/router decision, security enforcement and the final service transaction. A healthy observation at one stage is not proof of the entire chain.
A report says a client at 10.20.10.11/24 cannot reach a service, but the host has gateway 10.20.10.1. Before changing DNS or a router, inspect the best matching route and whether the expected IPv4 neighbor has a usable MAC entry. Predict which neighbor resolution you should observe for each destination.
| Destination | Route decision | MAC address to resolve |
|---|---|---|
| 10.20.10.42 /24The destination is inside the connected 10.20.10.0/24 prefix. | On-link | Resolve 10.20.10.42 |
| 10.20.20.25 /24The host uses its best route, here the default gateway. | Off-link | Resolve gateway 10.20.10.1 |
| 10.20.10.53 /24The example DNS resolver is a local peer, even if the queried name represents a remote system. | On-link | Resolve 10.20.10.53 |
If a remote destination is selected through the gateway, a missing or incomplete gateway ARP entry localizes the next check. A populated ARP cache is still only evidence of neighbor mapping; capture the actual traffic and interface state before calling the routed path healthy.
Correlate a destination-specific lookup with the installed route, next-hop resolution and interface state. Phase 03 examines how routing sources compete and how more-specific routes change forwarding.
Suppose someone reports, “The intranet is down.” There are several independent checkpoints. DNS may resolve intranet.northstar.example to 10.20.20.25. The host then needs a usable route and a permitted connection to the service. For typical HTTPS over TCP, a TCP handshake and TLS negotiation happen before the application can serve the requested page.
A valid answer says which address a resolver returned. It does not prove the server accepts connections.
TCP establishes a connection; UDP is connectionless. Services can use different transport protocols, including modern HTTP over QUIC/UDP.
Echo, unreachable, and related messages help diagnose paths, but success or silence alone doesn't prove application health.
For the remainder of this lesson, our HTTPS example uses a conventional direct TCP/443 connection. Real networks may include proxies, QUIC, tunnels, security policy, or cached DNS; be explicit about what your test actually checks.
When IPv4 connectivity works but IPv6 does not, a shared application name is not enough to identify the cause. Check the AAAA answer, IPv6 route, router advertisement state and ICMPv6 Neighbor Solicitation/Advertisement observations; use those to distinguish a missing off-link route from an on-link neighbor failure.
For example, a client at 2001:db8:10::11/64 talking to 2001:db8:20::25/64 normally forwards toward an appropriate IPv6 router. The next-hop address might be the router's link-local address such as fe80::1 on a specific interface.
Blocking ICMPv6 indiscriminately is unsafe. Neighbor Discovery and important error/control messages depend on it. IPv6 uses Hop Limit instead of IPv4 TTL.
Switch between local delivery, routed traffic, DNS-to-HTTPS, and an IPv6 first hop. Predict the next address or forwarding decision before revealing the next step. These are fixed teaching examples, not live network diagnostics.
Select a scenario, then advance one forwarding decision at a time. The data is fictional and illustrative; no traffic is sent or captured.
Two hosts share the 10.20.10.0/24 network. The sender can deliver directly to the peer's MAC address.
A transport segment (TCP or UDP, depending on the application) is encapsulated in an IP packet. The destination IP identifies the final host, not the next switch.
ipconfig /allConfirm the source IPv4 address and prefix; this alone does not prove the peer can respond.
The IP destination remains the peer, and the Ethernet destination is the peer's MAC. No router is required.
Commands are useful when they narrow the possibilities. Prefer read-only checks first, preserve the original symptom, and avoid changing a network simply because an output looks unusual.
ipconfig /allVerify the assigned IP, prefix, gateway, and resolver. A valid address does not mean the expected VLAN or service is reachable.
route print -4Check the best-matching route and interface. Compare source, destination, and the documented design.
arp -aLook for the correct IPv4 next hop. A cached MAC entry does not prove end-to-end access.
nslookup intranet.northstar.exampleInspect the answer, then test the intended TCP service and the application's original task separately.
Common authorized read-only checks include show mac address-table dynamic, show interfaces trunk, and show ip route. Use the relevant platform's equivalent, and treat output as evidence—not a permission slip for configuration changes.
Answer five independent scenarios. Each response explains the logic, including why an apparently reasonable alternative would be misleading. You can revise answers and try again; nothing is sent or graded remotely.
Your next required milestone is a new Packet Path Investigation Practice module with cases that demand evidence interpretation. The older Fundamentals lessons below are optional references if a concept needs refreshing.
Read and explore the packet journeys first. Then investigate a new packet-path case in Applied Practice; use Networking Foundations only if you need a refresher.