Wandering Thoughts archives


Our three generations of network implementations (over the time I've been here)

Over the time I've been here, we've had pretty much the same network structure but we've gone through three different major physical implementations of it. Between the three of them, we've pretty much covered the full spectrum of sensible ways to implement a multi-network environment.

When I arrived, we were at the tail end of the first implementation. This was built around a small number of big chassis switches from Foundry, the kind that take various sorts of 'blades', also known as cards (at the time, most of these were for 100 MBit ports). Every Foundry carried all of our networks as separate VLANs, and almost all of our drops were connected straight into the Foundry in the nearest building wiring closet or machine room. To 'rewire' a drop in a room to a different internal network, we changed the port's configuration on the relevant Foundry. The Foundries connected to each other over a set of trunk network connections (carried over fiber).

The second implementation was an attempt to duplicate this setup using individual 24-port switches instead of new big chassis switches (because we couldn't afford them). Essentially we treated each 24-port switch as if it was a Foundry blade. Each such switch carried all of our VLANs and it was configured on a port by port basis, just as the Foundries had been. If you wanted to change what network a drop was on, you could either switch it to a free port that was already on that network (if there was one somewhere) or you could reconfigure the switch to change the port's VLAN. Unfortunately this implementation turned out not to work too well. Making switch configuration changes isn't as easy as it looks and we soon got fed up with various problems that came up.

Our third implementation is the one I wrote up in 2011 and which we still use today with various pieces upgraded. We have a collection of core switches (now 10G) that carry all of our networks as separate VLANs, and then we hang single-VLAN switches off ports on the core switches (usually in a tree if we have more than 20 odd connections for a particular network in a machine room or building wiring closet). We change what network a particular drop is on by physically rewiring it to a different switch. The only time a core switch's configuration changes is if we need to add or remove a port for an entire network, which is pretty rare. This approach has worked out better for us than the previous two ones.

(This neat description is not quite complete. There are a few machines that have to be fed multiple VLANs on a single port, such as our internal firewalls, and there's a single breakout switch for our office drops that also carries multiple VLANs.)

I don't feel too bad about us doing the second implementation between the first and the third. At the time we started into it, using modern switches as replacements for Foundry blades seemed the obvious approach and we didn't yet have the experience to understand all of the annoyances and problems we were going to wind up running into. In practice it turned out the scale mattered (changing one Foundry on a regular basis is a lot easier than changing one of a half dozen or more 24-port switches), and quite possibly our Foundry setup was not ideal in the first place.

PS: We have some separate switches that use VLANs for brute force port isolation. They don't complicate this network implementation, partly because they've all got a fixed configuration and never plug directly into our core switches.

PPS: The one obvious way we haven't implemented a multi-network environment is to run each network over a completely separate switch tree and set of links between machine rooms and buildings. At a minimum, this would need far more fiber links than we have available.

sysadmin/OurThreeNetworkImplementations written at 00:20:18; Add Comment

Page tools: See As Normal.
Login: Password:
Atom Syndication: Recent Pages, Recent Comments.

This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.