A university core uses dual-supervisor Catalyst switches carrying voice and research traffic that cannot tolerate control-plane resets during an active supervisor failure. The design requires continuous forwarding and peer routers to retain adjacencies. Which graceful restart and NSF/SSO mechanism best delivers hitless supervisor failover?
Select an answer to reveal the explanation.
Short Explanation
You need the core to keep forwarding and preserve its routing adjacencies when a supervisor fails. SSO with NSF-capable supervisors and NSF-aware peers lets the standby take over while peers retain routes during graceful restart.
Full Explanation
Continuous forwarding with stable adjacencies during supervisor loss requires both state synchronization and cooperative routing recovery. SSO with NSF-capable supervisors and NSF-aware peers uses graceful restart to maintain forwarding state on the standby while peers retain routes during the grace period, avoiding control-plane resets for voice and research traffic. SSO alone synchronizes chassis state and can sustain Layer 2 forwarding, but routing neighbors must detect the restart and rebuild adjacencies, violating the requirement to retain them. NSF graceful restart alone can request timer extensions from peers, but without a hot, synchronized standby it cannot preserve forwarding hardware state; control-plane recovery may interrupt forwarding despite the grace period. HSRP provides first-hop gateway redundancy for hosts, but does not preserve core IGP or BGP adjacencies or forwarding continuity for research paths. On exams, distinguish NSF-capable devices that can restart gracefully from NSF-aware peers that honor grace periods, and do not confuse planned ISSU upgrades with protection from an unplanned supervisor failure. In practice, verify SSO mode, hot standby status, protocol NSF enablement, and peer grace reception with show redundancy, show cef state, and protocol-specific NSF status before testing a switchover in maintenance.