Answers for Last Week’s VLAN Lab, Plus a New Challenge

Analysis
Oct 4, 20106 mins

Can One Change Make VTP a Viable Option?

Last week’s lab puzzle required that you configure a network based on some requirements, with as few config mode commands as possible. We ended up with two challenges from last week’s post: the original lab, plus a variation that required VLAN trunking. The fewest commands I can use for each are 5 and 9,l respectively.  Today I’ll spell those out, but I’ll start with a slightly new set of requirements, so you can have one more lab puzzle to ponder.

If you’re not done so already, read last week’s post, and at least my one comment titled “Variation 1:…”.

First, consider the following as a new challenge. (I’m starting with the new challenge so you can ignore the rest of this post until you work on this new challenge, so the explanations in today’s post don’t spoil your fun.) The next challenge, which I’ll reference as variation 2, uses the same baseline requirements as last week’s lab, except:

  • You must make the 2 switch-to-switch links do VLAN trunking
  • If they use VTP, the switches must not use a VTP password

My best config so far with these requirements is 8 config mode commands. Feel free to post your best number, your config ideas, etc, with a spoiler alert as necessary. And I’ll list a few hints related to defaults at the very end of this post.

The rest of today’s post spells out answers and explanations from last week’s post. If you have questions on the why/wherefore’s in here, post away!

Baseline Lab:

In my original post last week, we used the following figure, with basically three main requirements:

  • Broadcasts sent by PC1 must travel in VLAN 2, arrive at PC2, but not arrive at SW3
  • All switches must know about VLAN 2
  • If you use VTP, you must use password=fred
  • All config must be complete, and only then can the cables be connected

To be honest, I was assuming folks would enable trunking, but I didn’t require trunking, and that leaves an opening for a shorter config, as follows:

SW1:

interface range F0/11, G0/1
  switchport access vlan 2

SW2:

interface range F0/11, G0/2
  switchport access vlan 2

SW3:

vlan 2

This short config uses one more obvious and one less obvious method to reduce the literal number of commands. First, the interface range command lets you use one command to tell the switch to add the upcoming interface subcommands to more than one switch port. In this case, “switchport access vlan 2” was added to 2 interfaces on both SW2, rather than requiring 2 separate interface commands on each switch.

The less obvious way to reduce the number of commands is to take advantage of the fact that the “switchport access VLAN x” command, when listing a VLAN unknown to the switch, causes the switch to add the VLAN to its config – assuming the switch is either a VTP server (default) or VTP transparent mode switch. So, SW1 and SW2 add a “vlan 2” command as a side-effect of the “switcport access vlan 2” command on each switch. On SW3, which simply needs to know about VLAN 2 to meet the original requirements, a simple “vlan 2” global command is all that’s required.

Finally, analyzing the end result of this config, when PC1 broadcasts, SW1 forwards the frame in VLAN 2. The SW1-SW2 link is in VLAN 2, so the frame goes to VLAN2. SW2 doesn’t forward the broadcast to SW3, because SW2’s G0/1 interface is still (by default) in VLAN 1. Note that the lab assumes 2960 switches, with a default of “switchport trunk dynamic auto”, which means these switches won’t form a trunk without some configuration.

Lab Variation 1:

With this variation, I added the requirement that the switch-to-switch links trunk, which means you can’t just make the SW1-SW2 link be in VLAN 2. In this case, to get the minimum number of config commands that I could think of, you still need to use the “interface range” command, and to rely on the switches to create VLAN 2 when you issue the “switchport access vlan 2” command. Additionally, you must also stop the VLAN 2 broadcasts from getting to SW3.

First, for the trunking, only one end of the trunk need be configured. By changing one end to use dynamic desirable mode (“switchport mode dynamic desirable”), or to always trunk (“switchport mode trunk”), the other end will negotiate to use trunking, so both switches on the ends will trunk.

The second additional item to configure once trunking will work is to limit SW2 so that it won’t forward a broadcast in VLAN 2 over the trunk to SW3. When I added that requirement, I was hoping to tempt folks to enable VTP, so that you could use VTP pruning, which would dynamically prevent these broadcasts. However, the overarching goal of fewest commands leads us to simply remove VLAN 2 from the allowed VLAN list on the SW2-SW3 trunk. It only needs to be removed on the SW2 side, although in real life, it make sense to remove the VLAN from both ends of the trunk. By removing VLAN 2 from the allowed VLAN list, SW2 won’t forward any VLAN 2 frames out the SW2-SW3 trunk.

The following shows the completed configuration, with a total of 9 config mode commands:

SW1:

interface F0/11
 switchport access vlan 2

SW2:

interface F0/11
 switchport access vlan 2

interface range G0/1,G0/2
 switchport trunk dynamic desirable

interface G0/1
 switchport trunk allowed vlan remove 2

SW3:

vlan 2

That’s it! Click over to the next page if you want to see a few hints about the new challenge outlined near the top of today’s post.

Hints for this week’s lab puzzle:

  • VTP defaults to server mode, with a null domain name, and no password.
  • A switch with default settings can learn the domain name, and start doing VTP, if the neighboring switch sends a VTP update with a domain name, and no password.