Content

| 4.1 |  | Methods of Inter-VLAN Routing |
| 4.1.4 |  | Role of the different VLANs |

There are various types of VLANS including:

- VLAN 1
- The default VLAN
- The user VLANs
- The native VLAN
- The management VLAN

By default, all Ethernet interfaces on Cisco switches are on VLAN 1. On Catalyst switches all of these VLANs listed above default to VLAN 1, which can add to the difficulty of understanding their differences. This section will help explain the various types of VLANS and attempt to clear up some of this confusion.

VLAN 1
The reason VLAN 1 became a special VLAN is that Layer 2 devices needed to have a default VLAN to assign to their ports, including their management port(s). In addition to that, many Layer 2 protocols such as CDP, PAgP, and VTP needed to be sent on a specific VLAN on trunk links. For all these purposes VLAN 1 was chosen.

CDP, VTP, PAgP, and DTP are always transmitted over VLAN 1. This is always the case and cannot be changed. Cisco recommends that VLAN 1 be used only for these protocols. The management VLAN and user VLANs should all be configured to use VLANs other than VLAN 1.

Default VLAN
By default, VLAN 1 is also the VLAN assigned to all switch interfaces, unless configured otherwise. VLAN 1 is also known as the default VLAN. Because it is the default, the other types of VLANs, the native VLAN, the management VLAN and the user VLANs, are all automatically members of VLAN 1.

All Ethernet interfaces on Catalyst switches default to VLAN 1. Any device connected to an interface on a switch will be a member of VLAN 1 unless that interface is configured to use a different VLAN with the switchport access vlan interface command.

User VLANs
User VLANs are what is normally thought of when we think of VLANs. A user VLAN is a VLAN that is created to segment a group of users, either geographically or logically, from the rest of the network. The switchport access vlan interface command is used to assign interfaces to these various user VLANs.

Native VLAN
A topic that causes considerable confusion is the native VLAN. The native VLAN is a term used with interfaces that are configured as VLAN trunks. When a switch port is configured as a trunk, it tags frames with the appropriate VLAN number. Frames from all VLANs are carried across the trunk link containing the 802.1Q tag, except for frames belonging to VLAN 1. By default, frames from VLAN 1 belong to the native VLAN, and are carried across the trunk untagged.

The IEEE committee that defined 802.1Q decided that, for backward compatibility it was desirable to support the so-called native VLAN, that is to say, a VLAN that is not associated explicitly with any VLAN (with a tag) on an 802.1Q link. This VLAN is implicitly used for all the untagged traffic received on an 802.1Q capable port.

This capability is desirable because it allows 802.1Q capable ports to talk to old 802.3 ports directly by sending and receiving untagged traffic. However, in all other cases, it may be very detrimental because frames associated with the native VLAN lose their tags. For example, identity enforcement, as well as Class of Service (802.1p) bits are lost when untagged frames are transmitted over an 802.1Q link.

For these reasons, loss of means of identification and loss of classification, the use of the native VLAN should be avoided for data traffic. There are very few reasons why the native VLAN would ever need to be used explicitly for traffic.

The native VLAN can be modified to a VLAN other than VLAN 1 with the following interface command:

> Switch(config-if)#switchport trunk native vlan vlan-id

It is recommended that the native VLAN should never be used as a user VLAN or the management VLAN.

Earlier it was stated that control traffic, CDP, VTP, PAgP, and DTP, is transmitted over VLAN 1, the default native VLAN. If the native VLAN is changed to something other than VLAN 1, then the control traffic would then be transmitted on VLAN 1 as tagged traffic. This will have no ill affects on the control traffic.

It is fine to leave VLAN 1 as the default native VLAN, as long as VLAN 1 is not used as a user VLAN or as the management VLAN. Control traffic should be the only information carried across VLAN 1. However, it is also common practice to change the native VLAN to some dummy VLAN (other than VLAN 1) that is not used for any data or management traffic.

It is also important to ensure that both ends of a switch-to-switch link have consistent native VLANs configured. If the native VLANs on both ends of a link are not the same, there will effectively be a bridge between the two VLANs and they will no longer be independent broadcast domains. Fortunately, recent versions of the IOS alert the user when mismatches in the native VLAN occur.

Management VLAN
Most of today’s switches and routers can be accessed remotely through Telnet to the IP address of the device. It is recommended practice to put these and other networking devices in their own VLAN, known as the management VLAN. This should be a separate VLAN, independent of any user VLANs, independent of the native VLAN, and independent of VLAN 1. In case there are network problems, such as broadcast storms or spanning tree convergence issues, an independent management VLAN allows the network administrator to still be able to access these devices and troubleshoot the problem.

Another reason to keep the management VLAN independent of user VLANs is that it keeps “trusted devices” separated from “untrusted devices” lessening the possibility, either by misconfiguration, by accident, or by intent, that users gain access to the routers or switches.

Configuring the Router
When a router’s interface is configured as a trunk link, frames received on that interface from the native VLAN on the switch enter the interface untagged. Frames from the other non-native VLANs enter the interface tagged as ISL or 802.1Q.

Configuring the router’s interface as a trunk link requires the use of subinterfaces. Each VLAN is configured on a separate subinterface. Each subinterface is configured to match the proper trunking protocol on the switch, ISL or 802.1Q. This is done with the router interface command:

> encapsulation [ dot1q | isl ] vlan.

However, the router's subinterface that receives the native VLAN traffic must be configured to expect those frames to be untagged. This is done using the native option on that subinterface:

> encapsulation [ dot1q | isl ] vlan. native

Prior to IOS 12.1(3)T the router had to be configured with the native VLAN on the physical interface and non-native VLANs were configured on the subinterface with the ISL or 802.1Q tag.

To summarize the different VLANs and how they should be used:

- By default, VLAN 1 is the native VLAN and should only be used to carry control traffic, such as CDP, VTP, PAgP, and DTP. This information is transmitted across trunk links untagged.
- User VLANs should not include the native VLAN. VLAN 1 will be the native VLAN unless the native VLAN is changed. User VLAN traffic will be sent as tagged frames across VLAN trunks.
- The Management VLAN should be a VLAN separate from the user VLANs and should not be the native VLAN and should not be VLAN 1. This will insure access to networking devices in case of problems with the network.
- The subinterface on the router that is used to send and receive native VLAN traffic must be configured with the native option on the encapsulation interface command. This will let the router know that any frames coming in untagged belong to that subinterface and are a member of the native VLAN.