Caveats for a SummitStack
The following describes the hitless failover caveats for a SummitStack:
- All customer ports and the stacking links connected to the failed
primary node will go down. In the recommended stack ring configuration, the stack becomes a
daisy chain until the failed node restarts or is replaced.
- A brief traffic interruption (less than 50 milliseconds) can occur
when the traffic on the ring is rerouted because the active topology becomes a daisy
chain.
- Since the SummitStack can contain more than two master-capable nodes,
it is possible to immediately elect a new backup node. If a new backup node is elected, when
the original primary node restarts, it will become a standby node.
- To simulate the behavior of a chassis, a MAC address of one of the
nodes is designated as the seed to form a stack MAC address. When a failover occurs, the
SummitStack continues to be identified with this address.
- During an OSPF (Open Shortest Path First) graceful restart, the
SummitStack successfully restores the original link state database only if the OSPF network
remains stable during the restart period. If the failed primary node provided interfaces to
OSPF networks, the link state database restoration is prematurely terminated, and
reconvergence occurs in the OSPF network due to the failover. See OSPF for a description of OSPF and the
graceful restart function.
- During a BGP (Border Gateway Protocol) graceful restart, the
SummitStack successfully restores the BGP routing table only if the BGP network remains
stable during the restart period. If a receiving speaker detected the need for a routing
change due to the failure of links on the failed primary node, it deletes any previous
updates it received from the restarting speaker (the SummitStack) before the restart
occurred. Consequently, reconvergence occurs in the BGP network due to the failover. See
BGP for a description of BGP and its
graceful restart function.
Print
this page
Email this topic
Feedback
View PDF
Download EPUB