Some of these topics are pretty basic, so there’s not much to say about them that hasn’t been said a million times. So I’m only going to call the sections out if there’s something I want to explicitly remember, or if there’s some obscure configuration that could pop up in the lab.
1.1.c i Access ports
The only thing I can think of here is the minimal keystrokes to enable an access port:
conf t
int g1/0/13
sw m a
sw ac v 10
1.1.c ii Trunk ports (802.1Q)
I just want to call out DTP and how to disable it.
conf t
interface gig 1/0/1
switchport nonegotiate
That tells the port to only work as a trunk port with a peer that’s configured explicitly as a trunk. Network automation is great when we’re doing SDA, etc. But let’s just stick to statically configuring our ports as access or trunk for now.
Also, minimum keystrokes to set an interface up as a trunk:
conf t
int g1/0/1
sw t e d
sw m t
1.1.c iii Native VLAN
I could imagine a native VLAN mismatch coming up on the lab and causing grief.
We can check the native vlan with show interface name trunk.
One other thing to call out here is if we want to tag our native vlan.
conf t
vlan dot1q tag native
If we’re tagging native VLANs on both sides of the link we’ll be able to ping VLAN interfaces, even if the native VLAN is mismatched. We’ll still get the error every couple seconds about the native vlan mismatch, but at least we’ll have connectivity.
1.1.c iv Manual VLAN pruning
For manual VLAN pruning, we just want to prevent unnecessary broadcasts to switches where we know a specific VLAN doesn’t exist. We can either explicitly state the VLANs to allow, or allow all except certain vlans.
conf t
int g1/0/1
swi trunk allowed vlan 101-103,105
OR
switchport trunk allowed vlan except 100,103-400,402
1.1.c v VLAN database
1.1.c vi Normal range and extended range VLANs
1.1.c vii Voice VLAN
1.1.c viii VTP
For VTP we’ll probably have to make sure we understand the modes based on their description. A task can ask us to “ensure Switch2 passes VLAN updates to neighbors, but they do not modify the local VLANs.”
Server: The server switch can create, modify, and delete VLANs within the VTP domain.
Client: Receives VTP advertisements and modifies the VLANs on that switch accordingly. Local configuration of VLANs isn’t allowed.
Transparent: VLANs are configured locally. VTP advertisements are passed on between neighboring switches, but don’t modify this transparent switch’s local VLAN database.
Off: Doesn’t send or forward VTP advertisements. VLANs are configured locally.
VTP Versions
We should really only be dealing with Version 3 at this point, which covers the full range of VLANs (1-4094). We can have multiple servers in a VTP domain, so we need to make sure we know how to set a primary VTP server (note it’s under Enable mode, not Config T):
enable
vtp primary
VTP Updates
The multicast VTP updates fall into three categories:
Summary: Every 300 seconds, or when there’s a change. Includes revision number, timestamp, domain, and VTP version.
Subset: Triggered by a VLAN configuration change. Includes the info to update the corresponding VLANs.
Client Requests: If a client notices it has a lower revision number, it can request a detailed Subset update.
VTP VLAN Configuration
We just configure the domain, the version number, the mode, and the password. We’re going to assume that the lab will ask us to configure a password, even though it’s optional. The only trick is the sequence, you can’t do vtp primary until you do the version, and you can’t do the version until you do the domain.
Switch1:
conf t
vtp domain oscorplabs.com
vtp version 3
vtp password C!sco123
vtp mode server
exit
vtp primary
Switch2:
conf t
vtp domain oscorplabs.com
vtp version 3
vtp password C!sco123
vtp mode client
VTP MST Configuration
Let’s get a little crazy here. Let’s set up one of the VTP clients (client for VLANs) as the MST primary server. Then we’ll set up a couple MST instances on that one box and have them pushed out automatically via VTP.
Switch 1 is currently using standard PVST.
Let’s make two quick changes on SW1:
conf t
spanning-tree mode mst
vtp mode client mst
Let’s make SW4 the VTP MST primary server:
conf t
spanning-tree mode mst
spanning-tree configuration
instance 10 vlan 10
end
vtp primary mst
Then we’ll do a show run | sec spanning-tree on SW1.
Then we’ll add a couple more instance commands on SW4, the MST primary. Now let’s check SW1 again.
Let’s look at the VTP status on SW1.
There are a couple interesting things to note here. The VTP MST has nothing to do with VTP VLANs. VTP is just the method of sending configuration updates automatically to peers (clients). To prove this point, I set up SW4 as a VTP VLAN Client, and a VTP MST Server. SW4 is in charge of updating MST instance information, but still can’t make any local VLAN changes.
Oscorp Labs 