Answers: Trunking for Only Some VLANs

Chris
By Chris 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.

 

 

Answers

Figure 1: Two Switches – Point-to-Point

 

Example 3: SW1 Config

 

Example 4: SW2 Config

 

Commentary

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
CLI Passwords 2
Chris
By Chris November 4, 2015 09:05
Write a comment

12 Comments

  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

      @Bojan:
      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.

    Regards
    Avinash

    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.

    Regards

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

      Hi,
      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! 🙂
      Wendell

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

        Hi,

        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

    hi,

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

      Reply to this comment
  6. Julie Lofquist January 8, 09:26

    Hi Mr. Odom,

    Question and then a comment:

    Question: the command “switchport trunk allowed vlan 1, 100, 200” seems easier to use than the “switchport trunk allowed vlan remove 2-99,101-199,201-4094.” I see that your original answer was to use the “remove” command. Is the “remove” command preferable?

    Also, in your Commentary, there is a slight typo in the “remove” command. You have “200-4094,” when it should be “201-4094.” (It is shown correctly in the commands, however.) Just wanted to let you know.

    Thanks so much!

    Julie Lofquist

    Reply to this comment
    • certskills January 21, 11:07

      Hi Julie,
      Thanks for the Mr! Feel free to use first names here as well – I’m pretty informal. But fine either way!
      I’ll fix the typo – thanks for the heads up.

      As for your questions about using the remove command/option, I used it here in the blog as an exercise to get everyone to try various options – no more no less.
      From a real-life perspective, it can be very useful. Imagine a few year time span, and company that by convention, all new VLANs must be explicitly allowed on trunks, and all VLANs that are removed from service must be removed from trunks. Certainly sounds like a pain, but from a security perspective, that might be a better approach than say allowing all VLANs, or allowing all and using VTP pruning. Anyway, if the norm is to remove a VLAN (or a few) when the work request is to decommission something in the network, then using the remove option can make a lot of sense. Of course, you could always look at the existing command, figure out what the results of the remove would be, but just doing the remove for sure just removes those VLANs.
      But yes, you could always just define the VLANs directly.

      Hope this helps,
      Wendell

      Reply to this comment
View comments

Write a comment

Comment; Identify w/ Social Media or Email

Subscribe

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

Thank you for subscribing.

Something went wrong.

Search

Categories