Home Resources Archived Articles Switching: Dynamic VLAN's, VQP, and VMPS
Switching: Dynamic VLAN's, VQP, and VMPS
Sunday, 10 October 1999 21:00

icon Switching: Dynamic VLAN's, VQP, and VMPS

Introduction

This article continues the series on LAN switching and Cisco Catalyst switches. This month we'll talk about dynamic VLAN's, and explain what VQP and VMPS are, as well as how they work and how to configure them.

Prior articles in the series:

What are VQP and VMPS

We talked in a prior article about configuring ports to belong to a VLAN. This is the static approach to VLAN's, where a port is always a member of a specific VLAN. You can also configure a port to dynamically determine what VLAN to belong to. Initially (and fundamentally) this process is tied to the MAC address of the end station on the port. Cisco is in the process of making this much more administrator-friendly (and useful!) by tying it into directory servers -- more on that later.

There is a process whereby a switch with a dynamic port can query a server with end station information to find out what VLAN the port should be in. The query is done via VQP, VLAN Query Protocol. The query goes to a VMPS, VLAN Membership Policy Server. The VMPS was initially a Catalyst 5xxx, but this is in the process of changing to where the server is perhaps a workstation running URT, User Response Tool, and eventually to perhaps a Windows 2000 Active Directory Server.

The following are capable of being VMPS servers right now: supervisor software release 2.3 or later on Catalyst 5000 and 2926G series switches. Many of the Cisco switches are capable of being VQP-using clients with dynamic VLAN's.

You can have several end stations on a dynamic port (using a hub), but they must all belong to the same dynamic VLAN. If there are more than 20 (29xx XL) to 50 (Catalyst 5xxx) end stations on a single port, the dynamic port will be shut down by the switch.

Configuring VMPS

Configuring VMPS is fairly simple, with only one minor surprise. (Troubleshooting it, however, may be a bit more complex).

Catalyst Set-Based Configuration

References: The basic command to start off with is
set vmps tftpserver ip-address [filename]
This tells the future VMPS server what TFTP server to get information from, and optionally what filename the information will be under. The default filename is vmps-config-database.1.

You then do a

set vmps state enable
(the alternative being disable), upon which the wannabe VMPS server will attempt to download the configuration database specified with the tftpserver command. If the TFTP download succeeds, then VMPS will become enabled. If the transfer fails, you'll get an error message and VMPS will remain disabled. The download/enable process also takes place when you reboot the switch.

You can force a download of new VMPS server information to a server with the command

download vmps
This also can be used to retry after a download fails.

To set up a set-based switch as a VQP client, you need to tell it who its VMPS server is. This is done with the command

set vmps server server-ip-address [primary]
You can do this up to three times, one primary and two backup VMPS servers. When the primary is down, it's status will be checked every five (5) minutes. When it is back up, queries will again be sent to the primary first.

For there to be any point to having a client, you need to use dynamic VLAN's. A port is made dynamic with the command

set port membership mod_num/port_num dynamic
and the status will show up in the show port command output. Use the command
reconfirm vmps
occasionally as enabled (privileged) user, if you wish to have the switch reconfirm all dynamic port VLAN assignments.

The design intent appears to be for there to be a VMPS server for local switches, say switches sharing a VTP domain. The point here is: you probably do not want to have to reach your VMPS server through a router, and if you do, it is the one Layer 3 switching hop to the server farm on a campus (more on this if I write a switched campus design article).

Other related commands:
 

clear vmps server This command deletes a VMPS server from the list of servers in the client switch.
clear vmps statistics This resets the VMPS statistics to zero. 
show vmps This command produces a summary of VMPS configuration and status information, including whether VMPS is enabled or disabled, which station the VMPS server might be, what the TFTPserver address is, and what the VMPS database filename is. 
show vmps mac This command (on the VMPS server) shows the MAC to VLAN mapping table (the database). It also shows the last requestor, which tells you which switch and switch port last had the end station in question attached to it, also whether the request succeeded or was denied. 
show vmps statistics This command displays VMPS-related statistics. It can be useful for troubleshooting, since it shows you VQP requests, denied requests, and also the MAC address of the end station associated with the last failed request.
show vmps vlan vlan-name On the VMPS server, this shows all MAC addresses for a VLAN in the VMPS configuration database. 
show vmps vlanports vlan-name On a Catalyst 5xxx switch, shows the ports associated with the specified VLAN name. 

 

 

 

 

Troubleshooting VMPS

Ways that VMPS can fail to start up:
  • Failure to configure TFTP server address
There's an error message to this effect, that shows up when you try to configure VMPS to be enabled. Do put the TFTP server address in!
  • Unable to contact TFTP server
When you enable VMPS, the switch might not be able to contact the TFTP server. Make sure the TFTP server is functioning (that is, it is up and running and that TFTP on it is working), then check routing and connectivity between the client switch and the TFTP server.
  • The configuration file isn't found on the TFTP server.
Check case and spelling of the name on both ends, switch and TFTP server.
  • Enable failure due to inadequate resources.
You're out of RAM on your switch, dude!
Ways VMPS/VQP and dynamic VLAN's can fail:
  • Client needs to see the attached endstation.
Check for link light, and check that the endstation is transmitting. (If it is not transmitting, the switch cannot learn its MAC address).
  • Client to server query.
The client and server need to be able to send IP UDP packets between each other. Test with ping. Since you're probably not doing this through a router, traceroute should be irrelevant.
  • Client needs to get a positive reply back.
If the client does not get a reply back, or if the reply that does come back is a denied response, then (see below) the client is placed in a default VLAN or the port is disabled. If you don't know this, you'll think there are link or switch port problems instead!

IOS-Based Configuration (2900 XL Series)

References: The IOS-based XL switches are currently VQP but not VMPS capable (nor does it appear VMPS functionality will be added to them, they're primarily edge switches).

To specify VMPS server, use the configuration command

    vmps server ipaddress [primary]
To check the effect of this, try
show vmps
To make an interface (port) dynamic instead of static, configure
interface fastethernet 0/1
switchport mode access
switchport access vlan dynamic
You can check this with
show interface interface switchport
To have the switch re-check the dynamic port VLAN assignments, use the EXEC mode command
vmps reconfirm
The default reconfirm interval is 60 minutes. The default number of retries on a VQP query are 3. You can configure these with
vmps reconfirm minutes
vmps retry number-of-retries

VMPS Configuration Database

Here is a sample of the VMPS configuration database file that a VMPS server might download from a TFTP server. Note that the syntax is not well documented. The file must start with the VMPS domain name, which must match the VTP domain (including case). Do NOT capitalize "vmps", the file contents are case-sensitive (and in at least some of the Cisco documentation I've seen, the Marketing Communications rewrite capitalized "vmps" as the name of the protocol/acronym).

The second line of the sample below specifies security mode, which can be either open or secure. In secure mode, an unknown MAC address causes the port to be shut down. In open mode, unknown MAC addresses are assigned to fallback (default) "unsecure" VLAN, specified with the vmps fallback line. The default mode is open. You can also specify whether requests with no VTP/VMPS domain are allowed or denied. By the way, when unknown MAC addresses or denied situations occur, the switch can send a SNMP trap to your SNMP trap receiver (management station). This might be useful for tracking use of unauthorized PC's in a campus environment (provided that's something you care to manage).

vmps domain mydomain
vmps mode open
! vmps mode { open | secure }
vmps fallback default
vmps no-domain-req deny
! vmps no-domain-req { allow | deny }
This section of the configuration database file is followed by the list of MAC addresses and VLAN names:
vmps-mac-addrs
!
address 0012.2233.4455 vlan-name Engineering
address 0012.3344.abcd vlan-name Engineering
address aaaa.bbbb.cccc vlan-name Accounting
address aaaa.bbbb.1111 vlan-name --NONE--
address aaaa.bbbb.2222 vlan-name SecureAccounting
Note that "--NONE--" is a way of excluding an untrusted MAC address: the VMPS server will send a denied response to any queries.

You can apparently specify what devices are allowed on what ports (I haven't tried this). Note that quotes are used when the name contains a space.

! vmps-port-group <group-name>
! device <device-id> { port <port-name> | all-ports }
!
vmps-port-group WiringCloset1
 device 172.16.1.1 port Fa1/3
 device 172.16.1.2 port Fa1/4
vmps-port-group "Executive Suite"
 device 172.16.10.1 port Fa0/1
 device 172.16.10.1 port Fa0/2
 device 172.16.10.10 all-ports
You can then create groups of VLAN (names) and then policies as to which VLAN's are allowed on which ports (using the above port-groups):
! vmps-vlan-group <group-name>
! vlan-name <vlan-name>
!
vmps-vlan-group Engineering
vlan-name hardware
vlan-name software
!
!vmps-port-policies {vlan-name <vlan_name> | vlan-group <group-name> }
! { port-group <group-name> | device <device-id> port <port-name> }
!
vmps-port-policies vlan-group Engineering
 port-group WiringCloset1
vmps-port-policies vlan-name Accounting
 device 172.16.10.1 port Fa0/3
vmps-port-policies vlan-name Management
 device 172.16.10.1 port Fa0/10
 port-group "Executive Suite"

CiscoWorks 2000 and VMPS

The User Tracking tool allows CW2000 to learn which users are on which ports in which VLAN's. This can be handy for troubleshooting, since not just MAC addresses but IP addresses can be picked up by the software (from ARP caches).

You can use the tool to then change multiple switch ports to dynamic status. You can also use it to save the MAC address information to TFTP server, and you can even trigger the VMPS server to download fresh MAC address table information.

Oh, and you can use CiscoView (and SNMP) to configure the VMPS servers and clients.  We do a demo of all this in the CEMS CiscoWorks 2000 course.

Wrap-Up

The question all of this leaves me with is, "how do you troubleshoot it when it breaks". That is, dynamic VLAN's are nifty. Having multiple VMPS servers means you probably won't have an entire campus down at one time. Nonetheless, VQP adds one more thing that can go wrong. Troubleshooting it has so far not been bad for me, but you do have to be careful with typos and do have to make sure you have a good scheme for managing and communicating with your switches (probably on VLAN 1).

I'm planning more switching topics for the next month or two. We may also sneak in a little design: you need to think about end-to-end VLAN's versus the "Layer 2 / Layer 3" hierarchical approach. See you in a month!

Dr. Peter J. Welcher (CCIE #1773, CCSI #94014) is a Senior Consultant with Chesapeake NetCraftsmen. NetCraftsmen is a high-end consulting firm and Cisco Premier Partner dedicated to quality consulting and knowledge transfer. NetCraftsmen has eleven CCIE's (4 of whom are double-CCIE's, R&S and Security). NetCraftsmen has expertise including large network high-availability routing/switching and design, VoIP, QoS, MPLS, network management, security, IP multicast, and other areas. See http://www.netcraftsmen.net for more information about NetCraftsmen. Pete's links start at http://www.netcraftsmen.net/about-us/bios/staff-articles-and-blogs/pete-welcher.html . New articles will be posted under the Articles link. Questions, suggestions for articles, etc. can be sent to This e-mail address is being protected from spambots. You need JavaScript enabled to view it .

10/10/99
Copyright (C)  1999,  Peter J. Welcher
 

Next Event

Resources

Articles and Blogs by Area



Advanced Search