1.1Enterprise network design principles and high availability

The architecture domain of ENCOR is not a test of memorizing model names. What is asked is the judgment of which layered topology and which redundancy technology to combine for a given availability requirement, failure mode, and operational constraint. Even within "duplication," duplicating the devices themselves (stacking/VSS), duplicating the supervisor inside a device (SSO), and duplicating the default-gateway role (FHRP) each protect against different failures, take different amounts of time to converge, and lose different things during the switchover. This section organizes how to choose a design model and which single point of failure each redundancy technology removes.

1.1.1Choosing a design model

• A 3-tier design splits the network into an access layer (endpoint connectivity), a distribution layer (policy application, aggregation, and the L2/L3 boundary), and a core layer (a backbone dedicated to fast, simple forwarding). Because faults and configuration changes are contained within each distribution block, it pays off most in large campuses with many buildings or blocks. As a rule no policy is placed in the core, preserving simplicity and stability of forwarding.
• A 2-tier (collapsed core) merges distribution and core into a single layer. At small-to-medium scale with few blocks, standing up a separate core mostly adds transit hops and hardware cost without materially improving availability, so collapsing is the sound judgment. Be aware, however, that as blocks multiply all interconnects concentrate on the collapsed layer, which tends to force a redesign when you later expand.
• A fabric overlays a logical network built by encapsulation—the overlay—on top of an underlay that provides physical reachability. Because policy can be distributed without being bound to VLANs or cabling, it is adopted in campuses and data centers that need the same policy applied regardless of location. Cloud places workloads on provider infrastructure; for site design it becomes a WAN/security question of where traffic terminates, how it is encrypted, and which path it egresses.

1.1.2Which single point of failure each technology removes

• A FHRP (First Hop Redundancy Protocol) has multiple routers/L3 switches share a virtual IP (the default gateway) so that a standby takes over when the active device fails. It removes the single point of failure of the gateway device going down, letting hosts keep communicating with no configuration change. The main examples are HSRP (Cisco; Active/Standby; default priority 100; preempt disabled by default) and VRRP (standard; Master/Backup; preempt enabled by default).
• SSO (Stateful Switchover) keeps redundant supervisors within a single chassis; when the active fails, the standby inherits state and continues control. What it removes is a supervisor (control engine) failure, not a power-system or upstream-link failure. SSO carries over L2 state and configuration, but the practical point is that maintaining routing-protocol adjacencies requires companion features such as NSF/NSR.
• Stacking and VSS treat multiple physical chassis as one logical switch. Beyond consolidating management, the biggest design benefit is that a MEC (multi-chassis EtherChannel) can span both chassis, so downstream switches see redundant links as a single logical link and avoid STP blocking. It removes chassis-level failure, but the flip side is that since it is logically one device, a software upgrade affects the whole thing.

1.1.3Selecting technology from the availability requirement

• If the requirement is "endpoint traffic must survive the loss of one gateway device," the answer is FHRP. If it is "a single chassis must not go down when the control engine fails," it is SSO. If it is "redundant links must carry traffic rather than idle, without waiting for STP reconvergence," it is stacking/VSS plus MEC. Identifying the failure mode the requirement is really describing first is the shortest path to not choosing wrong.
• More redundancy is not automatically better. Stacking FHRP, stacking, and SSO indiscriminately makes switchover events cascade across layers and convergence harder to predict. The design discipline is to decide where the L2/L3 boundary sits and pick one redundancy pairing that matches that boundary. Additionally, the convergence-time requirement (seconds versus sub-second) determines whether timer tuning or BFD is needed.

Suppose you operate a two-building, six-block campus and receive a report that "rebooting one of the distribution switches once a quarter causes roughly 15-30 seconds of outage for user endpoints." In the topology, access-layer L2 switches uplink to two distribution switches over two separate L2 links, and the two distribution switches run HSRP to make the default gateway redundant. The classic misdiagnosis here is to think "HSRP is deployed, so failover must already be fast." Checking show standby shows HSRP itself takes over Active within a few seconds, yet the outage is far longer—and that gap is exactly where the cause lives: what is slow is not the L3 gateway failover but the L2 topology recomputation beneath it. Because the two uplinks from access are separate L2 links, one of them is blocked by STP, so when the upstream device goes away you must wait for the blocked port to transition to forwarding. The sound remedy is to bond the two distribution switches into one logical device with VSS (or stacking) and turn the two access uplinks into a single logical link as a MEC. Downstream, the redundant links are then always forwarding, a reboot of one chassis is absorbed sub-second as the loss of one EtherChannel member, and neither an HSRP failover nor an STP reconvergence occurs at all (with a single logical gateway, FHRP is no longer needed). Choosing only to "shorten the HSRP hold timer" makes L3 failover faster but leaves the L2 reconvergence wait intact, so it is a partial fix, and tightening timers too far risks spurious flaps on brief glitches. Likewise, "deploy SSO-capable hardware at the access layer" addresses a different single point of failure (supervisor failure) than the reported mode (failover during a planned single-chassis reboot) and does not match the symptom. Decomposing the timeline of the symptom and identifying which layer's convergence dominates, before selecting technology, is how this class of design problem is solved.

1.1.4Section summary

• Choose the design model by scale and requirement: 3-tier for large deployments with many blocks, 2-tier (collapsed core) for few, and a fabric (underlay plus overlay) for location-independent policy distribution
• Choose redundancy by the single point of failure you want to remove: the gateway device is FHRP (HSRP/VRRP), the in-chassis control engine is SSO (with NSF/NSR to keep adjacencies), and the chassis itself is stacking/VSS
• Diagnose slow-failover symptoms by decomposing which layer's convergence dominates; when L2 reconvergence dominates, the root fix is VSS/stacking plus MEC so redundant links always forward