Certified - CompTIA Network +

Routing is the foundation of inter-network communication. When routing works, data flows between networks, the internet is accessible, and resources in other subnets can be reached seamlessly. But when routing breaks, devices become isolated, applications fail, and connectivity grinds to a halt. What makes routing issues especially disruptive is their all-or-nothing nature—unlike slow wireless or a flaky switchport, a routing problem can completely sever access to entire networks. It affects more than performance—it stops functionality. Troubleshooting these problems requires logical thinking, careful analysis, and step-by-step path validation.
In this episode, we focus on routing failures that result from missing or misconfigured routes, incorrect gateway settings, DHCP errors, and IP address conflicts. These issues commonly appear in both real-world troubleshooting and Network Plus exam scenarios. We'll show how to read routing tables, interpret command output, isolate Layer 3 pathing errors, and resolve problems stemming from DHCP misbehavior or configuration mistakes. The goal is to develop a repeatable, methodical approach to routing diagnostics—one that starts at the core and moves outward.
Your first stop in any routing investigation should be the routing table. On routers and layer 3 switches, the command show ip route reveals the networks the device knows how to reach, how those routes were learned, and what next-hop addresses will be used. On hosts, you can use netstat -r or route print to view the local routing table. Look for the presence of a default route (often listed as 0.0.0.0/0), as well as static or dynamic routes to specific subnets. If the desired network is missing or the next-hop gateway is unreachable, traffic will be dropped. Confirm whether routes are marked as static, directly connected, or dynamically learned.
Static route problems are a frequent source of frustration. A static route pointing to the wrong subnet, using an incorrect mask, or omitting a valid next-hop address can silently prevent traffic from reaching its destination. Unlike dynamic protocols, static routes do not adapt to changes, and a single misconfiguration breaks connectivity. Another issue arises when two routes overlap, but one has a lower administrative distance, causing the more specific or accurate route to be ignored. Always double-check syntax, IP ranges, and gateway reachability when working with static routes.
Dynamic routing protocols introduce their own set of issues. Protocols like OSPF, EIGRP, and BGP rely on neighbor relationships to exchange route information. If those adjacencies fail, routes may disappear from the table. Causes include mismatched configuration settings, missing network statements, incorrect authentication, or simply incompatible timers. Route flapping—when a route rapidly appears and disappears—can introduce instability that causes devices to drop valid routes or make poor forwarding decisions. Use commands like show ip ospf neighbor or show ip bgp summary to verify adjacency health and convergence.
Another area that causes routing problems is the gateway of last resort, often referred to as the default gateway. This setting defines where traffic should go when no specific route exists. If the default route is missing from a router’s table, devices behind it will be unable to access external networks. On client devices, an incorrect default gateway may result in connectivity to the local subnet but a complete inability to reach the internet. These issues typically stem from DHCP misconfigurations or incomplete routing setups and are common in new deployments or when configurations are modified without full verification.
DHCP misassignments are another root cause of routing confusion. If a DHCP server assigns a gateway outside of the client's subnet, routing will fail. Similarly, assigning an IP address that belongs to a different VLAN than the one the client is actually connected to will cause subnet mismatch errors. Sometimes, the DHCP server itself is misconfigured with incorrect scope settings or has run out of addresses to lease. This results in clients defaulting to link-local IP addresses, which offer no connectivity beyond the local segment. Always check DHCP logs, scope availability, and router interface configurations when investigating DHCP-related routing issues.
IP address conflicts can be subtle but damaging. When two devices are assigned the same IP address—either through overlapping DHCP leases and static assignments or duplicate static configurations—intermittent connectivity failures occur. The ARP table may rapidly switch between MAC addresses, leading to unpredictable traffic paths. One device may appear connected while the other suffers from dropped packets or session timeouts. Use commands like arp -a to inspect MAC-to-IP mappings and look for signs of instability. DHCP logs and IP conflict warnings on endpoints also help confirm whether duplication is to blame.
Subnet mask misconfigurations are another fundamental but frequently overlooked issue. A device with the wrong subnet mask may think it’s on a different network than it actually is, causing it to route traffic incorrectly. For example, if a device is supposed to be on a /24 subnet but is assigned a /16 mask, it may try to reach distant devices as if they were local—bypassing the router entirely. This leads to silent failures where traffic is sent but never answered. Mask mismatches can cause ping failures, reachability gaps, and strange routing loops. Always confirm that the subnet mask aligns with both the device’s IP and the router’s expectations.
Path testing using tools like ping and traceroute is essential for visualizing where traffic stops. Ping checks basic connectivity and latency, confirming whether a device is reachable. Traceroute reveals each hop along the path and shows where the communication breaks down. If traceroute gets through one or two routers and then stops, the problem likely lies in routing or firewall rules at that hop. If the trace ends at the local gateway, there may be a default route issue. Use these tools to map the communication path from local subnet to final destination.
Finally, DNS should never be mistaken for a routing problem. Many users report, “I can’t reach the internet,” when in reality they can ping IP addresses like 8.8.8.8 but not resolve domain names. Always test with an IP address before assuming routing is at fault. If IP connectivity exists but name resolution fails, the issue lies with DNS configuration, not with routing. Differentiating between these layers is critical to correct diagnosis.
For more cyber-related content and books, please check out cyber author dot me. Also, there are other podcasts on Cybersecurity and more at Bare Metal Cyber dot com.
Another valuable Layer 3 diagnostic method involves checking the ARP table on routers, switches, or end-user systems. The ARP table maps IP addresses to MAC addresses and plays a vital role in determining whether packets can be delivered across a subnet. If an entry is incorrect—perhaps due to stale cache data, duplicate addresses, or misconfigured devices—traffic may be silently dropped or misrouted. Use arp -a on Windows or show arp on network devices to verify that MAC address associations look correct. If an address points to the wrong device, or if it’s missing entirely, clearing the ARP cache and forcing regeneration can often resolve issues.
Access Control Lists (ACLs) are another common cause of failed routing, particularly when traffic seems to stop at the correct device but never reaches its destination. An interface ACL may be blocking traffic based on source or destination IP, port, or protocol. These blocks often show up as failed pings, broken applications, or incomplete traceroute paths. Review ACLs applied inbound or outbound on interfaces using commands like show access-lists or show run | include access-group. Rule order is crucial—if traffic matches a deny rule before a permit rule, it will be dropped. Be especially cautious with implicit deny behavior at the end of most ACLs.
Misconfigured VPNs and tunnel interfaces can also interfere with routing. In split-tunnel VPNs, only certain traffic is routed through the VPN while other traffic exits locally. If the routing policy is incorrect, internal resources may become unreachable while external browsing works—or vice versa. Another issue occurs when the tunnel interface is down or misconfigured. In that case, even though the VPN appears connected, the actual path to protected resources is broken. Tunnel diagnostics should include verifying interface status, route injection, and whether the client is receiving the correct internal routes upon connection.
Asymmetric routing becomes a problem when traffic takes one path to its destination and a different path back. This is especially problematic with stateful firewalls, which expect responses to return along the same path they originated. If traffic takes a different return route, the firewall may drop it as unsolicited. This is common in load-balanced environments or where redundant connections are in place. To diagnose asymmetric routing, use tools like traceroute in both directions or examine flow logs to see the full traffic path. Ensuring consistent next-hop behavior across all devices is key to fixing the issue.
Client-side configuration is another major source of routing failures. Static IP settings that fall outside the correct subnet, incorrect gateways, or mismatched DNS servers can all lead to inconsistent connectivity. A static IP may allow local access but break communication to remote networks if the gateway is wrong. Switching to DHCP, when available, allows the client to pull tested, valid network settings and helps confirm whether the issue is local or systemic. Comparing a functioning client’s settings to those of the failing one can often reveal subtle differences that point directly to the cause.
Sometimes the issue lies not with the client or the route, but with the DHCP server itself. If the DHCP service is not running, devices will fail to receive leases. If the server’s IP scope is exhausted, new clients will be left without an address. In routed networks, a missing DHCP relay agent or misconfigured ip helper-address can prevent clients on other subnets from reaching the server at all. Always verify that the DHCP service is running, that scopes are correctly defined and have available addresses, and that relays are properly forwarding requests from remote VLANs to the correct server.
The Network Plus exam frequently includes routing fault scenarios. You may be shown ping or traceroute output and asked to identify where the failure occurs. Some questions test your ability to recognize misconfigured static routes or incorrect default gateway settings. Others may require interpreting ARP table output or understanding the effect of ACLs. You could also be asked to select which DHCP option must be fixed, or to explain why a VPN user can’t reach internal systems. These questions test your understanding of the complete routing chain—from interface and gateway to routing table and firewall policy.
To summarize the key routing and addressing troubleshooting techniques: always start with the routing table. It tells you what the device knows and where it plans to send traffic. Use ping and traceroute to verify the actual path and identify where things stop working. Examine ARP tables, verify subnet masks, and compare IP configurations to ensure consistency. When DHCP is involved, check both client behavior and server health. Watch for address conflicts, ACL mismatches, and asymmetric paths. In environments with tunnels or VPNs, confirm policy routing and interface status to ensure full reachability.
Routing issues are challenging because they break entire paths—when routing fails, even simple tests like ping stop working. But with a methodical approach and the right tools, these problems can be diagnosed quickly. By combining routing table analysis, path testing, and configuration review, technicians can pinpoint errors that others overlook. Whether it’s a simple default route omission or a complex policy mismatch, solving routing issues restores not just connectivity—but full operational confidence.