Migrate from 1GB to 10GB uplinks - help?

[Frank]

I have a simple setup - two core switches (8800s), several edge switches (460s) connected like this: 8800s are running 16.1.3.6-patch1-9, 460-1 is on 15.4.1.3, 460-2 is on 15.6.1.4.

My problem is that the 460s are on 1GB fiber (ports 55,57) and I need to upgrade them to 10GB while everything stays up and running, i.e. the devices connected to the 460s don't lose access to the network.
The end goal is that the 10GB uplinks also need to be in ports 55,57 (for sanity's sake) Ideally, the corresponding ports in the 8800 should also stay the same (sanity!), but I could be persuaded to use different ports.

If I understand correctly, I can't just replace the SFPs one by one because of port speeds and sharing configs/mismatches.
Physically, the two 460s are right on top of each other, so I could run something between them and use that as an alternate path, but I also hear that loops are deadly. I don't think I can easily define that as a 460-ISC MLAG, as I'd have to put the ports on the 8800 side into sharing mode, affecting vlan-port associations to the 460. (Let's say vlan 1 goes to 460-1 vlan 2 goes to 460-2, let's say on the 8800s port 1:11 goes to 460-1, port 1:12 goes to 460-2. What all would die if I group 1:11 and 1:12? At least all vlans pointing to 1:12 would have an issue, right?)

On the other hand, I'm not currently running spanning-tree. If I connect the 460-1/2 with a gig-ether (or two , shared) in a non-MLAG setup, make sure all vlans that exist on both switches are defined to go to to both switches (and the connection between the 460s) and define spanning-tree on all the vlans, would that get me to a point where I can just rip out one 460's fiber uplink, replace it with 10G, then do the other 460, then disconnect the link between the 460s and kill off STP?

I've never configured STP on Extreme switches, btw. Especially not with share groups and an MLAG.

So, how can I pull this off without downtime (or downtime in the "few seconds" range)? Would STP be viable? Is there something better I can do during the fiber/SFP replacements?

Thanks for your help!
Frank

[Frank]

According to my graphs, something went haywire as heck. Some day when I can make the time , I'll dig deeper into that in a lab setting. For right now, I'm afraid to tick off too many customers if "very carefully" goes sideways.

As to configuring redundancy on both switches, I'm hesitant - if I use the same redundancy port (40) on both sides, I'm not sure what'll happen in case of a failure. If switch-1's port 55 fails, port 40 goes active. However, since switch-2's port 55 is still active, wouldn't it continue to block port 40 / have link-off? Regardless of whether we'd use "link-on" or "link-off"?

[Frank]

So I played with port redundancy. Made sure that all VLANs on switch-1 are also known to switch-2, made sure that all vlans are tagged to the backup link (port 40, which is a group of port 40,41) on both switch-1 and switch-2. At this point, ports 40,41 were disabled on both switches, because otherwise I'd have a bad loop - plus, some VLANs have access ports on both switches for ASA failover pairs and other redundancy things.

Then I thought that the "link on" option for redundancy sounded really nifty! Off I went on switch-1:
enable ports 40,41 (still disabled on switch-2)
configure port 55 redundant 40 link on

Now, as soon as I enabled port 40,41 on switch-2, I see RX traffic on switch-1. Not TX, but RX, so switch-2 decided (rightfully so) to send appropriate traffic to switch-1.
I didn't quite expect switch-1 to receive anything due to the software blocking the redundant link. It appears as if it only blocks TX, but not RX? (15.4.1.3 patch 1-10)
Got a little hectic, disabled the redundancy ports, reconfigured with "Link Off", now things appear to be working as expected.

Is the expected behavior on "link on" to only block TX while the primary port is still up? Is it perhaps because I used a redundant group?

[Michal_Rz]

If link redundant is configured to be on on switch-1, then switch-2 will send only
broadcast's, because from his perspective link is working normal, but aint see who is on the other side, thats why It send only broadcast and not unicasts. Also switch-1 can recive EDP, CDP packets or something else like that. To test it simple is to do
show edp port 40,41
and you will see neighbor, so EDP packets must goes through redundant port.

You can check traffic by yourself by capturing traffic on this port.
https://gtacknowledge.extremenetworks.com/articles/How_To/How-to-perform-a-local-packet-capture-on-a...
I have done it to test my theory 🙂

Also turning redundant link to be off it will extend switching process time from primary to secondary port.

[Frank]

Thanks for the tips on smart/software-controlled redundancy!
I'd like to add (from the 16.1 manual - see, I *do* read those things! - Emphasis mine):

• The master port is the only port of a load-sharing group that can be configured as either a primary or redundant port. Also, all ports on the load-sharing group must fail before the software-controlled redundancy is triggered.

The remaning question is:
• To configure the switch for the Smart Redundancy feature, use the following command:
enable smartredundancy port_list

Would that be a port-list of the redundant ports, the primary and redundant ports, or (for lazy people like me), just a list of all ports?

[Frank]

Nevermind. Earlier during the intro-paragraph, it states:

By default, Smart Redundancy is always enabled. If you enable Smart Redundancy, the switch automatically fails over to the redundant port and returns traffic to the primary port after connectivity is restored on that port.
If you do not want the automatic restoration of the primary link when it becomes active, disable Smart Redundancy.

Gracias, Señor Manual 😉