X670G2 EAPS Ring upgrade

[Ben_Giles]

Hi,

We’re running nine X670G2 switches for our core backbone network in an EAPs ring topology, including MLAG / OSPF / BGP / VRRP

The code base is quite old, 21.1.1.4-patch1-5.  We’re looking to upgrade to the latest maintenance release EXOS 22.7.1.2-patch1-15.

Does anyone follow a certain series of steps when upgrading their core switches?  The Extreme documentation and TAC indicate it’s as simple as upgrading one at a time, but I wonder if we will encounter any issues along the way others might have experience with?

Is there any configuration sanitation you go through when preparing for an upgrade?

Thanks!

[Ben_Giles]

I’m working on getting some less important switches to test the upgrade on, from what I’ve seen there is no way you can upgrade a virtual EXOS switch?

Ideally I’d create a three node EAPs ring virtually with similar config and then upgrade.  We don’t carry spare switches unfortunately.

[EtherMAN]

100% agree with Fredrik.  We don’t use stack in core services except where we have our VM’s setup up in Data center.  We have moved from EAPS to ERPS due to the ability to have a hold over timer to restore when broken link comes up and interoperability with other vendors. Still 85 or so Eaps rings in coer and upgrade process has always gone very well.  With you running so many protocols I would lab up a single box if you could and do an upgrade and then compare configurations to make sure they are not broken due to some difference in the commands between code revs.  I would not attempt this without having hands on and plugged directly into com interface for first node you plan to do to watch for boot up changes or errors.  It may also save you some grief if you break unplug and put your rings in failed state before you reboot.  Do the upgrade … make sure all you routing have stabilized and happy then plug the ring back in to complete the EAPS rings.  

Good luck 

[Ben_Giles]

Thanks very useful information, I’ll be careful to backup the configs outside of XMC.

Yes unfortunately all protocols are running on the same box, we’re moving towards layers of separation but it’s a slow process.

[FredrikB]

You may want to wait for the January patch to come out. I know there are some relevant fixes for MLAG in that one that you will want (if you can wait). You run quite a bunch of protocols in that environment. I hope you don’t have all that in the same boxes, or do you? Separating tasks could be worth looking into. I tend to move away from EAPS, especially in stacks as there are (still) issues with that in failover and reboot scenarios.

Generally, upgrading is not much of a fuzz. Downgrading can be a pain if the config has been converted by the upgrade process. Make sure you have the old image and config in the sec (or pri) partition so you can rollback easily. If you use XMC/NetSight, you should be aware that it will overwrite the primary config with the current one, so you cannot rely on the primary config file to be present after an XMC backup. A fix for this is coming in XMC 8.4 in February. In the meantime, save the config to a separate file on the switch(es) and obviously you need to make sure you have external backups of the configs when upgrading.

/Fredrik