Introduction
This document describes the configuration and theory of operation of servie ports in Cisco Unified Wireless Network Controllers (CUWN) and provides general guidelines for its deployment.The purpose of this document is to:
- Provide an overview and best practices guidelines to connect Cisco standalone Controllers (55000/8500) to the network
- Provide an overview , best practices and commands to troubleshoot service port issues in Wireless Service Module/Controllers (WiSM)
Prerequisites
Requirements
Cisco recommends you have knowledge of Cisco Wireless LAN Controllers
Components Used
The information in this document is based on Cisco Wireless Standalone Controlers and WiSM modules.
The information in this document is 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.
Overview of Service Port
Standalone Controllers
The service port on the Standalone Controllers is reserved for the out-of-band management of the controller and system recovery and maintenance in the event of a network failure. It is also the only port that is active when the controller is in boot mode. The service-port interface uses the controller’s factory-set service-port MAC address.
Service Port Features
- Service Port directly connects to the Control plane of the 5508 and hence it directly points to the CPU. The other physical data ports are connected via Data Plane
- The service port is not capable of carrying 802.1Q tags, so it must be connected to an access port on the neighbor switch
- The controller uses the static routes to ensure that service port is able to reach out of subnet destinations (subnets different than of its own). Whatever traffic matches a static route on the Wireless LAN Controller (WLC) leaves the controller through the service port, even if the incoming traffic came through the management interface (data ports) that includes the GUI of the Controller, RADIUS authentciation traffic and so on
Same subnet (service port vlan) reachability
- Service port does not have any gateway and is connected to the access port of the neighboring switch. So under normal circumstances, you must be able to access the service port by connecting the PC in the same access vlan on the neighboring switch. Here you do not need any static route on the WLC since your PC is connected to the service port vlan on the neighboring switch and you communicate with in the same vlan
- Do not configure the wired clients in the same vlan or subnet of the service port on the neighboring switch. As the service port directly points to the CPU/Control plane , you might see high CPU if the service port vlan has lots of mulicast/broadcast traffic
- GUI access via management ip address is not possible from this vlan
Remote subnet (different than service port vlan) reachability
If you need to manage the service port from a remote subnet , you must add the static routes to communicate to the remote subnets . Points for this Configuration are:
- If you want to reach the service port from everywhere in the network and give an static route for the destination 10.0.0.0/8 that points to the service port subnet gateway that is already present on the switch side. This big subnet might cover the entire Subnets used in the network including Radius servers and Tacacs servers. Following might be the results of this configuration
- The WLC GUI is not accessible via Management ip address from all the subnets covered under 10.0.0.0/8. You will have to use service port ip address to get GUI access of the WLC. This is derived from the fact that all the traffic matching the Static route is routed via service port even if the management traffic enters via management interface
- The Radius authentications fails since you might have added WLC management ip address as an AAA client. For successful authentications, you need to add WLC as an AAA client using service port interface ip address since traffic is getting routed via service port with source address of the service port ip address
- If service port ip address becomes unreachable due to any reason for some time, all subsequent radius authentications might fail for that time period
- You might see high CPU/Crashes if you have lots of multicast/broadcast that hit the service port
- Try to give specific routes as static, may be for one or two remote subnet and have Remote management work station
in that subnet. Even in this case, GUI access to the WLC will not be available using Management ip address of the Controller from the PCs of this subnet. If you have Radius server subnet covered under this specific route,authentication request reaching to the Radius server will still be sourced with the service port ip address
Configure
Configure the WLC Service Port
The configuration assumes that the wireless controller is configured already and you want to configure
the Service port.
In order to Configure the Service interface for the DHCP enter the config interface dhcp service-port enable command.
In order to disable the DHCP server, enter config interface dhcp service-port disable command
In order to configure the IPv4 address enter config interface address service-port ip-addr ip-netmask command.
In order to manage the service port from a remote subnet , you need to add the static routes to communicate to the remote subnets
Enter the config route add network-ip-addr ip-netmask gateway command.
Verify
In order to verify the configuration of the service port, use show interface detailed service-port command.
You get this output:
Interface Name................................... service-port
MAC Address...................................... 50:57:a8:bc:4b:01
IP Address....................................... 192.168.20.1
IP Netmask....................................... 255.255.255.0
Link Local IPv6 Address.......................... fe80::5257:a8ff:febc:4b01/64
STATE ........................................... REACHABLE
IPv6 Address..................................... ::/128
STATE ........................................... NONE
SLAAC............................................ Disabled
DHCP Protocol.................................... Disabled
AP Manager....................................... No
Guest Interface.................................. No
Speed ........................................... 10Mbps
Duplex .......................................... Half
Auto Negotiation ................................ Enabled
Link Status...................................... Up
Service Port in AP SSO mode
- Each (active and standby) unit has a unique IP for the service port .Both the service port addresses has to be present in the same subnet. This is because, if the standby controller’s service port is in a different subnet, you need to add new routes. This brings difference in the configurations on active and standby which is not expected.
Command to configure peer service port IP address and netmask of peer/standby controller:
(Cisco Controller) >config redundancy interface address peer-service-port ?
(Cisco Controller) >config redundancy peer-route ?
WiSM Controllers
WiSM module inside 6500 is a special case where service port is used for the communication between the WiSM controller and the supervisor. Service port configuration is mandatory to setup the WiSM controllers.
- WLAN Controller Protocol (WCP) is the software glue between the Supervisor and WiSM-2 Controller. WCP runs on UDP/IP, port 10000 over service interface. Once the WiSM controller is up, there are software heartbeats or keepalives between supervisor and WiSM Controller. The controller requests the supervisor for its slot/processor information.WCP runs on UDP/IP, port 10000 over service interface
- Service port vlan is local to the chassi and must have a layer 3 interface on the switch IOS. The service port can be assigned DHCP or static ip address depending on the switch port configuration on the controller. Service Port IP address should be on the different subnet from the Management interfaces of the controller. Not keeping the Service VLAN local might create issues for example some other switch in the network becoming root switch of the Service vlan.
- VRF on the service port is not supported
- Service port IP address must be on the different subnet from the management interfaces of the controller.
- Service VLAN is local to the chassis and is used for communication between Cisco WiSM and Catalyst Supervisor 720 or 2T over a Gigabit interface on the Supervisor and service-port in the Cisco WiSM.
Configure
Configure the WiSM Service Port
For information on how to setup WiSM module on 6500 Switch, Please refer to these links:
Troubleshoot and Configure Initial Wireless Services Module (WiSM) Setup
WiSM-2 2DP Deployment Guide
Verify
Use this section in order to confirm your service port configuration, use show wism status command.
Service Vlan : 213, Service IP Subnet : 8.8.8.1/255.255.255.0
WLAN
Slot Controller Service IP Management IP SW Version Controller Type Status
----+-----------+----------------+----------------+------------+------------------+---------------
7 1 8.8.8.2 10.105.98.13 7.0.252.0 WS-SVC-WISM-1-K9 Oper-Up
Troubleshoot
Use these commands in order to see the debug messages that show the communication between the WiSM controller and supervisor
(WiSM-slot7-1) >debug wcp events enable
*wcpTask: May 03 02:42:29.830: Received WCP_MSG_TYPE_REQUEST
*wcpTask: May 03 02:42:29.830: Received WCP_MSG_TYPE_REQUEST,of type WCP_TLV_KEEP_ALIVE
*wcpTask: May 03 02:42:29.830: Sent WCP_MSG_TYPE_RESPONSE,of type WCP_TLV_KEEP_ALIVE
*wcpTask: May 03 02:42:49.830: Received WCP_MSG_TYPE_REQUEST
*wcpTask: May 03 02:42:49.830: Received WCP_MSG_TYPE_REQUEST,of type WCP_TLV_KEEP_ALIVE
*wcpTask: May 03 02:42:49.830: Sent WCP_MSG_TYPE_RESPONSE,of type WCP_TLV_KEEP_ALIVE
*wcpTask: May 03 02:43:09.830: Received WCP_MSG_TYPE_REQUEST
*wcpTask: May 03 02:43:09.830: Received WCP_MSG_TYPE_REQUEST,of type WCP_TLV_KEEP_ALIVE
*wcpTask: May 03 02:43:09.830: Sent WCP_MSG_TYPE_RESPONSE,of type WCP_TLV_KEEP_ALIVE
- On the switch/router side
6500#debug wism events
dman_proc_service_tmr_handler Service Port Timer fired for slot/port: 7/2
May 3 04:39:18: WiSM-Evt:returning, rc 0, num_entries 0 for slot/port/vlan 7/10/213
May 3 04:39:19: WiSM-Evt:dman_cntrl_db_search_by_mac: Found mac 0019.30fb.ccc2 for slot/port 7/1
May 3 04:39:19: WiSM-Evt:dman_reg_arp_added: cntrl 7/1 got an ip 8.8.8.2 0019.30fb.ccc2/0019.30fb.ccc2
May 3 04:39:20: WiSM-Evt: dman_proc_service_tmr_handler Service Port Timer fired for slot/port: 7/2
In order to see the WCP transmit and recieve packets exchanged between the WiSM controller and supervisor:
6500#debug wism wcp data
May 3 04:32:54: WiSM-Evt:dman_proc_keepalive_tmr_handler: keepalive timer expired for 7/1
May 3 04:32:54: wcp-tx: src/dst:8.8.8.1/8.8.8.2 ver:1 sap2/1
May 3 04:32:54: typ:req len:61 seq:1079591 flg:0 sts:1
May 3 04:32:54: 00 00 00 01 00 00 00 18 00 00 00 04 08 08 08 01
May 3 04:32:54: 00 00 00 00 00 00 D5 20 00 00 00 00 00 00 00 05
May 3 04:32:54: wcp-rx: src/dst:8.8.8.2/8.8.8.1 ver:1 sap0/0
May 3 04:32:54: typ:rsp len:45 seq:1079591 flg:0 sts:1
May 3 04:32:54: 00 00 00 01 00 00 00 08 00 00 00 01 58 5F 60 11
Feedback