Prior to release 7.3, wireless LAN (WLAN) controller software ran on
dedicated hardware you were expected to purchase. The Virtual Wireless LAN
Controller (vWLC) runs on general hardware under an industry standard
virtualization infrastructure. The vWLC is ideal for small and mid-size
deployments with a virtual infrastructure and require an on-premises
controller. Distributed branch environments can also benefit with a centralized
virtual controller with fewer branches required (up to 200).
vWLCs are not a replacement of shipping hardware controllers. The
function and features of the vWLC offer deployment advantages and benefits of
controller services where data centers with virtualization infrastructure exist
or are considered.
Advantages of the vWLC:
Flexibility in hardware selection based on your
Reduced cost, space requirements, and other overheads since multiple
boxes can be replaced with single hardware running multiple instances of
controllers, network management devices (NCS) and other servers (ISE, MSE, VSG
Independent and mutually exclusive instances allow administrators to
use multiple virtual controllers to manage different campuses (or even to
manage multiple customer sites) using the same hardware.
Enable features provided by the virtualization software, including
High Availability, failover protection, and ease of
VMware benefits with the vWLC:
vSphere: A virtualization infrastructure package
from VMware, which includes ESX/ESXi hypervisor, vMotion, DRS, HA, Fault
Tolerance, vSphere Distributed Switch, and more.
vCenter Server: The VMware vCenter Server (formerly
VMware VirtualCenter) provides a scalable and extensible platform that forms
the foundation for virtualization management:
Centralized control and visibility at every level of virtual
Pro-active management with vSphere
Scalable and extensible management platform with a broad partner
This list includes the unsupported features of WLC Release 184.108.40.206
and Release 220.127.116.11:
Data Datagram Transport Layer Security (DTLS)
OfficeExtend Access Point (OEAP) (no data DTLS)
Wireless Rate Limiting (bandwidth contract)
Internal DHCP Server
Note: FlexConnect local switched multicast traffic is bridged
transparently for both wired and wireless on the same VLAN. FlexConnect access
points do not limit traffic that is based on Internet Group Management Protocol
(IGMP) or Multicast Listener Discovery (MLD) snooping.
Access Points in Local Mode
Indoor Mesh Access Points
Outdoor Mesh Access Points (an Outdoor AP with FlexConnect mode will
Note: Outdoor APs such as AP1552 are supported in FlexConnect mode if the
APs are not used in a mesh deployment.
All 802.11n APs with required software version 7.3 are
APs will be operating in FlexConnect mode only.
AP autoconvert to FlexConnect is supported on
New APs ordered will ship with 7.3 software from
Existing APs must be upgraded to 7.3 software before joining a
Note: The Virtual Controller in release 7.3 uses Self Signed Certificates
(SSC) as against the Manufacturing Installed Certificates (MIC) in the
traditional controller. The AP will be able to validate the SSC certificate
provided by the virtual controller before joining. See
AP Considerations in the
Troubleshooting section for more details.
The information in this document is based on these software and
Cisco Catalyst Switch
Wireless LAN Controllers Virtual Appliance
Wireless LAN Controller 7.3 Software
Cisco Prime Infrastructure 1.2
802.11n Access Points in FlexConnect Mode
Wireless Client Laptop, Smartphone, and Tablets (Apple iOS, Android,
Windows, and Mac)
The information in this document was created from the devices in a
specific lab environment. All of the devices used in this document started with
a cleared (default) configuration. If your network is live, make sure that you
understand the potential impact of any command.
In order to properly implement and test the Cisco vWLC, a minimal
network setup is required, similar to the diagram shown in this section. You
need to simulate a location with a FlexConnect AP in a centrally switched
deployment, and/or with the addition of local and remote sites with local DHCP
(better if there is also a DNS and local access to
This section provides a sample configuration of the Cisco Catalyst
interface connection to the ESXi server for the virtual switch as trunk
interface. The management interface can be connected to an access port on the
Create two separate virtual switches in order to map to the virtual
controller Service and Data Port. Go to ESX >
Configuration > Networking, and click
Select Virtual Machine, and click
Create a vSwitch and assign a physical NIC in order to connect the
vWLC service port. The service port does not have to be connected to any part
of the network (typically disconnected/unused). As a result, any NIC (even
disconnected) can be used for this vSwitch.
Provide a label (in this example, vWLC Service
Select None (0) for VLAN ID as the service port is
typically an access port.
Here, you see vSwitch1 is created for vWLC Service Port. Click
Add Networking in order to repeat for the Data
For the new vSwitch, select the physical NIC(s) connected on a trunk
port if there are multiple NICs / portgroup assigned to an etherchannel on the
Add the NIC.
Provide a label (in this example, vWLC Data
For VLAN ID, select ALL(4095) since this is
connected to a switch trunk port.
Click Next until you complete the steps to add the
Promiscuous mode is a security policy which can be defined at the
virtual switch or portgroup level in vSphere ESX/ESXi. A virtual machine,
Service Console, or VMkernel network interface in a portgroup which allows the
use of promiscuous mode can see all network traffic traversing the virtual
By default, a guest operating system's virtual network adapter only
receives frames that are meant for it. Placing the guest's network adapter in
promiscuous mode causes it to receive all frames passed on the virtual switch
that are allowed under the VLAN policy for the associated portgroup. This can
be useful for intrusion detection monitoring or if a sniffer needs to analyze
all traffic on the network segment.
The vWLC Data Port requires the assigned vSwitch to accept Promiscuous
mode for proper operations.
Complete these steps:
Locate vSwitch2 (assigned for vWLC Data Port), and click
Select the VMNet assigned to the vWLC Data Port (note that the
default Security Promiscuous Mode is set to Reject), and click
In the Properties window, select the Security
Check the box for Promiscuous Mode, choose
Accept from the drop-down list, and click OK.
It is important to note that the MAC Address Changes and
Forged Transmissions fields are set to Accept
by default. You must revert these values to Accept if you
changed them from the default values.
Confirm the change, and click
The virtual controller software is posted as an .ovf package in the
Cisco software center. You can download the .ova/.ovf package and install to
any other virtual application. The software comes with a free 60-day evaluation
license. After the VM is started, the evaluation license can be activated and a
purchased license can be automatically installed and activated
Download the virtual controller OVA image to the local
Go to ESX > File >
Deploy OVF Template in order to start the
Browse to the location of the OVA file (downloaded from Cisco site),
and click Next.
Provide a name for the vWLC or accept the default, and click
Accept the default Thick Provision Lazy Zeroed
setting, and click Next.
Accept the Network Mapping default, and click
Confirm the Deployment settings, and click Finish in
order to begin installation.
Click Close when Deployment is
Two important things to note regarding upgrading virtual
The OVA image is needed only for first time
The .AES image can be subsequently used for
The console port gives access to the console prompt of the WLC. As a
result, the VM can be provisioned with serial ports in order to connect to
these. In the absence of serial ports, the vSphere Client Console is connected
to the console on the vWLC.
VMware ESXi supports a virtual serial console port that can be added to
the vWLC VM. The serial port can be accessed in one of these two ways:
Physical Serial Port on the Host: The vWLC’s virtual
serial port is mapped to the hardware serial port on the server. This option is
limited to the number of physical serial port(s) on the host. If in a
multi-tenant vWLC scenario, this may not be ideal.
Connect via Network: The vWLC’s virtual serial port
can be accessed using Telnet session from a remote machine to a specific port
allocated for the VM on hypervisor. For example, if the hypervisor’s IP address
is 10.10.10.10 and the port allocated for a vWLC VM is 9090, using "telnet
10.10.10.10 9090", just like accessing a physical WLC’s console using a Cisco
terminal server, the vWLC’s serial console can be
Complete these steps:
On the vWLC Hardware tab, click
On the vWLC Hardware tab, click
In this example, choose Connect via Network, and
Go to Select Network Backing:
For Network Backing, choose Server (VM listens for
For Port URI, enter
telnet://<host>:<port> (for example,
Click Next in order to review the Options, and click
Click OK in order to complete the configured
In order to enable for the serial via network, ESX must be configured
to allow for such requests.
Navigate to the ESX, click the Configuration tab, go
to Software > Security Profile, and click
In the Firewall Properties window, select VM
serial port connected to vSPC, and click
Start the vWLC, and select the console in order to observe the
first-time installation process.
Monitor the progress until the VM console shows that the vWLC has
restarted (this is automatic).
Open a Telnet session to the vWLC as shown
The Telnet session will now manage the console to the
Note: Only one mode of console can be operational at any time, such as a
VM console (by key-interrupt at startup) or serial console (physical/network).
It is not possible to maintain both at the same time.
Continue to wait until the vWLC has come online fully and prompts you
to start the configuration tool wizard.
Configure the management interface address / mask / gateway.
Configure Management Interface VLAN ID if tagged. Continue with the
Similar to all network device(s), configuring the NTP is crucial. The
virtual controller must have the correct clock as it is possible to have an
incorrect clock on the ESX host, or from manual configuration, which may result
in APs not joining in the process.
Complete the configuration and allow the vWLC to
It is suggested that you ping the vWLC management interface in order
to ensure that it has come online. Log in to the
You can issue the show interface summary
command and ping the gateway from the vWLC.
Connect to vWLC management using a web
Initially, there are 0 (zero) Access Points Supported. Enable the
evaluation license in order to allow the AP to
Go to Management > Software
Activation > Licenses. Select
base-ap-count, and set the Priority to
Click OK, and Accept the EULA in
order to continue.
Click OK, and reset the vWLC in order for the
evaluation license to take effect.
Reboot the vWLC.
Log back in to the vWLC, and note that the 200 APs are now supported
with the evaluation license enabled.
Connect an AP, and monitor for the join message to
From the browser, go to WIRELESS and confirm that
the AP has joined.
Click the AP, and change the AP Mode to FlexConnect.
Only FlexConnect is supported (central and local switching) in the 7.3
It may be useful to consider using the autoconvert function of the
controller (for example, any mode AP joining the vWLC will be converted
automatically to FlexConnect). Issue this command in order to implement:
(Cisco Controller) > config ap autoconvert flexconnect enable
Cisco Prime Infrastructure version 1.2 is the minimum release required
to centrally manage one or more Cisco Virtual Controller(s). Management for the
Cisco Virtual Controller is no different than legacy physical controllers in
comparison to Cisco WCS or NCS. Cisco Prime Infrastructure 1.2 provides
configuration, software management, monitoring, reporting, and troubleshooting
of virtual controllers. Refer to Cisco Prime Infrastructure documentation as
required for administrative and management support.
Log in to Cisco Prime Infrastructure server as root.
By default, the management view selection is Lifecycle Theme, which is new
beginning with release version 1.2. The Classic Theme (shown later) will be
more familiar to administrators who have been working in Cisco WCS and
Go to Operate > Device Work
In Device Work Center, click Add
Enter the IP Address and SNMP Community string (Read/Write). By
default, the SNMP RW for the controller is Private. Click
Cisco Prime Infrastructure will discover and synchronize with the
virtual controller. Click refresh in order to update the
When the virtual controller is discovered, it is listed as Managed
and Reachable (shown in green). Add any other virtual controller(s) at this
point, if available.
The new controller will be listed in Device Type
> Cisco VIRTUAL Series Wireless LAN
Navigate to Home for a Summary view (in Lifecycle Theme) of the
devices being managed.
For the remainder of this guide, the Classic Theme is used to perform
similar task of adding the virtual controller, as well as updating the system
image. Go to and select Switch to Classic
Go to Configure >
In order to add a new virtual controller, select Add
Controllers... from the Select a command drop-down
Enter the IP Address, Read/Write SNMP Community string, and click
Cisco Prime Infrastructure will display this
Go to Configure > Controllers.
The virtual controller will be listed as Reachable once it has been
successfully discovered and added. Otherwise, and as shown above, the device
will appear in the Unknown Device page if it was not discovered
In the early steps of installation, the Cisco Virtual Controller
initially required an OVA file for new virtual appliance creation. However,
maintaining virtual controller features and software upgrades require a common
AES file downloadable from the Cisco website.
Complete these steps:
Download the AS*7_3*aes file to a target host (for example, the
Just as for legacy controllers, go to the web GUI of the controller
> COMMANDS > Download File. Select the
File Type, Transfer Mode, IP Address, File Path, and File Name (.aes file).
Click Download in order to start the
When the process has completed successfully, you are prompted to
Reboot in order for the new software image to take effect. Click the link to
the Reboot Page in order to continue.
Click Save and Reboot.
Cisco Prime Infrastructure can also be useful for upgrading one
virtual controller or many virtual controllers at the same time. Go to
Configure > Controllers. Select (check
box) one or more virtual controllers. Select Download Software
(TFTP) from the command drop-down list. This example uses TFTP mode
for image upgrade.
Provide the Download Type, TFTP server (new if using external), IP
Address, File Path, and Server File Name (which is the .aes file type). Click
This screen is an example of the AES image being transferred to the
Cisco Prime Infrastructure will update the status until the software
has transferred successfully.
Similar to the experience directly from the controller, a reboot is
required when the transfer is complete. In Cisco Prime Infrastructure, go to
Configure > Controllers, and select the
virtual controller(s). Select Reboot Controllers from the
Select a command... drop-down list.
Cisco Prime Infrastructure will prompt for reboot parameters such as
save configuration, and so forth. Click
Cisco Prime Infrastructure will notify the administrator that the
virtual controllers are being rebooted.
When complete, Cisco Prime Infrastructure will provide the results of
Known Issue: AP(s) not joining vWLC - The AP must get the hash entry
from a legacy controller before it joins a vWLC.
An AP must be at software version 18.104.22.168 and above to successfully
join a virtual controller. Virtual controllers use SSC in order to validate an
AP before joining.
An AP at version 7.3 can validate the SSC certificate provided by the
After successful certificate validation, an AP will check the hash
key of the virtual controller in the list of stored keys in flash. If it
matches the stored hash, validation is passed and the AP moves to the RUN
state. If hash validation fails, it will disconnect from the controller and
restart the discovery process.
The hash validation, which is an extra authorization step, will be
performed only if the AP is joining a virtual controller. There will be a knob
to turn on/off hash key validation.
By default, hash validation is enabled, which means that the AP needs
to have the virtual controller hash key in its flash before it can successfully
complete association with the virtual controller. If the knob is turned off,
the AP will bypass the hash validation and move directly to the RUN
The hash key can be configured in the controller mobility
configurations, which gets pushed to all the APs which are joined. The AP will
save this configuration until it successfully associates to another controller.
After which, it inherits the hash key configuration from the new
Typically, APs can join a traditional controller, download the hash
keys, and then join a virtual controller. However, if it is joined to a
traditional controller, the hash validation knob can be turned off and it can
join any virtual controller. The administrator can decide to keep the knob on
This information is captured in Cisco bug ID CSCua55382.
If the AP does not have any hash key in its flash, it will bypass the
hash validation, assuming that it is a first time installation.
In this case, the hash validation is bypassed irrespective of
whether the hash validation knob is on/off.
Once it successfully joins the controller, it will inherit the
mobility group member hash configuration (if configured in the controller).
After which, it can join a virtual controller only if it has a hash key entry
in its database.
Clearing the AP configuration from the controller or on the AP
console will result in the erasing of all the hash keys. After which, the AP
joins the virtual controller as if it is a first time installation.
At initial install, it is possible that the time may be skewed or not
properly synced. As a result, the AP may not be able to join properly. In this
instance, check the SSC validity time stamp in order to ensure that it is
correct. NTP is always recommended going forward.
The AP is a new AP with 7.3 and does NOT have hash can join virtual
ap#show capwap client config
The AP may have an older SSC hash, either from an old installation or
joining other controllers. It is possible to configure the WLC to not validate
SSC, allow APs to join the vWLC, then re-enabling the validation again.
Perform the test capwap
<erase/restart> command in order to
clear AP capwap settings and initiate join process.
APf866.f267.67af#test capwap erase
APf866.f267.67af#test capwap restart
*Jun 9 12:27:22.469: %DTLS-5-SEND_ALERT: Send FATAL : Close notify Alert to
*Jun 9 12:27:22.525: %WIDS-6-DISABLED: IDS Signature is removed and disabled.
*Jun 9 12:27:22.529: %LWAPP-3-CLIENTERRORLOG: LWAPP LED Init: incorrect led
*Jun 9 12:27:22.897: Starting Ethernet promiscuous mode
*Jun 9 12:27:32.903: %CAPWAP-3-ERRORLOG: Go join a capwap controller
*Jun 9 12:27:23.000: %CAPWAP-5-DTLSREQSEND: DTLS connection request sent
peer_ip: 10.10.11.20 peer_port: 5246
*Jun 9 12:27:23.276: %CAPWAP-5-DTLSREQSUCC: DTLS connection created
successfully peer_ip: 10.10.11.20 peer_port: 5246
*Jun 9 12:27:23.276: %CAPWAP-5-SENDJOIN: sending Join Request to 10.10.11.20
As part of the mobility configuration, if there is a virtual
controller in the network, the administrator needs to add a hash key of the
virtual controller in all the peer controllers. If adding another peer
controller, the consideration is to add the hash (shown in the SSC output
above) to the mobility group member.
(Cisco Controller) >config mobility group member add 10.10.11.30
(Cisco Controller) >config mobility group member hash 10.10.11.30