In my last post, I introduced the essentials of VLANs; so, if you need a refresher, be sure to read that article. Today, I’ll discuss what IEEE 802.1Q tagging is all about and demonstrate how to configure it.
Creating VLANs on a switch is easy: just add the new VLANs to the database and assign access ports into them. An access port can be a member of only one VLAN at a time. But what happens when you have more than one switch? Consider this scenario, in which the MAC tables of the switches are complete:
John sends a frame over to Ringo. Both switches have the same VLANs in their databases and John and Ringo are in the same VLAN. Were both devices connected S1, there would be no problem: it would simply forward the frame to Ringo. However, the switch has a trunk port connecting it to S2, and the frame will be sent through the trunk instead (all VLAN frames go through trunks by default). What happens when S2 gets a copy of the frame? Here are the basic details of an Ethernet frame header:
Preamble Destination MAC Source MAC Type Payload -------- --------------- ---------- ---- ------- Etc. MAC MAC IP IP packet
As you can see, the header has no field to indicate which VLAN this frame belongs to. When S2 receives the frame, how can it know whether it should send it to Ringo, who resides in VLAN 2? It might well be able to match the destination MAC to Ringo’s in its table, but unless it knows that the incoming frame is also in VLAN 2, it does not have the necessary information to forward the frame according to VLAN rules.
This scenario neatly illustrates why trunk links need to use VLAN tagging. Many older Cisco devices used a proprietary tagging method known as Inter-Switch Link (ISL), but that is now obsolete. The industry has standardized upon IEEE 802.1Q. In my trunking article, I describe how to place the trunk ports of each switch into trunking mode and enable IEEE 802.1Q tagging. Here’s a recap, taking S1 in our current scenario as an example:
S1# configure terminal S1(config)# interface Gi0/24 S1(config-if)# description Trunk to S2 S1(config-if)# switchport mode trunk S1(config-if)# switchport trunk encapsulation dot1q
It’s possible that modern Cisco devices will throw an error at that last line, since they support only 802.1Q encapsulation and therefore cannot change it to anything else. Still, there’s no harm in trying. With the same configuration applied to the Gi0/24 port on S2, our trunk is fully operational. John once more sends a frame to Ringo. The switch sends the frame over the trunk and, because this trunk uses 802.1Q, the frame is modified slightly before being sent:
Preamble Destination MAC Source MAC 802.1Q Type Payload -------- --------------- ---------- ------ ---- ------- Etc. MAC MAC VLAN ID IP IP packet
Note the insertion of an extra 802.1Q header between the source address and type fields. When S2 receives this frame on its own trunk port, it removes this extra field, takes note of its VLAN number, and sends the original frame on to Ringo, confident the VLANs match. In other words, the 802.1Q tag only appears as the frame passes over the trunk: the sender adds it and the receiver removes it. All other devices see the original Ethernet frame.
Let’s run another example: Ringo sends a broadcast. The frame goes to Gi0/1 on S2, which recognises the destination address as a broadcast (FF-FF-FF-FF-FF-FF). It also notes that the port it entered through is in VLAN 2. Thus, it sends a copy to all access ports in the same VLAN, so Paul and Mal get copies. It then sends the frame over any trunks. There is only one trunk here, on port Gi0/24, so the frame is tagged with 802.1Q indicating the VLAN number and sent to S1. Finally, S1 receives the frame and removes the tag, sending a copy to John and Brian, who also reside in VLAN 2.
So the idea of VLAN tagging is pretty simple. One further concept of 802.1Q is that of the native VLAN. By default, this is VLAN 1—which, you will recall, is the default VLAN on Cisco switches. All ports are members of this until you create some more VLANs and assign them. Imagine a device is attached to a port in the default VLAN 1, and sends a frame that needs to cross a trunk. If that trunk’s native VLAN is also 1, it will simply send the frame without inserting an 802.1Q tag. The receiving trunk port should be configured with the same native VLAN, so when it receives the untagged frame, it will consider it to be a member of VLAN 1 and act accordingly. Put in a few simple words: the native VLAN means that frames within a designated VLAN (1, by default) are not tagged when they go through trunks.
Considering our earlier scenario, we can see the native VLAN on a trunk port via:
S1# show interfaces gi0/24 switchport ---Sample output--- Name: GigibitEthernet0/24 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: 1 (default) Voice VLAN: none Trunking VLANs Enabled: ALL ---Output omitted---
Observe that the Trunking Native Mode VLAN is 1. It should be the same on S2’s Gi0/24 port else any frames from the default VLAN 1 will fail to cross the trunk properly and will not reach their destinations. For security reasons, it is recommended that you do not rely on the default VLAN 1; some attacks against it are possible. So, on a new switch, create a new VLAN to use as the default, then place all ports that are not part of any more specific VLANs into it. Since you cannot delete VLAN 1, it will remain in the database, but with no ports assigned to it. Let’s say that ports Gi/10 – 23 are not used in other VLANs; we’ll assign them to a new ‘Default’ VLAN numbered 50:
Switch# configure terminal Switch(config)# vlan 50 Switch(config-vlan)# name Default Switch(config-vlan)# exit Switch(config)# interface range Gi/10 – 23 Switch(config-if-range)# switchport mode access Switch(config-if-range)# switchport access vlan 50 Switch(config-if-range)# exit
Finally, we must tell the trunk port, Gi0/24, that the 802.1Q native VLAN is now 50:
Switch(config)# interface gi0/24 Switch(config-if)# switchport mode trunk Switch(config-if)# switchport trunk encapsulation dot1q Switch(config-if)# switchport trunk native vlan 50
Simple. The same sort of configuration would need to be used on other trunks and switches so that everything matches. Any traffic from VLAN 50 needing to cross the trunks will not be tagged, and any untagged traffic entering a trunk port will be assumed to belong to VLAN 50. (Of course, the native VLAN doesn’t have to be the switch’s default VLAN, it could be any; however, the default is typical.)
One further trunk configuration you may wish to make is to limit the VLANs that can pass through it. In the topology at the start of this article, observe that S2 only has ports in VLAN 2. Thus, it would be a waste of time sending other VLAN frames across the trunk from S1 to S2. You can tell a switch’s trunk port which VLANs are ‘fair game’ quite easily: let’s configure Gi0/24 on S1 to send only VLAN 2 traffic:
S1(config)# interface gi0/24 S1(config-if)# switchport trunk allowed vlan 2
The same should be applied at the other end of the trunk on S2. To add VLANs back in, use the add parameter, or delete them via remove. You can also specify multiple VLANs and ranges, as in:
S1(config-if)# switchport trunk allowed vlan add 1, 3-5 S1(config-if)# switchport trunk allowed vlan remove 1
To review these settings, issue:
S2# show interfaces Gi0/24 switchport ---Sample output--- Port Mode Encapsulation Status Native vlan ---- ---- ------------- ------ ----------- Gi0/24 on 802.1q trunking 50 Port Vlans allowed on trunk Gi0/24 2-5 ---Output omitted---
Under Port Vlans allowed on trunk, you can clearly see exactly which VLANs are permitted over the link. All the commands issues above are applied here, and only VLANs 2 to 5 are allowed.
To wrap up, how many VLANs can you create on a switch? Well, you’re limited by the number of bits used to identify the VLAN in that 802.1Q header that is added over trunks. The entire addition is 4 bytes (32 bits), of which 12 bits are used to number the VLAN. This gives 2 to the 12th power, or 4096 possibilities. Since devices start counting at zero, this provides a range of 0 to 4095; but the first and last numbers are reserved. This leaves 4094 assignable numbers. VLAN 1 is, as we’ve seen, always present as the default VLAN, although it is recommended you don’t use it. Most other numbers are usable, although there are a few reserved VLANs here and there, for historical reasons, like 1002 to 1005.
How many of these you can actually create on a switch depends upon the IOS and the hardware. However, it’s largely a moot point since you won’t come anywhere near the maximum! It is worth noting that Cisco considers VLANs 1 to 1005 to be standard VLANs, and those from 1006 to 4094 to be extended VLANs. The reason for the distinction is due to hangovers from the olden days of Cisco’s proprietary ISL trunking protocol, when the VLAN range ended at 1005.
In the next article, I’ll explore the time-saving dangers of the VLAN Trunking Protocol.