Lectures on LAN Switching – Part 08

802.1q Tagging vs. ISL Encapsulation

Currently, there are two trunking protocols being used in Cisco Catalyst Switches; 802.1q (Dot1q) and Inter-Switch Link (ISL). In choosing the trunking protocol to use, you need to check first if both Switches to be connected by a trunking link support the same trunking protocol. With mismatched trunking protocol, the Switches won’t understand how the packets are tagged or encapsulated.

But what are the differences between these protocols?

The main difference between these protocols is that ISL is Cisco proprietary, while Dot1q is an IEEE standard. In short, you can choose to use ISL if you are connecting two Cisco Catalyst Switches. On the other hand, you can use the Dot1q protocol if you need to connect a Cisco Catalyst Switch to a non-Cisco Switch (we refer to it as 3rd party device). Dot1q trunking protocol is usually supported by most non-Cisco Switches that we know.

The other difference between ISL and Dot1q trunking protocols are listed below:

ISL

• All packets are encapsulated (external tagging)
• Adds 26-byte ISL header and 4-byte CRC/FCS
• VLAN ID is included in the ISL header
• Packets are not altered
• Packets are sent as ‘giants’

802.1q

• All packets are encapsulated except those in Native VLAN
• A ‘tag’ is inserted into packets, which extends maximum packet size to 1522 bytes from 1518 bytes
• VLAN ID is included on the 802.1q tag
• Packets are altered. CRC/FCS value is recomputed for the entire packet after the tag insertion
• It presumes that there is only a single instance of STP

If we have this frame structure:

[DA][SA][Type/Length][Data][FCS]

ISL encapsulation will look like this:

[ISL Header][DA][SA][Type/Length][Data][FCS][New FCS]

On the other hand, Dot1q tagging will look like this:

[DA][SA][Dot1q Tag][Type/Length][Data][Recomputed FCS]


Native VLAN Concept

One thing unique with Dot1q trunking is the use of a Native VLAN. By default, both Dot1q and ISL trunking links allow traffic from all VLANs to pass through. There is also a need for ‘management’ frames to be exchanged between Switches (like CDP, VTP, DTP) over trunking connections.

The Native VLAN comes into play whenever there is a need to exchange ‘management’ frames between Switches. There’s no need for multiple instances of the same VTP advertisement to be exchanged just to cater to all the VLANs present on a Switch. In short, 10 VLANs won’t need 10 instances of the same ‘management’ frame. A single instance of the same frame can be exchanged through the Native VLAN.

On Catalyst Switches, VLAN1 is not only the pre-existing VLAN by default. It is also serves as the Native VLAN by default, and it is quite easy to change in both CatOS and IOS.

A quick note on trunking, both end of a trunking link should have the same configuration in order for the link to be up. This includes the Native VLAN configuration, or otherwise, the Switch may encounter ‘Native VLAN mismatch’ error.


Dynamic Trunking Protocol

Another topic that I will discuss about trunking is Dynamic Trunking Protocol (DTP). This protocol is used to negotiate the trunking status between Catalyst Switches’ switchport. By default, DTP is enabled on Switches, and all switchports participate with the trunking negotiation.

DTP provides 5 different statuses or modes to a switchport configured for a trunking link.

On. The trunk is enabled on the switchport regardless of the status of the switchport on the other side of a trunking link. DTP is also enabled and DTP frames are sent out of the link.

Off. The trunk is disabled on the switchport, but DTP is still enabled.

Auto. The switchport will be in passive mode, and will wait for instructions from the other side of the link (through received DTP frames) if it will be in trunk mode. The switchport will not send DTP frames eventhough DTP is enabled. It is not recommended for both sides to be configured in Auto mode.

Desirable. The switchport will actively seek to be in trunking status, and will send/receive DTP frames. But, it will still follow the wishes of the other side. If both of them are in Desirable mode, then a trunking link will most definitely be created. If paired with a switchport in Auto mode, the Desirable switchport will be the one to instruct the other side (to be in trunking status as much as possible).

Nonegotiate. The trunk is enabled on the switchport regardless of the status of the other side. But, DTP will be disabled and no DTP frames will be sent. This mode is useful if the other side is not capable of understanding DTP frames (possibly 3rd party devices).


For more information, you can start reading from this Trunking page from Cisco.com.