Answers: Trunking for Only Some VLANs

By Wendell November 4, 2015 09:05

Time to check your config versus this latest lab. Do you recall the command and syntax to restrict a trunk on a Catalyst switch from supporting all VLANs? Go try the lab yourself on paper, then come back here and check your answer.




Figure 1: Two Switches – Point-to-Point


Example 3: SW1 Config


Example 4: SW2 Config



The VLAN configuration follows a straightforward and familiar pattern. In this case, however, the configuration happens to omit any vlan vlan-id global commands. In each switch, the first time the switchport access vlan vlan-id global command identifies a new VLAN not formerly known by the switch, the switch automatically adds the matching vlan vlan-id global command.

A VLAN trunk forwards traffic from multiple VLANs at the same time. It does this on modern switches via the use of IEEE 802.1Q tagging. Assuming the default native VLAN settings are used, Ethernet frames from all VLANs except for VLAN 1 (the default native VLAN) will have an additional tag added to frame while being forwarded over the VLAN trunk. This tag is essentially a label that marks traffic with its respective VLAN. Once the traffic reaches the second device, that device is able to strip the tag off and use the information in it to properly forward the traffic.

Cisco Catalyst switches default their administrative trunking setting – that is, the configured setting by default – to a mode that tells the switch to use the Dynamic Trunking Protocol (DTP) to negotiate whether to operate as a trunk or not. The instructions told us to configure the statically configure the switches to trunk. To do that, a simple config is needed on both switches: the switchport mode trunk command is used on both switches. Both happen to connect to each other with their G0/3 interfaces.

Trunks support all defined VLANs by default. To achieve that final requirement of disallowing any new VLAN’s traffic from crossing this trunk, until such time as the configuration is changed, you could remove all the other VLANs from the trunk besides VLANs 100, 200, and the (default) native VLAN 1. Use the switchport trunk allowed vlan remove 2-99,101-199,200-4094 interface subcommand to do so. Alternately, you could directly define the VLANs using the switchport trunk allowed vlan 1,100,200 interface subcommand.

Finally, depending on how you read the requirements, you might have added the switchport nonegotiate command to each port as well. This command disables DTP. Whether you did so or not, the link between the two switches would still operate as a trunk due to the static configuration.

Trunking for Only Some VLANs
IPv6 Addressing with OSPFv3
By Wendell November 4, 2015 09:05
Write a comment


  1. Bojan November 4, 11:08

    I am struggling to grasp why DTP is even a “good thing”(tm). Why would an admin ever choose to make a trunk port an access port in a hurry? Without DTP, I know for certain what port is for what on the network. Granted, DTP gives us the option of converting a trunk into access, but then the trunking capacity could be compromised, or the Po is shrunk..etc. Do you know of any real world cases where DTP is useful?

    Reply to this comment
    • Mike November 4, 20:55

      Agreed, DTP can rank right up there (or add to the problem) with VTP regarding its danger. Off-topic: I’ve seen one recent instance where a switch was left with DTP on, it negotiated to trunk, and VTP blitzed the VLAN database (oopsie!). VTP transparent mode and nonegotiate would have saved the bacon on that one.

      From what I’ve gathered, “real world” is to explicitly trunk. As you mentioned, it will be exactly what we expect… a _trunk_. And with DTP off, an attacker cannot trick the switch into a trunk we don’t want. The explict trunking config also serves as documentation if all we had was the switch config (and not console/vty access). 😉

      Reply to this comment
  2. Avinash Kumar November 4, 23:21

    Dear Sir,
    Your blogs are very interesting just as anybody would expect from a mentor like you.

    switchport trunk allowed vlan 100,200

    I hope this will accomplish the same result as above.

    Thanks again.


    Reply to this comment
  3. jr90leo November 22, 19:45

    I think you are missing the ‘switchport nonegotiate’ command.
    As you wrote on the book, setting an interface to access/trunk does not mean autonegotiation is turned off.


    Reply to this comment
    • certskills November 28, 15:02

      Adding that command would disable the negotiation of trunking. My read of the problem statement doesn’t require that command, though. Regardless… the goal is to master the commands and technology, and sounds like we accomplished that. If you see it as required per the problem statement, then yes, that’s how! 🙂

      Reply to this comment
      • Happy April 26, 02:01


        i wonder if i we can also use
        switchport trunk allowed vlan 1,100,200 instead of
        instead of
        switchport trunk allowed vlan remove 2-99,101-199,200-4094 ?

        Reply to this comment
  4. Happy April 26, 02:23


    is the following also ok?

    switchport trunk allowed vlans 1,100,200

    Reply to this comment
  5. Josh G April 9, 16:02

    Just wondering for what reasons people may not want newly added VLANs to be automatically allowed to use the trunk.

    Reply to this comment
    • certskills April 10, 11:35

      Hi Josh,
      For example, imagine that by design, some VLANs are meant to be used on only one access switch, plus the distribution switches that lead to the rest of the network. Then also, imagine the network does not use VTP at all, meaning you do not have the ability to use VTP pruning. a broadcast in such a VLAN would be sent to all switches, unless you removed those VLANs from the appropriate trunks.

      Reply to this comment
View comments

Write a comment

Leave a Reply to Mike Cancel reply


Subscribe to our mailing list and get interesting stuff and updates to your email inbox.

Thank you for subscribing.

Something went wrong.