Technical guide

5 Common Subnetting Mistakes That Break Real Networks

By Subnetica · Published August 18, 2026 · Updated August 18, 2026

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.

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.

Subnetting is easier to retain when it appears inside routing and troubleshooting scenarios rather than only as isolated CIDR questions. Start with the Subnetting and IPv4 curriculum pages, then use the Troubleshooting path. Where a dedicated subnetting lab is not published, do not assume one exists; addressing is practiced inside the relevant routing and IPv4 activities, including the wrong-default-gateway lab when available.