Network Topologies - Choosing a Shape for a Small Fleet

Status: Active
Last Updated: 2026-08-26
Category: Networking - Architecture
Prerequisites: tcp-ip-fundamentals, ip-addressing-subnets
Time: 2 hours
Tags: topology, star, mesh, hybrid, architecture, planning

Summary

Compares star, mesh, and hybrid network topologies for a small self-hosted fleet like fogserv.cloud's, and explains why a hybrid (star + overlay mesh) is usually the right choice. Includes decision criteria, diagrams-as-text, and a concrete layout for our hosts.

🎯 What You'll Learn

By the end of this article, you'll be able to:

✅ Describe star, mesh, and hybrid topologies and their trade-offs
✅ Pick a topology based on host count, failure tolerance, and admin effort
✅ Design a small-fleet topology that combines a LAN star with a WireGuard mesh

Context / Why This Matters
The Three Candidates
Choosing One
Fogserv Reference Topology
Troubleshooting & Common Pitfalls
Next Steps / Ops Actions
Sources & Related
Change Log

Context / Why This Matters

"Topology" is how your nodes are physically or logically connected. For three servers behind one router it sounds academic — until a switch dies and you discover everything was single-homed through it, or you add a second site and every host needs a new tunnel to every other host.

Topology decisions determine blast radius: what breaks when one link, switch, or host fails. Getting this right early avoids re-cabling and re-addressing later. Prerequisites cover addressing (ip-addressing-subnets) and packet flow (tcp-ip-fundamentals); this article covers shape.

The Three Candidates

Star

Everything connects to a central node (switch/router).

        ┌───┐
   ┌────┤ R ├───┐          R = router/switch (single point of failure)
   │    └───┘   │
 ┌─┴─┐        ┌─┴─┐
 │ S1│        │ S2│  ... S3, S4 ...
 └───┘        └───┘

Pros: cheap, simple to reason about, easy to add nodes.
Cons: hub failure takes down everything; all east-west traffic traverses the hub.
Fit: any fleet ≤ ~10 hosts on one site. This is what almost every homelab actually is at L2.

Full Mesh

Every node has a direct link to every other node.

S1 ←→ S2   S1 ←→ S3   S1 ←→ S4
S2 ←→ S3   S2 ←→ S4   S3 ←→ S4     n(n-1)/2 links = 6 for 4 hosts

Pros: no single point of failure; direct paths, low latency between peers.
Cons: link count grows quadratically — 10 hosts need 45 links. Config burden explodes.
Fit: only tiny sets of critical peers (e.g., database replication pairs), or as a logical overlay (WireGuard mesh) where "links" are virtual and cheap.

Hybrid (star + overlay mesh)

Physical star at each site, plus a logical mesh (WireGuard) across sites/VLANs for the traffic that matters.

Site A (star)                 Site B (star)
  R ── S1,S2,S3                R ── S4,S5
  │                             │
  └──────── WireGuard mesh ─────┘
       S1↔S4  S1↔S5  S2↔S4 ...   (only needed tunnels, not all pairs)

Pros: physical simplicity + logical resilience; tunnels are config, not cable.
Cons: two layers to troubleshoot; key management overhead.

Choosing One

Decision rules of thumb:

Question	If yes
All hosts on one switch?	Star is fine; don't over-engineer.
Two or more sites / VPS + home?	Add an overlay mesh (hybrid).
Need host-to-host traffic to survive router loss?	Mesh overlay among those hosts.
More than ~10 hosts?	Segment first (see virtual-networks); topology follows segmentation.

For fogserv.cloud (small fleet behind Cloudflare DNS, Caddy/Traefik ingress, Linux hosts): hybrid. The public path is already effectively a star terminating at Cloudflare → your edge reverse proxy. East-west and admin access run over a partial WireGuard mesh rather than exposing SSH publicly.

Fogserv Reference Topology

Internet
   │
Cloudflare (proxy/WAF)          ← logical edge, see cloudflare-dns
   │ 443 only
Edge host: Traefik/Caddy        ← the only host with published ports
   │
LAN switch (star)               10.10.0.0/24 services VLAN
   ├── web-01    10.10.0.11
   ├── db-01     10.10.0.21      (mgmt via wg only)
   └── nas-01    10.10.0.31
   │
WireGuard mesh 10.100.0.0/24    ← see wireguard-setup
   wg0: edge=10.100.0.1  web=10.100.0.2  db=10.100.0.3  laptop=10.100.0.10

Rules encoded by this shape:

Only the edge host accepts inbound from the internet (firewalls-nftables).
db/nas management planes are reachable only over the WG mesh.
Adding a host = one switch port + one peer stanza. No cabling changes.

Practical Examples

Verify your actual topology from any host:

# Who can I reach directly at L3?
ip route get 10.10.0.21
# 10.10.0.21 dev wg0 src 10.100.0.2   → goes over the mesh

# Map which peers exist in the mesh
sudo wg show wg0 peers | wc -l

# Find the physical chokepoint: trace to the internet
traceroute -n 1.1.1.1
# hop 1 is always your router → confirms star dependency

Test blast radius: pull the uplink to your edge host (or sudo ip link set eth0 down in a VM test). Everything public should fail closed at Cloudflare with a 5xx origin error — not fall back to some unencrypted side door.

Troubleshooting & Common Pitfalls

Problem	Cause	Fix
East-west traffic slow after adding mesh	Both hosts route via mesh instead of local switch	Keep LAN subnets out of mesh `AllowedIPs` unless intended; see wireguard-setup
Single switch reboot kills monitoring too	Monitoring shares the same star hub	Run uptime probes externally (Cloudflare/Uptime Kuma off-host); see monitoring-networks
Accidental full-mesh growth	Peers added ad hoc per project	Maintain a peer inventory table; add tunnels only when a requirement exists
"Topology" differs per host's view	Stale docs	Document shape once here, reference from README

Next Steps / Ops Actions

Implement the mesh layer: wireguard-setup
Segment VLANs before scaling past ~10 hosts: virtual-networks
Lock down the edge host: firewalls-nftables, ../security/firewall-basics
Deeper security-zone rationale: ../security/network-segmentation

Sources & Related

External references consulted:

Change Log

2026-08-26

Initial creation: topology comparison, decision criteria, fogserv reference layout.