2006-12-06
Setting up switches to avoid unwanted VLAN leakage
We made a small mistake around here a while back: we used VLAN ID 1 for a real VLAN. In fact, we used it for our 'management network' VLAN.
This is a mistake because many switches insist that all ports be untagged members of some VLAN, and they pick VLAN 1 to be the default VLAN for this. The net effect is that unconfigured ports on many of our VLAN-aware switches are by default on our management network.
(Not all of our switches are VLAN aware; edge switches tend to handle only a single VLAN, all untagged. And not all of the VLAN-aware switches get fed the management VLAN from their upstream.)
What I'd like is that unconfigured ports would be dead. It would be easy for switches to allow this in a natural way: just turn off ports that are not members of any VLAN (untagged or tagged). (This doesn't require any new core functionality, since good switches can already disable ports through a direct interface.)
Short of this, we want to make sure that nothing leaks to or from unconfigured ports. We do this by creating a new do-nothing VLAN, by convention VLAN ID 4094, and switching all ports to be untagged members of it when we set up a new switch.
But this still leaves us with a little gotcha: all ports have to be untagged members of some VLAN, including the switch's uplink port, which will normally see only tagged traffic. Now we have a problem:
- we can't make the uplink port an untagged member of a real VLAN or various undesirable things start happening, ranging from packet duplication and echoing to having to having to remember that one VLAN is special because it is uplinked and downlinked untagged instead of tagged.
- we can't leave the uplink port as a member of the new default VLAN, because that would allow traffic from inactive, unconfigured ports to leak off the switch.
The solution is to make the uplink port an untagged member of a second do-nothing VLAN, by convention VLAN 4093. With no other port in that VLAN, the uplink port should never send any untagged traffic.
(It may receive untagged traffic, depending on how the upstream switch is configured.)
People who are less lazy and more thorough than I am can take this to the next level: make a new do-nothing VLAN for each port (perhaps numbering from 4000 on up, so you can easily keep them straight). This creates complete isolation for unconfigured ports.
(I might do this if our Allied Telesyn switches could be configured
through some scriptable command-line tool. Slogging through the tedium
of their serial console menu interface or their web server thingy to do
this much work is, however, beyond me. In theory I could use expect or
the like to create my own command-line tool, but that would be a lot of
work, necessarily be somewhat fragile, and likely run like warmed-over
maple syrup (while being a lot less appetizing).)
Sidebar: so why not explicitly disable unconfigured ports?
The simple answer is that it's too much make-work, because it means you have to touch two relatively widely separated areas of the switch's menu interface to turn up a port: you have to set its VLAN membership right, and then you have to remember to run off to a completely separate menu to actually turn it on. Forgetting to do one or the other will result in somewhat mysterious failures and a certain amount of annoyance.
(There's lots of reasons why a port might not come up when you plug something into it, such as a bad cable or something wonky on whatever you're using to test with.)
Since things only get plugged into unconfigured ports by accident anyways, I don't care that much and I'd rather avoid potential teeth-grinding mysteries.