Lead Image © bluedarkat, 123RF.com

Lead Image © bluedarkat, 123RF.com

VTP for VLAN management

Mod Comms

Article from ADMIN 47/2018
Cisco's VLAN Trunking Protocol for Virtual LAN management in medium to large computer networks can make a network administrator's life easier.

Virtual LANs (VLANs) are used widely in modern network infrastructures. A VLAN can divide a physical LAN into small pieces of virtual LAN to contain broadcast traffic in a limited, reasonable range. In technical terms, it breaks the network into different broadcast domains.

All hosts in a switched network are required to listen and supply resources to process broadcast messages, even when they are not the target. Decreasing the frequency of broadcast messages by breaking the network into domains can avoid wasting host CPU power. Also, limiting the broadcast can prevent switches from wasting bandwidth to forward messages to unnecessary ports. Finally, because hosts in different VLANs cannot communicate with each other directly, VLAN can also provide security.

A host can be assigned to any VLAN regardless of geographic location, as long as the switches are connected by trunk links. VLANs need to be created on all switches on the path through which VLAN traffic passes. For example, in Figure 1 (see also Listing 1 for the configuration commands), VLAN20 needs to be created on SW1 and SW2 for red hosts to communicate, whereas VLAN 30 must be on SW2 and SW3 for the blue hosts to communicate. If you want the green hosts to communicate, all three switches would need VLAN10.

Listing 1

VLAN Configuration Commands

SW1(config)#vlan 10
SW1(config-vlan)#name Accounting_Dept
SW1(config-vlan)#vlan 20
SW1(config-vlan)#name IT_Dept
SW2(config)#vlan 10
SW2(config-vlan)#name Accounting_Dept
SW2(config-vlan)#vlan 20
SW2(config-vlan)#name IT_Dept
SW2(config-vlan)#vlan 30
SW2(config-vlan)#name Marketing_Dept
SW3(config-vlan)#vlan 10
SW3(config-vlan)#name Accounting_Dept
SW3(config-vlan)#vlan 30
SW3(config-vlan)#name Marketing_Dept
Figure 1: A VLAN can be distributed on any switch across the entire network.

After VLAN configuration, the

show vlan

command verifies the settings (Listing 2). The VLAN information shown in the listing is also called the VLAN database. Besides the three VLANs that were just added manually, VLANs 1002 to 1005 are reserved for system usage. VLAN1 is the default VLAN, to which all ports are assigned if no configuration is made.

Listing 2

show vlan

SW2#show vlan
VLAN Name                             Status    Ports
---- -------------------------------- --------- -----------------------------
1    default                           active   Fa0/1, Fa0/2, Fa0/3, Fa0/4,
                                                Fa0/5, Fa0/6, Fa0/7, Fa0/8,
                                                Fa0/9, Fa0/10, Fa0/11, Fa0/12
10   Accounting_Dept                   active
20   IT_Dept                           active
30   Marketing_Dept                    active
1002 fddi-default                      active
1003 token-ring-default                active
1004 fddinet-default                   active
1005 trnet-default                     active
<--Output Omitted-->

By default, only VLAN2 to VLAN1001 are available for custom use. The VLAN configuration is stored in a file named vlan.dat located in flash memory (Listing 3) instead of in the running configuration file (unless you are using transparent mode or off mode , which I address in a later section). Even if the running configuration file is erased, the VLAN information exists until you delete the vlan.dat file.

Listing 3

Flash Memory Content

SW2>show flash
Directory of flash:/
    1  -rw-     4414921         Aug 22 2017 00:00:02  c2960-lanbase-mz.122-25.FX.bin
    2  -rw-         736         Aug 22 2017 10:53:02 vlan.dat
64016384 bytes total (59600727 bytes free)

If you assign ports to the correct VLAN, everything should be fine. I only show the command lines for SW1, because they are similar on SW2 and SW3:

SW1(config)#int fastEthernet 0/1
SW1(config-if)#switchport access vlan 10
SW1(config)#int fastEthernet 0/2
SW1(config-if)#switchport access vlan 20

Imagine you have more than 100 switches in your network. Every time a new VLAN is created, you will need to find the path through which VLAN traffic passes, so you can create the VLAN in the right switches. You also need to consider redundant paths, because the topology might change from time to time. This scenario is definitely a nightmare. Practically, VLANs are created on all switches to make sure they all can forward the traffic.

VTP Basic Configuration

Logging in to every switch individually to create or remove a VLAN is not fun. The VLAN Trunking Protocol (VTP) helps simplify such a boring and repetitive job. With VTP, you only need to manage the VLAN database at the VTP server; then, the VTP server propagates the VLAN information to all other VTP switches in the same VTP domain by using VTP update messages. For security reasons, the VTP password is also needed for a switch to join a VTP domain if a password has been set. The basic VTP configuration shown in Listing 4 should be placed on all switches in the same VTP domain.

Listing 4

VTP Configuration

SW1(config)#vtp domain admin
Changing VTP domain name from NULL to admin
SW1(config)#vtp password magazine
Setting device VLAN database password to magazine

VTPs have four operating modes – server, client, transparent, and off – each of which behaves differently with local VLAN database modifications and VTP update messages. Table 1 summarizes the operating modes.

Table 1

VTP Operating Modes

  Server Client Transparent Off Mode*
Local VLAN configuration allowed? Yes No Yes Yes
VTP updates generated? Yes Yes No No
VTP updates forwarded? Yes Yes Yes No
Own VLAN database synchronized with VTP updates? Yes Yes No No
*Only version 3 supports VTP off mode.

Server Mode

The default VTP operating mode is server mode, which allows VLAN database modification. It also advertises the most recent VLAN information to other switches. In Figure 2, SW4 is a VTP server. When the local VLAN database has changed, it sends VTP updates to its neighbors. For redundancy, you may have two or more VTP servers in a domain. If a server receives a VTP update, it compares the configuration revision number of the update message and its own VLAN database revision number. If the received revision number is larger, it accepts and updates its own database. The operating mode and configuration revision number can be verified with the

show vtp status
Figure 2: SW1 to SW6 are in the same VTP domain but have different VTP operational modes.

command (Listing 5).

Listing 5

show vtp status

SW4#show vtp status
VTP Version : 2
Configuration Revision : 6
Maximum VLANs supported locally : 255
Number of existing VLANs : 8
VTP Operating Mode : Server
VTP Domain Name : admin
VTP Pruning Mode : Disabled
VTP V2 Mode : Disabled
VTP Traps Generation : Disabled
MD5 digest : 0xFC 0xCB 0xFA 0x57 0x4D 0x07 0x6E 0xA1

Client Mode

To change a switch to client mode, use the

vtp mode client

command. While VTP is working in client mode, VLAN modification is not allowed. A warning message is displayed when modifying a VLAN database locally in client mode:

SW2(config)#vtp mode client
Setting device to VTP CLIENT mode.
SW2(config)#vlan 50
VTP VLAN configuration not allowed when device is in CLIENT mode.

The switch will receive and check the revision number of the VTP update. As in server mode, client mode updates its own database only if the configuration revision number is larger than its own. You might be surprised to learn that a client also can generate a VTP update to other switches, just like a server. According to Cisco documentation [1], the only difference between a server and a client is the ability to modify the VLAN database locally. In Figure 2, SW3 is a VTP client. It receives VTP update messages from SW4, accepts and updates its database, and propagates the VTP update to SW2.

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy ADMIN Magazine

Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

  • Segmenting networks with VLANs
    Network virtualization takes very different approaches at the software and hardware levels to divide or group network resources into logical units independent of the physical layer. It is typically a matter of implementing secure strategies. We show the technical underpinnings of VLANs.
  • OpenStack installation with the Packstack installer
    At first sight, an OpenStack installation might seem like rocket science, but you can launch a fully functional cloud environment with minimal effort in a relatively short time with the Packstack automation tool.
  • Virtual switching with Open vSwitch
    Virtualization with Vmware, KVM, and Xen is here to stay. But up to now, no virtual switch has supported complex scenarios. Open vSwitch supports flows, VLANS, trunking, and port aggregation just like major league switches.
  • Virtual networks with Hyper-V in Windows Server 2016
    Microsoft provides some interesting virtualization features in current and future versions of Windows Server. You can connect or isolate virtual machines, and Windows Server 2016 even supports virtual switches.
  • Affordable hardware switch for SDN
    Most OpenFlow-ready hardware switches are prohibitively expensive if you just want to set up a small-scale test lab. Northbound Networks has stepped in with a Kickstarter campaign, filling the gap with the Zodiac FX switch.
comments powered by Disqus