5

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.

4
  • Are you required to maintain strictly-separated networks for these different device classes, e.g., should a student iPad not be able to see a staff MacBook at all?
    – Handyman5
    Jun 9, 2011 at 0:10
  • My understanding is that they can still see each other, but will not share broadcasts (since they're on separate VLANs). We also apply a different security policy (e.g. iPads can SMTP, others cannot) based on these groups. Jun 9, 2011 at 2:27
  • I think the question right now is why was this design proposed in the first place. And whether or not this condition still exists. Without that context, to be honest, I'd question the sanity of a colleague or vendor who suggested doing this on 'my' network.
    – Rob Moir
    Jun 9, 2011 at 5:27
  • My understanding is that there were three primary reasons. One was as a way to work around iPads' apparent difficulty changing VLANs (if they're in an access control list, their VLAN doesn't need to change). Another is as a way of applying security policy (e.g. only the iPad VLAN can use SMTP). The last was the potential ability to get aggregate device usage metrics based on those VLANs' subnets (so we could say, "Subnet a.b.c.d/z had x statistics, and it only has iPads, so those are the iPad statistics."). Jun 9, 2011 at 6:25

3 Answers 3

13

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.

2
  • Thanks for your insight. Regarding people "sitting next to each other": I'm just looking at the way things like Bonjour (iPhone <-> Mac) aren't working well with the devices on separate VLANs and substantial new features like AirDrop and wireless iPad/iPhone syncs coming soon with OS X Lion... I'm worried we're almost ruling those out by guaranteeing the devices be on separate VLANs. Jun 9, 2011 at 2:23
  • In a setup like the one you describe, when a device moves from one building to another, what happens? The device would then need to renew its DHCP lease on the new subnet, right? What does the user see on his end? A momentary disconnection? I'd Google this myself, but I'm having trouble thinking of a good search phrase. Jun 9, 2011 at 17:40
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?

1
  • I agree. I feel like that would be the most intuitive for end-users. Thanks for your comment. Jun 9, 2011 at 2:47
1

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .