Skip to content

Network Ninja

The Long Road to Cisco

  • Home
  • About
  • Legal Disclaimer
  • Archives

Less
More
Trim
Untrim
« Older
Home
Loading
Newer »

Archive for the 'ISL' Category

VLAN Trunks

Published
by
Deon Botha
on April 9, 2008
in 802.1Q, BCMSN, Certification, Cisco Systems, Concepts and Constructs, ISL and Trunk
. 2 Comments

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
  • Proprietary
  • Non-proprietary
  • Encapsulated
  • Tagged
  • Protocol Independent
  • Protocol Dependant
  • Encapsulates the old frame in a new frame
  • Adds a field to the frame header

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.


Search

About

You are currently browsing the Network Ninja weblog archives for the ISL category.

Latest

RSS
  • Digital Growth with your Job
  • Open Shortest Path First – OSPF Fundamentals – Scenario
  • Open Shortest Path First – OSPF Fundamentals – Questions and Answers – Question 13
  • Open Shortest Path First – OSPF Fundamentals – Questions and Answers – Question 12
  • Open Shortest Path First – OSPF Fundamentals – Questions and Answers – Question 11
  • Open Shortest Path First – OSPF Fundamentals – Questions and Answers – Question 10
  • Open Shortest Path First – OSPF Fundamentals – Questions and Answers – Question 9
  • Open Shortest Path First – OSPF Fundamentals – Questions and Answers – Question 8
  • Open Shortest Path First – OSPF Fundamentals – Questions and Answers – Question 7
  • Open Shortest Path First – OSPF Fundamentals – Questions and Answers – Question 6

Archives

  • June 2009
  • April 2009
  • March 2009
  • February 2009
  • November 2008
  • October 2008
  • September 2008
  • August 2008
  • July 2008
  • June 2008
  • May 2008
  • April 2008

Categories

  • 802.11 (7)
  • 802.1Q (1)
  • 802.1X (1)
  • AAA (1)
  • Access Point (7)
  • ACL (4)
  • Addressing (3)
  • Asides (31)
  • auto-summary (3)
  • AutoQoS (1)
  • Bandwidth (2)
  • BCMSN (55)
  • BDR (2)
  • BGP (1)
  • BPDU Filtering (1)
  • BPDU Guard (2)
  • BPDU Root Guard (1)
  • BSCI (67)
  • BSCI Notes (18)
  • BSCI Questions (48)
  • Business (1)
  • Cabling and Equiptment (3)
  • CAM (1)
  • CCDA (1)
  • CDP (1)
  • CEF (1)
  • Certification (123)
  • CIDR (2)
  • CIR (2)
  • Cisco Systems (144)
  • Concepts and Constructs (76)
  • CoS (1)
  • Cost (3)
  • DAI (1)
  • DDNS (1)
  • Debug (2)
  • DHCP Snooping (1)
  • DHCP Spoofing (1)
  • DR (3)
  • DUAL (1)
  • Dynamic ARP Inspection (1)
  • ECNM (5)
  • EIGRP (5)
  • Enterprise Architecture (7)
  • EtherChannel (1)
  • GLBP (1)
  • Hello Timer (2)
  • Hold Timer (2)
  • Hot Standby Router Protocol (1)
  • HSRP (1)
  • IGRP (1)
  • IIN (2)
  • Inter-Vlan Routing (1)
  • Interconnection Technologies (2)
  • IP Source Guard (1)
  • IS-IS (1)
  • ISL (1)
  • LACP (1)
  • Link State Advertisements (2)
  • Load Balancing (2)
  • Loop Guard (1)
  • MAC Address Flooding (1)
  • MLS (1)
  • MSTP (1)
  • NBAR (1)
  • NBMA (1)
  • Off-Topic (12)
  • OSPF (18)
  • PAgP (1)
  • passive-interface (1)
  • PoE (1)
  • Port Security (1)
  • Priority (2)
  • Proxy ARP (1)
  • PVC (1)
  • QoS (2)
  • RIP (1)
  • RIPv2 (1)
  • Root Guard (1)
  • RSTP (1)
  • Show (6)
  • Software (1)
  • SONA (2)
  • SSH (2)
  • STP (5)
  • Stub Router (3)
  • summary-address (1)
  • Support (4)
  • Switch Spoofing (1)
  • TCAM (1)
  • Telnet (2)
  • Troubleshooting (1)
  • Trunk (6)
  • Unidirectional Link Detection (1)
  • VACL (3)
  • VC (1)
  • Vine (20)
  • VLAN (11)
  • VLAN Hopping (1)
  • VLSM (1)
  • VoIP (1)
  • VRRP (1)
  • VTP (4)
  • VTY (1)
  • Wireless (7)


Styled with Sawchuk

Powered by WordPress3.4.1 and K21.0-RC7

Entries Feed and Comments Feed

53 queries. 2.1910 seconds.