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 they’re purely numeric, they’re restricted to 0 – 4095 (in practice, this is actually less - for example, Ubiquiti UniFi’s restrictions are 2 – 4009), and they’re frequently displayed without context of the subnet that they’re assigned to and represent.
As part of my job, for various reasons that I won’t go into, I have to setup networks that need to have many diverse subnets that we have no real say in and will probably need to have more in the future (tip: always assume that your network will eventually include diverse subnets that you didn’t account for if, for example, your company buys another and needs to integrate the systems). So, when I was originally setting up these networks, 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:
Side note: My personal favourite subnetting scheme is 10.<location>.<network type>.<host> with network types being systems management (OOBM, network equipment, jumpboxes, etc), Domain Controllers, End User Devices (EUDs), guests, payment terminals, etc.
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:
|10.0.250.0/24||250||Fail: Collision with 172.16.250.0/24.|
|172.16.250.0/24||250||Fail: Collision with 10.0.250.0/24.|
|192.168.1.0/24||1||Fail: VLAN ID 1 is reserved as the default.|
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:
|10.0.250.0/24||10250||Fail: Too long.|
|172.16.250.0/24||172250||Fail: Too long.|
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. Plus, when combined with my preferred subnetting scheme, because VLANs are restricted to layer 2 networks the VLAN IDs will be consistent across sites which is great for centrally-managed Wi-Fi / SSIDs, etc.
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.
Anyway, I’ve never seen anyone else suggest anything like this before so I’m just putting this out there hoping that it’ll help someone someday.