Guest

Cisco Services Modules

Cisco WiSM in a Cisco Virtual Switching System Environment

Document ID: 109494

Updated: Feb 03, 2009

   Print

Introduction

This document explains how to integrate the Cisco WiSM with the Cisco Virtual Switching System (VSS).

Prerequisites

Requirements

This feature relies on an understanding of VSS concepts. Therefore it is highly recommended to review the relevant materials before you read this document. There is a brief description of VSS in this paper, but it is not meant to be a comprehensive explanation of it.

Refer to the Understanding Virtual Switching Systems section of Catalyst 6500 Release 12.2SXH and Later Software Configuration Guide for more information on VSS.

Components Used

The information in this document is based on these software and hardware versions:

  • Minimum Software Release: Supervisor 720 release 12.2(33) SXI and above

  • Cisco WiSM Software 4.2.130.0 or later

It is possible to support a maximum of five Cisco WiSM blades in a single chassis in VSS mode.

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.

Conventions

Refer to Cisco Technical Tips Conventions for more information on document conventions.

Background Information

The Virtual Switching System is a new and innovative feature on Cisco Catalyst 6500 series switches that effectively allows clustering of two physical chassis together into a single logical entity. Such a technology allows for new enhancements in all areas of enterprise campus and data center deployment, which includes High Availability, Scalability/performance, Management and Maintenance. Service module support is a key requirement in order to position the VSS in the enterprise campus and enterprise data center market. The first release of the VSS included support for the Network Access Module (NAM) service module. The list of service modules that are supported in the second release of the Virtual Switch System are:

  • the FireWall Service Module (FWSM)

  • the Intrusion Detection Service Module (IDSM)

  • the Application Control Engine (ACE) service module

  • the Wireless Service Module (WiSM)

wism-vss-integration-1.gif

This document only focuses on the VSS and Cisco WiSM integration. The first release of VSS and Cisco WiSM integration is supported on Cisco WiSM software release 4.2.130.0 and later along with Cisco IOS Software Release 12.2(33)SXI IOS.

The next few paragraphs describes how the integration and deployment of Cisco WiSM in VSS environment is done seamlessly and does not require special configuration. Only minor changes are required on the cat6500 side, and these are very much contained within the changes that are inherent to the VSS model of Cisco IOS.

Overview of Cisco WiSM integration

The Cisco WiSM is a member of the Cisco wireless LAN controller family. It works in conjunction with Cisco Aironet lightweight access points, the Cisco WCS, and the Cisco wireless location appliance to deliver a secure and unified wireless solution that supports wireless data, voice, and video applications. The Cisco WiSM consists of two Cisco 4404 controllers. Therefore, the IT staff must be aware that two separate controllers exist on a single module.

The first controller is considered the WiSM-A card, while the second controller is considered the WiSM-B card. Interfaces and IP addressing have to be considered on both cards independently.

WiSM-A manages 150 access points, while WiSM-B manages a separate lot of 150 access points. These controllers can be grouped together in a mobility group, forming a cluster.

wism-vss-integration-2.gif

Overview of VSS and Cisco WiSM

Current implementation of VSS allows you to merge two physical Cisco Catalyst 6500 series switches together into a single logically-managed entity. Figure provides a graphical representation of this concept where two 6509 chassis can be managed as a single 18-slot chassis once VSS is enabled.

wism-vss-integration-3.gif

The key enabler of the VSS technology is a special link that binds the two chassis together, called a Virtual Switch Link (VSL). VSL carries special control information as well as encapsulates every frame with a header that passes across this link. The Virtual Switching System concept allows for the combination of two switches into a single logical network entity from the network control plane and management perspective. To the neighboring devices, the VSS appears as a single logical switch or router. Within the VSS, one chassis is designated as the Virtual Switch Active and the other is designated as the Virtual Switch Standby. All control plane functions, such as Management (SNMP, Telnet, SSH, etc.), Layer 2 Protocols (BPDUs, PDUs, LACP, etc.), Layer 3 Protocols (Routing Protocols, etc.), and Software Data path, are centrally managed by the Active Supervisor of the Active Virtual Switch chassis. The supervisor on the Virtual Switch Active is also responsible for programming the hardware forwarding information onto all the Distributed Forwarding Cards (DFCs) across the entire VSS as well as the Policy Feature Card (PFC) on the Virtual Switch Standby supervisor. From a data plane and traffic forwarding perspective, both switches in the Virtual Switching System actively forward traffic. The PFC on the Virtual Switch Active supervisor performs central forwarding lookups for all traffic that ingresses the Virtual Switch Active, whereas the PFC on the Virtual Switch Standby supervisor performs central forwarding lookups for all traffic that ingresses the Virtual Switch Standby. The FWSM integration with VSS is aimed to behave similarly to availability of the service module as if both chassis are a single logical chassis. Therefore the user can access and activate the modules in either chassis in standalone mode as well as failover mode.

Refer to the Understanding Virtual Switching Systems section of Catalyst 6500 Release 12.2SXH and Later Software Configuration Guide for more information on VSS.

Refer to Integrate Cisco Service Modules with Cisco Catalyst 6500 Virtual Switching System 1440 for more information on the architecture and workflow of VSS and WiSM.

Like the other service modules, the Cisco WiSM can be placed in either of the two switches that make up the Virtual Switch. In instances where WiSM services are required, Cisco recommends that the you install at least one Cisco WiSM module per switch.

Control Path or OBC protocol

The communication between the WiSM module and the supervisor happens through the Wireless Control Protocol (WCP). This is UDP based and uses an internal management wireless VLAN. Information such as the slot number of the WiSM module and the IP addresses of the controllers are exchanged through WCP. Since WCP is UDP based it works seamlessly in the virtual switch environment.

HA

In standalone 6k, when the supervisors go through a Stateful Switchover (SSO) switchover, the WiSM line cards are kept intact and packet forwarding resumes in two seconds. Cisco WiSM continues to operate as usual if a SSO switchover occur.

For the first release of the Virtual Switch, the SSO is in between the two switches. Hence if there is a Cisco WiSM module on the standby switch, packet forwarding can continue during the SSO switchover since the data plane of the standby switch is already fully functional and forwarding.

The controllers use the existing clustering of APs to handle controller failures. In essence, the APs join another controller when one fails. The APs leverage the existing LWAPP Discovery and Join process to detect backup controllers for which the APs are configured.

Packet Flow

The WiSM modules expect to receive both upstream and downstream traffic. Typical deployments of the Virtual Switch include connectivity to the core switches and the access switch through Multichassis Ether Channels (MEC). With the existing implementation of MEC, traffic from the core or the access is load balanced to all the links of the MEC. This means that traffic can reach either of the two switches that make up the Virtual switch. If the service module for this traffic lies on the other switch, the traffic needs to traverse the VSL to reach the other switch. Hence you see traffic traverse the VSL in these cases.

wism-vss-integration-4.gif

Administration of a Cisco WiSM in VSS Switch

The most important change with the Cisco WiSM in a VSS environment is the way you access and manage it. In a Cisco Virtual Switching System environment, a switch ID is required for many commands used to administer the WiSM. In this example, a WiSM mode is installed in switch 1, slot 11 and switch 2, slot 11.

SFO# show module switch 1 slot 11

Switch Number: 1 Role: Virtual Switch Active
---------------------- -----------------------------

Mod Ports Card Type 				 										 Model 		    												Serial No.
------------------------------------------------------------------------
11  10 	  WiSM WLAN Service Module 	WS-SVC-WISM-1-K9   					SAD121400TD


Mod MAC addresses 		                   Hw   Fw            Sw           Status
--- --------------------------------   ---  ------------  -----------  -------
11  001f.9e81.d8e0 to 001f.9e81.d8ef   2.2  12.2(14r) S5  12.2(33)SXI  Ok


Mod Sub-Module 		                Model 		             Serial 	     Hw  Status
--- ---------------------------  -------------------  ------------ --- -------
11  Centralized Forwarding Card  WS-SVC-WISM-1-K9-D   SAD121400G3  2.1 Ok


Mod  Online Diag Status
---- -------------------
11   Pass


SFO#
SFO# show module switch 2 slot 11

Switch Number: 2 Role: Virtual Switch Standby
---------------------- -----------------------------


Mod Ports Card Type                   Model                  Serial No.
--- ----- -------------------------------------- ------------------ -----------
11  10    WiSM WLAN Service Module    WS-SVC-WISM-1-K9       SAD102106DK


Mod MAC addresses 																							Hw   Fw            Sw           Status
--- ---------------------------------- ------ ------------ ------------ -------
11 0017.e068.12b8 to 0017.e068.12c7      1.3  12.2(14r)S5   12.2(33)SXI  Ok


Mod Sub-Module                 Model 												 Serial       Hw        Status
---- --------------------------- ------------------ ----------- ------- -------
11 Centralized Forwarding Card WS-SVC-WISM-1-K9-D SAD1022057D  1.3       Ok


Mod  Online Diag Status
---- -------------------
11   Pass

Configuration Changes for Cisco WiSM in VSS mode

Complete these steps:

  1. Create a VLAN in the Supervisor 720. This VLAN is local to the chassis and is used for communication between Cisco WiSM and Catalyst Supervisor 720 over a Gigabit interface on the Supervisor and service-port in the Cisco WiSM.

    
    !--- Assign an appropriate IP address and 
    !--- subnet mask for VLAN 2.
    
    
    interface Vlan2
    ip address 172.23.226.87 255.255.254.0
    
  2. Create a DHCP scope for the service port of the Cisco WiSM in Supervisor 720 or on a standalone DHCP server. Then associate the VLAN for the service port.

    
    !---Configure this command to use vlan 2 
    !--- in order to communicate with the service-port.
    
    
    wism service-vlan 2
  3. Issue the show wism status command in order to verify that the Cisco WiSM received an IP address from the DHCP server.

    	SFO# show wism status
    
    Service Vlan : 2, Service IP Subnet : 172.23.226.87/255.255.254.0
    
    WLAN
    Slot Controller   Service IP      Management IP   SW Version   Status
    ----+-----------+---------------+---------------+-----------+----------
    27 				1          172.23.226.99   10.10.0.1      	5.2.104.0    Oper-Up
    27				 2          172.23.226.100  10.10.0.3       5.2.104.0    Oper-Up
    

Configuring Communication between the Supervisor 720 and Cisco WiSM

Manual LAG configuration is not supported in Cisco IOS Software Releases 12.2(33) SXI and later.


!--- Create the VLAN in the Supervisor 720 
!--- in order to communicate with the management and
!--- AP manager ports of the Cisco WiSM controller.



!--- Assign an appropriate IP address and subnet 
!--- mask for VLAN 101


interface Vlan101
description Management VLAN for WiSM
ip address 10.10.0.10 255.255.0.0
ip helper-address 10.30.0.1
end

The Supervisor automatically creates two port-channel interfaces for the two independent controllers in the Cisco WiSM as soon as the module is detected. Usually the port-channels have a high number, such as 709 and 710.

SFO#sh ip int brief | inc Port
Port-channel709 unassigned YES unset up up
Port-channel710 unassigned YES unset up up

These commands can be used in order to configure the port-channel with native and allowed VLANs. In this case, VLAN 101 is added as the native VLAN.

Note: Make sure that the native VLAN is not tagged while the Cisco WiSM is configured.

SFO(config)#wism switch 1 module 11 controller 1 ?
allowed-vlan
native-vlan
qos-trust Trust state of the interface
SFO(config)#wism switch 1 module 11 controller 1 native-vlan 101
SFO(config)#wism switch 1 module 11 controller 2 native-vlan 101
SFO(config)#wism switch 2 module 11 controller 1 native-vlan 101
SFO(config)#wism switch 2 module 11 controller 2 native-vlan 101

Additionally, Cisco recommends that you allow only VLANs that are configured in the Cisco WiSM through the port-channel and Gigabit interfaces with these command.

Note: If you configured the wism switch module x controller y allowed-vlan <list> command previously, as soon as the VSS comes up, this command disappears. The WiSM port-channels are down once the VSS is up/enabled and the ports are down as the allowed-vlan disappears. You need to configure this command again in order to allow the VLANs and bring up the ports. If you have not configured the wism switch module x controller y allowed-vlan <list> command, this needs to be configured now.

SFO(config)#wism switch 1 module 11 controller 1 allowed-vlan 101,280
SFO(config)#wism switch 1 module 11 controller 2 allowed-vlan 101,280


SFO(config)#wism switch 2 module 11 controller 1 allowed-vlan 101,280
SFO(config)#wism switch 2 module 11 controller 2 allowed-vlan 101,280

Issue the show wism status command in order to verify that the Cisco WiSM receives an IP address from the DHCP server for service-port.

SFO#show wism switch 1 module 11 controller 1 status
WiSM Controller 1 in Slot 27 configured with auto-lag
Operational Status of the Controller : Oper-Up
Service VLAN : 2
Service Port : 9
Service Port Mac Address : 001f.9e68.b722
Service IP Address : 172.23.226.99
Management IP Address : 10.10.0.1
Software Version : 5.2.104.0
Port Channel Number : 709
Allowed-vlan list : 101,280
Native VLAN ID : 101
WCP Keep Alive Missed : 0



SFO#show wism switch 1 module 11 controller 2 status
WiSM Controller 2 in Slot 27 configured with auto-lag
Operational Status of the Controller : Oper-Up
Service VLAN : 2
Service Port : 10
Service Port Mac Address : 001f.9e6c.3fe2
Service IP Address : 172.23.226.100
Management IP Address : 10.10.0.3
Software Version : 5.2.104.0
Port Channel Number : 710
Allowed-vlan list : 101,280
Native VLAN ID : 101
WCP Keep Alive Missed : 0

The initial configuration of the Cisco WiSM controller initiates a session from the supervisor. The Cisco WiSM controller is inserted into the appropriate slot and powered on. The basic configuration is completed with the help of the setup script. With the completion of basic configuration, the administrator can configure the Cisco WiSM controller through the console CLI or through the Cisco WiSM controller web-interface. In order to use the session command, you must make sure that the service port on the Cisco WiSM is assigned a static or DHCP assigned IP address. An administrator needs to configure WiSM-A and WiSM-B separately in the Cisco WiSM module, initially from the CLI and then from the web interface.

You can access the WiSM through a session command directly now.

SFO#session switch 1 slot 11 proc 1
The default escape character is Ctrl-^, then x.
You can also type 'exit' at the remote prompt to end the session
Trying 172.23.226.99 ... Open
(sfo-1-11-1)
User:

Related Information

Updated: Feb 03, 2009
Document ID: 109494