Switching: Trunks and Dynamic Trunking Protocol (DTP)

What is a Trunk?

 

We’ve seen in the previous article that a VLAN is a broadcast domain, a collection of ports or users that we wish to group together within an IP subnet, IPX network. We’ve also seen that VLAN’s work to control broadcast, multicast, unknown destination, and problem frame flooding. Our previous discussion centered on the concept of what a VLAN is, perhaps from the perspective of a single switch.

The natural question to ask then is, can VLAN’s span multiple switches?

The answer to this is certainly yes, if we take the naive approach of  setting up VLAN’s on the multiple switches, and then link the switches with paired ports, one pair per VLAN. The drawback to this naive approach is that it burns up switch ports interconnecting the switches. And it is rather manual, labor-intense and hard to maintain, if we go about it in this naive fashion. So vendors came up with VLAN trunking. The point is to cable switches together with high speed interlinks (uplinks), and have multiple VLAN’s share the one physical cable.

Well, one way to think about a VLAN is that when a broadcast comes in a port in the VLAN, the VLAN really is specifying what other ports a copy of the broadcast has to be flooded out. Local to one switch, no big deal. When the broadcast is sent across a common shared trunk cable, the receiving switch needs some way of knowing what VLAN the braodcast frame is in, so that it will know what ports to flood the broadcast out. The naive approach accomplished this by using a separate interconnect cable per VLAN: the receiving switch can look at the port the frame arrived on, just as with any local frame, and tell what VLAN the frame is in. With the shared trunk, the receiving switch has no way to do this.

So vendors came up with the idea of adding tags to frames as they transit a trunk. With VLAN tagging, the sending switch inserts a number in the frame indicating the VLAN the frame belongs to. The receiving switch then strips out the VLAN tag and forwards the frame. It can use the VLAN id to determine the appropriate VLAN when needed.

If you think of a VLAN as “virtual cabling”, you can then think of the tags as what keeps the virtual cables separated when they cross one physical trunk cable.

Of course, various vendors came up with all sorts of proprietary schemes for VLAN tagging. These also affected the trunk frame format, and were highly likely to cause non-interoperability, whereby the receiving switch didn’t understand or know to strip off the VLAN tagging information from another vendor’s sending switch. Cisco’s somewhat proprietary trunking scheme was ISL (Inter-Switch Link) on Fast Ethernet, and 802.10 on FDDI and other media.

The 802.10 standard is a security standard. Since VLAN’s can be thought of as a Security Association (group of users with shared security interests), this was a nice and logical attempt to not re-invent this particular wheel. Unfortunately it got hung up on the issue of encryption (unlikely / expensive at faster wire speeds), and there was a certain amount of anti-Cisco backlash as well. The standards committee finished up with the 802.1q standard. The various vendors including Cisco are evolving their products in that direction now.

Unless you’re using FDDI, you’re going to be choosing between ISL and 802.1q on Cisco switches. The fun thing is, you need a scorecard of which software releases and blades support which trunking schemes. In particular, the newer switches tend to do 802.1q, the older Catalyst blades do not and only do ISL. Check the software and blade capabilities if you’re doing a network design or network upgrade, to avoid nasty surprises!

What is Dynamic Trunking Protocol (DTP)?

 

In addition to the issue of how to transport VLAN’s between switches, there are a couple of other potential issues that arise when you start trunking.

The first issue is that both ends of a trunk cable had better agree they’re trunking, or they’re going to be interpreting trunk frames as normal frames. End stations will be extremely puzzled by the extra tag information in the frame header, their driver stacks won’t understand it, and the end systems may lock up or fail in odd ways. Not fun to troubleshoot! To resolve this, Cisco came up with a protocol for switches to communicate intentions. The first version of it was VTP, VLAN Trunking Protocol, which worked with ISL. The newer version works with 802.1q as well, and is called Dynamic Trunking Protocol (DTP), so you can tell it apart from VTP.

The second issue is creating VLAN’s. If you have to configure VLAN’s individually, switch by switch, you have a lot of work to do. Worse, there’s a danger of inconsistency, whereby VLAN 100 is Engineering on one switch, and Accounting on another. Oops! That would be a source of confusion in troubleshooting, and might also defeat your carefully crafted VLAN security scheme. This also is addressed by VTP/DTP. You can create or delete a VLAN on one switch, and have the information propagate automatically to a group of switches under the same (your) administrative control. This group of switches would be a VTP domain.

 

Catalyst Set-Based Configuration

 

On a Catalyst set-based switch, the syntax for setting up a link as a trunk is:

Use this command to set the specified port or ports to trunking. The first set of keyword arguments govern the DTP modes:

ModeWhat the Mode Does
onForces the link into permanent trunking, even if the neighbor doesn’t agree
offForces the link to permanently not trunk, even if the neighbor doesn’t agree
desirableCauses the port to actively attempt to become a trunk, subject to neighbor agreement (neighbor set to ondesirable, or auto)
autoCauses the port to passively be willing to convert to trunking. The port will not trunk unless the neighbor is set to on or desirable. This is the default mode. Note that auto-auto (both ends default) links will not become trunks.
nonegotiateForces the port to permanently trunk but not send DTP frames. For use when the DTP frames confuse the neighboring (non-Cisco) 802.1q switch. You must manually set the neighboring switch to trunking.

The second set of keywords governs the type of VLAN tagging to use: ISL, 802.1q, or negotiate which to use.

There is a complicated table in the documentation (see the URL above) showing what happens with different combinations of these two keywords. (One end at on-isl the other at on-dot1q, etc.). It’s messy and I think the simplest thing to do is not do it! That is, either hard-code isl or dot1q on both ends consistently, or (perhaps better) use the negotiate keyword wherever possible, to avoid inconsistencies.

You can also specify a VLAN range when configuring trunks. This VLAN range is what VLAN’s are allowed across the trunk. By default the trunk carries all VLAN’s between switches. If you over-ride this with a list of VLAN’s, then only those VLAN’s are connected between the two switches. The other ones have no connection between the switches, at least not across the trunk being configured.

You can also control which VLAN’s cross a trunk by blocking certain ones with the command:

With this, you specify that on certain ports, the stated VLAN’s do not extend across the trunk. You can add other VLAN’s across the trunk with:

To restore defaults settings, configure:

To check out what you’ve done, use the EXEC command:

For example:

IOS-Based Configuration (2900 XL Series)

 

The IOS-based switches are of course a bit different, but follow the same rough idea. You do need the Enterprise software edition, or you won’t have multiple VLAN’s and trunking will be moot (and missing from your IOS, too). Here is a sample configuration of one such switch:

ISL is the default trunk encapsulation. The documentation contains no discussion of negotiation (desirable) as an option. The entire switch must have either only ISL trunks or 802.1q trunks, not both.

The last line of the example shows how you can block selected VLAN’s on a trunk on an XL model switch. Here’s the abstract syntax for these commands:

802.1q has a notion of native VLAN for a trunk. Frames from the native VLAN are not tagged on a trunk, whereas frames from all other VLAN’s are. You can see where mismatches on native VLAN would be bad — neighboring switches would then inadvertantly connect two VLAN’s together. Apparently CDP is used by the XL switches to check for mismatches — and will complain mightily on the console if there is one! Here’s how you configure the native VLAN for a trunk:

These switches also have a multi mode for ports. This allows multiple VLAN’s on one port, presumably the port connected to a server. My guess after reading the documentation is that the multi port floods broadcasts to all related VLAN’s. Whereas access port broadcasts only flood to ports within the associate single VLAN. Note that the multi mode is incompatible with trunking on the same switch. I see it as a flexibility option for one-switch organizations. Otherwise, stay away from it!

Configuring VTP Domains

 

So VTP is used to ensure trunks are consistently configured. And it carries VLAN information throughout a VTP domain, a group of switches configured for common administrative control. Let’s look at the commands for setting up VTP domains. They come in set-based and IOS-based flavors (plus some variants on other switch models).

Catalyst Set-Based Configuration

 

On the Catalyst set-based switches, you configure VTP with the variants of the following command:

For example:

The defaults are server mode, no password, pruning disabled, v2 disabled, so if you want the default settings, you can omit those portions of the command. The way to clear the password is to set it to 0 (the digit zero). If you specify a password, it is used for authentication of VTP messages.

You can also specify which VLAN’s are eligible for pruning with:

And you can check what you’ve configured with:

The statistics commands are useful for troubleshooting; you can see whether the switch is sending and receiving VTP messages.

IOS-Based Configuration (2900 XL Series)

 

On these switches, you use a special mode to do VTP and most VLAN operations. This mode is sort of a separate configuration mode, reached from the EXEC mode by using the command:

Type apply or exit to exit this mode and update the VTP database revision number. Use abort to bail out without committing the changes or affecting the VTP database revision number.

VTP-related commands available within the vlan database mode:

The first of these specifies the VTP domain name. Remember: only consenting switches (with the same VTP domain name, interconnected by trunks) can share VLAN information via VTP. The second line is how you specify the VTP mode. The third one is how you restore the default, server mode. The fourth allow a change of the flash file that the VTP info is stored in (default filename flash:vlan.dat), or restore the default.

Some more commands within vlan database mode:

The first is to allow use of a password with VTP, as minor insurance against goofs. VTP pruning allows a VLAN to automatically not be carried across trunks to switches and groups of switches with no ports in that VLAN, reducing unnecessary broadcast and Spanning Tree traffic across trunks. That’s normally a good thing, but there is currently a bug in the XL switches whereby the presence of VTP pruning anywhere in the VTP domain apparently inhibits the switches from correct multicast forwarding/flooding.

Version 2 VTP has enhancements, especially for the ISL trunking of Token Ring. Otherwise you don’t need it. Turn it on on your VTP server and it will propagate throughout the VTP domain switches.

Finally, to see what you have wrought:

Creating and Deleting VLAN’s

 

Now we’ve established communication among our switches across trunks, it would be nice to know how to add or delete VLAN’s, to take advantage of this mechanism.

Catalyst Set-Based Configuration

 

The syntax for VLAN creation is:

Luckily, we normally don’t have to use all that! For Ethernet with defaults, we can get by with something like:

or

Many of the remaining options are for Token Ring switching, which we’re not going to go into, at least not in this article.

To delete VLAN 102 (throughout the domain!):

 

The following table lists the options and defaults, although some (for example, MTU) vary on Token Ring and FDDI media.

OptionMeaningDefault
nametext string name of the VLAN(none)
typetype of VLAN (pick one of the keywords)ethernet
statestate of VLAN (suspended doesn’t forward frames)active
saidSecurity Association ID for 802.10100000 plus the VLAN number
mtumaximum transmission unit (1500 for Ethernet)1500 bytes
ringlogical hex ring number for a Token Ring CRF
decringdecimal version of the above
bridgebridge number for Token Ring SRB, a BRF
parentBRF parent, required for a Token Ring CRF
modemode, Source Route Transparent or Source Route Bridging (Token Ring)
stptype of Spanning Tree Protocol to use; use ibm for SRB Token Ring environments
translationtranslation VLAN number for FDDI to Ethernet
backupcrfToken Ring CRF: is it a backup path or not?
aremaxhopAll Route Explorer max hops (Token Ring)7
stemaxhopSpanning Tree Explorer max hops (Token Ring)7

To look at the results, use the show vlan command.

IOS-Based Configuration (2900 XL Series)

 

Adding and deleting VLAN’s is done in vlan database mode on the 2900 and 3500 XL switches. This ends up looking like:

To delete a VLAN, do the following in vlan database mode:

And to look at the results, there’s also show vlan and variants on these switches.