This document introduces the concept of trunking between two Ethernet
switches and focuses on the IEEE 802.1Q trunking standard. After a brief
description of the 802.1Q trunking mechanism, the document describes the
implementation on the Catalyst 4500/4000, 5500/5000, and 6500/6000 series
switches. A full example is provided, along with some common errors that relate
to the 802.1Q trunking configuration with the use of Catalyst OS (CatOS) system
software. For examples of 802.1Q trunking with Cisco IOS® system software,
refer to
Configuring
802.1Q Trunking Between a Catalyst 3550/3560/3750 and Catalyst Switches That
Run Cisco IOS Software.

In Cisco terminology, a trunk is a point-to-point link that carries
several VLANs. The purpose of a trunk is to save ports when creating a link
between two devices that implement VLANs, typically two switches. In this
diagram, there are two VLANs that you want to have available on two switches,
Sa and Sb. The first easy method to implement is to create two physical links
between the devices. The physical links each carry the traffic for a VLAN:

Of course, this solution does not scale. If you want to add a third
VLAN, you must sacrifice two additional ports. This design is also inefficient
in terms of load sharing; the traffic on some VLANs may not justify a dedicated
link. A trunk bundles virtual links over one physical link, as this diagram
shows:

Here, the unique physical link between the two switches is able to
carry traffic for any VLAN. In order to achieve this, each frame sent on the
link is tagged by Sa so that Sb knows the VLAN to which it belongs. Different
tagging schemes exist. The most common for Ethernet segments are:

802.1Q uses an internal tagging mechanism. Internal means that a tag is
inserted within the frame:

Note: With ISL, the frame is encapsulated instead.

Note: On an 802.1Q trunk, one VLAN is NOT tagged. This VLAN, named the
native VLAN, must be configured the same on each side of the trunk. In this
way, you can deduce to which VLAN a frame belongs when you receive a frame with
no tag.

The tagging mechanism implies a modification of the frame; the trunking
device inserts a 4-byte tag and recomputes the frame check sequence (FCS):

The EtherType field that identifies the 802.1Q frame is 0x8100. In
addition to the 12-bit VLAN-ID, 3 bits are reserved for IEEE 802.1p priority
tagging.

Note: Inserting a tag into a frame that already has the maximum Ethernet
size creates a 1522-byte frame that can be considered a "baby giant" by the
receiving equipment. The IEEE 802.3 committee is extending the maximum standard
frame size in order to address this issue.

The 802.1Q standard is more than just a tagging mechanism. It also
defines a unique spanning tree instance that runs on the native VLAN for all
the VLANs in the network. Such a Mono Spanning Tree (MST) network lacks some
flexibility in comparison to a Per VLAN Spanning Tree (PVST) network that runs
one instance of Spanning Tree Protocol (STP) per VLAN. Cisco developed PVST+ in
order to allow running several STP instances (even over an 802.1Q network) by
using a tunneling mechanism. Although beyond the scope of this document, it can
be briefly described as utilizing a Cisco device in order to connect a MST zone
(typically the 802.1Q-based network of another vendor) to a PVST zone
(typically a Cisco ISL-based network). There is no specific configuration to
enter in order to achieve this. Ideally, a mixed environment should look like
this diagram:

In the current implementation, Cisco devices support only VLAN numbers
up to 1005. This restriction, introduced to match the number of VLANs that are
available with ISL, is allowed by the 802.1Q standard. Cisco implemented a VLAN
mapping feature in CatOS 5.1 in order to simplify interoperability with other
vendor devices, but it is seldom necessary.

Cisco also adapted its Dynamic ISL (DISL) protocol and turned it into
Dynamic Trunking Protocol (DTP). DISL can negotiate ISL trunking on a link
between two devices; DTP can, in addition, negotiate the type of trunking
encapsulation (802.1Q or ISL) that will be used as well. This is an interesting
feature as some Cisco devices support only ISL or 802.1Q, whereas some are able
to run both.

In Cisco implementation, a trunk is a point-to-point link, although it
is possible to use the 802.1Q encapsulation on an Ethernet segment shared by
more than two devices. Such a configuration is seldom needed but is still
possible with the disablement of DTP negotiation.

From a software point of view, the first appearance of 802.1Q
encapsulation was with CatOS software 4.1. In this release, trunking
configuration had to be hard coded; DTP only appeared with CatOS 4.2. See the
DTP Modes section of this document.

Not all Catalyst ports support 802.1Q encapsulation. Currently, while
Catalyst 4500/4000 switches only support 802.1Q, ports of the Catalyst
6500/6000 series are able to use 802.1Q or ISL encapsulation. Depending on the
module, Catalyst 5500/5000 trunk-capable ports are able to use 802.1Q
encapsulation, ISL encapsulation, or both. The best way to check this out is to
use the
show
port capabilities command. The trunking capacity is
explicitly stated:

When you configure a port for trunking, you can set two parameters: the
trunking mode and the encapsulation type (if DTP is supported on that
port).

The trunking mode defines how the port will
negotiate the setup of a trunk with its peer port. Here is a list of the
possible settings:

Trunking Mode

DTP Frames Sent

Description

Final State (Local Port)

on

YES, periodic

The local port advertises the remote it is going to the
trunking state.

Trunking, unconditionally.

auto

YES, periodic

The local port advertises the remote it is able to trunk but
does not request to go to the trunking state.

The port will end up in trunking state only if the remote
wants to, that is, the remote mode is on
or desirable.

desirable

YES, periodic

The local port advertises the remote it is able to trunk and
asks to go to the trunking state.

If the port detects that the remote is able to trunk (remote
in on, desirable, or auto
mode), it will end up in trunking state, or else will stay
nontrunking.

nonegotiate

NO

Local port goes to unconditionally trunking, with no DTP
notification to the remote.

Trunking, unconditionally.

off

YES

Disable trunking on the port. DTP frames are only sent out
when the port is transitioning to nontrunking.

Nontrunking, unconditionally.

Be careful that some modes (on,
nonegotiate, off) explicitly specify
in which state the port will end up. A bad configuration can lead to a
dangerous, inconsistent state in which one side is trunking and the other side
is not.

A port in on, auto, or
desirable sends DTP frames periodically. A trunking port
in auto or desirable goes back to
nontrunking if it does not receive a DTP update from its neighbor within 5
minutes.

Note: If you run CatOS software 4.1, you must disable any form of
negotiation by using the off or
nonegotiate mode when you configure
802.1Q trunking.

The encapsulation type allows the user to specify
whether 802.1Q or ISL should be used when setting up the trunk. Of course, the
parameter is only relevant if the module that you use is able to use both. The
parameter can have three different values:

Encapsulation Type

Description

ISL

Sets the port encapsulation to ISL.

dot1q

Sets the port encapsulation to 802.1Q.

negotiate

This encapsulation is only available in auto
or desirable trunking modes.

If the remote has a negotiate encapsulation type, the trunk
will eventually be set up with ISL.

If the remote is configured for ISL or 802.1Q, or is only
able to do ISL or 802.1Q, the trunking encapsulation that is used will be the
one of the remote port.

This example is based on a very simple lab setup that involves two
Catalyst 5500/5000 switches that are linked together via trunk-capable ports.
You need a
crossover
cable in order to interconnect two switches.

You have the default value for that kind of port. It came when
negotiating 100-MB full duplex, and it is assigned to VLAN 1. Issue the
show trunk 5/24 command in order to clearly see that
the port is not trunking and has a default mode auto and encapsulation
negotiate.

If you have the output of a show
interface command from your Cisco device, you can use
Output Interpreter
(registered customers only)
to
display potential issues and fixes.

Check connectivity between Sa and Sb.

Issue theping
10.0.0.2 command from switch Sa in order to prove that
switch Sb can now be reached:

Sa> (enable) ping 10.0.0.2
10.0.0.2 is alive
Sa> (enable)

Configure the same VTP domain on both
switches.

Now assign the same VTP domain to both switches. As you saw, having
the same VTP domain is mandatory in order to use DTP negotiation. Issue the
set
vtp domain cisco command on both switches in order to
configure them with the domain name "cisco":

Issue the
set
vlan 2 command on both switches in order to create the
VLAN 2. If the switches were already linked by a trunk, you would only need to
issue the command on one switch, and the other switch would learn it
automatically via VTP. As you do not have a trunk yet, there is no VTP
communication between Sa and Sb:

Sa> (enable) set vlan 2
Vlan 2 configuration successful
Sa> (enable)

Change the management interfaces to VLAN 2.

You now move the management interface of both switches into VLAN 2.
In this way, you show that there is no communication between Sa and Sb before a
trunk is established. Issue the
set
interface sc0 2 command on each switch in order to move
the sc0 interface in VLAN 2. Issue the
show
interface command in order to check that the command is
effective:

Now the trunk on Sa must be configured. You saw in Step 1 that both
ports were in the default trunking mode auto, encapsulation type negotiate. A
combination auto-auto does not bring a trunk up. This is normal; each side is
willing to become trunk, but will only do it if the remote requests it. With
consideration of the default configuration:

You just need to change the trunk mode to desirable on one side
in order to bring the trunk up. This is because a port in desirable mode
notifies its neighbor that it wants to go trunking. As the remote (in auto
mode) goes to trunking if prompted to, this is enough to bring the trunk up.

If you configure the encapsulation dot1q on a subinterface, this
means that that VLAN cannot be used again in the system since internally, the
6500 or 7600 allocate the VLAN and then make that subinterface the only member
of it. So it is not possible to have a VLAN and then try to use it in a
subinterface or vice versa. In order to fix that issue, instead of
subinterfaces, create trunk ports and that way the VLAN can be seen in all
interfaces. If subinterfaces are required, then the VLANs added in the
subinterfaces can not be used in other ports.

You also need to specify which encapsulation you want to use.
This is because both ports are ISL capable, and this encapsulation is chosen
first when both ends are in negotiate mode.

The console log of the previous command clearly shows that the port
moved to trunking, but you can also issue the
show
trunk 5/24 command on Sa and the
show
trunk 2/24 command on Sb in order to check. You can see a
subtle difference between the two outputs:

The port on Sa is in desirable mode, whereas the Sb port is in
auto mode.

More interesting, the encapsulation is dot1q on Sa whereas it is
n-dot1q on Sb. This is to show that Sb negotiated
its encapsulation to dot1q. If you did not specify an encapsulation on Sa, both
ports would have ended up in n-isl encapsulation:

The command
set vlan 2 5/24 is used to assign a port to a specific
VLAN. In the case of a trunking port, it changes the native VLAN to VLAN 2. Of
course, you need to do the same on Sb with
set
vlan 2 2/24 :

Before you change the native VLAN on Sb, there is now an
inconsistency between the Sa and Sb configuration. The two ends of the trunk do
not have the same native VLAN configuration. Here, some warning messages are
displayed on the Sb console.

Note: The switch that reports the inconsistency may vary, which depends
on which one is the root bridge for VLANs 1 and 2.

When you create a new trunk, it carries by default all the existing
VLANs in the network. You will see how to restrict the list of allowed VLANs on
a trunk. First, you must create two additional VLANs (3 and 4). You can issue
the
set
vlan 3 command and the
set
vlan 4 command on Sa, for instance, in order to create the
additional VLANs. You only need to enter the command on one switch; VTP
propagates this information to the other switch.

Note: This part of the configuration is absolutely the same whether
802.1Q or ISL encapsulation is used.

The command clear trunk module/port
vlan-list allows you to remove one or several VLANs
from a given trunk. Here, the four VLANs that you created were defined on your
trunk. Remove VLAN 2 and VLAN 3 with use of the
clear
trunk 5/24 2-3 command on Sa and the
clear
trunk 2/24 2-3 command on Sb. You can check the result of
the clear command with use of the
show
trunk 5/24 command. Only VLANs 1 and 4 now cross the trunk
between Sa and Sb. A ping between Sa and Sb now fails:

This is a frequent configuration error. The native VLAN that is
configured on each end of a 802.1Q trunk must be the same. Remember that a
switch receiving a nontagged frame assigns it to the native VLAN of the trunk.
If one end is configured for native VLAN 1 and the other to native VLAN 2, a
frame that is sent in VLAN 1 on one side is received on VLAN 2 on the other.
This results in the merge of VLAN 1 and 2. There is no reason that you would
want that, and it may imply some connectivity issues in your network.

A Cisco device usually warns you of a native VLAN mismatch. See Step 1
of the section Set the Native VLAN for the kind
of error messages that you get on the console in this case. Always check that
the native VLAN is the same on the trunk configuration of your switches.

When you create a trunk between two switches and you use DTP
negotiation, double check that the VTP domain that is configured on both
switches is the same. Negotiation does not take place between two switches that
are in different VTP domains. The example in this section takes the working
trunking configuration that is described above.

Note: Even if two switches are in different VTP domains, you can make these
switches communicate with each other if you add VLANs manually on each switch.
Although there is a VTP domain mismatch, the VLAN communication works fine.
However, VTP updates are not propagated through this link on that VLAN because
the domains are different.

Sa in trunking mode desirable, encapsulation dot1q

Sb in trunking mode auto, encapsulation negotiate

The same native VLAN, and the same VLANs allowed on each
side

The only difference is that you assign VTP domain "c" on Sa and VTP
domain "cisco" on Sb:

When you try to delete the extended-range VLANs from a trunk port with
use of the
clear
trunk command, this error is sometimes shown on the switch
console:

Failed to clear vlans in the extended range Maximum of 64 trunks can have
non-default extended range vlan configuration. Use the 'set trunk' command to restore
some existing entries to the default value.

Note: The term extended range includes any VLAN from
1025 to 4094. The term default extended range includes all
VLANs from 1025 to 4094. If you try to clear any VLAN in the range from 1025 to
4094, the VLAN becomes non-default extended range. The
maximum number of trunks which pass non-default extended
range is 64. This includes both inactive and active trunks.

This error and the limitation of 64 trunks come from the NVRAM block
which is used to store nondefault configurations for extended-range VLANs. If
you issue the
show
trunk extended-range command, you can see all the trunks
that are configured with nondefault extended ranges. By default, the entire
configuration is stored in NVRAM. NVRAM has different "blocks" for saving the
nondefault configurations. The blocks are placed into different categories,
such as global or module. The block that holds the nondefault configuration for
extended ranges has a limitation of 64 trunks.

There are two workarounds to reduce the number of nondefault
extended-range trunks. The first method is to set any of the nonactive/unused
trunk ports back to the default allowed VLANs. Use the
set
trunk mod/port
1025-4094 command. Then the clear trunk
mod/port 1025-4094
command should work for the extended VLANs. The second workaround is to change
the configuration mode from binary (default) to text mode. Use the
set
config mode text command in order to change the
configuration mode to text mode. Text mode typically uses less NVRAM or Flash
memory space than binary configuration mode uses.

Note: When operating in text file configuration mode, most user settings
are not immediately saved to NVRAM; configuration changes are only written to
DRAM. You must issue the
write
memory command in order to store the configuration in
nonvolatile storage. Use the set config mode text
auto-save command in order to save the text configuration in
NVRAM automatically.

This is a common issue that began to be raised to
Cisco
Technical Support when the first modules that were able to support both
802.1Q and ISL shipped. People were used to the configuration of a trunk with
use of the set trunk module/port
on command or the set trunk
module/port nonegotiate command. The
problem is that, by default, the encapsulation type is set to negotiate. The
negotiate encapsulation type is only supported by auto or desirable trunking
modes. The on and nonegotiate encapsulation types do not perform any
negotiations between switches and must be hard set to ISL or 802.1Q
encapsulation when they are configured. Here is a log of what happens on the
switch in this case: