Cisco Inter-Switch Link (ISL) Overview
Learn how Cisco ISL trunks carry multiple VLANs, how ISL compares with IEEE 802.1Q, legacy configuration commands, verification, and troubleshooting.
Inter-Switch Link (ISL) is a Cisco-proprietary method for carrying multiple VLANs across a single Layer 2 link. It was used mainly between older Cisco switches. ISL is now a legacy technology; IEEE 802.1Q is the normal choice for modern trunk links.
This lesson explains why trunks are needed, how ISL encapsulates Ethernet frames, how it differs from 802.1Q, and how to recognize or configure it on older Cisco equipment.
Why inter-switch trunk links are needed
A VLAN is a logical Layer 2 broadcast domain. A switch can assign different ports to different VLANs, even when the ports use the same physical switch.
Suppose two switches each have users in VLAN 10 and VLAN 20. Without a trunk, a separate physical link would normally be needed for each VLAN. A trunk allows one link to transport traffic for both VLANs while preserving their separation. This lets VLAN 10 span both switches and VLAN 20 span both switches.
| Feature | Access Port | Trunk Port |
|---|---|---|
| Number of VLANs carried | Normally one VLAN | Multiple VLANs |
| Typical connected device | Endpoint such as a computer, printer, or phone | Another switch, router, firewall, or virtualization host |
| VLAN identification on the link | The port configuration identifies the VLAN | Frames use trunk encapsulation or tagging to identify the VLAN |
| Common use case | Connecting an endpoint to its assigned VLAN | Extending VLANs between network devices |
An access port normally carries traffic for one user VLAN. An access-connected endpoint generally sends and receives ordinary Ethernet frames, while the switch associates those frames with the configured access VLAN. A trunk link carries traffic for several VLANs and needs a method to identify each frame's VLAN as it crosses the link.
What ISL is
Inter-Switch Link (ISL) is Cisco's proprietary VLAN trunk encapsulation protocol. It was designed primarily for Cisco-to-Cisco switch links and was common on older Cisco switching platforms.
ISL is not an open, multi-vendor standard. IEEE 802.1Q became the interoperable standard for Ethernet VLAN trunks and is the normal selection for current networks. Many current Cisco switches do not support ISL at all.
How ISL encapsulates a frame
ISL uses encapsulation, which means adding protocol-specific information around an existing frame. Rather than inserting a small VLAN tag inside the original Ethernet frame, ISL wraps the original Ethernet frame with an outer ISL header and adds an ISL trailer.
The outer header contains information that helps the receiving switch process the encapsulated frame. Most importantly, it includes the VLAN ID, the number that identifies the VLAN associated with the frame. The trailer includes integrity-checking information. Because ISL adds bytes before and after the original frame, the transmitted frame is larger than the original Ethernet frame.
A receiving switch must understand the ISL format. It reads the outer information, uses the VLAN ID to place the frame into the correct VLAN, checks the frame as appropriate, and removes the ISL header and trailer before forwarding the original Ethernet frame within the destination VLAN.
Important ISL fields at a conceptual level
- Destination and source address-related information: identifies the outer encapsulated transmission and the sending interface or device context.
- Frame-type information: indicates how the encapsulated content should be interpreted.
- Length and control information: helps describe and process the encapsulated frame.
- VLAN ID: identifies the VLAN to which the original frame belongs.
- Protocol and control indicators: can identify special control or bridged traffic.
- Integrity checking: an ISL trailer contains a frame-check value used to detect transmission errors. Ethernet also uses an FCS, or Frame Check Sequence, for error detection.
Exact field layouts are mainly relevant when studying legacy platform behavior or analyzing a packet capture. For CCNA-level operation, remember the key sequence: ISL wraps the original Ethernet frame, identifies its VLAN in the outer information, increases the frame size, and is removed by the receiving switch.
ISL compared with IEEE 802.1Q
Both protocols identify VLAN membership on a trunk, but they handle the Ethernet frame differently. ISL wraps the complete original frame. IEEE 802.1Q inserts a VLAN tag into the Ethernet frame between the source MAC address and the EtherType or length field.
| Characteristic | ISL | IEEE 802.1Q |
|---|---|---|
| Standards status | Cisco proprietary | IEEE open standard |
| Vendor support | Primarily older Cisco equipment | Broad support across Cisco and other vendors |
| Frame handling method | Encapsulates the complete Ethernet frame with an outer header and trailer | Inserts a VLAN tag into the Ethernet frame |
| Native VLAN behavior | Does not use the 802.1Q native-VLAN model for ordinary trunk transmission; ISL traffic is encapsulated | The native VLAN is normally sent untagged, while other VLAN traffic is tagged |
| Interoperability | Requires compatible Cisco equipment and ISL support at both ends | Designed for interoperability between implementations that support 802.1Q |
| Current deployment recommendation | Use only when maintaining compatible legacy equipment requires it | Preferred for modern switch-to-switch and other VLAN trunks |
The native VLAN difference
On an 802.1Q trunk, the native VLAN is the VLAN whose traffic is normally transmitted without an 802.1Q tag. The receiving switch assigns untagged traffic to its configured native VLAN. The native VLAN configuration must agree between connected devices to avoid unexpected VLAN assignment and mismatch warnings.
ISL does not have this same untagged native-VLAN behavior as part of its normal encapsulation model. This is one reason an ISL-to-802.1Q mismatch is not merely a minor configuration difference: the two ends interpret the transmitted frame format differently.
Trunk negotiation and compatibility
Dynamic Trunking Protocol (DTP) is a Cisco protocol historically used to negotiate trunk operation and related parameters on supported interfaces. A port may be configured to trunk, to negotiate trunking, or to remain an access port, depending on the platform and IOS behavior.
Both ends of a link must agree on the essential parameters:
- The link must be operationally trunking.
- The encapsulation must be mutually supported and interpreted consistently.
- The allowed VLAN lists must include the VLANs that need to cross the link.
- The VLANs must exist and be active on the relevant switches.
- Where DTP is used, the negotiation settings must produce the intended result.
An ISL endpoint connected to a peer expecting 802.1Q cannot consistently interpret the other's frames. The physical interface can still appear up because Layer 1 is working, while VLAN traffic fails at Layer 2. Similarly, a trunk-mode mismatch can leave a link operating as an access link or prevent trunk formation. On platforms that support only 802.1Q, an ISL selection command is rejected because the requested encapsulation is unavailable.
Legacy ISL configuration
Command syntax depends on the switch model and Cisco IOS release. On older platforms with selectable trunk encapsulation, the conceptual workflow is to select the interface, select ISL, place the interface in trunk mode, and ensure the interface is enabled.
interface gigabitethernet0/1
switchport trunk encapsulation isl
switchport mode trunk
no shutdown
On many modern Cisco switches, 802.1Q is implicit and there is no encapsulation-selection command. A modern trunk might be configured conceptually as follows:
interface gigabitethernet0/1
switchport mode trunk
switchport trunk allowed vlan 10,20,30
no shutdown
Exact syntax varies. Always use command help and the platform documentation for the specific IOS release and switch model.
DTP-related control
When supported, switchport nonegotiate disables DTP frames on an interface. Use it only when the peer is already configured to trunk and both sides have been deliberately configured. Disabling negotiation does not make an access port into a trunk by itself.
interface gigabitethernet0/1
switchport mode trunk
switchport nonegotiate
Verifying an ISL trunk
Verification should examine both the local interface and the peer. A successful physical link is not enough; the interface must be operationally trunking and must carry the required VLANs.
show interfaces trunk
show interfaces gigabitethernet0/1 switchport
show vlan brief
| Check | Expected Result | Relevant Verification Method |
|---|---|---|
| Physical interface status | Interface is up and the line protocol is up | show interfaces or platform-specific interface status output |
| Administrative and operational trunk state | Port is configured and operating as a trunk | show interfaces trunk and show interfaces ... switchport |
| Selected encapsulation | Both ends use a mutually supported encapsulation, such as ISL on a legacy link | show interfaces ... switchport |
| Allowed VLAN list | Every required VLAN is permitted | show interfaces trunk |
| VLAN forwarding state | Required VLANs are active and forwarding on the trunk | show interfaces trunk |
| Peer-side configuration agreement | Mode, encapsulation, VLAN numbering, and allowed VLAN policy agree | Run equivalent commands on the neighboring switch |
show interfaces trunk commonly displays the trunking state, encapsulation, native VLAN where applicable, allowed VLANs, and VLANs that are active or forwarding. The exact fields differ by platform. Use show vlan brief to confirm that the VLAN exists and to review local access-port membership.
Practical example: extending VLANs between switches
Switch A and Switch B each connect users in VLAN 10 and VLAN 20. The inter-switch link is configured as a trunk. When a host in VLAN 10 on Switch A sends traffic to a host in VLAN 10 on Switch B, the sending switch places the frame into the trunk format and identifies VLAN 10. Switch B receives the frame, uses the VLAN ID to associate it with VLAN 10, removes the trunk encapsulation, and forwards the original Ethernet frame toward the destination port.
On legacy Cisco hardware, the trunk could use ISL. On modern equipment, the same logical design should use 802.1Q. The VLAN number remains part of the design, but the wire format changes.
Troubleshooting ISL and trunk problems
Interface is up, but same-VLAN hosts cannot communicate
Possible causes include a link that is not operationally trunking, incompatible encapsulation, a missing VLAN in the allowed list, or a VLAN that is absent, inactive, or not forwarding on one switch.
- Compare both ends with
show interfaces trunk. - Confirm that trunk mode and encapsulation agree.
- Check the allowed, active, and forwarding VLAN lists.
- Use
show vlan briefto confirm VLAN creation and local port membership.
The ISL encapsulation command is rejected
The switch or IOS release may not support ISL, the platform may support only 802.1Q, or the interface type may not support selectable trunk encapsulation. Use command help and platform documentation to identify the available options. Configure an 802.1Q trunk instead when ISL is unavailable.
The trunk is up, but required or unexpected VLAN traffic crosses it
Compare the allowed VLAN lists and forwarding VLANs on both ends. Review any VLAN pruning policy. Also verify endpoint-facing ports: an incorrect access VLAN assignment can look like a trunk problem even when the trunk itself is operating correctly.
Migration from ISL to 802.1Q
During a hardware upgrade, a replacement switch may support 802.1Q but not ISL. A legacy all-Cisco trunk must be changed so both ends use a mutually supported encapsulation. Plan the change, configure 802.1Q on both sides where required, verify the allowed VLAN list, and test reachability for every affected VLAN.
Limitations and retirement of ISL
- Limited vendor interoperability: ISL is Cisco proprietary and is unsuitable for a trunk that must connect to equipment from vendors without ISL support.
- Limited hardware availability: many current switch platforms do not implement ISL.
- Additional frame overhead: wrapping the original frame increases the transmitted frame size.
- Compatibility requirements: both ends need compatible ISL support and matching trunk behavior.
- Modern design guidance: use IEEE 802.1Q for switch-to-switch, switch-to-router, firewall, and multi-vendor VLAN trunks.
ISL remains useful as a recognition and troubleshooting topic for legacy Cisco environments, but it should generally be retired rather than introduced into new networks. For related configuration practice, see configure trunk ports and configure router-on-a-stick.
Exam-relevant summary
- ISL is a Cisco-proprietary, legacy VLAN trunk encapsulation method.
- ISL wraps the complete Ethernet frame with an outer header and trailer.
- The ISL VLAN ID identifies the VLAN associated with the encapsulated frame.
- The receiving switch removes the ISL encapsulation before forwarding the frame inside the destination VLAN.
- IEEE 802.1Q inserts a VLAN tag into the original Ethernet frame and is the interoperable modern standard.
- 802.1Q has a native VLAN that is normally sent untagged; ISL does not use this same native-VLAN behavior.
- Both trunk endpoints must agree on trunk operation and a mutually supported encapsulation.
- An operational trunk must also permit the required VLANs, and those VLANs must exist and be active.
- Use 802.1Q for new deployments, including multi-vendor networks.