3 Measuring Topologies with Graph Metrics
Graph Metrics, Failure Domains, Scale Limits, Routing Overhead, and Evidence-Based Topology Decisions
3.1 Start With the Story
Suppose two network sketches both look tidy, but one loses half the building when a parent node fails and the other only slows down. Topology analysis is the habit of proving that difference before release. You turn the drawing into graph metrics, failure-domain evidence, scale limits, and routing-overhead notes so a reviewer can see what the shape can actually survive.
3.2 Overview: Topology Analysis Turns Diagrams Into Evidence
A topology diagram is a useful sketch, but analysis asks what the sketch proves. Model devices and links as a graph, measure the paths that traffic depends on, and test which nodes, links, gateways, channels, power sources, or ownership boundaries can break the service.
The goal is not to crown one topology name as good or bad. Star, tree, ring, mesh, bus, and hybrid patterns all work in the right conditions. A design is defensible when its metrics, failure behavior, and field evidence match the deployment constraints.
Consider a warehouse design where forty shelf sensors appear to form a healthy wireless layout because every sensor can reach a gateway during installation. The graph record may tell a different story: most routes still cross one relay aisle, the gateway has the highest degree, and the cold-room sensors have longer retry paths than the rest of the floor. A useful analysis records those dependencies before release. It asks which nodes become unreachable if the relay aisle loses power, whether alarms still arrive during a burst, and whether operations can see the difference between weak radio links, gateway queues, and application ingestion delays.
If you only need the intuition, this layer is enough: count the graph, identify the busiest and weakest dependencies, remove one likely failure, and record what evidence would make the topology safe to reuse.
Nodes
Devices, routers, access points, gateways, brokers, cloud services, and any boundary whose failure changes reachability.
Edges
Radio links, cables, uplinks, tunnels, broker paths, or logical dependencies that carry traffic between nodes.
Paths
Hop sequences for the flows that matter: telemetry, commands, local control, diagnostics, and recovery traffic.
Failure Domains
Shared dependencies that can disconnect devices even when the diagram appears to show alternate paths.
Overview Knowledge Check
3.3 Practitioner: Build the Topology Analysis Record
A practical analysis record should fit on one review page. It names the graph boundary, the metrics that matter, the failure probe, the operations evidence, and the trigger that reopens the decision when the site changes.
Use formulas as first-pass checks, not as deployment truth. A full mesh with `n` nodes needs `n(n - 1) / 2` links, while a partial mesh with average degree `k` has about `n * k / 2` links. Those numbers reveal maintenance pressure, but the decision still needs weighted links and failure probes.
Accept
The graph boundary, key metrics, failure probe, and operations evidence support the selected topology.
Constrain
Limit the topology decision to a named area, flow, gateway, traffic rate, device role, or ownership model.
Retest
Run a focused probe when node count, placement, relay role, traffic shape, or route behavior changes.
Hold
Do not approve when the graph hides a gateway, bridge link, power source, shared channel, or service dependency.
Practitioner Knowledge Check
3.4 Under the Hood: Failure Domains Decide Whether Metrics Matter
A topology can be connected and still be fragile. A graph has an articulation node if removing one node separates reachable groups. It has a bridge link if removing one link partitions traffic. It has a shared dependency when apparently redundant paths rely on the same gateway, switch, channel, power circuit, certificate, cloud service, or operating team.
Routing overhead also grows through the graph. Neighbor discovery, route maintenance, acknowledgements, retries, state storage, convergence, and sleep behavior can make a theoretically resilient topology expensive or unstable in the field.
This is why failure-domain evidence should be paired with weighted-link evidence. Removing a bridge link from an unweighted graph shows partition risk, but it does not show whether the alternate path is usable under battery, latency, duty-cycle, or interference constraints. A sleepy relay may be a valid backup for slow telemetry and a poor backup for command traffic. A redundant uplink may still share one power circuit or one operations team. The under-the-hood record should therefore name the assumed failure, the affected flows, the measured or observed weights, the degraded mode, and the exact condition that would require a retest.
Articulation Node
One node removal separates otherwise healthy devices. It needs redundancy, monitoring, or a documented acceptance decision.
Bridge Link
One link removal partitions traffic. Bridge links are common in tree branches, gateway uplinks, and under-connected meshes.
Shared Dependency
Two paths can still share one channel, breaker, uplink, credential store, or operator handoff.
Graceful Degradation
The strongest designs state what changes after failure: longer paths, buffering, alarms, local isolation, or lower sample rate.
Under-the-Hood Knowledge Check
3.5 Summary
Topology analysis makes a network design defensible by turning a diagram into a graph record. Count nodes and edges, measure degree, diameter, path length, and connectivity, then test what happens when a likely dependency fails.
The strongest topology records avoid topology-name shortcuts. They include weighted links, failure domains, routing overhead, operational evidence, limits, and a clear trigger for reopening the decision when device count, placement, traffic, ownership, or field counters change.
3.6 Key Takeaway
Trust a topology decision only when the graph metrics, failure probe, operations evidence, known limits, and recheck trigger all support the deployment claim.
3.7 See Also
Network Topologies: Basic Types
Review star, tree, ring, mesh, bus, and hybrid families before analyzing trade-offs.
Topology Selection
Turn analysis evidence into a bounded topology recommendation and recheck trigger.
Topology Failures
Study the failure modes that invalidate otherwise plausible topology diagrams.
Topology Management Techniques
Connect graph evidence to operational changes, rollback choices, and retest triggers.