VLANs

Note: This guide is related to using Cisco equipment. For basic introductory details about using Cisco, see: Cisco Introduction, Cisco equipment, and Cisco basic usage guide.

For an introduction to VLANs, see: VLANs.

How to start using VLANs
Creating a VLAN

Usually, the easiest way to make a VLAN is to just assign an interface to use the VLAN. That will create a VLAN as needed.

However, creating VLANs can also be done manually, without assigning an interface to the VLAN. To do that:

deviceName>enable
deviceName#config terminal
deviceName(config)#vlan vlan_number

e.g.:

deviceName>enable
deviceName#config terminal
deviceName(config)#vlan 2

There, that was easy, wasn't it?

The above command will have created the VLAN. It also will have placed the router in a different mode, ready to interact with that VLAN. The prompt demonstrates this, by looking different:

deviceName(vlan)#

There are some other things to know. Cisco recommends naming VLANs: Cisco Network Academy CCNA course “Discovery 3” slide “3.3.2.1” states, “Naming a VLAN is considered a network management best practice.”

deviceName(config-vlan)#name VLANname
deviceName(config-if)#exit
  • Note: This documentation looks slightly incosistent... Is the prompt “(vlan)” or “(config-vlan)”?

It can be nice to know how to undo what has been done, including creation. To destroy a VLAN:

deviceName(config)#no vlan 2

Note that this does not adjust the interface configurations. So if an interface was assigned to use the VLAN, the interface will still be configured to do so. However, if the device is not using the VLAN, this means that the interface will not be successful in communicating with the VLAN. This essentially just ends up meaning that the traffic is lost.

Assigning IP addresses

Although a router typically has an IP address assigned to a network interface, Cisco switches may (typically/usually/always?) have the IP address assigned to a VLAN. Use commands to assign an IP address and subnet mask to a VLAN, and to tell the VLAN to not be administratively down, similar to how it would be done on a router's network port.

(For some official documentation on this subject, Cisco 3560-X IOS 12.2: Manually Assigning IP Information shows setting a IPv4 address.)

It is believed that the VLAN may need to exist first. (See the prior section about creating a VLAN.)

deviceName(config)#int vlan 2
deviceName(config-vlan)#ip address 192.0.2.1
deviceName(config-if)#no shutdown
deviceName(config-if)#exit
deviceName(config)#

It may also be useful to add the minimum common routing information: a default gateway. (This doesn't affect typical network traffic that just happens to be going through the switch. Rather, the reason to add a default gateway is just to allow the switch to communicate to other subnets when the switch itself has something to communicate, which may happen when the switch is being remotely managed. The switch will be able to communicate to other subnets by knowing the IP address of the router to send traffic to.)

deviceName(config)#ip default gateway 192.0.2.1

... or ...

deviceName(config)#ip default-gateway 192.0.2.1

(The difference between those examples is the hyphenated “default-gateway” rather than the multi-word unhyphenated “default gateway”.)

The earlier syntax was documented by Cisco Network Academy CCNA “Discovery 3” slide 2.3.5.3, while the later was what was shown by the help built into IOS.)

Assigning NICs

Also, there is a need to “associate” network port(s) to the VLAN. That causes traffic on the network port(s) to be able to use that VLAN, so this task is needed in order to make the VLAN start to be useful. (Otherwise, assigning the IP address to a VLAN doesn't do much good if no physical network interface ports use that VLAN.) To see what network port(s) are assigned to existing VLANs:

deviceName(config-if)#end
deviceName#show vlan brief

On a switch using a fresh, default configuration, it will quickly become apparent that network ports default to VLAN 1. The name given to VLAN one is “default”. Cisco documentation may often refer to this as the “management” VLAN. (This is a bit confusing, because the VLAN's name does not default to “management”. If in doubt, when Cisco refers to the “management”, the authors are probably referring to VLAN 1.)

Other default VLANs may pre-exist starting with VLAN 1002. So, VLANs 2 through 1001 may be available, by default.

To add a single switch port to an already-existing VLAN:

deviceName#config terminal
deviceName(config)#interface fa#/#
deviceName(config-if)#switchport access vlan vlanNumber
deviceName(config-if)#exit

The “fa#/#” is intended to be customized, and might look something like “fa0/1” or “gi 0/1”. The precise name to use will vary based on what equipment is being used. This is handled the same as a router, and so is discussed in detail in the Cisco IOS basic usage guide.

deviceName#config terminal
deviceName(config)#interface fa0/1
deviceName(config-if)#switchport access vlan 2
deviceName(config-if)#exit

For a 48-port switch, assigning all of the ports to a common VLAN may be a rather reptitive task if each port is done individually, one at a time. Fortunately, there is a faster way: perform operations on multiple ports at the same time. The following example shows setting four ports (fa0/1 and fa0/2 and fa0/3 and fa0/4) to a VLAN.

deviceName#config terminal
deviceName(config)#interface range fa0/1 - fa0/4
deviceName(config-if)#switchport access 2
deviceName(config-if)#exit

Instead of a hyphen, online help does show a comma as being another option. That is probably a way to apply configuration to multiple interfaces, including mlutiple ranges of interfaces, when the interface names are not completely sequential.

Naturally, an interface can be disassociated from a VLAN by removing the configuration line that put the interface in the VLAN.

deviceName#config terminal
deviceName(config)#interface fa0/1
deviceName(config-if)#no switchport access 2
deviceName(config-if)#exit

According to Cisco Network Academy CCNA course “Discovery 3” slide “3.3.2.4”, this returns the port to VLAN 1.

The vlan.dat file

There's one more key point that people should learn about early into their experience of using VLANs on Cisco IOS devices. The VLANs are stored in a file named vlan.dat

With a router, a really incorrect configuration can often be reversed by using a command like reload, which may effectively copy a saved-config file over the running-config settings. A similar concept will often work with switches. However, that process doesn't overwrite all of the settings once VLANs are used.

After a device reloads, things might still be rather messed up as a result of prior configuration commands. The reason for this is because of the vlan.dat file may still contain some settings that are related to the undesired behavior.

The simple solution is this: remove the vlan.dat file before performing a reload.

deviceName>enable 15
deviceName#erase-or-delete??? vlan.dat
deviceName#reload

That should be able to get the router back into the “normal” state, assuming that startup-config was still left in good shape.

Cisco Routers supporting VLANs

Most of the previous discussion around VLANs centered on implementations on switches. This next section discusses using VLANs on routers running Cisco IOS, rather than switches that use Cisco IOS.

Routers can support multiple VLANs on a physical interface. When multiple VLANs are supported on a single physical interface, the router can receive traffic on one VLAN and then route the traffic to another VLAN on the same physical interface. The result is that the payload of the traffic goes out the same physical interface that it arrived at, although the traffic is modified because the traffic has a different VLAN number. When a router supports this configuration, the configuration is called “router-on-a-stick”.

If the traffic is going to be going out of one of the router's network interface ports that is not using 802.1Q tagging, the outgoing traffic is untagged. If the traffic had previously been tagged, then then the traffic will become untagged. (In other words, all data related to the 802.1Q tagging process will be removed.) This makes sense because the destination is not assumed to support the 802.1Q tagging. This behavior is true with switches, but the sitaution may be less prone to happen with switches. Switches do not have traffic going out a network interface port unless the outgoing network interface port uses the same VLAN tagging settings as the network interface port that the traffic was received on. Routers might send traffic out a physical interface (possibly including the same physical interface), even if traffic is not using the same VLAN. Specifically, routers would do this when traffic is being routed to a different subnet.

Here are some instructions for getting a router to support 802.1Q traffic.

Speed requirement?

Unknown reason why: Cisco Network Academy CCNA course “Discovery 3” slide “3.4.3.2” says “Select a router interface with a minimum of a 100Mbps FastEthernet”. Perhaps that was just meant as a recommendation, rather than a requirement?

Connection

The remote end needs to be actively supporting VLAN communications. For routers, this may require that the network interface port is acting in “trunk” mode, rather than operating in an “access port” mode. Fortunately, operating in “trunk mode” is often the default, so nothing really needs to be done as long as nothing has already been done that would switch the router out of being in “trunk mode”. However, that is an absolute requirement, so it is being mentioned here.

Further details are discussed in the section related to settings related to trunking. See: Cisco Certified Network Associate (“CCNA”) Routing and Switching certification???

Physical interface configuration

The physical interface should not have the IP address assigned to the physical interface. (Instead, the IP address will be assigned to a “sub-interface”.)

deviceName>enable
deviceName#config terminal
deviceName(config)#interface fa0/1
deviceName(config-if)#no ip address
deviceName(config-if)#no shutdown

(Cisco Network Academy CCNA course “Discovery 3” slide “3.4.3.4” shows the “no shutdown” command being placed right after a “no ip address” command. This likely answers the question on what happens if an administrator causes the interface to stop being configured to be administratively down, even before the IP address is assigned. Apparently what happens is nothing spectacular, including no problems. The network port will obviously not be functioning on an IP address when there isn't one set up, but the port is not configured to actively be remaining in a shutdown position. Once the conditions are right, which includes having an IP address, the network port will be useful for IP traffic.)

Subinterface

Make a sub-interface by placing a period directly after the interface name, and then a number. Typically, the number of the sub-interface used will match the VLAN number. For the following example, an interface named fw0/1 will be set up with VLAN 2.

deviceName>enable
deviceName#config terminal
deviceName(config)#interface fa0/1.2
deviceName(config-if)#encapsulation dot1q 2
deviceName(config-if)#ip address 192.0.2.1 255.255.255.0

In the above example, the sub-interface number is two (as specified by the number after the period on the line where the line was specified), and the VLAN number specified was two (as specified on the encapsulation line).

Just don't...

Having the sub-interface name mismatching the VLAN number could cause people to start thinking that the VLAN number is whatever the sub-interface number is. To maximize simplicity, and therefore success, resist any temptation to do such a thing.

The reason that the previous text indicated that the sub-interface number will “typically” match the VLAN number, rather than always matching, is simply because the technology does not actually impose a strict technical requirement that enforces a match between those numbers. People could violate that rule, and things will probably end up working as long as teh VLAN numbers are what are expected. Despite that apparent flexibility, people should follow the guideline to have the sub-interface number match simply because the approach makes so much sense and people are used to doing it that way. The consistency is likely to simplify the task of understanding a configuration.

Multiple VLANs per interface

So now that multiple VLANs on a physical router interface has been discussed, some people may wonder if multiple VLANs can be assigned to a single network interface port on a switch.

Um... yeah... apparently so... probably... whatever that means. Let's take a look at this topic.

A trunk interface on a switch will pass traffic on all VLANs, unless traffic of certain VLANs is restricted (VLAN pruning, or VLAN trunk allowed). (Based on https://learningnetwork.cisco.com/thread/7034 ) The network interface can have only one native VLAN, because the device needs to make a decision regarding which VLAN number will be assigned for all incoming untagged traffic.

IP addresses are assigned to VLANs, not physical network interface ports on a switch. If there is a desire to have a switch port be reachable using multiple VLANs, that may be doable by assigning multiple IP addresses to the VLAN.

Having considered these observations, no fully tested/researched answer is hereby provided to the question. Even if such a thing ends up being technically possible, there just might not be a compelling need to try to do this.

Showing details

Configurations may be checked.

The show commands (generally CCNA/Pre-CCNA level): VLAN-related commands shows multiple commands, many of which start with “ show vlan ”.

trunking

There is some newer info currently at Cisco Certified Network Associate (“CCNA”) Routing and Switching information: VLAN trunking. Older notes follow here.

support trunking. (If connected to another router, make sure the remote router also supports 802.1Q. This means to use router-on-a-stick for that router as well. If connected to another switch, make sure it is supporting 802.1Q. (This isn't just meaning that the device is capable of the ability to support 802.1Q traffic. This means that the 802.1Q support is actively enabled, and the device is actively ready to respond to 802.1Q traffic.)

For Cisco devices that support VLANs, being ready to handle 802.1Q traffic means that the remote network interface port should either be:

  • actively set to working in “trunk” mode,
  • or that the device is ready to switch to “trunk” mode if that behavior gets specified by negotations that are a part of Cisco's Dynamic Trunking Protocol (“DTP”).
Additional details
First-timers

Using Cisco's Dynamic Trunking Protocol (“DTP”) is a slightly more advanced topic than just using VLANs, so that is just being mentioned as one of the possibilties. People who are just trying to get VLANs to work for the first time, and who have full ability to configure all of the devices that will be participating in the VLAN, may have an easier time by just manually placing all of the related network interface ports into a mode where they are actively acting like trunks.

Learning more about Cisco's Dynamic Trunking Protocol (“DTP”) before that point is an approach that probably makes less sense unless using Cisco's Dynamic Trunking Protocol (“DTP”) is required. An example scenario of when Cisco's Dynamic Trunking Protocol (“DTP”) could be required is if communications are intended to be done with a remote device that supports Cisco's Dynamic Trunking Protocol (“DTP”), but which is not under the more manual control of the technician who is trying to make VLANs work.

Reviewers

Understanding “trunking” can be a bit challenging, particularly if lots of information (like “trunking” and using Cisco's Dynamic Trunking Protocol (“DTP”) and using Cisco's VLAN Trunking Protocol (“VTP”)) all gets thrown at a person in a relatively short time without clear clarification on what some of the different behaviors are accomplishing.

More details about Cisco's Dynamic Trunking Protocol (“DTP”) may currently be covered by the section on Cisco Certified Network Associate (“CCNA”) Routing and Switching certification, and is a very sensible topic to look at after having a good grasp of the concept of having network interface ports in “trunk” mode.

People who are already familiar with Cisco's Dynamic Trunking Protocol (“DTP”) have probably already been exposed to topics related to VLAN trunking, so this might simply be a review. For such people, some additional specific details can be provided that may help to give even more clarity. For the remote Cisco device to be actively supporting 802.1Q trunk communications, the remote device's network interface port should be actively configured to either:

  • actively be a trunk
  • be set to use one of the “dynamic” modes of Cisco's Dynamic Trunking Protocol (“DTP”). That means using one of these two modes:
    • either “dynamic desirable”,
    • or “dynamic auto”)
Seeing results:
deviceName#show interface fa0/1 switchport
Switchport: Enabled
Administrative Mode: dynamic auto
Operational Mode: static access
Administrative Trunking Encapsulation: negotiate
Operational Trunking Encapsulation: native
Negotiation of Trunking: On
Access Mode VLAN: 5 (VLAN0005)
Trunking Native Mode VLAN: 1 (default)
Adminsitrative Native VLAN tagging: enabled
Voice VLAN: none
Lots of: "Administrative private-vlan option: value"
Administrative private-vlan option: value"
Operational private-vlan: none
Trunking VLANs Enabled: ALL
Pruning VLANs Enabled: 2-1001
(Additional lines of output)

Another command:

deviceName#show interface trunk
Other VLAN-related topics

Familiarity with VTP/DTP may be expected for people who are interested in seeking the Cisco Certified Network Associate (“CCNA”) Routing and Switching certification. (Further details on that certification may be covered by the section about the Cisco Certified Network Associate (“CCNA”) Routing and Switching certification.)

In particular, see: Cisco Certified Network Associate (“CCNA”) Routing and Switching certification : “VLAN trunking” information