Subnetting and VLANs for Multiple Buildings Strategy

networkingsubnetvlan

Curious for a little feedback on how others do this.

A site I'm looking at has multiple buildings connected by fiber and each is on their own subnet.

192.168.0.0 - Building 1 - VLAN10
192.168.1.0 - Building 2 - VLAN20
192.168.2.0 - Building 3 - VLAN30

etc

(for the record I understand the undesired implications of being on a 192.168 subnet)

Each building is running its own small datacenter with DHCP servers and domain controllers.

My big issue is I think its very confusing to have servers at 

192.168.0.1 - building 1
192.168.0.5 - building 1
192.168.1.11 - building 2
192.168.2.5 - building 3
etc.

Obviously I could say put all networking gear at 192.168.0.0 subnet and all servers at 192.168.1.0, DHCP at 192.168.3.0, but this would create crossover vlans.

For example I would probably still want a DHCP server in VLAN20 with all the computers in that building, and likewise a DHCP server in VLAN10 with those computers in that building.

By tradition VLANs are kept 1 to 1 with their subnet.

How do others manage this?
Do you just know like 192.168.0.1-.50 is reserved for server gear?

I came from a 10.1.0.0/21 network so we had enough addresses to keep everything separated and didn't vlan it at all.

Best Answer

This is a very difficult question to answer on a scenario-basis because there are many factors to consider with little information provided. However, in a general sense, here is my insight.

Firstly, I agree with the comments against the question that no private address group is any more or less desirable than another based on susceptibility to being similar to a home users. From my experience, no matter how much you try and avoid conflicts with VPN users, if it doesn't occur for user 'A', eventually there will be some user 'B' for which it does.

One critical thing that you haven't mentioned in the question, is the volume of devices, and the expected growth over the lifetime of the infrastructure. I will keep points general, due to the open scope and ambiguity.

If you are determined to split your network into subnets per building, firstly identify the number of buildings that are needed, and then consider the probability that this will be sufficient for a longer term (5-10 years). Try to arrive at a quantity of networks that is not excessive but realistic. I would typically be liberal and allow marginal overhead. Use this to define the narrowest range practical for higher level subnets.

For example, if you have 3 buildings, but anticipated this could grow to 5 over 10 years, pick a base two multiple which is sensible for this, and split the first usable octet with this prefix. Eg. of 172.16.x.x with up to 8 networks:

000 | x xxxx . xxxx xxxx - Common Equiptment. 192.168.0.0 /19
001 | x xxxx . xxxx xxxx - Building 1. 172.16.32.0 /19
010 | x xxxx . xxxx xxxx - Building 2. 172.16.64.0 /19
011 | x xxxx . xxxx xxxx - Building 3. 172.16.96.0 /19
100 | x xxxx . xxxx xxxx - Building 4. 172.16.128.0 /19

This will maximise your address scope, and allow for further subnetting. It also simplifies defining routes if all subnets within any .19 scope are via the same node for the majority of the remaining network. Note that this balance should work two ways. Lets say for example that you have a small number of buildings in addition to your primary buildings, like remote offices, which don't need many addresses, but simply need to be connected - you could allocate these a single building 'parent' subnet, and divide it up to service them. Your goal is ultimately to keep the largest address space where it is likely to be needed most.

From here you may find that you split your network further, into application specific allotments. You might do something like the following:

Building 1 (from above).

001 | 0 0 | xxx . xxxx xxxx - Building 1's Default Network. 172.16.32.0 /21
001 | 0 1 | xxx . xxxx xxxx - Building 1's Misc Networks. 172.16.40.0 /21
001 | 1 0 | xxx . xxxx xxxx - Building 1's Phone Network. 172.16.48.0 /21

We could take this further and have:

001 | 0 1 | xxx . xxxx xxxx - Building 1's Misc Networks. 172.16.40.0 /21
001 | 0 1 | 001 . xxxx xxxx - Management Network. 172.16.41.0 /24
001 | 0 1 | 010 . xxxx xxxx - Security Camera Network. 172.16.42.0 /24
001 | 0 1 | 011 . xxxx xxxx - Alarm System Network. 172.16.43.0 /24

I feel the important thing to take away, is to find a solution that works for your scenario. You will probably want to:

  • Maximise the room for growth, in where it is most likely to occur. At a guess, I would assume it would be your end users network.
  • Maintain consistent patterns where possible, so ACLs and firewall rules can be simplified. Eg, if you know in the 3rd octet that the 4th and 5th bits with pattern '01' will always denote the 'misc networks', you could have one bitmask to capture all buildings in a single rule.
  • Rather than focusing on whether or not an address space could conflict with a users home network, try and focus your design on how they will use it. For example; if it is a point to point VPN, with no translation nor overloading, with additional routed traffic passing through, it may be important to maintain compatible address scopes. For most home users, the collision will not matter though, because they will connect from their end device, and their device will treat their connection as the gateway for all traffic. Any deviation from this could be against your usage policy and out of scope for you to support.
  • Networks of the same subnet, do not need to be on the same VLAN... but they probably should be. The VLAN ID is exactly that; just a number. It doesn't need to be the same across connected devices if they don't exchange it, but I can't think of any scenarios where it would be of benefit to have an inconsistent VLAN ID structure. To join two different VLANs together of the same network, you would use a bridge (switch). Essentially you will have split a switch into multiple sub switches, and inefficiently joined them in a way which is hard to maintain.
  • Minimise un-necessary routing. Whilst having all these networks can be nice and logical, if a high volume of traffic passes from network A to network B through a router, it isn't enough to just assume the router is capable of supporting it on the premise that its port speeds are adequate. For example, the Cisco 1941 dual gigabit Ethernet router, although having dual gigabit ports only has a speculated throughput of 153Mbps between networks. (Throughput Specs)
  • Don't have not enough networks (...in spirit of being contradictory). If you didn't use subnets to divide your network, a broadcast would reach all devices. If you find that certain groups of devices don't need to directly communicate often, this is a good indication that they should be separated.
  • Embrace horizontal scalability, both within and across networks. Rather than having one big server servicing all your users; have a smaller server for each network to service just its clients. They could share a common data source and this would also take the burden off of your router. There are many ways to achieve horizontal scaling though.

I hope this helps or gives you some ideas :)

Related Topic