10-07-2025 09:49 AM
TL;DR
We have trunks between two datacenters, with stretched vlans, that put were in place for DC migration and were never cleaned up completely. Does it matter?
I work on a large enterprise network that, once upon a time, shifted its on-prem datacenter workload to a co-lo facility and along the way layer two was stretched between old and new datacenters via several few port channels and fiberoptic gear.
Several trunks exist with inconsistent VLAN pruning. Some team members prune vlans when they create new ones, some do not. Some team members just prune one side of the port channel. It gives me spanning tree nightmares.
Some of the l2 environments were stretched deliberately to aid I migrations, some were part of the fallout of using the same ID on both sides of the port channel and creating an all-inclusive trunk. Some L2 environments have shifted the workloads completely to the new DC and some still have clients and/or servers in both locations. The stp roots are inconsistent , not always with the gateway, not always on the same side of the port channel that the clients are on.
New vlans created in the new DC sometimes are inadvertantly stretched back to the campus facility is due to lack of pruning on these "migration links" It's like a big nasty chewed up piece of gum that everyone steps in and unknowingly drags it around.
Tasked with cleaning up the remnants of datacenters past, my team and I have removed some unused vlans and pruned them from the stretched trunks. The more we prune the uglier the allow list becomes as ranges are broken up into smaller ranges.
We are soon to be deploying new datacenter network equipment and migrating off the old gear with stretched L2. I hear that we must have a true l3 boundary between sites. Which makes sense to me, although I can't articulate why. We are still working on re-ip some of the clients , moving gateways on some subnets. Deleting old vlans that aren't in use any longer.
I'm being questioned if it is worth it to clean up the "cosmetic" issue of vlans that don't exist on one side but are "allowed* on the trunks. I would just feel better if it was cleaned up while we hack away at the live environments and sort who goes where. I need help thinking of why it is or is not important to prune the trunks if they are eventually going to be removed anyway. Basically...which way is more risky...cleaning it up as we go , or getting the live vlans sorted out and then shutting down the rest in one swoop.
10-07-2025 03:01 PM
@jlw7595 wrote:
We have trunks between two datacenters, with stretched vlans, that put were in place for DC migration and were never cleaned up completely. Does it matter?
Perhaps the two biggest issues/concerns might be, VLANs extended where they shouldn't be, provide a security threat; and needless traffic on such trunks.
@jlw7595 wrote:
I'm being questioned if it is worth it to clean up the "cosmetic" issue of vlans that don't exist on one side but are "allowed* on the trunks. I would just feel better if it was cleaned up while we hack away at the live environments and sort who goes where. I need help thinking of why it is or is not important to prune the trunks if they are eventually going to be removed anyway. Basically...which way is more risky...cleaning it up as we go , or getting the live vlans sorted out and then shutting down the rest in one swoop.
My personal experience has been, half "a*sed" solutions have a nasty habit of coming back and causing problems later (although if you're lucky, you'll be long gone by then and it will be someone else's problem). So, I like to see things done "right", however I'm not adverse to incremental "fixes", that in the short term, negate much if not most of the potential issues, but are not intended to be the final resolution.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide