09-21-2014 02:12 PM - edited 03-07-2019 08:49 PM
Hi Team,
I am in the process of replacing the Primary SUP (SUP 720-10G) on Cat 6513 in VSS pair.
Currently the Primary SUP is operational but for some reason we need to replace this SUP with RMA SUP.
So i want to know that should i follow the same procedure which is mentioned in the attached document or this document is only for replacing the standby SUP.
Before replacing the Primary SUP we need to do the switchover (redundancy force-switchover) so that current standby SUP take role of active SUP and current active SUP take role of standby SUP.
Please share your experience/comments.
Thanks
09-21-2014 05:21 PM
Yes this is the correct procedure and its the same for replacing the primary as well.
Just make sure you do the force switch over to the standby sup so that it takes over the acitve role and then remove the primary and swap with the new one.
HTH
09-22-2014 01:58 PM
Dear Insharie
Thanks for the reply.
Can you please illustrate what series of sequence will occurred if i do redundancy force-switchover on the Primary SUP with the following configuration
switch virtual domain 10
switch mode virtual
switch 1 priority 200
mac-address use-virtual
As per my understanding following will be the sequence. Please correct if something is missing or wrong.
When we will do redundancy force-switchover the whole chassis of current active SUP will get reloaded (SUP and all cards) and transfer the control plan ownership to standby SUP and it takes over the active role and when the chassis of formerly active SUP come backs it takes over the standby role and will remain in standby role if preemption is not configured.
Also want to know the importance of switch ID number.
Does switch ID number has any relation of selecting the role of supervisor (active/standby)
09-22-2014 10:11 PM
Dear Insharie
Awaiting of your response.
Appreciate if you could reply as we need to do the activity in next couple of days.
09-23-2014 01:35 AM
Hi All,
If you perform the "redundancy force-switchover", this will reload of the ACTIVE supervisor, which include VSL link and it will be down
The following sequence of events provide a summary of the failover convergence process:
Switchover is invoked via software CLI, removing supervisor, powering down active switch, or system initiation.
The active switch relinquishes the unified control plane; the hot-standby initializes the SSO control plane.
All the line cards associated with active switch are deactivated as the active chassis reboots.
Meanwhile, the new active switch (previous hot-standby switch) restarts the routing protocol and starts the NSF recovery process.
In parallel, the core and access-layer rehash the traffic flow depending on the topology. The unicast traffic is directed toward the new active switch, which uses a hardware CEF table to forward traffic. Multicast traffic follows the topology design and either rebuilds the multicast control plane or uses the MMLS hardware table to forward traffic.
The NSF and SSO functions become fully initialized, start learning routing information from the neighboring devices, and update the forwarding and control plane protocols tables as needed.
Second:
=========
If the VSS active chassis or supervisor engine fails, the VSS initiates a stateful switchover (SSO) and the former VSS standby supervisor engine assumes the VSS active role. The failed chassis performs recovery action by reloading the supervisor engine
If the VSS standby chassis or supervisor engine fails, no switchover is required. The failed chassis performs recovery action by reloading the supervisor engine
The VSL links are unavailable while the failed chassis recovers. After the chassis reloads, it becomes the new VSS standby chassis and the VSS reinitializes the VSL links between the two chassis
The switching modules on the failed chassis are unavailable during recovery, so the VSS operates only with the MEC links that terminate on the VSS active chassis. The bandwidth of the VSS is reduced until the failed chassis has completed its recovery and become operational again. Any devices that are connected only to the failed chassis experience an outage.
Note:
The VSS may experience a brief data path disruption when the switching modules in the VSS standby chassis become operational after the SSO
After the SSO, much of the processing power of the VSS active supervisor engine is consumed in bringing up a large number of ports simultaneously in the VSS standby chassis. As a result, some links might be brought up before the supervisor engine has configured forwarding for the links, causing traffic to those links to be lost until the configuration is complete. This condition is especially disruptive if the link is an MEC link. Two methods are available to reduce data disruption following an SSO
Beginning in Cisco IOS Release 12.2(33)SXH2, you can configure the VSS to activate non-VSL ports in smaller groups over a period of time rather than all ports simultaneously
You can defer the load sharing of the peer switch's MEC member ports during reestablishment of the port connections
At the same time, i would like to share somd best practice about FWSM intergration with VSS
Refer:
http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps9336/white_paper_c11_513360.html
Please verify the #show redundancy status
Router# show redundancy status
my state = 13 -ACTIVE
peer state = 8 -STANDBY HOT
Mode = Duplex
Unit = Secondary
Unit ID = 18
Redundancy Mode (Operational) = sso
Redundancy Mode (Configured) = sso
Redundancy State = sso
Replace a Supervisor in your VSS pair than they way documented in the URL below:
http://www.cisco.com/en/US/products/ps9336/products_configuration_example09186a0080a64891
.shtml
<http://www.cisco.com/en/US/products/ps9336/products_configuration_example09186a0080a64
891.shtml >
I would recommend you do not stray the document proceedures, as those are definitely the
best way to swap out the Supervisor. There are some eliments of the virtual configuration
which are not saved in the configuration file (they are stored in memory), so you can’t
just use the old Supervisors config file. The document has you entering the vital config
that is necessary for the new Supervisor to come up with no issues.
HTH
Regards
Inayath
09-23-2014 05:23 AM
Dear Insharie
Thanks for your reply.
Appreciate if you could reply on the following queries.
I just to know with the following config if i do redundancy force-switchover on the Primary (active) SUP then the primary SUP get reloaded and standby SUP takes over the active role and when the formal active SUP will come online then will it remain in standby mode or will become active again b/c of high configured priority (200) on that switch.
When the formal active SUP will come online then the configuration of this SUP will get sync from current active SUP or not.
switch virtual domain 10
switch mode virtual
switch 1 priority 200
mac-address use-virtual
Also want to know the importance of switch ID number.
Does switch ID number has any relation of selecting the role of supervisor (active/standby)
Following link is not opening, can you please send the PDF.
<http://www.cisco.com/en/US/products/ps9336/products_configuration_example09186a0080a64891.shtml >
I would recommend you do not stray the document proceedures, as those are definitely the
best way to swap out the Supervisor. There are some eliments of the virtual configuration
which are not saved in the configuration file (they are stored in memory), so you can’t
just use the old Supervisors config file. The document has you entering the vital config
that is necessary for the new Supervisor to come up with no issues.
In your above comments, what are the config elements which are not save in config file.
Is it switch ID only and anything else.
09-23-2014 01:30 PM
Dear Insharie
Appreciate if you could spare some time and response to the requested queries
09-24-2014 12:25 PM
Dear Insharie
Appreciate if you could response to the requested queries.
Thanks in advance
09-24-2014 05:45 PM
Here is the answer:
1- just to know with the following config if i do redundancy force-switchover on the Primary (active) SUP then the primary SUP get reloaded and standby SUP takes over the active role and when the formal active SUP will come online then will it remain in standby mode or will become active again b/c of high configured priority (200) on that switch.
Answer: When you reboot the Switch the Primary goes down and Secondary would take over the Active role. Now when the Active sup is back the failover to the Active would not happen even though it has the highest priority(Same process as OSPF DR).
2-
When the formal active SUP will come online then the configuration of this SUP will get sync from current active SUP or not.
Answer: Yes the config would get sync. But if you have replaced it with the new SUp you need to do the configuration before attaching to VSS.
switch virtual domain 10
switch mode virtual
switch 1 priority 200
mac-address use-virtual
Also want to know the importance of switch ID number.
Does switch ID number has any relation of selecting the role of supervisor (active/standby)
Answer; NO Switch ID has no relation in selecting the role of Supervisor.
Please refer below link for more info:
http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst6500/ios/12-2SX/configuration/guide/book/vss.html#wp1111770
HTH
Regards
Inayath
**********Please dont forget to rate all usefull posts********
09-24-2014 11:25 PM
Dear Inayath
Appreciate your prompt response.
Could you please also clarify the following
In your below comments, what are the config elements which are not save in config file. Is it switch ID only and anything else ?
I would recommend you do not stray the document proceedures, as those are definitely the best way to swap out the Supervisor. There are some eliments of the virtual configuration which are not saved in the configuration file (they are stored in memory), so you can’t just use the old Supervisors config file. The document has you entering the vital config that is necessary for the new Supervisor to come up with no issues.
Following link is not opening, can you please send the PDF.
<http://www.cisco.com/en/US/products/ps9336/products_configuration_example09186a0080a64891.shtml >
09-24-2014 11:47 PM
Sorry Farooqi,
I dont have the PDF with me.
HTH
Regards
Inayath
************Please dont forget to rate usefull posts**********
09-26-2014 07:39 AM
Dear Inayath
Is below the same document (which you referred earlier) if compared to attached document in PDF
http://www.cisco.com/en/US/products/ps9336/products_configuration_example09186a0080a64891
09-26-2014 10:39 PM
yes kind of.
09-27-2014 12:24 AM
Dear Inayath
Can you please arrange to send me this document.
And what are the config elements which are not save in config file.
Is it switch ID only or anything else ?
Also wanted to clarify the following
1) Whenever I do 'redundancy force-switchover' the current active SUP will get reloaded and the current standby SUP will take over the primary role.
And when formal active SUP (current standby) come online then the configuration of this SUP will get sync from current active SUP (formal standby SUP) . Is that mean that all the existing config of formal active SUP will get overridden with the config of current active sup ?
Will the 'Bulk config syn logs' be displayed on Active or standy SUP during config synchronization.
10-06-2014 02:17 PM
Dear Inayath
Also wanted to clarify the following
1) Whenever I do 'redundancy force-switchover' the current active SUP will get reloaded and the current standby SUP will take over the primary role.
And when formal active SUP (current standby) come online then the configuration of this SUP will get sync from current active SUP (formal standby SUP) . Is that mean that all the existing config of formal active SUP will get overridden with the config of current active sup ?
Will the 'Bulk config syn logs' be displayed on Active or standy SUP during config synchronization.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide