VLAN's - Planning?

Solution 1:

Usually there's some straight forward obvious division already happening and you use that as a basis for segmenting the network. Sounds more like you want to subnet the network than vlan it though. vlans are usually based on administative requirements, like a management network, SAN, or VoIP, etc. Subnets follow those vlans, but also commonly divide various physical differences (one per building, floor, or other physical construct).

It's really hard to recommend anything specific without knowing anything about your network.

Solution 2:

The way @minarnhere describes is absolutely the way to go but do not just split by functionality, add in factors of security, physical location and number of hosts as well, divide your network into as many VLANs as are required based on all these factors.

Assuming the appropriate switches & routers are in place then there is no cost to having many VLANs and the benefits are huge, if it is planned correctly the admin overhead is minimal as well. Don't limit yourself with artificial constraints about putting all students or tutors or any group of users or hosts into a single VLAN, why would you want to do that anyway? Remember that traffic can only be controlled at layer 3 so split up your network so you can limit and control inter-VLAN traffic, you have no chance with traffic within a VLAN.

The classic way to design a campus LAN is to split the network into Access, Distribution and Core. Many Access layer 2 switches, each carrying traffic from one or more VLANs, will connect to a few layer 3 distribution switches which route the traffic to a small number of layer 3 core switches.

All your hosts must be connected to the Access layer which is split into VLANs based on the factors described above. Each access layer VLAN should, where possible, be limited to one physical switch (this rule only needs to be broken if you have dual homed servers that may need to failover to another switch in the same VLAN). Remember that each VLAN is a broadcast domain and you want to limit the broadcast traffic on each of these as much possible. Consider using only /24 subnets for your access layer, why would you want >250 hosts in a single broadcast domain?

There will be some, a very, very few, circumstances when a VLAN needs to spread over multiple switches but these will be very specialist, switch management maybe one (but that is debatable), there are very few others.

A good starting point would be your servers. If they are in the same physical location (room, not building) then you might want to split them into VLANs based on functionality but otherwise a single VLAN per ~200 hosts will be fine. Obviously (?) Internet facing servers should be on their own, preferably physically separate, network, firewalled from the campus (DMZ design is another speciality in itself, so I'll not get into that here). Your internal servers should also be split into those for the use of students and those for internal admin use only, splitting them into VLANs appropriately. If some servers belong to particular departments (E.g HR) then, if you may need to control the traffic to those servers, consider having a VLAN just for them.

If the servers are spread out then put them into separate VLANs based on location as well as functionality, there is no need for them to be in the same VLAN just 'because they are servers' or just 'because they are all web servers'.

Moving on to your student & staff users. For a start every single port or access point that is, or could be, accessible by non-IT staff should be considered a security risk and all the traffic originating from there should be treated as untrusted. Put your classrooms into VLANs based on possible number of hosts and, depending on the circumstances, user groups but do not make the mistake of 'trusting' particular ports, if tutors need to get to your admin network from a classroom then they should be given the same access method (VPN?) as if they were at home or a public coffee shop.

The wireless network should be on separate VLANs from the wired but with the same contraints, if it can be avoided (but it sometimes can't) don't put all the APs into a campus wide VLAN, split them using the same methodology and for the same reason as the wired.

IP phones should, surprise, surprise, be on separate VLANs from everything else, this is facilitated on some makes (Cisco in my experience) by the phone negotiating with the access switch to put traffic into the appropriate VLAN but this obviously requires the switch to be configured correctly.

There's lots more on LAN design but the above is a start. As a final note, as far as DHCP is concerned, use it for every single host including servers and printers, both of these should have statically assigned IP addresses based on their MAC addresses. The scope (or scopes) for the former should not have spare addresses, this goes some way to preventing casual plugging in of devices to server VLANs but, and this applies to printers as well, the point is that you have central control of the devices and any changes are dealt with centrally rather than relying on engineers wandering about the campus getting addresses right.

Okay, enough for now, I hope that helps a bit.

Solution 3:

As Chris S mentioned, VLANs and subnets are different things. BUT, we just assigned a separate subnet and DHCP scope to every VLAN on our school's campus. Each building has its own VLAN/Subnet/DHCP scope. This makes management much easier, but might not work if you have a larger campus than we do. We also use separate VLANs for Switch Management, Physical servers, VOIP phones, Student Wireless, Classroom Wireless, Student Labs, Virtual Servers, Business Office, SAN, VPN. Basically, we are small enough that any possible differentiation gets its own VLAN. (We're only up to 25 VLANs, and I started making up new divisions just because I wanted to isolate certain groups from the rest of the network...)

Creating separate subnets for every VLAN might be wasteful, but it makes management easier, and allows for easy IP -> VLAN conversions in your head, if you ever need to do that.

We use 10.x.x.x for IPs, so VLAN1 gets 10.1.x.x, VLAN8 gets 10.8.x.x, etc. Every VLAN that needs DHCP gets its own scope, but we don't create scopes for VLANs that don't need them, like Switch Management.