high availability configuration guide, cisco ios xe fuji ... ·...

High Availability Configuration Guide, Cisco IOS XE Fuji 16.9.x (Catalyst9400 Switches)First Published: 2018-07-18

Americas HeadquartersCisco Systems, Inc.170 West Tasman DriveSan Jose, CA 95134-1706USAhttp://www.cisco.comTel: 408 526-4000

800 553-NETS (6387)Fax: 408 527-0883

C O N T E N T S

Nonstop Forwarding with Stateful Switchover 1C H A P T E R 1

Prerequisites for Nonstop Forwarding with Stateful Switchover 1

Restrictions for Cisco Nonstop Forwarding with Stateful Switchover 1

Information About NSF with SSO 2

Overview of Nonstop Forwarding with Stateful Switchover 2

SSO Operation 3

NSF Operation 3

Cisco Express Forwarding 4

Routing Protocols 4

BGP Operation 4

EIGRP Operation 5

OSPF Operation 6

How to Configure Cisco NSF with SSO 7

Configuring SSO 7

Configuration Examples for Nonstop Forwarding with Stateful Switchover 8

Example: Configuring SSO 8

Verifying Cisco Express Forwarding with NSF 10

Additional References for Nonstop Forwarding with Stateful Switchover 11

Feature History Information for Nonstop Forwarding with Stateful Switchover 11

Configuring Graceful Insertion and Removal 13C H A P T E R 2

Restrictions for Graceful Insertion and Removal 13

Information about Graceful Insertion and Removal 13

Overview 13

Layer 2 interface shutdown 14

Custom Template 14

High Availability Configuration Guide, Cisco IOS XE Fuji 16.9.x (Catalyst 9400 Switches)iii

System Mode Maintenance Counters 15

How to Configure Graceful Insertion and Removal 15

Creating maintenance template 15

Configuring System Mode Maintenance 16

Starting and Stopping Maintenance Mode 17

Configuration Examples for Graceful Removal and Insertion 17

Example: Configuring maintenance template 17

Example: Configuring system mode maintenance 18

Example: Starting and Stopping maintenance mode 18

Example: Displaying system mode settings 18

Monitoring Graceful Insertion and Removal 19

Additional References for Graceful Insertion and Removal 19

Feature History and Information for GIR 20

Configuring Cisco StackWise Virtual 21C H A P T E R 3

Finding Feature Information 21

Prerequisites for Cisco StackWise Virtual 21

Restrictions for Cisco StackWise Virtual 22

Information About Cisco StackWise Virtual 23

Cisco StackWise Virtual on Cisco Catalyst 9400 Series Switches 23

StackWise Virtual Overview 23

Cisco StackWise Virtual Topology 23

Cisco StackWise Virtual Redundancy 25

SSO Redundancy 26

Nonstop Forwarding 26

Multichassis EtherChannels 26

MEC Minimum Latency Load Balancing 27

MEC Failure Scenarios 27

Cisco StackWise Virtual Packet Handling 28

Traffic on a StackWise Virtual link 28

Layer 2 Protocols 29

Layer 3 Protocols 29

Dual-Active Detection 31

Dual-Active-Detection Link with Fast Hello 31

High Availability Configuration Guide, Cisco IOS XE Fuji 16.9.x (Catalyst 9400 Switches)iv

Contents

Dual-Active Detection with enhanced PAgP 31

Recovery Actions 32

Implementing Cisco StackWise Virtual 32

How to Configure Cisco StackWise Virtual 33

Configuring Cisco StackWise Virtual Settings 33

Configuring Cisco StackWise Virtual Link 35

Configuring StackWise Virtual Fast Hello Dual-Active-Detection Link 36

Enabling ePAgP Dual-Active-Detection 37

Disabling Cisco StackWise Virtual 39

Verifying Cisco StackWise Virtual Configuration 40

Additional References for StackWise Virtual 41

Feature History and Information for Cisco StackWise Virtual 41

Configuring ISSU 43C H A P T E R 4

Prerequisites for Performing ISSU 43

Information About ISSU Process 43

Restrictions and Guidelines for Performing ISSU 44

Upgrade Software Using 1-Step WorkFlow 45

Upgrade Software Using 3-Step WorkFlow 45

Monitoring ISSU 46

Feature Information for ISSU 47

High Availability Configuration Guide, Cisco IOS XE Fuji 16.9.x (Catalyst 9400 Switches)v

Contents

High Availability Configuration Guide, Cisco IOS XE Fuji 16.9.x (Catalyst 9400 Switches)vi

Contents

C H A P T E R 1Nonstop Forwarding with Stateful Switchover

Cisco Nonstop Forwarding (NSF) works with the Stateful Switchover (SSO) feature to minimize the amountof time a network is unavailable to users following a switchover. The main objective of NSF SSO is to continueforwarding IP packets following a Route Processor (RP) switchover.

• Prerequisites for Nonstop Forwarding with Stateful Switchover, on page 1• Restrictions for Cisco Nonstop Forwarding with Stateful Switchover, on page 1• Information About NSF with SSO, on page 2• How to Configure Cisco NSF with SSO , on page 7• Configuration Examples for Nonstop Forwarding with Stateful Switchover, on page 8• Additional References for Nonstop Forwarding with Stateful Switchover, on page 11• Feature History Information for Nonstop Forwarding with Stateful Switchover, on page 11

Prerequisites for Nonstop Forwarding with Stateful Switchover• NSF must be configured on a networking device that has been configured for SSO.

• Border Gateway Protocol (BGP) support in NSF requires that neighbor networking devices be NSF-aware;that is, devices must have the graceful restart capability and advertise that capability in their OPENmessage during session establishment. If an NSF-capable device discovers that a particular BGP neighbordoes not have graceful restart capability, it does not establish an NSF-capable session with that neighbor.All other neighbors that have graceful restart capability continue to have NSF-capable sessions with thisNSF-capable networking device.

• Open Shortest Path First (OSPF) support in NSF requires that all neighbor networking devices beNSF-aware. If an NSF-capable device discovers that it has non-NSF-aware neighbors on a particularnetwork segment, it disables NSF capabilities for that segment. Other network segments composedentirely of NSF-capable or NSF-aware devices continue to provide NSF capabilities.

Restrictions for Cisco Nonstop Forwarding with StatefulSwitchover

The following are restrictions for configuring NSF with SSO:

• NSF does not support IP Multicast Routing, as it is not SSO-aware.

High Availability Configuration Guide, Cisco IOS XE Fuji 16.9.x (Catalyst 9400 Switches)1

• For NSF operation, you must have SSO configured on the device.

• All Layer 3 neighboring devices must be an NSF helper or NSF-capable to support graceful restartcapability.

• For IETF, all neighboring devices must be running an NSF-aware software image.

• The Hot Standby Routing Protocol (HSRP) is not supported with NSF SSO. Do not use HSRP with NSFSSO.

• An NSF-aware device cannot support two NSF-capable peers performing an NSF restart operation atthe same time. However, both neighbors can reestablish peering sessions after the NSF restart operationis complete.

• For SSO operation, ensure that both active and standby devices run the same version of the Cisco IOSXE image. If the active and standby devices are operating different images, SSO failover might causean outage.

Information About NSF with SSO

Overview of Nonstop Forwarding with Stateful SwitchoverCisco Nonstop Forwarding (NSF) works with the Stateful Switchover (SSO) feature. The device supportsfault resistance by allowing a standby switch to take over if the active device becomes unavailable. NSF workswith SSO to minimize the amount of time a network is unavailable.

Usually, when a networking device restarts, all routing peers of that device detect that the device went downand then came back up. This transition results in what is called a routing flap, which could spread acrossmultiple routing domains. Routing flaps caused by routing restarts create routing instabilities, which aredetrimental to the overall network performance. Cisco NSF helps to suppress routing flaps in SSO-enableddevices, thus reducing network instability.

Cisco NSF with SSO allows for the forwarding of data packets to continue along known routes while therouting protocol information is being restored following a switchover. With NSF/SSO, peer networkingdevices do not experience routing flaps. Data traffic is forwarded through intelligent line cards or dualforwarding processors (FPs) while the standby router processor (RP) assumes control from the failed activeRP during a switchover. NSF with SSO operation provides the ability of line cards and FPs to remain activethrough a switchover and to be kept current with the Forwarding Information Base (FIB) on the active RP.

NSF provides the following benefits:

• Improved network availability—NSF continues forwarding network traffic and application stateinformation so that user session information is maintained after a switchover.

• Overall network stability—Network stability can be improved with the reduction in the number of routeflaps that are created when devices in the network fail, and lose their routing tables.

• Neighboring devices do not detect a link flap—Because interfaces remain active during a switchover,neighboring devices do not detect a link flap (the link does not go down and come back up).

• Prevents routing flaps—Because SSO continues forwarding network traffic during a switchover, routingflaps are avoided.

• Maintains user sessions established prior to the switchover.


Nonstop Forwarding with Stateful SwitchoverInformation About NSF with SSO

• If the standby device does not respond, a new standby device is elected as the standby.

• If the active device does not respond, the standby device becomes the active device.

• If a stack member does not respond, that member is removed from the stack.

• If the standby device does not respond, a new standby device is elected.

• If the active device does not respond, the standby device becomes the active device.

SSO OperationWhen a standby device runs in SSO mode, the standby device starts up in a fully-initialized state andsynchronizes with the persistent configuration and the running configuration on the active device. Itsubsequently maintains the state of the protocols, and all changes in hardware and software states for featuresthat support SSO are kept in synchronization. Consequently, it offers minimum interruption to Layer 2 sessionsin a redundant active device configuration.

If the active device fails, the standby device becomes the active device. This new active device uses existingLayer 2 switching information to continue forwarding traffic. Layer 3 forwarding is delayed until routingtables are repopulated in the newly active device.

• If the standby device is not programmed with FIPS key, it will print warning messages since it is not inthe correct operating mode.

• The switch will work in SSO mode even if one supervisor (SUP) is not in FIPS mode i.e., one SUP is inFIPS mode and the other in non-FIPS mode.

Note

NSF OperationNSF always runs with SSO, and provides redundancy for Layer 3 traffic. NSF is supported by BGP, EnhancedInterior GatewayRouting Protocol (EIGRP), andOSPF routing protocols and also by Cisco Express Forwardingfor forwarding. These routing protocols have been enhanced with NSF-capability and awareness, which meansthat devices running these protocols can detect a switchover and take necessary actions to continue forwardingnetwork traffic and to recover route information from peer devices.

Each protocol depends on Cisco Express Forwarding to continue forwarding packets during switchover whilerouting protocols rebuild the Routing Information Base (RIB) tables. After the convergence of routing protocols,Cisco Express Forwarding updates the FIB table and removes stale route entries. Cisco Express Forwardingthen updates the hardware with the new FIB information.

If the active device is configured (with the graceful-restart command) for BGP, OSPF, or EIGRP routingprotocols, routing updates are automatically sent during the active device election.

NSF has two primary components:

• NSF-aware: A networking device is NSF-aware if it is running NSF-compatible software. If neighboringdevices detect that an NSF device can still forward packets when an active device election happens, thiscapability is referred to as NSF-awareness. Enhancements to the Layer 3 routing protocols (BGP, OSPF,and EIGRP) are designed to prevent route-flapping so that the Cisco Express Forwarding routing tabledoes not time out or the NSF device does not drop routes. An NSF-aware device helps to send routing


Nonstop Forwarding with Stateful SwitchoverSSO Operation

protocol information to the neighboringNSF device. NSF-awareness is enabled by default for EIGRP-stub,EIGRP, and OSPF protocols. NSF-awareness is disabled by default for BGP.

• NSF-capability: A device is NSF-capable if it is configured to support NSF; it rebuilds routing informationfrom NSF-aware or NSF-capable neighbors. NSF works with SSO to minimize the amount of time thata Layer 3 network is unavailable following an active device election by continuing to forward IP packets.Reconvergence of Layer 3 routing protocols (BGP, OSPFv2, and EIGRP) is transparent to the user andhappens automatically in the background. Routing protocols recover routing information from neighbordevices and rebuild the Cisco Express Forwarding table.

Cisco Express ForwardingA key element of Cisco IOS Nonstop Forwarding (NSF) is packet forwarding. In a Cisco networking device,packet forwarding is provided by Cisco Express Forwarding. Cisco Express Forwarding maintains theForwarding Information Base (FIB), and uses the FIB information that is current at the time of a switchoverto continue forwarding packets during a switchover, to reduce traffic interruption during the switchover.

During normal NSF operation, Cisco Express Forwarding on the active device synchronizes its current FIBand adjacency databases with the FIB and adjacency databases on the standby device. Upon switchover, thestandby device initially has FIB and adjacency databases that are mirror images of those that were current onthe active device. Cisco Express Forwarding keeps the forwarding engine on the standby device current withchanges that are sent to it by Cisco Express Forwarding on the active device. The forwarding engine cancontinue forwarding after a switchover as soon as the interfaces and a data path are available.

As the routing protocols start to repopulate the RIB on a prefix-by-prefix basis, the updates causeprefix-by-prefix updates to Cisco Express Forwarding, which it uses to update the FIB and adjacency databases.Existing and new entries receive the new version (“epoch”) number, indicating that they have been refreshed.The forwarding information is updated on the forwarding engine during convergence. The device signalswhen the RIB has converged. The software removes all FIB and adjacency entries that have an epoch olderthan the current switchover epoch. The FIB now represents the newest routing protocol forwarding information.

Routing ProtocolsRouting protocols run only on the active RP, and receive routing updates from neighbor devices. Routingprotocols do not run on the standby RP. Following a switchover, routing protocols request that the NSF-awareneighbor devices send state information to help rebuild routing tables. Alternately, the IntermediateSystem-to-Intermediate System (IS-IS) protocol can be configured to synchronize state information from theactive to the standby RP to help rebuild the routing table on the NSF-capable device in environments whereneighbor devices are not NSF-aware.

For NSF operation, routing protocols depend on Cisco Express Forwarding to continue forwarding packetswhile routing protocols rebuild the routing information.

Note

BGP OperationWhen a NSF-capable device begins a BGP session with a BGP peer, it sends an OPEN message to the peer.Included in the message is a declaration that the NSF-capable device has “graceful restart capability.” Gracefulrestart is the mechanism by which BGP routing peers avoid a routing flap following a switchover. If the BGPpeer has this capability, it is aware that the device sending the message is NSF-capable. Both the NSF-capable


Nonstop Forwarding with Stateful SwitchoverCisco Express Forwarding

device and its BGP peer(s) need to exchange the Graceful Restart Capability in their OPEN messages, at thetime of session establishment. If both peers do not exchange the Graceful Restart Capability, the session isnot graceful restart capable.

If the BGP session is lost during the RP switchover, the NSF-aware BGP peer marks all routes associatedwith the NSF-capable device as stale; however, it continues to use these routes to make forwarding decisionsfor a set period of time. This functionality means that no packets are lost while the newly active RP is waitingfor convergence of the routing information with the BGP peers.

After an RP switchover occurs, the NSF-capable device reestablishes the session with the BGP peer. Inestablishing the new session, it sends a new graceful restart message that identifies the NSF-capable deviceas having restarted.

At this point, the routing information is exchanged between two BGP peers. Once this exchange is complete,the NSF-capable device uses the routing information to update the RIB and the FIB with the new forwardinginformation. The NSF-aware device uses the network information to remove stale routes from its BGP table.Following that, the BGP protocol is fully converged.

If a BGP peer does not support the graceful restart capability, it will ignore the graceful-restart capability inan OPEN message; but will establish a BGP session with the NSF-capable device. This function allowsinteroperability with non-NSF-aware BGP peers (and without NSF functionality), but the BGP session withnon-NSF-aware BGP peers will not be graceful restart capable.

BGP support in NSF requires that neighbor networking devices be NSF-aware; that is, devices must have theGraceful Restart Capability and advertise that capability in their OPENmessage during session establishment.If an NSF-capable device discovers that a particular BGP neighbor does not have Graceful Restart Capability,it will not establish an NSF-capable session with that neighbor. All other neighbors that have Graceful RestartCapability will continue to have NSF-capable sessions with this NSF-capable networking device.

Note

EIGRP OperationEnhanced Interior Gateway Routing Protocol (EIGRP) NSF capabilities are exchanged by EIGRP peers inhello packets. The NSF-capable device notifies its neighbors that an NSF restart operation has started bysetting the restart (RS) bit in a hello packet. When an NSF-aware device receives notification from anNSF-capable neighbor that an NSF-restart operation is in progress, the NSF-capable and NSF-aware devicesimmediately exchange their topology tables. The NSF-aware device sends an end-of-table update packet whenthe transmission of its topology table is complete. The NSF-aware device then performs the following actionsto assist the NSF-capable device:

• The EIGRP hello hold timer is expired to reduce the time interval set for hello packet generation andtransmission. This allows the NSF-aware device to reply to the NSF-capable devicemore quickly reducingthe amount of time required for the NSF-capable device to rediscover neighbors and rebuild the topologytable.

• The route-hold timer is started. This timer is used to set the period of time that the NSF-aware devicewill hold known routes for the NSF-capable neighbor. This timer is configured with the timers nsfroute-hold command. The default time period is 240 seconds.

• In the peer list, the NSF-aware device notes that the NSF-capable neighbor is restarting, maintainsadjacency, and holds known routes for the NSF-capable neighbor until the neighbor signals that it isready for the NSF-aware device to send its topology table, or the route-hold timer expires. If the route-hold


Nonstop Forwarding with Stateful SwitchoverEIGRP Operation

timer expires on the NSF-aware device, the NSF-aware device discards held routes and treats theNSF-capable device as a new device joining the network and reestablishes adjacency accordingly.

• The NSF-aware device continues to send queries to the NSF-capable device which is still in the processof converging after a switchover, effectively extending the time before a stuck-in-active condition canoccur.

When the switchover operation is complete, the NSF-capable device notifies its neighbors that it has reconvergedand has received all of their topology tables by sending an end-of-table update packet to assisting devices.The NSF-capable device then returns to normal operation. The NSF-aware device will look for alternate paths(go active) for any routes that are not refreshed by the NSF-capable (restarting device). The NSF-aware devicewill then return to normal operation. If all paths are refreshed by the NSF-capable device, the NSF-awaredevice will immediately return to normal operation.

NSF-aware devices are completely compatible with non-NSF aware or -capable neighbors in an EIGRPnetwork. A non-NSF aware neighbor will ignore NSF capabilities and reset adjacencies and otherwise maintainthe peering sessions normally.

Note

OSPF OperationWhen an OSPF NSF-capable device performs a supervisor engine switchover, it must perform the followingtasks in order to resynchronize its link state database with its OSPF neighbors:

• Relearn the available OSPF neighbors on the network without causing a reset of the neighbor relationship.

• Reacquire the contents of the link state database for the network.

As quickly as possible after a supervisor engine switchover, the NSF-capable device sends an OSPF NSFsignal to neighboring NSF-aware devices. Neighbor networking devices recognize this signal as an indicatorthat the neighbor relationship with this device should not be reset. As the NSF-capable device receives signalsfrom other devices on the network, it can begin to rebuild its neighbor list.

After neighbor relationships are reestablished, the NSF-capable device begins to resynchronize its databasewith all of its NSF-aware neighbors. At this point, the routing information is exchanged between the OSPFneighbors. Once this exchange is complete, the NSF-capable device uses the routing information to removestale routes, update the RIB, and update the FIB with the new forwarding information. The OSPF protocolsare then fully converged.

OSPF support in NSF requires that all neighbor networking devices be NSF-aware. If an NSF-capable devicediscovers that it has non-NSF -aware neighbors on a particular network segment, it disables NSF capabilitiesfor that segment. Other network segments composed entirely of NSF-capable or NSF-aware devices continueto provide NSF capabilities.

Note


Nonstop Forwarding with Stateful SwitchoverOSPF Operation

How to Configure Cisco NSF with SSO

Configuring SSOYou must configure SSO in order to use NSF with any supported protocol.

Procedure

PurposeCommand or Action

Enables privileged EXEC mode.enableStep 1

Example: • Enter your password if prompted.Device> enable

Displays the operating redundancy mode.show redundancy states

Example:

Step 2

Device# show redundancy states

Enters redundancy configuration mode.redundancy

Example:

Step 3

Device(config)# redundancy

Configures stateful switchover.mode ssoStep 4

Example: • When this command is entered, thestandby switch is reloaded and begins towork in SSO mode.

Device(config-red)# mode sso

Exits redundancy configuration mode andreturns to privileged EXEC mode.

end

Example:

Step 5

Device(config-red)# end

Displays the operating redundancy mode.show redundancy states

Example:

Step 6

Device# show redundancy states

Enables the debugging of redundancy statusevents.

debug redundancy status

Example:

Step 7

Device# debug redundancy status


Nonstop Forwarding with Stateful SwitchoverHow to Configure Cisco NSF with SSO

Configuration Examples for Nonstop Forwarding with StatefulSwitchover

Example: Configuring SSOThis example shows how to configure the system for SSO and displays the redundancy state:Device(config)# redundancyDevice(config-red)# mode ssoDevice(config-red)# endDevice#

The following is sample output from the show redundancy command:Device# show redundancy states

my state = 13 -ACTIVEpeer state = 1 -DISABLED

Mode = SimplexUnit = Primary

Unit ID = 3

Redundancy Mode (Operational) = Non-redundantRedundancy Mode (Configured) = ssoRedundancy State = Non Redundant

Maintenance Mode = DisabledManual Swact = disabled (system is simplex (no peer unit))

Communications = Down Reason: Simplex mode

client count = 103client_notification_TMR = 30000 milliseconds

RF debug mask = 0x0

The following is sample output from the show redundancy clients command:Device# show redundancy clients

clientID = 29 group_id = 1 clientSeq = 60 Redundancy Mode RFclientID = 139 group_id = 1 clientSeq = 62 IfIndexclientID = 25 group_id = 1 clientSeq = 71 CHKPT RFclientID = 10001 group_id = 1 clientSeq = 85 QEMU Platform RFclientID = 77 group_id = 1 clientSeq = 87 Event ManagerclientID = 1340 group_id = 1 clientSeq = 104 RP Platform RFclientID = 1501 group_id = 1 clientSeq = 105 CWAN HAclientID = 305 group_id = 1 clientSeq = 110 Multicast ISSU ConsolidationRFclientID = 304 group_id = 1 clientSeq = 111 IP multicast RF ClientclientID = 22 group_id = 1 clientSeq = 112 Network RF ClientclientID = 88 group_id = 1 clientSeq = 113 HSRPclientID = 114 group_id = 1 clientSeq = 114 GLBPclientID = 4700 group_id = 1 clientSeq = 118 COND_DEBUG RFclientID = 1341 group_id = 1 clientSeq = 119 IOSXE DPIDXclientID = 1505 group_id = 1 clientSeq = 120 IOSXE SPA TSMclientID = 75 group_id = 1 clientSeq = 130 Tableid HAclientID = 501 group_id = 1 clientSeq = 137 LAN-Switch VTP VLANclientID = 71 group_id = 1 clientSeq = 139 XDR RRP RF ClientclientID = 24 group_id = 1 clientSeq = 140 CEF RRP RF Client


Nonstop Forwarding with Stateful SwitchoverConfiguration Examples for Nonstop Forwarding with Stateful Switchover

clientID = 146 group_id = 1 clientSeq = 142 BFD RF ClientclientID = 301 group_id = 1 clientSeq = 146 MRIB RP RF ClientclientID = 306 group_id = 1 clientSeq = 150 MFIB RRP RF ClientclientID = 402 group_id = 1 clientSeq = 161 TPM RF clientclientID = 520 group_id = 1 clientSeq = 162 RFS RFclientID = 210 group_id = 1 clientSeq = 163 Auth MgrclientID = 10101 group_id = 1 clientSeq = 164 NGMOD HMS RF clientclientID = 5 group_id = 1 clientSeq = 165 Config Sync RF clientclientID = 10007 group_id = 1 clientSeq = 170 NGWC FEC Rf clientclientID = 10009 group_id = 1 clientSeq = 173 NGWC POWERNET Rf clientclientID = 10100 group_id = 1 clientSeq = 174 NGMOD XCVR RF clientclientID = 502 group_id = 1 clientSeq = 187 LAN-Switch Port ManagerclientID = 530 group_id = 1 clientSeq = 189 Access TunnelclientID = 519 group_id = 1 clientSeq = 190 Mac address Table ManagerclientID = 209 group_id = 1 clientSeq = 209 L2FIBclientID = 207 group_id = 1 clientSeq = 215 CFM RFclientID = 208 group_id = 1 clientSeq = 218 LLDPclientID = 226 group_id = 1 clientSeq = 219 LACP

The following is sample output from the show redundancy counters command:Device# show redundancy counters

Redundancy Facility OMscomm link up = 0

comm link down = 0

invalid client tx = 0null tx by client = 0

tx failures = 0tx msg length invalid = 0

client not rxing msgs = 0rx peer msg routing errors = 0

null peer msg rx = 0errored peer msg rx = 0

buffers tx = 7250tx buffers unavailable = 0

buffers rx = 6786buffer release errors = 0

duplicate client registers = 0failed to register client = 0

Invalid client syncs = 0

The following is sample output from the show redundancy states command:Device# show redundancy states

my state = 13 -ACTIVEpeer state = 1 -DISABLED

Mode = SimplexUnit = Primary

Unit ID = 3

Redundancy Mode (Operational) = Non-redundantRedundancy Mode (Configured) = ssoRedundancy State = Non Redundant

Maintenance Mode = DisabledManual Swact = disabled (system is simplex (no peer unit))

Communications = Down Reason: Simplex mode


Nonstop Forwarding with Stateful SwitchoverExample: Configuring SSO

client count = 103client_notification_TMR = 30000 milliseconds

RF debug mask = 0x0

Verifying Cisco Express Forwarding with NSF

Procedure

show cef state

Displays the state of Cisco Express Forwarding on a networking device.

Example:Device# show cef state

CEF Status:RP instancecommon CEF enabledIPv4 CEF Status:CEF enabled/runningdCEF enabled/runningCEF switching enabled/runninguniversal per-destination load sharing algorithm, id DEA83012IPv6 CEF Status:CEF disabled/not runningdCEF disabled/not runninguniversal per-destination load sharing algorithm, id DEA83012RRP state:I am standby RRP: noRF Peer Presence: yesRF PeerComm reached: yesRF Progression blocked: neverRedundancy mode: rpr(1)CEF NSF sync: disabled/not runningCEF ISSU Status:FIBHWIDB brokerNo slots are ISSU capable.FIBIDB brokerNo slots are ISSU capable.FIBHWIDB Subblock brokerNo slots are ISSU capable.FIBIDB Subblock brokerNo slots are ISSU capable.Adjacency updateNo slots are ISSU capable.IPv4 table brokerNo slots are ISSU capable.CEF pushNo slots are ISSU capable.


Nonstop Forwarding with Stateful SwitchoverVerifying Cisco Express Forwarding with NSF

Additional References for Nonstop Forwarding with StatefulSwitchover

Related Documents

Document TitleRelated Topic

Catalyst 9400 Command ReferenceFor complete syntax and usage information forthe commands used in this chapter.

MIBs

MIBs LinkMIB

To locate and downloadMIBs for selected platforms, Cisco IOS releases,and feature sets, use Cisco MIB Locator found at the following URL:

http://www.cisco.com/go/mibs

All the supported MIBs for thisrelease.

Technical Assistance

LinkDescription

http://www.cisco.com/supportThe Cisco Support website provides extensive online resources, includingdocumentation and tools for troubleshooting and resolving technical issueswith Cisco products and technologies.

To receive security and technical information about your products, you cansubscribe to various services, such as the Product Alert Tool (accessed fromField Notices), the Cisco Technical Services Newsletter, and Really SimpleSyndication (RSS) Feeds.

Access to most tools on the Cisco Support website requires a Cisco.com userID and password.

Feature History Information for Nonstop Forwarding withStateful Switchover

The following table provides release information about the feature or features described in this module. Thistable lists only the software release that introduced support for a given feature in a given software releasetrain. Unless noted otherwise, subsequent releases of that software release train also support that feature.

Use Cisco Feature Navigator to find information about platform support and Cisco software image support.To access Cisco Feature Navigator, go to www.cisco.com/go/cfn. An account on Cisco.com is not required.


Nonstop Forwarding with Stateful SwitchoverAdditional References for Nonstop Forwarding with Stateful Switchover


http://www.cisco.com/support

http://www.cisco.com/go/cfn

Table 1: Feature Information for Nonstop Forwarding with Stateful Switchover

Feature InformationReleaseFeature Name

Cisco NSF works with the SSO feature. NSFworks with SSO to minimize the amount oftime a network is unavailable to usersfollowing a switchover. The main objectiveof NSF SSO is to continue forwarding IPpackets following a Route Processor (RP)switchover.

Cisco IOS XE Everest 16.6.2Nonstop Forwarding withStateful Switchover


Nonstop Forwarding with Stateful SwitchoverFeature History Information for Nonstop Forwarding with Stateful Switchover

C H A P T E R 2Configuring Graceful Insertion and Removal

Graceful Insertion and Removal (GIR) provides an alternative method to minimize network service impactcaused by device maintenance. GIR leverages redundant paths in the network to smoothly remove a deviceunder maintenance, out of service, and insert it back to service when the maintenance is complete. This moduledescribes the how to configure GIR.

• Restrictions for Graceful Insertion and Removal, on page 13• Information about Graceful Insertion and Removal, on page 13• How to Configure Graceful Insertion and Removal, on page 15• Configuration Examples for Graceful Removal and Insertion, on page 17• Monitoring Graceful Insertion and Removal, on page 19• Additional References for Graceful Insertion and Removal , on page 19• Feature History and Information for GIR, on page 20

Restrictions for Graceful Insertion and RemovalGIR is supported for layer two interface shutdown and ISIS routing protocol, HSRP, VRRPv3. This isconfigured either by creating customized templates or without a template.

Information about Graceful Insertion and Removal

OverviewGraceful Insertion and Removal (GIR) isolates a switch from the network in order to perform debugging oran upgrade. When switch maintenance is complete, the switch will return to normal mode on either reachingthe configured maintenance timeout, or by enabling the stop maintenance command.

A switch can be put into maintenance mode using default template or a custom template. The default templatecontains all the ISIS instances, along with shut down l2. In the custom template, you can configure the requiredISIS instances and shutdown l2option. On entering maintenancemode, all participating protocols are isolated,and L2 ports are shut down. When normal mode is restored, all the protocols and L2 ports are brought backup.


Creating a maintenance mode template before you put the switch in maintenance mode is optional. Theobjective of maintenance mode for a device is to minimize traffic disruption at the time of removal from thenetwork, as well as during the time of insertion. There are mainly three stages:

• Graceful removal of the node from network.

• Performing maintenance on the device.

• Graceful insertion into the network.

Snapshots are taken automatically while entering and exiting the maintenance mode. You can use the snapshotcreate snapshot-name snapshot-description command to capture and store snapshots for pre-selected features.Snapshots are useful to compare the state of a switch before it went into maintenance mode and after it cameback to normal mode. The snapshot process consists of three parts:

• Creating a snapshot of the states of a few preselected features on the switch and storing them onthepersistent storage media.

• Listing the snapshots taken at various time intervals and managing them.

• Comparing snapshots and showing the summary and details of each feature.

Themaximum number of snapshots that may be stored on the switch is 10. You can use the command snapshotdelete snapshot-name to delete a specific snapshot from the device.

Snapshot templates can be created to generate specific snapshots. Multiple snapshot templates with differentprotocols can be created but a single template can be applied to the default template taken during themaintenance mode. Only a single template can be applied to the snapshot create command. A new snapshottemplate can be created using the snapshot-templatetemplate-name command. The commandsnapshot-templatedefault-snapshot-template can be used to specify the default snapshot template in themaintenance mode. The snapshot create[templatetemplate-name]snapshot-namesnapshot-descriptioncommand can be used to apply a specific template to the snapshot create feature.

Layer 2 interface shutdownLayer 2 interfaces will be shut downwhen the system is transitioning into maintenancemode. Layer 2 interfacesare shut down using the shutdown l2 command in the custom template.

Custom TemplateThe network administrator can create a template that will be applied when the system goes into maintenancemode. This allows the administrator to isolate specific protocols. All instances that need to be isolated mustbe explicitly specified.

The admin can create multiple templates with different configurations. However, only a single template willbe applied to the maintenance mode CLI. Once applied, the template cannot be updated. If the template needsto be updated, then you must remove it, make the changes, and then re-apply.

Starting from Cisco IOS XE Fuji 16.9.1 release, support has been added to service protocols belonging to oneclass within a template in parallel. The priority order of the protocols will be the same as that of the defaulttemplate. To configure this feature, enter themaintenancemode using the systemmodemaintenance commandand enable the functionality using the templatetemplate-namecalss command.

For example if the custom template has the following protocols:


Configuring Graceful Insertion and RemovalLayer 2 interface shutdown

Maintenance-template foorouter isis 100hsrp Et0/1 1hsrp Et0/1 2router isis 200

In the above example, since isis belongs to CLASS_IGP, router isis 100 & router isis 200 will be serviced inparallel. Once acks are received for both these protocols belonging to IGP class, FHRP_CLASS clients, hsrpEt0/1 and hsrp Et0/1 2 will be serviced in parallel.

System Mode Maintenance CountersGIR has counters to track the following events:

• Number of times the switch went into maintenance.

• Ack statistics per client.

• Nack statistics per client

• Number of times a particular client did not acknowledge.

• Number of times switch over happened during GIR. GIR infra will rsync this counter to track multipleswitchovers.

• Number of times the failsafe timer expired.

• Number of times system got out of maintenance on a timeout expiry.

The show system mode maintenance counters command can be used to display the counters that are beingtracked by the feature.

The clear system mode maintenance counters command can be used to clear the counters supported bymaintenance mode in the feature.

The client-ack timeout value can be configured using the failsafefailsafe-timeout-value command. The failsafetimer can be configured between 5 - 180 minutes, with a default of 30 minutes.

How to Configure Graceful Insertion and Removal

Creating maintenance template

Procedure


Enables privileged EXEC mode. Enter yourpassword if prompted.

enable

Example:

Step 1

Device> enable

Enters the global configuration mode.configure terminal

Example:

Step 2


Configuring Graceful Insertion and RemovalSystem Mode Maintenance Counters

PurposeCommand or ActionDevice# config t

Creates a template with the specified name. Forexample, see Examples: Creating customerprofile.

maintenance-template template_name

Example:Device(config)# maintenance-template gir1

Step 3

Creates instances that should be isolated underthis template.

router routing_protocol instance_id |shutdown l2

Step 4

Example: • router: Configures routing protocols andassociated instance id.Device(config-maintenance-templ)# router

isis 1• shutdown l2: Shuts down layer 2interfaces.Device(config-maintenance-templ)#

shutdown l2

Configuring System Mode Maintenance

Procedure



enable

Example:

Step 1

Device> enable

Enters the global configuration mode.configure terminal

Example:

Step 2

Device# config t

Enters systemmodemaintenance configurationmode.

system mode maintenance

Example:

Step 3

Different sub commands to create maintenancemode parameters are configured in this mode.

Device(config)# system mode maintenance

Configures maintenance mode parameters.timeout timeout-value | templatetemplate-name | failsafe

Step 4

• timeout: Configures maintenance modetimeout period in minutes, after which thefailsafe-timeout-value | on-reload

reset-reason MAINTENANCE system automatically returns to normalmode.

• template: Configures maintenance modeusing the specified template.

• failsafe:Configures client-ack timeoutvalue.

If the system is going into maintenancemode, it will continue to reach


Configuring Graceful Insertion and RemovalConfiguring System Mode Maintenance


maintenance.If the system is exiting frommaintenance mode, then it will reachnormal mode.

• on-reload reset-reasonMAINTENANCE:Reloads system onmaintenance mode.

Starting and Stopping Maintenance Mode

Procedure



enable

Example:

Step 1

Device> enable

Puts the system into maintenance mode.start maintenance

Example:

Step 2

Device# start maintenance

Puts the system back into normal mode.stop maintenance

Example:

Step 3

Device# stop maintenance

Configuration Examples for Graceful Removal and InsertionThe following examples show the sequence followed to enable GIR during a maintanence window.

Example: Configuring maintenance templateThis example shows how to configure a maintenance template t1 with an ISIS routing protocol instance.Device# config terminalDevice (config)# maintenance-template t1Device (config-maintenance-templ)# router isis 1

This example shows how to configure a maintenance template t1 with shutdown l2.Device# config terminalDevice (config)# maintenance-template t1Device (config-maintenance-templ)# shutdown l2


Configuring Graceful Insertion and RemovalStarting and Stopping Maintenance Mode

Example: Configuring system mode maintenanceThis example shows how to create maintenance template and configure the maintenance mode parameters.Device# config terminalDevice(config)# system mode maintenanceDevice(config-maintenance)#timeout 20Device(config-maintenance)#failsafe 30Device(config-maintenance)#on-reload reset-reason MAINTENANCEDevice(config-maintenance)#template t1Device(config-maintenance)#exit

Example: Starting and Stopping maintenance modeThis example shows how to put the system into maintenance mode.Device# start maintenance

After the activity is completed, the system can be put out of maintenance mode.

This example shows how to put the system out of maintenance mode.Device# stop maintenance

Example: Displaying system mode settingsThis example shows how to display system mode settings using different options.Device#show system mode

System Mode: Normal

Device#show system mode maintenanceSystem Mode: NormalCurrent Maintenance Parameters:Maintenance Duration: 15(mins)Failsafe Timeout: 30(mins)Maintenance Template: t1Reload in Maintenance: False

Device#show system mode maintenance clientsSystem Mode: NormalMaintenance Clients:CLASS-EGP

CLASS-IGProuter isis 1: Transition None

CLASS-MCAST

CLASS-L2

Device#show system mode maintenance template defaultSystem Mode: Normaldefault maintenance-template details:router isis 1router isis 2


Configuring Graceful Insertion and RemovalExample: Configuring system mode maintenance

Device#show system mode maintenance template t1System Mode: NormalMaintenance Template t1 details:

router isis 1

Monitoring Graceful Insertion and RemovalTable 2: Privelege EXEC show commands

PurposeCommand

Displays information about system mode.show systemmode [maintenance [clients | templatetemplate-name]]

Displays all the snapshots present on the device inhuman readable format.

show system snapshots [dump<snapshot-file-name>]

Displays all the snapshots present on the device inXML format.

show system snapshots [dump<snapshot-file-name>]xml

Displays differences between snapshots taken beforeentering maintenance mode and after exiting from themaintenance mode.

show system snapshots compare snapshot-name1snapshot-name2

Table 3: Global Troubleshooting Commands

PurposeCommand

Displays information for troubleshooting GIR feature.debug system mode maintenance

Additional References for Graceful Insertion and RemovalRelated Documents


High Availability Command Reference, Cisco IOS XEEverest 16.6.1.

For complete syntax and usage information forthe commands used in this chapter.

MIBs

MIBs LinkMIB





Configuring Graceful Insertion and RemovalMonitoring Graceful Insertion and Removal



LinkDescription




Feature History and Information for GIRThe following table provides release information about the feature or features described in this module. Thistable lists only the software release that introduced support for a given feature in a given software releasetrain. Unless noted otherwise, subsequent releases of that software release train also support that feature.

ModificationRelease

This feature was introduced.Cisco IOS XE Fuji 16.8.1a

The following enhancements have been addedto the GIR feature:

• Snapshot templates can be used to generatespecific snapshots. Protocols belonging toone class within the same custom templatewill be serviced in parallel. System modemaintenance counters have been added totrack several events such as the number oftimes the switch went into maintenance.

• GIR is now supported for the HSRPprotocol

• GIR is now supported for VRRPv3protocol.

Cisco IOS XE Fuji 16.9.1


Configuring Graceful Insertion and RemovalFeature History and Information for GIR


C H A P T E R 3Configuring Cisco StackWise Virtual

• Finding Feature Information, on page 21• Prerequisites for Cisco StackWise Virtual, on page 21• Restrictions for Cisco StackWise Virtual, on page 22• Information About Cisco StackWise Virtual, on page 23• How to Configure Cisco StackWise Virtual, on page 33• Verifying Cisco StackWise Virtual Configuration, on page 40• Additional References for StackWise Virtual, on page 41• Feature History and Information for Cisco StackWise Virtual, on page 41

Finding Feature InformationYour software release may not support all the features documented in this module. For the latest caveats andfeature information, see Bug Search Tool and the release notes for your platform and software release. Tofind information about the features documented in this module, and to see a list of the releases in which eachfeature is supported, see the feature information table at the end of this module.

Use Cisco Feature Navigator to find information about platform support and Cisco software image support.To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn. An account on Cisco.com is notrequired.

Prerequisites for Cisco StackWise Virtual• All the switches in a Cisco StackWise Virtual solution must be of the same switch model.

• All the switches in a Cisco StackWise Virtual solution must be running the same license level.

• All the switches in a Cisco StackWise Virtual solution must be running the same software version.

• The supervisor module in each switch should be inserted in symmetrical slots. For example, in a CiscoCatalyst 9407R Switch, if you have installed the supervisor module in slot 3, ensure that the secondswitch also has the supervisor module installed in slot 3.

For chassis slot restrictions, refer to the Cisco Catalyst 9400 Series Supervisor Module Installation Note.


www.cisco.com/go/cfn

https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst9400/hardware/sup_install/b-c9400-sup-note.html

When you enable Cisco StackWise Virtual on the device:

• Layer 2, Layer 3, Security, Quality of Service, Multicast, Application, Monitoring and Management,Multiprotocol Label Switching, and High Availability are supported. Contact the Cisco Technical SupportCentre for the specific list of features that are supported under each one of these technologies.

• Resilient Ethernet Protocol, Remote Switched Port Analyzer, and Sofware-Defined Access are NOTsupported.

Note

Restrictions for Cisco StackWise Virtual• Cisco StackWise Virtual is supported only on Cisco Catalyst 9404R and Cisco Catalyst 9407R switches.

• Cisco StackWise Virtual is supported on Cisco Catalyst 9400 Series Supervisor 1Module (C9400-SUP-1)and Cisco Catalyst 9400 Series Supervisor 1XL Module (C9400-SUP-1XL). The feature requires aspecial, additional, C9400-SUP-UPG-LIC= license with Cisco Catalyst 9400 Series Supervisor 1Module(C9400-SUP-1).

• StackWise Virtual Link (SVL) connections are established only through 10G or 40G uplink ports on thesupervisor module. You cannot establish an SVL using a 10G port on one switch and a 40G port on theother switch.

• Cisco StackWise Virtual can be configured only on one supervisor module per chassis. You can installtwo supervisor modules in each chassis used in the Cisco StackWise Virtual solution. However, onlyone of the supervisor modules will be active; the other module will be powered off.

• The Federal Information Processing Standards (FIPS) is not supported on SVL.

• When deploying Cisco StackWise Virtual, ensure that VLAN ID 4094 is not used anywhere on thenetwork. All inter-chassis system control communication between stack members is carried over thereserved VLAN ID 4094 from the global range.

• Dual-active detection (DAD) and StackWise Virtual (SVL) link configurationmust be performedmanuallyand the device should be rebooted for the configuration changes to take effect.

• Fast Hello dual-active detection is supported only on supervisor module ports. Enhanced PAgP dual-activedetection is supported on supervisor module ports and line cards.

• Only Cisco Transceiver Modules are supported.

• The interface VLANMAC address that is assigned by default, can be overridden using themac-addresscommand. If this command is configured on a single SVI or router port that requires Layer 3 injectedpackets, all other SVIs or routed ports on the device also must be configured with the same first fourmost significant bytes (4MSB) of the MAC address. For example, if you set the MAC address of anySVI to xxxx.yyyy.zzzz, set theMAC address of all other SVIs to start with xxxx.yyyy. If Layer 3 injectedpackets are not used, this restriction does not apply.

This applies to all Layer 3 ports, SVIs, and routed ports. This does not apply toGigabitEthernet0/0 port.

Note


Configuring Cisco StackWise VirtualRestrictions for Cisco StackWise Virtual

Information About Cisco StackWise Virtual

Cisco StackWise Virtual on Cisco Catalyst 9400 Series SwitchesStarting with Cisco IOS XE Fuji 16.9.1, Cisco StackWise Virtual is supported on Cisco Catalyst 9400 SeriesSwitches. This section describes the Cisco StackWise Virtual features specific to Cisco Catalyst 9400 SeriesSwitches.

• You can configure upto 8 SVLs in a Cisco StackWise Virtual solution using Cisco Catalyst 9400 SeriesSwitches.

• Cisco StackWise Virtual links can have up to 80GE combined bandwidth per chassis, that is up to 8x10GEor 2x40GE per chassis.

• After configuring StackWise Virtual mode in a standalone chassis, the interface naming conventionchanges from the default 3-tuple (slot/bay/port) to 4-tuple (chassis/slot/bay/port) which includes thechassis identifier as part of the interface name. For example, Gi2/0/1 will change to Gi1/2/0/1 where thefirst number denotes the chassis number.

The following points explain changes to SNMP with the introduction of 4-tuple interface namingconvention:

• The physical index for chassis 1 and 2 are 2 and 500 respectively.

• The physical index for the slots in chassis 1 is in the range of 1000-10000 and slots in chassis 2 isin the range of 11000-20000.

• All MIB Object Identifiers (OID) that require a slot number for query will use a physical slot indexin the flat number space {1, 2, 3...20}, where slots 1-10 indicate chassis 1 and slots 11-20 indicatechassis 2.

• Use show snmp slot-mapping command to display the chassis/slot mapping.

StackWise Virtual OverviewCisco StackWise Virtual is a network system virtualization technology that pairs two switches into one virtualswitch. Switches in a Cisco StackWise Virtual solution increase operational efficiency by using single controland management plane, scale system bandwidth with distributed forwarding plane, and assist in buildingresilient networks using the recommended network design. Cisco StackWise Virtual allows two physicalswitches to operate as a single logical virtual switch using a 40G or 10G Ethernet connection.

Cisco StackWise Virtual TopologyA typical network design consists of core, distribution, and access layers. The default mode of a switch isstandalone. When two redundant switches are deployed in the distribution layer, the following networkchallenges arise:

• If VLAN IDs are reused between access layers then, it will introduce a spanning tree loop that will impactthe overall performance of the network.


Configuring Cisco StackWise VirtualInformation About Cisco StackWise Virtual

• Spanning tree protocols and configuration are required to protect Layer 2 network against spanning treeprotocol loop, and root and bridge protocol data unit management.

• Additional protocols such as first hop redundancy protocol are required to virtualize the IP gatewayfunction. This should align with STP root priorities for each VLAN.

• The Protocol independent multicast designated router (PIM DR) configuration should be fine-tuned toselectively build a multicast forwarding topology on a VLAN.

• The standalone distribution layer system provides protocol-driven remote failure and detection, whichresults in slower convergence time. Fine-tune FHRP and PIM timers for rapid fault detection and recoveryprocess.

We recommend Cisco StackWise Virtual model for aggregation layers and collapsed aggregation and corelayers. The stack can be formed over a redundant 40G or 10G fiber links to ensure that the distribution or theaggregation switches can be deployed over a large distance.

Note that STP keeps one of the ports connected to the distribution switches blocked on the access switches.As a result of this, an active link failure causes STP convergence and the network suffers from traffic loss,flooding, and a possible transient loop in the network. On the other hand, if the switches are logically mergedinto one switch, all the access switches might form an EtherChannel bundle with distribution switches, anda link failure within an EtherChannel would not have any impact as long as at least one member within theEtherChannel is active.Figure 1: Typical Network Design using Cisco StackWise Virtual

Etherchannel in StackWise Virtual is capable of implementing Multi-chassis EtherChannel (MEC) across thestackmembers.When access layer and aggregation layer are collapsed into a single StackWise Virtual system,MEC across the different access layer domain members and across distribution and access layer switches willnot be supported. MEC is designed to forward the traffic over the local link irrespective of the hash result.

Since the control plane, management plane, and data plane are integrated, the system behaves as a singleswitch.

The virtualization of multiple physical switches into a single logical switch is from a control and managementplane perspective only. Because of the control plane being common, it may look like a single logical entityto peer switches. The data plane of the switches is distributed. Each switch is capable of forwarding over itslocal interfaces without involving other members. However, when a packet coming into a switch has to beforwarded over a different member’s port, the forwarding context of the packet is carried over to the destination


Configuring Cisco StackWise VirtualCisco StackWise Virtual Topology

switch after ingress processing is performed in the ingress switch. Egress processing is done only in the egressswitch. This provides a uniform data plane behavior to the entire switch irrespective whether of the destinationport is in a local switch or in a remote switch. However, the common control plane ensures that all the switcheshave equivalent data plane entry for each forwarding entity.

An election mechanism elects one of the switches to be Cisco StackWise Virtual active and the other switchto be Cisco StackWise Virtual standby in terms of Control Plane functions. The active switch is responsiblefor all the management, bridging and routing protocols, and software data path. The standby switch is in hotstandby state ready to take over the role of active, if the active switch fails over.

The following are the components of the Cisco StackWise Virtual solution:

• Stack members

• StackWise Virtual link: 10G or 40G Ethernet connections. SVL is established using the 10G or 40Ginterfaces on the supported switch models. However, a combination of both the interfaces is not supported.

StackWise Virtual link is the link that connects the switches over Ethernet. Typically, Cisco StackWise Virtualconsists of multiple 10-G or 40-G physical links. It carries all the control and data traffic between the switchingunits. You can configure a StackWise Virtual link on a supported port. When a switch is powered up and thehardware is initialized, it looks for a configured StackWise Virtual link before the initialization of the controlplane.

The Link Management Protocol (LMP) is activated on each link of the StackWise Virtual links as soon as thelinks are established. LMP ensure the integrity of SVL links and monitors and maintains the health of thelinks. The redundancy role of each switch is resolved by the StackWise Discovery Protocol (SDP). It ensuresthat the hardware and software versions are compatible to form the SVL and determines which switch becomesactive or standby from a control plane perspective.

Cisco StackWise Virtual Header (SVH) is 64-byte frame header that is prepended over all control, data, andmanagement plane traffic that traverse over each SVL between the two stack members of the Cisco StackWiseVirtual domain. The SVH-encapsulated traffic operates at OSI Layer 2 and can be recognized and processedonly by Cisco StackWise Virtual-enabled switches. SVL interfaces are non-bridgeable and non-routeable,and allows non-routeable traffic over L2 or L3 network.

Cisco StackWise Virtual RedundancyCisco StackWise Virtual operates stateful switchover (SSO) between the active and standby switches. Thefollowing are the ways in which Cisco StackWise Virtual's redundancymodel differs from that of the standalonemode:

• The Cisco StackWise Virtual active and standby switches are hosted in separate switches and use aStackWise Virtual link to exchange information.

• The active switch controls both the switches of Cisco StackWise Virtual. The active switch runs theLayer 2 and Layer 3 control protocols and manages the switching modules of both the switches.

• The Cisco StackWise Virtual active and standby switches perform data traffic forwarding.

If the Cisco StackWise Virtual active switch fails, the standby switch initiates a switchover and assumes theCisco StackWise Virtual active switch role.

Note


Configuring Cisco StackWise VirtualCisco StackWise Virtual Redundancy

SSO RedundancyA StackWise Virtual system operates with SSO redundancy if it meets the following requirements:

• Both the switches must be running the same software version, unless they are in the process of softwareupgrade.

• StackWise Virtual link-related configuration in the two switches must match.

• License type must be same on both the switch models.

• Both the switch models must be in the same StackWise Virtual domain.

With SSO redundancy, the StackWise Virtual standby switch is always ready to assume control if a faultoccurs on the StackWise Virtual active switch. Configuration, forwarding, and state information aresynchronized from the StackWise Virtual active switch to the redundant switch at startup, and wheneverchanges to the StackWise Virtual active switch configuration occur. If a switchover occurs, traffic disruptionis minimized.

If StackWise Virtual does not meet the requirements for SSO redundancy, it will be incapable of establishinga relationship with the peer switch. StackWise Virtual runs stateful switchover (SSO) between the StackWiseVirtual active and standby switches. The StackWise Virtual determines the role of each switch duringinitialization.

The CPU in the StackWise Virtual standby switch runs in hot standby state. StackWise Virtual uses a StackWiseVirtual link to synchronize configuration data from the StackWise Virtual active switch to the StackWiseVirtual standby switch. Also, protocols and features that support high availability synchronize their eventsand state information to the StackWise Virtual standby switch.

Nonstop ForwardingWhile implementing Nonstop Forwarding (NSF) technology in systems using SSO redundancymode, networkdisruptions are minimized for campus users and applications. High availability is provided even when thecontrol-plane processing stack-member switch is reset. During a failure of the underlying Layer 3, NSF-capableprotocols perform graceful network topology resynchronization. The preset forwarding information on theredundant stack-member switch remains intact; this switch continues to forward the data in the network. Thisservice availability significantly lowers the mean time to repair (MTTR) and increases the mean time betweenfailure (MTBF) to achieve a high level of network availability.

Multichassis EtherChannelsMultichassis EtherChannel (MEC) is an EtherChannel bundled with physical ports having commoncharacteristics such as speed and duplex, that are distributed across each Cisco StackWise Virtual system. ACisco StackWise Virtual MEC can connect to any network element that supports EtherChannel (such as ahost, server, router, or switch). Cisco StackWise Virtual supports up to 128 MECs deployed in Layer 2 orLayer 3 modes. EtherChannel 128 is reserved for SVL connections. Hence, the maximum available MECcount is 127.

In a Cisco StackWise Virtual system, an MEC is an EtherChannel with additional capability. A multichassisEtherChannel link reduces the amount of traffic that requires transmission across the StackWise Virtual linkby populating the index port only with the ports local to the physical switch. This allows the switch to giveprecedence to the local ports of the multichassis EtherChannel link over those on the remote switch.

Each MEC can optionally be configured to support either Cisco PAgP, IEEE LACP, or Static ON mode. Werecommend that you implement EtherChannel using Cisco PAgP or LACP with a compatible neighbor. If a


Configuring Cisco StackWise VirtualSSO Redundancy

remotely connected neighbor such as CiscoWireless LANController (WLC) does not support this link-bundlingprotocol, then a Static ON mode can be deployed. These protocols run only on the Cisco StackWise Virtualactive switch.

An MEC can support up to eight physical links that can be distributed in any proportion between the CiscoStackWise Virtual active switch and the Cisco StackWise Virtual standby switch. We recommend that youdistribute the MEC ports across both switches evenly.

MEC Minimum Latency Load BalancingThe StackWise Virtual environment is designed such that data forwarding always remains within the switch.The Virtual Stack always tries to forward traffic on the locally available links. This is true for both Layer 2and Layer3 links. The primary motivation for local forwarding is to avoid unnecessarily sending data trafficover the StackWise Virtual link and thus reduce the latency (extra hop over the SVL) and congestion.Thebidirectional traffic is load-shared between the two StackWise Virtual members. However, for each StackWiseVirtual member, ingress and egress traffic forwarding is based on locally-attached links that are part of MEC.This local forwarding is a key concept in understanding convergence and fault conditions in a StackWiseVirtual enabled campus network.

The active and standby switches support local forwarding that will individually perform the desired lookupsand forward the traffic on local links to uplink neighbors. If the destination is a remote switch in the StackWiseVirtual domain, ingress processing is performed on the ingress switch and then traffic is forwarded over theStackWise Virtual link to the egress switch where only egress processing is performed.

MEC Failure ScenariosWe recommend that you configure a MEC with at least one link to each switch. This configuration ensuresthat there is always an alternate path for data traffic in case of a switch failure.

The following sections describe issues that may arise and the resulting impact:

Single MEC Link Failure

If a link within a MEC fails (and other links in the MEC are still operational), the MEC redistributes the loadamong the operational links, as in a regular port.

All MEC Links to the Cisco StackWise Virtual Active Switch Fail

If all the links to the Cisco StackWise Virtual active switch fail, a MEC becomes a regular EtherChannel withoperational links to the Cisco StackWise Virtual standby switch.

Data traffic that terminates on the Cisco StackWise Virtual active switch reaches the MEC by crossing aStackWise Virtual link to the Cisco StackWise Virtual standby switch. Control protocols continue to run inthe Cisco StackWise Virtual active switch. Protocol messages reach theMEC by crossing a StackWise Virtuallink.

All MEC Links Fail

If all the links in an MEC fail, the logical interface for the EtherChannel is set to Unavailable. Layer 2 controlprotocols perform the same corrective action as for a link-down event on a regular EtherChannel.

On adjacent switches, routing protocols and the Spanning Tree Protocol (STP) perform the same correctiveaction as for a regular EtherChannel.


Configuring Cisco StackWise VirtualMEC Minimum Latency Load Balancing

Cisco StackWise Virtual Standby Switch Failure

If the Cisco StackWise Virtual standby switch fails, a MEC becomes a regular EtherChannel with operationallinks on the Cisco StackWise Virtual active switch. Connected peer switches detect the link failures, andadjust their load-balancing algorithms to use only the links to the StackWise Virtual active switch.

Cisco StackWise Virtual Active Switch Failure

Cisco StackWise Virtual active switch failure results in a stateful switchover (SSO). After the switchover, aMEC is operational on the new Cisco StackWise Virtual active switch. Connected peer switches detect thelink failures (to the failed switch), and adjust their load-balancing algorithms to use only the links to the newCisco StackWise Virtual active switch.

Cisco StackWise Virtual Packet HandlingIn Cisco StackWise Virtual, the Cisco StackWise Virtual active switch runs the Layer 2 and Layer 3 protocolsand features and manages the ports on both the switches.

Cisco StackWise Virtual uses StackWise Virtual link to communicate system and protocol information betweenthe peer switches and to carry data traffic between the two switches.

The following sections describe packet handling in Cisco StackWise Virtual.

Traffic on a StackWise Virtual linkA StackWise Virtual link carries data traffic and in-band control traffic between two switches. All the framesthat are forwarded over the StackWise Virtual link are encapsulated with a special StackWise Virtual Header(SVH). The SVH adds an overhead of 64 bytes for control and data traffic, which provides information forCisco StackWise Virtual to forward the packet on the peer switch.

A StackWise Virtual link transports control messages between two switches. Messages include protocolmessages that are processed by the Cisco StackWise Virtual active switch, but received or transmitted byinterfaces on the Cisco StackWise Virtual standby switch. Control traffic also includes module programmingbetween the Cisco StackWise Virtual active switch and the switching modules on the Cisco StackWise Virtualstandby switch.

Cisco StackWise Virtual transmits data traffic over a StackWise Virtual link under the following circumstances:

• Layer 2 traffic flooded over a VLAN (even for dual-homed links).

• Packets processed by software on the Cisco StackWise Virtual active switch where the ingress interfaceis on the Cisco StackWise Virtual standby switch.

• The packet destination is on the peer switch, as described in the following examples:

• Traffic within a VLAN where the known destination interface is on the peer switch.

• Traffic that is replicated for a multicast group and the multicast receivers are on the peer switch.

• The known unicast destination MAC address is on the peer switch.

• The packet is a MAC notification frame destined for a port on the peer switch.

A StackWise Virtual link also transports system data, such as NetFlow export data and SNMP data, from theCisco StackWise Virtual standby switch to the Cisco StackWise Virtual active switch.


Configuring Cisco StackWise VirtualCisco StackWise Virtual Packet Handling

Traffic on the StackWise Virtual link is load balanced with the same global hashing algorithms available forEtherChannels (the default algorithm is source-destination IP).

Layer 2 ProtocolsThe Cisco StackWise Virtual active switch runs the Layer 2 protocols (such as STP and VTP) for the switchingmodules on both the switches. Protocol messages that are received on the standby switch ports must traverseSVL links to reach the active switch where they are processed. Similarly, protocol messages that are transmittedfrom the standby switch ports originate on the active switch, and traverse the SVL links to reach the standbyports.

All the Layer 2 protocols in Cisco StackWise Virtual work similarly in standalone mode. The followingsections describe the difference in behavior for some protocols in Cisco StackWise Virtual.

Spanning Tree Protocol

The Cisco StackWise Virtual active switch runs the STP. The Cisco StackWise Virtual standby switch redirectsthe STP BPDUs across a StackWise Virtual link to the StackWise Virtual active switch.

The STP bridge ID is commonly derived from the switch MAC address. To ensure that the bridge ID doesnot change after a switchover, Cisco StackWise Virtual continues to use the original switch MAC address forthe STP Bridge ID.

EtherChannel Control Protocols

Link Aggregation Control Protocol (LACP) and Port Aggregation Protocol (PAgP) packets contain a deviceidentifier. Cisco StackWise Virtual defines a common device identifier for both the switches. Use either PAgPor LACP on Multi EtherChannels instead of mode ON, even if all the three modes are supported.

A new PAgP enhancement has been defined for assisting with dual-active scenario detection.Note

Switched Port Analyzer

Switched Port Analyzer (SPAN) on StackWise Virtual link ports is not supported; SVL ports can be neithera SPAN source, nor a SPAN destination. Cisco StackWise Virtual supports all the SPAN features for non-SVLinterfaces. The number of SPAN sessions that are available on Cisco StackWise Virtual matches that on asingle switch running in standalone mode.

Private VLANs

Private VLANs on StackWise Virtual work the same way as in standalone mode. The only exception is thatthe native VLAN on isolated trunk ports must be configured explicitly.

Apart from STP, EtherChannel Control Protocols, SPAN, and private VLANs, the Dynamic Trunking Protocol(DTP), Cisco Discovery Protocol (CDP), VLAN Trunk Protocol (VTP), and Unidirectional Link DetectionProtocol (UDLD) are the additional Layer 2 control-plane protocols that run over the SVL connections.

Layer 3 ProtocolsThe Cisco StackWise Virtual active switch runs the Layer 3 protocols and features for the StackWise Virtual.All the Layer 3 protocol packets are sent to and processed by the Cisco StackWise Virtual active switch. Both


Configuring Cisco StackWise VirtualLayer 2 Protocols

the member switches perform hardware forwarding for ingress traffic on their interfaces. When softwareforwarding is required, packets are sent to the Cisco StackWise Virtual active switch for processing.

The same router MAC address assigned by the Cisco StackWise Virtual active switch is used for all the Layer3 interfaces on both the Cisco StackWise Virtual member switches. After a switchover, the original routerMAC address is still used. The router MAC address is chosen based on chassis-mac and is preserved afterswitchover by default. The following sections describe the Layer 3 protocols for Cisco StackWise Virtual.

IPv4 Unicast

The CPU on the Cisco StackWise Virtual active switch runs the IPv4 routing protocols and performs anyrequired software forwarding. All the routing protocol packets received on the Cisco StackWise Virtual standbyswitch are redirected to the Cisco StackWise Virtual active switch across the StackWise Virtual link. TheCisco StackWise Virtual active switch generates all the routing protocol packets to be sent out over ports oneither of the Cisco StackWise Virtual member switches.

Hardware forwarding is distributed across both members on Cisco StackWise Virtual. The CPU on the CiscoStackWise Virtual active switch sends Forwarding Information Base (FIB) updates to the Cisco StackWiseVirtual standby switch, which in turn installs all the routes and adjacencies into hardware.

Packets intended for a local adjacency (reachable by local ports) are forwarded locally on the ingress switch.Packets intended for a remote adjacency (reachable by remote ports) must traverse the StackWise Virtuallink.

The CPU on the Cisco StackWise Virtual active switch performs all software forwarding and feature processing(such as fragmentation and Time to Live exceed functions). If a switchover occurs, software forwarding isdisrupted until the new Cisco StackWise Virtual active switch obtains the latest Cisco Express Forwardingand other forwarding information.

In virtual switch mode, the requirements to support non-stop forwarding (NSF) match those in the standaloneredundant mode of operation.

From a routing peer perspective, Multi-Chassis EtherChannels (MEC) remain operational during a switchover,that is, only the links to the failed switch are down, but the routing adjacencies remain valid.

Cisco StackWise Virtual achieves Layer 3 load balancing over all the paths in the Forwarding InformationBase entries, be it local or remote.

IPv6

Cisco StackWise Virtual supports IPv6 unicast and multicast because it is present in the standalone system.

IPv4 Multicast

The IPv4 multicast protocols run on the Cisco StackWise Virtual active switch. Internet Group ManagementProtocol (IGMP) and Protocol IndependentMulticast (PIM) protocol packets received on the Cisco StackWiseVirtual standby switch are transmitted across a StackWise Virtual link to the StackWise Virtual active switch.The latter generates IGMP and PIM protocol packets to be sent over ports on either of the Cisco StackWiseVirtual members.

The Cisco StackWise Virtual active switch synchronizes the Multicast Forwarding Information Base (MFIB)state to the Cisco StackWise Virtual standby switch. On both the member switches, all the multicast routesare loaded in the hardware, with replica expansion table (RET) entries programmed for only local, outgoinginterfaces. Both the member switches are capable of performing hardware forwarding.


Configuring Cisco StackWise VirtualLayer 3 Protocols

To avoid multicast route changes as a result of a switchover, we recommend that all the links carrying multicasttraffic be configured as MEC rather than Equal Cost Multipath (ECMP).

Note

For packets traversing a StackWise Virtual link, all Layer 3 multicast replications occur on the egress switch.If there are multiple receivers on the egress switch, only one packet is replicated and forwarded over theStackWise Virtual link, and then replicated to all the local egress ports.

Software Features

Software features run only on the Cisco StackWise Virtual active switch. Incoming packets to the CiscoStackWise Virtual standby switch that require software processing are sent across a StackWise Virtual linkto the Cisco StackWise Virtual active switch.

Dual-Active DetectionIf the standby switch detects a complete loss of the StackWise Virtual link, it assumes the active switch hasfailed and will take over as the active switch. However, if the original Cisco StackWise Virtual active switchis still operational, both the switches will now be Cisco StackWise Virtual active switches. This situation iscalled a dual-active scenario. This scenario can have adverse effects on network stability because both theswitches use the same IP addresses, SSH keys, and STP bridge IDs. Cisco StackWise Virtual detects adual-active scenario and takes recovery action. Dual-active-detection link is the dedicated link used to mitigatethis.

If a StackWise Virtual link fails, the Cisco StackWise Virtual standby switch cannot determine the state ofthe Cisco StackWise Virtual active switch. To ensure that switchover occurs without delay, the Cisco StackWiseVirtual standby switch assumes that the Cisco StackWise Virtual active switch has failed and initiates switchoverto take over the Cisco StackWise Virtual active role. The original Cisco StackWise Virtual active switchenters recovery mode and brings down all the interfaces except the StackWise Virtual link and the managementinterfaces.

Dual-Active-Detection Link with Fast HelloTo use the dual-active fast hello packet detection method, you must provision a direct ethernet connectionbetween the two Cisco StackWise Virtual switches. You can dedicate up to four links for this purpose.

The two switches periodically exchange special dual-active hello messages containing information about theswitch state. If all SVLs fail and a dual-active scenario occurs, each switch recognizes that there is a dual-activescenario from the peer's messages. This initiates recovery actions as described in the Recovery Actions, onpage 32 section. If a switch does not receive an expected dual-active fast hello message from the peer beforethe timer expires, the switch assumes that the link is no longer capable of dual-active detection.

Do not use the same port for StackWise Virtual link and dual-active detection link.Note

Dual-Active Detection with enhanced PAgPPort aggregation protocol (PAgP) is a Cisco proprietary protocol used for managing EtherChannels. If aStackWise Virtual MEC terminates on a Cisco switch, you can run PAgP protocol on the MEC. If PAgP isrunning on the MECs between the StackWise Virtual switch and an upstream or downstream switch, the


Configuring Cisco StackWise VirtualDual-Active Detection

StackWise Virtual can use PAgP to detect a dual-active scenario. The MEC must have at least one port oneach switch of the StackWise Virtual setup.

Enhanced PAgP is an extension of the PAgP protocol. In virtual switch mode, ePAgP messages include anew type length value (TLV) which contains the ID of the StackWise Virtual active switch. Only switches invirtual switch mode send the new TLV.

When the StackWise Virtual standby switch detects SVL failure, it initiates SSO and becomes StackWiseVirtual active. Subsequent ePAgP messages sent to the connected switch from the newly StackWise Virtualactive switch contain the new StackWise Virtual active ID. The connected switch sends ePAgP messageswith the new StackWise Virtual active ID to both StackWise Virtual switches.

If the formerly StackWise Virtual active switch is still operational, it detects the dual-active scenario becausethe StackWise Virtual active ID in the ePAgP messages changes.Figure 2: Dual-active-detection with ePAgP

To avoid PAgP flaps and to ensure that dual-active detection functions as expected, the stack MAC persistentwait timer must be configured as indefinite using the command stack-mac persistent timer 0 .

Note

Recovery ActionsA Cisco StackWise Virtual active switch that detects a dual-active condition shuts down all of its non-SVLinterfaces to remove itself from the network. The switch then waits in recovery mode until the SVLs havebeen recovered. You should physically repair the SVL failure and the recovery switch should be manuallyreloaded for it to be the standby switch.

Implementing Cisco StackWise VirtualThe two-node solution of Cisco StackWise Virtual is normally deployed at the aggregation layer. Two switchesare connected over an SVL.

Cisco StackWise Virtual combines the two switches into a single logical switch with a large number of ports,offering a single point of management. One of the member switches is the control and management planemaster, while the other one is the standby. The virtualization of multiple physical switches into a single logical


Configuring Cisco StackWise VirtualRecovery Actions

switch is only from a control and management perspective. Because of the control plane being common, itmay look like a single logical entity to peer switches. The data plane of the switches are converged, that is,the forwarding context of a switch might be passed to the other member switch for further processing whentraffic is forwarded across the switches. However, the common control plane ensures that all the switcheshave equivalent data plane entry for each forwarding entity.Figure 3: Two-Node Solution

An election mechanism that determines which switch is Cisco StackWise Virtual active and which one is acontrol plane standby, is available. The active switch is responsible for management, bridging and routingprotocols, and software data path. These are centralized on the active switch supervisor of the Cisco StackWiseVirtual active switch.

How to Configure Cisco StackWise Virtual

Configuring Cisco StackWise Virtual SettingsTo enable StackWise Virtual, perform the following procedure :

Procedure



Example: • Enter your password if prompted.

Device>enable

(Optional) Reassigns the switch number.switchswitch-numberrenumbernew switch-number

Step 2

The default switch number will be 1. The validvalues for the new switch number are 1 and 2.Example:

Device#switch 1 renumber 2

(Optional) Assigns the priority number.switchswitch-numberprioritypriority-numberStep 3

Example:


Configuring Cisco StackWise VirtualHow to Configure Cisco StackWise Virtual


The default priority number is 1. The highestpriority number is 15.Device#switch 1 priority 5

Enters global configuration mode.configure terminal

Example:

Step 4

Device#configure terminal

Enables Cisco StackWise Virtual and entersstackwise-virtual submode.

stackwise-virtual

Example:

Step 5

Device(config)#stackwise-virtual

(Optional) Specifies the Cisco StackWiseVirtual domain ID.

The domain ID range is from 1 to 255. Thedefault value is one.

domain id

Example:Device(config-stackwise-virtual)#domain2

Step 6

Returns to privileged EXEC mode.end

Example:

Step 7

Device(config-stackwise-virtual)#end

show stackwise-virtualStep 8

Example:Device#show stackwise-virtual

Saves the running-configuration which residesin the system RAM and updates the ROMmon

write memory

Example:

Step 9

variables. If you do not save the changes, theDevice#write memory changes will no longer be part of the startup

configuration when the switch reloads. Notethat the configurations for stackwise-virtualand domain are saved to therunning-configuration and thestartup-configuration after the reload.

Restarts the switch and forms the stack.reload

Example:

Step 10

Device#reload


Configuring Cisco StackWise VirtualConfiguring Cisco StackWise Virtual Settings

Configuring Cisco StackWise Virtual Link

SVL is supported on all 10G, 40G and 25G interfaces of the supported switch models. However, a combinationof different interface speeds is not supported.

Note

To configure a switch port as an SVL port, perform the following procedure :

Procedure




Device>enable


Example:

Step 2


Enters ethernet interface configuration mode.interface { TenGigabitEthernet |FortyGigabitEthernet | TwentyFiveGigE} <interface>

Step 3

Example:Device(config)#interfaceTenGigabitEthernet1/2/0/4

Associates the interface with configured SVL.stackwise-virtual link link value

Example:

Step 4

Device(config-if)#stackwise-virtual link1


Example:

Step 5

Device(config-if)#end


write memory

Example:

Step 6


configuration when the switch reloads. Notethat the configuration for stackwise-virtuallink link value is saved only in therunning-configuration and not thestartup-configuration.


Configuring Cisco StackWise VirtualConfiguring Cisco StackWise Virtual Link


Restarts the switch.reload

Example:

Step 7

Device#reload

Configuring StackWise Virtual Fast Hello Dual-Active-Detection LinkTo configure StackWise Virtual Fast Hello DAD link, perform the following procedure. This procedure isoptional.

Procedure




Device>enable


Example:

Step 2



Step 3


Associates the interface with StackWise Virtualdual-active-detection.

stackwise-virtual dual-active-detection

Example:

Step 4

This commandwill not be visible onthe device after the configuration,but will continue to function.

NoteDevice(config-if)#stackwise-virtualdual-active-detection


Example:

Step 5



write memory

Example:

Step 6


configuration when the switch reloads. Note


Configuring Cisco StackWise VirtualConfiguring StackWise Virtual Fast Hello Dual-Active-Detection Link


that the configuration for stackwise-virtualdual-active-detection is saved only in therunning-configuration and not thestartup-configuration.

Restarts the switch and configuration takeseffect.

reload

Example:

Step 7

Device#reload

Enabling ePAgP Dual-Active-DetectionTo enable ePAgP dual-active-detection on a switch port, perform the following procedure on . This procedureis optional.

Procedure




Device>enable


Example:

Step 2



Step 3


Enables PAgP MEC with channel-group id inthe range of 1 to 128 for 10 GigabitEthernetinterfaces.

channel-group group_IDmode desirable

Example:Device(config-if)#channel-group 1 modedesirable

Step 4

Exits interface configuration.exit

Example:

Step 5

Device(config-if)#exit


Configuring Cisco StackWise VirtualEnabling ePAgP Dual-Active-Detection


Selects a port channel interface to configure.interface port-channel channel-group-id

Example:

Step 6

Device(config)#interface port-channel1

Shuts down an interface.shutdown

Example:

Step 7

Device(config-if)#shutdown


Example:

Step 8


Enters the StackWise Virtual configurationmode.

stackwise-virtual

Example:

Step 9

Device(config)#stackwise-virtual

Enables pagp dual-active detection. This isenabled by default.

dual-active detection pagp

Example:

Step 10

Device(config-stackwise-virtual)#dual-activedetection pagp

Enables dual-active detection trust mode onchannel-group with the configured ID.

dual-active detection pagp trustchannel-group channel-group id

Example:

Step 11

Device(config-stackwise-virtual)#dual-activedetection pagp trust channel-group 1

Exits the StackWise-Virtual configurationmode.

exit

Example:

Step 12

Device(config-stackwise-virtual)#exit

Configured port-channel on the switch.interface port-channel portchannel

Example:

Step 13

Device(config)#interface port-channel1

Enables the configured port-channel on theswitch.

no shutdown

Example:

Step 14

Device(config-if)#no shutdown

Exits interface configuration.end

Example:

Step 15



Configuring Cisco StackWise VirtualEnabling ePAgP Dual-Active-Detection



write memory

Example:

Step 16


configuration when the switch reloads. Notethat the configuration for dual-activedetection pagp trust channel-groupchannel-group id is saved to therunning-configuration and thestartup-configuration after the reload.

Restarts the switch and configuration takeseffect.

reload

Example:

Step 17

Device#reload

Disabling Cisco StackWise VirtualTo disable Cisco StackWise Virtual on a switch, perform the following procedure:

Procedure




Device>enable


Example:

Step 2


Enters the interface configuration mode.interface { TenGigabitEthernet |FortyGigabitEthernet | TwentyFiveGigE} <interface>

Step 3

Example:Device(config)#interfaceTenGigabitEthernet 1/2/0/3

Dissociates the interface from StackWiseVirtual DAD.

no stackwise-virtual dual-active-detection

Example:

Step 4

Device(config-if)#no stackwise-virtualdual-active-detection


Configuring Cisco StackWise VirtualDisabling Cisco StackWise Virtual


Enters the interface configuration mode.Repeat step Step 3, on page 39.

Example:

Step 5

Device(config)#interfaceTenGigabitEthernet 1/2/0/2

Dissociates the interface from SVL.no stackwise-virtual link link

Example:

Step 6

Device(config-if)#no stackwise-virtuallink 1


Example:

Step 7


Disables StackWise Virtual configuration.no stackwise-virtual

Example:

Step 8

Device(config)#no stackwise-virtual

Exits the global configuration mode.exit

Example:

Step 9

Device(config)#exit

Saves the running configuration.write memory

Example:

Step 10

Device#write memory

Restarts the switch and the configuration takeseffect.

reload

Example:

Step 11

Device#reload

Verifying Cisco StackWise Virtual ConfigurationTo verify your StackWise Virtual configuration, use the following show commands:

Displays information of a particular switch in the stack.show stackwise-virtual switch number <1-2>

Displays StackWise Virtual link information.show stackwise-virtual link

Displays the bandwidth available for the Cisco StackWiseVirtual.

show stackwise-virtual bandwidth

Displays the Cisco StackWise Virtual neighbors.show stackwise-virtual neighbors

Displays StackWise Virtual dual-active-detectioninformation.

show stackwise-virtual dual-active-detection


Configuring Cisco StackWise VirtualVerifying Cisco StackWise Virtual Configuration

Displays ePAgP dual-active-detection information.show stackwise-virtual dual-active-detectionpagp

Additional References for StackWise VirtualRelated Documents


High Availability Command Reference for Catalyst 9400Switches

For complete syntax and usage information forthe commands used in this chapter.

MIBs

MIBs LinkMIB





LinkDescription




Feature History and Information for Cisco StackWise VirtualModificationRelease

This feature is introducedCisco IOS XE Fuji 16.9.1


Configuring Cisco StackWise VirtualAdditional References for StackWise Virtual




Configuring Cisco StackWise VirtualFeature History and Information for Cisco StackWise Virtual

C H A P T E R 4Configuring ISSU

• Prerequisites for Performing ISSU, on page 43• Information About ISSU Process , on page 43• Restrictions and Guidelines for Performing ISSU, on page 44• Upgrade Software Using 1-Step WorkFlow, on page 45• Upgrade Software Using 3-Step WorkFlow, on page 45• Monitoring ISSU, on page 46• Feature Information for ISSU, on page 47

Prerequisites for Performing ISSUThe following prerequisites apply for performing ISSU:

• The active switch must have access to the new IOS XE image or pre-load it into flash.

• The switch must be running in install mode.

• Non-Stop Forwarding (NSF) must be enabled.

Information About ISSU ProcessIn-Service Software Upgrade (ISSU) is a process that upgrades an image to another image on a device whilethe network continues to forward packets. ISSU helps network administrators avoid a network outage whenperforming a software upgrade. The images are upgraded in install mode wherein each package is upgradedindividually.

ISSU supports upgrades and rollbacks.

ISSU is supported in dual supervisor module configuration on a standalone switch.Note

ISSU Upgrade

The following steps describe the process that is followed in performing ISSU:

1. Copy the new image to the standby and active switches.


2. Unzip the files and copy packages to both the active and standby switches.

3. Install the packages on the standby switch.

4. Restart the standby switch.

The standby switch is now upgraded to the new software.

5. Install the packages on the active switch.

6. Restart the active switch and switchover the standby to new active switch. After the switchover, the newstandby switch will be up with the new software. The new software image is already installed on the newactive switch, hence ISSU is completed.

The ISSU upgrade process remains the same under StackWise Virtual configuration.Note

ISSU Upgrade: 3-Step Work Flow

This workflow involves three steps—add, activate, and commit. After activation, all switches are upgradedto new software version except that the software is not committed automatically but must be performedmanually via the install commit command. The advantage of this approach is the system can be rolled backto a previous software version. The system automatically rolls back if the rollback timer is not stopped usingthe install abort-timer-stop or the install commit command. If the rollback timer is stopped, the new softwareversion could be run on the device for any duration and then rolled back to the previous version.

ISSU Upgrade: 1-Step Work Flow

This workflow involves only one step and helps in optimization. You cannot roll back as the upgrade iscommitted automatically.

For more information about ISSU release support and recommended releases, see Technical References→In-Service Software Upgrade (ISSU).

Restrictions and Guidelines for Performing ISSU• Upgrading hardware and software simultaneously is not supported. Only one upgrade operation can beperformed at a time.

• We recommend that upgrades are performed during a maintenance window.

• Do not perform any configuration changes while the ISSU process is being performed.

• Downgrade with ISSU is not supported.

• ISSU is not supported for an upgrade from IOS XE Fuji 16.9.x to IOS XE Gibraltar 16.10.x. This appliesto a dual supervisor module setup.

• While performing ISSU fromCisco IOSXE Fuji 16.9.x to Cisco IOSXEGibraltar 16.12.x, if interface-idsnmp-if-indexcommand is not configured with OSPFv3, packet loss can occur. Configure the interface-idsnmp-if-index command either during the maintenance window or after isolating the device (by usingmaintenance mode feature) from the network before doing the ISSU.


Configuring ISSURestrictions and Guidelines for Performing ISSU

https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst_standalones/b-in-service-software-upgrade-issu.html

Upgrade Software Using 1-Step WorkFlowBefore you begin

• The device must be booted in the install mode.

Procedure



enable

Example:

Step 1

Switch> enable

Automates the sequence of all upgradeprocedures that include downloading the images

install add file { ftp: | tftp: | flash: | disk:*.bin } actvate issu commit

Step 2

to both the switches and expanding intopackages, and upgrading each switch as per theprocedure.

This command throws an error if theswitch is booted with a bundleimage.

Note

Upgrade Software Using 3-Step WorkFlowBefore you begin

• The device must be booted in the install mode.

Procedure



enable

Example:

Step 1

Switch> enable

This command downloads the image into thebootflash and expands it on both the switches.

install add file { ftp: | tftp: | flash: | disk:*.bin }

Example:

Step 2

Switch# install add file ftp:file.bin

On executing this command, the followingsequence of events occurs:

install activate issu

Example:

Step 3


Configuring ISSUUpgrade Software Using 1-Step WorkFlow

PurposeCommand or ActionSwitch# install activate issu a. A rollback timer is started. If the rollback

timer expires, the system rolls back to thesame state before the start of the ISSU. Therollback timer can be stopped by using theinstall abort-timer stop command. ISSUcan be rolled back using install abort issucommand.

b. The standby switch is provisioned with thenew software and it reloads with the newsoftware version. Next, the active switch isprovisioned with the new software and itreloads. The standby switch with the newimage now becomes the active switch andthe old active switch becomes the standby.

c. At the end of this procedure, both theswitches run with the new software image.

The commit command performs the necessaryclean up, enables the new software as permanent

install commit

Example:

Step 4

(removing the older version of the software)Switch# install commit and stops the rollback timer. Any reboot after

the commit will boot with new software.

There is no rollback when thiscommand is used.

Note

Monitoring ISSUTo verify ISSU on SatckWise Virtual, use the following show commands:

DescriptionCommand

Displays a list of the current ISSU clients--that is, thenetwork applications and protocols supported byISSU.

show issu clients

Displays the formats, versions, and size of ISSUmessages supported by a particular client.

show issu message types

Displays results of a negotiation that occurredconcerning message versions or client capabilities.

show issu negotiated

Displays detailed information about a particular ISSUclient, includingwhether the client status is compatiblefor the impending software upgrade.

show issu sessions


Configuring ISSUMonitoring ISSU

DescriptionCommand

Displays information regarding the ISSU compatibilitymatrix.

show issu comp-matrix

Displays information about entities within one or moreISSU clients.

show issu entities

Displays the current ISSU state.show issu state [detail]

Feature Information for ISSUThe following table provides release information about the feature or features described in this module. Thistable lists only the software release that introduced support for a given feature in a given software releasetrain. Unless noted otherwise, subsequent releases of that software release train also support that feature.

Use Cisco Feature Navigator to find information about platform support and Cisco software image support.To access Cisco Feature Navigator, go to www.cisco.com/go/cfn. An account on Cisco.com is not required.

ReleaseFeature Name

Cicso IOS XE Fuji 16.9.1ISSU

Cisco IOS XE Fuji 16.9.2ISSU on SVL


Configuring ISSUFeature Information for ISSU

http://www.cisco.com/go/cfn


Configuring ISSUFeature Information for ISSU