An example VLAN configured through the use of global config mode on a single switch. To support multiple VLANs that span multiple switches one uses trunks. A trunk carries the traffic of multiple VLANs over links (multiplexing) and enable the extension of a single layer-2 VLAN between switches.
A trunk can exist between two switches, a switch and a router, a switch and a trunk-capable NIC (server). If a physical link carries multiple VLANs (trunk) then each frame going onto the link must be market with a VLAN ID (VID) which is added when entering into the link and removed when forwarded to a access port. This is accomplished through the use of trunking protocols. The two trunking protocols are ISL or Cisco ISL (proprietary) and 802.1Q which is IEEE standard trunking protocol.
| ISL | 802.1Q |
|
|
|
|
|
|
|
|
Depending on the trunking protocol as shown above the data sent across a trunk link is either proprietary to cisco, cross platform (dont you know thats going to be an exam question, encapsulated or tagged, and protocol independant or protocol dependant another exam question.
In short the purpose of a trunking protocol is to provide the receiving switch with a method to identify the VLAN from which the frame originated by giving it a VID as reference by which to insert the frames into the right VLAN.
ISL in Detail
Inter-Switch Link (ISL) is a Cisco Proprietary trunking protocol used to configure layer-2 trunk links. It is the original standard for trunking and pre-dates the IEEE 802.1Q standard. ISL takes the original frame and encapsulates them with a new ISL header and trailer (frame check sequence), cyclic redundancy check (CRC) before sending them on the trunk link.
Because an entirely new header is appended to the original frame, the header offers some features not found in 802.1Q like:
- Multiple protocol support (Ethernet, Token Ring, FDDI, and ATM)
- Supports Per VLAN Spanning Tree (PVST) Protocol
- Does not use native VLAN, so it encapsulates every frame
- The encapsulation process leaves the original frame unmodified
ISL Encapsulation Mechanics
When a switch port is configured as ISL the original frame, including header and frame check sequence is encapsulated before it enters the trunk. Encapsulation (CCNA) is the process of adding a additional header and trailer at the end of the original layer-2 frame. At the receiving end the new header and trailer is read and removed.
Getting more technical ISL adds a 26-byte header and a 4-byte trailer to a frame. The source VLAN-ID (VID) that comprises of a 15-bit VID field in the header. The trailer contains a Cyclic redundancy check (CRC) value to ensure data integrity. ISL adds a total of 30 bytes to a frame.
802.1Q in Detail
Like ISL the 802.1Q trunking protocol allows a single physical link to carry multiple VLANs communication. This is the non-proprietary version by the IEEE meaning that other brand kit will support it (note that other players in the market have more or less ability in following the standards even if they are open). This version rather than encapsulate the frame simply insets a tag into the original header and recalculates the frame check sequence (FCS) then retransmits the frame over the trunk link.
- Suppport for Ethernet and Token Ring.
- Support for 4096 VLANs (big networks, lots of VLANs)
- Support for Common Spanning Tree (CST), Multiple Tree Protocol (MSTP), and Rapid Spanning Tree Protocol (RSTP).
- Point-to-Multipoint topology support.
- Support for untagged traffic over the trunk link via native VLAN.
- Extended quality of service (QoS) support.
- Growing standard for IP telephony links.
802.1Q Tagging Mechanics
In Ethernet, 802.1Q adds a 4 byte tag just after the source address field. The first two bytes are used as Tag Protocol Identifier (TPID) and always have a value of 0×8100 to signify an 802.1Q tag. The remaining two bytes are used as Tag Control Information (TCI) that contains a three bit field for Class-of-Service (COS); One bit of TCI is a Canonical Format Indicator (CFI) flagging whether the MAC Address are in Ethernet or Token Ring. The last 12 bits are used as VLAN ID (VID) to indicate source VLAN. These values can be 0 to 4095. VLANs 0,1 and 4095 are reserved. 802.1Q adds a total of 4 bytes to a frame.
Ethernet Frames cannot (generally) exceed 1518-bytes, known as baby giant frames (if the frame size is near or at that size) adding the 802.1Q header to a baby giant frame makes the frame oversized at 1522-bytes and could cause errors and the frame may be dropped. This shouldn’t be a problem as Cisco Catalyst are compliant with IEEE 802.3ac that extends frame size to 1522-bytes.
802.1Q and ISL
As 802.1Q is an open standard (that favours compatibility inter-vendor) and technically does the same thing (tagging vlans which may be the reason I’ve read in places that Cisco no longer supports ISL on all Switch Platforms). One of the big-ish problems with the use of ISL is that frames that are already big (frames with more than 1518 bytes of payload (MTU) a.k.a jumbo frames or baby giant frames) when encapsulated using ISL (30 bytes) get even bigger. Cisco uses propriotary hardware to deal with this encapsulation method so this shouldn’t be a problem Cisco to Cisco (it’s just so you know).
The problem with trunking Cisco to Cisco may be when one Catalyst Switch Platform supports ISL and another (Catalyst or Non-Cisco) Switch platform doesn’t (apart from the fact that a trunk won’t form). The non-ISL Catalyst switch may report baby “giant” frames and drop the frame. To solve this simply use 802.1Q as Cisco hardware is compliant with 802.3ac.
Similar to the above problem Cisco to Non-Cisco the option to use ISL is eliminated because ISL is propriotary but the Non-Cisco compliance to standards (802.3ac) means that baby giant frames may still be dropped if they exceed the 1518 payload (not actively dissing other vendors, you just don’t want to sit at a clients offices and look clueless when this may be the problem).
Native VLANs
When configuring an 802.1Q trunk, a matching native VLAN must be defined (usually default VLAN 1) on each end of the trunk link. A trunk link is inherently associated with tagging each frame with a VID. The native VLAN is to allow untagged frames across the trunk. If both ends have non-matching Native VLANs problems will arise this is a common configuration error.
Native VLANs have these attributes:
- The VLAN that a port is associated with when not in trunking operational mode
- The VLAN that is associated with untagged frames that are received on a switch port
- The VLAN to which layer-2 frames will be forwarded if received untagged on an 802.1Q trunk port
Comparing this to ISL where no frames will be transported across the trunk unless tagged (encapsulated), and any un-encapsulated frames are dropped.
Notes and Notices:
This is a part of my personal BCMSN notes and research to assist myself in learning and understanding the concepts and theory for the BCMSN exam. I learn by making notes reading and writing things down and wish to file them where I can’t lose them. These notes are not to be seen, judged or mistaken for replacements to Cisco recognized and authorized training which I personally support and attend and suggest you undertake if you are going for the BCMSN Certification.