For VLANs to span across multiple switches, you obviously need to connect the switches to each other. Although it is possible to simply plug one switch into another using an Access port just as you would plug in a host or a hub, doing so kills the VLAN-spanning feature and a bunch of other useful stuff too. A switch-to-switch link must be set up as a trunk link in order for the VLAN system to work properly. A trunk link is a special connection; the key difference between an ordinary connection (an Access port) and a Trunk port is that although an Access port is only in one VLAN at a time, a Trunk port has the job of carrying traffic for all VLANs from one switch to another. Any time you connect a switch to another switch, you want to make it a trunk.
Some key points about trunks are as follows:
- A trunk can be created only on a Fast Ethernet or Gigabit Ethernet connection; 10Mb Ethernet ports are not fast enough to support the increased traffic from multiple VLANs, so the commands are not available for a regular Ethernet port.
- By default, traffic from all VLANs is allowed on a trunk. You can specify which VLANs are permitted (or not) to cross a particular trunk if you have that requirement, but these functions are beyond the scope of the CCNA exam.
- Switches (whether trunked or not) are always connected with crossover cables, not straight-through cables. In CCNA land, there is no such thing as a "smart port" that will auto-detect a crossed connection and fix it. The Catalyst 2960 has such a feature, but the exam will test your knowledge of when to use a crossover cable. For the purposes of your exams, if two switches are not connected with a crossover cable, there will be no connectivity between them, period.
When creating a trunk, you must choose a trunking protocol. A trunking protocol adds a VLAN identification tag to frames coming into the switch. As those frames are forwarded across the trunk, the VLAN from which the frame originated is identifiable, and the data frame can be distributed to ports in the same VLAN on other switches—and not to different VLANs. This frame tagging and multiplexing function is what enables VLANs to span multiple switches and still keeps each VLAN as a separate broadcast domain. Figure 12.9 illustrates a simple trunk as it multiplexes frames from two separate VLANs across a single Fast Ethernet Trunk.
Figure 12.9 Trunks carry traffic from multiple VLANs across a single physical link.
Cisco supports two trunking protocols, ISL and 802.1Q, as described in the next sections.
The Inter-Switch Link (ISL) protocol is a Cisco-proprietary Layer 2 protocol. ISL operates by re-encapsulating host frames as they are received by the switch port. The ISL encapsulation adds a 26-byte header and a 4-byte trailer to the original host frame. The header includes the VLAN ID (the VLAN number) and several other fields. The trailer is a new CRC to check the integrity of the ISL frame.
There are two significant issues with ISL. The first is that it is Cisco proprietary, meaning that it will work only between two Cisco devices. In a perfect world, of course, everyone would have all Cisco gear, but the reality is a lot of non-Cisco network devices are out there. To complicate matters, Cisco has begun to phase out ISL in favor of 802.1Q; for example, the Cisco 2960 does not support ISL at all, only 802.1Q.
The second issue with ISL is frame size. If a frame is received that is already at the MTU, the addition of the 26-byte header and 4-byte trailer can create frames that are over the Ethernet MTU of 1,518 bytes (with ISL encapsulation, now at 1,548 bytes), which will be dropped as "Giant" frames by devices that do not recognize the ISL encapsulation. Figure 12.10 illustrates an ISL-encapsulated frame.
Figure 12.10 ISL Re-encapsulates the original host frame.
The IEEE-standard 802.1Q trunk encapsulation has the advantage of being an industry standard, so inter-vendor operation is much less of a problem. Often referred to as "dot1q" (because geeks like lingo), this protocol does not re-encapsulate the original frame, but instead inserts a 4-byte tag into the original header. This means that a dot1q frame will be seen as a "baby giant" of 1,522 bytes. Most modern NICs will not reject these frames if they mistakenly receive one. Figure 12.11 shows a dot1q-tagged frame.
Figure 12.11 802.1Q inserts a 4-byte tag into the existing frame header.
Configuring Switches for Trunking
Configuring a switch for trunking is fairly straightforward. Once again, we focus on the Catalyst 2960 switch; other switches have slightly different capabilities and syntax, and special note of this is made when necessary.
A switch port can be in one of five modes:
- Off—In Off mode, the port is an Access port and will not trunk, even if the neighbor switch wants to. This mode is intended for the connection of single hosts or hubs. DTP frames are not sent or acknowledged. The command to enable this is switchport mode access.
- On—In On mode, the port will trunk unconditionally, and trunk connectivity will happen if the neighbor switch port is set to Auto, Desirable, or NoNegotiate. DTP frames are sent but not acted upon if received. The command to enable this is switchport mode trunk.
- NoNegotiate—Sets the port to trunk unconditionally even if the neighbor switch disagrees. A trunk will form only if the neighbor switch port is set to On, Auto, or Desirable mode. DTP frames are not sent or acknowledged. The command to enable this is switchport nonegotiate.
- (Dynamic) Desirable—This mode actively solicits a trunk connection with the neighbor. DTP frames are sent and responded to if received. A trunk forms if the neighbor is set to On, Desirable, or Auto. If the neighbor is set to NoNegotiate, the trunk will not form because Desirable needs a response from the neighbor, which NoNegotiate will not send. The command to enable this is switchport mode dynamic desirable.
- (Dynamic) Auto—The port trunks only in response to a DTP request to do so. A trunk forms with a neighbor port set to on or desirable. DTP frames are not sent but are acknowledged if received. The command to enable this is switchport mode dynamic auto.
To configure a switch port to trunk, we need to set the mode and choose a trunking protocol (assuming that the switch supports more than one to choose from).
The command to set the port mode is switchport mode, executed at the interface configuration prompt for the port you want to modify. Remember that to set NoNegotiate mode, the command is switchport nonegotiate:
2960(config)#int fa0/1 2960(config-if)#switchport mode access Trunk dynamic auto dynamic desirable 2960(config-if)#switchport nonegotiate
To change the trunking protocol, you need to use a different type of switch because the 2960 only supports 802.1Q. We will use a 2900 for our example:
2900(config-if)switchport trunk encapsulation [isl | dot1q]