Following on from my last post on basic Cisco switch configuration, let’s venture into trunking. A trunk is a link between two switches, such as you will undoubtedly need in any reasonably-sized network. Here’s the simple topology I’ll be considering:
We have two switches, labelled S1 and S2, with 24 gigabit interfaces each. Mary and Peter are cabled into port Gi0/1 on each switch, and the switches are trunked via their Gi0/24 ports (I like to use the highest port numbers for trunks). Before we go into trunking details, consider the scenario of Mary sending a frame to Peter. This will illustrate that adding more switches does not change the basics of the forwarding logic they use.
At the outset, each switch’s MAC address table is empty. Mary’s frame enters S1 on port Gi0/1, destined for Peter, and the switch checks the destination MAC against its table. There is no match, so it floods the frame out of all other active ports; in this scenario, the only other active port is the trunk via Gi0/24. S1 also notes the source address, Mary’s, is located out of Gi0/1, and makes an entry in its table.
The frame now enters S2 via its Gi0/24 port. Again, its destination MAC (Peter’s) finds no match since the switch’s table is empty. Thus, it is flooded out of the only other active port, Gi0/1, and Peter receives the frame. S2 notes that the sender’s MAC address (Mary’s) is located via its Gi0/24 port, and makes an entry in its table accordingly. Note that it considers Mary to be reachable via its Gi0/24 port. In fact, Mary is not directly connected to this port; rather, this port connects to another switch and Mary is ultimately attached to that. But none of this affects the switching logic.
We can now review the MAC address table on S1:
S1# show mac-address-table dynamic ---Sample output--- Vlan Mac Address Type Ports ---- ----------- ---- ----- 1 d8f5.5705.aa78 Dynamic Gi0/1
And also on S2:
S2# show mac-address-table dynamic ---Sample output--- Vlan Mac Address Type Ports ---- ----------- ---- ----- 1 d8f5.5705.aa78 Dynamic Gi0/24
The tables are exactly as expected at this point in the scenario. When Peter responds, the two switches will keep a note of his MAC address. S2 will record it as attached to Gi0/1, and S1 will record it as attached to Gi0/24.
The cable used to interconnect these two switches is a regular UTP Ethernet cable. Once upon a time, when connecting two similar devices, like two switches, you had to employ a crossover cable instead of the usual straight-through Ethernet cable. Nowadays, all switch ports use the auto MDI-X technology to choose the correct pinouts, so you can use a straight-through cable in all situations.
This simple topology would work as expected without any further configuration. However, when the time comes to break up the network into multiple VLANs, which I’ll be covering in the next few posts, links between the switches need to become trunks. A trunk is a special kind of link that can carry frames from multiple VLANs and identify which frames belong to which VLAN. Without trunks, VLAN traffic would be restricted to just a single switch, which is hardly useful.
In our topology, two ports participate in the trunk, and they are the Gi0/24 ports on each switch. We will begin with S1’s trunk port:
S1(config)# interface gi0/24 S2(config-if)# description Trunk to S2 S1(config-if)# switchport mode trunk S1(config-if)# switchport trunk encapsulation dot1q
That’s it. First, we tell the port to act as a trunk. The default port mode is access, meaning an end device will be attached which will be a member of a single VLAN. Making the port a trunk will allow frames from all VLANs to flow through it to the switch on the other end. The second line of configuration forces the port to mark frames using the IEEE 802.1q tagging system. We’ll get into the mechanics of this when we cover VLANs in detail, starting in the next post. For now, just appreciate that, when a frame is sent over a trunk, it must be modified to hold the number of the VLAN to which it belongs. 802.1q is the modern standard, but many older Cisco switches also support a proprietary method of tagging frames known as Inter-Switch Link, or ISL. Our configuration ensures 802.1q is being used.
On the other switch, the same configuration is applied:
S2(config)# interface gi0/24 S2(config-if)# description Trunk to S1 S2(config-if)# switchport mode trunk S2(config-if)# switchport trunk encapsulation dot1q
These two ports will now form a trunk. However, there are a few different settings you can apply, and the Cisco exams want you to know the details. First, you can disable trunking by turning a switch port back into a regular access port:
S1(config-if)# switchport mode access
Second, there are a couple of dynamic (automatic) settings that enable a port to negotiate whether or not it should form a trunk, depending on what is attached. Here’s the first:
S2(config-if)# switchport mode dynamic desirable
This causes the port to try its best to form a trunk, provided another switch is connected. If an ordinary end device is attached, the port will remain in access mode. Or, you can use:
S2(config-if)# switchport mode dynamic auto
This tells the port to respond and become a trunk if the attached device signals for it to do so; otherwise, it will remain in access mode. It will not actively signal the other device to form a trunk. Thus, there are three approaches to making a switch port a trunk:
Switch(config-if)# switchport mode trunk Switch(config-if)# switchport mode dynamic desirable Switch(config-if)# switchport mode dynamic auto
Given these settings can potentially differ on the switch ports at each end, you should know how they work in combination. If both ports are set to trunk, then a trunk will, of course, be formed. This is the most solid approach to creating a trunk, since you’re not relying on dynamic machanisms. If one end is set to trunk, and the other uses one of the dynamic settings, a trunk will always form. If one or both ends are set to dynamic desirable, a trunk will also form. The only combination to watch out for is having dynamic auto at both ends. In this scenario, both ports will await the other’s instruction to become a trunk: and both will wait forever. As a result, both ports will remain in access mode.
These automatic settings form what Cisco calls the Dyanmic Trunking Protocol (DTP). Since this protocol is unauthenticated, it is possible for a host to send false reports to a switch, in order to trick it into forming a trunk. This will potentially allow it access to traffic from multiple VLANs, which is a security risk. (See my next set of articles for the details of VLANs.) Therefore, it is recommended that you manually set the port’s mode to trunk, for your trunk ports, and access for the others.
To finish up, let’s see how to confirm a port’s settings for trunking and VLAN access:
S1(config-if)# do show interfaces gi0/24 switchport ---Sample output--- Name: GigibitEthernet0/24 Switchport: Enabled Administrative mode: trunk Operational mode: trunk Administrative Trunking Encapsulation: dot1q Operational Trunking Encapsulation: dot1q Negotiation of Trunking: On Access Mode VLAN: 1 (default) Trunking Native Mode VLAN: 1 (default) Voice VLAN: none Trunking VLANs Enabled: ALL ---Output omitted---
This shows the port has been administratively set to trunk, and that it is currently operating as a trunk. It also reports that 802.1q is administratively set as the VLAN tagging method to use over the link. I’ll cover the various VLAN details shown here over the course of the next few posts. Another approach is to use:
S1(config-if)# do show interfaces trunk ---Sample output--- Port Mode Encapsulation Status Native vlan ---- ---- ------------- ------ ----------- Gi0/24 on 802.1q trunking 1 Port Vlans allowed on trunk Gi0/24 1-4094 Port Vlans allowed and active in management domain Gi0/24 1 Port Vlans in spanning tree forwarding state and not pruned Gi0/24 1
The first line of output states that Gi0/24 has trunking turned on and uses the 802.1q encapsulation. The Status field reports that trunking is currently operational. Now that we’ve seen the essentials of creating trunk links, we can begin an investigation of VLANs.