A router forwards packets between IP networks. Its core job is to compare the packet’s destination IP address with a forwarding table, select an eligible next hop or outgoing interface, and transmit the packet on the next link. A home gateway, a large enterprise router and a virtual cloud router all perform variations of that operation, even though their interfaces, policies and management systems look different. To understand routers, start with the actual packet path and the evidence that proves it works—not claims that a box always chooses the fastest internet connection.
This article explains how router forwarding behaves and how to diagnose a forwarding failure. Routing protocols, WAN design and security features matter, but their purpose is clearer when separated from the core forwarding decision. A router can have a healthy interface and still drop traffic because there is no route; conversely, a learned route can exist in the control plane while an access policy or unresolved neighbor prevents successful forwarding.
A host decides whether it needs a router
Before a router receives anything, a sending host evaluates its own address and prefix. When the destination is considered on-link, the host tries to deliver locally through its link-layer mechanism. When the destination is outside that scope, the host usually sends the packet toward a configured default gateway. The link-layer destination then identifies the next-hop interface, not necessarily the ultimate remote application. The IP destination stays associated with the end-to-end packet while hop-specific frame headers change.
A default gateway is not a second DNS server and not automatically a security product. It is the next hop selected when no more specific local route is appropriate. If the gateway is unreachable, the host cannot forward through it, regardless of whether the remote website’s address is correct. A useful comparison is the default gateway relationship: confirm the local subnet and neighbor resolution before treating an outside-network failure as a provider outage.
For a typical Ethernet IPv4 interface, the host can learn the gateway’s MAC address using ARP. IPv6 uses Neighbor Discovery, including router advertisements and neighbor solicitations, under its own rules. A route pointing to an IP next hop is therefore not enough by itself; the outgoing interface must be usable and the link must be able to deliver the frame. The exact sequence differs for point-to-point links, tunnels and other network types, where Ethernet ARP may not be used at all.
Longest-prefix matching determines the destination class
Routers commonly carry overlapping routes: a connected subnet, several learned networks, a more-specific exception and perhaps a default route written as 0.0.0.0/0 or ::/0. The first essential forwarding rule is longest-prefix match. If both 10.40.0.0/16 and 10.40.7.0/24 match the packet destination 10.40.7.25, the /24 is more specific and is selected for that destination class. This remains true even if another route seems more convenient because its prefix is broader.
After identifying the best-matching destination prefix, a router applies its own route eligibility and implementation-specific selection among eligible routes, including administrative preference, metrics, equal-cost paths or policy. Do not compress these steps into the slogan ‘the lowest metric wins’: a metric in one routing protocol is not directly comparable with another protocol’s metric. A static route, a connected route and a dynamically learned route can have different priority and failure behavior. A valid route must also resolve to a forwarding next hop or interface.
A missing specific route may fall through to the default route if one is installed. That does not prove the default provider accepts the destination or provides a return path. Conversely, an explicit discard or blackhole route may be intentional for loop prevention or attack mitigation. The concept of IP subnetting supports correct prefix reasoning, but a correct subnet mask alone does not establish end-to-end connectivity.
Control-plane routing and data-plane forwarding are different
A routing protocol lets devices exchange reachability information and react to topology changes. Static routes are entered by an administrator or controller, while dynamic protocols such as OSPF and BGP exchange information under their own scopes and policies. The routing information base may contain several candidates for a destination. The forwarding information base reflects the selections programmed for packet forwarding. Those structures are related, not interchangeable, and a software or hardware failure may prevent an intended control-plane route from becoming usable in the data plane.
For example, an OSPF adjacency can be up even if an import policy, an incorrect area design or an overlapping more-specific route prevents the expected traffic path. A BGP peering session can be Established while a prefix is rejected by policy or its next hop is unresolved. A routing protocol also does not inspect an HTTP transaction to choose the fastest application server. It advertises reachability and supports an operator’s route-selection decisions. A comparison of routing protocol families can deepen these distinctions once the forwarding basics are clear.
Reconciliation after a link failure takes time. Physical detection, neighbor loss, route recalculation, forwarding-table update and remote return-path changes may occur on different schedules. Vendor fast-failover features can reduce some intervals but do not establish a universal zero-interruption guarantee. Test actual application behavior during failure where an authorized environment permits, and distinguish observed convergence from a configuration setting that merely advertises a target.
Each routed hop rebuilds its local frame
Consider a workstation in 192.0.2.0/24 sending traffic to a host in another network. The workstation sends an IP packet to its chosen gateway using an Ethernet frame addressed to the gateway’s local MAC. The router removes the incoming frame, evaluates IP forwarding, updates fields required by the IP version such as TTL or hop limit, and builds the outgoing link-layer frame for the selected next hop. On a conventional routed Ethernet hop, that new frame has the local router interface as its sender and the selected next-hop MAC as its destination.
The remote application’s IP address is not substituted with the gateway’s IP merely because the gateway receives the frame. In a network employing NAT, an address or port translation may also occur, but translation is a separate function governed by configuration and state. A packet can travel through many routers without NAT, and a NAT device can fail to translate correctly even while routing remains healthy. Calling NAT ‘what every router does’ obscures the real troubleshooting path.
Network devices often combine functions. A multilayer switch can bridge Ethernet frames within a VLAN and route between VLAN interfaces; a Wi-Fi access point may bridge stations while a home all-in-one appliance separately routes toward the provider. A firewall can also route and inspect traffic. Separate the observable function from the marketing name on the chassis, especially when drawing a trust boundary.
Segmentation and security require explicit policy
A router separates IP forwarding domains and can act as a policy enforcement point, but adding a route does not itself make a tenant or subnet secure. Whether an isolated department can reach another depends on routing reachability, ACLs, firewalls, VRFs, authentication and any overlay policy. Inter-VLAN routing should be introduced only with clear permitted flows, not as evidence that every VLAN is independent once a Layer 3 interface exists. For design choices see inter-VLAN routing.
Security checks need both positive and negative tests: an approved service must remain accessible, and an unauthorized source must be denied at the intended boundary. IP routes describe potential destinations; they are not user identities or complete access grants. If a firewall denies traffic after the route lookup, the route table can be entirely correct. If a reverse route is missing, a permitted forward connection can still fail. Stateful filtering, NAT, asymmetric paths and return traffic should be reviewed together.
Troubleshoot the path in evidence order
Begin with the source host and a known destination: what interface, IP address, prefix, gateway and DNS resolver does it actually use? Is there a local route for the destination? Can it reach the selected next-hop link-layer neighbor? Next examine the router’s selected route for the exact destination IP, not merely a related aggregate. Check outbound-interface status, next-hop resolution, counters, policy hits and any translation state that applies. After that, inspect the path beyond the router and verify the return direction.
Tools such as route-table displays, interface counters, neighbor tables, ICMP probes and traceroute supply different evidence. A successful ping shows a response on one tested path; it cannot prove every TCP service, MTU-dependent transaction or security policy is healthy. Traceroute may omit devices that suppress or rate-limit TTL-expiry responses. Likewise, a rising error counter can indicate physical or queueing problems even if some traffic still passes. A measurement should be linked to its source device, interface, timestamp and direction.
Imagine a hypothetical branch whose users can reach local servers but not an external service. If the branch gateway responds locally, the problem may still lie in its default route, upstream link, NAT policy, DNS, or the remote service. Test an external IP separately from name resolution. If outbound IP reaches its target but the named service fails, investigate DNS and application behavior rather than replacing routing advertisements. If only one VLAN fails, compare that VLAN’s gateway and policy with a working VLAN before resetting the whole router.
Operate routes as controlled changes
Record the intended prefix, next hop, owner, failure behavior and rollback for every route change that matters. Before altering a default or aggregate route, list its dependent networks; a seemingly harmless new specific prefix can capture traffic that used a different gateway. Validate both the active route and the actual forwarding path after the change. Test the negative case: traffic that must not cross a policy boundary should still fail for the expected reason.
Route summaries improve scale but need careful handling when downstream destinations disappear. A broad aggregate can attract traffic even though a more-specific internal destination is unreachable, so loop-prevention and discard behavior matter. For critical systems, test recovery before the change window ends rather than relying on a configuration tool’s success message. Backup state, interface observations, route-selection evidence and application checks make the next incident faster to diagnose.
The practical router mental model is therefore precise: a host chooses a next hop; a router selects a matching destination prefix and usable forwarding action; each hop delivers over its own link; policies and other devices may alter or block the flow; and return traffic has a path of its own. Understanding those decisions does more for network reliability than treating routers as devices that mysteriously pick the internet’s fastest route.
