What else stops when one device fails?

Look beyond the failed device to the work it disrupts↑

A failure domain covers more than the failed component: it includes the affected endpoints and business tasks. One cause can produce symptoms in several places, so record the cause and its effects separately.

If A1 stops, PC-A loses its only connection. PC-B on A2 may remain connected. But if the authentication service used by both endpoints runs on a server reachable only through A1, PC-B may also be unable to log in for a new business task. Its physical link is healthy, yet the user cannot access the application.

Writing “only endpoints on A1 are affected” would omit that shared-service dependency. Start with the failed device, identify the connections it takes down, and follow those connections to the business tasks that need them. Be specific about user actions: an already authenticated session may behave differently from a new login.

To narrow down the failure domain, also compare endpoints where the same task still works. Try that task from another segment and compare addressing, name resolution, authentication, and responses. One successful attempt does not prove that the whole service is always healthy, but it helps identify shared and differing dependencies.

Describe the failure domain in terms of business functions as well as devices. If a printer and an authentication service share a switch, losing both the printer and the server may affect more services than the endpoint count suggests. Distinguish connections lost directly from business tasks that subsequently fail because they depend on those functions.

For each failure, compare the expected outage scope with what the business can tolerate. A small site may accept a complete outage while a device is replaced; another site may need separate sections so that only one area stops. Before trying to shrink a failure domain, identify the business requirement that separation must meet.

Overlay power, cabling, logical connections, and service dependencies↑

Several kinds of failure boundaries overlap in one network. A physical diagram or a VLAN list alone cannot show the full scope of every failure.

For physical dependencies, trace each device's power input through the PDU to its supply circuit. For fiber, the conduit between buildings matters more than simply using different ports. D1 and D2 may be separate devices, but a power outage or damaged conduit can take both down if they share those dependencies.

For logical dependencies, check how far each VLAN extends and where routing boundaries sit. An L2 problem can affect segments sharing a VLAN, but a routing boundary does not contain every service failure. Dependencies on upstream paths and shared control functions still need separate review.

At the service layer, map name resolution, authentication, address assignment, and application servers. A list showing two DNS servers does not establish independence: both servers may run on the same virtualization host or storage. Different server addresses do not help if losing that host or storage makes both servers unavailable.

Shared DNS does not mean every connection must fail immediately. Flows that already know an address may be affected at a different time from requests that need fresh name resolution. Record both the dependency and when it is used, so the predicted failure domain can be compared with actual observations.

Finally, add management access and change processes to the map. Does emergency management access use the same path as the failed service? Does one configuration template update several blocks at once? Drawing management and configuration-deployment paths alongside user packet paths helps reveal how redundant devices could still stop together during operations.

The network below has separate paths through D1 and D2, but those devices share one power circuit, and the two DNS servers share one host. Overlaying power and service dependencies on the solid packet paths shows where two devices can still fail together.

Trace power, conduits, and configuration changes for D1 and D2 separately. This reveals where one problem could stop both devices despite having two of them.

Check whether one incident can cut both paths↑

Two devices and two links can still fail from the same cause. Check which power and cabling dependencies are separate and which segments remain shared.

Suppose D1 and D2 plug into different power strips. If both strips use one supply circuit, they are not independent of a circuit failure. This arrangement may help with the failure of one power strip, but losing the entire circuit can still stop both devices. Give power-strip failures and supply-circuit outages separate rows in the test plan.

Two fiber links may use different ports yet pass through the same conduit X. Disconnecting one link may leave an alternate path, while conduit damage removes both. If an independent path Y is added, compare cabling records with the actual installation to verify that X and Y take different physical routes. Different colors on a drawing do not separate links running through the same conduit.

Shared software and configuration errors are another common cause. Using the same model and configuration can simplify consistent operation, but one defect or bad change may affect both devices. Mixing different platforms by default creates new management and interoperability risks, so that choice also needs justification.

If path separation has not been verified, say so in the documentation. Different carriers may still share a building-entry conduit or intermediate facilities. Distinguish contractual separation from the physical routes you can actually verify, and record unverified shared segments as residual risks.

Before multiplying two devices' failure probabilities in an availability calculation, explain assumptions such as independence. Here, instead of calculating availability from unverified probabilities, we examine which functions keep working after each failure. Common causes that cannot be verified remain separate documented risks.

Separate design and change units where the impact would be too broad↑

To limit an outage, separate devices and paths so that a problem in one area does not stop work in another, while preserving required communication. Dividing every segment as finely as possible may only add connections and policies to manage. Separate what the business needs separated.

First ask whether endpoints in different wiring closets must share an L2 segment. If they only need IP connectivity, extending a VLAN across those closets may be unnecessary; compare a design that places the routing boundary closer to them. Check applications requiring address mobility or L2 adjacency before making that choice.

Compare design units with change units. If block B must stay operational while block A is serviced, look for any shared task that still changes both at once. Separate hardware does not limit the impact of an automated change applied to both blocks simultaneously.

Aligning address plans with blocks helps describe scope and create route summaries. It does not, by itself, contain physical failures or shared-service outages. Compare address boundaries, VLAN extent, power, and cabling on one diagram, and explain where their boundaries differ.

Here we first establish which devices and business tasks a single failure affects. The redundancy article examines how quickly traffic switches to an alternate path. Designing failure domains and measuring actual failover time are separate, necessary tasks.

Where a single failure occurs determines which endpoints disconnect and which paths remain. Compare the functions lost in these four cases.

Account for the extra operational work that separation creates↑

Separating failure domains creates new connections and management tasks. Compare the reduction in outage impact with the added operational complexity to find a design you can actually maintain.

More VLAN and routing boundaries mean more addresses, routes, and policies to manage. Distributing shared services also requires consistent data and configuration, plus failure detection and recovery procedures. Adding devices is only the start: configurations and policies must stay aligned, and failover must be checked throughout operation.

Without clear ownership for each segment, incident response can fall back on temporary workarounds and policy exceptions. Record which team changes configurations, who checks business impact, and where rollback materials are stored. If the design's boundaries do not match operational responsibilities, even a small change can leave teams unsure who should check and act.

If current staffing and checks cannot sustain a design, compare a simpler alternative. Can it still meet the required outage scope and recovery time? Record any shortfall as an accepted risk. Judge a design by whether it can sustain the required availability, not by device count or diagram complexity.

Smaller domains can add connections and policies to manage; larger domains can widen the impact of one change. Neither is always better. Compare the complexity operators can handle with the outage scope the business can tolerate.

Leave an impact table for each failure and diagrams showing device and service dependencies. Operators should be able to see which business tasks remain available if a device, conduit, power source, service, or change process fails. During a real incident, comparing observations with these predictions can expose failures the design did not anticipate.