Setting up switches to avoid unwanted VLAN leakage

December 6, 2006

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.

Written on 06 December 2006.
« A small annoyance with Unix wildcards
How not to set up your DNS (part 13) »

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

Last modified: Wed Dec 6 22:45:50 2006
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.