Virtual Local Area Networks (VLANs) are used to provide logical segmentation in a network. Sometimes they are used for security isolation, other times they are used to just break things up so the network don’t get too overwhelming from a management perspective. Many use cases exist.

VLAN capability is a feature of business-class switches, and comes on equipment that claims to be “managed” (unfortunately, sometimes this is the only thing they mean when they use the word “managed”… actually I feel that if the manufacturer has to use the term “managed”, I tend to stay away from it – more on this another time).

In technical terms, VLANs are used to split up the broadcast domain, and all devices on the same VLAN are on the same layer 2 network. This means you need to use some kind of routing to be able to communicate between devices on different VLANs – either a router or a layer-3 switch.

VLANs are locally-significant on a switch. This means every switch that gets deployed needs to have the VLANs defined before they can be used.

When a lot of VLANs and/or a lot of switches are involved, VLAN Trunking Protocol (VTP) can be used to automatically push out VLAN definitions to simplify management.

Note: I will generally use Cisco parlance in this section for simplicity, but I can add other syntax if reader-feedback demands it (that means you!).

Use VLANs! Don’t Be Afraid.

VLANs are a great thing, but I’ve encountered a number of IT managers that either don’t understand how they work or are worried they are too complex for their environment.

A VLAN gets assigned to a specific switchport, and any switchports with the same VLAN assignment will be on the same network. Any ports assigned to different VLANs will not be able to communicate without going through an IP routed boundary – a router, firewall, or layer 3 switch.

On Cisco switches, creating a VLAN is just done using the “vlan XX” command, nothing else is needed.  VLANs are also automatically defined when set as the access VLAN on a switchport, and the CLI should also notify you that this is happening.

One IP Subnet per VLAN

When deploying VLANs, make sure to dedicate a full IP subnet per-VLAN.

This means two things:

1. You won’t be able to use the same IP block everywhere.  Each VLAN needs to have its own IP scheme.  For example, VLAN 10 can be 192.168.10.XX, and VLAN 20 can be 192.168.20.XX; you can’t use 192.168.1.XX on both VLANs and expect them to work together.
2. You shouldn’t use a bunch of different IP subnets on the same VLAN. This is possible to do, but don’t do it.  Just having different IP subnets does not mean they are isolated from each other.

Keep it simple, and use a consistent design as best as you can.

Match the VLAN ID with the IP Subnet

I alluded to this earlier, but it helps to restate.  Since you should use exactly one IP subnet per VLAN, try to find a way to match up your VLAN IDs with some part of the IP address. Usually this works well with the 3rd octet.

This is not a requirement, you can use any arbitrary VLAN ID with any arbitrary IP subnet, but it is good design to keep them similar in some way that fits with the overall design.

This is not always possible, I understand, but do your best.  Make an IP numbering plan for the whole organization, plan VLAN assignment, and any time new VLANs are turned up try to use the new scheme.

Avoid VLAN 1

VLAN ID #1 is reserved for protocols that don’t support VLAN tags, and by default VLAN 1 is used as the “untagged” VLAN on a trunk link. It is best to put normal user traffic in a dedicated VLAN other than #1.

Only Configure One SVI

The Switched Virtual Interface (SVI) is the layer-3 part of a VLAN, used on layer-3 switches. On Cisco switches for example, it is the “interface Vlan XX” configuration setting.

Since the SVI gets an IP address in the VLAN, it can perform actions that a router could do, like route, respond to ARP requests, and operate as a default gateway.

Make sure you only configure SVIs on switches that are intended to perform these functions. It is not appropriate to configure the SVI on all access switches that have the VLAN defined.

Disable VTP By Default

VTP isn’t always needed, especially when only a few switches are deployed. While it may seem like a pain to define VLANs in multiple places, I actually think it’s good to make a network operator intentional about VLAN creation. That said, please use VTP if it makes sense.

Often VTP is left enabled by default, so check the settings on each switch.

• Set all switches to transparent mode (or VTP disabled) in baseline configuration
  • Make sure this is done before connecting a switch to the network for the first time. Here is one of many discussions on this topic.
• Use VTP for switching environments that have 4 or more separately-managed switches (or switch stacks)
• Use VTP if you tend to make a lot of network changes and it will help with workflow

Use VTP Version 3, Set a Domain and Password

VTP version support will depend on switch model and software version, so check compatibility.

Use the highest supported VTP version on all switches, don’t mix versions.

Always set a domain name and password, do not leave the domain NULL!

Set the core switch to Server mode, set all other switches to Client mode

Define All VLANs Everywhere

If you create a VLAN, make sure it is defined everywhere, even if you aren’t planning on using it on every switch. Either create it manually or through VTP, but make sure it is defined on all switches. This avoids troubleshooting issues later.

Example: I was part of a troubleshooting call for a large hospitality organization where this came into play. The technician was onsite for two days and was not able to get two subnets to talk to each other as a final step in a project install. He came to the conclusion that the $15,000 core switch needed to be replaced.  However, I spent about 30 minutes taking him through a bottom-up troubleshooting approach, and it wasn’t long before we discovered one of the intermediate switches failed to have the VLAN defined. Clearly, we didn’t need to replace the switch!

VLAN Pruning can be used to make sure VLAN traffic doesn’t go down tagged links if no access ports exist. This is better than not having the VLAN assigned.

One DHCP Relay per VLAN

Dynamic Host Configuration Protocol (DHCP) Relay is used when you have a central DHCP server not on the same VLAN as hosts needing automatic configuration.

(Here is a section just on DHCP server config also!)

DHCP uses broadcast traffic to discover and request IP addressing and other configuration options from the DHCP server. Since VLANs break up the broadcast domain, a central DHCP server wouldn’t find the DHCP server for address assignment. The DHCP relay, or helper-address, listens for DHCP broadcast messages and then retransmits them as unicast packets to the configured DHCP server on another VLAN.

By understanding how DHCP relay operates, you can see that you only need one relay per VLAN. I have seen this configured as a default config on many switches in the same environment, all with SVIs and DHCP relay, since the network operator just copied the config from one to another. It is easy to do, but please don’t.

Also, be careful when using DHCP relay. DHCP relay actually redirects more than just DHCP messages! Here is a most interesting description on what is forwarded with the “ip helper-address” command.