VLAN ID naming schemes

Introduction

Naming schemes are hard. I don’t think anyone would argue with me on that. Whether they’re for domain names, hostnames, usernames, etc, coming up with one that is informative / standalone, intuitive, flexible, consistent, and future-proof within the restrictions of a system is easy to fail at, speaking from experience.

VLAN IDs are particularly tricky because:

1. They’re purely numeric.

2. They’re restricted to 0 – 4095. In practice, this is actually less. For example, Ubiquiti UniFi’s restrictions are 2 – 4009.

3. They’re frequently displayed without context of the subnet that they’re assigned to and represent.

Tip: Throughout my years in IT, one thing I’ve learned is that networks will eventually include subnets that you didn’t account for.

When I was first tasked with setting up a network to support multiple clients’ existing and future subnets after realising the above, I researched publicly-accepted VLAN ID naming schemes but each that I found quickly fell apart for our usage.

So, to demonstrate the suitability of each VLAN ID naming scheme, I will be using the following subnets as examples:

• 10.0.250.0/24

• 172.16.250.0/24

• 192.168.1.0/24

Accepted naming scheme #1: Sequential or random

I don’t think I need to spend long on this one. Obviously, you’d have to use some kind of reference material like a spreadsheet to know what VLAN ID corresponds to what subnet which is far from ideal.

Accepted naming scheme #2: Third octet

The rule of this naming scheme is just to use the third octet (section) of the subnet so let’s see how that works out:

Accepted naming scheme #3: First octet + third octet

So, a workaround around to #2 is to append the third octet to the first octet so let’s see how that works out:

My naming scheme

So, my naming scheme is RFC 1918 “private subnet” designation (10.*.*.*/8 = 1, 172.16.*.*/12 = 2, 192.168.*.*/16 = 3) + third octet so let’s see how that works out:

This one is almost everything I said in my first paragraph: informative / standalone, flexible, consistent, and future-proof.

Almost everything. Like everything in life, there are tradeoffs: You have to know the rule for it to be intuitive and it probably won’t work if you need literally thousands of VLANs in one location. But hey, it’s the least worst option.

I’ve never seen anyone else suggest anything like this before, hence this post.

Update 2020/07/24: Today, I was on a Juniper JNCIA-Junos certification training webinar and I was both surprised and happy to see that they seem to agree!

My subnetting scheme

While we’re on the subject of schemes that are easy to get wrong, I thought I’d share my personal subnetting scheme. I like to use 10.<location>.<network type>.<host>/24 with the third octet starting at 0 and increasing by multiples of 8. For example:

• 10.0.0.0/24

• 10.0.8.0/24

• 10.0.16.0/24

• …

• 10.0.232.0/24

• 10.0.240.0/24

• 10.0.248.0/24

The benefits of this are as follows:

1. It’s scalable and an efficient use of IP space because the third octet being seperated by multiples of 8 means that, if needed, the existing subnets’ prefixes / masks can be expanded into the gaps or new subnets can be inserted.

2. When combined with my preferred VLAN ID naming scheme, the VLAN IDs will be consistent across sites because VLANs are restricted to layer 2 networks. This is great for centrally-managed Wi-Fi / SSIDs, manually tagged devices, etc.

Some examples of network types that I would always try to segment are as follows:

• Systems management such as Out-of-Band Management (OOBM) / Lights-Out Management (LOM), routers, firewalls, jumpboxes, etc.

• Domain Controllers.

• General servers.

• Printers.

• Organisation-owned End User Devices (EUDs) such as desktop PCs, laptop PCs, tablet PCs, smartphones, Remote Desktop Session Host (RDSH) servers, etc.

• Personal-owned and guest devices.

• Payment terminals.

  etc

Below, I have created a diagram as a visualisation of all of this: