DEV Community: Subnetica

5 Common Subnetting Mistakes That Break Real Networks

Subnetica — Thu, 20 Aug 2026 03:40:26 +0000

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.

FRRouting and the Linux Routing Table: How Routes Reach the Kernel

Subnetica — Wed, 19 Aug 2026 18:02:35 +0000

FRRouting does not forward packets by itself. Its protocol daemons learn and evaluate routes; Zebra coordinates the selected result with the Linux kernel, whose forwarding tables ultimately decide what happens to a packet.

The route's journey

A useful mental model is to separate learning a route from forwarding a packet. OSPF, BGP, or a static configuration produces routing information inside FRR. The protocol daemon sends candidates to Zebra. Zebra applies FRR's selection rules, resolves next hops, and asks the kernel to install the winners. Linux then performs the lookup when a packet arrives.

What each FRR daemon does

FRR is a suite of cooperating daemons. ospfd maintains OSPF adjacencies and its link-state database, then calculates OSPF paths. bgpd exchanges routes with BGP peers and applies BGP policy. staticd manages static routes when that daemon is enabled. These daemons know their own protocol state; they are not independent kernel forwarding planes.

zebra is the routing manager and the bridge to the operating system. It receives route candidates, keeps FRR's main routing view, chooses the routes that should win across protocols, and communicates interface, address, and route state to the Linux kernel. The command syntax may look familiar to Cisco users, but FRR's architecture and implementation are not Cisco IOS.

Protocol information, the RIB, and the FIB

There are several layers of "the route exists." A protocol database may contain an OSPF learned path. FRR's RIB may select that path as the best route for a prefix. The kernel's FIB may then contain an installed route. Only the last layer is directly used by Linux for ordinary packet forwarding.

That is why "OSPF learned it" does not prove that the host will forward traffic through it. A better administrative distance or preference can win. The next hop may not resolve recursively. An interface can be down, a route can be filtered by policy, or the kernel can reject an installation. A newer route can also replace the one you were inspecting.

RIB vs FIB: why the distinction matters

In practical troubleshooting, think of the RIB as the selected control-plane answer and the FIB as the installed forwarding answer. On Linux, the operational view is exposed through commands such as ip route; FRR's view is exposed through show ip route. They should agree for routes that FRR successfully installed, but they are not guaranteed to be identical snapshots.

Inspect both sides

Start with FRR's selected view, then inspect the Linux interfaces, neighbors, and routes. The comparison is more valuable than either command alone.

# FRR: selected routes and protocol-specific evidence
show ip route
show ip ospf route
show bgp ipv4 unicast

# Linux: addresses, neighbors, and the forwarding table
ip -br addr
ip neigh
ip route

# Ask Linux which route it would use for a destination
ip route get 10.44.8.10

show ip route can show a route selected by FRR while ip route tells you whether that route reached the kernel. ip route get is especially useful because it performs a lookup for a concrete destination and displays the chosen interface, source address, and next hop.

Watch the installation boundary

If the state changes while you are troubleshooting, watch both views instead of repeatedly taking screenshots. Linux can report route changes as they happen, while FRR can show whether a route was replaced or withdrawn. This is useful when an interface flaps or a protocol reconverges:

ip monitor route

# In another terminal, watch the selected FRR view
show ip route 10.44.8.0/24

A route disappearing from the kernel immediately after FRR selects it points toward installation, interface, or next-hop problems. A route that never reaches FRR's selected view points earlier in the chain: adjacency, policy, preference, or recursive resolution. The timing often tells you more than a single static table.

This distinction between FRR's view of the network and the Linux kernel's forwarding state is one of the reasons I built Subnetica's labs around FRRouting and Linux rather than hiding the underlying networking stack.

Scenario: OSPF learned the route, but forwarding fails

Suppose Router R1 reports an OSPF route to 10.44.8.0/24, but a host behind R1 cannot reach 10.44.8.10. Work from the control plane toward the data plane:

Check show ip ospf neighbor and confirm the expected adjacency is actually Full. A stale or partial adjacency may leave the protocol database incomplete.
Use show ip ospf route to verify the prefix and next hop are present in OSPF's view.
Use show ip route 10.44.8.0/24 or show ip route to see whether FRR selected an OSPF path, or whether another protocol won.
Run ip route and ip route get 10.44.8.10. If Linux has no matching route, the problem is between FRR selection and kernel installation, or the route was never selected.
Check ip -br addr for interface state and addressing, then ip neigh for a missing or failed next-hop resolution.
If both tables contain the route, test the next hop and the return path. A correct local FIB entry cannot repair a missing reverse route, filtering rule, or disabled forwarding on another hop.

This method avoids a common category error: treating a protocol's knowledge as proof of end-to-end connectivity. Route installation, neighbor resolution, interface state, and return traffic all still matter.

Do not confuse route presence with forwarding success

Even a matching FIB entry is only one part of packet delivery. Linux still needs an operational output interface and a usable neighbor entry for the next hop. The receiving host needs a route back, and local firewall or forwarding policy may reject the packet. For a router namespace, also check that IPv4 forwarding is enabled; a namespace with two addresses is not automatically a router.

That layered model scales beyond FRR. It is the same reason a Kubernetes node can have a route in one namespace while an application namespace has a different view, or why a container route can be correct while the host-side veth or bridge is misconfigured.

Where namespaces make this easier to see

Linux network namespaces make it possible to inspect several independent routing tables on one host. Put FRR in a router namespace, connect it with veth pairs, and the same protocol-to-Zebra-to-kernel pipeline becomes visible without physical hardware. The companion guide explains that topology in detail.

If you want to practice this kind of troubleshooting interactively, Subnetica has browser-based networking labs where you can inspect FRR state, routing tables, and connectivity and have the resulting network automatically graded.

How Network Namespaces Let You Build an Entire Network on One Linux Host

Subnetica — Tue, 18 Aug 2026 20:03:59 +0000

A Linux network namespace is an independent network stack. Give several namespaces interfaces, addresses, routes, and virtual Ethernet connections, and one machine can behave like multiple hosts, switches, and routers without pretending they share one routing table.

What a namespace isolates

Each namespace gets its own interfaces, IP addresses, routing table, neighbor/ARP table, firewall state, and loopback interface. The host kernel still provides the machinery, but a process placed in namespace host-a sees a different network world from a process in namespace host-b.

The namespace starts with a loopback device that is normally down. Bring it up before relying on software that expects localhost to work. The namespace does not magically have a connection to the outside world; connectivity appears only when you create and connect interfaces.

veth pairs are virtual Ethernet cables

A veth pair always has two endpoints. A packet written to one endpoint appears at the other. Move one endpoint into host-a and the other into router, and you have a link between those namespaces. Repeat the operation for router and host-b.

sudo ip netns add host-a
sudo ip netns add router
sudo ip netns add host-b

sudo ip link add veth-a type veth peer name veth-r1
sudo ip link add veth-b type veth peer name veth-r2
sudo ip link set veth-a netns host-a
sudo ip link set veth-r1 netns router
sudo ip link set veth-b netns host-b
sudo ip link set veth-r2 netns router

These commands require root privileges and change the host's live network configuration. Use an isolated test machine or a disposable VM, and keep a recovery path. The commands create only the links; they do not assign addresses, enable forwarding, or make the links operational.

Bring the links and loopbacks up

Configure each namespace from the outside with ip netns exec. The endpoint names are local to their namespace after the move.

sudo ip netns exec host-a ip link set lo up
sudo ip netns exec router ip link set lo up
sudo ip netns exec host-b ip link set lo up

sudo ip netns exec host-a ip link set veth-a up
sudo ip netns exec router ip link set veth-r1 up
sudo ip netns exec router ip link set veth-r2 up
sudo ip netns exec host-b ip link set veth-b up

sudo ip netns exec host-a ip addr add 192.0.2.2/24 dev veth-a
sudo ip netns exec router ip addr add 192.0.2.1/24 dev veth-r1
sudo ip netns exec router ip addr add 198.51.100.1/24 dev veth-r2
sudo ip netns exec host-b ip addr add 198.51.100.2/24 dev veth-b

At this point each directly connected subnet should be visible only in the namespace that owns the interface. Verify the separation:

sudo ip netns exec host-a ip -br addr
sudo ip netns exec host-a ip route
sudo ip netns exec router ip route
sudo ip netns exec host-b ip neigh

Make the router namespace route

Host A knows how to reach 192.0.2.0/24; Host B knows how to reach 198.51.100.0/24. Neither host knows the other network is behind the router. Add routes to the remote subnet and enable IPv4 forwarding in the router namespace.

sudo ip netns exec host-a ip route add 198.51.100.0/24 via 192.0.2.1
sudo ip netns exec host-b ip route add 192.0.2.0/24 via 198.51.100.1
sudo ip netns exec router sysctl -w net.ipv4.ip_forward=1

sudo ip netns exec host-a ping -c 3 198.51.100.2
sudo ip netns exec host-a ip route get 198.51.100.2

Forwarding is a router function, not a property of merely having two interfaces. If the ping fails, check link state, addresses, both return routes, neighbor entries, and the router's forwarding setting. Network namespaces make this troubleshooting concrete because each command can be run from the exact node whose view matters.

Bridges act like virtual switches

A Linux bridge connects ports at Layer 2. Attach several namespace veth endpoints to the bridge and they share an Ethernet broadcast domain. The bridge learns MAC addresses and forwards frames between ports; it does not replace the IP routing table. A router namespace or the host itself can have an IP address on a bridge when it needs to participate at Layer 3.

sudo ip link add br-lan type bridge
sudo ip link set br-lan up

Create a separate cable to the bridge for host-a. These names are different from the veth-a/veth-r1 pair above.

sudo ip link add veth-switch-a type veth peer name veth-bridge-a
sudo ip link set veth-switch-a netns host-a
sudo ip link set veth-bridge-a master br-lan
sudo ip netns exec host-a ip link set veth-switch-a up
sudo ip link set veth-bridge-a up

Inspect bridge ports and learned MAC addresses

bridge link
bridge fdb show

In real setups, connect the bridge to a namespace endpoint or a host-facing interface deliberately. Avoid attaching production interfaces to an experimental bridge without understanding the impact.

From namespaces to a virtual router

A namespace can run a routing daemon such as FRRouting and behave like a router:

FRR's protocol daemon learns routes, Zebra selects and coordinates them, and the Linux kernel forwards packets through R1's namespace.

This is also the basic idea behind browser-based networking environments such as Subnetica: Linux networking primitives and FRRouting can be combined to create isolated virtual networks that behave much more like real systems than a purely diagram-based simulator.

Why this matters for containers and labs

Containers use namespaces to isolate process and network views. Kubernetes networking builds on related primitives, often combining namespaces, veth pairs, bridges or other virtual devices, routing, and policy. Network emulators use them to model hosts and routers cheaply. The concepts transfer: inspect the namespace's own interfaces and routes, then follow the packet across each virtual link.

Clean up a disposable experiment

sudo ip netns del host-a
sudo ip netns del router
sudo ip netns del host-b
sudo ip link del br-lan  # only if you created it in the root namespace

Deleting a namespace removes its contained interfaces and routes. Treat cleanup as part of the experiment so the host does not accumulate stale virtual devices.

If you want to experiment with routing and troubleshooting without building the namespace topology yourself, check out Subnetica, which provides browser-based FRRouting/Linux labs with automatic grading.

DEV Community: Subnetica

5 Common Subnetting Mistakes That Break Real Networks

1. The two hosts use different masks

2. Overlapping subnets are assigned to different networks

3. The default gateway is assumed to be reachable

4. A network or broadcast address is used as a host address

5. The route covers too small a network

Why longest-prefix match exposes bad subnetting

When subnetting looks suspicious, check this first

A short diagnostic challenge

Further reading

FRRouting and the Linux Routing Table: How Routes Reach the Kernel

The route's journey

What each FRR daemon does

Protocol information, the RIB, and the FIB

RIB vs FIB: why the distinction matters

Inspect both sides

Watch the installation boundary

Scenario: OSPF learned the route, but forwarding fails

Do not confuse route presence with forwarding success

Where namespaces make this easier to see

Further reading

How Network Namespaces Let You Build an Entire Network on One Linux Host

What a namespace isolates

veth pairs are virtual Ethernet cables

Bring the links and loopbacks up

Make the router namespace route

Bridges act like virtual switches

From namespaces to a virtual router

Why this matters for containers and labs

Clean up a disposable experiment

Further reading