CCNA 200-125 Lab: The Need For VTP

There are exceptions, but generally speaking, we want all switches in our network to know of all VLANs in the network – even when a particular switch doesn’t have a port placed in some VLANs.  If this doesn’t happen, we could run into a connectivity issue, as we’ll see using the following network.

VTP Network Topology

Show interface switchport verifies the hosts are both in VLAN 1, the default VLAN.  The switches had their configs totally erased before this lab started, so I’m not trying to pull any funny business on you. (I promise!)   We could use show vlan brief to verify the VLAN memberships as well.

SW1#show int switchport
  Name: Fa0/1
  Switchport: Enabled
  Administrative Mode: dynamic auto
  Operational Mode: static access
  Administrative Trunking Encapsulation: negotiate
  Operational Trunking Encapsulation: native
  Negotiation of Trunking: On
  Access Mode VLAN: 1 (default)

SW3#show int switchport
  Name: Fa0/3
  Switchport: Enabled
  Administrative Mode: dynamic auto
  Operational Mode: static access
  Administrative Trunking Encapsulation: negotiate
  Operational Trunking Encapsulation: native
  Negotiation of Trunking: On
  Access Mode VLAN: 1 (default)

Can the hosts ping each other?    Yes, they can!

HOST1#ping 10.1.1.3
 Sending 5, 100-byte ICMP Echos to 10.1.1.3,
 !!!!!

HOST3#ping 10.1.1.1
  Sending 5, 100-byte ICMP Echos to 10.1.1.1,
 !!!!!

Life brings changes, and right now those changes mean moving these hosts into VLAN 100. We’ll make the ports access ports while we’re at it.  (Reminder – access ports can belong to one and only one VLAN.)

SW1(config)#int fast 0/1
  SW1(config-if)#switchport mode access
  SW1(config-if)#switchport access vlan 100
  % Access VLAN does not exist. Creating vlan 100

SW3(config)#int fast 0/3
  SW3(config-if)#switchport mode access
  SW3(config-if)#switchport access vlan 100
  % Access VLAN does not exist. Creating vlan 100

Our new friend show interface switchport verifies the changes.

SW1#show int switchport
 Name: Fa0/1
  Switchport: Enabled
  Administrative Mode: static access
  Operational Mode: static access
  Administrative Trunking Encapsulation: negotiate
  Operational Trunking Encapsulation: native
  Negotiation of Trunking: Off
  Access Mode VLAN: 100 (VLAN0100)

SW3#show interface switchport
  Name: Fa0/3
  Switchport: Enabled
  Administrative Mode: static access
  Operational Mode: static access
  Administrative Trunking Encapsulation: negotiate
  Operational Trunking Encapsulation: native
  Negotiation of Trunking: Off
  Access Mode VLAN: 100 (VLAN0100)

Naturally, we’ll send a few pings to verify we still have the connectivity that we had just before the move to VLAN 100…

HOST1#ping 10.1.1.3
  Sending 5, 100-byte ICMP Echos to 10.1.1.3, timeout is 2 seconds:
  .....

HOST3#ping 10.1.1.1
  Sending 5, 100-byte ICMP Echos to 10.1.1.1, timeout is 2 seconds:
  .....

… and the pings that were successful a few minutes ago are now failing.  Why?  What happened?    When a problem like this pops up after a config change, it’s very likely the changes caused the problem.   (About a 99.9% chance, and that’s being conservative.)

We actually made two changes.  First, we made each port an access port, which means they belong to one and only one VLAN.  That really shouldn’t have caused any trouble.   The other change was putting the hosts into VLAN 100.  When we did that, we received this message on both SW1 and SW3:

% Access VLAN does not exist. Creating vlan 100

That’s great for SW1 and SW3, but does SW2 — the switch in the middle of the action — know about VLAN 100?   (I’ve edited VLANs 1002-1005 from this output.)

Show Vlan Brief on SW2

SW2 doesn’t know VLAN 100 exists, and since SW1 and SW3 are both connected to that switch but not to each other, that’s a problem!

The hosts could ping when both were in VLAN 1, since all three switches have VLAN 1 in their VLAN database by default.

VLAN 1 Pings Go Through

 

When a frame tagged for VLAN 100 arrives at SW2, that switch has no idea that VLAN even exists, so that frame will be dropped.

VLAN 100 frames are dropped.

We could certainly create VLAN 100 manually on SW2.  That would be easy to keep up with in a 3-switch network, but what about a 300-switch network?   Statically creating VLANs simply isn’t a scalable solution.  Additionally, the more manual configuration you have, the more time it takes and the larger the chances of manual misconfiguration.

When we place all three of these switches into the same VTP management domain (generally referred to simply as a “VTP domain”), they’ll exchange information about the VLANs they know about and all three switches will have a synched view of the VLANs on the network.  Our hosts in VLAN 100 can then communicate with no manual VLAN creation necessary on SW2.

We’ll create a VTP domain and get all three switches to join the new domain with one simple command — and on only one switch!  — in the next part of this CCNA tutorial on VTP. See you there!

Chris B.