Routing starts on the endpoint before a router ever forwards the packet
The most useful routing model begins with one question on the sending host: is the destination inside my local IP network, or is it remote? That decision determines whether the host tries to deliver directly on the local link or sends the packet to a router.
After reviewing routing, use the AP Networking Routing and Default Gateway Practice Test to apply the table to exact destinations. It separates longest-prefix selection from metric comparison, then asks whether next-hop reachability, traffic policy, and return routing support the selected path.
A host uses its own address and prefix/mask to classify the destination. If the destination is local, the host can resolve a local Layer 2 neighbor and send directly. If remote, it normally resolves the default gateway as the local next hop. The IP packet still names the remote destination; only the Layer 2 frame targets the gateway.
This is why a wrong subnet mask can create routing-like symptoms even when every router is configured correctly. The host may make the wrong local-versus-remote decision before the first router participates.
Follow one remote packet across five decision boundaries
Keeping these boundaries separate makes troubleshooting much faster. A failure before the gateway is a different branch from a missing downstream route, and both differ from a broken return path.
The subnet mask changes what the host believes is directly reachable
Consider 192.168.10.25/24. Destination 192.168.10.80 is inside the same /24, while 192.168.20.80 is not. The first can be treated as local; the second requires Layer 3 forwarding through a gateway.
Now imagine the client mistakenly uses a much broader prefix. It may believe a truly remote address is local and attempt neighbor resolution instead of sending the packet to its gateway. A narrower wrong prefix can produce the opposite error: a genuinely local peer may be treated as remote.
This connection between subnetting and routing is operational, not just mathematical. Prefix length controls forwarding behavior on endpoints as well as route specificity on routers.
The default gateway is a local next hop for remote destinations—not the packet's final IP target
Suppose client 10.10.10.25 sends to server 10.50.50.20. The IP destination remains 10.50.50.20 as the packet crosses routers unless another mechanism such as NAT intentionally changes addressing. On the client's Ethernet segment, however, the destination MAC belongs to the gateway interface.
This distinction explains why a client normally does not ARP for the remote server's MAC. ARP/neighbor resolution serves the local link. The router receives the frame, removes that link-layer framing, performs its Layer 3 decision, and creates appropriate framing for the next link.
Routers rebuild link-layer delivery hop by hop
Students often picture one Ethernet frame traveling from a laptop through several routers to a server. That is not the routed model. Ethernet addressing is local to an Ethernet segment. At a router boundary, incoming Layer 2 framing terminates; the router processes the IP packet and sends it onward using new link-layer information suitable for the outgoing link.
The IP header also changes in routing-relevant ways: IPv4 TTL is decremented at each router, and the header checksum is updated accordingly. The source and destination IP addresses generally remain the endpoint addresses unless a translation mechanism such as NAT changes them.
Separating “which IP endpoint?” from “which local next-hop frame?” is one of the highest-value concepts for interpreting ARP tables, packet captures, and routing diagrams.
Read each route as destination prefix → forwarding instruction → provenance
A routing-table entry typically tells you which destination prefix it covers and where matching traffic should go, such as a next-hop address or outgoing interface. It may also identify how the route was learned and include preference or metric information.
| Route type | Why it exists | What it can tell you | What it does not prove |
|---|---|---|---|
| Connected | Network attached to an operational interface/context | Direct network reachability represented by the router | Every host on that subnet is alive |
| Static | Configured route | Administrator-defined forwarding intent | Next hop or downstream path is healthy |
| Dynamic | Learned through a routing process | Protocol-derived path information | Application or return path works |
| Default /0 | Catch-all fallback | Where unmatched IPv4 destinations are sent | It overrides a more-specific match |
Swipe horizontally to see the full table.
Multiple routes can match; the narrowest installed destination range wins
The /24 wins because it has the longest matching prefix. This rule allows broad summary routes and narrow exceptions to coexist. It also means a default route with a tiny metric does not beat an installed /24 that matches the destination.
For deeper route-selection cases involving candidate sources, equal cost, and recursive next-hop resolution, use How Routers Choose Paths.
A route choice is only the beginning of successful forwarding
After choosing a route, the router still needs a usable forwarding action. A connected destination can be delivered through the attached network. A route naming another router as next hop requires the device to determine how that next-hop address is reached and, on technologies such as Ethernet, obtain the local neighbor information needed to transmit.
An installed route therefore supports the statement “this router intends to forward matching traffic this way.” It does not support “the destination is reachable.” The outgoing interface can be down, neighbor resolution can fail, the next router can lack a route, policy can block the packet, or the return path can be broken.
Do not mix route-source preference, protocol metrics, and prefix specificity
Connected, static, and dynamically learned candidates can compete for the same destination prefix. Platforms use route-source preference rules and routing-protocol calculations to decide what becomes active. Metrics then help rank paths in the appropriate protocol context.
Once routes are installed, forwarding a packet asks a different question: which installed prefix is the longest match for this destination? This is why “choose the lowest metric” is an unsafe universal rule.
If a prompt supplies administrative preference/distance values, protocol metrics, or multiple candidate routes, use the supplied context rather than assuming every vendor implements identical values.
A default route solves unknown-destination forwarding but can also hide missing specificity
0.0.0.0/0 matches every IPv4 destination and is useful when a router does not need a detailed route for every possible network. A branch router, for example, may send all nonlocal destinations toward an upstream core or Internet edge.
But “there is a default” is not the same as “routing is correct.” A more-specific wrong route will win over the default. And a default may send internal traffic toward an inappropriate upstream device if a needed internal route is missing. Troubleshooting must inspect the route actually selected for the failing destination.
Different VLAN IP networks need a Layer 3 device to communicate
VLANs create separate Layer 2 broadcast domains. When VLAN 10 uses 10.10.10.0/24 and VLAN 20 uses 10.20.20.0/24, a host in VLAN 10 classifies a VLAN 20 address as remote and sends toward its gateway. A router or Layer 3 switch then performs the Layer 3 forwarding decision.
This creates a useful troubleshooting split. If two hosts in the same VLAN/subnet cannot communicate, investigate local switching, VLAN placement, addressing, and endpoint state first. If same-VLAN communication works but cross-VLAN traffic fails, gateway interfaces/SVIs, routing, ACL/firewall policy, and return paths rise in value.
TTL limits how long an IPv4 packet can survive a loop
Every router decrements IPv4 TTL. If forwarding state causes routers to circulate a packet, TTL eventually reaches zero and the packet is discarded. A router may send ICMP Time Exceeded, which is also the mechanism leveraged by traceroute-style tools to expose responding hops.
A loop is different from “no route.” With no usable route, forwarding stops at the device lacking a match/default. In a loop, multiple routers keep making forwarding decisions that send the packet back toward one another. Repeated hop patterns plus routing-table evidence can support that diagnosis.
One-way success is not a complete routing proof
A request can reach a server while its reply fails. Each direction has its own routing decisions, and the reverse path does not have to mirror the forward path. That asymmetry can be perfectly valid in a well-designed network.
Stateful firewalls and NAT can make asymmetry operationally important because a device may need to see both directions to apply connection state or translation correctly. If captures show requests arriving at the destination but no replies returning to the client, investigate the server-side gateway, return routes, stateful boundaries, and policy rather than repeatedly changing the known-good forward route.
Locate the first boundary where the evidence stops supporting progress
Host configuration
Address, prefix, gateway, and active interface establish what the endpoint believes.
Gateway reachability
A successful gateway test supports local IP reachability to that next hop.
Local route
The router table predicts the selected prefix, next hop, and interface.
Path behavior
Traceroute or downstream evidence can show where visible forwarding behavior changes.
Destination arrival
Packet capture or service-side evidence can establish that the request actually arrives.
Return path
Replies need valid routing and policy back toward the source.
Same-subnet works, remote networks fail: inspect the host-to-gateway boundary first
A client can communicate with peers in 192.168.40.0/24 but cannot reach any remote subnet. Its address and /24 mask are correct, but its default gateway is configured as 192.168.40.254 while the router interface is 192.168.40.1.
The local success is expected because same-subnet traffic does not require the gateway. The broad remote failure is also coherent: every remote destination depends on the wrong first-hop gateway setting. Correcting a downstream static route would not address the demonstrated boundary.
After repair, verify the gateway value, local gateway reachability, at least one required remote destination, and the original application—not merely one ping.
Most remote networks work, but one subnet fails: look for destination-specific routing
A client reaches its gateway, DNS server, and several remote networks, but 10.70.40.0/24 fails. The local router contains a default route and a specific route for 10.70.40.0/24 pointing to an old next hop.
Because the /24 is more specific than /0, the router selects the stale /24 instead of the otherwise useful default. The fact that “the Internet works” does not clear the routing table; it only proves other destinations have usable paths.
This is a high-information pattern: broad success plus one-prefix failure should move attention toward that prefix's route, next hop, policy, downstream state, and return route.
The server receives requests, but the client sees no replies: change direction
Suppose a capture on the server confirms packets from 10.10.10.25 arrive. That evidence pushes the failure boundary past the client and forward routing. If the server sends replies but its gateway lacks a route back to 10.10.10.0/24, the reverse traffic may follow an inappropriate default or be dropped.
The next question is no longer “can the client route to the server?” It is “what forwarding decision is made for the reply?” Direction-specific reasoning prevents a healthy forward path from being repeatedly reconfigured.
24 AP Networking routing flashcards
These cards connect endpoint subnet decisions, gateway behavior, Layer 2/Layer 3 boundaries, route tables, longest-prefix matching, ARP, TTL, inter-VLAN routing, return paths, and troubleshooting evidence.
Routing mistakes often come from proving more than the artifact supports
“The route exists, so it works.”
A table entry does not prove next-hop or downstream reachability.
“The lowest metric always wins.”
Do not ignore destination-prefix specificity or route-source context.
“The gateway is the IP destination.”
The gateway is normally the local next hop for a remote destination.
“The remote server's MAC crosses routers.”
Layer 2 framing is rebuilt hop by hop.
“Forward path good = connection good.”
Return routing and stateful policy can still fail.
“A traceroute * means no route.”
A missing diagnostic reply does not reveal the router's forwarding table by itself.
Prove the repair at the same boundary that originally failed—and beyond it
If you correct a host gateway, verify the new configuration and then the original remote requirement. If you replace a stale /24 route, confirm that the intended /24 is installed, its next hop is usable, and traffic to that subnet succeeds. Also test a destination that should continue using the broader/default route so the repair has not stolen unrelated traffic.
When a stateful firewall or NAT sits in the path, include both directions in verification. Routing correctness is not merely a green ping; it is the intended forwarding behavior supporting the required application while preserving network policy.
Pair routing tables with endpoint, path, and packet evidence
Different artifacts answer different questions. ipconfig can show what gateway and prefix the endpoint has. An ARP/neighbor table can show local next-hop mapping. A routing table can show the forwarding choice represented on one device. Traceroute can expose responding path behavior. Packet capture can show whether a request or reply crosses a particular boundary.
The strongest diagnosis uses the smallest set of artifacts that separates the remaining hypotheses. For cross-artifact practice, use AP Networking Artifact Analysis and Network CLI Output Practice.
Translate every routing artifact into a bounded statement
Instead of writing “the network is routed correctly,” write “for destination 10.70.40.8, this router's longest matching installed prefix is 10.70.40.0/24 and it selects next hop 10.1.1.2.” Then identify the next unresolved dependency.
That language makes distractors easier to reject. A proposed DNS change does not repair a demonstrated missing route. A lower default-route metric does not override a matching /24. A successful gateway ping does not prove the return path from a remote server.