About VLANs

VLANs are central in directing traffic to your resources. You might never need to interact directly with any VLANs because they are managed automatically; they are assigned as needed and removed when not.

A VLAN is a network concept. VLANs allow you to create broadcast domains at the OSI Model layer 2 level, the data link layer. VLANs provide one method of packet identification, and they allow multiple workloads to coexist on the same physical equipment. For more information about VLANs, see this article.

Types of VLANs

IBM Cloud® refers to the two distinct types of VLANs as Automatic and Premium. They each play a different role, and depending on your needs, understanding their differences is important.

Automatic VLANs

Automatic VLANs are managed by IBM Cloud automatically. They're assigned and removed as needed to fulfill the needs of other products that you order. You typically have one automatic VLAN per router. Automatic VLANs are associated to servers ordered without a specific VLAN selected. It's not possible to order or cancel automatic VLANs because they exist on your account only when our systems determine that they are required. They're removed when our systems determine that they are no longer needed.

Premium VLANs

Premium VLANs are acquired by ordering a VLAN. See Ordering VLANs for instructions. You can order as many premium VLANs as you like, subject to capacity limitations. If capacity is unavailable, seek VLANs in another pod or data center.

An important distinction of Premium VLANs is that they're not selected automatically to fulfill a server order. Premium VLANs must be explicitly selected while you are ordering servers to have servers reside on them. See the FAQs for instructions on VLAN selection.

Premium VLANs which are not in use may be subject to automatic reclaim.

Premium VLANs which are not participating in Layer 2 or Layer 3 networks for 90 days or more are subject to automatic cancellation of billing and reclaim of the VLAN in order to maintain sufficient VLAN capacity for all customers. Any secondary subnets present on the VLAN will be unrouted as part of VLAN reclaim. For more information regarding the automatic reclaim policy of unrouted secondary subnets, see the Subnets FAQs.

VLAN identification

VLANs exist on routers within IBM Cloud data centers. Each VLAN is identified by a unique fully qualified name. For example, the fully qualified name dal10.fcr03.1431 is identified by the VLAN number 1431, on router fcr03, and within data center dal10 (Dallas 10).

VLANs and subnets

VLANs can contain one or more subnets. Like VLANs, some subnets are automatically added and removed as devices require IP addresses. The different types of subnets and how they operate is further detailed in Subnets and IPs.

Communication within a VLAN

All resources on a VLAN can communicate, but that does not mean they will by default. Remember that VLANs are an OSI Model layer 2 construct, and that subnet/IPs are a layer 3 construct. Communication happens differently at each layer. Resources in different VLANs, whether on the public or private network, cannot communicate with one another via layer 2 methods.

Communication within a VLAN on the public network

Communication between resources on the public network is not inherently restricted, whether on one or more VLANs within IBM Cloud's public network infrastructure or the internet. Restrictions can be added by introducing a firewall or gateway appliance.

Communication within a VLAN on the private network

By default, only compute within the same subnet can communicate, even if multiple subnets are in the same VLAN. However, it is possible to communicate with other subnets on the same VLAN, provided that the compute instances have route entries for the additional subnets on that VLAN. Managing route entries on all compute nodes that need to communicate across private subnets can be cumbersome. See VLAN spanning for how to handle situations where default communication is required among all compute within the same VLAN. Review VLAN spanning carefully before enabling, because it has broad implications.