Latest

CCNA RnS Article #27: VLAN Trunking Configuration

 

CCNA RnS Article #27: VLAN Trunking 

In this article, we are going to see VLAN trunk configuration Reviewing the previous articles on VLANs – VLAN Configuration, Virtual VLAN Concepts, VLAN Tagging, and Inter-VLAN Routing is good.

Overview

A physical connection between two switches is called the VLAN trunk. This trunk link carries the traffic for multiple VLANs. Using trunk, you extend your network from one switch to another to provide flexibility in your network. For example, you don’t need all users in VLAN 10 to be in one location, it can be spread across the building using trunking.

Configuring trunking between two switches is straightforward when it is hard coded. However, it can also be negotiated using the Dynamic Trunking Protocol (DTP) between the switches. Understanding the behavior of various scenarios is required for a network administrator and this is what we’ll cover here.

There are three trunking types - IEEE 802.1Q, ISL, or auto-negotiate [using DTP]. Let’s understand two terms first – administrative mode and operational mode. Auto-negotiation using DTP can decide whether a connection is to be tunneled or not depending on the interface settings (performed by admin). This is called the administrative mode. The result post-negotiation is called the operational mode (it means what is the current state of the connection – trunk/no-trunk).

A trunk between two switches is configured using the switchport mode interface configuration command. This command has multiple options –

switchport mode access – configure a port as access and don’t perform trunking

switchport mode trunk – configure a port as trunk

switchport mode Dynamic desirable – initiate negotiation message and respond to messages to dynamically choose whether to form a trunk or not

switchport mode dynamic auto – wait for negotiation message to come, once a message is received then respond and negotiate on the trunk. (it means don’t initiate any message just listen from the other end). Let’s look at some of the scenarios –

Figure 1: Auto Config

When both switches are configured with “switchport mode auto”, no trunk will be formed. It is due to the fact, both switches will not initiate the negotiation messages.

Now if we change either side to “switchport mode dynamic desirable”, for instance switch 2 – will initiate the negotiation message and a trunnel will be formed between two switches.

Figure 2: Switch 2 - dynamic desirable

As you can see from command output below switch 1 and switch 2 connections are by default configured as dynamic auto. Due to this there is no trunk formed between the switch and the connection is in Access mode [notice the current operational mode of the link – it is the outcome of the current settings on the interface].

Figure 3: dynamic auto setting at both ends

Let’s change the switch 2 interface to “dynamic desirable”.

Figure 4: Switch 2 Dynamic Desirable

Once either end is set to dynamic desirable, a trunk will be formed as the other end is listening and based on the current administrative trunk Encapsulation configuration (dot1Q), a IEEE 802.1q trunk is formed between switch 1 and 2.

I hope the below output clarifies lots of things for an administrator. You should be able to interpret the same.

Figure 5: Trunk Status on both Switches

Observe the Administrative mode on Switch 1 is “dynamic auto” as it is default setting and nothing has been changed on switch 1. If you see the same filed in Switch 2, you can see it is “dynamic desirable” as it is changed by administrator (Figure 4).

Check the Operational Mode filed on Switch 1 is “trunk”. Switch 2 is initiating the trunk negotiation messages and switch 1 ethernet 0/1 port listening to those and formed a trunk as both sides are compatible to form a trunk.

Administrative trunking Protocol is configured as dot1q at both ends (default setting for our lab switch), so a dot1q trunk is formed [notice the Operational Trunking Encapsulation field at both switches].

Now on a switch, if you want to know how many trunk connections are there, you can use “show interface trunk” command –

Figure 6: show interface trunk

You can see there is 1 trunk formed on port Gig0/1, it’s local mode is auto, and dot1q encapsulation is negotiated based on the other end configuration setting. The native VLAN on this trunk is 1, which means traffic in VLAN 1 will not be tagged with VLAN information over this trunk interface.

Let’s see how the output of “show interface trunk” command differs on switch 2 –

Figure 7: Switch 2 - show int trunk

You can notice, the local Mode setting is “desirable” as configured by admin. Finally let’s look at the expected turning operational mode based on the configured mode –

Switch 1 – administrative Mode

Switch 2 – administrative Mode

Trunk Operational Mode

dynamic auto

dynamic auto

Access

dynamic auto

access

Access

dynamic auto

dynamic desirable

Trunk

dynamic auto

trunk

Trunk

trunk

trunk

Trunk

Configuring one end as “access” and the other end as “trunk” is problematic. You need not use this setting in production. This is a mismatched trunk configuration, traffic tagged by one side of the port will be discarded at the other end (as it is an access port). 

Finally, let's discuss a few things that stop an interface to form a trunk connection - 

- if you configure auto at both ends will not form a trunk

- if one end is configured as access at one end and the trunk at another will be in a problematic state (not functioning trunk)

- if one end is configured as auto and the other end is access, this will transition an interface to access port not trunk 

- at last, make sure both ends match on the native VLAN configuration

Tip: Cisco’s best practice says to disable trunk negotiation on the interfaces and configure it manually. This is for better security. Once an interface is configured as trunk or access it stops sending DTP messages. There is another command “switchport negotiate” to disable auto-negotiation on an interface.

I hope you find this informative! 

Continue Reading...