This topic has been marked solved and closed to new posts due to inactivity. We hope you'll join the conversation by posting to an open topic or starting a new one.
I need to "upgrade" my very old Netgear switches (1 stack of 2 GS724TS) to M4300 new gen (1 stack of 2 m4300-24x24f) and start enjoying the 10G links copper & fiber.
My plan is to rack the new M4300 stack just above the legacy GS stack, create a LAG multi-vlan trunk, and migrate all 'server' cables one-by-one to avoid any downtime.
As all my servers use either multi NIC or bonding, I expect very short / 0 loss network connectivity for the applications running on servers.
As a pre-requisite:
I'm ensuring configurations are similar (with the +24 port translation on the m4300 24x24f cause copper cables start at port 25) in terms of VLAN, PVID, .. on the OLD and NEW switches
Ports used for LAG are free and do not have any specific VLAN attached to it
Regarding the LAG,
I want it using 1 port on each stack member (for redundancy), and configure VLAN mode TAGGED on the LAG1 just created for each of my VLAN defined.
I'm doing step1 on both my old switches and new switches
just to update & close this thread after having done migration.
This worked fine for non complex single-cabled servers and with servers having NIC bonding, losing a single ping when de-cabling / re-cabling.
It went not fine with ESX servers for some unknown reasons, vlans were not properly propagated until i moved the firewalls (doing the segregation between vlans) to new switches.
Was it is misconfiguration from my side, or something really not working for a good reason, i'll never know.
Hmm, I don't think this is going to work without any sort of (albeit very small) downtime if the configuration is corret on both the interconnect between the old and the new stack.
Both switch generations do support distributing LAG members across different switches _when stacked together_. In contrast: The M4500 does multi-chassis LAG (MLAG) - without stacking. Since you cannot stack the two generations together into 1 stack you cannot stretch LAG member ports across these two generations / series of switches.
Thus your LAG trunk between the old and new stack looks sound / sane to me if that is all of your switches that you currently have in that setup.
But I would not attempt having the server connected to both switches at the same time. I'd definitely prefer having a small maintenance window for each server: Assuming you have LAGs with 2 ports per Server, I would unplug both server ports on the old switch, then plug both into the new stack. Then check if the server and switch bring the LAG / port-channel up and if your server and applications can talk to the servers that are still on the old switch. Then rince and repeat with the rest of the servers.
The issue is, that it might confuse the heck out of either the server or the switches when you try to keep form / bring up a LAG on your server side while the 2 ports are connected to 2 independent stacks that don't know about LAG members between these 2 generations.
This way the LAG goes down from the perspective of the server, this way the server will properly exchange LACP message between the M4300 switches when the ports are reconnected on the new stack.
just to update & close this thread after having done migration.
This worked fine for non complex single-cabled servers and with servers having NIC bonding, losing a single ping when de-cabling / re-cabling.
It went not fine with ESX servers for some unknown reasons, vlans were not properly propagated until i moved the firewalls (doing the segregation between vlans) to new switches.
Was it is misconfiguration from my side, or something really not working for a good reason, i'll never know.
