CNC Logo

Switching: Trunks and Dynamic Trunking Protocol (DTP)

Peter J. Welcher

Introduction

This continues the series on LAN switching. Last month's article on VLAN's can be found at http://www.netcraftsmen.net/welcher/papers/switchvlan.html .

For more detail, you may also wish to look at the book by Mentor Technologies' Kennedy Clark and Kevin Hamilton: CCIE Professional Development : Cisco Lan Switching (The Cisco Press CCIE Professional Development Series) . You may also wish to look at the new edition of the classic reference from Radia Perlman, Interconnections, Second Edition: Bridges, Routers, Switches, and Internetworking Protocols (Addison-Wesley Professional Computing Series) . This second edition will be published 9/10/99. I've got a galley proof copy and hope to review it at the end of this series of switching articles.

Amazon.Com links for these books:

  • K. Clark/K. Hamilton: http://www.amazon.com/exec/obidos/ASIN/1578700949/o/qid=936467683/sr=2-1/002-7463159-6136060
  • R. Perlman: http://www.amazon.com/exec/obidos/ASIN/0201634481/qid=936467879/sr=1-3/002-7463159-6136060

    • 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.

    Configuring Trunks

    The relevant Cisco documentation can be found at:

    Catalyst Set-Based Configuration

    On a Catalyst set-based switch, the syntax for setting up a link as a trunk is:
    set trunk mod_num/port_num [on | desirable | auto | nonegotiate] [isl | dot1q | negotiate] [vlan_range]
    Use this command to set the specified port or ports to trunking. The first set of keyword arguments govern the DTP modes:
     
    Mode What the Mode Does
    on Forces the link into permanent trunking, even if the neighbor doesn't agree
    off Forces the link to permanently not trunk, even if the neighbor doesn't agree
    desirable Causes the port to actively attempt to become a trunk, subject to neighbor agreement (neighbor set to on, desirable, or auto )
    auto Causes 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.
    nonegotiate Forces 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:

    clear trunk mod_num/port_num vlans
    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:
    set trunk mod_num/port_num vlans
    To restore defaults settings, configure:
    clear trunk module/port
    To check out what you've done, use the EXEC command:
    show trunk
    show trunk [mod_num/port_num]
    For example:
    set trunk 2/1-2 desirable negotiate
    clear trunk 2/1-2 100-199

    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:
    interface fast 0/1
    switchport mode trunk
    switchport trunk encapsulation isl

    interface fast 0/2
    switchport mode trunk
    switchport trunk encapsulation dot1q

    interface fast 0/3
    switchport mode trunk
    switchport trunk encapsulation isl
    switchport trunk allowed vlan except 100-199

    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:

    switchport mode {access | multi | trunk}
    switchport trunk encapsulation {isl | dot1q}
    no switchport mode {access | multi | trunk}
    switchport trunk allowed vlan {add vlan-list | all | except vlan-list | remove vlan-list}
    no switchport trunk allowed vlan
    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:
    switchport trunk native vlan
    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:
    set vtp [domain domain_name] [mode {client | server | transparent}] [password password]
    [pruning {enable | disable}] [v2 {enable | disable}]
    For example:
    set vtp AnnapolisCampus mode server
    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:

    set vtp pruneeligible vlans
    clear vtp pruneeligible vlan
    And you can check what you've configured with:
    show vtp domain
    show vtp statistics
    clear vtp statistics
    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:
    vlan database
    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:

    vtp domain domain-name
    vtp {server | client | transparent}
    no vtp {server | client | transparent}
    vtp file ifsfilename
    no vtp file
    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:

    vtp password password-value
    no vtp password password-value
    vtp pruning
    no vtp pruning
    vtp v2-mode
    no vtp v2-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:

    show vtp

    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:
    set vlan vlannum [name name] [type {ethernet | fddi | fddinet | trcrf | trbrf}]
    [state {active | suspend}] [said said] [mtu mtu] [ring hex_ring_number ]
    [decring decimal_ring_number ] [bridge bridgenum] [parent vlannum] [mode {srt | srb}]
    [stp {ieee | ibm | auto}] [translation vlannum] [backupcrf {off | on}]
    [aremaxhop hopcount] [stemaxhop hopcount]
    Luckily, we normally don't have to use all that! For Ethernet with defaults, we can get by with something like:
    set vlan 102
    or
    set vlan 102 name Engineering
    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!):

    clear vlan 102
    The following table lists the options and defaults, although some (for example, MTU) vary on Token Ring and FDDI media.
     
    Option Meaning Default
    name text string name of the VLAN (none)
    type type of VLAN (pick one of the keywords) ethernet
    state state of VLAN (suspended doesn't forward frames) active
    said Security Association ID for 802.10 100000 plus the VLAN number
    mtu maximum transmission unit (1500 for Ethernet) 1500 bytes
    ring logical hex ring number for a Token Ring CRF
    decring decimal version of the above
    bridge bridge number for Token Ring SRB, a BRF
    parent BRF parent, required for a Token Ring CRF
    mode mode, Source Route Transparent or Source Route Bridging (Token Ring)
    stp type of Spanning Tree Protocol to use; use ibm for SRB Token Ring environments
    translation translation VLAN number for FDDI to Ethernet
    backupcrf Token Ring CRF: is it a backup path or not?
    aremaxhop All Route Explorer max hops (Token Ring) 7
    stemaxhop Spanning 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:
    vlan database
    vlan number name vlanname
    exit
    To delete a VLAN, do the following in vlan database mode:
    no vlan number
    And to look at the results, there's also show vlan and variants on these switches.

    Wrap-Up

    I'm planning more switching topics for the next month or two. We may also sneak in a little design: you need to think about end-to-end VLAN's versus the "Layer 2/Layer 3" hierarchical approach. See you in a month!

    Dr. Peter J. Welcher (CCIE #1773, CCSI #94014) is a Senior Consultant with Chesapeake NetCraftsmen. NetCraftsmen is a high-end consulting firm and Cisco Premier Partner dedicated to quality consulting and knowledge transfer. NetCraftsmen has nine CCIE's, with expertise including large network high-availability routing/switching and design, VoIP, QoS, MPLS, network management, security, IP multicast, and other areas. See http://www.netcraftsmen.net for more information about NetCraftsmen. Pete's links start at http://www.netcraftsmen.net/welcher . New articles will be posted under the Articles link. Questions, suggestions for articles, etc. can be sent to pjw@netcraftsmen.net . 


    9/4/99
    Copyright 1999, Peter J. Welcher