By default, our switch ports will pass traffic for one virtual LAN, or VLAN, and one VLAN only. Which VLAN will that be? Well which VLAN do our ports belong to by default? VLAN 1. So by default, we’re only passing traffic for one VLAN. But we run into a problem now when we connect two switches together. If I connect two switches together and I want to pass traffic for multiple VLANs across that one single link, how do we do it?
Trunk Operation
Well we need to trunk those switches together. We’ll change our encapsulation really. We’ll change the language that we speak across that link just a little bit and we’ll further identify the VLAN for the frames that traverse that link. That’s a trunk, okay? Now if you’re struggling with this, I want you to think about the challenge – a link, by default, is an access link and it lacks this trunking mechanism. And therefore, one link can only carry one VLAN’s worth of traffic, because we can’t discretely identify which VLAN a frame would be part of. So think about the fact that multiple switches will generally be part of the broadcast domain that the VLAN lives in and we’re going to have potentially hundreds of VLANs in one given space. Certainly, it’s quite common to see 15 to 50 VLANs in a common space to the access layer. So now we have a really big challenge. We might have a gigabit link or a 10 Gb link between our switches, and carrying one VLAN isn’t sufficient, is it? So we choose to make that a trunk link and voilà, our connectivity problem is solved. We still might have a bottleneck, but the VLANs can then flow. So this is a big deal, isn’t it? And we have to think to ourselves, okay, switch-to-switch connections should probably be trunk links, right? Also, switch to multilayer switch or switch to router, because those devices would have to terminate and route for the different VLANs. So all things being equal, when I look at a topology, I think all the links that are going down to PCs, those are going to be access ports, they’re not going to be trunks. And then, the links between my switches, those I’m going to make trunks.
This trunk link has to keep track of which VLAN that traffic belongs to, so it’s going to be tagging. But is every single VLAN tagged when we send traffic over that trunk?
There is an exception to every rule, right? At least, that’s very true here. The trunking protocol that we use in modern day Cisco is 802.1Q. You might see Inter-Switch Link, or ISL, nothing wrong with that, but we’re talking about 802.1Q – the standardized trunking technology. The Institute of Electrical and Electronics Engineers, or IEEE, who designed it, baked in the untagged VLAN called the native VLAN, a default to VLAN 1 and it can be changed. If you change it, make sure you change it on both sides of the trunk link and it, in fact, is a security challenge, so we choose to change it often to 99 or 999. So one of the 4,094 VLANs that could flow, one of them is untagged. That’s the native VLAN, defaults to 1.
Switch#conf t
Switch(config)#int eth 1/1
Switch(config-if)#switchport mode trunk
Command rejected: An interface whose trunk encapsulation is “Auto” can not be configured to “trunk” mode.
Switch(config-if)#switchport trunk encapsulation dot1q
Switch(config-if)#switchport mode trunk
Switch(config-if)#switchport trunk native vlan 99
Configuring Trunks
What we’re looking at here is Cisco’s recommended best practices for trunk implementation. Look at interface Ethernet 1/1, switchport mode trunk. We are explicitly configuring that port to become a trunk. That is not the default configuration. The default configuration on our Catalyst switches is either going to be dynamic auto or dynamic desirable, which is an automatic method for trunking. We will discuss that more here shortly, but Cisco states let’s manually set it. Now switchport mode trunk is going to work if we manually set the encapsulation method as well. Our switches can support both ISL as well as 802.1Q. The majority of the time we are using 802.1Q in the real world. That is the standard we go for. So in order for us to set the mode of trunk, we’ll have to manually set our encapsulation method as well, and what’s the command for that?
Switch#conf t
Switch(config)#int eth 1/1
Switch(config-if)#switchport mode trunk
Command rejected: An interface whose trunk encapsulation is “Auto” can not be configured to “trunk” mode.
Switch(config-if)#switchport trunk encapsulation dot1q
Switch(config-if)#switchport mode trunk
Switch(config-if)#switchport trunk native vlan 99
Yes, you can see it on the screen. So you would say switchport trunk encapsulation and then you would choose dot1q. Now if I look at this switch, the only way that this command switchport mode trunk would be allowed by default is if there wasn’t the option of running ISL, and that is the case on 2960. It will let you do that command and not bark at you. But don’t be too surprised that if you are in the real world, in the wild, you’re going to be doing this on maybe your 3750s or even higher-end devices as it is on the screen. And you do that command and it says no, no, no, you’ve got to choose an encapsulation before it is forceful in the configuration. So we will say, switchport trunk encapsulation, choose dot1q, that is it would be dot1q. That would be the parameter to specify IEEE 802.1Q as the trunking technology, then you can do these other commands.
What about our native VLAN? Cisco throws out 99 in pretty much all of their documentation. That is not a number you have to use, not something you have to use. Well you can see, we changed it using switchport trunk native vlan and we specify that VLAN number. Let’s say you wind up in a testing environment and you want to figure out what VLAN they are using as the native VLAN, but you’re configuring fresh trunk ports so it may not be abundantly obvious. There is a potential for someone to do some good documentation that you can see. Do you remember the command that lists off all of your VLANs? Well you might do that to see what the VLANs are named, and some conventions will have the native VLAN for the entire domain named for you in that list. So you can understand exactly what VLAN the original deployer of that architecture used. Do a show vlan brief if there is any doubt in your mind. Now bear in mind, you have to make sure that both sides of the trunk link match up with regards to the native VLAN. If you don’t, you’re going to affect the VLANs that are misplaced as the native VLAN, okay, we call that merged VLANs. We won’t show you that, but Cisco Discovery Protocol, or CDP, will even sometimes show you, hey, your native VLANs are mismatched across the trunk link, assuming you have CDP running, okay. So make sure that they match up on both sides.
So the very first command we need to familiarize ourselves with is show interfaces, the specific interface that you have set up as a trunk or you expect to be a trunk and then the switchport keyword. Don’t forget the switchport keyword. If we don’t include that switchport keyword, what type of output do we receive? We just see the layer 2 output, like this is how many collisions we had, this is the speed, this is the duplex, it’s up/up. But if I want to see the VLAN-relevant output for an interface, we tack on switchport. So this is really a key, tack on to the command and otherwise this output would be quite elusive to you.
Switch#show interface Ethernet 1/1 switchport
Name: Et1/1
Switchport: Enabled
Administrative Mode: trunk
Operational Mode: trunk
Administrative Trunking Encapsulation: dot1q
Operational Trunking Encapsulation: dot1q
Negotiation of Trunking: On
Access Mode VLAN: 1 (default)
Trunking Native Mode VLAN: 99 (Inactive)
Administrative Native VLAN tagging: enabled
So we can see here, the Name FastEthernet 0/11, Switchport: Enabled, ooh, that’s important. Switchport: Enabled means we are a layer 2 switch port. If it was disabled, that means we were a layer 3 port. We cover that in more advanced courses. So we want to see enabled here, layer two. Administrative Mode, that is what we have configured on our device for the trunking mode. This is where we can verify the default value. Remember, I said the default value would be dynamic auto or dynamic desirable? So we would see that default output here under Administrative Mode. If we change it like we did switchport mode trunk, then we see it’s trunk. The Operational Mode is what we are operating as. So are we a trunk or are we a static access port? We can see the encapsulation method 802.1Q. We can verify whether we have the ability to dynamically negotiate our trunk link. It says Negotiation of Trunking is On. That means we are utilizing the Dynamic Trunking Protocol, or DTP, to send out DTP messages in order to automatically form that trunk between the two switches.
That is an unusual configuration and an undesirable configuration, but this is a trunk link. And when I’m verifying trunk links on a chassis, what I’ll probably do first is I’ll do a show cdp neighbors, and I’ll see what are the other switches and, potentially, routers that I’m connected up to directly. And that will give me some perspective on how many trunk links I expect, switch-to-switch or switch-to-router links, I’m going to expect them to be trunk links.
Switch#show cdp neighborsCapability Codes: R – Router, T – Trans Bridge, B – Source Route BridgeS – Switch, H – Host, I – IGMP, r – Repeater, P – Phone,D – Remote, C – CVTA, M – Two-port Mac RelayDevice ID Local Intrfce Holdtme Capability Platform Port IDRouter Eth 0/1 146 R Linux Uni Eth 0/0Router Eth 0/2 158 R Linux Uni Eth 0/0
At least, I’m going to want them to be trunk links unless I see a need for something else. So I’ll do a show interface trunk.
Switch#show interfaces trunkPort Mode Encapsulation Status Native vlanEt1/1 on 802.1q trunking 99Port Vlans allowed on trunkEt1/1 1-4094Port Vlans allowed and active in management domainEt1/1 1-2Port Vlans in spanning tree forwarding state and not prunedEt1/1 1-2
I prefer that command and I would encourage you to not specify Ethernet 1/1 trunk here, just say show interfaces trunk. That recommendation does not apply to the switchport parameter, you do need to do switchport up top. But nevertheless, whether you put in one interface for the trunk show command or you omit the interface altogether, you’ll get that same output. It will say the Port, then the Mode. Mode on says the switchport mode trunk command was used. We can see the Encapsulation. On some switches you’ll see n- and if you see n-, it means it was negotiated. The Status is trunking, that’s good. The Native vlan 99, that needs to match on both sides. So at least from this local output, we’re quite happy with the configuration that we have here for our trunk.
Our Recommended Premium CCNA Training Resources
These are the best CCNA training resources online:
Click Here to get the Cisco CCNA Gold Bootcamp, the most comprehensive and highest rated CCNA course online with a 4.8 star rating from over 30,000 public reviews. I recommend this as your primary study source to learn all the topics on the exam.
Want to take your practice tests to the next level? AlphaPreps purpose-built Cisco test engine has the largest question bank, adaptive questions, and advanced reporting which tells you exactly when you are ready to pass the real exam. Click here for your free trial.
