cancel
Showing results for 
Search instead for 
Did you mean: 

Replacing slot #1 XOS

Replacing slot #1 XOS

Sarah_Seidl
New Contributor III
Hello, I am trying to understand the proper method for replacing slot #1 (<-- specifically) in an XOS stack. Example: (2) 460-48p switches, Master & Backup running 16.2.2.4 p1-3. Slot #1 needs to be replaced. Prep replacement with proper code and partitions enable stacking protocol enhanced. Remove existing switch 1, switch 2 becomes master. Install new switch 1, enable stacking node-address (new node's info), configure stacking node-address (new node's info) slot-number 1, synchronize stacking node-address (new node's info). Reboot node-address (new node's info). New node comes back up (see vlan synch, fdb, acl synching). Stack looks okay for now. Issue command configure stacking mac address and reboot the stack. At this point new slot 1 becomes master and gets stuck at enter passphrase. And the switch reboots. The only way we have found to resolve this is to then config none on all switches in the stack, and load script of the original config. This is time consuming and not the preferred method I can guess.This has happened at several locations that we've had to replace slot #1 in particular. So it's not just one example. What would be the best method for success for replacing slot #1 in XOS?
Thanks,
Sarah

12 REPLIES 12

Sarah_Seidl
New Contributor III
So we had another crack at this. Had a stack of (3) x460-48p (G1s), 2 of the 3 which needed replacing, slots 1 and 2. So in preparation upgraded the stack to the 16.2.3.5 code and rebooted the stack, it was running the new code. Before we began the replacements the setup was like this.

Slot 1 - master

Slot 2 - backup

Slot 3 - standby

Steps Taken: replaced slot 2. Slot 3 became the backup (slot 1 still master). Added slot 2 to the stack using the standard commands enable stacking, configure stacking and give slot and synchronize stacking, then rebooted the new slot 2. It joined the stack just dandy. So now we have slot 1 master, 2 standby and 3 backup. Then replaced slot 1, it too was a champ and joined the stack as expected. It became a standby after it was rebooted. Then issued command configure stacking mac-address from the master node (slot 3 which we never had replaced but was the master at the time). Once the stack rebooted, all 3 nodes were stacked together, it booted all the way up (thanks for the tip on the newer code) but there was no config. And my .xsf file that I had saved (which would have been on all slots including slot 3) was of no use, was on a slot that I couldn't copy things from (standby).

Slot 1 - master, Slot 2 - backup, Slot 3 - standby.

It was as if it was a new switch. Had to copy an xsf file to the stack and load it to get things talking. Why didn't the config keep? Am I missing something still?

Any tips on what can I do to improve having to restore a config each time b/c the switch defaults?

Thanks,

Sarah

Sarah_Seidl
New Contributor III
Thanks could you add this to the documentation?





OscarK (ESE) replied to this problem:

Replacing slot #1 XOS


After you have replaced all the slots needed, before you do reboot the complete stack, sync all new slots. sync slot , that will sync OS versions and all files on the new slot to be the same as the current master.
sync stacking slot will sync all stacking parameters to the new slot.



Naresh
Extreme Employee
Hi,

Adding to above comment, pease find the below article to find the steps “how to replace node in a summitstack” using below link

https://gtacknowledge.extremenetworks.com/articles/How_To/How-to-replace-a-node-in-a-SummitStack



Steven_Lin
Extreme Employee
There is an article introduce about how to replace a node in a SummitStack, hope it's helpful!
https://gtacknowledge.extremenetworks.com/articles/How_To/How-to-replace-a-node-in-a-SummitStack

Sarah_Seidl
New Contributor III
that makes sense, thanks again
GTM-P2G8KFN