topic RE: Replacing slot #1 XOS in ExtremeSwitching (Other)

Replacing slot #1 XOS

Sarah_Seidl — Wed, 02 Aug 2017 16:22:00 GMT

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

RE: Replacing slot #1 XOS

OscarK — Wed, 02 Aug 2017 16:26:00 GMT

You see this because of a bug in EXOS when you load on the new slot a config where there is an SSH key but there is none stored internally.
Check this article, a solution would be upgrading to a release that contains a fix.
https://gtacknowledge.extremenetworks.com/articles/Solution/Why-does-Enter-passphrase-show-up-during...

RE: Replacing slot #1 XOS

Sarah_Seidl — Wed, 02 Aug 2017 16:26:00 GMT

Thank you, so want to make sure I understand would this only apply to replacing slot 1? We don't seem to have this type of trouble when we replace other nodes (example slots 2 thru .

RE: Replacing slot #1 XOS

OscarK — Wed, 02 Aug 2017 16:26:00 GMT

You encounter this only on slots that are master with that key not installed internally.

RE: Replacing slot #1 XOS

Sarah_Seidl — Wed, 02 Aug 2017 16:26:00 GMT

that makes sense, thanks again

RE: Replacing slot #1 XOS

Steven_Lin — Wed, 02 Aug 2017 16:31:00 GMT

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

RE: Replacing slot #1 XOS

Naresh — Wed, 02 Aug 2017 16:31:00 GMT

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

RE: Replacing slot #1 XOS

Sarah_Seidl — Wed, 02 Aug 2017 16:31:00 GMT

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.

RE: Replacing slot #1 XOS

Sarah_Seidl — Fri, 04 Aug 2017 00:21:00 GMT

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

RE: Replacing slot #1 XOS

OscarK — Fri, 04 Aug 2017 12:18:00 GMT

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.

RE: Replacing slot #1 XOS

Sarah_Seidl — Fri, 04 Aug 2017 12:18:00 GMT

Thanks again!

RE: Replacing slot #1 XOS

Sarah_Seidl — Wed, 16 Aug 2017 16:14:00 GMT

Hello, I have to say we are almost at wits end. With this new code I feel it's virtually impossible to get things to go properly the first time. Here's the most recent example:

Scenario: Stack of 3 devices
X460-48p - slot 1 Master
X460-48p - Slot 2 Backup
X460-48p - Slot 3 Standby

16.2.3.5 p1-6 primary (current stack booted into primary)
16.2.2.4 p1-3 secondary

Slots 1 and 3 have poe failure. Steps taken
1. Remove slot 3
2. install replacement slot 3
3. join to stack; enable stacking node-address (new slot 3), configure stacking node-address (new slot 3), synchronize stacking (new slot 3).
4. Reboot node-address (new slot 3) so it can join the stack.
5. It successfully joins the stack, issue command synchronize slot 3 - it synchronizes, reboots and again joins the stack.
6. Repeat steps 1 thru 5 but now for slot 1.
7. Now everything is replaced the stack is backup after the slots 1 and 3 had synchronized (before the stack reboot as OscarK recommended).
8. Configure stacking mac address and reboot
9. Stack comes back up, now slot 1 is again master, but slots 2 and 3 crash and reboot.
The only way to get the stack stable again is to unconfigure switch all (you have to catch the stack between rebooting of slots 2/3 it seems). Then you have to load script.

Why oh why? What can I do differently? Do I not need to do step 8, does synchronize slot take care of the stack mac?

Thanks in advance

RE: Replacing slot #1 XOS

Doug — Wed, 23 Aug 2017 23:51:00 GMT

Sarah,

If you are still having issues I would suggest to contact the GTAC for further assistance.
https://gtacknowledge.extremenetworks.com/articles/How_To/How-to-contact-Extreme-Networks-Global-Tec...