SummitStack node has customer ports that are under the control of its single central processor. In a SummitStack, failure of the primary node results in all ports that require that node's processor for normal operation going down. The remaining SummitStack nodes' ports continue to function normally.
As described in the section Understanding System Redundancy, if you configure at least two master-capable nodes in a SummitStack, one assumes the role of primary and the other assumes the role of backup.
The primary node provides all of the switch management functions including bringing up and programming the other (standby) nodes in the SummitStack, running the bridging and routing protocols, and configuring the switch. The primary node also synchronizes the backup node in case it needs to take over the management functions if the primary node fails.
The configuration is one of the most important pieces of information checkpointed to the backup node. Each component of the system needs to checkpoint whatever runtime data is necessary to allow the backup node to take over as the primary node if a failover occurs, including the protocols and the hardware-dependent layers. For more information about checkpointing data and relaying configuration information, see Replicating Data Between Nodes.
Not all protocols support hitless failover. Layer 3 forwarding tables are maintained for pre-existing flows, but subsequent behavior depends on the routing protocols used. Static Layer 3 configurations and routes are hitless. You must configure OSPF (Open Shortest Path First) graceful restart for OSPF routes to be maintained, and you must configure BGP (Border Gateway Protocol) graceful restart for BGP routes to be maintained. For more information about OSPF, see OSPF and for more information about BGP, see BGP. For routing protocols that do not support hitless failover, the new primary node removes and re-adds the routes.
Print
this page
Email this topic
Feedback
View PDF
Download EPUB