Home / server / Questions / 278523
Accepted
Moduspwnens
Asked: 2011-06-09 16:00:12 +0800 CST

Campus VLAN Segmentation - By OS?

  • 772

We've been thinking through re-arranging our network and VLAN configuration. Here's the situation.

We already have our servers, VoIP phones, and printers on their own VLANs, but our problem lies with end user devices. There are just too many to lump on the same VLAN without being hammered with broadcasts! Our current segmentation strategy has them split into VLANs like this:

  • Student iPads
  • Staff iPads
  • Student Macbooks
  • Staff Macbooks
  • Gaming devices
  • Staff (Other)
  • Student (Other)

**Note that our network has many more iPads and MacBooks than most.*

Since the primary reason we're splitting them is just to put them in smaller groups, this has been working for us (for the most part). However, this required our staff to maintain access control lists (MAC addresses) of all devices belonging in these groups. It also has the unfortunate side effect of illogically grouping broadcast traffic. For example, using this setup, students on opposite ends of campus using iPads will share broadcasts, but two devices belonging to the same user (in the same room) will likely be on completely separate VLANs.

I feel like there must be a better way of doing this.

I've done a lot of research and I'm having trouble finding instances of this kind of segmentation being recommended. The feedback on the most relevant SO question seems to point toward VLAN segmentation by building/physical location. I feel like that makes sense because logically, at least among miscellaneous end users, broadcasts will typically be intended for nearby devices.

  • Are there other campuses/large-scale networks out there segmenting VLANs based on end-system OS?
  • Is this a typical configuration?
  • Would VLAN segmentation based on physical location (or some other criteria) be more effective?

EDIT: I've been told that we will soon be able to dynamically determine device OS without maintaining access lists, although I'm not sure how much that affects the answers to the questions.

networking vlan

3 Answers

  1. Best Answer

    I think segmenting user subnets by OS is more work than it's worth, and quite honestly in all my interactions with HiEd IT people, I've never heard anyone talk about segmenting by OS. What benefit would you get by doing that? Additionally, what do you do when the operating system of a certain machine changes or perhaps a more common situation would be what to do with a computer that dual-boots say OSX and Windows?

    We have around six different security "zones" on campus:

    1. General (non-privileged) faculty/staff office ethernet drops
    2. Privileged staff office ethernet drops (mostly ITS staff)
    3. Guest Wifi (only has internet access)
    4. ResNet (dorm networking)
    5. Secure Wifi (WPA2/802.1x, users get put into a specific VLAN depending on role)
    6. Server rooms

    Each of the above are divided into smaller subnets, usually by building and then by which wiring closet they connect to. For wireless, we have several subnets that non-privileged users get assigned to at random. For the server rooms, we do group by OS (mostly for security separation between Windows and Linux), as well as further sub-dividing within OS groups for ITS servers versus Department-owned servers. We maintain subnet ACLs for each subnet with a default deny policy, only allowing traffic through that we explicitly allow. In addition to the subnet firewalls, we implement host firewalls on all of our servers, whether Linux or Windows. There are also several special-purpose VLANs kicking around for things like server management, network management, iSCSI, HVAC equipment, door access panels, security cameras, etc.

    Your goal of keeping broadcast domains small is a good goal to have. Honestly, though, it doesn't really matter if two people sitting next to each other are in the same L2 broadcast domain.

    • 13

  2. Seems like A LOT of work for the IT department to have to organize and keep track of the MAC addresses and devices they are associated with.

    The biggest side effect that I thought of was the "two devices belonging to the same user (in the same room) will likely be on completely separate VLANs." You'll have a lot of folks calling IT support wondering why they can't see each others devices in iTunes. :)

    I still think the best solution is segmenting by building, then by official campus devices, and finally student devices. This way you can make sure that all devices can talk to each other that need to talk to each other while mitigating students from hacking official campus devices.

    What do you think?

    • 2

  3. I agree with what ErikA said: break VLANs up into functional groups:

    • SERVER1, SERVER2, SERVER3, etc. (say, all under 10.2.0.0/16: Windows in 10.2.0.0/17, Unix in 10.2.128/16)
    • DMZ1, DMZ2, etc. (all under 10.3.0.0/16)
    • WIRELESS1, WIRELESS2, (all under 10.4/16)
    • GUEST1, GUEST2, (10.5/16)
    • UNDERGRAD1, UNDERGRAD2, (10.6/16)
    • GRADS1, GRADS2, (10.7)
    • FACULTY, (10.8)
    • PRINTERS (10.9)
    • NETWORKING (10.10.x.y)

    Sometimes particular research groups may get their own VLANs as well. Similarly you may have 'private' VLANs that are not routable to the rest of the network for things like storage (NFS, iSCSI); they often had Jumbo Frames enabled as well, whereas everywhere else had the default MTU of 1500.

    If want to give the network users some flexibility, you can use something called "dynamic VLANs": this is where when a machine is plugged in, the switch takes its MAC address and queries a RADIUS server, and it tells which VLAN to make the port. Check out the RADIUS attributes of "Tunnel Type", "Tunnel Medium Type", and "Tunnel Private Group ID". Similarly for WiFi, when a user logins in via WPA2, and the AP talks to the RADIUS server, in addition to the allow/deny response for the username and password, the RADIUS server can respond back with the VLAN that the AP should put the user in.

    Unregistered host MACs and users can either be denied any access (a blocked port), or put into a default (guest) VLAN, depending on your security policy. HP switches (and others?) are also able to do two-level stuff: by default MAC-level access is given, but if the user runs an 802.1x program and authenticates themselves (as opposed to just the host "authenticating" itself--with anyone actually at the keyboard), the switch can then the port to a VLAN tied to the individual.

    Also, tying the functional VLANs with subnet ranges help to make firewall rules easier in many cases, as well as debugging where strange packets are coming from (Windows hosts are statistically more like to be attacked/compromised, so putting those servers in any easy to segment network may be worth considering).

    When you provision users/devices for access into to WiFi (Macbooks, iPads, iPods), you'd rotate the subnets/VLANs that they'd be placed in: studentA would be place in WIRELESS1/10.4.1.0, studentB in WIRELESS2/10.4.2.0, studentC back in WIRELESS1/10.4.1.0, etc. Add more subnets/VLANS as needed to "load balance" the user load. Similarly for facultyA, facultyB, facultyC. If you notice an imbalance in distribution because of graduation/dropouts/staff-churn you can always rebalance with a simple script that updates the database (SQL, LDAP, whatever).

    You can certainly also do it by building, but within each building you'll have functional separation as well: BLDA_SERVER_HR, BLDA_SERVER_FINANCE, BLDA_WIFI_STAFF, BLDA_WIFI_GUEST, BLDA_PRINTERS, BLDB_WIFI_GUEST, BLDB_PRINTERS, etc.

    • 1