Network Topologies & Failure Domains

Physical attachment, logical forwarding, service reachability, and shared-risk structure are different topologies over the same system. This entry compares common graph shapes, shows how forwarding removes loops, and turns redundancy drawings into testable failure-domain claims.

budding working of working confidence: certain planted 2026-08-20 tended 2026-08-20 topologyredundancyfailure-domainsmeshspanning-tree

Topology is a graph: nodes joined by links. The hard part is declaring what the nodes and links mean. A physical topology may use switches and fibers; a logical topology may use routers and adjacencies; a service topology may collapse the entire underlay into one virtual link. RFC 8345 makes this layering explicit because no single graph answers every operational question.

Four common shapes #

A bus shares one medium, a star concentrates attachment at one center, a ring provides two directions only when forwarding supports them, and a partial mesh adds selected independent paths. Red marks a shared failure point rather than merely a visually central object.

Shape	Useful property	Structural cost or failure mode
point-to-point / chain	simple ownership and predictable path	an intermediate failure partitions everything beyond it
bus / multipoint medium	few physical attachments and native one-to-many observation	capacity and faults are shared; access must be coordinated
star	easy edge isolation and cabling	the center is a concentration point unless internally redundant
ring	two physical directions with bounded degree per node	an unprotected break partitions it; loop control is mandatory
tree	scalable hierarchy and simple upstream aggregation	upper links and nodes aggregate large failure impact
partial mesh	alternative paths where they are valuable	routing/control complexity and more failure combinations
full mesh	a direct link for every pair	$n(n-1)/2$ undirected links, impractical at large $n$

The graph shape does not determine the forwarding behavior. A physical ring may run a loop-free logical tree; a physical star can emulate one shared Ethernet segment; a routed mesh may expose a simple virtual point-to-point service.

Physical, logical, and service topology #

Consider two routers connected through a provider Ethernet service. The customer logical graph contains one adjacency. The provider graph may contain many bridges, protection paths, and fibers. Below those, two “independent” links may share a conduit. Above them, a tunnel topology may connect virtual routers that have no direct physical link.

Each layer should state:

node identity and its termination points;
whether links are directed or bidirectional;
which lower-layer nodes and links realize each higher-layer link;
metrics and constraints used for path selection;
shared-risk groups not visible in the logical graph.

Without this mapping, an overlay can route two replicas over paths that look disjoint but converge on the same underlay failure.

Loops are physical options and forwarding hazards #

Redundant links create graph cycles. Cycles are useful because they provide alternate paths, but uncontrolled forwarding can circulate traffic indefinitely. A forwarding system therefore needs one of three broad strategies:

Disable selected links to form a spanning tree for the active forwarding graph.
Compute loop-free next hops from a common topology and reconverge after change.
Carry explicit path or hop state that constrains where each unit may go.

IEEE 802.1Q bridges can organize bridged LANs and VLANs while loop-control mechanisms select usable forwarding paths. Routed networks instead compute next hops from routing information. Neither makes the physical cycle disappear; it controls how packets traverse it.

A spanning tree connects all $n$ reachable nodes with $n-1$ links and no cycles. A minimum spanning tree minimizes the sum of selected edge costs, but minimum total cost is not automatically the best operational design: it can overload one hub, maximize failure blast radius, or ignore latency and policy constraints.

Failure domains are hyperedges, not circles on a rack diagram #

A failure domain is the set of components or services affected by one cause. That cause can be:

one chassis, line card, power feed, rack, room, or conduit;
one software release or configuration push;
one routing or spanning-tree control plane;
one provider, region, identity service, or certificate authority;
one shared spectrum channel or upstream bottleneck.

These sets overlap, so they are not a simple hierarchy. Two switches on different power feeds can still share software and control-plane failure. Two fibers on different ports can share the same trench. Mark the cause and the affected set, not merely a colored “zone.”

Validate a topology claim #

For every required communication pair:

Enumerate the steady-state forwarding path and all lower-layer realizations.
Remove one named failure domain—not only one logical edge.
Recompute reachability and remaining bottleneck capacity.
Check convergence behavior, transient loops, and stale state.
Repeat for maintenance states, because redundancy often disappears during an upgrade.

Graph connectivity is necessary but insufficient. The surviving path must also preserve addressing, policy, MTU, timing, and capacity. A topology becomes operationally meaningful only when those conditions and the failure cause are explicit.