07-03-2003 06:21 AM - edited 03-02-2019 08:36 AM
1) Can one show advantages (disadvantages) of using ISL instead of 802.1q?
2) Is there any impact to LAN network in case mixing those two between different devides.
3) Is ISL frame decapsulated on each switch or does it go like a flow? What about 802.1q?
Jakub
Solved! Go to Solution.
07-03-2003 11:46 PM
Hi,
ad 1) The only advantage of using ISL I know is support for FDDI and Token Ring frames while 802.1q suports only Ethernet.
Disadvantages: proprietary, 30-bytes header, only 1000 VLANs supported (802.1q: standard, 4-bytes header, 4000 VLANs supported)
ad 2) It should work with no problem but the network design is more complicated.
ad 3) Interesting question. I understand that you are asking: Is a new header and FCS calculated when a tagged frames comes on trunk and is forwarded to another trunk?
I haven't found any document describing directly, but http://www.cisco.com/warp/public/473/741_4.pdf says:
"The SA field is the source address field of the ISL packet. It should be set to the "802.3" MAC address of the switch port transmitting the frame. It is a 48-bit value. The receiving device may ignore the SA field of the frame."
and
"The INDX field indicates the port index of the source of the packet as it exits the switch. It is used for diagnostic purposes only, and may be set to any value by other devices. It is a 16-bit value and is ignored in received packets."
So I think for correct filling these header fields the ISL frame should be decapsulated on each switch. But I'm not sure - if these fields were filled incorrectly the ISL frame still gets to the destination.
Regarding 802.1q - I haven't found any CCO document again. But I don't see any reason why to recalculate frame FCS if nothing has changed (one reason might be 802.1p priority changing).
Also IEEE 802.1q specification says:
"Relaying a tagged frame requires
j) If the frame formats used on the source and destination MAC methods differ, translation of the tag header to the format appropriate for the destination MAC method;
k) If the source and destination MAC methods differ, relaying the frame may require translation of the remainder of the frame, as defined in ISO/IEC 11802-5, IETF RFC 1042, and IETF RFC 1390;
l) Inclusion/adjustment of the PAD field, if necessary, where the destination MAC method is 802.3/Ethernet (7.2);
m) Re-computation of the Frame Check Sequence (FCS) if necessary.
So I think 802.1q frames are sent like a flow while transmitted from one trunk to another.
Regards,
Milan
07-03-2003 06:28 AM
ISL is Cisco Proprietary. dot 1 q is a standard.
ISL is not supported in some cisco switches, (4000 comes to mind) could lead to nasy suprises.
THey are mutually exclusive, running both would complicate your l-2 design
depends.
smart money does dot 1 q
07-03-2003 10:23 PM
Hi vmiller,
I know that ISL is Cisco's proprietary. I have asked because I would like to know if there are any advantages of using ISL instead of dot 1q. I'm about to design new network for campus and as you noticed ISL is not available in low-end products. So that's design consideration.
Jakub
07-03-2003 11:47 PM
The only advantage of ISL over Dot1Q is that ISL also supports Token Ring, FDDI and ATM VLAN's and a max frame size of 4530 bytes .
However given the 30 bytes overhead for ISL (26 byte header / 4 byte CRC) compared to Dot1Q's 4 byte overhead and the choice of a standards based against proprietry, personally I would always choose Dot1Q
07-03-2003 11:46 PM
Hi,
ad 1) The only advantage of using ISL I know is support for FDDI and Token Ring frames while 802.1q suports only Ethernet.
Disadvantages: proprietary, 30-bytes header, only 1000 VLANs supported (802.1q: standard, 4-bytes header, 4000 VLANs supported)
ad 2) It should work with no problem but the network design is more complicated.
ad 3) Interesting question. I understand that you are asking: Is a new header and FCS calculated when a tagged frames comes on trunk and is forwarded to another trunk?
I haven't found any document describing directly, but http://www.cisco.com/warp/public/473/741_4.pdf says:
"The SA field is the source address field of the ISL packet. It should be set to the "802.3" MAC address of the switch port transmitting the frame. It is a 48-bit value. The receiving device may ignore the SA field of the frame."
and
"The INDX field indicates the port index of the source of the packet as it exits the switch. It is used for diagnostic purposes only, and may be set to any value by other devices. It is a 16-bit value and is ignored in received packets."
So I think for correct filling these header fields the ISL frame should be decapsulated on each switch. But I'm not sure - if these fields were filled incorrectly the ISL frame still gets to the destination.
Regarding 802.1q - I haven't found any CCO document again. But I don't see any reason why to recalculate frame FCS if nothing has changed (one reason might be 802.1p priority changing).
Also IEEE 802.1q specification says:
"Relaying a tagged frame requires
j) If the frame formats used on the source and destination MAC methods differ, translation of the tag header to the format appropriate for the destination MAC method;
k) If the source and destination MAC methods differ, relaying the frame may require translation of the remainder of the frame, as defined in ISO/IEC 11802-5, IETF RFC 1042, and IETF RFC 1390;
l) Inclusion/adjustment of the PAD field, if necessary, where the destination MAC method is 802.3/Ethernet (7.2);
m) Re-computation of the Frame Check Sequence (FCS) if necessary.
So I think 802.1q frames are sent like a flow while transmitted from one trunk to another.
Regards,
Milan
07-04-2003 12:03 AM
Hi Milan,
Thanks a lot for your valuable notes.
Jakub
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide