1500bytes

Appearance

On this page

VLAN Design ​

There are numerous factors to considered when designing your vlan enivonment such as, broadcast networks, security, accessibility, management and high-availability.

Design considerations ​

You shouldn't be lazy when it comes to your VLAN designs, this is a very simple task to perform in the intital configuration of your enviromnent that becomes exponentionally more difficult once the network is in production.

Review the needs of your network, see how many hosts you expect on each network and plan accordingly.

Of course, every enviromnent is unique and has their own needs that you should take into consideration.

Example design - One site ​

Here is a simple example for a medium sized customer as how I'd perform it.

With the example below we're only allocating 1022 addresses to this location while having enough addresses for all systems in that environment, if you'd do this the simple way and just allocate /24 networks for each VLAN we'd be allocating 1524 addresses instead.

This doesn't sound too bad considering the almost 18 million IPv4 addresses within RFC1918 we have to utilize but that's no longer your only consideration when you connect these systems to MSP core networks without fully utilizing NAT.

We'll allocate 10.0.0.0/22 to this customer and segment it down into smaller subnets to save IPv4 addresses and simplify connectivity into MSP environments.

  • 10.0.0.0/24 - Wired staff network
  • 10.0.1.0/24 - Wireless staff network
  • 10.0.2.0/25 - Guest network
  • 10.0.2.128/25 - IOT Network
  • 10.0.3.0/25 - Security system
  • 10.0.3.128/25 - Device management network

This method will provide us with all the neccesary subnets to effectivley contain traffic and minimize broadcast interferance while keeping core functionality.

Example design - Multiple sites ​

Now what if we're allocating VLANs in an MSP environment where we have hundreds of customers which need to connect into our core networks and even utilizing our DCs for their internet breakout?

Again, of course it's theoretically possible to have every customer utilize the same /16 subnet with configurations restricting conflict possibilites, this doesn't work well in practice and makes it difficult to prevent unneccesary outages and conflicts, along with unneccesary complications for IPAM documentation.

One common extreme example of this done wrong is utilizing the network addresses for visible documentation such as this: 10.[SITE ID].[VLAN ID].0/24

In this case, if a customer has 6 sites and 6 VLANs per site to terminate and you give each VLAN a /24 it would be like this:

Site 1

  • VLAN 1 - 10.1.1.0/24
  • VLAN 2 - 10.1.2.0/24
  • VLAN 3 - 10.1.3.0/24
  • VLAN 4 - 10.1.4.0/24
  • VLAN 5 - 10.1.5.0/24
  • VLAN 6 - 10.1.6.0/24

Site 2

  • VLAN 1 - 10.2.1.0/24
  • VLAN 2 - 10.2.2.0/24
  • VLAN 3 - 10.2.3.0/24
  • VLAN 4 - 10.2.4.0/24
  • VLAN 5 - 10.2.5.0/24
  • VLAN 6 - 10.2.6.0/24

So you would have two possible ways of achieving this:

  1. The better way is if you really want this way of subnetting you will allocate the /24 networks as shown above and then route every /24 individually into the core networks, you won't be massively wasting addresses but you'll have overly complicated your routing just to have the networks more visibly pleasing.

  2. If you simplify the routing along with having the visibly pleasing subnetting you've effectively guaranteed issues in the future for your entire infrastructure as you've now allocated entire /16 networks for every site for this one customer...

In summary if you allocate /24 networks with this visibly pleasing method you'll overly complicate your routing for the sake of visibly pleasing network addresses...

If you don't want to complicate your routing while maintaining this visibly pleasing subnetting method you'll have wasted massive amounts of addresses and simply moved your routing issues further down the line to be implemented on your cores to prevent conflicts.

Visibly pleasing /24 subnets - W/ Routing ​

If you decided for the visibly pleasing subnets and decide it's worth it to bite the bullet on the routing part you can expect the following:

  • Access policies for every individual /24 network
    • 6 Sites x 6 VLANs so 36 configuration components
  • Routing policies for every individual /24 network
    • 6 Sites x 6 VLANs so 36 configuration components

6 Sites and 6 VLANs on each site with /24 subnets gives you 9144 allocated IPv4 addresses.

Visibly pleasing /24 subnets - W/O Routing ​

If you want the visibly pleasing subnets but don't want to overly complicate your routing and access policies to the customer in your core networks and rather have core configuration reference all customer subnets in each configuration component...

Following the previous examples of 10.[SITE ID].[VLAN ID].0/24 you'll need to configure each customer location for /16 subnets or even go as far as wasting the entire /8 for the customer which anyone can see is a really really bad idea.