Our brute force solution for port isolation without port isolated switches

March 6, 2015

We have a problem: a number of our areas don't have anywhere near the network jack density that people need. Sometimes this is easy to deal with; if everyone in an office just needs one particular sandbox network we can just deploy a dumb switch to add more ports for it. But sometimes people need either multiple networks in one office or, more crucially, more ports on one of our port isolated networks, which we really want to stay that way (even between machines in the same office). And that's the real problem, because we just haven't found any reasonably priced fanless small switches that have good support for port isolation (as well as VLANs; we need both in the same switch).

(Some offices are used by only a single person so it's only sort of dangerous if their infected laptop starts attacking their desktop. But other offices have multiple people, for example grad students, and there we really don't want person A's laptop trying to infect person B's laptop.)

So we've adopted a brute force switch intensive solution to the problem. The 8-port fanless switches we use may not support port isolation but they do fully support VLANs, so we put together what is basically a virtual patch panel system. Each port on an office switch is in a separate VLAN, all of which are forwarded over the uplink port. In the wiring closet, this uplink plugs into another switch that then breaks out each of those VLANs to a separate port again. We then plug each port on the wiring closet forwarding switch into an appropriate port in our regular network infrastructure for whatever network is needed. Effectively the wiring closet switch is a patch panel; it patches through its network ports on a 1 to 1 basis to network ports in office(s).

We initially considered a more complicated and obvious version of this where the wiring closet forwarding switch carried some of our non port isolated VLANs as real VLANs (passed to the office switches) and only did the 1:1 port patch panel thing for the port isolated networks. After trying to plan it out we decided that the potential moderate improvement in port density on the forwarding switch simply wasn't worth the extra complexity, including in keeping track of what ports were on what VLAN(s), what exact configuration a replacement 8-port switch would need for any particular office, and so on. Pure port forwarding has the great virtue of being completely generic.

(Doing actual VLANs on the office switches and the port forwarding switch might slightly improve overall network bandwidth if office machines talk to each other on non port isolated networks. In practice this is not the usage pattern on most of our networks; if there are office machines, they're usually talking to servers that are located elsewhere.)

We could have used more 8-port switches as the wiring closet switches, but for various reasons we wound up deciding to use 24-port ones instead (partly because our 24-port switches are designed to be rack mounted while the little 8-port ones generally aren't). A 24-port switch neatly supports three 8-port office switches with no wasted ports, but it does mean we have three varieties of 8-port office switches (one for which set of seven per-port VLANs it uses). In practice this is not a problem; we label the 8-port switches based on whether they are set up for A ports, B ports, or C ports. Then you just make sure you always connect an A port switch to the A port uplink on the 24-port switch.

(And if you get it wrong you find out right away because nothing works since the VLAN numbers don't match up. The 24-port switch is sending the 8-port switch traffic for (eg) VLANs 1 through 7, while the 8-port switch expects and is sending traffic for VLANs 15 through 21. Both sides drop each other's unexpected VLANs and nothing gets through.)


Comments on this page:

If the smart switches were running Cumulus Linux, you could get away with 1 config for all the office switches.

Since we just hardware accelerate the normal Linux bridge, there is no need for VLAN #s to be global. You can create a bridge that has swp1.100 and swp2.101 and it'll just work. We do exactly this in our test lab, using breakout switches essentially as software-controlled patch panels.

BTW, are you using the Netgear GS108E as for the office switches?

- nolan

By cks at 2015-03-09 12:50:51:

Our current 8-port switches for this are HP 1810-1G switches. This is subject to periodic change; I think we've gone through at least three variants of 8-port switches as the companies involved changed them and their prices.

Being able to cross-connect VLANs like that sounds like a useful trick. Hopefully more inexpensive switches will gain flexible software in the future.

Written on 06 March 2015.
« The simple way CPython does constant folding
Why ZFS's 'directory must be empty' mount restriction is sensible »

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

Last modified: Fri Mar 6 23:51:34 2015
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.