Network Resilience and Redundancy Questions

Designing network layer resilience to avoid single points of failure and to ensure connectivity during outages. Topics include redundant links and devices, routing and path diversity, active active and active passive configurations, failover protocols such as Hot Standby Routing Protocol and Virtual Router Redundancy Protocol, border gateway and routing strategies, network segmentation, and monitoring and documentation for recovery. Candidates should be able to explain how network failures propagate and how to design networks that support application level high availability and disaster recovery plans.

EasyTechnical

53 practiced

What is Bidirectional Forwarding Detection (BFD) and how does it improve failover times for routing protocols? Explain how BFD integrates with OSPF, BGP and static routes, best practices for timer selection, and potential pitfalls when enabling BFD at scale (CPU, session state).

EasyTechnical

66 practiced

Describe active-active and active-passive device deployment models. For each model, list benefits and drawbacks in terms of performance, complexity, state synchronization, failure modes, and testing. Provide at least one example scenario where active-passive is preferable and one where active-active is preferable.

MediumSystem Design

100 practiced

You need to implement BGP multihoming for an enterprise edge with two ISPs. Describe an active-active and active-passive BGP edge design, including BGP session placement (two routers vs route-reflector), how to influence inbound/outbound traffic using AS-path prepending, communities, MED and local-pref, and how to avoid routing oscillations and asymmetric routing pitfalls.

Sample Answer

**Clarify requirements**- Two ISPs, single enterprise AS, want multihoming with predictable inbound/outbound traffic, resilience, and minimal routing churn.

**Active‑Active design**- Topology: two edge routers (R1, R2) each form eBGP with both ISPs if possible (full mesh) or with one primary ISP each plus iBGP between R1–R2.- BGP session placement: prefer two routers in same PoD; use iBGP between them (or a small route-reflector pair for scale).- Traffic engineering: - Outbound: set local‑pref on iBGP to prefer one exit per prefix (higher local‑pref wins). - Inbound: use AS‑path prepending on the ISP you want to de‑prefer; request ISP to honor well‑known communities (no-export, local‑pref manipulation) to steer more precisely. - MED: advertise MED to influence multi‑exit AS behavior when both ISPs are same provider (lower MED preferred). Only effective when ISPs exchange MED and AS relationships allow it.- Notes: keep consistent MED policies and only use AS‑prepends in small steps to avoid flapping.

**Active‑Passive design**- Topology: R1 is active (primary) with both ISPs; R2 is standby. iBGP between them; R2 only announces prefixes when passive failure detected (use BFD + BGP graceful restart).- Traffic engineering: - Outbound: R1 higher local‑pref; R2 lower. On failover, scripts change local‑pref or enable route announcements from R2. - Inbound: advertise full routes from R1; R2 either withdraws or advertises heavily prepended AS‑path until active fails.

**Avoiding oscillations & asymmetric pitfalls**- Configure deterministic next‑hop and loop prevention: ensure iBGP full mesh or route‑reflector with route‑reflection consistency.- Use route damping carefully; avoid aggressive damping that hides valid reconvergence.- Prevent oscillation: avoid conflicting policies (e.g., changing local‑pref based on inbound reachability without hysteresis). Implement hold‑down timers and BFD for fast failure detection.- Avoid asymmetric forwarding issues: ensure reverse path reachability by synchronizing default/gateway policies, advertise return paths, and apply consistent community tags so ISPs install symmetrical routes when required.- Testing & monitoring: simulate failovers, monitor AS‑path lengths, prefix origin, and use flow logs to verify actual paths.

This design balances control (local‑pref, MED) and coarse control (AS‑path prepending, communities) while protecting against churn via careful timers, consistent policies, and use of BFD/graceful restart.

MediumSystem Design

69 practiced

Design a leaf-spine EVPN-VXLAN solution to provide active-active multihoming for top-of-rack (ToR) switches serving 2000 VMs per site. Describe how EVPN Type-2/Type-5 routes, multihoming (DF election), and ARP/ARP/ND suppression are used to achieve fast failover and prevent MAC-flapping. Include a short note on MTU and any multicast considerations.

Sample Answer

**Clarify requirements & topology**- Two-site leaf‑spine per site, each site has two active ToR switches (multihomed) serving ~2000 VMs. VXLAN EVPN as underlay L3 fabric + L2 overlay for tenant networks.

**High-level design**- Use EVPN control-plane (BGP EVPN) to advertise MAC/IP via Type‑2 (MAC/IP) and Type‑5 (IP Prefix) routes. VXLAN encapsulation on Leafs; Spines carry underlay IP (IGP + MP‑BGP).

**Type‑2 vs Type‑5 roles**- Type‑2: advertise MAC + optional IP for local VMs — used for ARP/ND suppression and per‑MAC reachability.- Type‑5: advertise host routes for IP-only devices or to optimize inter-subnet forwarding (EVPN L3outs).

**Active-active multihoming & DF election**- Configure Ethernet Segment Identifier (ESI) on both ToRs and attach same ES to the VNI. Use EVPN multihoming with ESI and per-EVI DF election: DF elected per VNI (or per-IP/mask) via BGP bestpath rules to avoid duplicate BUM forwarding.- Preferred DF tie‑breakers: higher IP, then higher router-id. Non-DF ToR suppresses BUM (flood) locally but can still forward unicast — ensures active‑active forwarding without loops.

**ARP/ND suppression & MAC-flap prevention**- Enable ARP/ND suppression on leafs: the DF ToR responds to ARP/ND on behalf of remote VMs using advertised Type‑2 (MAC+IP) entries; eliminates broadcast ARP floods and speeds resolution.- Remote MAC learning performed from EVPN control-plane; data-plane learning disabled or suppressed to prevent MAC‑flapping across multihomed ToRs.- If both ToRs advertise same MAC, route target/ESI removes ambiguity; keep consistent MAC aging and use control-plane primacy.

**Fast failover**- Failure of DF triggers fast re-election; non‑DF immediately becomes DF for affected VNI so BUM resumes without ARP storm. Unicast path uses ECMP to remote Leafs — BGP convergence + underlay IGP timers tuned (BFD on adjacencies) for sub-second failover.

**MTU & multicast**- Ensure MTU accommodates VXLAN (UDP/encap ~50–60 bytes). Set underlay MTU ≥ 1600–9100 depending on jumbo support; verify DFZ path.- For multicast: prefer ingress replication to avoid multicast state scale, or mLDP/PIM in underlay if using multicast for BUM; with ARP suppression and DF, multicast state reduced.

**Operational notes**- Use BFD between peers, tune MAC/IP withdrawal timers, test failover scenarios. Monitor EVPN Type‑2/5 advertisements and ESI state to detect split‑brain.

MediumSystem Design

52 practiced

Design an active-active SD-WAN architecture across three branch sites and two data centers that ensures traffic is automatically steered away from failed WAN links or data center outages. Include overlay design, centralized policy, health checks, failover timers, and how the solution maintains application SLAs during failovers.

Sample Answer

**Situation & goals**Design active‑active SD‑WAN for 3 branches and 2 DCs so traffic is automatically steered away from failed WAN links or DC outages while preserving app SLAs.

**High‑level architecture**- Two data centers (DC-A, DC-B) and three branches (B1,B2,B3). Each site has two active WAN links (ISP1, ISP2) and a local SD‑WAN edge (vEdge/CPE or virtual appliance).- Full mesh overlay between all edges; BGP/MP‑BGP inside overlay for route distribution and preference.

Diagram (logical):B1-(ISP1/ISP2)-SD-WAN-Overlay-DC-A \-DC-B

**Overlay & routing**- IPSec tunnels between every pair of edges (full-mesh or via orchestrator hub). Tunnels carry multiple transport paths with per-path metrics.- Route selection uses weighted metrics: latency, jitter, loss, and path cost. Application-aware routing tags traffic classes (voice/video/ERP).

**Centralized policy & orchestration**- Orchestrator (controller) maintains centralized policies: - App classification, SLA thresholds (max latency, loss). - Preferred path lists and diversion rules. - Link health thresholds and failover timers.- Controller pushes policies and live telemetry to edges.

**Health checks & monitoring**- Active probes per path: ICMP + TCP+UDP synthetic transactions and application probes (SIP REGISTER, HTTP GET).- Continuous RTT, jitter, packet-loss sampling (1s granularity for voice, 5s for others).- Local and central monitoring with hysteresis to avoid flapping.

**Failover timers & behavior**- Two-tier timers: - Detect: 3 consecutive failed probes or loss > 5% over 5s → mark path degraded. - Failover hold-down: 10–30s (voice shorter ~10s) before permanent switch to alternate. - Recovery: path considered restored after 3 successful probe windows and stable for 30s.- Graceful reroute: session preservation using microflow pinning + symmetric steering; for TCP, use TCP reset avoidance where possible (re-route within short timer to keep flows via same session when path recovers).

**Maintaining application SLAs**- App-aware steering: traffic classes mapped to SLA policies. Realtime (VoIP) gets prioritized links and stricter probe cadence and lower failover timer.- WAN link bundling and dynamic path selection: if single path degrades, steering moves flows to best remaining path; for packet-loss sensitive apps use FEC or duplicate small RTP streams across both links during transient degradation.- DC outage handling: Controller instantly withdraws DC‑specific prefixes from overlay and redistributes, branches failover to remaining DC with sticky sessions preserved via application load balancer in DCs and DNS TTLs minimized; prepositioned active service instances in both DCs so routing switch is sufficient.

**Operational notes & tradeoffs**- Tune timers to balance detection speed vs false positives.- Use QoS, policing, and per‑tenant queues on edges.- Monitor telemetry and maintain runbooks for partial failures.- Tradeoffs: faster detection increases false positives; duplication/FEC increases bandwidth.

This design provides automated, application‑aware, active‑active resiliency across WAN links and DCs while maintaining SLAs via prioritized steering, fast detection, and controller‑driven policies.

Unlock Full Question Bank

Get access to hundreds of Network Resilience and Redundancy interview questions and detailed answers.

Join thousands of developers preparing for their dream job.