covered, but no worries because I'm going to cover the access
, mode
, nonegotiate
, and trunk
commands very soon. Let's start with setting an access port on S1, which is probably the most widely used type of port you'll find on production switches that have VLANs configured:
By starting with the switchport mode access
command, you're telling the switch that this is a nontrunking layer 2 port. You can then assign a VLAN to the port with the switchport access
command. Remember, you can choose many ports to configure simultaneously with the interface range
command.
Let's take a look at our VLANs now:
Notice that port Fa0/3 is now a member of VLAN 3. But, can you tell me where ports 1 and 2 are? And why aren't they showing up in the output of show vlan
? That's right, because they are trunk ports!
We can also see this with the show interfaces interface switchport
command:
The highlighted output shows that Fa0/3 is an access port and a member of VLAN 3 (Marketing).
Before we move onto trunking and VTP, let's add a voice VLAN on our switch. When an IP phone is connected to a switch port, this port should have a voice VLAN associated with it. By creating a separate VLAN for voice traffic, which of course you would do, what happens when you have a PC or laptop that connects via Ethernet into an IP phone? The phone connects to the Ethernet port and into one port on the switch. You're now sending both voice and data to the single switch port.
All you need to do is add another VLAN to the same switch port like so to fix this issue and separate the data at the switch port into two VLANs:
That's it. Well, sort of. If you plugged devices into each VLAN port, they can only talk to other devices in the same VLAN. But as soon as you learn a bit more about trunking, we're going to enable inter-VLAN communication!
Configuring Trunk Ports
The 2960 switch only runs the IEEE 802.1q encapsulation method. To configure trunking on a FastEthernet port, use the interface command switchport mode trunk
. It's a tad different on the 3560 switch.
The following switch output shows the trunk configuration on interfaces Fa0/15–18 as set to trunk
:
If you have a switch that only runs the 802.1q encapsulation method, then you wouldn't use the encapsulation command as I did in the preceding output. Let's check out our trunk ports now:
Notice that port Fa0/15 is a trunk and running 802.1q. Let's take another look:
Take note of the fact that ports 15–18 are now in the trunk mode of on and the encapsulation is now 802.1q instead of the negotiated ISL. Here's a description of the different options available when configuring a switch interface:
switchport mode access I discussed this in the previous section, but this puts the interface (access port) into permanent nontrunking mode and negotiates to convert the link into a nontrunk link. The interface becomes a nontrunk interface regardless of whether the neighboring interface is a trunk interface. The port would be a dedicated layer 2 access port.
switchport mode dynamic auto This mode makes the interface able to convert the link to a trunk link. The interface becomes a trunk interface if the neighboring interface is set to trunk or desirable mode. The default is dynamic auto
on a lot of Cisco switches, but that default trunk method is changing to dynamic desirable
on most new models.
switchport mode dynamic desirable This one makes the interface actively attempt to convert the link to a trunk link. The interface becomes a trunk interface if the neighboring interface is set to trunk
, desirable
, or auto
mode. This is now the default switch port mode for all Ethernet interfaces on all new Cisco switches.
switchport mode trunk Puts the interface into permanent trunking mode and negotiates to convert the neighboring link into a trunk link. The interface becomes a trunk interface even if the neighboring interface isn't a trunk interface.
switchport nonegotiate Prevents the interface from generating DTP frames. You can use this command only when the interface switchport mode is access or trunk. You must manually configure the neighboring interface as a trunk interface to establish a trunk link.
Dynamic Trunking Protocol (DTP) is used for negotiating trunking on a link between two devices as well as negotiating the encapsulation type of either 802.1q or ISL. I use the
nonegotiate
command when I want dedicated trunk ports; no questions asked.
To disable trunking on an interface, use the switchport mode access
command, which sets the port back to a dedicated layer 2 access switch port.
Defining the Allowed VLANs on a Trunk
As I've mentioned, trunk ports send and receive information from all VLANs by default, and if a frame is untagged, it's sent to the management VLAN. Understand that this applies to the extended range VLANs too.
But we can remove VLANs from the allowed list to prevent traffic from certain VLANs from traversing a trunked link. I'll show you how you'd do that, but first let me again demonstrate that all VLANs are allowed across the trunk link by default:
The preceding command affected the trunk link configured on S1 port Fa0/15, causing it to permit all traffic sent and received for VLANs 4, 6, 12, and 15. You can try to remove VLAN 1 on a trunk link, but it will still send and receive management data like CDP, DTP, and VTP, so what's the point?
To remove a range of VLANs, just use the hyphen:
If by chance someone has removed some VLANs from a trunk link and you want to set the trunk back to default, just use this command:
Next, I want to show you how to configure a native VLAN for a trunk before we start routing between VLANs.
Changing or Modifying the Trunk Native VLAN
You can change the trunk port native VLAN from VLAN 1, which many people do for security reasons. To change the native VLAN, use the following command:
So we've changed our native VLAN on our trunk link to 4, and by using the show running-config
command, I can see the configuration under the trunk link:
Oops – wait a minute! You didn't think it would be this easy and would just start working, did you? Of course not! Here's the rub: If all switches don't have the same native VLAN configured on the given trunk links, then we'll start to receive this error, which happened immediately after I entered the command:
Actually, this is a good, noncryptic error, so either we can go to the other end of our trunk link(s) and change the native VLAN or we set the native VLAN back to the default to fix it. Here's how we'd do that:
Now our trunk link is using the default VLAN 1 as the native VLAN. Just remember that all switches on a given trunk must use the same native VLAN or you'll have some serious management problems. These issues won't affect user data, just management traffic between switches.