5 Common Subnetting Mistakes That Break Real Networks

Subnetting errors rarely announce themselves as "bad math." More often, two devices make different decisions about whether a destination is local, a route points at the wrong boundary, or a cloud/VPN design contains two networks that cannot be unambiguously routed. These five failure modes are worth recognizing in live configurations. 1. The two hosts use different masks Consider Host A at 192.168.10.10/24 and Host B at 192.168.11.10/16. A calculates that B is outside 192.168.10.0/24, so A sends the packet to its default gateway. B calculates that A is inside 192.168.0.0/16, so B treats A as local and tries ARP directly. The result can be asymmetric: one direction follows a router, while the reply is sent directly or never reaches the expected gateway. Check the actual prefix on both interfaces, not just the dotted decimal mask shown in a diagram. ip -br addr ip route ping -c 3 192.168.11.10 Correct the prefix so both endpoints agree, or intentionally route between two correctly defined subnets. 2. Overlapping subnets are assigned to different networks Suppose a branch uses 10.20.0.0/16, while a cloud VPC or VPN peer also uses 10.20.0.0/16. The problem is not that either mask is mathematically invalid. The problem is that a router cannot distinguish "the branch's 10.20.5.0/24" from "the cloud's 10.20.5.0/24" if both are reachable through different paths. Symptoms include traffic taking the wrong tunnel, routes that cannot be installed, or a VPN that connects but cannot reach some subnets. Inventory both sides of a tunnel and compare the complete network/prefix pairs. A longer, more specific route may make one destination appear to work while hiding the underlying overlap. ip route ip route get 10.20.5.25 traceroute -n 10.20.5.25 The durable correction is renumbering or using an intentional translation/design boundary. Adding increasingly specific routes is usually a brittle workaround. This is also why I prefer teaching subnetting inside routing and troubleshooting scenarios rather than only through standalone CIDR exercises. On Subnetica, subnetting shows up as part of the network you actually have to diagnose and configure. 3. The default gateway is assumed to be reachable A default gateway is not simply "the first address in the subnet." For an ordinary Ethernet host, the gateway must be reachable on a directly connected local network. A host at 192.168.50.20/24 cannot normally use 192.168.51.1 as its gateway because the host believes that address is remote and has no route to reach it. "It looks close" is not a routing rule. Verify the interface prefix and the connected route before debugging the gateway device. ip addr show dev eth0 ip route ip route get 1.1.1.1 ip neigh show dev eth0 Fix the host prefix, choose an on-link gateway, or add a deliberate design that makes the next hop reachable. On point-to-point links and some special configurations, the exact on-link behavior differs, so inspect the kernel's route rather than relying on a blanket rule. 4. A network or broadcast address is used as a host address For 192.0.2.0/24, 192.0.2.0 is the network address and 192.0.2.255 is the directed-broadcast address in the conventional IPv4 subnet model. Assigning either as an ordinary host address creates ambiguity or is rejected by the platform. The usable host range is commonly 192.0.2.1 through 192.0.2.254. This rule is about the address plan, not a claim that every modern point-to-point implementation behaves identically. For a point-to-point link, follow the platform's documented interface and prefix semantics; do not mechanically apply LAN broadcast assumptions. # Inspect the address and the connected route ip addr show ip route # Ask a calculator or your own binary-prefix method: # 192.0.2.0/24 -> network .0, broadcast .255 Correct the host address and verify that ARP/neighbor discovery and the connected route now match the intended subnet. 5. The route covers too small a network Imagine the design calls for 10.20.0.0/16, but the router is configured with 10.20.0.0/24. Destinations from 10.20.0.0 through 10.20.0.255 match; 10.20.1.10 does not. That creates the frustrating symptom where "some hosts in the network work" while others follow a default route or disappear into a different path. Routing protocols, administrative preference, and metrics determine which candidate route for a given prefix is installed. When forwarding a packet, the system then selects the most specific matching installed route using longest-prefix match. A /24 has a longer prefix length than a /16, so it is more specific and covers a narrower network. A more-specific mistaken route can override a correct summary without changing the summary itself. ip route ip route get 10.20.0.10 ip route get 10.20.1.10 # On an FRR router, compare the selected RIB entry too: show ip route 10.20.1.10 Correct the route to 10.20.0.0/16 if that is the intended boundary, then check for competing more-specific routes and the return path. Why longest-prefix match exposes bad subnetting Routers do not choose the route with the prettiest address or the route learned first. The routing process first decides which candidate for each prefix should be installed, using protocol rules, administrative preference, and metrics. The forwarding table then compares a packet’s destination with the installed routes and uses longest-prefix match. A /24 beats a /16 for destinations inside that /24 because the /24 is narrower and more specific. This makes an incorrect subnet mask especially deceptive. A broad summary can carry most traffic successfully while one accidental more-specific route sends a small range somewhere else. When only a handful of destinations fail, compare ip route get results for a working and failing address, then inspect the exact prefix, not just the next hop. Compare addresses on either side of a suspected boundary ip route get 10.20.0.250 ip route get 10.20.1.10 On a Linux router, the chosen device and gateway are the evidence ip -br link ip route When subnetting looks suspicious, check this first Source address and prefix, on the actual interface. Destination address and whether it should be local or routed. Default gateway and whether the kernel sees it as reachable. The routing table and the result of longest-prefix match. Duplicate, overlapping, or unexpectedly summarized networks. A short diagnostic challenge Given 192.168.10.10/24 and 192.168.11.10/16, which host believes the other is local? Host B, because its /16 covers both addresses. Host A does not, because its /24 ends at 192.168.10.255. The important lesson is not the answer. It is that "same subnet" is a calculation made independently by each endpoint. If you want to practice these concepts in actual network scenarios, take a look at Subnetica, a networking learning platform with lessons, quizzes, and automatically graded FRRouting/Linux labs. Further reading Linux ip-route(8) manual page IETF RFC 4632, Classless Inter-domain Routing