Replacing slot #1 XOS

  • 1
  • 1
  • Problem
  • Updated 1 year ago
  • Not a Problem

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

Photo of Sarah Seidl

Sarah Seidl

  • 1,326 Points 1k badge 2x thumb

Posted 1 year ago

  • 1
  • 1
Photo of OscarK

OscarK, ESE

  • 7,912 Points 5k badge 2x thumb
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...
Photo of Sarah Seidl

Sarah Seidl

  • 1,326 Points 1k badge 2x thumb
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 8).
Photo of OscarK

OscarK, ESE

  • 7,912 Points 5k badge 2x thumb
You encounter this only on slots that are master with that key not installed internally.
Photo of Sarah Seidl

Sarah Seidl

  • 1,326 Points 1k badge 2x thumb
that makes sense, thanks again
Photo of Steven Lin

Steven Lin, Employee

  • 2,320 Points 2k badge 2x thumb
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
Photo of Sarah Seidl

Sarah Seidl

  • 1,326 Points 1k badge 2x thumb

Thanks could you add this to the documentation?


OscarK ESE profile picture

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 <slot>, that will sync OS versions and all files on the new slot to be the same as the current master.
sync stacking slot <slot> will sync all stacking parameters to the new slot.

Photo of Naresh

Naresh, Employee

  • 1,336 Points 1k badge 2x thumb

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

Photo of Sarah Seidl

Sarah Seidl

  • 1,326 Points 1k badge 2x thumb

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



Photo of OscarK

OscarK, ESE

  • 7,912 Points 5k badge 2x thumb
After you have replaced all the slots needed, before you do reboot the complete stack, sync all new slots. sync slot <slot>, that will sync OS versions and all files on the new slot to be the same as the current master.
sync stacking slot <slot> will sync all stacking parameters to the new slot.
Photo of Sarah Seidl

Sarah Seidl

  • 1,326 Points 1k badge 2x thumb
Thanks again!
Photo of Sarah Seidl

Sarah Seidl

  • 1,326 Points 1k badge 2x thumb

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

Photo of Doug Hyde

Doug Hyde, Technical Support Manager

  • 20,514 Points 20k badge 2x thumb
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...