Common Anti-Patterns

Most network outages are not exotic. They are the same handful of mistakes repeated across teams and stacks: the flat network with no segmentation, the single DNS resolver, the firewall rule that defaults to allow, the subnet sized with no room to grow, the ICMP someone blocked "for security." Each is cheap to avoid at design time and expensive to suffer in production — and each maps cleanly back to a mechanism covered earlier in this course.

This topic is the field guide. The four sections below group the recurring anti-patterns by family — addressing and routing, security, reliability, and the silent killers — and for each one names the specific consequence and the fix, pointing at the chapter that explains it in depth. Read it as a checklist of things to recognize on a whiteboard before they become a 3 a.m. page.

Addressing and Routing Anti-Patterns

The most expensive addressing mistake is the overlapping CIDR. Two VPCs carved from 10.0.0.0/16 independently cannot peer, and a network you later need to connect to on-prem that reuses the same range cannot be routed to without renumbering one side — a project, not a config change (CIDR planning, Topic 13). The fix is a single authoritative IP plan allocated top-down before the first subnet is created.

Two more belong here. No growth headroom — sizing a subnet to today's host count so it fills and forces a renumber (Topic 13). And the flat layer-2 network, one giant broadcast domain where every host can reach every other: broadcast traffic scales with host count, a single misbehaving NIC floods everyone, and there is no segmentation boundary to contain a compromise (Topic 53). The fix for both is to subnet deliberately, with room to grow and a routing boundary between tiers.

Security Anti-Patterns

Security anti-patterns share a theme: trusting by default. Default-allow egress lets a compromised host phone home and exfiltrate freely, because nobody filtered outbound — the inbound rules were the only ones anyone wrote (default-deny, Topic 49). Perimeter-only trust assumes anything inside the network is friendly, so a single breached host has lateral run of a flat internal network with no further checks.

Public-by-default is the cloud version: instances assigned public IPs and databases reachable from the internet because that was the path of least resistance, leaving admin ports exposed to the entire address space. Each of these is closed by the same discipline — default-deny in both directions, private-by-default addressing, and identity-based authentication between services rather than implicit network trust (the hardening checklist, Topic 76).

Reliability Anti-Patterns

The reliability anti-patterns are the single-of-everything family. A single DNS provider is a SPOF that no amount of multi-region backend redundancy can survive: when it goes down, every region behind it goes dark together (designing for failure, Topic 74). A single upstream transit is the same trap one layer down.

Untested failover is the one that bites hardest — a standby that has never carried live traffic is a hypothesis, and the config has usually drifted or the DNS TTL is too long to fail over in time. No connection draining rounds out the family: removing an instance without draining resets every in-flight request, so each deploy and each health-check eviction becomes a visible blip. Run a second DNS provider, exercise failover on a schedule, and drain on every removal.

The Silent Killers

The worst anti-patterns produce no error message — they degrade silently and intermittently. Blocked ICMP is the canonical one: a firewall that drops ICMP "type 3, code 4" (fragmentation needed) breaks Path MTU Discovery, so large packets vanish into a black hole while small ones sail through, and the connection hangs only on big payloads (MTU/PMTUD, Topic 68). The fix is one line: allow PMTUD ICMP through every firewall.

The other silent killers are saturation you are not watching. An unmonitored conntrack table fills under a connection flood and starts dropping new flows with no log entry on the application side (Topic 49). Ephemeral-port exhaustion on a busy NAT or proxy caps new outbound connections the same invisible way. And ignored TTLs — DNS records or routes with TTLs too long to converge — mean a failover or correction takes effect long after you made it. Each is invisible until you put a graph and an alert on it.

# the silent killers, made visible — watch these before they drop traffic
sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max
# count / max — if count nears max, new flows are dropped silently
sysctl net.ipv4.ip_local_port_range   # ephemeral pool for outbound conns
# confirm PMTUD ICMP is allowed, not dropped at the firewall
iptables -L INPUT -n | grep -i icmp