ExtremeSwitching (Other)

Expand all | Collapse all

Replacing slot #1 XOS

  • 1.  Replacing slot #1 XOS

    Posted 08-02-2017 09:22
    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



  • 2.  RE: Replacing slot #1 XOS

    Posted 08-02-2017 09:26
    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...



  • 3.  RE: Replacing slot #1 XOS

    Posted 08-02-2017 09:26
    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 😎.


  • 4.  RE: Replacing slot #1 XOS

    Posted 08-02-2017 09:26
    You encounter this only on slots that are master with that key not installed internally.


  • 5.  RE: Replacing slot #1 XOS

    Posted 08-02-2017 09:26
    that makes sense, thanks again


  • 6.  RE: Replacing slot #1 XOS

    Posted 08-02-2017 09:31
    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


  • 7.  RE: Replacing slot #1 XOS

    Posted 08-02-2017 09:31
    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





  • 8.  RE: Replacing slot #1 XOS

    Posted 08-02-2017 09:31
    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


  • 9.  RE: Replacing slot #1 XOS

    Posted 08-03-2017 17:21
    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



  • 10.  RE: Replacing slot #1 XOS

    Posted 08-04-2017 05:18
    After you have replaced all the slots needed, before you do reboot the complete stack, sync all new slots. sync slot


  • 11.  RE: Replacing slot #1 XOS

    Posted 08-04-2017 05:18
    Thanks again!


  • 12.  RE: Replacing slot #1 XOS

    Posted 08-16-2017 09:14
    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



  • 13.  RE: Replacing slot #1 XOS

    Posted 08-23-2017 16:51
    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...