Reliability starts with a service requirement—not a count of backup devices
A network is reliable only in relation to something it must keep doing. “We have two routers” is an inventory fact. A stronger statement is: “The student testing application must remain usable after one WAN circuit fails, with no more than the allowed interruption and without bypassing security policy.” That requirement tells you what failure to test and what success must look like.
Check the difference between device uptime and useful service recovery with the AP Networking Network Design and Redundancy Practice Test. The explanations trace name resolution, identity, backend state, power, and capacity dependencies so a successful cable-failure test is not mistaken for proof of every outage case.
Draw what the service depends on before calling anything redundant
Reliability improves when the alternative removes the actual failure domain. If two devices share power, two links share conduit, or two services share one host, the diagram contains redundancy at one layer and a common dependency at another.
Ask which components can fail together
Physical
Conduit, fiber path, rack, building, cooling, power circuit, UPS, and provider entrance can create common-cause failures.
Network
One switch, router, firewall, gateway, trunk, routing neighbor, or upstream device can remain shared by apparently diverse paths.
Service
DNS, DHCP, authentication, NAT, application backends, and management systems can make transport redundancy irrelevant to the user's outcome.
Configuration
A bad policy, route, automation push, or identical misconfiguration can affect redundant devices simultaneously even when hardware is independent.
Extra components create options; fault tolerance describes the service outcome
Redundancy means additional components, paths, or instances exist. Fault tolerance is stronger: the service continues through a defined failure within the required interruption/performance boundary. A redundant design can still have a visible outage while routing, spanning tree, clustering, or another control mechanism reconverges.
| Claim | What it establishes | What remains unproven |
|---|---|---|
| Two WAN circuits exist | Additional physical connectivity | Independence, routes, NAT/policy, capacity, DNS, service |
| Backup route is installed | Forwarding has an alternate | Application, return path, security, performance |
| Application works after failure | Tested service survived that failure | Other services/failures unless separately tested |
| Prohibited flow remains blocked | One security control survived failover | Other controls/flows unless tested |
Swipe horizontally to see the full evidence table.
Count dependencies, not boxes
Two servers behind one nonredundant access switch still depend on that switch. Two Internet circuits connected to one edge router still depend on that router. Two access points powered by one failed PoE switch can disappear together. Two DNS servers on one virtualization host can fail together.
A single point of failure is therefore not necessarily a single device drawn alone. It can be a shared resource that sits underneath several apparently redundant components.
Continue with Single Point of Failure and Network Redundancy Explained.
A backup path needs detection, selection, transition, and usable service
Routing protocols, spanning tree, link aggregation, gateway redundancy, clustering, and load balancers use different mechanisms, but the reasoning is similar. A physically present backup that is never selected does not provide operational resilience.
User-visible outage includes more than convergence
A link may fail instantly, but detection can take time. Forwarding can then reconverge, while application sessions may require additional recovery. This is why “the backup route appeared” and “users experienced no meaningful interruption” are different claims.
For an AP Networking scenario, name which stage the evidence proves. A routing table can prove path selection; it does not by itself prove the application session recovered.
Backup capacity must match the failure-state requirement
Suppose the primary WAN is 1 Gb/s and normally carries 650 Mb/s during a critical testing period. The backup is 200 Mb/s. Routing can fail over correctly and ping can work, yet the backup is oversubscribed by the normal workload.
| State | Available path | Offered load | Likely result |
|---|---|---|---|
| Normal | 1 Gb/s primary | 650 Mb/s | Capacity headroom remains |
| Primary failed | 200 Mb/s backup | 650 Mb/s demand | Queueing/loss/application degradation likely |
| Failure with traffic prioritization | 200 Mb/s backup | Critical subset | May meet a deliberately reduced requirement |
Reliability can therefore require either enough spare capacity or a documented degraded-service plan that prioritizes critical traffic.
Standby resources can fail silently
A backup circuit that is never used can accumulate errors, lose routing, have expired credentials, or become misconfigured without immediate user impact. Monitoring should therefore cover primary and standby dependencies: interface state/errors, routing adjacency, device health, power, service probes, utilization, latency, loss, and capacity trends.
A backup that worked last year may be undersized today
Growth changes reliability without changing the topology. More clients, cloud traffic, cameras, voice, backups, or application demand can consume the spare capacity that failover depends on. A path that once carried the entire site during testing may later support only a fraction of normal demand.
Track normal utilization and failure-state headroom over time. Capacity planning is part of reliability because the network must work under the failure condition, not merely during normal operation.
Use Network Scaling Problems for the growth side of this analysis.
Availability cannot come at the cost of bypassing policy
A primary route may traverse the intended firewall and inspection policy while an alternate route uses different interfaces or rules. If failover restores the application but accidentally permits traffic that should be denied, availability improved while security regressed.
Two WAN links, one edge router
A school has ISP A and ISP B, but both terminate on Router R1. ISP A fails and traffic uses ISP B successfully. The design is redundant against the tested ISP/link failure. It is not redundant against failure of R1.
Bounded claim: the second circuit reduces one failure domain but leaves the edge router shared. If the requirement says the school must survive an edge-router failure too, another independent forwarding path is needed.
Two core switches, one UPS
Core A and Core B have separate links and routing. A power event takes down the single UPS feeding both. The data-plane diagram looked redundant, but the dependency map was incomplete.
Next discriminating evidence: power-feed documentation and rack/UPS dependency. Adding another data link would not address this failure; the change must target the shared power domain.
Failover succeeds for ping but the application fails
After WAN 1 is disabled, the route table selects WAN 2 and remote numeric IPs respond. The web application still fails because DNS requests cannot reach the resolver through the backup policy.
Evidence boundary: successful ping proves some IP forwarding, not complete application availability. The next evidence should test DNS resolution and backup-path policy before changing unrelated routing.
The backup path works—but only until peak demand
A 250 Mb/s backup passes an overnight failover test when site demand is 90 Mb/s. During a daytime outage, demand reaches 500 Mb/s and critical applications degrade.
The original test proved path availability at low load, not failure-state capacity. A stronger test uses a representative workload or a documented capacity model and verifies critical traffic under realistic demand.
Test the failure you claim to survive
| Step | Evidence to capture | Question answered |
|---|---|---|
| Baseline | Path, route, service, latency/loss, utilization | What does healthy normal look like? |
| Induce defined failure | Timestamp and failed dependency | Did we test the intended failure? |
| Observe recovery | Neighbor/route/path state | Did the recovery mechanism activate? |
| Positive service test | Required app/flow | Did the service survive? |
| Negative security test | Representative denied flow | Did policy survive? |
| Capacity check | Utilization, delay, loss, app behavior | Is the alternate adequate? |
| Restore primary | Path/state and service retest | Does restoration behave correctly? |
Swipe horizontally to see the complete test plan.
When redundancy fails, localize the first unresolved dependency
Start with the affected population and original requirement. Preserve known-good evidence. If primary WAN failed and the backup route never appeared, investigate detection/routing before DNS. If the route appeared and numeric IP works but names fail, move the boundary to DNS. If the app works but performance collapses, investigate capacity rather than path existence.
Replace “add redundancy” with a specific reliability argument
A weak answer says, “Add another router for reliability.” A stronger answer says: “The current design has two WAN links but both depend on Router R1. If the requirement is to survive one edge-router failure, add an independent edge forwarding path, ensure both WAN/policy paths can carry the required service, then test by removing one router and verifying the application and security controls.”
This names the requirement, existing failure domain, targeted design change, and proof.
Match the evidence to the claim you are allowed to make
| Evidence | Safe claim | Do not overclaim |
|---|---|---|
| Backup link is physically up | Physical link is available | Service failover works |
| Alternate route becomes active | Forwarding selected an alternate | All apps/security/capacity are healthy |
| Required app succeeds | That app survived the tested failure | Every service survives every failure |
| App + negative policy test + load test pass | Tested requirement is strongly supported under that failure/load | Untested failures are covered |
24 network reliability flashcards
Use these cards to practice failure domains, redundancy boundaries, failover evidence, capacity, monitoring, recovery, security, growth, and AP Networking reliability explanations. Filter the deck, shuffle it, or work through all 24.