An example of the evolution of a real network

June 13, 2011

Our network as it is today has a little oddity in how it is implemented. There is a set of separate switches for one particular private sandbox network, which is odd enough considering our normal network implementation transports all sandboxes over a set of backbone switches. Even more oddly, these switches are not generic dumb switches, because they transport the sandbox between themselves as a tagged VLAN (and detag it to edge ports). All of our printers are connected to this sandbox and to this single-subnet switch network.

To understand this oddity, we need to walk back in history.

The switches are all VLAN-aware and the inter-switch links are tagged because this set of switches used to transport several different networks, not just one. In fact, it used to transport several of our public networks, which, yes, our printers were connected to.

Our printers used to be connected to our public networks because back in the old days, we did not have and use private subnets; all of our IP address space was public and everything went on it, printers included. The printers stayed on our public networks when we migrated other things off because renumbering printers is a huge pain in the rear (and we've had mysterious problems with it in the past).

Well, fine. But why did the printers have a completely separate network of switches, instead of just having their traffic transported over our core backbone switches?

The answer is: because those public subnets weren't (and aren't) carried on our core backbone switches. And in turn, this is because how they were configured on our previous generation of switches. On our previous generation, our big three public subnets were bundled together into what the old switches called a 'protocol based VLAN'; the switches could peer into the packets to pull out the subnet address and treat it as basically a sub-VLAN. This let us configure most ports as 'VLAN BLUE, but only subnet 128.100.X' and some ports as 'VLAN BLUE, all subnets'.

Our current-generation switches do not support this sort of VLAN. For various reasons we decided that they should carry only one of the three subnets in the old BLUE VLAN, the one we were moving all of our servers to (and that did not have any printers, at least once we did a bit of work). This meant that the printers needed their own network infrastructure to get the other old public subnets to them.

So there you have it. An odd and otherwise inexplicable bit of our network infrastructure is the way it is because of decisions that were probably made ten years ago and a completely logical series of decisions made since then.

Sidebar: one reason to carry only one subnet in the new world

My memory of this has been blurred by the passage of time (and by being only peripherally involved in this set of decisions), but as I remember it one reason that we did not want to carry all three subnets on our new backbone switches is that it would have required inventing new VLAN numbers for at least two of the three subnets. This would have led to a confusing situation where subnets were in different VLANs (with different VLAN numbers) depending on which bit of network gear you were looking at.

Written on 13 June 2011.
« Noting some wandering thoughts on the occasion of an anniversary
A package dependency failure in Fedora 15 »

Page tools: View Source, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Mon Jun 13 00:19:53 2011
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.