I was looking into VLANs recently and noticed that in several tutorials, VLAN tags with large numeric gaps were chosen, like 10, 20, 30, etc. Is there a reason why one wouldn't simply enumerate it like 1, 2, 3, 4, ...?
Thank you.
-
3There is no "best practice." Use whatever system makes sense to you. I'm voting to close because any answers will just be someone's personal opinion.– Ron TrunkSep 14, 2021 at 14:51
-
1Round values are more memorable. Some numbers are reserved eg 0,4095, VLAN1 is the default VLAN in Cisco systems I believe. It can be used though but can't be deleted. So I would avoid using VLAN1. The list of reserved numbers may vary depending on vendor and hardware OS - check the docs.– KateSep 14, 2021 at 17:24
-
2@Anonymous That’s not the reason why it’s a best practice to avoid VLAN 1, so you know. It’s because VLAN 1 is not part of the VLAN database, and the VLAN database is one of the last things loaded upon boot, so when a switch is first booting, there is a brief moment where all ports are on VLAN 1 instead of their correct VLAN, causing a security risk where you can capture packets for a VLAN you’re not supposed to be on.– Jesse P.Sep 14, 2021 at 17:55
Add a comment
|
2 Answers
It does not matter, but leaving gaps between enumerated things, e.g. ACL lines, is a good practice, and people often carry that over to other things.
You may want to leave room to add logically related VLANs to be in the same range of 10 to 19. For example, if you have department VLAN numbering, and a department that uses VLAN 10 for its data wants to add a VoIP VLAN, then you can make that VLAN 11.
answered Sep 14, 2021 at 14:52
Not really an official best practice, and I know this is primarily opinion (which is frowned upon here) but, like Ron said already, leaving space between VLAN IDs allows for better grouping of similar types of devices and such.
Additionally, matching the VLAN IDs to the third octet of an IPv4 network makes it easy to keep track of which VLAN is associated with which network.
For example:
VLAN 10: 10.10.10.0/24 VLAN 11: 10.10.11.0/24 VLAN 12: 10.10.12.0/24
The reason I prefer doing this on the third octet is mainly due to route summarization. If the VLAN IDs were matched networks on the second octet, for example, you’d have to include each network separately in route advertisements or static routes.
Take this example: With 10.10.10.0/24, 10.10.11.0/24, and 10.10.12.0/24, assuming that all networks (present and future) with 10.10.x.x will reside at the same physical location, I can summarize my route advertisement as 10.10.0.0/16 and any new networks I may create within the environment will automatically be included in the summary route.
If I used the second octet instead, there is no clean way to summarize the routes.
Take this example: With 10.10.0.0/24, 10.11.0.0/24, and 10.12.0.0/24, you would have to advertise them as 10.10.0.0/15 and then 10.12.0.0/24, or figure out how large you want to go, and then also figure out what you would do for other locations without overlap or using a completely different scheme. It gets really messy.