Mobility System Software Configuration Guide

Configuration Guide

Mobility System Software

Copyright © 2013, Juniper Networks, Inc.

Configuration Guide


© 2013 Juniper Networks, Inc. All rights reserved.

Trademarks Juniper Networks, the Juniper Networks logo, NetScreen, NetScreen Technologies, the NetScreen logo, NetScreen-Global Pro, ScreenOS, and GigaScreen are registered trademarks of Juniper Networks, Inc. in the United States and other countries. The following are trademarks of Juniper Networks, Inc.: ERX, ESP, E-series, Instant Virtual Extranet, Internet Processor, J2300, J4300, J6300, J-Protect, J-series, J-Web, JUNOS, JUNOScope, JUNOScript, JUNOSe, M5, M7i, M10, M10i, M20, M40, M40e, M160, M320, M-series, MMD, NetScreen-5GT, NetScreen-5XP, NetScreen-5XT, NetScreen-25, NetScreen-50, NetScreen-204, NetScreen-208, NetScreen-500, NetScreen-5200, NetScreen-5400, NetScreen-IDP 10, NetScreen-IDP 100, NetScreen-IDP 500, NetScreen-Remote Security Client, NetScreen-Remote VPN Client, NetScreen-SA 1000 Series, NetScreen-SA 3000 Series, NetScreen-SA 5000 Series, NetScreen-SA Central Manager, NetScreen Secure Access, NetScreen-SM 3000, NetScreen-Security Manager, NMC-RX, SDX, Stateful Signature, T320, T640, T-series, and TX Matrix. All other trademarks, service marks, registered trademarks, or registered service marks are the property of their respective owners. All specifications are subject to change without notice. Juniper Networks assumes no responsibility for any inaccuracies in this document. Juniper Networks reserves the right to change, modify, transfer, or otherwise revise this publication without notice

Disclaimer All statements, specifications, recommendations, and technical information are current or planned as of the date of the publication of this document. They are reliable as of the time of this writing and are presented without warranty of any kind, expressed or implied. In an effort to continuously improve the product and add features, Juniper Networks reserves the right to change any specifications contained in this document without prior notice of any kind.

Copyright © 2013, Juniper Networks, Inc. All rights reserved. Juniper Networks, the Juniper Networks logo, NetScreen, NetScreen Technologies, the NetScreen logo, NetScreen-Global Pro, ScreenOS, and GigaScreen are registered trademarks of Juniper Networks, Inc. in the United States and other countries. The following are trademarks of Juniper Networks, Inc.: ERX, ESP, E-series, Instant Virtual Extranet, Internet Processor, J2300, J4300, J6300, J-Protect, J-series, J-Web, JUNOS, JUNOScope, JUNOScript, JUNOSe, M5, M7i, M10, M10i, M20, M40, M40e, M160, M320, M-series, MMD, NetScreen-5GT, NetScreen-5XP, NetScreen-5XT, NetScreen-25, NetScreen-50, NetScreen-204, NetScreen-208, NetScreen-500, NetScreen-5200, NetScreen-5400, NetScreen-IDP 10, NetScreen-IDP 100, NetScreen-IDP 500, NetScreen-Remote Security Client, NetScreen-Remote VPN Client, NetScreen-SA 1000 Series, NetScreen-SA 3000 Series, NetScreen-SA 5000 Series, NetScreen-SA Central Manager, NetScreen Secure Access, NetScreen-SM 3000, NetScreen-Security Manager, NMC-RX, SDX, Stateful Signature, T320, T640, T-series, and TX Matrix. All other trademarks, service marks, registered trademarks, or registered service marks are the property of their respective owners. All specifications are subject to change without notice. Juniper Networks assumes no responsibility for any inaccuracies in this document. Juniper Networks reserves the right to change, modify, transfer, or otherwise revise this publication without notice.


Configuration Guide


Table of Contents About This Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Juniper Networks Mobility System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Planning, Configuration, and Deployment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Configuration and Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Documentation Symbols Key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Hypertext Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Text and Syntax Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Documentation Feedback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Requesting Technical Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Self-Service Online Tools and Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Opening a Case with JTAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 END USER LICENSE AGREEMENT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Adding Licenses to an WLC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Installing Upgrade Activation Keys on an WLC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 WLC Platform Feature Licensing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 WLC License Upgrades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 New Controllers Supported in MSS 9.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17 Support for JunosV Wireless LAN Controller (JunosV WLC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17 Support for the Wireless LAN Controller 100 (WLC100). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Using the Command-Line Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 CLI Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 Command Prompts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 Syntax Notation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Text Entry Conventions and Allowed Characters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 MAC Address Notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 IP Address and Mask Notation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Subnet Masks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Wildcard Masks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Port Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Virtual LAN Identification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Command-Line Editing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Keyboard Shortcuts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 History Buffer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Tabs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Using CLI Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Single-Asterisk (*) Wildcard Character . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 Double-Asterisk (**) Wildcard Characters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 Configuring Administrative and Local Access. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Overview of Administrative and Local Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Mobility System Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 About Administrative Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 Access Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 First-Time Configuration via the Console. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Logging into the WLC for the First Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Setting the WLC Enable Password . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Saving the Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Service-Type Access to Privileged CLI Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Authenticating at the Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

i

Configuring Passwords. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 Configuring Passwords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 Setting an MSS password for a User in the Local Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30 Enabling Password Restrictions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30 Setting the Maximum Number of Login Attempts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 Specifying Minimum Password Length. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 Configuring Password Expiration Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 Restoring Access to a Locked-Out User . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 Displaying Password Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 Adding and Clearing Local Users for Administrative Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 Administrative Access Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 Saving the Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 Configuring LDAP Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 About LDAP Authentication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 Configuring LDAP Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 LDAP Configuration Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 Changing the MAC Authorization Password . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 Configuring Communication with RADIUS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 RADIUS Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 Before You Begin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 Configuring RADIUS Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 Configuring Authentication Protocols for RADIUS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 Configuring Global RADIUS Defaults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 Setting the System IP Address as the Source Address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .44 Configuring Individual RADIUS Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .44 Configuring MAC Addresses as Usernames on a RADIUS Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 Deleting RADIUS Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 Configuring RADIUS Server Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 Creating Server Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .46 Ordering Server Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .46 Configuring Load Balancing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .46 Adding Members to a Server Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 Deleting a Server Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .48 Using the RADIUS Ping Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .48 RADIUS and Server Group Configuration Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .49 Dynamic RADIUS Extensions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .50 Configuring Dynamic RADIUS Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .50 Attribute for RADIUS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .50 MAC User Range Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 Configuring MAC User Range Authentication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 MAC Authentication Request Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 Configuring MAC Authentication Requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 Split Authentication and Authorization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 Configuring Command Auditing and RADIUS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 Managing System Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 About System Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 Displaying Software Version Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 Boot Information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 Managing Files Stored on the WLC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

ii


Displaying a List of Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 Copying a File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .60 Using SCP to Manage Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 Deleting a File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 Creating a Subdirectory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 Removing a Subdirectory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .64 Managing Configuration Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .64 Displaying the Running Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .64 Saving Configuration Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 Specifying the Configuration File to Use After the Next Reboot . . . . . . . . . . . . . . . . . . . . . . . . . . . . .66 Loading a Configuration File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .66 Specifying a Backup Configuration File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 Resetting to the Factory Default Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 Backing Up and Restoring the System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .68 Managing Configuration Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .69 Backup and Restore Examples. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 Upgrading the System Image . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 Command Changes During Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 Wireless LAN Access Points. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .71 WLA Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .71 Configuring WLA Points. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .71 Network Address Translation (NAT) Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 Country of Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 Directly Connected WLAs and Distributed WLAs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 Distributed WLA Network Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 Distributed WLAs and Spanning Tree Protocol (STP). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 Distributed WLAs and DHCP Option 43 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 Boot Process for Distributed WLAs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 WLA Boot Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 Example of an WLA Booting over a Layer 2 Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 Example of an WLA Booting over a Layer 3 Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 Example of a WLA with a Static IP Configuration Booting on the Network . . . . . . . . . . . . . 78 Loading and Activating Operational Images . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 Forcing an WLA To Download an Operational Image from the WLC . . . . . . . . . . . . . . . . . . . 79 WLA Parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 Resiliency and Dual-Homing Options for WLAs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .80 Bias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 Dual-Homed Configuration Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 Dual-Homed Direct Connections to a Single WLC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 Dual-Homed Direct Connections to Two WLC Switches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 Dual-Homed Direct and Distributed Connections to WLC Switches. . . . . . . . . . . . . . . . . . . . . 82 Dual-Homed Distributed Connections to WLC Switches on Both WLA Ports . . . . . . . . . . . 82 Dual-Homed Distributed Connections to WLC Switches on One WLA Port . . . . . . . . . . . . . 83 Configuring WLAs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .85 Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .85 Specifying the Country of Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .85 Configuring an Auto-AP Profile for Automatic WLA Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . .89 Locating an WLC for Automatic WLA Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .89 Configured WLAs Have Precedence Over Unconfigured WLAs . . . . . . . . . . . . . . . . . . . . . . . . .90 Configuring an Auto-AP Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .90

iii

Changing WLA Parameter Values. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 Enabling the Auto-AP Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 Specifying the Radio Profile Used by the Auto-AP Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 Displaying Status Information for WLAs Configured by the Auto-AP Profile . . . . . . . . . . . . . . . . . . . . . . 93 Converting an WLA Configured by the Auto-AP Profile into a Permanent WLA . . . . . . . . . 93 Configuring WLA Port Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 Configuring an WLA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 Configuring Static IP Addresses on Distributed WLAs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .96 Specifying IP Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .96 Specifying the WLC Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .96 Specifying VLAN information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 Clearing an WLA from the Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 Changing WLA Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 Changing Bias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 Disabling or Reenabling Automatic Firmware Upgrades. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .98 Enabling LED Blink Mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .98 Configuring AP LED Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .98 Configuring AP Communication Time Out . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .98 Configuring WLA-WLC Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .99 Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .99 Encryption Key Fingerprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .99 Encryption Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .99 Verifying an WLA Fingerprint on an WLC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .100 Finding the Fingerprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .100 Verifying a Fingerprint on the WLC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 Setting the WLA Security Requirement on an WLC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 Fingerprint Log Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 Configuring IEEE 802.11n . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 PoE Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 Glossary of Terms for IEEE 802.11n . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 Configuration Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 Frame Aggregation Commands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 Data Rate Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 Muticast Traffic to Unicast Traffic Conversion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 Displaying WLA Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 Displaying WLA Configuration Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 Displaying Connection Information for Distributed WLAs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 Displaying a List of Unconfigured Distributed WLAs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 Displaying Active Connection Information for Distributed WLAs. . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 Configuring WLAN Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 Configuring a Service Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 Service Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 Public and Private SSIDs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .114 Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .115 Mixed Cipher Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .115 Configuring a Service Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 Creating a Service Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 Removing a Service Profile. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 Changing a Service Profile Setting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 Disabling or Reenabling Encryption for an SSID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

iv


Disabling or Reenabling Beaconing of an SSID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 Changing the Fallthru Authentication Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 Changing Transmit Rates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 Enforcing the Data Rates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 Disabling Idle-Client Probing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 Changing the User Idle Timeout. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 Changing the Short Retry Threshold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 Changing the Long Retry Threshold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .121 Transmit Beam-forming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .121 Displaying Service Profile Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 Configuring a Radio Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 Radio Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 RF Auto-Tuning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 Default Radio Profile. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 Radio-Specific Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 Creating a New Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 Changing Radio Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130 Changing the Beacon Interval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130 Changing the DTIM Interval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130 Changing the RTS Threshold. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .131 Changing the Fragmentation Threshold. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .131 Changing the Maximum Receive Threshold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .131 Changing the Maximum Transmit Threshold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 Changing the Preamble Length . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 Resetting a Radio Profile Parameter to the Default Value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 Removing a Radio Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 Configuring Radio-Specific Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 Configuring the Channel and Transmit Power . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 Configuring the External Antenna Model and Location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134 Specifying the External Antenna Location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 Mapping the Radio Profile to Service Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 Assigning a Radio Profile and Enabling Radios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 Disabling or Enabling Radios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 Enabling or Disabling Individual Radios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 Disabling or Enabling All Radios Using a Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 Resetting a Radio to Factory Default Settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 Restarting an WLA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 Configuring Local Packet Switching on WLAs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 Configuring Local Switching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 Configuring a VLAN Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 Enabling Local Switching on an WLA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 Applying a VLAN Profile to an WLA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 Clearing the VLAN Profile from an WLA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 Removing a VLAN Profile from the WLC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 WLA to WLA Tunneling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 Configuring WLA to WLA Tunneling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 Displaying Service Profile Information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143 Displaying Radio Profile Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144

v

Displaying WLA Status Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144 Displaying Static IP Address Information for Distributed WLAs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 Displaying WLA Statistics Counters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146 Displaying Access Category Counters on a per-SSID, per-VLAN, and per-Radio Basis . . . . . . 147 Displaying VLAN Profile Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148 Displaying the ARP Table for an WLA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148 Displaying the Forwarding Database for an WLA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149 Displaying VLAN Information for an WLA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149 Displaying ACL Information for an WLA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150 Configuring Radio-Specific Parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153 Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153 Configuring the Channel and Transmit Power . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153 Configuring the External Antenna Model and Location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154 Specifying the External Antenna Location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154 Mapping the Radio Profile to Service Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154 Assigning a Radio Profile and Enabling Radios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154 Disabling or Enabling Radios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155 Enabling or Disabling Individual Radios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155 Disabling or Enabling All Radios Using a Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155 Resetting a Radio to Factory Default Settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156 Restarting an WLA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156 Displaying Service Profile Information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156 Displaying Radio Profile Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157 Displaying WLA Statistics Counters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158 Displaying VLAN Profile Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159 Displaying the ARP Table for an WLA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159 Displaying the Forwarding Database for an WLA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160 Displaying VLAN Information for an WLA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160 Displaying ACL Information for an WLA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161 Configuring Local Packet Switching on WLAs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 Configuring Local Switching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164 Configuring a VLAN Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164 Enabling Local Switching on an WLA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164 Applying a VLAN Profile to an WLA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164 Clearing the VLAN Profile from an WLA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165 Removing a VLAN Profile from the WLC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165 WLA to WLA Tunneling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165 Configuring WLA to WLA Tunneling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 Displaying Radio Profile Information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 Displaying WLA Status Information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171 Displaying Static IP Address Information for Distributed WLAs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171 Displaying WLA Statistics Counters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172 Displaying VLAN Profile Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173 Displaying the ARP Table for an WLA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173 Displaying the Forwarding Database for an WLA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174 Displaying VLAN Information for an WLA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174 Displaying ACL Information for an WLA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175 Configuring WLAN Mesh Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .177 WLAN Mesh Services Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177

vi


Enhancements to Mesh Services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177 Configuring WLAN Mesh Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179 Configuring the Mesh AP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179 Configuring the Service Profile for Mesh Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180 Configuring Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180 Recommended Configuration Best Practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181 Enabling Link Calibration Packets on the Mesh Portal WLA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181 Deploying the Mesh AP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181 Configuring Wireless Bridging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182 Displaying WLAN Mesh Services Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183 Configuring WLAN Outages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185 Configuring WAN Outage using MSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185 Configuring WLAs for WAN Outage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186 Roaming between WLAs at Remote Sites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188 Configuring Additional Remote Site Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188 Adding Limited Roaming Capabilities to the WLA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188 Adding Limited AAA Capability to the WLA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189 Adding Configuration Support to the WLA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189 Adding Support for 4-way Handshakes and Group Key Handshakes (GKHS) . . . . . . . . . . . . . . 189 Assigning a Different Country Code to a Remote WLA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189 Configuring Path MTU between a WLC and a WLA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189 Remote WLA High Latency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192 Enhancements to Access Points in MSS 9.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193 Persistent Configuration for Access Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193 Access Point Discovering the Controller. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194 Supporting CLI Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195 Extended Authorization Support for Access Points. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196 RADIUS Client on WLA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196 CLI Changes for Extended Authentication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197 Access Point Power Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198 Extended character support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200 Configuring User Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201 Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201 Configuring User Encryption Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203 Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203 Configuring WPA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203 Creating a Service Profile for WPA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203 Enabling WPA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203 Specifying the WPA Cipher Suites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204 Changing the TKIP Countermeasures Timer Value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204 Enabling PSK Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204 Configuring a Global PSK Passphrase or Raw Key for All Clients . . . . . . . . . . . . . . . . . . . . . 205 Disabling 802.1X Authentication for WPA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205 Displaying WPA Settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205 Assigning the Service Profile to Radios and Enabling the Radios . . . . . . . . . . . . . . . . . . . . . 206 Configuring RSN (802.11i) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .207 Creating a Service Profile for RSN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .207 Enabling RSN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .207 Specifying the RSN Cipher Suites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208 Changing the TKIP Countermeasures Timer Value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208

vii

Enabling PSK Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208 Displaying RSN Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208 Assigning the Service Profile to Radios and Enabling the Radios . . . . . . . . . . . . . . . . . . . . . 209 Configuring WEP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209 Setting Static WEP Key Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210 Assigning Static WEP Keys. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .211 Encryption Configuration Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213 Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213 Enabling WPA with TKIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213 Enabling Dynamic WEP in a WPA Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215 Configuring Encryption for MAC Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217 Managing Sessions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221 About the Session Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221 Displaying and Clearing Administrative Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221 Displaying and Clearing All WLC Administrative Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221 Displaying and Clearing an Administrative Console Session . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222 Displaying and Clearing Client Telnet Sessions .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . 222

Displaying and Clearing Mesh Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222 Displaying and Clearing Network Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227 Displaying Verbose Network Session Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227 Displaying and Clearing Network Sessions by Username . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .229 Displaying and Clearing Network Sessions by MAC Address. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .229 Displaying and Clearing Network Sessions by VLAN Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230 Displaying and Clearing Network Sessions by Session ID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230 Displaying SIP Client Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232 Displaying Session Statistics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232 Displaying Voice Details for a Network Session . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .234 Show Sessions Enhancements for Cluster Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .235 Displaying and Changing Network Session Timers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .236 Changing or Disabling the User Idle Timeout in an MSS Service Profile . . . . . . . . . . . . . . . . . . . . . 237 IPv6 Addressing Support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237 IPv6 and Quality of Service (QoS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .239 IPv6 Traffic Filtering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240 IPv6 and ACLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240 Wi-Fi Certified Passpoint (Hotspot 2.0) Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241 Generic Advertisement Service (GAS) and Access Network Query Protocol (ANQP). . . . . . .242 Enhanced Layer 2 Functionality to Support 802.11u . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .243 Configuring Interworking Profiles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .243 Configuring Interworking Profile Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244 Additional 802.1X Authentication Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246 Configuring Layer 2 Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246 Configuring Venue Information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247 Configuring and Managing IP Interfaces and Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .307 MTU Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .307 Configuring and Managing IP Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .307 Adding an IP Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .307 Statically Configuring an IP Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .307 Enabling the DHCP Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308 Resolving Conflicts with Statically Configured IP Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308 Configuring the DHCP Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309

viii


Displaying DHCP Client Information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309 Disabling an IP Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310 Removing an IP Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310 Displaying IP Interface Information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310 Configuring the System IP Address. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310 Designating the System IP Address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .311 Displaying the System IP Address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .311 Clearing the System IP Address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .311 Configuring IPSec Clients for RADIUS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .311 Configuring and Managing IP Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312 Displaying IP Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312 Adding a Static Route. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314 Removing a Static Route. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314 Maintaining Management Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317 Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317 Managing SSH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317 Login Timeouts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317 Enabling SSH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317 Adding an SSH User . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318 Managing SSH Server Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318 Managing Telnet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319 Telnet Login Timers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319 Enabling Telnet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319 Adding a Telnet User. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319 Displaying Telnet Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320 Changing the Telnet Service Port Number . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320 Resetting the Telnet Service Port Number to the Default Port . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320 Managing Telnet Server Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320 Managing HTTPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321 Changing the Idle Timeout for CLI Management Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322 Setting a Message of the Day (MOTD) Banner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322 Prompting the User to Acknowledge the MOTD Banner. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .323 Configuring and Managing DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .323 Enabling or Disabling the DNS Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .324 Configuring DNS Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .324 Adding or Removing a DNS Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .324 Configuring a Default Domain Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .324 Adding or Removing the Default Domain Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .324 Displaying DNS Server Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .325 Configuring and Managing Aliases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .325 Adding, Removing, and Displaying an Alias. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .325 Configuring and Managing Time Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .326 Statically setting the Time and Date . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .326 Using NTP Servers to Set the Time and Date. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .326 Setting, Displaying, and Clearing the Time Zone. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327 Configuring the Summertime Period . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327 Configuring and Managing NTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .328 Adding and Removing an NTP Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .329 Changing the NTP Update Interval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .329 Resetting the Update Interval to the Default . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .329

ix

Enabling the NTP Client. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .329 Displaying NTP Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .329 Managing the ARP Table. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330 Displaying ARP Table Entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330 Adding an ARP Entry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331 Changing the Aging Timeout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331 Pinging Another Device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331 Logging Into a Remote Device. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .332 IP Interfaces and Services Configuration Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .333 Configuring and Managing DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337 Enabling or Disabling the DNS Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337 Configuring DNS Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337 Adding or Removing a DNS Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337 Configuring a Default Domain Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337 Adding or Removing the Default Domain Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338 Displaying DNS Server Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338 Configuring and Managing Aliases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338 Adding, Removing, and Displaying an Alias. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339 Managing the ARP Table. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339 Displaying ARP Table Entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339 Adding an ARP Entry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340 Changing the Aging Timeout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340 Pinging Another Device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341 Logging Into a Remote Device. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341 IP Interfaces and Services Configuration Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .342 Configuring and Managing Time Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347 Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .347 Statically setting the Time and Date . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .347 Using NTP Servers to Set the Time and Date. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .347 Setting, Displaying, and Clearing the Time Zone. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .347 Configuring the Summertime Period . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348 Configuring and Managing NTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349 Adding and Removing an NTP Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349 Changing the NTP Update Interval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350 Resetting the Update Interval to the Default . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350 Enabling the NTP Client. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350 Displaying NTP Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350 Configuring and Managing Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .353 Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .353 Setting the Port Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .353 Setting a Port for a Directly Connected WLA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354 Configuring an WLA Connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .355 Setting a Port for a Wired Authentication Use. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356 Clearing a Port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357 Clearing a Distributed WLA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357 Configuring a Port Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357 Configuring Port Operating Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358 10/100 Ports—Autonegotiation and Port Speed. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358 Gigabit Ports—Autonegotiation and Flow Control. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359 Disabling Flow Control on a WLC Gigabit Port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359

x


Disabling a Port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359 Disabling Power over Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359 Resetting a Port. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359 Displaying Port Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360 Displaying Port Configuration and Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360 Displaying PoE State. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361 Displaying Port Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361 Clearing Statistics Counters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .362 Monitoring Port Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .362 Configuring Load-Sharing Port Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363 Load Sharing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363 Link Redundancy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363 Configuring a Port Group. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363 Removing a Port Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364 Displaying Port Group Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364 Load Sharing Groups Interoperating with Cisco Systems EtherChannel . . . . . . . . . . . . . . . . . . . 365 Managing the Layer 2 Forwarding Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365 Types of Forwarding Database Entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365 How Entries Are Added to the to the Forwarding Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365 Displaying Forwarding Database Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366 Adding an Entry to the Forwarding Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .367 Removing Entries from the Forwarding Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .367 Configuring the Aging Timeout Period. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .367 Displaying and Changing the Aging Timeout Period . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .367 Port and VLAN Configuration Scenario. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 368 Configuring and Managing VLANs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375 VLAN Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375 VLANs, IP Subnets, and IP Addressing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375 Users and VLANs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375 VLAN Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .376 Roaming and VLANs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .376 Traffic Forwarding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .376 802.1Q Tagging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377 Tunnel Affinity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377 WLA Tunnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377 Configuring a VLAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .378 Creating a VLAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .378 Adding Ports to a VLAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .378 Removing an Entire VLAN or a VLAN Port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .379 Configuring VLAN Pooling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 380 Configuring VLAN Pooling using MSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 380 VLAN Pooling Commands and Configuration Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 380 Enhancements to VLAN Pooling in MSS 9.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381 Changing Tunneling Affinity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .382 Restricting Layer 2 Forwarding Among Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383 Displaying VLAN Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385 Configuring a WLC as a DHCP Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .387 Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .387 How the MSS DHCP Server Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .387 Configuring the DHCP Server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 388

xi

Displaying DHCP Server Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389 Configuring SNMP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 391 Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 391 Configuring SNMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 391 Setting the System Location and Contact Strings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 391 Enabling SNMP Versions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .392 Configuring Community Strings (SNMPv1 and SNMPv2c Only). . . . . . . . . . . . . . . . . . . . . . . . . . . . .392 Creating a USM User for SNMPv3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .392 Configuring Groups and Roles for SNMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394 Defining SNMP Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394 Displaying SNMP Group Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395 Command Examples. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395 Configuring a Notification Profile. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395 Command Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .397 Configuring a Notification Target. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 399 Command Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 400 Enabling the SNMP Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 400 Displaying SNMP Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 401 Displaying SNMP Version and Status Information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 401 Displaying the Configured SNMP Community Strings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 401 Displaying USM Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 401 Displaying Notification Profiles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 401 Displaying Notification Targets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 401 Displaying SNMP Statistics Counters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 401 About AAA for Network Users. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403 Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403 Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403 Authentication Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403 Authentication Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404 Authentication Chaining . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 406 Summary of AAA Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 406 AAA Tools for Network Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407 “Globs” and Groups for Network and Local User Classification . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407 Wildcard “Any” for SSID Matching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407 Configuring the SSID Name “Any” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407 About Last-Resort Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 408 User Credential Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 408 Authorization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409 Accounting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 410 AAA Methods for IEEE 802.1X and Web Network Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 410 AAA Rollover Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 410 Local Override Exception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .411 Remote Authentication with Local Backup. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .411 IEEE 802.1X Extensible Authentication Protocol Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413 Implementing EAP on an WLC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414 Effects of Authentication Type on Encryption Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414 Configuring 802.1X Authentication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415 Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415 Configuring EAP Offload . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415 Using Pass-Through . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415

xii


Authenticating Users in a Local Database. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 416 Binding User Authentication to Computer Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 416 Authentication Rule Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417 Bonded Authentication Period . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417 Bonded Authentication Configuration Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 418 Displaying Bonded Authentication Configuration Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 418 Configuring Authentication and Authorization by MAC Address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 419 Adding and Clearing MAC Users and User Groups Locally . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 420 Adding MAC Users and Groups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 420 Clearing MAC Users and Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 420 Configuring MAC Authentication and Authorization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 421 Changing the MAC Authorization Password for RADIUS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .422 Managing 802.1X on the WLC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .423 Managing 802.1X on Wired Authentication Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .423 Enabling and Disabling 802.1X Globally . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .423 Setting 802.1X Port Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .423 Managing 802.1X Encryption Keys. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424 Enabling 802.1X Key Transmission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424 Configuring 802.1X Key Transmission Time Intervals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424 Configuring 802.1X Rekey Timers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .425 Managing WEP Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .425 Configuring 802.1X WEP Rekeying . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426 Configuring the Interval for WEP Rekeying . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426 Setting EAP Retransmission Attempts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426 Managing 802.1X Client Reauthentication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 427 Enabling and Disabling 802.1X Reauthentication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 427 Setting the Maximum Number of 802.1X Reauthentication Attempts . . . . . . . . . . . . . . . . . . . . . . 427 Setting the 802.1X Reauthentication Period. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 428 Setting the Bonded Authentication Period . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 428 Managing Other Timers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 429 Setting the 802.1X Quiet Period . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 429 Setting the 802.1X Timeout for an Authorization Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 429 Setting the 802.1X Timeout for a Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 429 Setting the 802.1X Timeout for the Handshake . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 430 Displaying 802.1X Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 430 Viewing 802.1X Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 430 Viewing the 802.1X Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 431 Configuring Web Portal WebAAA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .433 Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .433 How Web Portal WebAAA Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .433 Display of the Login Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434 WLC Web AAA Requirements and Recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434 WebAAA Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435 User VLAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435 Fallthru authentication type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435 Authorization attributes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 436 Portal ACL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 436 Authentication rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 436 Portal ACL and User ACLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 436 Network Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .437

xiii

WLC Recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .437 Client NIC Recommendations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .437 Client Web Browser Recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .437 Configuring Web Portal WebAAA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .437 Web Portal WebAAA Configuration Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 438 External Captive Portal Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 440 CLI Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 441 Displaying Session Information for Web Portal WebAAA Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . 441 Using a Custom Login Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 442 Copying and Modifying the Web Login Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443 Customizing the Login Page Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443 Using Dynamic Fields in WebAAA Redirect URLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445 Logging Out of Web Portal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 446 Using an ACL Other Than portalacl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 446 Configuring the Web Portal WebAAA Session Timeout Period . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .447 Configuring the Web Portal WebAAA Logout Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 448 Configuring Last-Resort Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 449 Configuring Last-Resort Access for Wired Authentication Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . 450 Configuring AAA for Users of Third-Party APs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 451 Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 451 Authentication Process for Users of a Third-Party AP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 451 Third-Party AP Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 451 WLC Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .452 RADIUS Server Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .452 Configuring Authentication Third-Party APs with Tagged SSIDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453 Configuring Authentication — Non-802.1X Users of a Third-Party AP, Tagged SSIDs . . . . . . . . . . . 454 Configuring Access for Any Users of a Non-Tagged SSID. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455 Assigning Authorization Attributes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .457 Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .457 Assigning Attributes to Users and Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 460 Adding Accounting Interval Attribute. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 461 Simultaneous Login Support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 461 Assigning SSID Default Attributes to a Service Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 462 Assigning a Security ACL to a User or a Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 462 Assigning a Security ACL Locally . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463 Assigning a Security ACL on a RADIUS Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463 Clearing a Security ACL from a User or Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463 Assigning Encryption Types to Wireless Users. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464 Assigning and Clearing Encryption Types Locally. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464 Assigning and Clearing Encryption Types on a RADIUS Server. . . . . . . . . . . . . . . . . . . . . . . . 465 Keeping Users on the Same VLAN Even After Roaming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465 Overriding or Adding Attributes Locally with a Location Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 466 About the Location Policy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 466 How the Location Policy Differs from a Security ACL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .467 Setting the Location Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .467 Applying Security ACLs in a Location Policy Rule. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 468 Displaying and Positioning Location Policy Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 468 Clearing Location Policy Rules and Disabling the Location Policy . . . . . . . . . . . . . . . . . . . . . . . . . 469 Configuring Accounting for Wireless Network Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 471 Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 471

xiv


Configuring Periodic Accounting Update Records . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 472 Enabling System Accounting Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 472 Viewing Local Accounting Records. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .473 Viewing Roaming Accounting Records . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .473 Displaying the AAA Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .474 Avoiding AAA Problems in Configuration Order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .475 Using the Wildcard “Any” as the SSID Name in Authentication Rules. . . . . . . . . . . . . . . . . . . . . . .475 Using Authentication and Accounting Rules Together. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .475 Configuration Producing an Incorrect Processing Order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .475 Configuration for a Correct Processing Order. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .476 Configuring a Mobility Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .479 Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .479 Network User Configuration Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 480 General Use of Network User Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 480 Enabling RADIUS Pass-Through Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 482 Enabling PEAP-MS-CHAP-V2 Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483 Enabling PEAP-MS-CHAP-V2 Offload . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483 Combining EAP Offload with Pass-Through Authentication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483 Overriding AAA-Assigned VLANs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484 Network User Configuration Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .487 Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .487 General Use of Network User Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .487 Enabling RADIUS Pass-Through Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 489 Enabling PEAP-MS-CHAP-V2 Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 489 Enabling PEAP-MS-CHAP-V2 Offload . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 490 Combining EAP Offload with Pass-Through Authentication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 490 Overriding AAA-Assigned VLANs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 491 Device Fingerprinting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 493 DHCP Fingerprinting Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 493 DHCP Fingerprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 493 Interactions between the User Policy and the Device Policy . . . . . . . . . . . . . . . . . . . . . . . . . . 499 Other Functionalities Supported by Device Fingerprinting . . . . . . . . . . . . . . . . . . . . . . . . . . . . 499 Configuring Device Fingerprinting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 499 Applying a Device Fingerprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 500 Configuring Custom Device Fingerprints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 500 Adding Rules to Device Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 500 Configuration Example for a Complete Device Fingerprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . 501 New VSAs for RADIUS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 502 Device Profile Attributes Preference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 503 Configuring the Device Detect ACL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 503 Configuring Device Detect Timeout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 503 Example Rules for Different Mobile Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 504 Show Sessions Enhancements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 514 Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 517 Configuring Device Fingerprinting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 519 Applying a Device Fingerprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 520 Configuring Custom Device Fingerprints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 521 Adding Rules to Device Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 521 Configuration Example for a Complete Device Fingerprint . . . . . . . . . . . . . . . . . . . . . . . . . . . .522 New VSAs for RADIUS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .522

xv

Device Profile Attributes Preference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .523 Configuring the Device Detect ACL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .523 Configuring Device Detect Timeout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .524 Example Rules for Different Mobile Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .525 Show Sessions Enhancements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .535 Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 538 About Mobility Domains. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .697 About the Mobility Domain Feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 697 Smart Mobile Virtual Controller Cluster (Network Resiliency) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 697 Configuring a Mobility Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 699 Configuring the Seed. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 699 Configuring Member WLC Switches on the Seed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 699 Configuring a Member . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 700 Configuring Mobility Domain Seed Redundancy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 700 Displaying Mobility Domain Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 701 Displaying the Mobility Domain Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 701 Clearing a Mobility Domain from an WLC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 701 Clearing a Mobility Domain Member from a Seed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .702 Smart Mobile Virtual Controller Cluster (Network Resiliency). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .703 Smart Mobile Virtual Controller Cluster Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .703 Virtual Controller Cluster Configuration Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 704 Centralized Configuration Using Virtual Controller Cluster Mode . . . . . . . . . . . . . . . . . . . . . . . . . . 704 Autodistribution of WLAs on the Virtual Controller Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .705 Hitless Failover with Virtual Controller Cluster Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .705 Configuring AP Affinity for Cluster Members . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 707 Load Balancing in a Cluster Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 708 Additional Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 708 Configuring Smart Mobile Cluster Configuration on a Mobility Domain . . . . . . . . . . . . . . . . . . . . 709 Complete Virtual Controller Cluster Command Syntax. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 709 Other Virtual Controller Cluster Configuration Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . 710 Hitless Software Upgrade for Cluster Configurations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 711 Dot1X Settings in a Cluster Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 711 CLI Enhancements for Network Resiliency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 711 WLA Network Resiliency Roaming Enhancements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 712 Configuring WLC-WLC Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 713 Monitoring the VLANs and Tunnels in a Mobility Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 713 Displaying Roaming Stations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 714 Displaying Roaming VLANs and Affinities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 714 Displaying Tunnel Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 715 Understanding the Sessions of Roaming Users. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 715 Requirements for Roaming to Succeed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 716 Effects of Timers on Roaming. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 716 Monitoring Roaming Sessions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 717 Displaying NAT Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 717 Mobility Domain Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 718 Configuring WLC-WLC Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 721 Monitoring the VLANs and Tunnels in a Mobility Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 721 Displaying Roaming Stations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 722 Displaying Roaming VLANs and Affinities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 722

xvi


Displaying Tunnel Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 723 Understanding the Sessions of Roaming Users. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 723 Requirements for Roaming to Succeed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 724 Effects of Timers on Roaming. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 724 Monitoring Roaming Sessions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 725 Displaying NAT Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 725 Mobility Domain Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .726 Monitoring the VLANs and Tunnels in a Mobility Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .729 Displaying Roaming Stations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .729 Displaying Roaming VLANs and Affinities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .729 Displaying Tunnel Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .730 Understanding the Sessions of Roaming Users. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .730 Requirements for Roaming to Succeed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 732 Effects of Timers on Roaming. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 732 Monitoring Roaming Sessions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 733 Displaying NAT Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 733 Mobility Domain Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .734 About Network Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 737 About the Network Domain Feature. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 737 Network Domain Seed Affinity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .739 Configuring a Network Domain. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 741 Network Domain Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 741 Configuring Network Domain Seeds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 741 Specifying Network Domain Seed Peer Relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 742 Configuring Network Domain Members . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 742 Displaying Network Domain Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .743 Clearing Network Domain Configuration from an WLC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .743 Clearing a Network Domain Seed from an WLC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .743 Clearing a Network Domain Peer from a Network Domain Seed. . . . . . . . . . . . . . . . . . . . . . . . . . . .744 Clearing Network Domain Seed or Member Configuration from an WLC Switch . . . . . . . . . . . .744 Network Domain Configuration Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 745 Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .745 Network Domain Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .745 Configuring and Managing Spanning Tree Protocol. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 791 Enabling the Spanning Tree Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 791 Changing Standard Spanning Tree Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 791 Bridge Priority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .792 Port Cost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .792 Port Priority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .792 Changing the Bridge Priority. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .792 Changing STP Port Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .793 Changing the STP Port Cost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .793 Resetting the STP Port Cost to the Default Value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .793 Changing the STP Port Priority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .794 Resetting the STP Port Priority to the Default Value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .794 Changing Spanning Tree Timers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .794 Changing the STP Hello Interval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .795 Changing the STP Forwarding Delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .795 Configuring and Managing STP Fast Convergence Features. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .795 Port Fast Convergence. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 796

xvii

Backbone Fast Convergence. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 796 Uplink Fast Convergence. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 796 Configuring Port Fast Convergence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 796 Displaying Port Fast Convergence Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 796 Configuring Backbone Fast Convergence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 797 Displaying the Backbone Fast Convergence State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 797 Displaying Uplink Fast Convergence Information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 798 Displaying Spanning Tree Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 798 Displaying STP Bridge and Port Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 798 Displaying the STP Port Cost by VLAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 799 Displaying Blocked STP Ports. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 799 Displaying Spanning Tree Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 800 Clearing STP Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 802 Spanning Tree Configuration Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 802 Configuring Quality of Service. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 807 About QoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 807 Summary of QoS Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 807 SIP Awareness. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 809 End-to-End QoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 810 QoS Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 810 QoS Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 811 Static CoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 812 CoS ACLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 812 Bandwidth Management for QoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 818 U-APSD Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 818 Call Admission Control. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 819 Session Timers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 819 Broadcast Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 819 Changing QoS Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 819 Changing the QoS Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 820 Enabling U-APSD Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 820 Configuring Call Admission Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 820 Enabling CAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 820 Changing the Maximum Number of Active Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 820 Configuring Session Timers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 821 Configuring Static CoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 821 Changing CoS Mappings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .822 Using the Client DSCP Value to Classify QoS Level. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .822 Enabling Broadcast Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .822 Displaying QoS Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .823 Displaying QoS Settings for a Radio Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .823 Displaying QoS Settings for a Service Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .823 Displaying CAC Session Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 824 Displaying CoS Mappings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 825 Displaying the Default CoS Mappings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 825 Displaying a DSCP-to-CoS Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 825 Displaying a CoS-to-DSCP Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 825 Displaying the DSCP Table. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 826 Displaying WLA Forwarding Queue Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 826 Displaying Per-Session Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 826

xviii


Configuring and Managing IGMP Snooping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 829 Enabling or Disabling IGMP Snooping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 829 Enabling or Disabling Proxy Reporting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 829 Enabling the Pseudo-Querier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 829 Changing IGMP Timers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 830 Changing the Query Interval. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 830 Changing the Other-Querier-Present Interval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 830 Changing the Query Response Interval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 830 Changing the Last Member Query Interval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 830 Changing Robustness. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 831 Enabling Router Solicitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 831 Changing the Router Solicitation Interval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 831 Configuring Static Multicast Ports. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 831 Adding or Removing a Static Multicast Router Port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .832 Adding or Removing a Static Multicast Receiver Port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .832 Displaying Multicast Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .832 Displaying Multicast Configuration Information and Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . .832 Displaying Multicast Statistics Only . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 834 Clearing Multicast Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 834 Displaying Multicast Queriers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 834 Displaying Multicast Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 834 Displaying Multicast Receivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 835 Link Layer Discovery Protocol (LLDP). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .837 Link Layer Discovery Protocol for Media Endpoint Devices (LLDP-MED) . . . . . . . . . . . . . . . . . . 838 Displaying LLDP Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 839 Rogue Detection and Countermeasures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 843 About Rogues and RF Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 843 Rogue Access Points and Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 843 Rogue Classification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 843 Rogue Detection Lists. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 844 RF Detection Scans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 845 Dynamic Frequency Selection (DFS). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 846 Countermeasures. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .847 Mobility Domain Requirement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .847 Summary of Rogue Detection Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .847 Configuring Rogue Detection Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 849 Configuring a Permitted SSID List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 849 Configuring a Client Blacklist. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 850 RF Dynamic BlackList . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 850 Configuring a Rogue List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 851 Configuring an Neighbor List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 851 Enabling Countermeasures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 852 Using On-Demand Countermeasures in a Mobility Domain. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 853 Disabling or Reenabling Active Scan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 853 Enabling WLA Signatures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 854 Disabling or Reenabling Logging of Rogues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 854 Enabling Rogue and Countermeasures Notifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 854 IDS and DoS Alerts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 854 Flood Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 855 DoS Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 855

xix

Netstumbler and Wellenreiter Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 856 Wireless Bridge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 856 Ad-Hoc Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 856 Weak WEP Key Used by Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 856 Displaying Statistics Counters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 856 IDS Log Message Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 856 Displaying RF Detection Information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 861 Displaying Rogue Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 861 Displaying Rogue Detection Counters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 862 Displaying SSID or BSSID Information for a Mobility Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 864 Displaying RF Detect Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 865 Displaying the APs Detected by an WLA Radio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 866 Displaying Countermeasures Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 866 WLA Intrusion Detection System (IDS) Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 867 Configuring Adaptive Channel Planner (Auto-Tune Enhancements) . . . . . . . . . . . . . . . . . . . . . . . . . 869 Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 869 Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 869 Using the CLI to Configure ACP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 870 Scheduling ACP on the Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 871 Configuring Specific Channel Sets for ACP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 871 Adding ACP to the Radio Channel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .872 Grouping Radios by Interference Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .872 Configuring Auto-tune Convergence Delay. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .872 Displaying ACP Information at the CLI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .872 Changing Power Tuning Settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .873 Enabling Power Tuning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .873 Changing the Power Tuning Interval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .874 Changing the Maximum Default Power Allowed On a Radio . . . . . . . . . . . . . . . . . . . . . . . . . .874 Displaying RF Auto-Tuning Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .874 Displaying RF Auto-Tuning Settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .874 Displaying RF Neighbors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .875 Displaying RF Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .875 RF Load Balancing Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 876 Configuring RF Load Balancing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 876 Disabling or Enabling RF Load Balancing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 877 Assigning Radios to Load Balancing Groups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 877 Specifying Band Preference for RF Load Balancing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 877 Setting Strictness for RF Load Balancing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 877 Exempting an SSID from RF Load Balancing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 878 Configuring Additional RF Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 878 RF Auto-Tuning Settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 879 Selecting Available Channels on the 802.11a Radio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 879 Disabling or Reenabling Channel Tuning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 879 Changing Power Tuning Settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 880 Enabling Power Tuning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 880 Changing the Power Tuning Interval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 880 Changing the Maximum Default Power Allowed On a Radio . . . . . . . . . . . . . . . . . . . . . . . . . 880 Locking Down Tuned Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 880 Displaying RF Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 881 Displaying RF Settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 881

xx


Displaying RF Neighbors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 882 Displaying RF Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 882 Configuring RF Load Balancing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 883 RF Load Balancing Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 883 Configuring RF Load Balancing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 883 Disabling or Enabling RF Load Balancing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 883 Assigning Radios to Load Balancing Groups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 884 Specifying Band Preference for RF Load Balancing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 884 Setting Strictness for RF Load Balancing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 884 Exempting an SSID from RF Load Balancing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 885 Configuring Spectrum Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 887 Providing Data to the Classifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 888 Configuring Data Path Encryption. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 901 Configuring and Managing Security ACLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 903 About Security Access Control Lists. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 903 Overview of Security ACL Commands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 903 Security ACL Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 904 Putting ACLs in Order and Applying to Traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 904 Traffic Direction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 904 Selection of User ACLs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 905 Creating and Committing a Security ACL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 905 Setting a Source IP ACL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 905 Wildcard Masks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 907 Class of Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 907 Setting an ICMP ACL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 907 Creating TCP and UDP ACLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 909 Setting a TCP ACL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 909 Setting a UDP ACL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 909 Creating a MAC Address ACL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 910 Determining the ACE Order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 910 Committing a Security ACL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 910 Viewing Security ACL Information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 910 Viewing the Edit Buffer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 911 Viewing Committed Security ACLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 911 Viewing Security ACL Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 911 Displaying Security ACL Hits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 912 Clearing Security ACLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 913 Mapping Security ACLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 913 Mapping User-Based Security ACLs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 914 Mapping Security ACLs to Ports, VLANs, Virtual Ports, or Distributed WLAs . . . . . . . . . . . . . . . . 915 Displaying ACL Maps to Ports, VLANs, and Virtual Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 915 Clearing a Security ACL Map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 916 Modifying a Security ACL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 917 Adding Another ACE to a Security ACL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 917 Adding an ACE Before an Existing ACE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 918 Modifying an Existing Security ACL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 919 Clearing Security ACLs from the Edit Buffer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 920 Using ACLs to Change CoS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 921 Filtering Based on DSCP Values. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .922 Using the DSCP Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .922

xxi

Using the Precedence and ToS Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .923 Enabling Prioritization for Legacy Voice over IP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 924 General Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 924 Enabling VoIP Support for TeleSym VoIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 925 Enabling SVP Optimization for SpectraLink Phones. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 925 Known Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 926 Configuring a Service Profile for RSN (WPA2). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 926 Configuring a Service Profile for WPA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 926 Configuring a Radio Profile. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .927 Configuring a VLAN for Voice Clients. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .927 Configuring an ACL to Prioritize Voice Traffic. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 928 Mapping ACLs to Both Traffic Directions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 928 Setting 802.11b/g Radios to 802.11b (for Siemens SpectraLink VoIP Phones only) . . . 929 Disabling RF Auto-Tuning Before Upgrading a SpectraLink Phone . . . . . . . . . . . . . . . . . . . 929 Restricting Client-To-Client Forwarding Among IP-Only Clients. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 929 Security ACL Configuration Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 930 Configuring IPv6 Traffic Filtering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 931 Enabling and Logging Into Web View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 935 System Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 935 Browser Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 935 WLC Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 935 Enabling TLS 1.0, SSL 2.0, or SSL 3.0 in Windows Internet Explorer . . . . . . . . . . . . . . . . . . . . . . . 935 Logging Into Web View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 935 WebView Quick Start . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 936 Configuring Location Based Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 941 Configuring WLA Radios to Listen for AeroScout RFID Tags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 941 Locating an RFID Tag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 942 Using an AeroScout Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 942 Using RingMaster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 943 Troubleshooting an WLC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .947 Fixing Common WLC Setup Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .947 Recovering the System After Losing the Enable Password . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 948 WLC2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 948 All Other Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 949 Configuring and Managing the System Log. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 949 Log Message Components. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 949 Logging Destinations and Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 950 Using Log Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 950 Logging to the Log Buffer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 951 Logging to the Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 952 Logging Messages to a Syslog Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 952 Setting Telnet Session Defaults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 953 Changing the Current Telnet Session Defaults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 953 Logging to the Trace Buffer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 954 Enabling Mark Messages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 954 Saving Trace Messages in a File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 954 Displaying the Log Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 954 Running Traces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 955 Using the Trace Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 955 Tracing Authentication Activity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 955

xxii


Tracing Session Manager Activity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 956 Tracing Authorization Activity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 956 Tracing 802.1X Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 956 Displaying a Trace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 956 Stopping a Trace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 956 About Trace Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .957 Displaying Trace Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .957 Copying Trace Results to a Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .957 Clearing the Trace Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 958 List of Trace Areas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 958 Using Show Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 958 Viewing VLAN Interfaces. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 958 Viewing AAA Session Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 958 Viewing FDB Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 959 Viewing ARP Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 960 Port Mirroring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 960 Configuration Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 960 Configuring Port Mirroring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 960 Displaying the Port Mirroring Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 961 Clearing the Port Mirroring Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 961 Remotely Monitoring Traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 961 How Remote Traffic Monitoring Works. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 961 Using Snoop Filters on Radios Configured for Active Scanning . . . . . . . . . . . . . . . . . . . . . . . . 961 All Snooped Traffic Is Sent in the Clear . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 961 Best Practices for Remote Traffic Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 962 Configuring a Snoop Filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 962 Displaying Configured Snoop Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 963 Editing a Snoop Filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 963 Deleting a Snoop Filter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 963 Mapping a Snoop Filter to a Radio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 964 Displaying the Snoop Filters Mapped to a Radio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 964 Displaying the Snoop Filter Mappings for All Radios. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 964 Removing Snoop Filter Mappings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 964 Enabling or Disabling a Snoop Filter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 965 Displaying Remote Traffic Monitoring Statistics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 965 Preparing an Observer and Capturing Traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 965 Capturing System Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 966 The show tech-support Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 967 Core Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 967 Debug Messages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 969 Sending Information to TAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 969 Traffic Ports Used by MSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 971 Supported RADIUS Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .973 Supported Standard and Extended Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .973 Juniper Networks Vendor-Specific Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 977 Managing Keys and Certificates. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .979 Why Use Keys and Certificates? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 979 Wireless Security through TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 979 PEAP-MS-CHAP-V2 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 979 About Keys and Certificates. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 980

xxiii

Public Key Infrastructures. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 980 Public and Private Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 981 Digital Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 981 PKCS #7, PKCS #10, and PKCS #12 Object Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 982 Certificates Automatically Generated by MSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 982 Creating Keys and Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 983 Selecting the Appropriate Certificate Installation Method for Your Network. . . . . . . . . . . . . . . 983 Creating Public-Private Key Pairs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 984 Generating Self-Signed Certificates. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 985 Support for Extended Certificate Chains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 985 Installing a Key Pair and Certificate from a PKCS #12 Object File . . . . . . . . . . . . . . . . . . . . . . . . . . 986 Creating a CSR and Installing a Certificate from a PKCS #7 Object File. . . . . . . . . . . . . . . . . . . . 986 Installing a CA Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 987 Displaying Certificate and Key Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 988 Invalidating Existing Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 988 Key and Certificate Configuration Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 988 Creating Self-Signed Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 989 Installing CA-Signed Certificates from PKCS #12 Object Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 991 Installing CA-Signed Certificates Using PKCS #10 Object File and PKCS #7 Object File . . . 992

xxiv


Part 1 - Using MSS System Tools


1

2


About This Guide

About This Guide The Mobility System Software (MSS™) documentation set describes configuring and managing the Juniper Networks Mobility System™ wireless LAN (WLAN) using command line interface (CLI) commands that you enter on a Wireless LAN Controller™. Read the documentation set if you are a network administrator responsible for managing Wireless LAN Controller (WLC) switches and Wireless LAN Access™ (WLA™) points in a network.

Juniper Networks Mobility System The Juniper Networks Mobility System is an enterprise-class WLAN solution that seamlessly integrates with an existing wired enterprise network. The Juniper system provides secure connectivity to both wireless and wired users in large environments such as office buildings, hospitals, and university campuses and in small environments such as branch offices. The Juniper Mobility System fulfills the three fundamental requirements of an enterprise WLAN: It eliminates the distinction between wired and wireless networks, allows users to work safely from anywhere (secure mobility), and provides a comprehensive suite of intuitive tools for planning and managing the network before and after deployment, greatly easing the operational burden on IT resources. The Juniper Networks Mobility System consists of the following components: RingMaster tool suite— A full-featured graphical user interface (GUI) application used to plan, configure, deploy, and manage a WLAN and its users One or more Wireless LAN Controller™ (WLC™) switches— Distributed, intelligent machines for managing user connectivity, connecting and powering Wireless LAN Access (WLA) points, and connecting the WLAN to the wired network backbone Mobility System Software™ (MSS™)— The operating system that runs all WLC switches and WLAs in a WLAN, and is accessible through a command-line interface (CLI), the Web View interface, or the RingMaster GUI.

Documentation Consult the following documents to plan, install, configure, and manage a Juniper Networks Mobility System.

Planning, Configuration, and Deployment RingMaster Quick Start Guide— Instructions for installing and configuring RingMaster services. RingMaster Planning Guide— Instructions for planning, deploying, and managing the entire WLAN with the RingMaster tool suite. Read this guide to learn how to plan wireless services. RingMaster Configuration Guide— Instructions for configuring the WLAN with the RingMaster tool suite. Read this guide to learn how to configure wireless services. RingMaster Management Guide— Instructions for managing and monitoring your WLAN using the RingMaster tool suite.


Juniper Networks Mobility System

3

Installation Juniper Wireless LAN Controller Hardware Installation Guide— Instructions and specifications for installing an WLC. JuniperMobility System Software Quick Start Guide— Instructions for performing basic setup of secure (802.1X) and guest (WebAAA™) access, and for configuring a Mobility Domain for roaming Juniper Indoor Wireless LAN Access Installation Guide— Instructions and specifications for installing an WLA access point and connecting it to an WLC. Juniper Outdoor Wireless LAN Access Installation Guide— Instructions and specifications for installing outdoor access points and connecting to an WLC. Juniper Regulatory Information— Important safety instructions and compliance information that you must read before installing Juniper Networks products.

Configuration and Management Juniper Mobility System Software Configuration Guide— Instructions for configuring advanced features through the MSS CLI. Juniper Mobility System Software Command Reference— Functional and alphabetic reference to all MSS commands supported on WLCs and WLAs.

Documentation Symbols Key

Informational Note: Indicates important features or instructions.

Caution: This situation or condition can lead to data loss or damage to the product or other property

Warning: Alerts you to the risk of personal injury or death.

Hypertext Links Hypertext links appear in Blue. For example, this is a link to END USER LICENSE AGREEMENT.

Text and Syntax Conventions Juniper guides use the following text and syntax conventions: Table 1.

Text and Syntax Conventions

Convention

Description

Example

Bold text like this

Represents text that you type.

Represents text that you type.

4



About This Guide

Table 1.

Text and Syntax Conventions

Convention

Description

Example

Fixed-width text like this

Represents output that appears on the

user@host> show chassis alarms

terminal screen.

No alarms currently active

Italic text like this

Introduces important new terms.

A policy term is a named structure that defines match conditions and actions.

Identifies book names. Identifies RFC and Internet draft titles

Italic text like this

Represents variables (options for which you substitute a value) in commands or configuration statements.

Junos OS System Basics Configuration Guide RFC 1997, BGP Communities Attribute Configure the machine’s domain name: [edit] root@# set system domain-name domain-name

Plain text like this

Represents names of configuration statements, commands, files, and directories; IP addresses; configuration hierarchy levels; or labels on routing platform components.

To configure a stub area, include the stub statement at the [edit protocols ospf area area-id] hierarchy level. The console port is labeled CONSOLE.

< > (angle brackets)

Enclose optional keywords or variables.

stub ;

| (pipe symbol)

Indicates a choice between the mutually exclusive keywords or variables on either side of the symbol. The set of choices is often enclosed in parentheses for clarity.

broadcast | multicast

# (pound sign)

Indicates a comment specified on the same line as the configuration statement to which it applies

rsvp { # Required for dynamic MPLS only

[ ] (square brackets)

Identify a level in the configuration hierarchy.

[edit]

(string1 | string2 | string3)

routing-options { static { route default { nexthop address; retain; } } } ; (semicolon)

Identifies a leaf statement at a configuration hierarchy level.

Documentation Feedback We encourage you to provide feedback, comments, and suggestions so that we can improve the documentation. Send e-mail to [email protected] with the following: Document URL or title Page number if applicable Software version Your name and company



5

Requesting Technical Support Technical product support is available through the Juniper Networks Technical Assistance Center (JTAC). If you are a customer with an active J-Care or JNASC support contract, or are covered under warranty, and need post-sales technical support, you can access our tools and resources online or open a case with JTAC. JTAC policies—For a complete understanding of our JTAC procedures and policies, Review the JTAC User Guide located at http://www.juniper.net/us/en/local/pdf/resourceguides/ 7100059-en.pdf Product warranties—For product warranty information, visit http://www.juniper.net/support/warranty/ . JTAC hours of operation—The JTAC centers have resources available 24 hours a day, 7 days a week, 365 days a year.

Self-Service Online Tools and Resources For quick and easy problem resolution, Juniper Networks has designed an online self-service portal called the Customer Support Center (CSC) that provides you with the following features: Find CSC offerings: http://www.juniper.net/customers/support/ Search for known bugs: http://www2.juniper.net/kb/ Find product documentation: http://www.juniper.net/techpubs/ Find solutions and answer questions using our Knowledge Base: http://kb.juniper.net/ Download the latest versions of software and review release notes: http://www.juniper.net/customers/csc/software/ Search technical bulletins for relevant hardware and software notifications: https://www.juniper.net/alerts/ Join and participate in the Juniper Networks Community Forum: http://www.juniper.net/company/communities/ Open a case online in the CSC Case Management tool: http://www.juniper.net/cm/ To verify service entitlement by product serial number, use our Serial Number Entitlement (SNE) Tool: https://tools.juniper.net/SerialNumberEntitlementSearch/

Opening a Case with JTAC You can open a case with JTAC on the Web or by telephone. Use the Case Management tool in the CSC at http://www.juniper.net/cm/ . Call 1-888-314-JTAC (1-888-314-5822 toll-free in the USA, Canada, and Mexico). For international or direct-dial options in countries without toll-free numbers, see http://www.juniper.net/support/requesting-support.html .

6

Requesting Technical Support


About This Guide

END USER LICENSE AGREEMENT READ THIS END USER LICENSE AGREEMENT (“AGREEMENT”) BEFORE DOWNLOADING, INSTALLING, OR USING THE SOFTWARE. BY DOWNLOADING, INSTALLING, OR USING THE SOFTWARE OR OTHERWISE EXPRESSING YOUR AGREEMENT TO THE TERMS CONTAINED HEREIN, YOU (AS CUSTOMER OR IF YOU ARE NOT THE CUSTOMER, AS A REPRESENTATIVE/AGENT AUTHORIZED TO BIND THE CUSTOMER) CONSENT TO BE BOUND BY THIS AGREEMENT. IF YOU DO NOT OR CANNOT AGREE TO THE TERMS CONTAINED HEREIN, THEN (A) DO NOT DOWNLOAD, INSTALL, OR USE THE SOFTWARE, AND (B) YOU MAY CONTACT JUNIPER NETWORKS REGARDING LICENSE TERMS. 1. The Parties. The parties to this Agreement are (i) Juniper Networks, Inc. (if the Customer’s principal office is located in the Americas) or Juniper Networks (Cayman) Limited (if the Customer’s principal office is located outside the Americas) (such applicable entity being referred to herein as “Juniper”), and (ii) the person or organization that originally purchased from Juniper or an authorized Juniper reseller the applicable license(s) for use of the Software (“Customer”) (collectively, the “Parties”). 2. The Software. In this Agreement, “Software” means the program modules and features of the Juniper or Juniper-supplied software, for which Customer has paid the applicable license or support fees to Juniper or an authorized Juniper reseller, or which was embedded by Juniper in equipment which Customer purchased from Juniper or an authorized Juniper reseller. “Software” also includes updates, upgrades and new releases of such software. “Embedded Software” means Software which Juniper has embedded in or loaded onto the Juniper equipment and any updates, upgrades, additions or replacements which are subsequently embedded in or loaded onto the equipment. 3. License Grant. Subject to payment of the applicable fees and the limitations and restrictions set forth herein, Juniper grants to Customer a non-exclusive and non-transferable license, without right to sublicense, to use the Software, in executable form only, subject to the following use restrictions: a. Customer shall use Embedded Software solely as embedded in, and for execution on, Juniper equipment originally purchased by Customer from Juniper or an authorized Juniper reseller. b. Customer shall use the Software on a single hardware chassis having a single processing unit, or as many chassis or processing units for which Customer has paid the applicable license fees; provided, however, with respect to the Steel-Belted Radius or Odyssey Access Client software only, Customer shall use such Software on a single computer containing a single physical random access memory space and containing any number of processors. Use of the Steel-Belted Radius or IMS AAA software on multiple computers or virtual machines (e.g., Solaris zones) requires multiple licenses, regardless of whether such computers or virtualizations are physically contained on a single chassis.



7

c.

Product purchase documents, paper or electronic user documentation, and/or the particular licenses purchased by Customer may specify limits to Customer’s use of the Software. Such limits may restrict use to a maximum number of seats, registered endpoints, concurrent users, sessions, calls, connections, subscribers, clusters, nodes, realms, devices, links, ports or transactions, or require the purchase of separate licenses to use particular features, functionality, services, applications, operations, or capabilities, or provide throughput, performance, configuration, bandwidth, interface, processing, temporal, or geographical limits. In addition, such limits may restrict the use of the Software to managing certain kinds of networks or require the Software to be used only in conjunction with other specific Software.Customer’s use of the Software shall be subject to all such limitations and purchase of all applicable licenses.

d. For any trial copy of the Software, Customer’s right to use the Software expires 30 days after download, installation or use of the Software. Customer may operate the Software after the 30-day trial period only if Customer pays for a license to do so. Customer may not extend or create an additional trial period by re-installing the Software after the 30-day trial period. e. The Global Enterprise Edition of the Steel-Belted Radius software may be used by Customer only to manage access to Customer’s enterprise network. Specifically, service provider customers are expressly prohibited from using the Global Enterprise Edition of the Steel-Belted Radius software to support any commercial network access services. The foregoing license is not transferable or assignable by Customer. No license is granted herein to any user who did not originally purchase the applicable license(s) for the Software from Juniper or an authorized Juniper reseller. 4. Use Prohibitions. Notwithstanding the foregoing, the license provided herein does not permit the Customer to, and Customer agrees not to and shall not: (a) modify, unbundle, reverse engineer, or create derivative works based on the Software; (b) make unauthorized copies of the Software (except as necessary for backup purposes); (c) rent, sell, transfer, or grant any rights in and to any copy of the Software, in any form, to any third party; (d) remove any proprietary notices, labels, or marks on or in any copy of the Software or any product in which the Software is embedded; (e) distribute any copy of the Software to any third party, including as may be embedded in Juniper equipment sold in the secondhand market; (f) use any ‘locked’ or key-restricted feature, function, service, application, operation, or capability without first purchasing the applicable license(s) and obtaining a valid key from Juniper, even if such feature, function, service, application, operation, or capability is enabled without a key; (g) distribute any key for the Software provided by Juniper to any third party; (h) use the Software in any manner that extends or is broader than the uses purchased by Customer from Juniper or an authorized Juniper reseller; (i) use Embedded Software on non-Juniper equipment; (j) use Embedded Software (or make it available for use) on Juniper equipment that the Customer did not originally purchase from Juniper or an authorized Juniper reseller; (k) disclose the results of testing or benchmarking of the Software to any third party without the prior written consent of Juniper; or (l) use the Software in any manner other than as expressly provided herein. 5. Audit. Customer shall maintain accurate records as necessary to verify compliance with this Agreement. Upon request by Juniper, Customer shall furnish such records to Juniper and certify its compliance with this Agreement.

8



About This Guide

6. Confidentiality. The Parties agree that aspects of the Software and associated documentation are the confidential property of Juniper. As such, Customer shall exercise all reasonable commercial efforts to maintain the Software and associated documentation in confidence, which at a minimum includes restricting access to the Software to Customer employees and contractors having a need to use the Software for Customer’s internal business purposes. 7. Ownership. Juniper and Juniper’s licensors, respectively, retain ownership of all right, title, and interest (including copyright) in and to the Software, associated documentation, and all copies of the Software. Nothing in this Agreement constitutes a transfer or conveyance of any right, title, or interest in the Software or associated documentation, or a sale of the Software, associated documentation, or copies of the Software. 8. Warranty, Limitation of Liability, Disclaimer of Warranty. The warranty applicable to the Software shall be as set forth in the warranty statement that accompanies the Software (the “Warranty Statement”). Nothing in this Agreement shall give rise to any obligation to support the Software. Support services may be purchased separately. Any such support shall be governed by a separate, written support services agreement. TO THE MAXIMUM EXTENT PERMITTED BY LAW, JUNIPER SHALL NOT BE LIABLE FOR ANY LOST PROFITS, LOSS OF DATA, OR COSTS OR PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES, OR FOR ANY SPECIAL, INDIRECT, OR CONSEQUENTIAL DAMAGES ARISING OUT OF THIS AGREEMENT, THE SOFTWARE, OR ANY JUNIPER OR JUNIPER-SUPPLIED SOFTWARE. IN NO EVENT SHALL JUNIPER BE LIABLE FOR DAMAGES ARISING FROM UNAUTHORIZED OR IMPROPER USE OF ANY JUNIPER OR JUNIPER-SUPPLIED SOFTWARE. EXCEPT AS EXPRESSLY PROVIDED IN THE WARRANTY STATEMENT TO THE EXTENT PERMITTED BY LAW, JUNIPER DISCLAIMS ANY AND ALL WARRANTIES IN AND TO THE SOFTWARE (WHETHER EXPRESS, IMPLIED, STATUTORY, OR OTHERWISE), INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NONINFRINGEMENT. IN NO EVENT DOES JUNIPER WARRANT THAT THE SOFTWARE, OR ANY EQUIPMENT OR NETWORK RUNNING THE SOFTWARE, WILL OPERATE WITHOUT ERROR OR INTERRUPTION, OR WILL BE FREE OF VULNERABILITY TO INTRUSION OR ATTACK. In no event shall Juniper’s or its suppliers’ or licensors’ liability to Customer, whether in contract, tort (including negligence), breach of warranty, or otherwise, exceed the price paid by Customer for the Software that gave rise to the claim, or if the Software is embedded in another Juniper product, the price paid by Customer for such other product. Customer acknowledges and agrees that Juniper has set its prices and entered into this Agreement in reliance upon the disclaimers of warranty and the limitations of liability set forth herein, that the same reflect an allocation of risk between the Parties (including the risk that a contract remedy may fail of its essential purpose and cause consequential loss), and that the same form an essential basis of the bargain between the Parties. 9. Termination. Any breach of this Agreement or failure by Customer to pay any applicable fees due shall result in automatic termination of the license granted herein. Upon such termination, Customer shall destroy or return to Juniper all copies of the Software and related documentation in Customer’s possession or control.



9

10. Taxes. All license fees payable under this agreement are exclusive of tax. Customer shall be responsible for paying Taxes arising from the purchase of the license, or importation or use of the Software. If applicable, valid exemption documentation for each taxing jurisdiction shall be provided to Juniper prior to invoicing, and Customer shall promptly notify Juniper if their exemption is revoked or modified. All payments made by Customer shall be net of any applicable withholding tax. Customer will provide reasonable assistance to Juniper in connection with such withholding taxes by promptly: providing Juniper with valid tax receipts and other required documentation showing Customer’s payment of any withholding taxes; completing appropriate applications that would reduce the amount of withholding tax to be paid; and notifying and assisting Juniper in any audit or tax proceeding related to transactions hereunder. Customer shall comply with all applicable tax laws and regulations, and Customer will promptly pay or reimburse Juniper for all costs and damages related to any liability incurred by Juniper as a result of Customer’s non-compliance or delay with its responsibilities herein. Customer’s obligations under this Section shall survive termination or expiration of this Agreement. 11. Export. Customer agrees to comply with all applicable export laws and restrictions and regulations of any United States and any applicable foreign agency or authority, and not to export or re-export the Software or any direct product thereof in violation of any such restrictions, laws or regulations, or without all necessary approvals. Customer shall be liable for any such violations. The version of the Software supplied to Customer may contain encryption or other capabilities restricting Customer’s ability to export the Software without an export license. 12. Commercial Computer Software. The Software is “commercial computer software” and is provided with restricted rights. Use, duplication, or disclosure by the United States government is subject to restrictions set forth in this Agreement and as provided in DFARS 227.7201 through 227.7202-4, FAR 12.212, FAR 27.405(b)(2), FAR 52.227-19, or FAR 52.227-14(ALT III) as applicable. 13. Interface Information. To the extent required by applicable law, and at Customer's written request, Juniper shall provide Customer with the interface information needed to achieve interoperability between the Software and another independently created program, on payment of applicable fee, if any. Customer shall observe strict obligations of confidentiality with respect to such information and shall use such information in compliance with any applicable terms and conditions upon which Juniper makes such information available. 14. Third Party Software. Any licensor of Juniper whose software is embedded in the Software and any supplier of Juniper whose products or technology are embedded in (or services are accessed by) the Software shall be a third party beneficiary with respect to this Agreement, and such licensor or vendor shall have the right to enforce this Agreement in its own name as if it were Juniper. In addition, certain third party software may be provided with the Software and is subject to the accompanying license(s), if any, of its respective owner(s). To the extent portions of the Software are distributed under and subject to open source licenses obligating Juniper to make the source code for such portions publicly available (such as the GNU General Public License (“GPL”) or the GNU Library General Public License (“LGPL”)), Juniper will make such source code portions (including Juniper modifications, as appropriate) available upon request for a period of up to three years from the date of distribution. Such request can be made in writing to Juniper Networks, Inc., 1194 N. Mathilda Ave., Sunnyvale, CA 94089, ATTN: General Counsel. You may obtain a copy of the GPL at http://www.gnu.org/licenses/gpl.html, and a copy of the LGPL at http://www.gnu.org/licenses/lgpl.html .

10



About This Guide

15. Miscellaneous. This Agreement shall be governed by the laws of the State of California without reference to its conflicts of laws principles. The provisions of the U.N. Convention for the International Sale of Goods shall not apply to this Agreement. For any disputes arising under this Agreement, the Parties hereby consent to the personal and exclusive jurisdiction of, and venue in, the state and federal courts within Santa Clara County, California. This Agreement constitutes the entire and sole agreement between Juniper and the Customer with respect to the Software, and supersedes all prior and contemporaneous agreements relating to the Software, whether oral or written (including any inconsistent terms contained in a purchase order), except that the terms of a separate written agreement executed by an authorized Juniper representative and Customer shall govern to the extent such terms are inconsistent or conflict with terms contained herein. No modification to this Agreement nor any waiver of any rights hereunder shall be effective unless expressly assented to in writing by the party to be charged. If any portion of this Agreement is held invalid, the Parties agree that such invalidity shall not affect the validity of the remainder of this Agreement. This Agreement and associated documentation has been written in the English language, and the Parties agree that the English version will govern. (For Canada: Les parties aux présentés confirment leur volonté que cette convention de même que tous les documents y compris tout avis qui s'y rattaché, soient redigés en langue anglaise. (Translation: The parties confirm that this Agreement and all related documentation is and will be in the English language)).



11

12



Adding Licenses to an WLC

Adding Licenses to an WLC With MSS, WLAs and certain features require licensing to become active on the network. Be sure to review the MSS Release Notes when upgrading from one version of MSS to the next version.

Installing Upgrade Activation Keys on an WLC WLA licensing is supported on WLC platforms as shown in Table 2: Table 2.

Licensing and Upgrade Increments for the WLC Models

WLC Model

Base WLA Support

Maximum WLA Support

Upgrade Increment

WLC800R

16

128

16

WLC200R

32

192

32

WLC2800

64

512

64

WLC100

4

32

4

JunosV WLC

4

256

1, 8, or 32 From October 2013 onwards, the incremental upgrade is: 10 0r 100

Informational Note: If you downgrade to a previous version of MSS that does not support the higher capacity licenses, the number of allowed WLAs is reduced to comply with the older software limitations.

WLC Platform Feature Licensing Feature licensing is supported on WLC platforms as show in Table 3. Table 3.

WLC Feature Licensing Matrix

WLC Model

Advance Voice Module

High Availability Module Mesh/Bridging Module

WLC2

Supported

Not Supported

Up to 4 WLAs (16 WLAs in Cluster mode)

WLC8

Supported

Not Supported

Up to 12 WLAs (48 in Cluster mode)

WLC800R

Supported

Supported

Up to 128 WLAs (512 WLAs in Cluster mode)

WLC200R

Supported

Supported


WLC2800

Supported

Supported


WLC100

Supported

Supported

Up to 32 WLAs

JunosV WLC

Supported

Supported

(128 in Cluster mode) Up to 256 WLAs (2048 in Cluster mode)


Installing Upgrade Activation Keys on an WLC

13

WLC License Upgrades To upgrade an WLC license: 1. Obtain a license coupon for the upgrade from Juniper Networks or your channel partner. 2. Establish a management session with the WLC to display the serial number. To display the serial number, type the following command: WLC> show version In the following example, the WLC serial number is 1234567890: Mobility System Software, Version: 7.7.0.1 REL Copyright (c) 2013 Juniper Networks, Inc. All rights reserved. Build Information: (build#0) REL_7_7_1_branch 2008-08-02 14:21:00 Model:

WLC800R

Hardware Mainboard:

version 24 ; revision 3 ; FPGA version 24

PoE board:

version 1 ; FPGA version 6

Serial number

1234567890

Flash:

7.7.0.2.0.0.49

Kernel:

3.0.0#112: Wed Aug

BootLoader:

7.7 / 7.7.1

- md0a 2 10:26:32 PDT 2009

3. Use a Web browser to access the Juniper Networks license server at the following URL: http://www.juniper.net/support/product_licenses 4. Type your e-mail address in the E-mail and Confirm E-mail fields. 5. Select your WLC model from the Product Selection list. 6. Type or copy and paste the WLC serial number into the Product Serial Number field, and click OK. The Product Licensing page appears. 7. Type the coupon activation code(s) into the Coupon Code(s) fields and click OK. The Licensing Confirmation page appears, and displays the activation key (also called the license key). 8. Highlight and copy the entire activation key. 9. On the WLC, use the following command at the enable (configuration) level of the CLI to install the activation key: set license activation-key In the following example, an activation key for an additional 96 WLAs is installed on an WLC200: WLC200# set license 3B02-D821-6C19-CE8B-F20E success: license accepted 10. Verify installation of the new license by typing the following command: WLC200# show licenses Following is the example output of the above command:

14

WLC Platform Feature Licensing


Adding Licenses to an WLC

Feature: 96 additional WLAs Informational Note: Support for the additional WLAs begins immediately. You do not need to restart the WLC to place the upgrade into effect.



15

16



New Controllers Supported in MSS 9.0

New Controllers Supported in MSS 9.0 Support for JunosV Wireless LAN Controller (JunosV WLC) The next-generation Juniper Networks JunosV Wireless LAN Controller (JunosV WLC) is a virtual controller using a cloud-based architecture with physical access points. The current functionality of a physical controller is available on the virtual controller, and the virtual controller can support up to 256 access points. Before you install the virtual controller, you must have the following software installed on a server: VMware ESXi 5.0 VMware ESXi 5.1 VMware vSphere Client The JunosV WLC supports the following parameters as described in table 1.

Table 4: JunosV Wireless LAN Controller Parameters Parameter

Description or Supported Value

Form factor

Virtual Machine Software

Deployment modes Local switching mode

Yes

Overlay mode

Yes

Mesh

Yes

Scale Minimum access points

4

Maximum access points

256 Active

Maximum client support

6400

Maximum number of remote WLA groups

256 Active, 2048 in cluster

Maximum access points per remote WLA group

100

Maximum SSIDs

128

Maximum VLANs

256

Roaming VLANs per JunosV WLC

256

Statically configured VLANs

256

Tunneled or Dynamic VLANs per controller

256

Number of Service Profiles per WLC

256

Number of Radio Profiles per WLC

256

Forwarding database entries (maximum supported)

32768

ACLs

256

Telnet management sessions

4

Telnet client sessions (client for remote login)

4

SSHv2 management sessions

4

Active AAA sessions (or clients trying to establish active connections) per JunosV WLC

6400


Support for JunosV Wireless LAN Controller (JunosV WLC)

17

Table 4: JunosV Wireless LAN Controller Parameters Parameter

Description or Supported Value

AAA users configured in local database

999

Minimum Hardware Specification Interfaces or network I/O

1 GE

CPU

2 GHz

Memory

2 GB recommended

Disk Space

16 GB

Features Supported Auto-tune

Yes

Bandwidth Control (Identity based)

Yes

Admission Control (CAC)/Wi-Fi Multimedia (WMM)

Yes

Guest services (wireless)

Yes

Wired Authentication

Yes

Access Control Lists (ACLs)

Yes

JunosV WLC High Availability

WLC Controller Clustering

Support for the Wireless LAN Controller 100 (WLC100) The WLC100 is Juniper's next-generation Wireless LAN controller that cost-effectively enables WLAN services in small to medium-sized branches and schools, small offices, and retail stores. The WLC100 is supported by MSS and RingMaster. At a platform level, the features offered by the WLC100 are the following: 4 x GE Ports (Includes 2 PoE+ ports) 1 x Console port (RJ45) 1 x USB2.0 Type A Port 1x Reset Config button with pin hole access 1 x DC Jack for Power input Fixed DDR3 Memory with ECC - 1GB memory with 2GB options

18

Support for the Wireless LAN Controller 100 (WLC100)


Using the Command-Line Interface

Using the Command-Line Interface Mobility System Software (MSS) supports a Juniper Networks Mobility System wireless LAN (WLAN) consisting of RingMaster software, Wireless LAN Controller (WLC) switches, and Wi (WLA) access points. MSS has a command-line interface (CLI) on the WLC that you can use to configure and manage the WLC and the attached WLAs. You configure the WLC and the WLA primarily with set, clear, and show commands. Use set commands to change parameters. Use clear commands to reset parameters to their defaults. In many cases, you can overwrite a parameter with another set command. Use show commands to display the current configuration and monitor the status of network operations. The WLC supports two connection modes: Administrative access mode, which enables the network administrator to connect to the WLC and configure the network. Network access mode, which enables network users to connect through the WLC to access the network

CLI Conventions Be aware of the following MSS CLI conventions for command entry: “Command Prompts” on page 19 “Syntax Notation” on page 20 “Text Entry Conventions and Allowed Characters” on page 20

Command Prompts By default, the MSS CLI provides the following prompt for restricted users. The mm portion shows the WLC model number (for example, 20) and the nnnnnn portion shows the last 6 digits of the WLC media access control (MAC) address. WLCmm-nnnnnn> When you log into the WLC as an administrative user and enter the enable command and supplying a suitable password, MSS displays the following prompt: WLCmm-nnnnnn# For ease of presentation, this manual shows the restricted and enabled prompts as follows: WLC> WLCC# Informational Note: For information about changing the CLI prompt on an WLC, see the set prompt command description in the Juniper Mobility System Software Command Reference.


CLI Conventions

19

Syntax Notation The MSS CLI uses standard syntax notation: Bold monospace font identifies the command and keywords you must type. For example: set enablepass Italic monospace font indicates a placeholder for a value. For example, you replace vlanid in the following command with a virtual LAN (VLAN) ID: clear interface vlanid ip Curly brackets ({ }) indicate a mandatory parameter, and square brackets ([ ]) indicate an optional parameter. For example, you must enter dynamic or port and a port list in the following command, but a VLAN ID is optional: clear fdb {dynamic | port port-list} [vlan vlanid] A vertical bar ( | ) separates mutually exclusive options within a list of possibilities. For example, you enter either enable or disable, not both, in the following command: set port {enable | disable} port-list

Text Entry Conventions and Allowed Characters Unless otherwise indicated, the MSS CLI accepts standard ASCII alphanumeric characters, except for tabs and spaces, and is case-insensitive. The CLI has specific notation requirements for MAC addresses, IP addresses, and masks, and allows you to group usernames, MAC addresses, virtual LAN (VLAN) names, and ports in a single command. It is recommended that you do not use the same name with different capitalizations for VLANs or access control lists (ACLs). For example, do not configure two separate VLANs with the names red and RED. Informational Note: The CLI does not support the use of special characters including the following in any named elements such as SSIDs and VLANs: ampersand (&), angle brackets (< >), number sign (#), question mark (?), or quotation marks (“”). Informational Note: In addition, the CLI does not support the use of international characters such as the accented É in DÉCOR.

MAC Address Notation MSS displays MAC addresses in hexadecimal numbers with a colon (:) delimiter between bytes—for example, 00:01:02:1a:00:01. You can enter MAC addresses with either hyphen (-) or colon (:) delimiters, but colons are preferred. For shortcuts: You can exclude leading zeros when typing a MAC address. MAC addresses are displayed including all leading zeros. In some specified commands, you can use the single-asterisk (*) wildcard character to represent an entire MAC address or from 1 byte to 5 bytes of the address.

20

CLI Conventions



IP Address and Mask Notation MSS displays IP addresses in dotted decimal notation—for example, 192.168.1.111. MSS uses both subnet masks and wildcard masks.

Subnet Masks Unless otherwise noted, use classless interdomain routing (CIDR) format to express subnet masks—for example, 192.168.1.112/24. Indicate the subnet mask with a forward slash (/) and specify the number of bits in the mask.

Wildcard Masks Security access control lists (ACLs) use source and destination IP addresses and wildcard masks to determine if the WLC filters or forwards IP packets. Matching packets are either permitted or denied network access. The ACL checks the bits in IP addresses that correspond to any 0s (zeros) in the mask, but does not check the bits that correspond to 1s (ones) in the mask. Specify the wildcard mask in dotted decimal notation. For example, the address 10.0.0.0 and mask 0.255.255.255 match all IP addresses that begin with 10 in the first octet. The ACL mask must be a contiguous set of zeroes starting from the first bit. For example, 0.255.255.255, 0.0.255.255, and 0.0.0.255 are valid ACL masks. However, 0.255.0.255 is not a valid ACL mask. Informational Note: ACLs use a “reverse” subnet mask numbering scheme which should not be confused with standard IP subnet masks.

Port Lists The physical Ethernet ports on an WLC can be set for WLA connections, authenticated wired users, or the network backbone. You can include a single port or multiple ports in one MSS CLI command by using the appropriate list format. The ports on an WLC are numbered 1 through 22. No port 0 exists on the WLC. You can include a single port or multiple ports in a command that includes port port-list. Use one of the following formats for port-list: A single port number. For example: WLC# set port enable 16 A comma-separated list of port numbers, with no spaces. For example: WLC# show port poe 1,2,4,13 A hyphen-separated range of port numbers, with no spaces. For example: WLC# reset port 12-16 Any combination of single numbers, lists, and ranges. Hyphens take precedence over commas. For example: WLC# show port status 1-3,14


CLI Conventions

21

Virtual LAN Identification The names of virtual LANs (VLANs), used in Mobility Domain™ communications, are set and can be changed. In contrast, VLAN ID numbers, used locally, are determined when the VLAN is first configured and cannot be changed. Unless otherwise indicated, you can refer to a VLAN by either a VLAN name or a VLAN number. CLI set and show commands use a VLAN name or number to uniquely identify the VLAN on the WLC.

Command-Line Editing MSS editing functions are similar to those of many other network operating systems.

Keyboard Shortcuts The following keyboard shortcuts are available for entering and editing CLI commands: Table 5.

CLI Command Keyboard Shortcuts

Keyboard Shortcut(s)

Function

Ctrl+A

Jumps to the first character of the command line.

Ctrl+B or Left Arrow key

Moves the cursor back one character.

Ctrl+C

Escapes and terminates prompts and tasks.

Ctrl+D

Deletes the character at the cursor.

Ctrl+E

Jumps to the end of the current command line.

Ctrl+F or Right Arrow key

Moves the cursor forward one character.

Ctrl+K

Deletes from the cursor to the end of the command line.

Ctrl+L or Ctrl+R

Repeats the current command line on a new line.

Ctrl+N or Down Arrow key

Enters the next command line in the history buffer.

Ctrl+P or Up Arrow key

Enters the previous command line in the history buffer.

Ctrl+U or Ctrl+X

Deletes characters from the cursor to the beginning of the command line.

Ctrl+W

Deletes the last word typed.

Esc B

Moves the cursor back one word.

Esc D

Deletes characters from the cursor forward to the end of the word.

Delete key or Backspace key

Erases mistake made during command entry. Reenter the command after using this key.

History Buffer The history buffer stores the last 63 commands you entered during a terminal session. You can use the Up Arrow and Down Arrow keys to select a command that you want to repeat from the history buffer.

Tabs The MSS CLI uses the Tab key for command completion. You can type the first few characters of a command and press the Tab key to display the command(s) that begin with those characters. For example: WLC# show i

22

igmp

Show igmp information

interface

Show interfaces

ip

Show ip information

CLI Conventions



Using CLI Help The CLI provides online help. To see the full range of commands available at your access level, type the following command: WLC# help Table 6: CLI Help Commands Command

Description

clear

Clear, use 'clear help' for more information

commit

Commit the content of the ACL table

copy

Copy from filename (or url) to filename (or url)

crypto

Crypto, use 'crypto help' for more information

delete

Delete url

dir

Show list of files on flash device

-disable

Disable privileged mode

exit

Exit from the Admin session

help

Show this help screen

history

Show contents of history substitution buffer

install

Install sygate on-demand agent files

load

Load, use 'load help' for more information

logout


monitor

Monitor, use 'monitor help' for more information

ping

Send echo packets to hosts

quit


reset

Reset, use 'reset help' for more information

rollback

Remove changes to the edited ACL table

save

Save the running configuration to persistent storage

set

Set, use 'set help' for more information

show

Show, use 'show help' for more information

telnet

telnet IP address [server port]

traceroute

Print the route packets take to network host

uninstall

Uninstall sygate on-demand agent files

Informational Note: For more information on help, see the help command description in the Juniper Mobility System Software Command Reference

To see a subset of the online help, type the first letter of the command to see more information. For example, the following command displays all the commands that begin with the letter i: WLC# show i? Table 7: CLI Help show i Commands Command

Description

igmp

Show igmp information

interface

Show interfaces


CLI Conventions

23

Table 7: CLI Help show i Commands Command

Description

ip

Show ip information

To see all the variations, type one of the commands followed by a question mark (?). For example: WLC# show ip ? Table 8: CLI Help shop ip Commands Command

Description

alias

Show ip aliases

dns

show DNS status

https

show ip https

route

Show ip route table

telnet

show ip telnet

To determine the port on which Telnet is running, type the following command: WLC# show ip telnet Server Status

Port

---------------------------------Enabled

2

Single-Asterisk (*) Wildcard Character You can use the single-asterisk (*) wildcard character when configuring user globs.

Double-Asterisk (**) Wildcard Characters The double-asterisk (**) wildcard character matches all usernames.

24

CLI Conventions


Part 2- System Administration


21

22


Configuring Administrative and Local Access

Configuring Administrative and Local Access Overview of Administrative and Local Access As administrator, you must establish administrative access for yourself, and any additional administrative users, before you can configure the WLC for operation. Table 1 provides an overview of configuration tasks and options: Table 1.

Administrative Configuration Tasks and Options

Console connection

By default, any administrator can connect to the console port and manage the WLC, because no authentication is enforced. (Juniper Networks recommends that you enforce authentication on the console port after initial connection.

Telnet or SSH connection Administrators cannot establish a Telnet or Secure Shell (SSH) connection to the WLC by default. To provide Telnet or SSH access, you must add a username and password entry to the local database A CLI Telnet connection to the WLC is not secure, unlike SSH, RingMaster and Web View connections. (For details, see Chapter , “Managing Keys and Certificates,” on page 979.) Restricted mode

When you initially connect to the WLC, the mode of operation is restricted. In this mode, only a small subset of status and monitoring commands is available. Restricted mode is useful for administrators with basic monitoring privileges who are not allowed to change the configuration or run traces.

Enabled mode

To enter the enabled mode of operation, type the enable command at the command prompt. In enabled mode, you can use all CLI commands. Although MSS does not require an enable password, Juniper Networks highly recommends that you set one.

Customized authentication

You can require authentication for all users or for only a subset of users. Username globbing (see “Wildcard Masks” on page 21) allows different users or classes of user to be given different authentication treatments. You can configure console authentication and Telnet authentication separately, and you can apply different authentication methods to each. For any user, authorization uses the same method(s) as authentication for that user.

Local override

A special authentication technique called local override allows authentication using the local database before attempting authentication through a RADIUS server. The WLC attempts administrative authentication in the local database first. If no match is found, the WLC attempts administrative authentication on the RADIUS server. (For information about setting an WLC to use RADIUS servers, see Configuring Communication with RADIUS on page 41.)

Accounting for administrative access sessions

Accounting records can be stored and displayed locally or sent to a RADIUS server. Accounting records provide an audit trail of the number of administrative user logins, the administrator username, the number of bytes transferred, and the time the session started and ended. (For information about setting an WLC to use RADIUS servers, see Configuring Communication with RADIUS on page 41.)


Overview of Administrative and Local Access

23

Table 1.

Administrative Configuration Tasks and Options

LDAP Authentication

Lightweight Directory Access Protocol (LDAP) authentication is an alternative to complex RADIUS installations for external authentication of users on the wireless network. To configure LDAP authentication, see Configuring LDAP Authentication on page 37.

Mobility System Diagram Figure 1–1 illustrates typical WLCs, WLAs, and network administrator in an enterprise network. As network administrator, you initially access the WLC via the console. Informational Note: Juniper Networks recommends enforcing authentication for administrative access using usernames and passwords stored either locally or on RADIUS servers.

Figure 1–1. Typical Juniper Networks Mobility System

About Administrative Access Administrative access allows you to access the WLC using a username and password, and enter the enable mode to configure the WLC.

24

Mobility System Diagram



Access Modes MSS provides two modes of access: Administrative access mode—Allows a network administrator to access the WLC and configure it. Informational Note: You must enable administrative access before adding users. See “Logging into the WLC

for the First Time” on page 25. Network access mode—Allows network users to connect through the WLC. Informational Note: For information about configuring network users, see “Configuring AAA for Network

Users” on page 123.

First-Time Configuration via the Console Administrators must initially configure the WLC with a computer or terminal connected to the WLC console port through a serial cable. Informational Note: Telnet access is not initially enabled. Informational Note: Before you continue with these steps, use the Juniper Networks Mobility System Software Quick Start Guide to set up an WLC and the attached WLAs for basic service.

To configure a previously unconfigured WLC through the console, you must complete the following tasks: 1. Log into the WLC to configure an enable password. (See “Logging into the WLC for the First Time” on page 25.) 2. Configure authentication. (See “Authenticating at the Console” on page 27.) 3. Save the configuration. (See “Saving the Configuration” on page 26.)

Logging into the WLC for the First Time To enable yourself as an administrator, you must log into the WLC from the console. Until you set the enable password and configure authentication, the default username and password are blank. Use the following steps to access the WLC from the serial console and log in for the first time: 1. Log into the WLC from the serial console, and press Enter when the WLC displays a username prompt: Username: 2. Press Enter when the WLC displays a password prompt. Password: 3. Type enable to go into enabled mode. WLC> enable 4. Press Enter to display an enabled-mode command prompt:


First-Time Configuration via the Console

25

WLC# Once you see this prompt, you have administrative privileges, which allow you to further configure the WLC.

Setting the WLC Enable Password There is one enable password for the WLC. Optionally, you can change the enable password from the default. Warning: Juniper Networks recommends that you change the enable password from the default (no password) to prevent unauthorized users from entering configuration commands.

To set the enable password for the first time: 1. At the enabled prompt, type set enablepass. 2. At the “Enter old password” prompt, press Enter. 3. At the “Enter new password” prompt, enter an enable password of up to 32 alphanumeric characters with no spaces. The password is not displayed as you type it.

Informational Note: The enable password is case-sensitive.

4. Type the password again to confirm it. The password is now set. Warning: Be sure to use a password that you can remember. If you lose the enable password, the only way to restore it is to return the WLC to the default settings which erases any saved configuration. (For details, see “Recovering

the

System After Losing the Enable Password” on page 948.)

Saving the Configuration 5. Store the configuration by typing the following command: WLC# save config success: configuration saved.

Service-Type Access to Privileged CLI Mode Service-Type access to the privileged CLI mode allows CLI users authenticated using AAA to automatically escalate into the CLI enabled mode and doesn’t require the user to enter the enable password. The Service-Type access applies to users configured with service-type attribute. For Telnet, SSH, or console login, the following applies: A user with service-type = 6 (admin) is allowed to directly log into privilege mode without prompting for the enable password. 26

Service-Type Access to Privileged CLI Mode



A user with service-type = 7 (nas-prompt) is allowed to login in but is not authorized to enable the privileged mode. The users must be defined in the database with service-type 6 (administrative). All other service-types are not granted login access. If the service-type is unconfigured, a user is allowed to login and is authorized to enable privileged mode, and the enable password is required. Informational Note: If you use RingMaster to continue configuring the WLC, enter the enable password of the WLC when you upload the WLC configuration into RingMaster. For RingMaster information, see the RingMaster Configuration Guide.

Authenticating at the Console You can configure the console to require authentication or not require authentication. Juniper Networks recommends that you enforce authentication on the console port. To enforce console authentication, take the following steps: 1. Add a user in the local database by typing the following command with a username and password: WLC# set user username password Enter new password: Retype new password: success: change accepted. 2. To enforce the use of console authentication via the local database, type the following command: Warning: If you type this command before you have created a local username and password, you can lock yourself out of the WLC. Before entering this command, you must configure a local username and password.

WLC# set authentication console * local 3. To store this configuration into nonvolatile memory, type the following command: WLC# save config success: configuration saved. By default, no authentication is required at the console. If you previously required authentication and have decided not to require it (during testing, for example), type the following command to configure the console so that it does not require username and password authentication: WLC# set authentication console * none Informational Note: The authentication method “none” that you can specify for administrative access is different from the fallthru authentication type None, which applies only to network access. The authentication method none allows access to the WLC by an administrator. The fallthru authentication type None denies access to a network user. Informational Note: For information about the fallthru authentication types, see “Authentication Algorithm”

on page 124.


Authenticating at the Console

27

28

Authenticating at the Console


Configuring Passwords

Configuring Passwords Overview Juniper Networks recommends that all users create passwords that are memorable to themselves, difficult for others to guess, and not subject to a dictionary attack. By default, user passwords are automatically encrypted when entered in the local database. However, the encryption is not strong. To maintain security, MSS displays only the encrypted form of the password in show commands. Optionally, you can configure MSS so that the following additional restrictions apply to user passwords: Passwords must be a minimum number of characters in length, and a mix of uppercase letters, lowercase letters, numbers, and special characters, including at least two of each (for example, Tre%Pag32!). A user cannot reuse any of the 10 previous passwords (not applicable to network users). When a user changes his or her password, at least 4 characters must be different from the previous password. A user password expires after a configured amount of time. A user is locked out of the system after a configured number of failed login attempts. When this happens, a trap is generated and an alert is logged. (Administrative users can gain access to the system through the console even when the account is locked.) Only one unsuccessful login attempt is allowed in a 10-second period for a user or session. All administrative logins, logouts, and logouts due to idle timeout, and disconnects are logged. The audit log file on the WLC (command_audit.cur) cannot be deleted, and attempts to delete log files are recorded.

Informational Note: These restrictions are disabled by default.

Configuring Passwords This section describes the following tasks: “Setting an MSS password for a User in the Local Database” on page 30 “Enabling Password Restrictions” on page 30 “Specifying Minimum Password Length” on page 31 “Configuring Password Expiration Time” on page 31 “Restoring Access to a Locked-Out User” on page 32


Overview

29

Setting an MSS password for a User in the Local Database Use the following steps to set a password for a local user: 1. To configure a user password in the local database, type the following command: set user username password [encrypted] password For example, to configure user Jose with the password sprRin9 in the local database on the WLC, type the following command: WLC# set user Jose password spRin9 success: User Jose created The encrypted option indicates that the password string you are entering is the encrypted form of the password. Use this option only if you do not want MSS to encrypt the password for you. By default, usernames and passwords in the local database are not case-sensitive, but passwords can be made case-sensitive by activating password restrictions, as described in the following section. To clear a user from the local database, type the following command: clear user username

Enabling Password Restrictions To activate password restrictions for network and administrative users, use the following command: set authentication password-restrict {enable | disable} When this command is enabled, the following password restrictions take effect: Passwords must be a minimum number of characters in length, and a mix of uppercase letters, lowercase letters, numbers, and special characters, including at least two of each (for example, Tre%Pag32!). A user cannot reuse any of 10 previous passwords (not applicable to network users). When a user changes his or her password, at least 4 characters must be different from the previous password. The password restrictions are disabled by default. When you enable them, MSS evaluates the passwords configured on the WLC and displays a list of users with passwords that do not meet the restriction on length and character types. For example, to enable password restrictions on the WLC, type the following command: WLC# set authentication password-restrict enable warning: the following users have passwords that do not have at least 2 each of upper-case letters, lower-case letters, numbers and special characters dan admin user1 user2 jdoe 30




dang success: change accepted.

Setting the Maximum Number of Login Attempts To specify the maximum number of login attempts by users before locking the user out of the system, use the following command: set authentication max-attempts number For Telnet or SSH sessions, a maximum of 4 failed login attempts are allowed by default. For console or network sessions, an unlimited number of failed login attempts are allowed by default. You can specify a number between 0 – 2147483647. Specifying 0 causes the number of allowable login attempts to reset to the default values. If a user is locked out of the system, you can restore user access with the clear user lockout command. See “Restoring Access to a Locked-Out User” on page 32. For example, to allow users a maximum of 3 attempts to log into the system, type the following command: WLC# set authentication max-attempts 3 success: change accepted.

Specifying Minimum Password Length To specify the minimum allowable length for user passwords, use the following command: set authentication minimum-password-length length You can specify a minimum password length between 0 – 32 characters. Specifying 0 removes the restriction on password length. By default, there is no minimum length for user passwords. When this command is configured, you cannot configure a password shorter than the specified length. When you enable this command, MSS evaluates the passwords configured on the WLC and displays a list of users with passwords that do not meet the minimum length restriction. For example, to set the minimum length for user passwords at 7 characters, type the following command: WLC# set authentication minimum-password-length 7 warning: the following users have passwords that are shorter than the minimum password length dan admin user2 jdoe success: change accepted.

Configuring Password Expiration Time 1. To specify how long a user password is valid before it must be reset, use the following command: set user username expire-password-in time 2. To specify how long the passwords are valid for users in a user group, use the following command: Copyright © 2013, Juniper Networks, Inc.


31

set usergroup group-name expire-password-in time By default, user passwords do not expire. You can use this command to specify how long a specified user password is valid. After this amount of time, the user password expires, and a new password is set. The amount of time can be specified in days (for example, 30 or 30d), hours (720h), or a combination of days and hours (30d12h) For example, the following command sets user Student1 password to be valid for 30 days: WLC# set user Student1 expire-password-in 30 success: change accepted. The following command sets user Student1 password to be valid for 30 days and 15 hours: WLC# set user Student1 expire-password-in 30d15h success: change accepted. The following command sets user Student1’s password to be valid for 720 hours: WLC# set user Student1 expire-password-in 720h success: change accepted. The following command sets the passwords for the users in user group cardiology to be valid for 30 days: WLC# set usergroup cardiology expire-password-in 30 success: change accepted.

Restoring Access to a Locked-Out User If a user password has expired, or the user is unable to login within the configured limit for login attempts, then the user is locked out of the system, and cannot gain access without the intervention of an administrator. To restore access to a user locked out of the system, use the following command: clear user username lockout If a user is locked out of the system because of an expired password, you must first assign the user a new password before you can restore access to the user. The following command restores access to user Nin, who was locked out of the system: WLC# clear user Nin lockout success: change accepted.

Displaying Password Information To display user password information with the show user verbose command. Enter the following command: WLC# show user verbose Following is example output of the above command: user bob Password = 00121a08015e1f (encrypted) 32

Displaying Password Information



Password-expires-in = 59 hours (2 days 11 hours) status = disabled Group: VLAN = default Other attributes: None Informational Note: For information about the fields in the output, see the Juniper Mobility System Software Command Reference.

Informational Note: Although MSS allows you to configure a user password for the special “last-resort” guest user, the password has no effect. Last-resort users can never access an WLC in administrative mode and never require a password.



33

34



Adding and Clearing Local Users for Administrative Access

Adding and Clearing Local Users for Administrative Access Administrative Access Overview Usernames and passwords can be stored locally on the WLC. Juniper Networks recommends that you enforce console authentication after the initial configuration to prevent unauthorized access to the console. The local database on the WLC is the simplest way to store user information in a Juniper Networks system. 1. To configure a user in the local database, type the following command: set user username password [encrypted] password For example, to configure user Jose with the password spRin9 in the local database on the WLC, type the following command: WLC# set user Jose password spRin9 success: User Jose created The encrypted option indicates that the password string is the encrypted form of the password. Use this option only if you do not want MSS to encrypt the password for you. 2. To clear a user from the local database, type the following command: clear user username

Saving the Configuration You must save the configuration for all commands that you enter and want to use for future sessions. 1. After you enter the administrator AAA configuration, type the following command to maintain these commands in WLC nonvolatile memory: WLC# save config success: configuration saved. 2. You can also specify a filename for the configuration—for example, configday. To do this, type the following command: WLC# save config configday Configuration saved to configday. You must type the save config command to save all configuration changes since the last time you rebooted the WLC or saved the configuration. If the WLC is rebooted before you have saved the configuration, all changes are lost.


Administrative Access Overview

35

36

Administrative Access Overview


Configuring LDAP Authentication

Configuring LDAP Authentication About LDAP Authentication Lightweight Directory Access Protocol (LDAP) is an Internet protocol for accessing and updating information in an X.500-compliant directory. A network administrator with LDAP clients can connect to X.500 directory service and add, delete, modify, or search for information if they have the appropriate access rights to the directory. LDAP is designed to run over TCP/IP and can access information in both X.500 directories and many non-X.500 directories. LDAP authentication supports the following: LDAPv3 (RFC4510) User authentication against a standard LDAP server for Web portal, MAC, and admin/console. User groups, SSID defaults and location policy as the mechanism to assign user attributes. Encrypted authentication requests “ping” test commands

Configuring LDAP Authentication You must have an LDAP server on your network and it must be pre-populated with the appropriate information. 1. To configure LDAP authentication, use the following command: WLC# set ldap server server-name {[address ipaddr | auth-port portnum] | [timeout seconds | deadtime minutes] [bind-mode simple-auth | sasl-md5] fqdn dns-name][mac-addr-format [hyhpens | colons | one-hyphen | raw] [base-dn string] [key-dn string]} The default value for timeout is 5 seconds with a range of 0 to 65535 seconds. The default deadtime is 5 minutes with a range of 0 to 1440 minutes. 2. To add an LDAP server to the LDAP group, use the following command: WLC# set ldap server group name members [server1 | server2 | server3 | server4] You must configure an LDAP group before you can configure authentication using LDAP even if you have only one LDAP server. 3. To configure Web or MAC authentication with LDAP, use the following commands: WLC# set authentication [mac | web] [ssid ssid-name | wired] mac-glob [ldap_group1 | ldap_group2 | ldap_group3 | ldap_group4] You can configure up to four LDAP server groups for authentication. 4. To configure admin or console authentication with LDAP, use the following commands: WLC# set authentication [admin | console] user-glob [ldap_group1 | ldap_group2 | ldap_group3 | ldap_group4] 5. To configure load balancing between LDAP servers, use the following command: Copyright © 2013, Juniper Networks, Inc.

About LDAP Authentication

37

WLC# set ldap server group server-group-name load-balance [enable | disable] 6. Use enable to allow load balancing between LDAP servers, and disable to cease load-balancing between servers.

LDAP Configuration Example To add an LDAP server to authenticate users, you should follow these steps: 1. Obtain the IP address and port of the LDAP server: 172.21.52.145, port 389 (default) 2. Use the default values for timeout and dead time. 3. Configure an LDAP server group. 4. To ping an LDAP server, use the following command: WLC# ldap-ping server server-name login id password password To clear LDAP settings, use the clear command for each configurable parameter, for example: WLC# clear ldap server server-name 5. To view the LDAP configuration, use the show LDAP command: WLC20-ss# show ldap Following is the example output of the above command: LDAP Servers Default Values auth-port=389, timeout=5(s), bind-mode=sasl-md5,

deadtime=5(mn)

mac-addr-format=hyphens

LDAP Servers Flags: (state)

U=up, D=down

(bind-mode)

s=simple-auth, m=sasl-md5

(mac-format) h=hyphens, c=colons, o=one-hyphen, r=raw Auth Server

IP address

Port

Out

Time Deadtime

Conf:Rem

s:bm

Flags

FQDN

-------------- --------------- ---- ---- ---------- -------------------techpubs

10.8.112.212

389

5

5

:0m

U:mh

testldap

10.8.112.212

389

5

5

:0m

U:mh

juniper.net

Server groups techldap: testldap

38



Configuring LDAP Authentication

Changing the MAC Authorization Password You can change the default password for LDAP authorization by using the following commands: WLC# set ldap author-password string To set the password as the MAC address, use the parameter USE-MAC-ADDRESS to send the MAC address as the password. To use this option on the LDAP server, use the set ldap server author-password command. To set the password back to the default value, use the clear commands for each option.



39

40



Configuring Communication with RADIUS

Configuring Communication with RADIUS For a list of the standard and extended RADIUS attributes and Juniper vendor-specific attributes (VSAs) supported by MSS, see “Supported RADIUS Attributes” on page 973.

RADIUS Overview Remote Authentication Dial-In User Service (RADIUS) is a distributed client-server system. RADIUS servers provide a repository for all usernames and passwords, and can manage and store large groups of users. RADIUS servers store user profiles that include usernames, passwords, and other AAA attributes. You can use authorization attributes to authorize users for a type of service, for appropriate servers and network segments through VLAN assignments, for packet filtering by access control lists (ACLs), and for other services during a session. Informational Note: You must include RADIUS servers in a server group before you can access the servers. Informational Note: See “Split Authentication and Authorization” on page 52

Figure 1–2 illustrates the interactions between wireless users (clients), WLAs, an WLC, and attached RADIUS servers when clients attempt access to the network. Figure 1–2. Wireless Client, WLA, WLC, and RADIUS Server

In the example shown in Figure 1–2, the following events occur: 1. The wireless user (client) requests an IEEE 802.11 association from the WLA. 2. After the WLA creates the association, the WLC sends an Extensible Authentication Protocol (EAP) identity request to the client. 3. The client sends an EAP identity response.


RADIUS Overview

41

4. From the EAP response, the WLC receives the client username. The WLC then searches the AAA configuration, and attempting to match the client username against the user globs in the AAA configuration. When a match is found, the methods specified by the matching AAA command determine client authentication, either locally on the WLC, or via a RADIUS server group. 5. If the client does not support 802.1X, MSS attempts to perform MAC authentication for the client instead. In this case, if the WLC configuration contains a set authentication mac command that matches the client MAC address, MSS uses the method specified by the command. Otherwise, MSS uses local MAC authentication by default.

Before You Begin To ensure that you can contact the RADIUS servers you plan to use for authentication, send the ping command to each one to verify connectivity. ping ip-address You can then set up communication between the WLC and each RADIUS server group.

Configuring RADIUS Servers An authentication server validates each client with access to an WLC port before any services are available on the WLC or the wireless network. The authentication server can reside either in the local database on the WLC or on a remote RADIUS server. When a RADIUS server is used for authentication, you must configure RADIUS server parameters. For each RADIUS server, you must set the following parameters: Server name Password (key) IP address You can include any or all of the other optional parameters. You can set some parameters globally for the RADIUS servers. For RADIUS servers without explicitly set dead times, timeout timers, and transmission attempts, MSS sets the following values by default: Dead time—5 (five) minutes (The WLC designates unresponsive RADIUS servers as unavailable. for 5 minutes.) Transmission attempts—3 Timeout (server response time)—5 seconds

42

Before You Begin



When MSS sends an authentication or authorization request to a RADIUS server, MSS waits the length of the RADIUS timeout for the server to respond. If the server does not respond, MSS retransmits the request. MSS sends the request up to the configured number of retransmits. The retransmit setting specifies the total number of attempts, including the first attempt. For example, using the default values, MSS sends a request to a server up to three times, waiting 5 seconds between requests. If a server does not respond before the last request attempt times out, MSS stops further requests to the server, for the duration of the dead time. For example, if you set the dead time to 5 minutes, MSS stops sending requests to the dead server for 5 minutes before reattempting a connection to the server. During the holddown, MSS ignores any dead RADIUS servers and skips to the next live server, or on to the next method if no more live servers are available, depending on your configuration. For example, if a RADIUS server group is the primary authentication method and local is the secondary method, MSS fails over to the local method if all RADIUS servers in the server group are unresponsive and have entered the dead time. For failover authentication or authorization to work promptly, Juniper Networks recommends that you change the dead time to a value other than 0. With the 0 setting, the dead time is never invoked and MSS does not hold down requests to unresponsive RADIUS servers. Instead, MSS attempts to send each new authentication or authorization request to a server even if the server appears unresponsive. This behavior can cause authentication or authorization failures on clients because MSS does not fail over to the local method quickly and the clients eventually time out.

Configuring Authentication Protocols for RADIUS MSS supports CHAP and MS-CHAPv2 as authentication protocols on a RADIUS server. To add CHAP or MS-CHAPv2 to a RADIUS server, enter the following commands: WLC# set radius server auth-protocol {pap | chap | mschap-v2}

Configuring Global RADIUS Defaults You can change RADIUS values globally and set a global password (key) with the following command. The key string is the shared secret that the WLC uses to authenticate to the RADIUS server. set radius {deadtime minutes | encrypted-key string | key string | retransmit number | timeout seconds} Informational Note: To override global settings for individual RADIUS servers, use the set radius server command. See “Configuring Individual RADIUS Servers” on page 44.

For example, the following commands set the dead-time timer to 10 minutes and set the password to r8gney for all RADIUS servers in the WLC configuration: WLC# set radius deadtime 10 success: change accepted. WLC# set radius key r8gney success: change accepted. To reset global RADIUS server settings to their factory defaults, use the following command: clear radius {deadtime | key | retransmit | timeout} Copyright © 2013, Juniper Networks, Inc.

Configuring RADIUS Servers

43

For example, the following command resets the dead-time timer to 0 minutes on all RADIUS servers in the WLC configuration: WLC# clear radius deadtime success: change accepted.

Setting the System IP Address as the Source Address By default, RADIUS packets leaving the WLC have the source IP address of the outbound interface on the WLC. The source address can change when routing conditions change. If you set a system IP address for the WLC, you can use it as a permanent source address for the RADIUS packets sent by the WLC. To set the WLC system IP address as the address of the RADIUS client, type the following command: WLC# set radius client system-ip success: change accepted. To remove the WLC system IP address as the source address in RADIUS client requests from the WLC to the RADIUS server(s), type the following command: WLC# clear radius client system-ip success: change accepted. The command causes the WLC to select a source interface address based on routing table information as the RADIUS client address.

Configuring Individual RADIUS Servers You must set up a name and IP address for each RADIUS server. To configure a RADIUS server, use the following command: set radius server server-name [address ip-address] [key string] The server name must be unique for this RADIUS server on the WLC. Do not use the same name for a RADIUS server and a RADIUS server group. The key (password) string is the shared secret that the WLC uses to authenticate to the RADIUS server.

Informational Note: For additional options, see the Juniper Mobility System Software Command Reference.

The following command names a RADIUS server rs1 with the IP address 192.168.0.2 and the key testing123: MX-20# set radius server rs1 address 192.168.0.2 key testing123 success: change accepted. You can configure multiple RADIUS servers. When you define server names and keys, case is significant. For example: MX-20# set radius server rs1 address 10.6.7.8 key seCret success: change accepted. MX-20# set radius server rs2 address 10.6.7.9 key BigSecret

44

Configuring RADIUS Servers



success: change accepted. Informational Note: You must provide RADIUS servers with unique names. To prevent confusion, Juniper Networks recommends that RADIUS server names differ in ways other than case. For example, avoid naming two servers RS1 and rs1.

You must configure RADIUS servers into server groups before you can access them. For information on creating server groups, see “Split Authentication and Authorization” on page 52.

Configuring MAC Addresses as Usernames on a RADIUS Server MAC authentication request is an enhancement to the current username and password format currently available in MSS for authentication through a RADIUS server. Changes to this feature allow for better interoperability with third-party vendors who may use different formats for MAC address authentication. A new parameter is available to configure a MAC address format to be sent as a username to a RADIUS server for MAC authentication. To configure the MAC address format with MSS, use the following command: WLCR2# set radius server name mac-addr-format {hyphens | colons | one-hyphen | raw} For example, WLCR2# set radius server sp1 mac-addr-format? hyphens

12-34-56-78-9a-bc

colons

12:34:56:78:9a:bc

one-hyphen

123456-789abc

raw

123456789abc

You can also configure all RADIUS servers to use a specific MAC address format with the following command: WLCR2># set radius mac-addr-format {hyphens | colons | one-hyphen | raw}

Deleting RADIUS Servers To remove a RADIUS server from the WLC configuration, use the following command: clear radius server server-name

Configuring RADIUS Server Groups A server group is a group of up to four RADIUS servers. Before you can use a RADIUS server for authentication, you must first create a RADIUS server group and add the RADIUS server to the group. You can also configure load balancing, so that authentications are distributed between servers in the group. You must declare all members of a server group, in contact order, when you create the group. Once the group is configured, you can use a server group name as the AAA method with the set authentication and set accounting commands. Subsequently, you can change the members of a group or configure load balancing. Copyright © 2013, Juniper Networks, Inc.

Configuring RADIUS Server Groups

45

If you add or remove a RADIUS server in a server group, all the RADIUS dead timers for that server group are reset to the global default.

Creating Server Groups To create a server group, you must have the RADIUS servers. After configuring RADIUS servers, type the following command: set server group group-name members server-name1 [server-name2] [server-name3] [server-name4] For example, to create a server group called shorebirds with the RADIUS servers heron, egret, and sandpiper, type the following commands: WLC# set radius server egret address 192.168.253.1 key apple WLC# set radius server heron address 192.168.253.2 key pear WLC# set radius server sandpiper address 192.168.253.3 key plum WLC# set server group shorebirds members egret heron sandpiper In this example, a request to shorebirds contacts the RADIUS servers in the order listed in the server group configuration, first egret, then heron, then sandpiper. You can change the RADIUS servers in server groups at any time. Informational Note: See “Adding Members to a Server Group” on page 47. Informational Note: Any RADIUS servers that do not respond are marked dead (unavailable) for a period of time. The unresponsive server is ignored during the configured dead time. Once the dead time elapses, the server is again a candidate for receiving requests. To change the default dead-time timer, use the set radius or set radius server command.

Ordering Server Groups You can configure up to four methods for authentication, authorization, and accounting (AAA). AAA methods can be the local database on the WLC and/or one or more RADIUS server groups. You set the order in which the WLC attempts the AAA methods by the order that you enter the methods. In most cases, if the first method results in a pass or fail, the evaluation is final. If the first method does not respond or results in an error, the WLC tries the second method and so on. However, if the local database is the first method in the list, followed by a RADIUS server group, the WLC responds to a failed search of the database by sending a request to the following RADIUS server group. This exception is called local override.

Configuring Load Balancing You can configure the WLC to distribute authentication requests across RADIUS servers in a server group. Distributing the authentication process across multiple RADIUS servers significantly reduces the load on individual servers while increasing resiliency on a system-wide basis.

46




When you configure load balancing, the first client RADIUS requests are directed to the first server in the group, the second client RADIUS requests are directed to the second server in the group, and so on. When the last server in the group is reached, the cycle is repeated. Informational Note: MSS attempts to send accounting records to one RADIUS server, even if load balancing is configured.

To configure load balancing, use the following command: set server group group-name load-balance enable For example, to configure RADIUS servers pelican and seagull as the server group swampbirds with load balancing: 1. Configure the members of a server group by typing the following command: WLC# set server group swampbirds members pelican seagull success: change accepted. 2. Enable load balancing by typing the following command: WLC# set server group swampbirds load-balance enable success: change accepted. The following command disables load balancing for a server group: clear server group group-name load-balance

Adding Members to a Server Group To add RADIUS servers to a server group, type the following command: set server group group-name members server-name1 [server-name2] [server-name3] [server-name4]] The keyword members lists the RADIUS servers contained in the named server group. A server group can contain between one and four RADIUS servers. This command accepts any RADIUS servers as the current set of servers. To change the server members, you must reenter all of them. For example, to add RADIUS server coot to server group shorebirds: 1. Determine the server group by typing the following command: WLC# show radius Radius Servers Server

Addr

Ports

T/o Tries Dead State

------------------------------------------------------------------sandpiper

192.168.253.3

1812 1813

5

3

0

UP

heron

192.168.253.1

1812 1813

5

3

0

UP

coot

192.168.253.4

1812 1813

5

3

0

UP

egret

192.168.253.2

1812 1813

5

3

0

UP

Server groups



47

shorebirds (load-balanced): sandpiper heron egret The RADIUS server coot is configured but not part of the server group shorebirds. To add RADIUS server coot as the last server in the server group shorebirds, type the following command: WLC# set server group shorebirds members sandpiper heron egret coot success: change accepted.

Deleting a Server Group To remove a server group, type the following command: clear server group group-name For example, to delete the server group shorebirds, type the following command: WLC# clear server group shorebirds success: change accepted. The members of the group remain configured, although no server groups are shown: WLC# show radius Default Values authport=1812 acctport=1813 timeout=5 acct-timeout=5 retrans=3 deadtime=0 key=(null) author-pass=(null) Radius Servers Server

Addr

Ports


------------------------------------------------------------------sandpiper

192.168.253.3

1812 1813

5

3

0

UP

heron

192.168.253.1

1812 1813

5

3

0

UP

coot

192.168.253.4

1812 1813

5

3

0

UP

egret

192.168.253.2

1812 1813

5

3

0

UP

Server groups

Using the RADIUS Ping Utility The following command and options are now available that allow you to ping a RADIUS server to determine the status. WLC200# radping {server servername | group servergroup} request authentication user username password password auth-type [mschapv2] This command sends an authentication request with the specified username and password to the RADIUS server or RADIUS server group. WLC200# radping {server servername | group servergroup} request {acct-start | acct-stop | acct-update} user username This command sends an accounting request from the specified user to the specified server or server group.

48




WLC200# radping {server servername | group servergroup} request {acct-on | acct-off}

RADIUS and Server Group Configuration Scenario The following example illustrates how to add four RADIUS servers to an WLC and configure them into two load-balancing server groups, swampbirds and shorebirds: 1. Configure RADIUS servers. Type the following commands: WLC# set radius server pelican address 192.168.253.11 key elm WLC# set radius server seagull address 192.168.243.12 key fir WLC# set radius server egret address 192.168.243.15 key pine WLC# set radius server sandpiper address 192.168.253.17 key oak 2. Place two of the RADIUS servers into a server group called swampbirds. Type the following command: WLC# set server group swampbirds members pelican seagull 3. Enable load balancing for swampbirds. Type the following command: WLC# set server group swampbirds load-balance enable 4. Place the other RADIUS servers in a server group called shorebirds. Type the following command: WLC# set server group shorebirds members egret pelican sandpiper 5. Enable load balancing for shorebirds. Type the following command: WLC# set server group shorebirds load-balance enable 6. Display the configuration. Type the following command: WLC# show radius Default Values authport=1812 acctport=1813 timeout=5 acct-timeout=5 retrans=3 deadtime=0 key=(null) author-pass=(null) Radius Servers Server

Addr

Ports


------------------------------------------------------------------sandpiper

192.168.253.17

1812 1813

5

3

0

UP

seagull

192.168.243.12

1812 1813

5

3

0

UP

egret

192.168.243.15

1812 1813

5

3

0

UP

pelican

192.168.253.11

1812 1813

5

3

0

UP

Server groups swampbirds (load-balanced): pelican seagull shorebirds (load-balanced): egret pelican sandpiper


RADIUS and Server Group Configuration Scenario

49

Dynamic RADIUS Extensions This feature allows administrators supporting a RADIUS server to disconnect a user and change the authorization attributes of an existing user session. New terminology is introduced in support of RFC 4673 (Dynamic Authorization Server MIB): Dynamic Authorization Server (DAS) — The component residing on the NAS and processes the Disconnect and Change-of-Authorization (CoA) requests sent by the Dynamic Authorization Client (DAC). Dynamic Authorization Client (DAC) — The component sending the Disconnect and CoA requests to the DAS. Though the DAC often resides on the RADIUS server, it can be located on a separated host, such as a routing engine. Dynamic Authorization Server Port — The UDP that the DAS listens for Disconnect and CoA requests sent by the DAC.

Configuring Dynamic RADIUS Extensions 1. To configure a RADIUS DAC server on an WLC, use the following commands: WLC# set radius dac dac-name ip-address key Additional attributes include the following: [disconnect [enable | disable] | [change-of-author [enable | disable] | replay-protection [enable | disable] | replay-window seconds ] 2. To configure the dynamic authorization server port, use the following command: WLC# set radius das-port portnum 3. To clear the das-port, use the following command: WLC# clear radius das-port 4. To configure SSIDs for RADIUS DAC, use the following commands: WLC# set authorization dynamic {ssid [wireless_8021X | 8021x | any |]| wired } You can configure up to four SSIDs and four wired rule names for RADIUS DAC.

Attribute for RADIUS This attribute supports reauthentication of all access types: dot1x, web-portal, MAC, and last-resort. When the value is set to 0, the user session is terminated after the session timeout expires. If the value is set to 1, the user session is reauthenticated by sending a RADIUS request message after the session timeout expires. The command syntax is displayed below: WLC# set usergroup groupname attr termination-action [0 | 1]

50

Dynamic RADIUS Extensions



WLC# set user username attr termination-action [0 | 1] Table 2.

termination-action Attribute Properties with Dot1X Dynamic WEP Clients Session Timeout (ST)

Termination

Configured (not 0)

0

Not set

0

Disconnect

Disconnect after dot1x timer

Disconnect after dot1x timer

1

Reauthenticate

Immediate reauthentication after connecting

Reauthenticate after dot1x timer

not set

Reauthenticate

Reauthenticate after dot1x Reauthenticate after dot1x timer timer

Action (TA)

Table 3.

Non Dot1X and Nondynamic WEP Dot1X Clients Session Timeout (ST)

Termination

Configured (not 0)

0

Not set

0

Disconnect

Never disconnect

Never disconnect

1

Reauthenticate

Immediate reauthentication after connecting

Never disconnect

not set

Disconnect if non Dot1X client. Reauthenticate if Dot1X client.

Never disconnect

Never disconnect

Action (TA)

MAC User Range Authentication RingMaster and MSS allow authentication of users based on the MAC address of a device. This provides enhancements that allow a set of MAC-authenticated devices like VoIP phones to authenticate through a RADIUS server and through the WLC local database without additional configuration. RingMaster adds a User MAC Address field to allow input such as 00:11:00:* instead of the entire MAC address. Only one * (asterisk) is allowed in the address format and it must be the last character. During authentication of the MAC User client, the most specific entry that matches the MAC-user glob is selected. Therefore, an entry for 00:11:30:21:ab:cd overrides an entry for 00:11:30:21:*, and an entry for 00:11:30:21:* overrides an entry for 00:11:30:*.

Configuring MAC User Range Authentication 1. To configure a MAC User Range with MSS, follow these steps: WLC200# set mac-user 00:11:* WLC200# set mac-user 00:11:* attr value WLC200# set mac-user 00:11:* group groupname 2. To configure this feature for authentication on a RADIUS server, use the following command: WLC200# set authentication mac-prefix {ssid | wired} mac-glob radius-server-group



51

The parameter mac-glob represents the range of MAC addresses for this rule and determines the prefix used for authentication. During authentication, the MAC prefix is extracted from the MAC-glob and used as the user-name in the Access-Request portion of the handshake.

MAC Authentication Request Format MAC Authentication Request is an enhancement to the current username and password format available in MSS for authentication through a RADIUS server. Changes to this feature allow for better interoperability with third-party vendors who may use different formats for MAC address authentication.

Configuring MAC Authentication Requests A new parameter is available to configure a MAC address format to be sent as a username to a RADIUS server for MAC authentication. To configure the MAC address format with MSS, use the following command: WLC200# set radius server name mac-addr-format {hyphens | colons | one-hyphen | raw} For example, WLC200# set radius server sp1 mac-addr-format ? hyphens

12-34-56-78-9a-bc

colons

12:34:56:78:9a:bc

one-hyphen

123456-789abc

raw

123456789abc

You can also configure all RADIUS servers to use a specific MAC address format with the following command: WLC# set radius mac-addr-format {hyphens | colons | one-hyphen | raw}

Split Authentication and Authorization With the implementation of this feature, a RADIUS server authenticates a user but authorization attributes are taken from the WLC local user database. This is accomplished by including a Vendor Specific Attribute (VSA) in the RADIUS Accept response. When the WLC receives the RADIUS Accept response, the WLC uses the group name and attempts to match it to authorization attributes of a corresponding user group in the local user database. Additional attributes must be configured on the RADIUS server. For the user-group name, specify a value consisting of a string 1-32 characters long. Additional values consist of Type - 26, Vendor ID- 14525, Vendor Type - 9 (Juniper VSA). Attributes that appear in the RADIUS Access Accept response are added to the session attributes. If the Access Accept has a Juniper group-name VSA, the attributes from the corresponding user group in the local database are applied.

52




Configuring Command Auditing and RADIUS MSS can log commands used at the CLI and send them to a RADIUS server. All commands, including show commands, that complete successfully or fail are logged on the RADIUS server. The command accounting message includes the following elements: Timestamp TTY Port Username Source IP address Command issued Command status (success or failure) You can also configure primary and secondary RADIUS servers to log CLI commands. When command auditing is enabled, all valid CLI commands are captured and logged to a RADIUS server. The message sent to the RADIUS server has the following format: Table 4.

RADIUS Commands

RADIUS Attribute Name

RADIUS value

Field Value

Acct-Status-type

40

Always set to STOP value

Username

1

TTY username for SSH/Telnet/console sessions UNKNOWN if no login name was used RINGMASTER, SNMP, WEBVIEW for related clients

Event-timestamp

55

Timestamp of the event in UTC format

Calling-Station-Id

31

IP address of the user

Acct-Session-Id

44

Unique accounting session ID for each record

Acct-Multi-Session-Id

50

Unique value for a same user session

NAS-Port

5

TTY port or connection port used

NAS-Port-Type

61

Type of connection

NAS-IP-Address

4

WLC IP address

NAS-Identifier

32

Always set to the value Trapeze

Trapeze-Audit

VSA 13

String containing audit information with the following convention: cmd - logged CLI command xml - XML transactions status - transaction execution as success or fail version - MSS version string platform - WLC platform string serial - serial number of the platform

1. To configure command auditing on the WLC, use the following command: WLC# set accounting command radius-server-group 2. To clear command auditing on the WLC, use the following command: WLC# clear accounting command



53

54



Managing System Files

Managing System Files You can manage files stored on the WLC in nonvolatile storage using MSS. In addition, you can copy files between the WLC and a TFTP or FTP server on the network. You can also use SCP (secure copy protocol) to securely transfer or copy files on the WLC.

About System Files Generally, the nonvolatile storage of a WLC contains the following types of files: Table 5: MS System File Types File Type

Description

System image files

Operating system software for the WLC and the attached WLAs.

Configuration files

CLI commands that configure the WLC and the attached WLAs.

System log files

Files containing log entries generated by MSS.

When you power on or reset the WLC or reboot the software, the WLC loads a designated system image, then loads configuration information from a designated configuration file. An WLC can also contain temporary files with trace information used for troubleshooting. Temporary files are not stored in nonvolatile memory, but are listed when you display a directory of the files on the WLC.

Displaying Software Version Information 1. To display the software, firmware, and hardware versions, use the following command: show version [details] The details option displays hardware and software information about the WLAs configured on the WLC. 2. To display version information for an WLC, type the following command: WLC# show version Following is example output of the above command: Mobility System Software, Version: 8.0.0.2 REL Copyright (c) 2013 Juniper Networks, Inc. All rights reserved. Build Information: (build#0) REL_8_0_0_branch 2013-04-06 23:46:00 Model:

WLC200

Hardware Mainboard:

version 24 ; revision 3 ; FPGA version 24

PoE board:

version 1 ; FPGA version 6

Serial number

0321300013

Flash:

8.1.0.5

Kernel:

3.0.0#14: Sat Oct

BootLoader:

8.0 / 780.6


- md0a 7 00:03:52 PDT 2012

About System Files

55

3. To display WLA information, type the following command: WLC# show version details Following is example output of the above command: Mobility System Software, Version 7.6.2.3 REL Copyright (c) 2002 - 2012 Juniper Networks, Inc. AllRights Reserved Build Information:

(build#0) REL_7_6_2_branch 2012-02-02 16:42:00

Label:

REL_7.6.2.3_0202212

Build Suffix

-d-01

Model:

MXR-2

Hardware Mainboard:

version 0 ; revision f

CPU Model:

405EP (Revision 9.80)

Serial Number:

0525200163

Flash:

1.0.0 -1

Kernel:

6.3.0

Bootloader:

7.1 / 7.04

AP

Serial #

AP Model

Versions

---------------------------------------------: Informational Note: For additional information about the output, see the Juniper Networks Mobility System Software Command Reference.

Boot Information Boot information consists of the MSS version and the names of the system image file and current configuration file on the WLC. The boot command also lists the system image and configuration file that are loaded after the next reboot. The currently running versions are listed in the Booted fields. The versions that are used after the next reboot are listed in the Configured fields. Each time the WLC successfully loads an MSS software image, a reference to this image is saved as the “safe boot” image. If the MSS software cannot be loaded the next time the WLC is booted, then the WLC automatically attempts to load the safe boot image.

56

Boot Information



Boot failover may occur when an image update is attempted, and the update process fails. For example, with image A loaded on the WLC, you can configure the WLC to load image B the next time the WLC is booted. When the WLC is reset, and if image B fails to load, the WLC then attempts to load image A, the last image successfully loaded on the WLC. Informational Note: For additional information about the output, see the Juniper Networks Mobility System Software Command Reference.

To display boot information, type the following command: WLC# show boot The following example describes the return information: WLCR2_desk# show boot Configured boot version:

7.7.0.0.85

Configured boot image:

boot1:mx07700.002

Configured boot configuration:

file:configuration

Backup boot configuration:

file:backup.cfg

Booted version:

7.6.0.0.85

Booted image:

boot1:mx07600.002

Booted configuration:

file:configuration

Product model:

WLC2

In the example, the WLC is running software version 7.7.0.0.85. The WLC used the mx07700.002 image file in boot partition boot1 and the configuration file for the most recent reboot. The WLC is set to use image file mx07700.002 in boot partition boot1 and configuration file configuration for the next reboot. If MSS cannot read the configuration file when the WLC is booted, then the configuration file backup.cfg is used instead.

Managing Files Stored on the WLC This section describes the following WLC file management tasks: “Displaying a List of Files” on page 57 “Copying a File” on page 60 “Using SCP to Manage Files” on page 62 “Deleting a File” on page 62 “Creating a Subdirectory” on page 63 “Removing a Subdirectory” on page 64

Displaying a List of Files Files are stored on an WLC in the following areas: File—Contains configuration files Copyright © 2013, Juniper Networks, Inc.

Managing Files Stored on the WLC

57

Boot—Contains system image files Temporary—Contains log files and other files created by MSS The file and boot areas are in nonvolatile storage and remain in storage following a software reload or power cycle. The files in the temporary area are removed following a software reload or power cycle. The boot area is divided into two partitions: boot0 and boot1. Each partition can contain one system image file. The file area can contain subdirectories. Subdirectory names are indicated by a forward slash at the end of the name. In the following example, dangdir and old are subdirectories. To display a list of the files in nonvolatile storage and temporary files, type the following command: WLC# dir Following is example output of the above command: =========================================================================== file: Filename

Size

file:configuration 15:02:32

48 KB

Jul 12 2005,

file:corp2:corp2cnfig 22:20:04

17 KB

Mar 14 2005,

corp_a/ 19:15:48

512 bytes

file:dangcfg 22:20:04

14 KB

old/ 17:23:44

512 bytes

Created

May 21 2004, Mar 14 2005, May 16 2004,

file:pubsconfig-april062005 21:08:30

40 KB

May 09 2005,

file:sysa_bak 19:18:44

12 KB

Mar 15 2005,

file:testback 16:37:18

28 KB

Apr 19 2005,

Total:

159 Kbytes used, 207663 Kbytes free

=========================================================================== Boot: Filename

58

Size

Created

boot0:mx040100.020 15:54:08

9780 KB

Aug 23 2005,

*boot1:mx040100.020 21:09:56

9796 KB

Aug 28 2005,

Boot0: Total:


Boot1: Total:





=========================================================================== temporary files: Filename

Size

core:command_audit.cur 21:11:41

37 bytes

Total:

Created Aug 28 2005,

37 bytes used, 91707 Kbytes free

The following command displays the files in the old subdirectory: WLC# dir old =========================================================================== file: Filename

Size

Created

file:configuration.txt 22:55:44

3541 bytes

Sep 22 2003,

file:configuration.xml 22:55:44

24 KB

Sep 22 2003,

Total:


The following command limits the output to the contents of the user files area: WLC# dir file: Following is example output of this command: file: Filename

Size

file:configuration 15:02:32

48 KB

Jul 12 2005,

file:corp2:corp2cnfig 22:20:04

17 KB

Mar 14 2005,

corp_a/ 19:15:48

Created

512 bytes

file:dangcfg 22:20:04

14 KB

dangdir/ 17:23:44

May 21 2004, Mar 14 2005,

512 bytes

May 16 2004,

file:pubsconfig-april062005 21:08:30

40 KB

May 09 2005,

file:sysa_bak 19:18:44

12 KB

Mar 15 2005,

file:testback 16:37:18

28 KB

Apr 19 2005,

Total:


The following command limits the output: WLC# dir core: Copyright © 2013, Juniper Networks, Inc.


59

Following is example output of this command: file: Filename

Size

core:command_audit.cur 21:11:41

37 bytes

Total:



The following command limits the output to the contents of the boot0 partition: WLC# dir boot0: Following is example output of this command: file: Filename

Size

boot0:mx040100.020 15:54:08 Total:

9780 KB



Informational Note: For information about the fields in the output, see the Juniper Networks Mobility System Software Command Reference

Copying a File You can perform the following copy operations: Copy to nonvolatile storage from a TFTP server or FTP server. Copy from nonvolatile storage or temporary storage to a TFTP server or FTP server. Copy from one area in nonvolatile storage to another. Copy a file to a new filename in nonvolatile storage. Securely copy a file using SCP. To copy a file, use the following command. copy source-url destination-url A URL can be one of the following: [subdirname/]filename file:[subdirname/]filename tftp://ip-addr/[subdirname/]filename ftp://username:password@ip-addr/filename scp://ip-addr//tftpboot/filename/username/password tmp:filename The filename and file:filename URLs are equivalent. You can use either URL to refer to a file on the WLC. The tftp://ip-addr/filename URL refers to a file on a TFTP server. If DNS is configured on the WLC, you can specify a TFTP server hostname as an alternative to specifying the IP address. 60




The tmp:filename URL refers to a file in temporary storage. You can copy a file out of temporary storage but you cannot copy a file into temporary storage. The subdirname/ option specifies a subdirectory. If you are copying a system image file into nonvolatile storage, the destination-url must include the boot partition name. You can specify one of the following: boot0:/filename boot1:/filename You must specify the boot partition that was not used to load the current image. The maximum supported file size for TFTP is 32 MB. Informational Note: You can copy a file from an WLC to a TFTP server or from a TFTP server to an WLC, but you cannot use MSS to copy a file directly from one TFTP server to another.

To copy the file floor2wlc from nonvolatile storage to a TFTP server, type the following command: WLC# copy floor2wlc tftp://10.1.1.1/floor2mx success: sent 365 bytes in 0.401 seconds [ 910 bytes/sec] The above command copies the file to the same filename on the TFTP server. To rename the file, type the following command: WLC# copy floor2wlc tftp://10.1.1.1/floor2mx-backup success: sent 365 bytes in 0.401 seconds [ 910 bytes/sec] To copy a file named newconfig from a TFTP server to nonvolatile storage, type the following command: WLC# copy tftp://10.1.1.1/newconfig newconfig success: received 637 bytes in 0.253 seconds [ 2517 bytes/sec] The above command copies the file to the same filename. To rename the file, type the following command: WLC# copy tftp://10.1.1.1/newconfig mxconfig success: received 637 bytes in 0.253 seconds [ 2517 bytes/sec] To copy system image WLC010101.020 from a TFTP server to boot partition 1 in nonvolatile storage, type the following command: WLC# copy tftp://10.1.1.107/WLC010101.002 boot1:WLC010101.002 ........................................................................... .................................success: received 9163214 bytes in 105.939 seconds [ 86495 bytes/sec] To rename test-config to new-config, you can copy it from one name to the other in the same location, and then delete test-config. Type the following commands: WLC# copy test-config new-config WLC# delete test-config success: file deleted.



61

To copy file corpa-login.html from a TFTP server into subdirectory corpa in the nonvolatile storage of the WLC, type the following command: WLC# copy tftp://10.1.1.1/corpa-login.html corpa/corpa-login.html success: received 637 bytes in 0.253 seconds [ 2517 bytes/sec] To copy a file from an FTP server, use the following command: WLC# copy ftp://anonymous:[email protected]/configuration/corpa-login.html

Using SCP to Manage Files To copy a file from a remote server, 172.21.14.83, to a local file system using SCP, type the following command: WLC# copy scp://172.21.14.83//tftpboot/WLC071100.280 file: User: jdoe Password: RSA key fingerprint is 71:cf:f7:9a:1c:3c:19:fd:b8:38:6d:67:c2:ae Do you want to continue (yes/no)? yes ........................................................................... ........................................................................... ........................................................................... .............................................success: copy complete. To copy a file from the WLC to a remote server using SCP, type the following command: WLC# copy file:WLC071100.280 scp://[email protected]//tftpboot/WLC071100.280 copy Password:.................................................................. ...........................................sucess:copy complete. If there are conflicting RSA keys, you see a warning message indicating that the RSA keys have changed. You must edit or delete your SCP host file before continuing the process.

Deleting a File Informational Note: MSS does not allow you to delete the currently running software image file or the running configuration.

1. To delete a file, use the following command: delete url The URL can be a filename of up to 128 alphanumeric characters. 2. To copy a file named testconfig to a TFTP server and delete the file from the WLC, type the following commands: WLC# copy testconfig tftp://10.1.1.1/testconfig success: sent 365 bytes in 0.401 seconds [ 910 bytes/sec] WLC# delete testconfig 62




success: file deleted.

Creating a Subdirectory 1. To create a subdirectory in the user files area of the WLC, use the following command: mkdir {subdirname} 2. To create a subdirectory called corp2 and display the root directory to verify the result, type the following commands: WLC# mkdir corp2 Following is an example of the command return: success: change accepted. WLC# dir =================================================================file: Filename Size

Created

file:configuration 17 KB

May 21 2009, 18:20:53

file:configuration.txt 379 bytes corp2/

May 09 2009, 18:55:17 512 bytes

corp_a/

512 bytes

May 21 2009, 19:22:09

file:dangcfg 13 KB dangdir/

May 21 2009, 19:15:48

May 16 2009, 18:30:44 512 bytes

old/

512 bytes

May 16 2009,17:23:44

Total:

Sep 23 2009, 21:58:48


===================================================================== Boot: Filename

Size

*boot0:bload

Created

746 KB

May 09 2009,

8182 KB

May 09 2009,

8197 KB

May 21 2009,

19:02:16 *boot0:mx070000.020 18:58:16 boot1:mx070000.020 18:01:02 Boot0: Total:


Boot1: Total:


=================================================================== temporary files: Filename Total:


Size

Created



63

Removing a Subdirectory 1. To remove a subdirectory from the WLC, use the following command: rmdir {subdirname} 2. To remove subdirectory corp2, type the following example: WLC# rmdir corp2 success: change accepted.

Managing Configuration Files A configuration file contains CLI commands to set up the WLC. The WLC loads a designated configuration file immediately after loading the system software when the WLC is rebooted. You can also load a configuration file while the WLC is running to change the WLC configuration. When you enter CLI commands to make configuration changes, these changes are immediately added to the WLC configuration but not saved to the configuration file. This section describes displaying the current configuration and configuration file, and saving and loading configuration changes. A procedure is also provided for resetting the WLC to a factory default configuration.

Displaying the Running Configuration 1. To display the configuration running on the WLC, use the following command: show config area [all] 2. The area parameter limits the display to a specific configuration area. Informational Note: For more information, see the Juniper Networks Mobility System Software Command Reference.

The all parameter includes all commands that are set at the default value. Without the all parameter, the show config command lists only those configuration commands set to a value other than the default parameter. 3. To display the running configuration, type the following command: WLC# show config Following is an example of the output of the above command: # Configuration nvgen'd at 2007-5-10 19:08:38 # Image 8.0.2.3.0 # Model WLC2 set ip route default 172.24.111.1 1 set system name WCL2-TP-01 set system ip-address 172.24.111.110 set system countrycode US 64

Displaying the Running Configuration



set timezone PST -8 0 set service-profile clear-acme-public ssid-name acme-public set service-profile clear-acme-public ssid-type clear set service-profile clear-acme-public auth-fallthru last-resort set service-profile crypto-acme-corporate ssid-name acme-corporate set enablepass password c5a068a6b2a5e40e4685196368db15ad7c11 set authentication dot1x ssid acme-corporate ** peap-mschapv2 local set user admin password encrypted 15130f010d24 set radio-profile default service-profile clear-acme-public set radio-profile default service-profile crypto-acme corporate set ap 1 serial-id 07733700338 model WLA532 set ap 1 radio 1 mode enable set vlan 1 port 1 set vlan 1 port 2 set interface 1 ip 172.24.111.110 255.255.255.0 4. To display only the VLAN configuration commands, type the following command: WLC# show config area vlan Following is the output of the above command: # Configuration nvgen'd at 2004-5-10 19:08:38 # Image 2.1.0 # Model WLC # Last change occurred at 2004-5-10 16:31:14 set vlan 1 port 1 set vlan 10 name backbone tunnel-affinity 5 set vlan 10 port 21 set vlan 10 port 22 set vlan 3 name red tunnel-affinity 5 set igmp mrsol mrsi 60 vlan 1 set igmp mrsol mrsi 60 vlan 10

Saving Configuration Changes 1. To save the current configuration to a configuration file, use the following command: save config [filename]



65

If you do not specify a filename of up to 128 alphanumeric characters, the command replaces the startup configuration file that was loaded the last time the software was rebooted.

Informational Note: To display the filename of the configuration file, see “Boot Information” on page 56.

2. To save the running configuration to the file loaded the last time the software was rebooted, type the following command: WLC# save config success: configuration saved. 3. To save the running configuration to a file named newconfig, type the following command: WLC# save config newconfig success: configuration saved to newconfig.

Specifying the Configuration File to Use After the Next Reboot By default, the WLC loads the configuration file named configuration following a software reboot. To use a different configuration file after rebooting, use the following command: set boot configuration-file filename To configure an WLC to load the configuration file floor2wlc following the next software reboot, type the following command: WLC# set boot configuration-file floor2wlc success: boot config set.

Loading a Configuration File To load configuration commands from a file into the WLC current configuration, use the following command: load config [url] Warning: This command completely removes the running configuration and replaces it with the configuration contained in the file. Juniper Networks recommends that you save a copy of the current running configuration to a backup configuration file before loading a new configuration.

The default URL is the name of the configuration file loaded after the last reboot. To load a configuration file named newconfig, type the following command: WLC# load config newconfig Reloading configuration may result in lost of connectivity, do you wish to continue? (y/n) [n]y success: Configuration reloaded After you type y, MSS replaces the current configuration with the configuration in the newconfig file. If you type n, MSS does not load the newconfig file and the current configuration remains unchanged.

66




Specifying a Backup Configuration File In the event that part of the configuration file is invalid or otherwise unreadable, MSS does not load the file. You can optionally specify a backup file to load if MSS cannot load the original configuration file. 1. To specify a backup configuration file, use the following command: set boot backup-configuration filename 2. To specify a file called backup.cfg as the backup configuration file, use the following command: WLC# set boot backup-configuration backup.cfg success: backup boot config filename set. 3. After enabling this feature, you can clear a backup configuration file by entering the following command: WLC# clear boot backup-config success: Backup boot config filename was cleared. To display the name of the file specified as the backup configuration file, enter the show boot command. For example: pubs# show boot Configured boot version:

6.1.0.60

Configured boot image:

boot0:mx060100.020

Configured boot configuration:

file:configuration

Backup boot configuration:

backup.cfg

Booted version:

6.1.0.60

Booted image:

boot0:mx060100.020

Booted configuration:

file:configuration

Product model:

WLC

Resetting to the Factory Default Configuration 1. To reset the WLC to a factory default configuration, use the following command: clear boot config This command removes the configuration file used when the WLC is rebooted. 2. To back up the current configuration file named configuration and reset the WLC to the factory default configuration, type the following commands: a. To copy the current configuration: WLC# copy configuration tftp://10.1.1.1/backupcfg Following is an example of a successful execution of the copy configuration command: success: sent 365 bytes in 0.401 seconds [ 910 bytes/sec] b. To complete clear the current boot configuration file: WLC# clear boot config Copyright © 2013, Juniper Networks, Inc.

Resetting to the Factory Default Configuration

67

Following is an example of a successful execution of the clear boot config command: success: Reset boot config to factory defaults. WLC# reset system force ...... rebooting ...... The reset system force command reboots the WLC. The force option immediately restarts the system and reboots. If you do not use the force option, the command first compares the running configuration to the configuration file. If the files do not match, the WLC does not restart but instead displays a message advising you to either save the configuration changes or use the force option.

Backing Up and Restoring the System The following commands enable you to easily backup and restore WLC system and user files: Table 6.

WLC System Back and Restore Commands

Command

Description

Example

backup system

The backup command creates an archive in Unix tape archive (tar) format.

backup system [tftp:/ip-addr/]filename [all | critical]

restore system

The restore command unzips an archive restore system [tftp:/ip-addr/]filename [all | created by the backup command and copies critical] [force] the files from the archive onto the WLC. If a file in the archive is duplicated on the WLC, the archive version of the file replaces the file on the WLC. The restore command does not delete files without duplicates in the archive. For example, the command does not completely replace the user files area. Instead, files in the archive are added to the user files area.

You can create or unzip an archive located on a TFTP server or on the WLC. If you specify a TFTP server as part of the filename with the backup command, the archive is copied directly to the TFTP server and not stored locally on the WLC. Both commands have options to specify the types of files to back up and restore. Table 7.

Backup and Restore Command Options

Option

Use Description

critical

Backs up or restores system files, including the configuration file used when booting, and certificate files. The size of an archive created by this option is generally 1MB or less. This is the default for the restore command. Use the critical option if you want to back up or restore only the system-critical files required to operate and communicate with the WLC.

all

Backs up or restores the same files as the critical option, and all files in the user files area. Archive files created by the all option are larger than files created by the critical option. The file size depends on the files in the user area, and the file size can be large if the user area contains image files. This is the default for the backup command.Use the all option if you also want to back up or restore WebAAA pages, backup configuration files, image files, and any other files stored in the user files area of nonvolatile storage.

68

Resetting to the Factory Default Configuration



Informational Note: If the archive files cannot fit on the WLC, the restore operation fails. Juniper Networks recommends deleting unnecessary image files before creating or restoring an archive.

The maximum supported file size is 32 MB. If the file size is too large, delete unnecessary files (such as unused copies of system image files) and try again, or use the critical option instead of the all option. Neither option archives image files or any other files listed in the Boot section of dir command output. The all option archives image files only if the files are present in the user files area. The backup command stores the MAC address of the WLC in the archive. By default, the restore command works only if the MAC address in the archive matches the MAC address of the WLC where the restore command is entered. The force option overrides this restriction and allows you to unpack one WLC archive onto another WLC. Warning: Do not use the force option unless advised to do so by Juniper Networks TAC. If you restore one WLC system files onto another WLC, you must generate new key pairs and certificates on the WLC.

Managing Configuration Changes The backup command places the boot configuration file into the archive. (The boot configuration file is the Configured boot configuration in the show boot command output.) If the current configuration contains unsaved changes, these changes are not in the boot configuration file and are not archived. To archive the configuration currently on the WLC, use the save config command to save the current configuration to the boot configuration file, before using the backup command. The restore command replaces the boot configuration on the WLC with the archived one. The boot configuration includes the configuration filename and the image filename to use after the next WLC restart. (These are the Configured boot image and Configured boot configuration files listed in the show boot command output.) The restore command does not affect the running image or the current configuration. If you want to use the configuration in the boot configuration file restored from an archive instead of the current configuration on the WLC, use the load config command to load the boot configuration file, or restart the WLC. If you want to replace the configuration restored from the archive with the running configuration, use the save config command to save the running configuration to the boot configuration file. Informational Note: When the WLC is restarted after the restore command is used, the WLC uses the boot configuration filename in use when the archive was created. If you change the boot configuration filename after creating the archive, the new name is not used when the WLC is restarted. To use the new configuration, use the save config filename command, where filename is the name of the boot configuration file restored from the archive, before you restart the WLC. If you have already restarted the WLC, use the load config filename command to load the new configuration, then use the save config filename command.


Managing Configuration Changes

69

Backup and Restore Examples The following command creates an archive of the system-critical files and copies the archive directly to a TFTP server. The filename in this example includes a TFTP server IP address, so the archive is not stored locally on the WLC. WLC# backup system tftp:/10.10.20.9/sysa_bak critical success: sent 28263 bytes in 0.324 seconds [ 87231 bytes/sec] The following command restores system-critical files on a WLC, from archive sysa_bak: WLC# restore system tftp:/10.10.20.9/sysa_bak success: received 11908 bytes in 0.150 seconds [ 79386 bytes/sec] success: restore complete.

Upgrading the System Image Refer to the MSS Release Notes for a specific version before upgrading to a new MSS release. There may be notes and cautions that apply only to that release.

Command Changes During Upgrade When you upgrade an WLC, some commands from the previously installed release may have been deprecated or changed in the new release, and may affect your configuration. For information about deprecated or changed commands from a previous release, see the release notes for the software version that you are installing on the WLC.

70

Backup and Restore Examples


Wireless LAN Access Points

Wireless LAN Access Points Wireless LAN Access points contain radios that provide connections between your wired network and IEEE 802.11 wireless users. An WLA connects to the wired network through a 10/100 Ethernet link and connects to wireless users through radio signals.

WLA Overview Figure 1–3 shows an example of a Juniper network containing WLAs and WLCs. An WLA can be directly connected to an WLC port or indirectly connected to an WLC through a Layer 2 or IPv4 Layer 3 network. Figure 1–3. Example of a Juniper Network Topology

Configuring WLA Points To configure WLA access points, perform the following tasks: Specify the country of operation. Configure WLA access ports, Distributed WLA connections, and dual homing.


WLA Overview

71

If required, configure radio-specific parameters, including the channel number, transmit power, and external antenna model (optional). Informational Note: You do not need to set channels and power if you use RF Auto-Tuning to set these values. You do not need to specify an external antenna model unless a radio uses an external antenna. However, if you do install an external antenna, you must ensure that the specified external antenna model parameter matches the external antenna attached to the WLA external antenna port, in order to meet regulatory requirements.

Configure SSID and encryption settings in a service profile. Map the service profile to a radio profile. Assign the radio profile to radios, and enable the radios.

Network Address Translation (NAT) Support MSS supports network address translation (NAT) which provides the translation of IP addresses in one network for those in a different network. NAT is typically used in firewall applications in which a private network is hidden behind the firewall to protect it from the public network. In some network configurations, a firewall appliance or other network appliance may be placed between an WLA and an WLC and use NAT in a configuration. Changes to the MSS architecture affected the WLC-WLA control plane, WLC-WLA client data transport, and the WLC-WLC roaming client data transport portions of MSS. NAT support is transparent through MSS.

Country of Operation Before you can configure WLAs and radio parameters, you must specify the country that you plan to operate the radios. Since each country has different regulatory requirements, the country code determines the transmit power levels and channels you can configure on the radios. MSS ensures that the values you can configure are valid for the specified country. Informational Note: For more information on configuring the country of operation, see “Specifying the Country of Operation” on page 85.

Directly Connected WLAs and Distributed WLAs To configure the WLC to support an WLA, you must first determine how the WLA connects to the WLC. There are two types of WLA to WLC connections: Direct—a WLA connects to one 10/100 port on an WLC. The WLC port is then configured specifically for a direct attachment to an WLA. There is no intermediate networking equipment between the WLC and WLA and only one WLA is connected to the WLC port. The WLC 10/100 port provides PoE to the WLA. The WLC also forwards data only to and from the configured WLA on that port. The port numbers on the WLC reference a particular directly connected WLA.

72

WLA Overview



Distributed—An WLA indirectly connected to an WLC is considered a Distributed WLA. There may be intermediate Layer 2 switches or Layer 3 IP routers between the WLC and WLA. The WLC may communicate to the Distributed WLA through any network port. The WLC contains a configuration for a Distributed WLA based on the WLA serial number. Similar to ports configured for directly connected WLAs, distributed WLA configurations are numbered and can reference a particular WLA. These numbered configurations do not reference any physical port.

Distributed WLA Network Requirements Because Distributed WLAs are not directly attached to an WLC, they require additional support from the network. Information on the booting and operation sequence for Distributed WLAs is covered in the section “Boot Process for Distributed WLAs” on page 75. Power - PoE must be provided on one of the Ethernet connections to the WLA. Providing PoE on both Ethernet connections (for models that have two Ethernet ports) allows redundant PoE. DHCP - By default, a Distributed WLA uses TCP/IP for communication, and relies on DHCP to obtain IP information. Therefore, DHCP services must be available on the subnet connected to the WLA. DHCP must provide the following parameters to the WLA: - IP address - Domain name - DNS server address - Default router address

Static IP configuration—If DHCP is not available in the network, a Distributed WLA can be configured with static IP information and the WLC to use as the boot device. DNS—If the intermediate network between the WLC and Distributed WLA includes one or more IP routers, create a TRPZ.mynetwork.com or wlan-switch.mynetwork.com entry on the DNS server. The entry needs to map one of these names to the system IP address of the WLC. If the subnet contains more than one WLC in the same Mobility Domain, you can use the system IP address of any of the WLC switches. (For redundancy, you can create more than one DNS entry, and map each entry to a different WLC in the subnet.) The DNS entry allows the WLA to communicate with an WLC not on the WLA subnet. If the WLA cannot locate an WLC on the same subnet, the WLA sends DNS requests to both TRPZ and wlan-switch, and the DNS suffix for mynetwork.com is obtained through DHCP. If only TRPZ is defined in DNS, the WLA contacts the WLC with an IP address returned for TRPZ. If only wlan-switch is defined in DNS, the WLA contacts the WLC with the IP address for wlan-switch. If both TRPZ and wlan-switch are defined in DNS, the WLA contacts the WLC with IP address for TRPZ. The WLA ignores the IP address for wlan-switch. If both TRPZ and wlan-switch are defined in DNS, and the WLA is unable to contact the IP address for TRPZ, the WLA never contacts the IP address returned for wlan-switch. The WLA does not boot.


WLA Overview

73

Distributed WLAs and Spanning Tree Protocol (STP) A Distributed WLA is a leaf device. You do not need to enable STP on a port directly connected to the WLA. Informational Note: Configuring STP on a port directly connected to a Distributed WLA can prevent the WLA from booting.

As part of the boot process, an WLA disables and reenables the link on the port that the WLA is attempting to boot. If STP is enabled on the device that is directly connected to the port, the link state change can cause the port on the other device to leave the forwarding state and stop forwarding traffic. The port remains unable to forward traffic for the duration of the STP forwarding delay. An WLA waits 30 seconds to receive a reply to a DHCP Discover message, then tries to restart using the other WLA port. If the boot attempt fails on the other port also, the WLA then attempts to restart on the first port. The process continues until a boot attempt is successful. If STP prevents the port on the other device from forwarding traffic during each boot attempt, the WLA repeatedly disables and reenables the link, causing STP to repeatedly stop the other device from forwarding traffic. As a result, the boot attempt is never successful. To allow an WLA to boot over a link that has STP enabled, do one of the following on the other device: Disable STP on the port of the other device. Enable the port fast convergence feature, if supported, on the other device port. If the other device is running Rapid Spanning Tree or Multiple Spanning Tree, configure the port for edge port mode.

Distributed WLAs and DHCP Option 43 The option 43 field in a DHCP Offer message provides a simple and effective way for WLAs to find WLC switches across an intermediate Layer 3 network. It is especially useful in networks that are geographically distributed or have a flat domain name space. You can use the DHCP option 43 field to provide a list of WLC IP addresses, without configuring DNS servers. To use DHCP option 43, configure the option to contain a comma-separated list of WLC IP addresses or hostnames, in the following format: ip:ip-addr1,ip-addr2,... or host:hostname1,hostname2,... Informational Note: You can use an IP address list or a hostname list, but not both. If the list contains both types of values, the WLA does not use the list. Informational Note: If your DNS server requires a fully qualified domain name, using a list of hostnames does not append the domain name to the DNS request.

The IP and host keywords can be in lowercase, uppercase (ip or HOST), or mixed case (example: Ip, Host). You can use spaces after the colon or commas, but spaces are not supported within IP addresses or hostnames. Leading zeroes are supported in IP addresses. For example, 100.130.001.1 is valid.

74

WLA Overview



Valid hostname characters are in uppercase and lowercase letters, numbers, periods ( . ), and hyphens ( ). Other characters are not supported. If you use the host option, you must configure the network DNS server with address records that map the hostnames in the list to the WLC IP addresses. After receiving a DHCP Offer containing a valid string for option 43, a Distributed WLA sends a unicast Find WLC message to each WLC in the list. No configuration is required on the WLC.

Boot Process for Distributed WLAs When a distributed WLA boots on the network, the WLA uses the process described in this section. Note that this process applies only to distributed WLAs. It does not apply to a directly connected WLA. The boot process for a directly connected WLA occurs strictly between the WLA and WLC and makes no use of the network DHCP or DNS services. The boot process for a distributed WLA consists of the following steps: 1. Establishing connectivity on the network. 2. Contacting an WLC. 3. Loading and activating an operational image. 4. Obtaining configuration information from the WLC. These steps are described in more detail in the following sections.

WLA Boot Descriptions The following figures show WLA boot descriptions: Figure 1–4 on page 75 shows an example of the boot process for an WLA connected through a Layer 2 network. Figure 1–5 on page 77 shows an example of the boot process for an WLA connected through a Layer 3 network. Figure 1–6 on page 78 shows an example of the boot process for an WLA configured with static IP information.

Example of an WLA Booting over a Layer 2 Network Figure 1–4 shows an example of the boot process for an WLA connected through a Layer 2 network. WLC1, WLC2, and WLC3 each have a Distributed WLA configuration for the WLA. Figure 1–4. An WLA Booting over a Layer 2 Network


WLA Overview

75

1. The WLA sends a DHCP Discover message from the WLA port 1. 2. DHCP server receives the Discover message (through a relay agent) and replies with a DHCP Offer message with the IP address for the WLA, the router IP address for the WLA IP subnet, the DNS server address, and the domain name. WLA then sends a DHCP Request message to the server and receives an Ack from the server. 3. The WLA sends a broadcast Find WLC message to IP subnet broadcast address. 4. WLC1 and WLC3 have high priority for the WLA and reply immediately. 5. The WLA contacts WLC1 and determines if it should use a locally stored operational image or download it from the WLC. WLC1 is contacted because it has fewer active WLA connections than WLC3. Once the operational image is loaded, the WLA requests configuration information from WLC1.

Example of an WLA Booting over a Layer 3 Network Figure 1–5 shows an example of the boot process for an WLA connected through a Layer 3 network.

76

WLA Overview



Figure 1–5. An WLA Booting over a Layer 3 Network

1. The WLA sends DHCP Discover message from port 1 on the WLA. 2. The DHCP server replies with a DHCP Offer message containing an IP address for the WLA, the default router IP address for the WLA IP subnet, the DNS server address, and the domain name. WLA then sends a DHCP Request message to the server and receives an Ack from the server. 3. The WLA sends a broadcast Find WLC message to the IP subnet broadcast address. 4. When the WLA is unable to locate an WLC on the subnet connected to it, the WLA then sends a DNS request for TRPZ.example.com and wlan.example.com. 5. The DNS server sends the system IP address of the WLC mapped to TRPZ.example.com or wlan.example.com. In this example, the address is for WLC1. 6. The WLA sends a unicast Find WLC message to WLC1. 7. WLC1 receives the Find WLC message and compares the bias settings on each WLC for the WLA. More than one WLC has a high bias for the WLA, so WLC1 selects the WLC with the greatest capacity to add new active WLA connections. In this example, WLC1 has more capacity. WLC1 sends its IP address in the Find WLC Reply message to the WLA.


WLA Overview

77

8. The WLA contacts WLC1 and determines to use a locally stored operational image or download it from the WLC. Once the operational image is loaded, the WLA requests configuration information from WLC1.

Example of a WLA with a Static IP Configuration Booting on the Network Figure 1–6 shows an example of the boot process for an WLA configured with static IP information. In the example, the WLA has been configured to use the following: Static IP address: 172.16.0.42, netmask: 255.255.255.0, default router 172.16.0.20 Boot WLC : wlc2, DNS server: 172.16.0.1 Figure 1–6. WLA Booting with a Static IP Address

After the WLA is configured with the above information, the next time the WLA boots, the following takes place: 1. The WLA sends an ARP request for the IP address to discover if the IP address is available. 2. The DNS server resolves the fully qualified domain name of the WLC, wlc2. 3. The WLA sends a Find WLC message to the WLC mxr2. 4. The wlc2 responds to the Find WLC message. 5. The WLA sends a unicast message to WLC wlc2 and determines if the WLA should use a locally stored operational image or download it from the WLC. 6. Once the operational image is loaded, wlc2 sends configuration information to the WLA.

78

WLA Overview


Loading and Activating Operational Images

Loading and Activating Operational Images An WLA operational image is software that allows the WLA to function as a wireless access point on the network. As part of the WLA boot process, an operational image is loaded into the WLA RAM and activated. The WLA stores copies of the operational image locally in the internal flash memory. The WLA can either load the local image or download an operational image from a connected WLC. After the WLA establishes an WLC connection, the WLA bootloader determines if the WLC is configured to allow the WLA to load a local image or download an image from the WLC. If the WLC is configured with MSS Version 5.0 or later, and the WLC has an older image than the WLA local image, the WLA loads the local image. If the WLC is configured with an older MSS version, or the WLC has a different image than the WLA local image, the WLA downloads the operational image from the WLC. The bootloader also compares the WLA local image version to the image version on the WLC. If the versions do not match, then the image is downloaded from the WLC to the WLA. After the operational image is downloaded from the WLC, the image is copied into the WLA flash memory. The WLA reboots, and copies the new version from the flash memory to the RAM. In addition, the WLA receives configuration information from the WLC and becomes functional on the network as a wireless access point.

Forcing an WLA To Download an Operational Image from the WLC To force the WLA to always download an image from the WLC, use the following command: set ap apnum force-image-download {enable | disable} A change to the forced image download option takes place the next time the WLA is restarted. Even when forced image download is disabled by default, the WLA still checks with the WLC to verify that the WLA has the latest image, and to verify that the WLC is running MSS Version 5.0 or later. The WLA loads a local image only if the WLC is running MSS Version 5.0 or later and does not have a different WLA image than the one in the WLA local storage. If the WLC is not running MSS Version 5.0 or later, or the WLC has a different version of the WLA image than the local version on the WLA, the WLA loads an image from the WLC.

WLA Parameters Table 8 summarizes parameters that apply to individual WLAs, including dual-homing parameters. (For information about parameters for individual radios, see “Radio Profiles” on page 127 and “Radio-Specific Parameters” on page 129.) Table 8.

Global WLA Parameters

Parameter

Default Value

Description

ap-tunnel

disabled

Configures tunneling on a WLA. If a client connects to a WLA that has local switching enabled on a VLAN, and the VLAN does not exist in the VLAN profile, then the client connects in overlay mode.


WLA Parameters

79

Table 8.

Global WLA Parameters (continued)

Parameter

Default Value

Description

name

Based on the port or Distributed WLA connection number. For example:

WLA name.

MP01 AP01 bias

high sticky low

Setting the WLA bias on an WLC to high causes the WLC to be preferred over WLC switches with low bias, for booting and managing the WLA. Setting the bias to sticky allows the WLA to select an WLC to boot from, and the WLA continues to use that WLC for the active data link even if another WLC configured with high bias for the WLA becomes available. Bias applies only to WLC switches that are indirectly attached to the WLA through an intermediate Layer 2 or Layer 3 network. An WLA always attempts to boot on WLA port 1 first, and if an WLC is directly attached on WLA port 1, the WLA boots from it regardless of the bias settings.

group

None

Named set of WLAs. MSS load-balances user sessions among the access points in the group.

upgrade-firmware

enable

Automatic upgrade of boot firmware.

blink

disable

LED blink mode—blinking LEDs on an WLA make the WLA visually easy to identify.

Resiliency and Dual-Homing Options for WLAs WLAs can support a wide variety of resiliency options such as redundancy for PoE, for data link connections, and WLC services. PoE redundancy—On WLA models that have two Ethernet ports, you can provide PoE redundancy by connecting both ports to PoE sources. PoE can come from a directly connected WLC or a PoE injector. Dual-homing support for PoE is automatically enabled when you connect both WLA Ethernet ports.

Informational Note: The only WLA that supports two ports is the WLA522. Other models have only one port.

Data link redundancy—You can provide data link redundancy by connecting both Ethernet ports directly to one WLC, two WLC switches, an intermediate Ethernet switch, or a combination of WLC and Ethernet. If an intermediate Ethernet connection is used, you also need an WLC with a Distributed WLA configuration on the network. Dual-homing support for data link redundancy is automatically enabled when you connect both WLA Ethernet ports.

80

WLA Parameters



WLC redundancy—You can provide redundant WLC services by dual-homing the WLA to two directly connected WLC switches. Another option is to add a Distributed WLA configuration on either two or more indirectly connected WLC switches, or on a combination of a directly connected WLC and one or more indirectly connected WLC switches. To provide WLC redundancy on an WLA model that has only one WLA port, configure a Distributed WLA connection on two or more indirectly connected WLC switches.

Bias On an WLC, configurations for WLAs have a bias (low or high) associated with them. The default parameter is high. An WLC with high bias for an WLA is preferred over an WLC with low bias for an WLA. Configuring the bias as sticky allows the WLA to select an WLC to boot from, and the WLA continues to use that WLC for the active data link even if another WLC configured with high bias for the WLA becomes available. If more than one WLC has high bias, or the bias for all connections is the same, the WLC with the greatest capacity to add more active WLAs is preferred. For example, if one WLC has 50 active WLAs while another WLC has 60 active WLAs, and both WLC switches are capable of managing 80 active WLAs, the new WLA uses the WLC with 50 active WLAs. Informational Note: Bias applies only to WLC switches indirectly attached to the WLA through an intermediate Layer 2 or Layer 3 network. An WLA always attempts to boot on WLA port 1 first, and if an WLC is directly attached on WLA port 1, the WLA boots from it regardless of the bias settings.

Dual-Homed Configuration Examples Dual-homing means that the WLA has more than one connection to the WLC. The following sections show examples of dual-homed configurations. You can use any of these configurations to dual home an WLA model that has two Ethernet ports. WLA models with one Ethernet port support only the dual-homing configuration in “Dual-Homed Distributed Connections to WLC Switches on One WLA Port” on page 83.

Dual-Homed Direct Connections to a Single WLC Figure 1–7 shows an example of a dual-homed direct connection to one WLC. In this configuration, if the WLA active data link with the WLC fails, the WLA detects the link failure and restarts using the other link on the same WLC. Figure 1–7. Dual-Homed Direct Connections to a Single WLC

Dual-Homed Direct Connections to Two WLC Switches Figure 1–8 shows an example of a dual-homed direct connection to two separate WLC switches. In this configuration, if the active data link fails, the WLA detects the link failure and restarts using a link to the other WLC.


WLA Parameters

81

Figure 1–8. Dual-homed Direct Connections to Two WLC Switches

Dual-Homed Direct and Distributed Connections to WLC Switches Figure 1–9 shows an example of a dual-homed configuration where one WLA connection is direct and the other is distributed over the network. Figure 1–9. Dual-Homed Direct and Distributed Connections to WLC Switches

In this example, port 1 of the WLA 1 is directly connected to an WLC. The WLA always attempts to boot first from the directly connected WLC. The WLA attempts to boot using WLA port 2 only if the boot attempt on port 1 fails. If the active data link fails, the WLC reboots using the other link.

Dual-Homed Distributed Connections to WLC Switches on Both WLA Ports Figure 1–10 shows an example of a dual-homed configuration in which both WLA connections are distributed over the network.

82

WLA Parameters



Figure 1–10. Dual-homed Distributed Connections to WLC Switches on Both WLA Ports

In this configuration, the WLA first attempts to boot on port 1. If more than one WLC has high bias or if all WLCs have the same bias, the WLA uses the WLC that has the greatest capacity for new active WLA connections.

Dual-Homed Distributed Connections to WLC Switches on One WLA Port Figure 1–11 shows an example of an WLA with a single physical link to a network containing three WLC switches. Figure 1–11. Single-homed Connection to Multiple WLC Switches on One WLA Port

In this configuration, the WLA sends a boot request through the connected port. WLC switches in the same subnet respond to the WLA. WLC switches with high bias for the WLA respond immediately, whereas WLC switches with low bias for the WLA respond after a brief delay. If the WLCs are in another subnet, the WLA uses DNS to locate one of the WLCs, and requests the WLC to send the IP address of the best WLC to use, based on the bias settings on each WLC and the capacity of each WLC to add new active WLA connections. The WLA then requests an image and configuration files from the best WLC.


WLA Parameters

83

84

WLA Parameters


Configuring WLAs

Configuring WLAs Overview To configure WLAs, perform the following tasks: Specify the country of operation. (See “Specifying the Country of Operation” on page 85.) Configure an Auto-AP profile for automatic configuration of Distributed WLAs. (See “Configuring an Auto-AP Profile for Automatic WLA Configuration” on page 89.) Configure WLA access ports and dual homing. (See “Dual-Homed Direct Connections to a Single WLC” on page 81.) Configure WLA-WLC security. (See “Setting the WLA Security Requirement on an WLC” on page 101.) Configure a service profile to set SSID and encryption parameters. (See “Creating a Service Profile” on page 117.) Configure a radio profile. (See “Creating a New Profile” on page 129.) If required, configure the channel, transmit power, and external antenna type on each radio. (See Table , “Default Values for Radio Profile Parameters” on page 129.) Map the radio profile to a service profile. (See “Mapping the Radio Profile to Service Profiles” on page 135.) Assign the radio profile to radios and enable the radios. (See “Assigning a Radio Profile and Enabling Radios” on page 135.)

Specifying the Country of Operation You must specify the country in which you plan to operate the WLC and the WLAs. MSS does not allow you to configure or enable the WLA radios until you specify the country of operation. Informational Note: In countries where Dynamic Frequency Selection (DFS) is required, MSS performs the appropriate check for radar. If radar is detected on a channel, the WLA radio stops using the channel for the amount of time specified in the country’s regulations. MSS also generates a log message as notification when this occurs.

To specify the country, use the following command: set system countrycode code For the country, you can specify one of the codes listed in Table 9. Table 9.

Country Codes

Country

Code

Algeria

DZ

Argentina

AR

Anguilla

AI

Australia

AU

Austria

AT

Bahrain

BH


Overview

85

Table 9.

Country Codes (continued)

Country

Code

Belgium

BE

Bolivia

BO

Botswana

BW

Brazil

BR

Bulgaria

BG

Canada

CA

Chile

CL

China

CN

Colombia

CO

Costa Rica

CR

Cote d’Ivoire

CI

Croatia

HR

Cyprus

CY

Czech Republic

CZ

Denmark

DK

Dominica

DM

Dominican Republic

DO

Ecuador

EC

El Salvador

SV

Egypt

EG

Estonia

EE

Finland

FI

France

FR

Germany

DE

Greece

GR

Grenada

GD

Guatemala

GT

Honduras

HN

Hong Kong

HK

Hungary

HU

Iceland

IS

India

IN

Indonesia

ID

Ireland

IE

Israel

IL

Italy

IT

Jamaica

JM

Japan

JP

Jordan

JO

Kazakhstan

KZ

86

Overview


Configuring WLAs

Table 9.


Country

Code

Kenya

KE

St. Kitts and Nevis

KN

Kuwait

KW

Cayman Islands

KY

Latvia

LV

Lebanon

LB

Liechtenstein

LI

Lithuania

LT

St. Lucia

LC

Luxembourg

LU

Malaysia

MY

Malta

MT

Mauritius

MU

Mexico

WLC

Monserrat

MS

Morocco

MA

Namibia

NA

Netherlands

NL

New Zealand

NZ

Nigeria

NG

Norway

NO

Oman

OM

Pakistan

PK

Panama

PA

Paraguay

PY

Peru

PE

Philippines

PH

Poland

PL

Portugal

PT

Puerto Rico

PR

Romania

RO

Russia

RU

Saudi Arabia

SA

Serbia

CS

Singapore

SG

Slovakia

SK

Slovenia

SI

South Africa

ZA

South Korea

KR

Spain

ES


Overview

87

Table 9.


Country

Code

Sri Lanka

LK

Sweden

SE

Switzerland

CH

Taiwan

TW

Tanzania

TZ

Thailand

TH

Trinidad and Tobago

TT

Tunisia

TN

Turkey

TR

Ukraine

UA

United Arab Emirates

AE

United Kingdom

GB

United States

US

Uruguay

UY

Venezuela

VE

Vietnam

VN

St. Vincent and the Grenadines

VC

Zambia

ZM

Zimbabwe

ZW

To verify the configuration change, use the following command: show system The following commands set the country code to US (United States) and verify the setting: WLC# set system countrycode US success: change accepted. WLC# show system =========================================================================== ==== Product Name:

WLC

System Name:

WLC

System Countrycode: US System Location: System Contact: System IP:

30.30.30.2

System idle timeout:3600 System MAC:

00:0B:0E:02:76:F6

=========================================================================== ==== Boot Time: 88

Overview

2003-05-07 08:28:39 Copyright © 2013, Juniper Networks, Inc.

Configuring WLAs

Uptime:

0 days 04:00:07

=========================================================================== ==== Fan status:

fan1 OK fan2 OK fan3 OK

Temperature:

temp1 ok

PSU Status: Supply missing

temp3 ok

Lower Power Supply DC ok AC ok

Memory: Total POE Draw [W]

temp2 ok

Upper Power

115.09/496.04 (23%) : 32.000

===========================================================================

Configuring an Auto-AP Profile for Automatic WLA Configuration You can use an Auto-AP profile to deploy unconfigured Distributed WLAs. A Distributed WLA that does not have a configuration on an WLC can receive a configuration file from the Auto-AP profile instead. From the range of available valid WLA numbers on the WLC, the Auto-AP profile assigns a Distributed WLA number and name to the WLA. The Auto-AP profile also configures the WLA and radio parameter settings in the profile. (See “Configuring an Auto-AP Profile” on page 90.) The Auto-AP profile does not configure SSIDs, encryption parameters, or any other parameters managed by service profiles. You still need to configure a service profile separately for each SSID. An WLC can have one Auto-AP profile. Informational Note: Auto-AP only works with APs on VLANs where DHCP is enabled and the AP can get an IP address.

Locating an WLC for Automatic WLA Configuration The boot process for unconfigured Distributed WLA on an WLC is similar to the process for configured Distributed WLAs. After the WLA starts up, the WLA uses DHCP to configure the IP connection to the network. The WLA then uses the IP connection to contact an WLC switch. The WLC contacted by the WLA determines the best WLC for configuring the WLA, and sends the WLC IP address to the WLA. The best switch to use for configuring the WLA is one that has an Auto-AP profile with a high bias setting. If more than one WLC has an Auto-AP profile with a high bias setting, the WLC with the greatest capacity to add new unconfigured WLAs is selected. An WLC with the capacity to add a new unconfigured Distributed WLA meets the minimum of the following criteria: Maximum number of WLAs configurable on the WLC, minus the number already configured. Maximum number of WLAs active on the WLC, minus the number already active.


Overview

89

For example, suppose the Mobility Domain has two WLC switches, with the capacities and loads listed in Table 10. Table 10.

Example WLC8 WLA Capacities and Loads WLC8A

WLC8B

Maximum Configured

30

30

Maximum Active

12

12

Number Currently Configured

25

20

Number Currently Active

8

12

For WLC8A: The Number of WLAs that can be configured on the WLC, minus the number currently configured, is 30 - 25 = 5. The Number of WLAs that can be active on the WLC, minus the number currently active, is 12 - 8 = 4. The lesser of the two values is 4. The WLC can add up to 4 more WLAs. For WLC8B: The Number of WLAs that can be configured on the WLC, minus the number currently configured, is 30 - 20 = 10. The Number of WLAs that can be active on the WLC, minus the number currently active, is 12 - 12 = 0. The lesser of the two values is 0. The WLC cannot add more WLAs. WLC8A has the capacity to add 4 more WLAs, whereas WLC8B cannot add any more WLAs. Therefore, the contacted WLC sends the IP address of WLC8A to the WLA. The WLA then requests a software image file and configuration from WLC8A.

Configured WLAs Have Precedence Over Unconfigured WLAs When an WLC determines the WLC IP address to send to a booting WLA, the WLC gives preference to WLAs previously configured instead of unconfigured WLAs that require an Auto-AP profile. The WLC can direct a configured WLA to a WLC with active WLAs configured using the Auto-AP profile, even if the WLC does not have capacity for more active WLAs. In this case, the WLC randomly selects an WLA with an Auto-AP profile to disconnect, and accepts a connection from the configured WLA instead. The disconnected WLA can then begin the boot process again to find another WLC with an Auto-AP profile. When the WLA is disconnected, the WLA clients experience a service disruption, and attempts to associate with another available WLA to reconnect to the SSID. If another WLA is not available to a client, the client can still reconnect after the disconnected WLA locates a new WLC and finishes the boot and configuration process.

Configuring an Auto-AP Profile The Auto-AP profile for Distributed WLA configuration is identical to configuring an individual WLA, except the configuration has the name auto instead of a Distributed WLA number. To create an Auto-AP profile for automatic Distributed WLA configuration, type the following command: WLC# set ap auto success: change accepted.

90

Overview


Configuring WLAs

To display the WLA settings in the Auto-AP profile, type the following command: WLC# show ap config Ap auto: mode: disabled bias: high fingerprint boot-download-enable: YES force-image-download: Radio 1: type: 802.11g, mode:

NO enabled, channel: dynamic

tx pwr: 15, profile: default auto-tune max-power: default Radio 2: type: 802.11a, mode:

enabled, channel: dynamic

tx pwr: 11, profile: default auto-tune max-power: default This example shows the defaults for the WLA parameters you can configure in the Auto-AP profile. Table 11 lists the configurable Auto-AP profile parameters and their defaults. The only parameter that requires configuration is the Auto-AP profile mode. The Auto-AP profile is disabled by default. To use the Auto-AP profile to configure Distributed WLAs, you must enable the profile. (See “Enabling the Auto-AP Profile” on page 92.) Table 11.

Configurable Profile Parameters for Distributed WLAs

Parameter

Default Value

WLA Parameters bias

high

blink

disable

contact

none

force-image-download

disable (NO)

group (load balancing group)

none

mode

disabled

persistent

none

timeout

25seconds

upgrade-firmware (boot-download-enable)

enable (YES)

Radio Parameters radio num auto-tune max-power

default

radio num mode

enabled

radio num radio-profile

default

radiotype

11g (or 11b for country codes where 802.11g is not allowed)

Also, the SSIDs and encryption settings are configured from the service profiles mapped to the radio profile. To use a radio profile other than default, you must specify the radio profile. (See “Specifying the Radio Profile Used by the Auto-AP Profile” on page 92.)


Overview

91

Changing WLA Parameter Values The commands for configuring WLA and radio parameters for the Auto-AP profile are identical to the commands for configuring an individual Distributed WLA. Instead of specifying a Distributed WLA number with the command, specify auto. For more information about the syntax, see the “WLA Commands” chapter of the Juniper Mobility System Software Command Reference. WLA Parameters: set ap auto bias {high | low} set ap auto blink {enable | disable} set ap auto force-image-download {enable | disable} set ap auto group name set ap auto mode {enable | disable} set ap auto persistent [apnum | all] set ap auto upgrade-firmware {enable | disable} Radio Parameters: set ap auto radiotype {11a | 11b| 11g} set ap auto radio {1 | 2} auto-tune max-power power-level set ap auto radio {1 | 2} mode {enable | disable} set ap auto radio {1 | 2} radio-profile name mode {enable | disable}

Enabling the Auto-AP Profile To enable the Auto-AP profile for automatic Distributed WLA configuration, type the following command: WLC# set ap auto mode enable success: change accepted.

Specifying the Radio Profile Used by the Auto-AP Profile The Auto-AP profile uses radio profile default by default. To use another radio profile instead, use the following command: set ap auto radio {1 | 2} radio-profile profile-name mode {enable | disable} The following command changes the Auto-AP profile to use radio profile autodap1 for radio 1: WLC# set ap auto radio 1 radio-profile autodap1 success: change accepted.

Informational Note: You must configure the radio profile before you can apply it to the Auto-AP profile.

92

Overview


Configuring WLAs

Displaying Status Information for WLAs Configured by the Auto-AP Profile To display status information for WLAs configured by the Auto-AP profile, type the following command: WLC# show ap status auto AP: 7, AP model: WLA522, manufacturer Juniper, name: MP07 ==================================================== State:

operational (not encrypted)

CPU info:

IBM:PPC speed=266666664 Hz version=405GPr id= ram=33554432 s/n=0333703027 hw_rev=A3

Uptime:

18 hours, 36 minutes, 27 seconds

Radio 1 type: 802.11g, state: configure succeed [Enabled] (802.11b protect) operational channel: 1 operational power: 14 base mac: 00:0b:0e:00:d2:c0 bssid1: 00:0b:0e:00:d2:c0, ssid: public bssid2: 00:0b:0e:00:d2:c2, ssid: employee-net bssid3: 00:0b:0e:00:d2:c4, ssid: mycorp-tkip Radio 2 type: 802.11a, state: configure succeed [Enabled] operational channel: 64 operational power: 14 base mac: 00:0b:0e:00:d2:c1 bssid1: 00:0b:0e:00:d2:c1, ssid: public bssid2: 00:0b:0e:00:d2:c3, ssid: employee-net bssid3: 00:0b:0e:00:d2:c5, ssid: mycorp-tkip The output displays auto next to the Distributed WLA number to indicate that the WLA was configured using an Auto-AP profile.

Converting an WLA Configured by the Auto-AP Profile into a Permanent WLA You can convert a temporary WLA configuration created by the Auto-AP profile into a persistent WLA configuration on the WLC. To do so, use the following command: set ap auto persistent {apnum | all} This command creates a persistent Distributed WLA configuration based on the settings in the Auto-AP profile. The Distributed WLA name and number assigned by the Auto-AP profile are used for the persistent entry. For example, if the Auto-AP profile assigned the number 100 and the name DAP100 to the WLA, the persistent configuration for the WLA has the same number and name. In this case, use 100 as the apnum with show ap, set ap, or clear ap commands.


Displaying Status Information for WLAs Configured by the Auto-AP Profile

93

The WLA continues to operate without interruption after you enter the set ap auto persistent command. The next time the WLA is restarted, the Auto-AP profile is not used to configure the WLA. Instead, the persistent configuration is used. (Use the save config command to make the WLA configuration persistent across switch restarts.)

94

Displaying Status Information for WLAs Configured by the Auto-AP Profile


Configuring WLA Port Parameters

Configuring WLA Port Parameters To configure an WLC to connect to an WLA, see “Configuring an WLA” on page 95. Optionally, you also can change other parameters that affect the entire WLA: WLA name. (See “Changing WLA Names” on page 97.) Dual-home bias. (See “Changing Bias” on page 97.) Session load-balancing. “Managing Sessions” on page 221 Automatic firmware upgrade capability. (See “Disabling or Reenabling Automatic Firmware Upgrades” on page 98.) LED blink mode. (See “Enabling LED Blink Mode” on page 98.) Table 12 lists how many WLAs you can configure on an WLC, and how many WLAs that an WLC can boot. The numbers are for directly connected and Distributed WLAs combined. Table 12.

Maximum WLAs Supported Per WLC

WLC Model

Maximum That Can Be Configured

Maximum That Can Be Booted

WLC2800

2048

512

WLC200

480

32, 64, 96, 128, or 192*

WLC880R

2048

192a

WLC880

512

128

WLC8

48

12

WLC2

16

3

a.The number depends on the type of license purchased from Juniper Networks.

Configuring an WLA Configure the WLA using the following command: set ap apnum serial-id serial-ID model {2330 | 2330A | 2330B| 2332-A1| AP-EASYA| AP1602 | AP1602C | AP2750 | AP3750 | AP3850 | AP9551| MP371 | MP371B | MP-372 | MP372A| MP372B| | MP422 | MP422A | MP422B | MP422FB| MP422F| | MP432 | MP432F| MP-522 | MP-522E MP620 | MP620A | MP620B| MP622 | MP71 |MP82|| WLA321-US | WLA322-US |WLA522E-US | WLA532-US | WLA532E-US | WLA632-US |} [radiotype {11ng | 11a | 11b| 11g | 11na}] To configure an WLA model MP422 with serial-ID 0322199999, type the following command: WLC# set ap 1 serial-id 0322199999 model MP620 success: change accepted. Informational Note: The variable, apnum, can now have a value from 1 to 9999 on the network. Informational Note: To specify the external antenna type, use the set ap radio antennatype command. See “Radio-Specific Parameters” on page 129.


95

Configuring Static IP Addresses on Distributed WLAs By default, Distributed WLAs use the procedure described in “Distributed WLAs and DHCP Option 43” on page 74 to obtain an IP address and connect to an WLC. In some installations, DHCP may not be available. In such a case, you can manually assign static IP address information to the WLA. You can also optionally specify the WLC that the Distributed WLA uses as the boot device, and an 802.1Q VLAN tag to be applied to Ethernet frames sent from the distributed WLA. When you configure static IP information for a Distributed WLA, the WLA uses the boot procedure described in “Example of a WLA with a Static IP Configuration Booting on the Network” on page 78 instead of the default boot procedure.

Specifying IP Information To specify static IP address information for a Distributed WLA, use the following command: set ap apnum boot-configuration ip ip-addr netmask mask-addr gateway gateway-addr [mode {enable | disable}] To configure Distributed WLA 1 to use IP address 172.16.0.42 with a 24-bit netmask, and use 172.16.0.20 as the default router (gateway), type the following command: WLC# set ap 1 boot-configuration ip 172.16.0.42 netmask 255.255.255.0 gateway 172.16.0.20 mode enable success: change accepted. The next time the Distributed WLA is booted, the WLA uses the specified IP information. If the manually assigned IP information is incorrect, the WLA uses DHCP to obtain the IP address.

Specifying the WLC Information To specify the WLC that a WLA contacts and attempts to use as a boot device, use the following command: set ap apnum boot-configuration [switch-ip ip-addr] [name name dns ip-addr] [mode {enable | disable}] You can specify the WLC by a fully qualified domain name (FQDN). In this case, you also specify the address of the DNS server used to resolve the WLC name. If you specify the address of the WLC, and the WLC name and DNS server address, then the WLA ignores the WLC address and uses the FQDN. When a static IP address is specified for a Distributed WLA, there is no preconfigured DNS information or DNS name for the WLC, the Distributed WLA attempts to use as the boot device. If you configure a static IP address for a Distributed WLA, but do not specify a boot device, then the WLC must be reachable via subnet broadcast. The following command configures Distributed WLA 1 to use the WLC with address 172.16.0.21 as the boot device. WLC# set ap 1 boot-configuration switch-ip 172.16.0.21 mode enable success: change accepted. The following command configures Distributed WLA 1 to use the WLC with the name mxr2 as the boot device. The DNS server at 172.16.0.1 is used to resolve the name of the WLC.

96


Configuring WLA Port Parameters

WLC# set ap 1 boot-configuration switch name mxr2 dns 172.16.0.1 mode enable success: change accepted.

Specifying VLAN information To specify 802.1Q VLAN tagging information for a Distributed WLA, use the following command: set ap apnum boot-configuration vlan vlan-tag tag-value [mode {enable disable}] When this command is configured, all Ethernet frames transmitted from the Distributed WLA are formatted with an 802.1Q tag with a specified VLAN number. Untagged frames sent to the Distributed WLA are ignored. The following command configures Distributed WLA 1 to use VLAN tag 100: WLC# set ap 1 boot-configuration vlan vlan-tag 100 mode enable success: change accepted.

Clearing an WLA from the Configuration Warning: When you clear an WLA, user sessions on the WLA are terminated

To clear the port settings from a port, use the following command: clear port type port-list This command resets the port as a network port and removes all WLA-related parameters from the port. Informational Note: The clear port type command does not place the cleared port in any VLAN, not even in the default VLAN (VLAN 1). To use the cleared port in a VLAN, you must add the port to the VLAN.

To clear an WLA, use the following command: clear ap apnum

Changing WLA Names The default name of a directly attached WLA is based on the port number of the WLA access port. For example, the default name for an WLA on WLA access port 1 is MP01. The default name of a Distributed WLA is based on the number you assign to it when you configure the connection. For example, the default name for Distributed WLA 1 is AP01. WLA names appear in the output of some CLI show commands and in RingMaster. To change the name of an WLA, use the following command: set ap apnum name name

Changing Bias The CLI commands described in this section enable you to change the bias for an WLA.


97

To change the bias of an WLA, use the following command: set ap apnum bias {high | sticky | low} The default bias is high. To change the bias for a Distributed WLA to low, type the following command: WLC# set ap 1 bias low success: change accepted.

Disabling or Reenabling Automatic Firmware Upgrades An WLA can automatically upgrade the boot firmware by loading a later version of the firmware from an WLC when the WLA is booting. Automatic firmware upgrades are enabled by default. To disable or reenable automatic firmware upgrades, use the following command: set ap apnum upgrade-firmware {enable | disable}

Enabling LED Blink Mode Blink mode makes an WLA easy to identify. When blink mode is enabled on WLAs, the health and radio LEDs alternately blink green and amber. When blink mode is enabled on an AP2750, the 11a LED blinks on and off. By default, LED blink mode is disabled. If enabled, blink mode continues until you disable it. Changing the LED blink mode does not alter operation of the WLA. Only the behavior of the LEDs is affected. To enable or disable LED blink mode, use the following command: set ap apnum blink {enable | disable}

Configuring AP LED Control This LED control feature incorporates a single nonvolatile setting which can be set to Auto, Static, or off. The default setting is Auto and each AP can have a different setting. Using this feature disables the flashing LEDs on the AP. To configure this feature, use the following command: set ap apnum led-mode {auto | static | off} When set to auto, the LEDs operate normally. When set to Off, the LEDs are disabled. When set to static, the LEDs operate normally, but the normal flashing patterns are converted to a static On pattern.

Configuring AP Communication Time Out You can configure the communication time out on a WLA using the following command” set ap apnum time-out seconds The length of time can be set from 5 to 3600 seconds. The default value is 25 seconds.

98


Configuring WLA-WLC Security

Configuring WLA-WLC Security Overview MSS provides security for management traffic between WLC switches and Distributed WLAs. When the feature is enabled, all management traffic between Distributed WLAs that support encryption and the WLC is encrypted. WLA-WLC security is set to optional by default. The encryption uses RSA as the public key cryptosystem, with AES-CCM for data encryption and integrity checking and HMAC-MD5 for keyed hashing and message authentication during the key exchange. Bulk data protection is provided by AES in CCM mode (AES CTR for encryption and AES-CBC-MAC for data integrity). A 64-bit Message Authentication Code is used for data integrity. Informational Note: This feature applies to Distributed WLAs only, not to directly connected WLAs configured on WLC ports.

Informational Note: The maximum transmission unit (MTU) for encrypted WLA management traffic is 1498 bytes, whereas the MTU for unencrypted management traffic is 1474 bytes. Make sure the devices in the intermediate network between the WLC and Distributed WLA can support the higher MTU value.

Encryption Key Fingerprint WLAs are configured with an encryption key pair at the factory. The fingerprint for the public key is displayed on a label on the back of the WLA, in the following format: RSA a:aaaa:aaaa:aaaa: aaaa:aaaa:aaaa:aaaa If the WLA is already installed, you can display the fingerprint in MSS. (See “Finding the Fingerprint” on page 100.)

Encryption Options By default, an WLC can configure and manage a Distributed WLA even if the WLA has an encryption key, and if you confirm the fingerprint by setting it in MSS. You can configure an WLC to require Distributed WLAs to have an encryption key. In this case, the WLC also requires the fingerprints to be confirmed in MSS. When WLA security is required, an WLA can establish a management session with the WLC only if the fingerprint has been confirmed in MSS. If you do not want any WLAs to use encryption for management information, you can disable the feature.


Overview

99

Table 13 lists the WLA security options and whether an WLA can establish a management session with an WLC based on the option settings. Table 13.

WLA Security Requirements

WLA Security Setting

WLA Has Fingerprint?

Fingerprint Verified in MSS?

WLA Can Establish Management Session with WLC?

WLA Security Required

Yes

Yes

Yes

No

No

No

Not Applicable

No

WLA Security Optional

Yes

Yes

No

Yesa

No

Yes

Not Applicable

Yes

1

a.MSS generates a log message listing the WLAserial number and fingerprint so you can verify the WLA identity. (See “Fingerprint Log Message” on page 101.)

Verifying an WLA Fingerprint on an WLC To verify an WLA fingerprint, find the fingerprint and use the set ap fingerprint command to enter the fingerprint in MSS.

Finding the Fingerprint The WLA fingerprint is listed on a label on the back of the WLA. (See “Encryption Key Fingerprint” on page 99.) If the WLA is already installed and operating, use the show ap status command to display the fingerprint. The following example shows information for WLA 8, including the fingerprint: WLC# show ap status 8 AP: 7, AP model:WLA522, manufacturer Juniper, name: MP07 fingerprint: b4:f9:2a:52:37:58:f4:d0:10:75:43:2f:45:c9:52:c3 ==================================================== State:

operational (not encrypted)

CPU info:

IBM:PPC speed=266666664 Hz version=405GPr id=0x29f1886d447f111a ram=33554432 s/n=0424000779 hw_rev=A3

Uptime:


Radio 1 type: 802.11g, state: configure succeed [Enabled] operational channel: 1 operational power: 1 base mac: 00:0b:0e:0a:60:00 bssid1: 00:0b:0e:0a:60:00, ssid: public bssid2: 00:0b:0e:0a:60:02, ssid: juniper Radio 2 type: 802.11a, state: configure succeed [Enabled] operational channel: 48 operational power: 11

100

Overview


Configuring WLA-WLC Security

base mac: 00:0b:0e:0a:60:01 bssid1: 00:0b:0e:0a:60:01, ssid: public bssid2: 00:0b:0e:0a:60:03, ssid: juniper The fingerprint is displayed even if it is unverified in MSS. Informational Note: The show ap config command lists an WLA fingerprint only if the fingerprint has been verified in MSS. If the fingerprint has not been verified, the fingerprint information in the command output is blank.

Verifying a Fingerprint on the WLC To verify an WLA fingerprint on an WLC, use the following command: set ap apnum fingerprint hex where hex is the 16-digit hexadecimal number of the fingerprint. Use a colon between each digit. Make sure the fingerprint you enter matches the fingerprint used by the WLA. The following example sets the fingerprint for Distributed WLA 8: WLC# set ap 8 fingerprint b4:f9:2a:52:37:58:f4:d0:10:75:43:2f:45:c9:52:c3 success: change accepted.

Setting the WLA Security Requirement on an WLC You can configure the WLC to require all Distributed WLAs to have encryption keys. In this case, the WLC does not establish a management session with a Distributed WLA unless the WLA has a key, and you have confirmed the fingerprint of the key in MSS. Informational Note: A change to WLA security support does not affect management sessions that are already established. To apply the new setting to an WLA, restart the WLA.

To configure WLA security requirements, use the following command: set ap security {require | optional | none} The require option enforces encryption of management traffic for all Distributed WLAs, and requires the key fingerprints to be confirmed in MSS. The none option disables encryption of management traffic for all Distributed WLAs. The default is optional, which allows connection to WLAs with or without encryption. The following command configures an WLC to require Distributed WLAs to have encryption keys: WLC# set ap security require

Fingerprint Log Message If WLA encryption is optional, and an WLA with an unverified fingerprint in MSS establishes a management session with the WLC, MSS generates a log message such as the following: AP-HS:(secure optional)configure AP 0335301065 with fingerprint c6:98:9c:41:32:ab:37:09:7e:93:79:a4:ca:dc:ec:fb Copyright © 2013, Juniper Networks, Inc.

Overview

101

The message lists the serial number and fingerprint of the WLA. You can check this information against your records to verify that the WLA is authentic.

102

Overview


Configuring IEEE 802.11n Combining centralized WLAN management with optimized traffic flow, Smart Mobile provides the highest performance WLANs today—802.11n-ready without costly upgrades. Smart Mobile’s intelligent switching is the first and only WLAN architecture that allows data to be forwarded centrally or in distributed fashion, depending on the underlying application. MSS now supports 802.11n with the introduction of new 802.11n-capable WLAs. Some of the features for the 802.11n WLAs include the following: 40 MHz channels High throughput Additional Rates MAC Data Protocol Unit (MPDU) aggregation MIMO Legacy Clients and WLAs 2.4 GHz and 5 GHz capabilities You can configure different data rates on the 802.11n-capable WLAs for 802.11b, 802.11ng, and 802.11na. Table 14.

Data Rates on IEEE 802.11n-capable WLAs

IEEE Standard

Data rates

802.11na

6.0, 9.0,12.0, 18.0, 24.0, 36.0, 48.0, 54.0, MCS0-15

802.11b

1.0, 2.0, 5.5, 11.0

802.11ng

1.0, 2.0, 5.5, 6.0, 9.0, 11.0, 12.0, 18.0, 24.0, 36.0, 48.0, 54.0, MCS0-15

PoE Requirements PoE support is different for the MP432 because the WLA has two 802.11n radios and requires more PoE support than a single 802.3af power source. There are two possible configurations for supplying power to the MP432: If the power mode is set to “auto”, the power is managed automatically by sensing the power level on the AP. If low power is detected, unused Ethernet is disabled and reduces the traffic on the 2.4 GHz radio. If high power is detected, then both radios operate at 3x3 (3 transmit chains and 3 receive chains). If the power mode is set to “high”, both radios operate at the maximum power available which requires both ports using 802.3af PoE. set ap power-mode


Configuring IEEE 802.11n

103

Glossary of Terms for IEEE 802.11n Table 15.

IEEE 802.11n Terms

Term

Definition

A-MPDU (Aggregate MAC Protocol Data Unit)

Allows multiple MPDUs to be transmitted as a single PDU frame. This is configured as 8K, 16K, 32K, or 64K.

A-MSDU (Aggregate MAC Service Data Unit)

Allows multiple MSDUs to be transmitted within a single or multiple data MSDUs. Only MSDUs with whose destination address and source address map to the same receiver address and transmitter address are aggregated. This can be configured as 4K or 8K.

Short Guard Interval

Used to prevent inter-symbol interference for 802.11n. When enabled, the interval is 400 nanoseconds and enhances throughput when multi-path delay is low.

Informational Note: Best Practices for 802.11n: Separate radio profiles for using long and short guard intervals 40 MHz channels should not be configured on the 2.4 GHZ radio. 40 MHz channels may not be optimal for areas with high client density such auditoriums or large classrooms. Consider using two 802.11n WLAs on different 20 MHz channels and load balance traffic between the two WLAs

Configuration Commands WLCR2# set ap apnum port portnum model {2330 | 2330A | AP2750 | AP3750 |AP3850 | MP352| MP371 | MP372 | MP372-JP | MP372A | MP-372-CN |MP372-JP | MP422 | MP422A | MP422F| MP432 | MP620 | MP620A | MP71} poe {enable | disable} radiotype {11a| 11b|11g | 11na|11ng}

Frame Aggregation Commands Frame aggregation is a feature of the IEEE 802.11e and 802.11n wireless LAN standards that increases throughput by sending two or more data frames in a single transmission. MAC Serivce Data Unit (MSDU) aggregation collects Ethernet frames to be transmitted to a single destination and wraps them in a single 802.11n frame. This is efficient because Ethernet headers are much shorter than 802.11 headers. MAC Protocol Data Unit (MPDU) aggregation also collects Ethernet frames to be transmitted to a single destination, but it wraps each frame in an 802.11n MAC header. WLCR2# set service-profile profile-name 11n a-mpdu-max-length [8K| 16K| 32K| 64K] a-msdu-max-length [4K | 8K] frame-aggregation [msdu|mpdu|all|disable] {mode-na|mode-ng [enable|disable| required]} short-guard-interval [enable|disable]

104

Configuring IEEE 802.11n


Data Rate Commands WLCR2# set service-profile profile-name transmit-rates 11ng mandatory {1.0|2.0|5.5|6.0|9.0|11.0|12.0|18.0|24.0|36.0|48.0|54.0|m0|m1|m2|m3|m 4|m5|m6|m7|m8|m9|m10|m11|m12|m13|m14|m15} beacon-rate disabled multicast-rate {auto|1.0|2.0|5.5|6.018.0|24.0|36.0|48.0|54.0| m0|m1|m2|m3|m4|m5|m6|m7|m8|m9|m10|m11|m12|m13|m14|m15} WLCR2# set service-profile profile-name transmit-rates 11na mandatory {6.0|9.0|12.0|18.0|24.0|36.0|48.0|54.0|m0|m1|m2|m3|m4|m5|m6|m7|m8|m9| m10| m11|m12|m13|m14|m15} beacon-rate disabled multicast-rate {auto|6.0|9.0|12.0|18.0|24.0|36.0|48.0|54.0|m0|m1|m2|m3|m4|m5|m6|m7|m 8|m9|m10|m11|m12|m13|m14|m15} 11n Channel Commands

WLCR2#

profile-name 11n channel-width-na {20MHz | 40MHz}

Muticast Traffic to Unicast Traffic Conversion Media applications require reliable support for media transmissions on the wireless network. Applications and products such as security and surveillance use "TV-like" video distribution on the wireless network and require reliable support for quality content delivery. Multicast transmission is unreliable due to the absence of feedback mechanism in the IEEE 8002.11 MAC protocol. Broadcast can be undesirable in some situations such as wireless phones in sleep mode may wake up when a broadcast packet is received. This feature uses the multicast to unicast conversion of video content and performs additional optimizations such as prioritization of video traffic, bandwidth reservation, and load optimization on the WLA to ensure reliable delivery of video content.


Muticast Traffic to Unicast Traffic Conversion

105

EgressQ - multicast and unicast frames that are part of the existing AP software. M2U Handler - decides if multicast conversion is required based on the input received from the conversion parameter, data payload type such as voice and video, excessive number of associations, etc. M2U Converter - consults the IGMP member list and decides which wireless clients receive unicast frames. This also includes IGMP v3 enabled wireless clients. The module also optimizes the buffer requirement to deliver multicast frames to multiple wireless clients as unicast frames. IGMP Member List - contains information about wireless clients joining multicast groups. To configure this feature, use the following command: WLC# set service-profile profilename multicast-conversion {enable | disable}

Displaying WLA Information You can display the following information: WLA and radio-specific configuration settings Connection information for Distributed WLAs configured on an WLC List of Distributed WLAs not configured on an WLC Connection information for Distributed WLAs Service profile information Radio profile information Status information Information about static IP addresses on Distributed WLAs Statistics counters

106

Displaying WLA Information


Information about VLAN profiles configured for local switching ARP table on an WLA Forwarding Database (FDB) for an WLA Information about the VLANs locally switched by an WLA Information about ACLs used by the WLA External antennas as the configured antenna type

Displaying WLA Configuration Information To display configuration information, use the following commands: show ap config [apnum [radio {1 | 2}]] The command lists information separately for each WLA. To display configuration information for WLA59, type the following command: WLC# show ap config 4 AP 4 (AP04) Model: MP422 Mode: Bias: high Power mode: auto Options: upgrade-firmware Connection: network Serial number: 0675200557 Fingerprint: Communication timeout: 25 Location: Contact: Vlan-profile: default Radio 1 (802.11g) Mode: sentry Radio profile: default Channel: dynamic Load balancing: YES Tx power: 22 Load balancing group: Autotune max power: default Force rebalance: NO Antenna location: indoors Antenna type: INTERNAL Service profiles: Snoop filters on radio: none Snoop filters on radio profile: none Radio 2 (802.11a) Mode: enabled Radio profile: mirunaMeshOne Copyright © 2013, Juniper Networks, Inc.


107

Channel: 36 Load balancing: YES Tx power: 5 Load balancing group: Auto tune max power: default Force rebalance: NO Antenna location: indoors Antenna type: INTERNAL Service profiles: mirunaMeshOne (Mesh) Snoop filters on radio: none Snoop filters on radio profile: non

Informational Note: For information about the fields in the output, see the Juniper Mobility System Software Command Reference.

Displaying Connection Information for Distributed WLAs To display connection information for Distributed WLAs configured on an WLC, use the following command: show ap global [apnum | serial-id serial-ID] This command lists the System IP addresses of all the WLC switches configured with each Distributed WLA, and lists the bias for the WLA on each WLC. For each Distributed WLA that is configured on the local WLC, the connection number is also listed. Connections are shown only for the Distributed WLAs that are configured on the WLC where the command is entered, and only for the Mobility Domain the WLC is in. To display connection information for all WLAs configured on a WLC, type the following command: WLC# show ap global Total number of entries: 8 AP Serial Id

WLC IP Address

Bias

--- ----------- --------------- ----

108

1

11223344

10.3.8.111

HIGH

-

11223344

10.4.3.2

LOW

2

332211

10.3.8.111

LOW

-

332211

10.4.3.2

HIGH

17

0322100185

10.3.8.111

HIGH

-

0322100185

10.4.3.2

LOW

18

0321500120

10.3.8.111

LOW

-

0321500120

10.4.3.2

HIGH



This command indicates that four Distributed WLAs are configured on the WLC, with serial IDs 11223344, 332211, 0322100185, and 0321500120. Each WLA is also configured on one of two other WLC switches, with system IP addresses 10.3.8.111 and 10.4.3.2. The bias for the WLA on each WLC is listed. Normally, a Distributed WLA boots from the WLC with the high bias for the WLA

Informational Note: For more information, see and “Boot Process for Distributed WLAs” on page 1–75

Add the cross reference. The AP field indicates the connection number of each WLA on the WLC on which the command is typed. A hyphen ( - ) in the AP field indicates that the WLA is configured on another WLC in the same Mobility Domain.

Displaying a List of Unconfigured Distributed WLAs To display a list of unconfigured Distributed WLAs, use the following command: show ap unconfigured The following command displays information for two unconfigured WLAs: WLC# show ap unconfigured Total number of entries: 1 Serial Id: 0333001287 Model: MP422 IP Address: 10.2.2.1.1 Port: 5 Vlan: DAP Reason: No configuration

Displaying Active Connection Information for Distributed WLAs A Distributed WLA can have only one active data connection. To display the system IP address of the WLC with the active connection (the WLC that booted the WLA), use the following command: show ap connection [apnum | serial-id serial-ID] The serial-id parameter displays the active connection for a Distributed WLA even if that WLA is not configured on the WLC. However, if you use the command with the apnum parameter or without a parameter, connection information is displayed only for Distributed WLAs configured on the WLC. This command provides information only if the Distributed WLA is configured on the WLC that the command is entered. The WLC does not need to be the one that booted the WLA, but it must have the WLA in the configuration. Also, the WLC that booted the WLA must be in the same Mobility Domain as the WLC that you entered the command.



109

110



Configuring WLAN Services

Configuring WLAN Services In addition to configuring WLAs on the WLC, you must add WLAN services to the WLAs.

Configuring a Service Profile A service is a set of options configured and deployed on the wireless network. Services are configured to provide various types of wireless services to users such as secure access, VoIP, guest access, and open access. Multiple services can be supported by MSS to create a Service Profile. VLANs are assigned to service profiles on the wireless network. Service profiles control advertisement (beaconing) and encryption for a SSID, as well as default authorization attributes that apply to users accessing the SSID. Other attributes include authentication type, authentication location, user group, and encryption type. A service profile is a set of parameters that control advertisement (beaconing) and encryption for an SSID, as well as default authorization attributes that apply to users accessing the SSID.

Service Profiles A service profile controls advertisement and encryption for an SSID. You can specify the following: SSIDs that use the service profile are beaconed. If the SSIDs are sent encrypted or in the clear (unencrypted). For encrypted SSIDs, the encryption settings to use for the SSID. The fallthru authentication type for users without 802.1X or MAC authentication. Informational Note: Configuring an SSID name with one character may prevent the SSID from appearing as an available network with the Windows Wireless Client. It is considered a best practice to use more than one character for an SSID name.

Table 16 lists the parameters controlled by a service profile and the default values. Table 16.

Defaults for Service Profile Parameters

Parameter

Default Value

Radio Behavior When Parameter Set To Default Value

11n

None

Supports aggregation of 802.11n frames.

active-call-idle-timeout

None

Configure the time that a VoIP call is idle before it times out on the network.

attr

No attributes configured

Does not assign the SSID authorization attribute values to SSID users, even if attributes are not otherwise assigned.

auth-dot1x

enable

When the Wi-Fi Protected Access (WPA) information element (IE) is enabled, uses 802.1X to authenticate WPA clients.

auth-fallthru

none

Denies access to users who do not match an 802.1X or MAC authentication rule for the SSID requested by the user.

auth-psk

disable

Does not support using a preshared key (PSK) to authenticate WPA clients.

(Moved to rsn-ie and wpa-ie

Moved to rsn-ie and wpa


Configuring a Service Profile

111

Table 16.

Defaults for Service Profile Parameters (continued)

Parameter

Default Value


backup-ssid

disable

Configure attributes for a backup SSID on the network.

beacon

enable

Sends beacons to advertise the SSID managed by the service profile.

bridging

disable

Enables wireless bridging of traffic between WLAs.

cac-mode

none

Does not limit the number of active user sessions based on Call Admission Control (CAC).

cac-session

14

If session-based CAC is enabled (cac-mode is set to session), limits the number of active user sessions on a radio to 14.

cac-voip-call

none

Sets the maximum number of VoIP calls allowed on a service profile. The number of calls can be a value between 0 and 500.

cipher-ccmp

disable

Does not use Counter with Cipher Block Chaining Message Authentication Code Protocol (CCMP) to encrypt traffic sent to WPA clients.

disable

When the WPA IE is enabled, uses Temporal Key Integrity Protocol (TKIP) to encrypt traffic sent to WPA clients.

disable

Does not use Wired Equivalent Privacy (WEP) with 104-bit keys to encrypt traffic sent to WPA clients.

disable

Does not use WEP with 40-bit keys to encrypt traffic sent to WPA clients.

device-detect

enable

Enables device fingerprinting for any user connected to the service profile.

device-detect-acl

disable

Configures an ACL for device fingerprinting authorization

device-detect-timeout

N/A

Configure the length of time for a device to be identified on the network before disconnecting.

dhcp-restrict

disable

Does not restrict a client traffic to only DHCP traffic while the client is being authenticated and authorized.

dot1x-handshake-timeout

disable

Number of milliseconds before handshake message is retransmitted.

idle-client-probing

enable

Sends a keepalive packet (a null-data frame) to each client every 10 seconds.

keep-initial-vlan

disable

Reassigns the user to a VLAN after roaming, instead of leaving the roamed user on the VLAN assigned by the WLC where the user logged on.

(Moved to rsn-ie and wpa-ie) cipher-tkip (Moved to rsn-ie and wpa-ie) cipher-wep104 Moved to rsn-ie and wpa-ie cipher-wep40 Moved to rsn-ie and wpa-ie

Note: Enabling this option does not retain the user initial VLAN assignment in all cases. load-balancing-exempt

disable

Exempts traffic from load balancing between radios.

long-retry-count

5

Sends a long unicast frame up to five times without acknowledgment.

max-bw

0

Supports bandwidth control per service profile. Default is unlimited bandwidth per service profile.

mesh

Not configured

Disables mesh mode by default.

multicast-conversion

disable

Enable or disable multicast conversion of unicast traffic.

no-broadcast

disable

Does not reduce wireless broadcast traffic by sending unicasts to clients for ARP requests and DHCP Offers and Acks instead of forwarding them as multicasts.

112




Table 16.


Parameter

Default Value


proxy-arp

disable

Does not reply on behalf of wireless clients to ARP requests for client IP addresses. Instead, the radio forwards the ARP Requests as wireless broadcasts.

psk-encryption

none

Set an encrypted preshared key for the service profile.

psk-phrase

No passphrase defined

Uses dynamically generated keys rather than statically configured keys to authenticate WPA clients.

psk-raw

No preshared key defined

Uses dynamically generated keys rather than statically configured keys to authenticate WPA clients.

rsn-ie

disable

Set RSN IE parameters including cipher-ccmp and cipher-tkip.

shared-key-auth

disable

Does not use shared-key authentication. This parameter does not enable PSK authentication for WPA. To enable PSK encryption for WPA, use the set service-profile auth-psk command.

short-retry-count

5

Sends a short unicast frame up to five times without acknowledgment.

ssid-name

juniper

Uses the SSID name juniper.

ssid-type

crypto

Encrypts wireless traffic for the SSID.

tkip-mc-time

60000

Uses Michael countermeasures for 60,000 ms (60 seconds) following detection of a second MIC failure within 60 seconds.

transmit-rates

802.11a: mandatory: 6.0,12.0,24.0 beacon-rate: 6.0 multicast-rate: auto disabled: none 802.11b: mandatory: 1.0,2.0 beacon-rate: 2.0 multicast-rate: auto disabled: none 802.11g:

Accepts associations only from clients that support one of the mandatory rates. Sends beacons at the specified rate (6 Mbps for 802.11a, 2 Mbps for 802.11b/g). Sends multicast data at the highest rate that can reach all clients connected to the radio. Accepts frames from clients at all valid data rates. (No rates are disabled by default.)

mandatory: 1.0,2.0,5.5,11.0 beacon-rate: 2.0 multicast-rate: auto disabled: none user-idle-timeout

180


Allows a client to remain idle for 180 seconds (3 minutes) before MSS changes the client session to the Disassociated state.


113

Table 16.


Parameter

Default Value


web-portal-acl

portalacl

If set to portalacl and the service profile fallthru is set to web-portal, radios use the portalacl ACL to filter traffic for Web Portal users during authentication.

Note: This is the If the fallthru type is web-portal but web-portal-acl is set to an ACL other than default only if the portalacl, the other ACL is used. fallthru type on If the fallthru type is not web-portal, radios do not use the web-portal-acl setting. the service profile has been set to web-portal. Otherwise, the value is unconfigured. web-portal-form

Not configured

For Web Portal WebAAA users, serves the default login web page or, if configured, the SSID-specific login web page.

web-portal-logout

Not configured

Configure Web logout parameters.

web-portal-session-timeout 5

Allows a Web Portal WebAAA session to remain in the Deassociated state 5 seconds before being terminated automatically.

wep

Uses dynamic WEP rather than static WEP.

No keys defined

Note: If you configure a WEP key for static WEP, MSS continues to also support dynamic WEP. wep active-multicast-index (Deprecated in 7.1)

1

Uses WEP key 1 for static WEP encryption of multicast traffic if WEP encryption is enabled and keys are defined.

wep active-unicast-index

1

Uses WEP key 1 for static WEP encryption of unicast traffic if WEP encryption is enabled and keys are defined.

wpa-ie

disable

Sets WPA IE parameters including cipher-ccmp and cipher-tkip.

Informational Note: To configure a service profile, see “Service Profiles” on page 111.

Public and Private SSIDs Each radio can support the following types of SSIDs: Encrypted SSID—Clients using this SSID must use encryption. Use an encrypted SSID for secured access to your enterprise network. Clear SSID—Clients using this SSID do not use encryption. Use the clear SSID for public access to nonsecure portions of your network. WLA models can support up to 32 SSIDs per radio. Each SSID can be encrypted or clear, and beaconing can be enabled or disabled on an individual SSID basis.

114




Each radio has 32 MAC addresses and can therefore support up to 32 SSIDs, with one MAC address assigned to each SSID as the BSS. An WLA MAC address block is listed on a label on the back of the WLA. If the WLA is already deployed and running on the network, you can display the MAC address assignments by using the show ap status command. Informational Note: For more information on MAC addresses and per WLA allocations, see the Indoor Wireless LAN Access Point Hardware Installation Guide.

Encryption Encrypted SSIDs can use the following encryption methods: Wi-Fi Protected Access (WPA) Non-WPA dynamic Wired Equivalent Privacy (WEP) Non-WPA static WEP Dynamic WEP is enabled by default.

Mixed Cipher Support You can configure more than one cipher per IE rather than just one per SSID. To configure mixed ciphers, use the following commands: WLC# set service-profile profile-name wpa-ie cipher-tkip enable WLC# set service-profile profile-name rsn-ie [cipher-ccmp | cipher-tkip] enable To configure auth types (auth-dot1x is the default): WLC# set service-profile profile-name psk-phrase psk-phrase WLC# set service-profile profile-name [rsn-ie | wpa-ie] auth-psk enable Informational Note: Upgrade and downgrade functionality: When you upgrade from an earlier version of MSS, configured ciphers and authorization types are applied to both the RSN and WPA IEs for existing service profiles. When creating a new service profile in MSS 7.1, ciphers must be configured explicitly, since TKIP is not enabled by default. Auth-dot1x continues to be the default authorization type for WPA and RSN IEs.

Informational Note: You can no longer configure WPA and WEP on the same service profile. This command was deprecated to comply with WiFi certification.

.

Informational Note: To display service profile settings, see “Service Profiles” on page 111.



115

116




Configuring a Service Profile Creating a Service Profile To create a service profile and assign an SSID to the profile, use the following command: set service-profile profile-name ssid-name ssid-name An SSID can be up to 32 alphanumeric characters long. You can include blank spaces within the name, if you delimit the name with single or double quotation marks. However, the name should not begin with or end with blank spaces. You must use the same type of quotation mark (either single or double) on both ends of the string. The following command configures a service profile named corp1, and assigns SSID mycorp_rnd to it: WLC# set service-profile corp1 ssid-name mycorp_rnd success: change accepted. The following command applies the name corporate users to the SSID managed by service profile mycorp_srvcprf: WLC# set service-profile mycorp_srvcprf ssid-name “corporate users” success: change accepted.

Removing a Service Profile To remove a service profile, use the following command: clear service-profile profile-name Using this command completely removes a service profile.

Changing a Service Profile Setting To change a setting in a service profile without removing the profile, use the set service-profile command for the setting you want to change. Do not use the clear service-profile command.

Disabling or Reenabling Encryption for an SSID To specify whether the SSID is encrypted or unencrypted, use the following command: set service-profile profile-name ssid-type [clear | crypto] The default is crypto.

Disabling or Reenabling Beaconing of an SSID To specify whether the SSID is beaconed, use the following command: set service-profile beacon {enable | disable} SSIDs are beaconed by default.


117

An WLA radio responds to an 802.11 probe any request only for a beaconed SSID. A client that sends a probe any request receives a separate response for each of the beaconed SSIDs supported by a radio. For a nonbeaconed SSID, radios respond only to directed 802.11 probe requests that match the nonbeaconed SSID string. When you disable beaconing for an SSID, the radio still sends beacon frames, but the SSID name in the frames is blank.

Changing the Fallthru Authentication Type By default, MSS denies access to users who do not match an 802.1X or MAC authentication rule, and therefore fall through these authentication types. You can change the fallthru method to last-resort or web-portal. To change the fallthru method, use the following command: set service-profile auth-fallthru {last-resort | none | web-portal}

Changing Transmit Rates Each type of radio (802.11a, 802.11b, 802.11g, and 802.11n) providing service to an SSID has a set of rates the radio is allowed to use for sending beacons, multicast frames, and unicast data. The rate set also specifies the rates clients must support in order to associate with a radio. Table 17 lists the rate settings and the default values. Table 17. Parameter mandatory

Transmit Rates Default Value 11a— 6.0,12.0,24.0 11b—1.0,2.0 11g—1.0,2.0,5.5,11.0 11na—6.0, 9.0,12.0, 18.0, 24.0, 36.0, 48.0, 54.0, MCS0-15 11ng—1.0, 2.0, 5.5, 6.0, 9.0, 11.0, 12.0, 18.0, 24.0, 36.0, 48.0, 54.0, MCS0-15

Description Set of data transmission rates that clients are required to support in order to associate with an SSID on an WLA radio. A client must support at least one of the mandatory rates. These rates are advertised in the basic rate set of 802.11 beacons, probe responses, and reassociation response frames sent by WLA radios. Data frames and management frames sent by WLA radios use one of the specified mandatory rates. The valid rates depend on the radio type:

11a—6.0, 9.0, 12.0, 18.0, 24.0, 36.0, 48.0, 54.0 11b—1.0, 2.0, 5.5, 11.0 11g—1.0, 2.0, 5.5, 6.0, 9.0, 11.0, 12.0, 18.0, 24.0, 36.0, 48.0, 54.0 Use a comma to separate multiple rates; for example: 6.0,9.0,12.0 disabled

None. All rates applicable to the Data transmission rates that WLA radios do not use to transmit data. This radio type are supported by setting applies only to data sent by the WLA radios. The radios still accept default. frames from clients at disabled data rates. The valid rates depend on the radio type and are the same as the valid rates for mandatory. If you disable a rate, you cannot use the rate as a mandatory rate or the beacon or multicast rate. All rates that are applicable to the radio type and that are not disabled are supported by the radio.

118



Table 17.

Transmit Rates (continued)

Parameter

Default Value

beacon-rate

11a—6.0 11b—2.0 11g—2.0

multicast-rate

auto for all radio types

Description Data rate of beacon frames sent by WLA radios. This rate is also used for probe-response frames. The valid rates depend on the radio type and are the same as the valid rates for mandatory. However, you cannot set the beacon rate to a disabled rate. Data rate of multicast frames sent by WLA radios. rate—Sets the multicast rate to a specific rate. The valid rates depend on the radio type and are the same as the valid rates for mandatory. However, you cannot set the multicast rate to a disabled rate. auto—Sets the multicast rate to the highest rate that can reach all clients connected to the WLA radio.

To change transmit rates for a service profile, use the following command: set service-profile profile-name transmit-rates {11a | 11b | 11g} mandatory rate-list [disabled rate-list] [beacon-rate rate] [multicast-rate {rate | auto}] The following command sets 802.11a mandatory rates for service profile sp1 to 6 Mbps and 9 Mbps, disables rates 48 Mbps and 54 Mbps, and changes the beacon rate to 9 Mbps: WLC# set service-profile sp1 transmit-rates 11a mandatory 6.0,9.0 disabled 48.0,54.0 beacon-rate 9.0 success: change accepted.

Enforcing the Data Rates By default, the rate set is not enforced, meaning that a client can associate with and transmit data to the WLA using a disabled data rate, although the WLA does not transmit data back to the client at the disabled rate. You can configure MSS to enforce the data rates, which means that a connecting client must transmit at one of the mandatory or standard rates in order to associate with the WLA. When data rate enforcement is enabled, clients transmitting at the disabled rates are not allowed to associate with the WLA. Data rate enforcement is useful if you want to completely prevent clients from transmitting at disabled data rates. For example, you can disable slower data rates so that clients transmitting at these rates do not consume bandwidth on the channel at the expense of clients transmitting at faster rates. Data rate enforcement is disabled by default. To enable data rate enforcement for a radio profile, use the following command: set radio-profile profile-name rate-enforcement mode {enable | disable} For example, the following command enables data rate enforcement for radio profile rp1 WLC# set radio-profile rp1 rate-enforcement mode enable The following command sets a 802.11g mandatory rate for service profile sp1 to 54 Mbps and disables rates 1.0 Mbps and 2.0 Mbps: WLC# set service-profile sp1 transmit-rates 11g mandatory 54.0 disabled 1.0,2.0


119

The following command maps radio profile rp1 to service profile sp1. WLC# set radio-profile rp1 service-profile sp1 After these commands are entered, if a client transmitting with a data rate of 1.0 Mbps or 2.0 Mbps attempts to associate with an WLA managed by service profile sp1, that client is not allowed to associate with the WLA.

Disabling Idle-Client Probing By default, an WLA radio sends keepalive messages (idle-client probes) every 10 seconds to each client with an active session on the radio, to verify that the client is still active. The probes are unicast null-data frames. Normally, an active client sends an Ack in reply to an idle-client probe. If a client does not send any data or respond to any idle-client probes before the user idle timeout expires (see “Changing the User Idle Timeout” on page 1–120), MSS changes the client session to the Disassociated state. Responding to keepalive messages requires power use by a client. If you need to conserve power on the client (for example, on a VoIP handset), you can disable idle-client probing. To disable or reenable idle-client probing, use the following command: set service-profile profile-name idle-client-probing {enable | disable} The following command disables idle-client probing on service profile sp1: WLC# set service-profile sp1 idle-client-probing disable success: change accepted.

Changing the User Idle Timeout The user idle timeout specifies the number of seconds a client can remain idle before the WLC changes the client session to the Disassociated state. A client is considered to be idle if it does not send data and does not respond to idle-client probes. You can specify a timeout value from 20 to 86400 seconds. The default is 180 seconds (3 minutes). To disable the user-idle timeout, set the value to 0. To change the user-idle timeout, use the following command: set service-profile profile-name user-idle-timeout seconds The following command increases the user idle timeout to 360 seconds (6 minutes): WLC# set service-profile sp1 user-idle-timeout 360 success: change accepted.

Changing the Short Retry Threshold The short retry threshold specifies the number of times a radio can send a short unicast frame for an SSID without receiving an acknowledgment for the frame. A short unicast frame is a frame that is shorter than the RTS threshold. To change the short retry threshold, use the following command: set service-profile profile-name short-retry threshold The threshold can be a value from 1 through 15. The default is 5. To change the short retry threshold for service profile sp1 to 3, type the following command:

120



WLC# set service-profile sp1 short-retry 3 success: change accepted.

Changing the Long Retry Threshold The long retry threshold specifies the number of times a radio can send a long unicast frame for an SSID without receiving an acknowledgment for the frame. A long unicast frame is a frame that is equal to or longer than the RTS threshold. To change the long retry threshold, use the following command: set service-profile profile-name long-retry threshold The threshold can be a value from 1 through 15. The default is 5. To change the long retry threshold for service profile sp1 to 8, type the following command: WLC# set service-profile sp1 long-retry 8 success: change accepted.

Transmit Beam-forming Transmit beam-forming (TxBF) is a technique that uses an array of transmitting antennas to send radio signals with adjusted magnitude and phase at each antenna to achieve a focused beam target to the receiver. TxBF can increase the Signal-to-Noise Ratio (SNR) at the receiver and improve performance. This feature is supported on the WLA532, WLA321, and WLA322. Informational Note:

In this implementation of TxBF, it is required that the wireless clients support IEEE 802.11n-based TxBF. Not all clients can support 802.11n-based TxBF.

TxBF is configured on a per service profile basis. For example, WLC# set service-profile profile 11n txbf {immediate | delay | disable} TxBF is set to disable by default. When TxBF is set to immediate mode, TxBF is enabled. When a WLA receives a sounding frame from a wireless client, the WLA responds with channel feedback obtained by measuring a sounding frame within an ActionNoAck management frame to the client immediately after a SIFS interval. When TxBF is set to delay mode, the WLA responds with channel feedback obtained by measuring a sounding frame within an ActionNoAck management frameand sends it to the client in the next transmission opportunity. On a radio profile, when an associated service profile is configured for TxBF immediate mode, other service profiles with TxBF radio profiles must set TxBF mode to disable. This is enforced by the CLI and error messages are returned for invalid service profile configurations. However, if TxBF is configured in delay mode, there is no limitation to the number of service profiles enabled in this mode.


Transmit Beam-forming

121

In a mesh configuration, a TxBF WLA always uses immediate mode to establish a link to a TxBF mesh portal. If TxBF is established on the mesh link, the radio used by the mesh WLA cannot be configured with additional service profiles with TxBF. To display information about TxBF on a service profile, you can use the show service-profile profile-name command. Syntax show service-profile profile Defaults None Access Enable History Transmit beam-forming information added in MSS Version 8.0. Usage Display TxBF information for a service profile. Examples

show service-profile profile General Attributes: SSID Name:

corp

SSID type:

clear

......... 11n attributes 11na Mode (na):

enabled

11n Mode (ng):

enabled

Guard Interval:

short

Frame Aggregation mode:

all

MSDU Max length:

4K

MPDU Max length:

64K

TxBF:

immediate

To display TxBF information for a session, you can use the show session network command. Syntax show session network session-id number number

ID numbers are associated with individual sessions

Defaults None Access Enable History New in MSS Version 8.0 Usage Display TxBF information for a network session.

122




Examples

show session network session-id 52 1 of 25 sessions matched Name:

last-resort-platform-aes-101

Session ID:

52

Global ID:

SESS-52-91c81a-108216-94443c

Login type:

open

SSID:

corp

IP:

192.168.100.50

MAC:

00:41:c0:a8:01:23

... ... 11n Capabilities: Max Rx A-MSDU size:

8K

Max Rx A-MPDU size:

64K

SM power save:

none

TxBeamformer:

All

TxBeamformee:

NonComp-All, Comp-All

Table 18.Output for a show sessions network with TxBF information Field

Possible Values

Description

TxBeamformer

None

Device does not support steering from explicit feedback

NonComp

Device supports steering from noncompressed beamforming explicit feedback.

Comp

Device supports steering from compressed beamforming explicit feedback.

All

Device supports steering from both noncompressed and compressed beamforming explicit feedback

NonComp-None

Device does not support noncompressed explicit feedback

NonComp-Delay

Device supports noncompressed delay feedback

NonComp-Immediate

Device supports noncompressed immediate feedback

NonComp- All

Device supports noncompressed delay and immediate feedback.

TxBeamformee



123

Table 18.Output for a show sessions network with TxBF information Field

124


Possible Values

Description

Comp-None

Device does not support compressed explicit feedback.

Comp-Delay

Device supports compressed delay feedback.

Comp-Immediate

Device supports compressed immediate feedback.

Comp-All

Device supports compressed delay and immediate feedback.


Displaying Service Profile Information

Displaying Service Profile Information To display service profile information, use the following command: show service-profile {profile-name | ?} Entering show service-profile ? displays a list of the service profiles configured on the WLC. To display information for service profile sp1, type the following command: WLC# show service-profile sp1 ssid-name:

corp

Beacon:

ssid-type: clear

yes

Short retry limit: Auth fallthru:

5 last-resort

Enforce SODA checks:

yes

Proxy ARP: no Long retry limit: 5 Sygate On-Demand (SODA): no SODA remediation ACL:

Custom success web-page:

Custom failure web-page:

Custom logout web-page:

Custom agent-directory:

Static COS:

no

COS: 0

Client DSCP:

no

CAC mode: none

CAC sessions:

14

User idle timeout: 180

yes

Keep initial vlan: no

Idle client probing: Web Portal Session Timeout:

5

Web Portal ACL: Load Balance Exempt:

Mesh enabled: no Bridging enabled: no

no

Web Portal Logout: no

6.0

multicast rate: AUTO

Custom Web Portal Logout URL: vlan-name = default 11a beacon rate:

11a mandatory rate: 6.0,12.0,24.0 standard rates: 9.0,18.0,36.0,48.0,54.0 11b beacon rate:

2.0


11b mandatory rate: 1.0,2.0 standard rates: 5.5,11.0 11g beacon rate:

2.0


11g mandatory rate: 1.0,2.0,5.5,11.0 standard rates: 6.0,9.0,12.0,18.0,24.0,36.0,48.0,54.0 Informational Note: For information about the fields in the output, see the Juniper Mobility System Software Command Reference.


125

126


Configuring a Radio Profile

Configuring a Radio Profile Overview A radio profile is a set of parameters that apply to multiple radios. You can easily assign configuration parameters to many radios by configuring a profile and assigning the profile to the radios. These radio profiles also map to service profiles. Radio profiles are used to control beacon intervals (how often a radio advertises a SSID on the network), and other parameters that you want to apply across all radios on the network. If you want to control individual radios on WLAs, you have to configure the parameters on each radio separately. For instance, you might want to configure antennas attached to a WLA, so you would configure the WLA radio with antenna specific information. To configure a radio profile: Create a new profile. Change radio parameters. Map the radio profile to one or more service profiles. The channel number, transmit power, and external antenna type are unique to each radio and are not controlled by radio profiles. Informational Note: To display radio profile information, see “Displaying Radio Profile Information” on

page 144. Informational Note: To configure these parameters, see “Configuring Radio-Specific Parameters” on

page 133.

Radio Profiles You can easily assign radio configuration parameters to many radios by configuring a radio profile and assigning the profile to the radios. You can enable the radio when you assign the profile. Table 19 summarizes the parameters controlled by radio profiles. Generally, the only radio parameters controlled by the profile to modify are the SSIDs and, if applicable, Wi-Fi Protected Access (WPA) settings. The other parameter settings are standard. Informational Note: To configure aradio profile on auto W:As, see “Configuring an Auto-AP Profile for Automatic WLA Configuration” on page 89 Table 19.

Default Values for Radio Profile Parameters

Parameter

Default Value


11n

None

Configures 11n parameters for the profile including channel width.

auto-tune

None

Enable auto-tune parameters including channel and power options.

active-scan

enable

Sends probe any requests (probe requests with a null SSID name) to solicit probe responses from other access points.

beacon-interval

100

Waits 100 ms between beacons.


Overview

127

Table 19.

Default Values for Radio Profile Parameters (continued)

Parameter

Default Value


cac

None

Configures call admission control parameters including background, best-effort, video, or voice.

client-tx-constraint

None

Configure transmit power from a wireless client.

countermeasures

Not configured

Does not issue countermeasures against any device.

dfs-channels

None

Enable or disable DFS compliant channels for the radio.

dtim-interval

1

Sends the delivery traffic indication map (DTIM) after every beacon.

frag-threshold

2346

Uses the short-retry-count for frames shorter than 2346 bytes and uses the long-retry-count for frames that are 2346 bytes or longer.

max-rx-lifetime

2000

Allows a received frame to stay in the buffer for up to 2000 ms (2 seconds).

max-tx-lifetime

2000

Allows a frame that is scheduled for transmission to stay in the buffer for up to 2000 ms (2 seconds).

preamble-length

short

Advertises support for short 802.11b preambles, accepts either short or long 802.11b preambles, and generates unicast frames with the preamble length specified by the client.

Note: This parameter applies only to 802.11b/g radios. qos-mode

wmm

Classifies and marks traffic based on 802.1p and DSCP, and optimizes forwarding prioritization of WLA radios for Wi-Fi Multimedia (WMM).

rate-enforcement

None

Enable or disable data rate enforcement mode for the radio profile.

rf-scanning

None

Set to actively probe or passively listen on the network.

rfid-mode

disable

Radio does not function as a location receiver in an AeroScout Visibility System.

rts-threshold

65535

Transmits frames longer than 65535 bytes by means of the Request-to-Send/Clear-to-Send (RTS/CTS) method.

service-profile

No service profiles defined

You must configure a service profile. The service profile sets the SSID name and other parameters.

wmm-powersave

disable

Requires clients to send a separate PSpoll to retrieve each unicast packet buffered by the WLA radio.

RF Auto-Tuning The RF Auto-Tuning feature dynamically assigns channel and power settings to WLA radios, and adjusts those settings when needed. RF Auto-Tuning can perform the following tasks: Assign initial channel and power settings when an WLA radio is started. Periodically assess the RF environment and change the channel or power setting if needed. Change the transmit data rate or power to maintain at least the minimum data rate with all associated clients. By default, RF Auto-Tuning is enabled for channel configuration but disabled for power configuration.

Default Radio Profile MSS contains one default radio profile, called default. To apply common parameters to radios, you can modify the default profile or create a new one. When you create a new profile, the radio parameters in the profile are set to the factory default values.

128

Overview



Radio-Specific Parameters The channel number, transmit power, and external antenna parameters are unique to each radio and are not controlled by radio profiles. Table 20 lists the defaults for these parameters. Table 20.

Radio-Specific Parameters

Parameter

Default Value

Description

antennalocation

indoors

Radio antenna location

Note: This parameter applies only to WLAs that support external antennas. antennatype

For most WLA models, the default is internal. Juniper external antenna model For MP620, the default for the 802.11b/g radio is ANT-1360-OUT. The default for the 802.11a radio is ANT-5360-OUT.

Note: This parameter is configurable only on WLAs that support external antennas.

The default for the 802.11b/g radio on model MP262 is ANT1060. auto-tune max-power

channel

Highest setting allowed for the country of operation or highest setting supported on the hardware, whichever is lower.

Maximum percentage of client retransmissions a radio can experience before RF Auto-Tuning considers changing the channel on the radio

802.11b/g—6 Channel number that a radio transmits and receives traffic. 802.11a—Lowest valid channel number for the country of operation

mode

disable

Operational state of the radio.

radio-profile

None. You must add the radios to a radio profile.

802.11 settings

tx-power

Highest setting allowed for the country of operation or highest setting supported on the hardware, whichever is lower.

Transmit power of a radio, in decibels referred to 1 milliwatt (dBm)

Although these parameters have default values, Juniper Networks recommends that you change the values for each radio for optimal performance. For example, leaving the channel number on each radio set to the default value can result in high interference among the radios.

Creating a New Profile To create a radio profile, use the following command: set radio-profile profile-name [mode {enable | disable}] Specify a name of up to 32 alphanumeric characters. Do not include the mode enable or mode disable option. After you create the radio profile, you can use the enable and disable options to enable or disable all radios that use the profile. To configure a new radio profile named rp1, type the following command: WLC# set radio-profile rp1 success: change accepted.


Overview

129

To assign the profile to one or more radios, use the set ap radio radio-profile command.

Informational Note: See “Assigning a Radio Profile and Enabling Radios” on page 135.

Changing Radio Parameters To change individual parameters controlled by a radio profile, use the commands described in the following sections. Informational Note: You must disable all radios that are using a radio profile before you can change parameters in the profile. (See “Disabling or Enabling All Radios Using a Profile” on page 136.)

Changing the Beacon Interval The beacon interval is the rate at which a radio advertises beaconed SSID(s). To change the beacon interval, use the following command: set radio-profile profile-name beacon-interval interval The interval can be a value from 25 ms through 8191 ms. The default is 100. The beacon interval does not change even when advertisement is enabled for multiple SSIDs. MSS still sends one beacon for each SSID during each beacon interval. To change the beacon interval for radio profile rp1 to 200 ms, type the following command: WLC# set radio-profile rp1 beacon-interval 200 success: change accepted.

Changing the DTIM Interval The DTIM interval specifies the number of times after every beacon that a radio sends a delivery traffic indication map (DTIM). An WLA access point sends the multicast and broadcast frames stored in its buffers to clients who request them in response to the DTIM. The DTIM interval applies to both the beaconed SSID and the unbeaconed SSID. The DTIM interval does not apply to unicast frames. An WLA also stores unicast frames in buffer memory, but the WLA includes information about the buffered unicast frames in each beacon frame. When a user station receives a beacon frame that advertises unicast frames destined for the station, the station sends a request for the frames and the WLA transmits the requested frames to the user station. To change the DTIM interval, use the following command: set radio-profile profile-name dtim-interval interval The interval can be a value from 1 through 31. The default is 1. To change the DTIM interval for radio profile rp1 to 2, type the following command: WLC# set radio-profile rp1 dtim-interval 2 success: change accepted.

130

Overview



Changing the RTS Threshold The RTS threshold specifies the maximum length a frame can be before a radio uses the Request-to-Send/Clear-to-Send (RTS/CTS) method to send the frame. The RTS/CTS method clears the air of other traffic to avoid corruption of the frame due to a collision with another frame. When a frame is long enough for the RTS/CTS method to be applicable, the radio sends a Request-To-Send (RTS) message addressed to the intended receiver for the frame. The receiver replies with a Clear-To-Send (CTS) message. When the radio receives the CTS message, the radio transmits the frame and waits for an acknowledgment from the receiver. The radio does not transmit additional frames until acknowledgment is received. Any other user station that overhears the RTS or CTS message stops transmitting until the station overhears the acknowledgment message. To change the RTS threshold, use the following command: set radio-profile profile-name rts-threshold threshold The threshold can be a value from 256 bytes through 3000 bytes. The default is 2346. To change the RTS threshold for radio profile rp1 to 1500 bytes, type the following command: WLC# set radio-profile rp1 rts-threshold 1500 success: change accepted.

Changing the Fragmentation Threshold The fragmentation threshold specifies the longest length of a frame without fragmenting into multiple frames by a radio before transmission. To change the fragmentation threshold, use the following command: set radio-profile profile-name frag-threshold threshold The threshold can be a value from 256 through 2346. The default is 2346. To change the fragmentation threshold for radio profile rp1 to 1500 bytes, type the following command: WLC# set radio-profile rp1 frag-threshold 1500 success: change accepted.

Changing the Maximum Receive Threshold The maximum receive threshold specifies the number of milliseconds a frame received by a radio can remain in buffer memory. To change the maximum receive lifetime, use the following command: set radio-profile profile-name max-rx-lifetime time The time can be from 500 ms (0.5 second) through 250,000 ms (250 seconds). The default is 2000 ms (2 seconds). To change the maximum receive threshold for radio profile rp1 to 4000 ms, type the following command: WLC# set radio-profile rp1 max-rx-lifetime 4000 success: change accepted.


Overview

131

Changing the Maximum Transmit Threshold The maximum transmission threshold specifies the number of milliseconds a frame scheduled to be transmitted by a radio can remain in buffer memory. To change the maximum transmit lifetime, use the following command: set radio-profile profile-name max-tx-lifetime time The time can be from 500 ms (0.5 second) through 250,000 ms (250 seconds). The default is 2000 ms (2 seconds). To change the maximum transmit threshold for radio profile rp1 to 4000 ms, type the following command: WLC# set radio-profile rp1 max-tx-lifetime 4000 success: change accepted.

Changing the Preamble Length By default, 802.11b/g radios advertise support for frames with short preambles and can support frames with short or long preambles. An 802.11b/g radio generates unicast frames to send to a client with the specified preamble length. An 802.11b/g radio always uses a long preamble in beacons, probe responses, and other broadcast or multicast traffic. Generally, clients assume access points require long preambles and request to use short preambles only if the associated access point advertises support for short preambles. You can disable the advertisement of support for short preambles by setting the preamble length value to long. In this case, clients assume that the access point supports long preambles only and the clients request long preambles. Changing the preamble length value affects only the support advertised by the radio. Regardless of the preamble length setting (short or long), an 802.11b/g radio accepts and can generate 802.11b/g frames with either short or long preambles. If any client associated with an 802.11b/g radio uses long preambles for unicast traffic, the WLA still accepts frames with short preambles but does not transmit any frames with short preambles. This change also occurs if the WLA overhears a beacon from an 802.11b/g radio on another access point that indicates the radio has clients that require long preambles. The default preamble length value is short. This command does not apply to 802.11a radios. To change the preamble length advertised by 802.11b/g radios, use the following command: set radio-profile profile-name preamble-length {long | short} To configure 802.11b/g radios that use the radio profile rp_long to advertise support for long preambles instead of short preambles, type the following command: WLC# set radio-profile rp_long preamble-length long success: change accepted.

Resetting a Radio Profile Parameter to the Default Value To reset a radio profile parameter to default values, use the following command: clear radio-profile profile-name parameter

132

Overview



The parameter can be one of the radio profile parameters listed in “Changing Radio Parameters” on page 130. Warning: Make sure you specify the radio profile parameter you want to reset. If you do not specify a parameter, MSS deletes the entire profile from the configuration.

All radios that use this profile must be disabled before you can delete the profile. If you specify a parameter, the setting for the parameter is reset to the default value. The settings of the other parameters are unchanged and the radio profile remains in the configuration. If you do not specify a parameter, the entire radio profile is deleted from the configuration. To disable the radios that are using radio profile rp1 and reset the beaconed-ssid parameter to its default value, type the following commands: WLC# set radio-profile rp1 mode disable WLC# clear radio-profile rp1 beaconed-ssid success: change accepted.

Removing a Radio Profile To remove a radio profile, use the following command: clear radio-profile name Informational Note: You must disable all radios that are using a radio profile before you can remove the profile. (See “Disabling or Enabling All Radios Using a Profile” on page 136.)

To disable the radios that are using radio profile rptest and remove the profile, type the following commands: WLC# set radio-profile rptest mode disable WLC# clear radio-profile rptest success: change accepted.

Configuring Radio-Specific Parameters This section shows how to configure the channel and transmit power on individual radios, and how to configure for external antennas. (For information about the parameters you can set on individual radios, see “Changing Radio Parameters” on page 130.)

Configuring the Channel and Transmit Power Informational Note: If RF Auto-Tuning is enabled for channels or power, you cannot set the channels or power manually using the commands in this section.

To set the channel and transmit power of a radio, use the following commands:


Configuring Radio-Specific Parameters

133

set ap apnum radio {1 | 2} channel channel-number set ap apnum radio {1 | 2} tx-power power-level The parameters are shown in separate commands for simplicity. However, you can use the channel and tx-power parameters on the same command line. Specify 1 or 2 for the radio number: For a single-radio model, specify radio 1. For the 802.11b/g radio in a two-radio model, specify radio 1. For the 802.11a radio in a two-radio model, specify radio 2. Informational Note: The maximum transmit power you can configure on any Juniper Networks radio is the highest setting allowed for the country of operation or the highest setting supported on the hardware.

To configure the 802.11b radio on port 11 for channel 1 with a transmit power of 10 dBm, type the following command: WLC# set ap 11 radio 1 channel 1 tx-power 10 success: change accepted. To configure the 802.11a radio on port 5 for channel 36 with a transmit power of 10 dBm, type the following command: WLC# set ap 5 radio 2 channel 36 tx-power 10 success: change accepted. You also can change the channel and transmit power on an individual basis.

Configuring the External Antenna Model and Location The MP372 and MP422 have connectors for attaching optional external 802.11a or 802.11b/g antennas. The 802.11b/g radios in WLA models MP341 and MP352 have an internal antenna but can use an external antenna. The MP262 802.11b/g radio requires a Juniper external antenna. For specific information on external antennas and WLAs, refer to each WLA installation guide. Informational Note: When using external antennas in conjunction with Mesh configurations, enable Mesh mode before configuring the external antenna. After configuring the antenna, reboot the WLA in order to use the external antenna.

To specify the external antenna model, use the following command: set ap apnum radio {1 | 2} antennatype {ANT1060 | ANT1120 | ANT1180 | ANT5060 | ANT5120 | ANT5180 | ANT7360 ANT-1360-OUT | ANT-5360-OUT | ANT-5060-OUT | ANT-5120-OUT | ANT-7360-OUT | internal} To configure antenna model ANT-1060 for an MP372 on WLA 1, type the following command: WLC# set ap 1 radio 1 antennatype ANT1060 success: change accepted.

134




Specifying the External Antenna Location In some cases, the set of valid channels for a radio differs if the antenna is located indoors or outdoors. You can ensure that the proper set of channels is available on the radio by specifying the antenna location (indoors or outdoors). The default location is indoors. To change an external antenna location, use the following command: set ap apnum antenna-location {indoors | outdoors}

Mapping the Radio Profile to Service Profiles To assign SSIDs to radios, you must map the service profiles for the SSIDs to the radio profile assigned to the radios. To map a radio profile to a service profile, use the following command: set radio-profile profile-name service-profile profile-name The following command maps service-profile wpa_clients to radio profile rp2: WLC# set radio-profile rp2 service-profile wpa_clients success: change accepted.

Assigning a Radio Profile and Enabling Radios To assign a radio profile to radios, use the following command: set ap apnum radio {1 | 2} radio-profile profile-name mode {enable | disable} To assign radio profile rp1 to radio 1 on ports 5-8, 11-14, and 16 and enable the radios, type the following command: WLC# set ap 5-8,11-14,16 radio 1 radio-profile rp1 mode enable success: change accepted. To assign radio profile rp1 to radio 2 on ports 11-14 and port 16 and enable the radios, type the following command: WLC# set ap 11-14,16 radio 2 radio-profile rp1 mode enable success: change accepted. To disable radio 1 on port 6 without disabling the other radios using radio profile rp1, type the following command: WLC# set ap 6 radio 1 radio-profile rp1 mode disable (To disable or reenable all radios that are using a radio profile, see “Disabling or Enabling All Radios Using a Profile” on page 136.)

Disabling or Enabling Radios You can disable or enable radios on a radio profile basis or individual basis. You also can reset a radio to the factory default settings.


Disabling or Enabling Radios

135

(To disable or enable radios when assigning or removing a radio profile, see “Assigning a Radio Profile and Enabling Radios” on page 135.)

Enabling or Disabling Individual Radios To disable or enable an WLA radio, use the following command: set ap apnum radio {1 | 2} mode {enable | disable} To disable radio 2 on port 3 and 7, type the following command: WLC# set ap 3,7 radio 2 mode disable success: change accepted.

Disabling or Enabling All Radios Using a Profile To disable or enable all radios that are using a radio profile, use the following command: set radio-profile profile-name [mode {enable | disable}] The following command enables all radios that use radio profile rp1: WLC# set radio-profile rp1 mode enable success: change accepted. The following commands disable all radios that use radio profile rp1, change the beacon interval, then reenable the radios: WLC# set radio-profile rp1 mode disable success: change accepted. WLC# set radio-profile rp1 beacon-interval 200 success: change accepted. WLC# set radio-profile rp1 mode enable success: change accepted.

Resetting a Radio to Factory Default Settings To disable an WLA radio and reset it to the factory default settings, use the following command: clear ap apnum radio {1 | 2 | all} This command performs the following actions: Sets the transmit power, channel, and external antenna type to the default values. Removes the radio from a radio profile and places the radio in the default radio profile. This command does not affect the PoE setting. To disable and reset radio 2 on the WLA connected to port 3, type the following command: WLC# clear ap 3 radio 2

Restarting an WLA To restart an WLA, use the following command: reset ap apnum

136




Use the reset ap command to reset an WLA configured on an WLA access port. Use the reset ap command to reset a Distributed WLA. When you enter one of these commands, the WLA drops all sessions and reboots.

Warning: Restarting an WLA can cause data loss for users who are currently associated with the WLA.

Configuring Local Packet Switching on WLAs WLAs can be configured to perform local packet switching. Local packet switching allows packets to switch directly from the WLA to the wired network, instead of passing through an intermediate WLC. The term, tunnel, can be confusing as it can have different meanings, depending on the context. Here are a couple of definitions to assist with understanding tunnel as it applies here: Overlay tunnel — A data tunnel that exists between an WLC and WLA. If the client session is not locally switched, then it is an overlay tunnel and the client data traffic is included in this tunnel. Sessions that use this type of tunnel: - Sessions with local switching disabled. - Sessions with local switching enabled but the VLAN for the session is set to overlay mode in the

VLAN profile on the WLA. Mobility Domain tunnel — data tunnel between two WLCs, 2 WLAs, or an WLC and an WLA. It is used when an WLA or WLC with local switching enabled does not have the client VLAN configured on it and the traffic is tunneled from another WLC or WLA. When an WLA is configured to perform local switching, the WLC is removed from the forwarding path for client data traffic. When local switching is enabled, the client VLAN is directly accessible through the wired interface on the WLA. Packets can be switched directly to and from this interface. Normally, when local switching is disabled on an WLA, packets are tunneled through the network back to an WLC, and traffic is placed on the client VLAN. This process requires packets to be encapsulated, unencapsulated, and possibly fragmented, which may introduce latency in the switching path. Omitting the WLC from the forwarding path for client traffic eliminates the tunnel encapsulation process, which can result in improved network performance. Local packet switching is disabled by default. An WLA can be configured to switch packets for some VLANs locally and tunnel packets for other VLANs through the WLC switch.

Notes Restricting Layer 2 forwarding for a VLAN is not supported if the VLAN is configured for local switching. The DHCP restrict feature is not supported for locally switched clients. When the set ap port type command is used to specify a port for a directly attached WLA, the WLA cannot be configured to perform local switching. However, a directly connected WLA with an unspecified port can perform local switching. Copyright © 2013, Juniper Networks, Inc.

Configuring Local Packet Switching on WLAs

137

IGMP snooping is not supported with local switching.

Configuring Local Switching Enable local switching on an WLA and in addition, a vlan-profile can be configured and applied to an WLA if you want the VLAN to exist on the WLA when the client connects to it.

Configuring a VLAN Profile A VLAN profile consists of a list of VLANs and tags. When a VLAN profile is applied to an WLA, the VLAN is initiated when clients are connected and are authorized on the VLAN. To add VLANs to a VLAN profile, use the following command: set vlan-profile profile-name vlan vlan-name [tag tag-value] Enter a separate set vlan-profile command for each VLAN you want to add to the VLAN profile. A VLAN profile can contain up to 128 entries. When the optional tag-value is set, it is used as the 802.1Q tag for the VLAN. To add an entry for VLAN red to VLAN profile locals, type the following command: WLC# set vlan-profile locals vlan red success: change accepted.

Enabling Local Switching on an WLA To enable local switching for a specified WLA, use the following command: set ap apnum local-switching mode {enable | disable} Local switching can be enabled on WLAs connected to the WLC through an intermediate Layer 2 or Layer 3 network. Local switching is not supported for WLAs directly connected to an WLC. To enable local switching for WLA 7, type the following command: WLC# set ap 7 local-switching mode enable success: change accepted.

Applying a VLAN Profile to an WLA By default, there is no VLAN profile applied to the WLA. To apply a VLAN profile to an WLA for local switching, use the following command: set ap apnum local-switching vlan-profile profile-name When a VLAN profile is applied to an WLA, traffic for the VLANs specified in the VLAN profile is locally switched by the WLA instead of sending the traffic back to an WLC. If local switching is enabled on an WLA, but no VLAN profile is configured, then a default VLAN profile is used. The default VLAN profile includes a single VLAN named default that is not tagged. When applying a VLAN profile causes traffic previously tunneled to an WLC to be locally switched by WLAs, or vice-versa, the sessions of clients associated with the WLAs with the applied VLAN profile are terminated, and the clients must re-associate with the WLAs. To specify that WLA 7 use VLAN profile locals, type the following command: WLC# set ap 7 local-switching vlan-profile locals

138




success: change accepted.

Clearing the VLAN Profile from an WLA To clear the VLAN profile applied to an WLA, use the following command: clear ap apnum local-switching vlan-profile This command resets the VLAN profile used by the WLA for local switching to the default VLAN profile. Traffic previously locally switched because of the cleared VLAN profile is instead tunneled to an WLC. When clearing a VLAN profile causes traffic previously locally switched by WLAs to be tunneled to an WLC, the sessions of clients associated with the applied VLAN profile on WLAs are terminated, and the clients must re-associate with the WLAs. To clear the VLAN profile applied to WLA 7, type the following command: WLC# clear ap 7 local-switching vlan-profile success: change accepted.

Removing a VLAN Profile from the WLC To remove a VLAN profile or individual entries from a VLAN profile, use the following command: clear vlan-profile profile-name [vlan vlan-name] You can use this command to remove individual VLANs from a VLAN profile, or to remove an entire VLAN profile. If you remove all of the entries from a VLAN profile, the VLAN profile is removed. If a VLAN profile is changed so that traffic previously tunneled to an WLC is now locally switched by WLAs, or vice-versa, the sessions of clients associated with the WLAs with the applied VLAN profile are terminated, and the clients must re-associate with the WLAs. To remove the entry for VLAN red from VLAN profile locals, type the following command: WLC# clear vlan-profile locals vlan red WLC# To remove VLAN profile locals, type the following command: WLC# clear vlan-profile locals

WLA to WLA Tunneling WLA-WLA tunneling feature now extends the WLC-WLC tunnel feature to allow WLAs with local switching enabled to create and terminate client VLAN tunnels. Therefore, a VLAN is not required on every WLA. When a client connects to an WLA with local switching enabled and is assigned to a specific VLAN, the following events occur on the network: If the VLAN exists locally on the WLA, then the VLAN is used for client traffic. If the VLAN does not exist locally on the WLA, the WLA performs a search in the roaming VLAN database to find the client VLAN. Once the VLAN is located, the WLA creates a tunnel to the client and client traffic is sent through the tunnel.



139

The WLA can create a tunnel to an WLC or to another WLA, depending on the configured tunnel affinity. By default, a VLAN on the WLC has an affinity of 5 and a VLAN on an WLA has an affinity of 4. If the tunnel affinity is the same, then the node with the lowest load is selected as a tunnel endpoint. With WLA to WLA tunneling, it is not necessary for an WLA to have a VLAN profile since it does not need a configured local VLAN. Therefore, when local switching is enabled on an WLA, a VLAN profile is not automatically assigned in the configuration. With local switching, a VLAN profile is assigned to indicate the following: A VLAN is locally switched. A VLAN is locally available on the WLA. Therefore, when a client connects to an WLA with local switching enabled and assigned a VLAN, if the VLAN is part of the VLAN profile, the session is locally switched. However, if the VLAN is not part of the VLAN profile, the session is in overlay mode. By default, the VLAN mode is local-switching. If the mode is set to overlay, this indicates that the VLAN is to be used in overlay mode. WLC# set vlan-profile profile-name vlan vlan-name mode [overlay | local-switching] To display information about VLAN profiles, use the following command: WLC# show vlan-profile VLAN profile: test AP list: 4 VLAN name

Tag

Mode

----------------------------------------------------------VLAN1

none

overlay

VLAN2

none

local-switched

You can also see roaming VLAN information by using the following command: WLC# show roaming vlan VLAN Name

Switch IP Address Affinity

AP

Load

-------------------------------------------------------------------default 5

----

10.2.2.12

AP03

19

test 4

10.8.116.105

21

Configuring WLA to WLA Tunneling To configure WLA to WLA tunneling, use the following command: WLC# set ap apnum tunnel-affinity affinity

140




where affinity is a value between 0 and 10 with a default value of 4 and 0 indicates that the WLA should not be used as a tunnel endpoint. To display the tunnel configuration, use the following command: WLC# show ap config apnum AP 2 (AP02) Model:

MP372

Mode: Bias:

high

Power mode:

auto

Options:

upgrade-firmware, led-auto

Connection:

port 3

Serial number: Fingerprint: Communication timeout:

25

Location: Contact: Vlan-profile: Tunnel affinity:

4

Radio 1 (802.11g) Mode:

sentry

Radio profile:

default

Channel:

dynamic

Load balancing:

YES

Tx power:

18

Load balancing group:

Auto tune max power:

default

Force rebalance:

Antenna location:

indoors

Antenna type:

NO

INTERNAL Num External Antenna: 0 Service profiles: techpubs3 Radio 2 (802.11a) Mode:

sentry

Radio profile:

default

Channel:

dynamic

Load balancing:

YES

Tx power:

17



default

Force rebalance:

Antenna location:

indoors

Antenna type:

NO

INTERNAL Num External Antenna: 0 Service profiles:



141

techpubs3 To display information about an WLA tunnel, use the following command: WLC# show tunnel VLAN

Local Address

Remote Address

State

Port

LVID

RVID ---------------- --------------- --------------- ------- ----- ----- To display detailed information about the WLA to WLA tunnel, use the following command: WLC# show tunnel ap apnum vlan vlan-name VLAN Address

Local Address Remote AP

Local AP

Remote

Load

-----------------------------------------------------------------------default AP02 student

142

10.8.116.105

-

10.8.121.114

10.8.116.106

AP04

10.8.121.116

75




-

23

faculty AP02

10.2.2.212

AP03

10.8.111.104

10.2.2.212

AP03

10.8.111.105

32

others Engineering 55

The local or remote WLA column displays the WLA name. If nothing is displayed, the node is an WLC. The Load column indicates traffic load on the local WLA.

Displaying Service Profile Information To display service profile information, use the following command: show service-profile {profile-name | ?} Entering show service-profile ? displays a list of the service profiles configured on the WLC. To display information for service profile sp1, type the following command: WLC# show service-profile sp1 ssid-name:

corp

Beacon:

ssid-type: clear

yes


5 last-resort


yes






Static COS:

no

COS: 0

Client DSCP:

no

CAC mode: none

CAC sessions:

14


yes


Idle client probing: Web Portal Session Timeout:

5

Web Portal ACL: Load Balance Exempt:

Mesh enabled: no Bridging enabled: no

no


6.0




2.0




2.0



143


Displaying Radio Profile Information To display radio profile information, use the following command: show radio-profile {profile-name | ?} Entering show radio-profile ? displays a list of radio profiles. To display radio profile information for the default radio profile, type the following command: WLC# show radio-profile default Beacon Interval:

100

Max Tx Lifetime:

2000

Max Rx Lifetime: 2000

RTS Threshold:

2346

Frag Threshold: 2346

Long Preamble:

no

Tune Channel Range (11a): Tune Power:

DTIM Interval: 1

Tune Channel: yes

lower-bands

Ignore Clients: no

no

Tune Channel Interval: 3600

Tune Power Interval:

600

Power ramp interval: 60

Channel Holddown:

300

Countermeasures: none

Active-Scan:

yes

RFID enabled: no

WMM Powersave:

no

QoS Mode: wmm

Rate Enforcement:

no

Initial Load: 1000

ETT Link Factor:

3

Dwell Time:

Change Threshold: 25

3600

Initial Measure Interval:

Probe Interval: 60

Radio Link Timeout:

60

Maximum Measure Interval: 600

5


Displaying WLA Status Information To display status information including link state and WLC status, use the following commands: show ap status [apnum | all | verbose |[radio {1 | 2}]] The all option displays information for all directly attached WLAs and all Distributed WLAs configured on the WLC. The following command displays the status of a Distributed WLA: WLC# show ap status 9991 144




Flags: o = operational[0], c = configure[0], d = download[0], b = boot[0] x= down a = auto AP, m = mesh AP, p/P = mesh portal (ena/actv), r = redundant[0] i = insecure, e = encrypted, u = unencrypted Radio: E = enabled - 20MHz channel, S = sentry W/w = enabled - 40MHz wide channel (HTplus/HTminus) D = admin disabled IP Address: * = AP behind NAT AP Flag IP Address Uptime

Model

MAC Address

Radio 1 Radio 2

---- ---- --------------- ------------ ----------------- ------- ------9991 oa-i 129.0.1.10

MP422 00:0b:0e:00:1b:00 E

6/22 D 44/18 03d21h


Displaying Static IP Address Information for Distributed WLAs To display information about WLAs configured with static IP address information, use the following command: show ap boot-configuration apnum To display statistics counters for WLA 1, type the following command: WLC# show ap boot-configuration 1 Static Boot Configuration AP: 7 IP Address:

Disabled

VLAN Tag:

Disabled

Switch:

Disabled

Mesh:

Disabled

IP Address: Netmask: Gateway: VLAN Tag:



145

Switch IP: Switch Name: DNS IP: Mesh SSID: Mesh PSK: Informational Note: For information about the fields in the output, see the Juniper Mobility System Software Command Reference.

Displaying WLA Statistics Counters To display WLA statistics counters, use the following commands: show ap counters [apnum [radio {1 | 2}]] To display statistics counters for WLA 7, type the following command: WLC# show ap counters 7 AP: 7

radio: 1

================================= LastPktXferRate

36

PktTxCount

14855302

NumCntInPwrSave

0

MultiPktDrop

0

LastPktRxSigStrength

-75

MultiBytDrop

0

LastPktSigNoiseRatio

20

User Sessions

0

TKIP Pkt Transfer Ct

0

MIC Error Ct

0

TKIP Pkt Replays

0

TKIP Decrypt Err

0

CCMP Pkt Decrypt Err

0

CCMP Pkt Replays

0

CCMP Pkt Transfer Ct

0

RadioResets

0

Radio Recv Phy Err Ct

0

Transmit Retries

0

Radio Adjusted Tx Pwr

0

Noise Floor

-90

802.3 Packet Tx Ct

0

802.3 Packet Rx Ct 0

No Receive Descriptor

0

Invalid Rates

TxUniPkt

TxUniByte

TxMultiPkt

RxPkt

0

RxByte

UndcrptPkt

TxMultiByte

UndcrptByte PhyErr

146

1.0:

0

2.0:

0

0

502648

67698076

0

0

0 14849546

0 2066952151

37537

2107316

0

0 25187852

5.5:

0

0

0

0

73167

11803093

0

0

9311

6.0:

0

0

0

0

434213 231595484

0

0

462

9.0:

0

0

0

0

541

223968

0

0

0

11.0:

0

0

0

0

129686

30105586

0

0

2774


0

2592086



12.0:

0

0

0

0

9016

612251

0

0

4

18.0:

0

0

0

0

29052

3427179

0

0

96

24.0:

0

0

0

0

96325

9941100

0

0

924

36.0:

0

0

0

0

136912

17914903

0

0

5846

48.0:

0

0

0

0

176674

41518676

0

0

563

54.0:

0

0

0

0 1231544 387008280

0

0

15705

TOTL:

0 14849546

0 2066952151 2857315 803955912

0

0 27815623

... Informational Note: For information about the fields in the output, see the Juniper Mobility System Software Command Reference.

To display statistics counters and other information for individual user sessions, use the show sessions network command.

Displaying Access Category Counters on a per-SSID, per-VLAN, and per-Radio Basis With MSS 9.0, the following counters can be displayed on a per SSID, per VLAN and per radio basis: TX/RX multicast packets TX/RX multicast bytes TX/RX unicast packets TX/RX unicast bytes TX retry packets



147

TX/RX drops WLC# show ap counters [apnum] radio [radionum] ssid [ssid] This command displays each SSID with individual ACs and a Total line. AC/ssid

txpkt

txrexmit

txdrop

rxpkt

rxbyte

rxdrop

AP:9 radio: 1 SSID: corpnet Background

0

0

0

0

0

0

BestEffort

0

0

0

0

0

0

Video

0

0

0

0

0

0

Voice

0

0

0

0

0

0

Multicast

0

0

0

4684

372648

0

Total

0

0

0

4684

372648

0

Displaying VLAN Profile Information To display the contents of the VLAN profiles configured on the WLC, use the following command: show vlan-profile [profile-name] The command lists the names and tags for each VLAN in the VLAN profile, as well as the WLAs to which the VLAN profile has been applied. To display the contents of VLAN profile locals type the following command: WLC# show vlan-profile locals vlan-profile: locals Vlan Name

Tag

---------

---

blue

none

red

45

ap numbers: 67 Informational Note: For information about the fields in the output, see the Juniper Mobility System Software Command Reference.

Displaying the ARP Table for an WLA To display the ARP table for a specified WLA, use the following command: show ap arp apnum 148




The following command displays ARP entries for AP 7: WLC# show ap arp 7 AP 7: Host

HW Address

VLAN

State

Type

------------------------------ ----------------- ----- -------- ------10.5.4.51

00:0b:0e:00:04:0c

1 EXPIRED

DYNAMIC

10.5.4.53

00:0b:0e:02:76:f7

1 RESOLVED LOCAL


Displaying the Forwarding Database for an WLA To display the entries in a specified WLA forwarding database, use the following command: show ap fdb apnum The following command displays FDB entries for AP 7: WLC# show ap fdb 7 AP 7: # = System Entry. $ = Authenticate Entry VLAN TAG

Dest MAC/Route Des [CoS] Destination Ports

---- ---- ------------------ ----- ----------------4095 4095 00:0b:0e:00:ca:c1 4095

#

0 00:0b:0e:00:04:0c

CPU eth0


Displaying VLAN Information for an WLA To display information about the VLANs that are either locally switched by the specified WLA or tunneled from the WLA to an WLC, use the following command: show ap vlan apnum The command lists the VLANs to which the clients associated with the WLA are members, and whether traffic for each VLAN is locally switched or tunneled back to an WLC. The following command displays information about the VLANs switched by AP 7: WLC# show ap vlan 7 AP 7: VLAN Name

Mode

---- ---------------- ---1 default Copyright © 2013, Juniper Networks, Inc.

local

Port

Tag

---------------- ---1 none Configuring Local Packet Switching on WLAs

149

2 red

4 green

local

1

2

radio_1

20

radio_1

21

radio_2

22

1

4

radio_1

23

5 yellow

mx_tun

5

local tunnel

radio_1 00:0b:0e:00:04:0c

244095

0

eth0


Displaying ACL Information for an WLA When an WLA is configured to perform local switching, you can display the number of packets filtered by security ACLs (“hits”) on the WLA. Each time a packet is filtered by a security ACL, the WLA ACL hit counter increments. To display ACL hits for an WLA, use the following command: show ap acl hits apnum For MSS to count hits for a security ACL, you must specify hits in the set security acl commands that define ACE rules for the ACL. The following command displays the security ACL hits on WLA 7, WLC# show ap acl hits 7 ACL hit-counters for AP 7 Index Counter

ACL-name

----- -------------------- -------1

0 acl_2

2

0 acl_175

3

916 acl_123

To display a summary of the security ACLs that are mapped on an WLA, use the following command: show ap acl map apnum This command lists only the ACLs that have been mapped on the specified WLA. To list all committed ACLs, use the show security acl info command. To list ACLs not yet committed, use the show security acl editbuffer command. To display a summary of the security ACLs mapped on WLA 7, type the following command: WLC# show ap acl map 7 ACL

Type Class

Mapping

---------------------------- ---- ------ ------acl_123

150


IP

Static In



acl_133

IP

Static In

acl_124 eth0

IP

Static 4095

0 00:0b:0e:00:04:0c




151

152




Configuring Radio-Specific Parameters Overview This section shows how to configure the channel and transmit power on individual radios, and how to configure for external antennas. (For information about the parameters you can set on individual radios, see “Changing Radio Parameters” on page 130.)

Configuring the Channel and Transmit Power Informational Note: If RF Auto-Tuning is enabled for channels or power, you cannot set the channels or power manually using the commands in this section.

To set the channel and transmit power of a radio, use the following commands: set ap apnum radio {1 | 2} channel channel-number set ap apnum radio {1 | 2} tx-power power-level The parameters are shown in separate commands for simplicity. However, you can use the channel and tx-power parameters on the same command line. Specify 1 or 2 for the radio number: For a single-radio model, specify radio 1. For the 802.11b/g radio in a two-radio model, specify radio 1. For the 802.11a radio in a two-radio model, specify radio 2. Informational Note: The maximum transmit power you can configure on any Juniper Networks radio is the highest setting allowed for the country of operation or the highest setting supported on the hardware.

To configure the 802.11b radio on port 11 for channel 1 with a transmit power of 10 dBm, type the following command: WLC# set ap 11 radio 1 channel 1 tx-power 10 success: change accepted. To configure the 802.11a radio on port 5 for channel 36 with a transmit power of 10 dBm, type the following command: WLC# set ap 5 radio 2 channel 36 tx-power 10 success: change accepted. You also can change the channel and transmit power on an individual basis.


Overview

153

Configuring the External Antenna Model and Location The WLA532e, WLA322 MP422 have connectors for attaching optional external 802.11a or 802.11b/g antennas. For specific information on external antennas and WLAs, refer to each WLA installation guide. Informational Note: When using external antennas in conjunction with Mesh configurations, enable Mesh mode before configuring the external antenna. After configuring the antenna, reboot the WLA in order to use the external antenna.

To specify the external antenna model, use the following command: set ap apnum radio {1 | 2} antennatype {ANT1060 | ANT1120 | ANT1180 | ANT5060 | ANT5120 | ANT5180 | ANT7360 ANT-1360-OUT | ANT-5360-OUT | ANT-5060-OUT | ANT-5120-OUT | ANT-7360-OUT | internal} To configure antenna model ANT-1060 for an MP372 on WLA 1, type the following command: WLC# set ap 1 radio 1 antennatype ANT1060 success: change accepted.

Specifying the External Antenna Location In some cases, the set of valid channels for a radio differs if the antenna is located indoors or outdoors. You can ensure that the proper set of channels is available on the radio by specifying the antenna location (indoors or outdoors). The default location is indoors. To change an external antenna location, use the following command: set ap apnum antenna-location {indoors | outdoors}

Mapping the Radio Profile to Service Profiles To assign SSIDs to radios, you must map the service profiles for the SSIDs to the radio profile assigned to the radios. To map a radio profile to a service profile, use the following command: set radio-profile profile-name service-profile profile-name The following command maps service-profile wpa_clients to radio profile rp2: WLC# set radio-profile rp2 service-profile wpa_clients success: change accepted.

Assigning a Radio Profile and Enabling Radios To assign a radio profile to radios, use the following command: set ap apnum radio {1 | 2} radio-profile profile-name mode {enable | disable} To assign radio profile rp1 to radio 1 on ports 5-8, 11-14, and 16 and enable the radios, type the following command: WLC# set ap 5-8,11-14,16 radio 1 radio-profile rp1 mode enable success: change accepted. 154

Overview



To assign radio profile rp1 to radio 2 on ports 11-14 and port 16 and enable the radios, type the following command: WLC# set ap 11-14,16 radio 2 radio-profile rp1 mode enable success: change accepted. To disable radio 1 on port 6 without disabling the other radios using radio profile rp1, type the following command: WLC# set ap 6 radio 1 radio-profile rp1 mode disable (To disable or reenable all radios that are using a radio profile, see “Disabling or Enabling All Radios Using a Profile” on page 1–155.)

Disabling or Enabling Radios You can disable or enable radios on a radio profile basis or individual basis. You also can reset a radio to the factory default settings. (To disable or enable radios when assigning or removing a radio profile, see “Assigning a Radio Profile and Enabling Radios” on page 1–154.)

Enabling or Disabling Individual Radios To disable or enable an WLA radio, use the following command: set ap apnum radio {1 | 2} mode {enable | disable} To disable radio 2 on port 3 and 7, type the following command: WLC# set ap 3,7 radio 2 mode disable success: change accepted.

Disabling or Enabling All Radios Using a Profile To disable or enable all radios that are using a radio profile, use the following command: set radio-profile profile-name [mode {enable | disable}] The following command enables all radios that use radio profile rp1: WLC# set radio-profile rp1 mode enable success: change accepted. The following commands disable all radios that use radio profile rp1, change the beacon interval, then reenable the radios: WLC# set radio-profile rp1 mode disable success: change accepted. WLC# set radio-profile rp1 beacon-interval 200 success: change accepted. WLC# set radio-profile rp1 mode enable success: change accepted.



155

Resetting a Radio to Factory Default Settings To disable an WLA radio and reset it to the factory default settings, use the following command: clear ap apnum radio {1 | 2 | all} This command performs the following actions: Sets the transmit power, channel, and external antenna type to the default values. Removes the radio from a radio profile and places the radio in the default radio profile. This command does not affect the PoE setting. To disable and reset radio 2 on the WLA connected to port 3, type the following command: WLC# clear ap 3 radio 2

Restarting an WLA To restart an WLA, use the following command: reset ap apnum Use the reset ap command to reset an WLA configured on an WLA access port. Use the reset ap command to reset a Distributed WLA. When you enter one of these commands, the WLA drops all sessions and reboots.

Warning: Restarting an WLA can cause data loss for users who are currently associated with the WLA.

Displaying Service Profile Information To display service profile information, use the following command: show service-profile {profile-name | ?} Entering show service-profile ? displays a list of the service profiles configured on the WLC. To display information for service profile sp1, type the following command: WLC# show service-profile sp1 ssid-name: Beacon: Short retry limit: Auth fallthru: Enforce SODA checks:

ssid-type: clear

yes 5 last-resort yes






Static COS:

no

COS: 0

Client DSCP:

no

CAC mode: none

CAC sessions:

14


yes


Idle client probing: 156

corp




Web Portal Session Timeout:

5

Mesh enabled: no

Web Portal ACL:

Bridging enabled: no

Load Balance Exempt:

no


6.0




2.0



2.0




100

Max Tx Lifetime:

2000


RTS Threshold:

2346


Long Preamble:

no


DTIM Interval: 1

Tune Channel: yes

lower-bands

Ignore Clients: no

no



600


Channel Holddown:

300


Active-Scan:

yes

RFID enabled: no

WMM Powersave:

no

QoS Mode: wmm

Rate Enforcement:

no

Initial Load: 1000

ETT Link Factor:

3

Dwell Time:


3600


Probe Interval: 60

Radio Link Timeout:


60


5


157

0 Informational Note: For information about the fields in the output, see the Juniper Mobility System Software Command Reference.


radio: 1


36

PktTxCount

14855302

NumCntInPwrSave

0

MultiPktDrop

0


-75

MultiBytDrop

0


20

User Sessions

0


0

MIC Error Ct

0

TKIP Pkt Replays

0

TKIP Decrypt Err

0


0

CCMP Pkt Replays

0


0

RadioResets

0


0

Transmit Retries

0


0

Noise Floor

-90

802.3 Packet Tx Ct

0



0

Invalid Rates

TxUniPkt

TxUniByte

TxMultiPkt

RxPkt

0

RxByte

UndcrptPkt

TxMultiByte

UndcrptByte PhyErr

158

1.0:

0

2.0:

0

502648

67698076

0

0

0 14849546

0 2066952151

37537

2107316

0

0 25187852

5.5:

0

0

0

0

73167

11803093

0

0

9311

6.0:

0

0

0

0

434213 231595484

0

0

462

9.0:

0

0

0

0

541

223968

0

0

0

11.0:

0

0

0

0

129686

30105586

0

0

2774

12.0:

0

0

0

0

9016

612251

0

0

4

18.0:

0

0

0

0

29052

3427179

0

0

96

24.0:

0

0

0

0

96325

9941100

0

0

924

36.0:

0

0

0

0

136912

17914903

0

0

5846


0

0

2592086



48.0:

0

0

0

0

176674

41518676

0

0

563

54.0:

0

0

0

0 1231544 387008280

0

0

15705

TOTL:

0 14849546

0 2066952151 2857315 803955912

0

0 27815623




Tag

---------

---

blue

none

red

45


Displaying the ARP Table for an WLA To display the ARP table for a specified WLA, use the following command: show ap arp apnum The following command displays ARP entries for AP 7: WLC# show ap arp 7 AP 7: Host

HW Address

VLAN

State

Type

------------------------------ ----------------- ----- -------- ------10.5.4.51


00:0b:0e:00:04:0c

1 EXPIRED

DYNAMIC


159

10.5.4.53

00:0b:0e:02:76:f7

1 RESOLVED LOCAL




---- ---- ------------------ ----- ----------------4095 4095 00:0b:0e:00:ca:c1 4095

#

0 00:0b:0e:00:04:0c

CPU eth0



Mode

---- ---------------- ----

Tag

---------------- ----

1 default

local

1 none

2 red

local

1

2

radio_1

20

radio_1

21

radio_2

22

1

4

radio_1

23

4 green

160

Port


local



5 yellow

tunnel

mx_tun

5 radio_1

00:0b:0e:00:04:0c

244095

0

eth0



ACL-name

----- -------------------- -------1

0 acl_2

2

0 acl_175

3

916 acl_123


Type Class

Mapping

---------------------------- ---- ------ ------acl_123

IP

Static In

acl_133

IP

Static In

acl_124 eth0

IP

Static 4095

0 00:0b:0e:00:04:0c




161

162




Configuring Local Packet Switching on WLAs Overview WLAs can be configured to perform local packet switching. Local packet switching allows packets to switch directly from the WLA to the wired network, instead of passing through an intermediate WLC. The term, tunnel, can be confusing as it can have different meanings, depending on the context. Here are a couple of definitions to assist with understanding tunnel as it applies here: Overlay tunnel — A data tunnel that exists between an WLC and WLA. If the client session is not locally switched, then it is an overlay tunnel and the client data traffic is included in this tunnel. Sessions that use this type of tunnel: - Sessions with local switching disabled. - Sessions with local switching enabled but the VLAN for the session is set to overlay mode in the

VLAN profile on the WLA. Mobility Domain tunnel — data tunnel between two WLCs, 2 WLAs, or an WLC and an WLA. It is used when an WLA or WLC with local switching enabled does not have the client VLAN configured on it and the traffic is tunneled from another WLC or WLA. When an WLA is configured to perform local switching, the WLC is removed from the forwarding path for client data traffic. When local switching is enabled, the client VLAN is directly accessible through the wired interface on the WLA. Packets can be switched directly to and from this interface. Normally, when local switching is disabled on an WLA, packets are tunneled through the network back to an WLC, and traffic is placed on the client VLAN. This process requires packets to be encapsulated, unencapsulated, and possibly fragmented, which may introduce latency in the switching path. Omitting the WLC from the forwarding path for client traffic eliminates the tunnel encapsulation process, which can result in improved network performance. Local packet switching is disabled by default. An WLA can be configured to switch packets for some VLANs locally and tunnel packets for other VLANs through the WLC switch.

Informational Note:

Restricting Layer 2 forwarding for a VLAN is not supported if the VLAN is configured for local switching. The DHCP restrict feature is not supported for locally switched clients. When the set ap apnum port portnum type command is used to specify a port for a directly attached WLA, the WLA cannot be configured to perform local switching. However, a directly connected WLA with an unspecified port can perform local switching. IGMP snooping is not supported with local switching.


Overview

163

Configuring Local Switching Enable local switching on an WLA and in addition, a vlan-profile can be configured and applied to an WLA if you want the VLAN to exist on the WLA when the client connects to it.

Configuring a VLAN Profile A VLAN profile consists of a list of VLANs and tags. When a VLAN profile is applied to an WLA, the VLAN is initiated when clients are connected and are authorized on the VLAN. To add VLANs to a VLAN profile, use the following command: set vlan-profile profile-name vlan vlan-name [tag tag-value] Enter a separate set vlan-profile command for each VLAN you want to add to the VLAN profile. A VLAN profile can contain up to 128 entries. When the optional tag-value is set, it is used as the 802.1Q tag for the VLAN. To add an entry for VLAN red to VLAN profile locals, type the following command: WLC# set vlan-profile locals vlan red success: change accepted.

Enabling Local Switching on an WLA To enable local switching for a specified WLA, use the following command: set ap apnum local-switching mode {enable | disable} Local switching can be enabled on WLAs connected to the WLC through an intermediate Layer 2 or Layer 3 network. Local switching is not supported for WLAs directly connected to an WLC. To enable local switching for WLA 7, type the following command: WLC# set ap 7 local-switching mode enable success: change accepted.

Applying a VLAN Profile to an WLA By default, there is no VLAN profile applied to the WLA. To apply a VLAN profile to an WLA for local switching, use the following command: set ap apnum local-switching vlan-profile profile-name When a VLAN profile is applied to an WLA, traffic for the VLANs specified in the VLAN profile is locally switched by the WLA instead of sending the traffic back to an WLC. If local switching is enabled on an WLA, but no VLAN profile is configured, then a default VLAN profile is used. The default VLAN profile includes a single VLAN named default that is not tagged. When applying a VLAN profile causes traffic previously tunneled to an WLC to be locally switched by WLAs, or vice-versa, the sessions of clients associated with the WLAs with the applied VLAN profile are terminated, and the clients must re-associate with the WLAs. To specify that WLA 7 use VLAN profile locals, type the following command: WLC# set ap 7 local-switching vlan-profile locals success: change accepted.

164

Overview



Clearing the VLAN Profile from an WLA To clear the VLAN profile applied to an WLA, use the following command: clear ap apnum local-switching vlan-profile This command resets the VLAN profile used by the WLA for local switching to the default VLAN profile. Traffic previously locally switched because of the cleared VLAN profile is instead tunneled to an WLC. When clearing a VLAN profile causes traffic previously locally switched by WLAs to be tunneled to an WLC, the sessions of clients associated with the applied VLAN profile on WLAs are terminated, and the clients must re-associate with the WLAs. To clear the VLAN profile applied to WLA 7, type the following command: WLC# clear ap 7 local-switching vlan-profile success: change accepted.

Removing a VLAN Profile from the WLC To remove a VLAN profile or individual entries from a VLAN profile, use the following command: clear vlan-profile profile-name [vlan vlan-name] You can use this command to remove individual VLANs from a VLAN profile, or to remove an entire VLAN profile. If you remove all of the entries from a VLAN profile, the VLAN profile is removed. If a VLAN profile is changed so that traffic previously tunneled to an WLC is now locally switched by WLAs, or vice-versa, the sessions of clients associated with the WLAs with the applied VLAN profile are terminated, and the clients must re-associate with the WLAs. To remove the entry for VLAN red from VLAN profile locals, type the following command: WLC# clear vlan-profile locals vlan red WLC# To remove VLAN profile locals, type the following command: WLC# clear vlan-profile locals

WLA to WLA Tunneling WLA-WLA tunneling feature now extends the WLC-WLC tunnel feature to allow WLAs with local switching enabled to create and terminate client VLAN tunnels. Therefore, a VLAN is not required on every WLA. When a client connects to an WLA with local switching enabled and is assigned to a specific VLAN, the following events occur on the network: If the VLAN exists locally on the WLA, then the VLAN is used for client traffic. If the VLAN does not exist locally on the WLA, the WLA performs a search in the roaming VLAN database to find the client VLAN. Once the VLAN is located, the WLA creates a tunnel to the client and client traffic is sent through the tunnel. The WLA can create a tunnel to an WLC or to another WLA, depending on the configured tunnel affinity. By default, a VLAN on the WLC has an affinity of 5 and a VLAN on an WLA has an affinity of 4. If the tunnel affinity is the same, then the node with the lowest load is selected as a tunnel endpoint.


Overview

165

With WLA to WLA tunneling, it is not necessary for an WLA to have a VLAN profile since it does not need a configured local VLAN. Therefore, when local switching is enabled on an WLA, a VLAN profile is not automatically assigned in the configuration. With local switching, a VLAN profile is assigned to indicate the following: A VLAN is locally switched. A VLAN is locally available on the WLA. Therefore, when a client connects to an WLA with local switching enabled and assigned a VLAN, if the VLAN is part of the VLAN profile, the session is locally switched. However, if the VLAN is not part of the VLAN profile, the session is in overlay mode. By default, the VLAN mode is local-switching. If the mode is set to overlay, this indicates that the VLAN is to be used in overlay mode. WLC# set vlan-profile profile-name vlan vlan-name mode [overlay | local-switching] To display information about VLAN profiles, use the following command: WLC# show vlan-profile VLAN profile: test AP list: 4 VLAN name

Tag

Mode

----------------------------------------------------------VLAN1

none

overlay

VLAN2

none

local-switched

You can also see roaming VLAN information by using the following command: WLC# show roaming vlan VLAN Name

Switch IP Address Affinity

AP

Load

-------------------------------------------------------------------default 5

----

10.2.2.12

AP03

19

test 4

10.8.116.105

21

Configuring WLA to WLA Tunneling To configure WLA to WLA tunneling, use the following command: WLC# set ap apnum tunnel-affinity affinity where affinity is a value between 0 and 10 with a default value of 4 and 0 indicates that the WLA should not be used as a tunnel endpoint. To display the tunnel configuration, use the following command: WLC# show ap config apnum AP 2 (AP02)

166

Overview



Model:

MP372

Mode: Bias:

high

Power mode:

auto

Options:

upgrade-firmware, led-auto

Connection:

port 3

Serial number: Fingerprint: Communication timeout:

25

Location: Contact: Vlan-profile: Tunnel affinity:

4

Radio 1 (802.11g) Mode:

sentry

Radio profile:

default

Channel:

dynamic

Load balancing:

YES

Tx power:

18



default

Force rebalance:

Antenna location:

indoors

Antenna type:

NO

INTERNAL Num External Antenna: 0 Service profiles: techpubs3 Radio 2 (802.11a) Mode:

sentry

Radio profile:

default

Channel:

dynamic

Load balancing:

YES

Tx power:

17



default

Force rebalance:

Antenna location:

indoors

Antenna type:

NO

INTERNAL Num External Antenna: 0 Service profiles: techpubs3 To display information about an WLA tunnel, use the following command: WLC# show tunnel VLAN

Local Address

Remote Address

State

Port

LVID

RVID Copyright © 2013, Juniper Networks, Inc.

Overview

167

---------------- --------------- --------------- ------- ----- ----- To display detailed information about the WLA to WLA tunnel, use the following command: WLC# show tunnel ap apnum vlan vlan-name VLAN

Local Address

Local AP

Remote Address

Remote AP

Load

-----------------------------------------------------------------------default

10.8.116.105

-

10.8.121.114

AP02

75

student

10.8.116.106

AP04

10.8.121.116

-

23

faculty

10.2.2.212

AP03

10.8.111.104

AP02

32

others

10.2.2.212

AP03

10.8.111.105

Engineering 55

The local or remote WLA column displays the WLA name. If nothing is displayed, the node is an WLC. The Load column indicates traffic load on the local WLA.

168

Overview


Displaying Radio Profile Information


100

Max Tx Lifetime:

2000


RTS Threshold:

2346


Long Preamble:

no


DTIM Interval: 1

Tune Channel: yes

lower-bands

Ignore Clients: no

no



600


Channel Holddown:

300


Active-Scan:

yes

RFID enabled: no

WMM Powersave:

no

QoS Mode: wmm

Rate Enforcement:

no

Initial Load: 1000

ETT Link Factor:

3

Dwell Time:


3600


Probe Interval: 60

Radio Link Timeout:

60


5



169

170


Displaying WLA Status Information

Displaying WLA Status Information To display status information including link state and WLC status, use the following commands: show ap status [apnum | all | verbose |[radio {1 | 2}]] The all option displays information for all directly attached WLAs and all Distributed WLAs configured on the WLC. The following command displays the status of a Distributed WLA: WLC# show ap status 9991 Flags: o = operational[0], c = configure[0], d = download[0], b = boot[0] x= down a = auto AP, m = mesh AP, p/P = mesh portal (ena/actv), r = redundant[0] i = insecure, e = encrypted, u = unencrypted Radio: E = enabled - 20MHz channel, S = sentry W/w = enabled - 40MHz wide channel (HTplus/HTminus) D = admin disabled IP Address: * = AP behind NAT AP Flag IP Address Uptime

Model

MAC Address

Radio 1 Radio 2

---- ---- --------------- ------------ ----------------- ------- ------9991 oa-i 129.0.1.10

MP422 00:0b:0e:00:1b:00 E

6/22 D 44/18 03d21h


Displaying Static IP Address Information for Distributed WLAs To display information about WLAs configured with static IP address information, use the following command: show ap boot-configuration apnum To display statistics counters for WLA 1, type the following command: WLC# show ap boot-configuration 1 Static Boot Configuration AP: 7 IP Address:

Disabled

VLAN Tag:

Disabled

Switch:

Disabled

Mesh:

Disabled

IP Address: Netmask: Copyright © 2013, Juniper Networks, Inc.

171

Gateway: VLAN Tag: Switch IP: Switch Name: DNS IP: Mesh SSID: Mesh PSK: Informational Note: For information about the fields in the output, see the Juniper Mobility System Software Command Reference.


radio: 1


36

PktTxCount

14855302

NumCntInPwrSave

0

MultiPktDrop

0


-75

MultiBytDrop

0


20

User Sessions

0


0

MIC Error Ct

0

TKIP Pkt Replays

0

TKIP Decrypt Err

0


0

CCMP Pkt Replays

0


0

RadioResets

0


0

Transmit Retries

0


0

Noise Floor

-90

802.3 Packet Tx Ct

0



0

Invalid Rates

TxUniPkt

TxUniByte

TxMultiPkt

RxPkt

0

RxByte

UndcrptPkt

TxMultiByte

UndcrptByte PhyErr

172

1.0:

0

2.0:

0

0

0

502648

67698076

0

0

2592086

0 14849546

0 2066952151

37537

2107316

0

0 25187852

5.5:

0

0

0

0

73167

11803093

0

0

9311

6.0:

0

0

0

0

434213 231595484

0

0

462



9.0:

0

0

0

0

541

223968

0

0

0

11.0:

0

0

0

0

129686

30105586

0

0

2774

12.0:

0

0

0

0

9016

612251

0

0

4

18.0:

0

0

0

0

29052

3427179

0

0

96

24.0:

0

0

0

0

96325

9941100

0

0

924

36.0:

0

0

0

0

136912

17914903

0

0

5846

48.0:

0

0

0

0

176674

41518676

0

0

563

54.0:

0

0

0

0 1231544 387008280

0

0

15705

TOTL:

0 14849546

0 2066952151 2857315 803955912

0

0 27815623




Tag

---------

---

blue

none

red

45


Displaying the ARP Table for an WLA To display the ARP table for a specified WLA, use the following command: show ap arp apnum The following command displays ARP entries for AP 7:


173

WLC# show ap arp 7 AP 7: Host

HW Address

VLAN

State

Type

------------------------------ ----------------- ----- -------- ------10.5.4.51

00:0b:0e:00:04:0c

1 EXPIRED

DYNAMIC

10.5.4.53

00:0b:0e:02:76:f7

1 RESOLVED LOCAL




---- ---- ------------------ ----- ----------------4095 4095 00:0b:0e:00:ca:c1 4095

#

0 00:0b:0e:00:04:0c

CPU eth0



Mode

---- ---------------- ----

174

Port

Tag

---------------- ----

1 default

local

1 none

2 red

local

1

2 Copyright © 2013, Juniper Networks, Inc.


4 green

radio_1

20

radio_1

21

radio_2

22

1

4

radio_1

23

5 yellow

mx_tun

5

local tunnel

radio_1 00:0b:0e:00:04:0c

244095

0

eth0



ACL-name

----- -------------------- -------1

0 acl_2

2

0 acl_175

3

916 acl_123


Type Class

Mapping

---------------------------- ---- ------ ------acl_123

IP

Static In

acl_133

IP

Static In


175

acl_124 eth0

IP

Static 4095

0 00:0b:0e:00:04:0c


176


Configuring WLAN Mesh Service

Configuring WLAN Mesh Service WLAN Mesh Services Overview WLAN mesh services allow an WLA to provide wireless services to clients without a wired interface on the WLA. Instead of a wired interface, there is a radio link to another WLA with a wired interface.There are three components to a mesh deployment: Mesh Portal – the WLA connected to the wired port on an WLC. Mesh WLA – the wireless WLA without a wired connection (untethered) Mesh Link – a Layer 2 transparent bridge with the Mesh Portal and the Mesh WLA as endpoints. WLAN mesh services can be used at sites when running Ethernet cable to a location is inconvenient, expensive or impossible. Note that power must be available at the location where the Mesh AP is installed.

Enhancements to Mesh Services Multihop is now available when configuring Mesh Services. The system can support up to 16 Mesh Portals with each Mesh Portal supporting a 6 Mesh AP fan-out with a depth of 2 Mesh APs. Also, a single WLA can perform two roles: Mesh Portal and Mesh WLA. Mesh Services reliability is improved by adding the following enhancements: Improved transmission of station session record. Ability to manage link loss between Mesh Portals and Mesh APs. Improved management of duplicate messages for SSR updates from multiple Mesh APs. Mesh portal selection has improved by scanning for Mesh Link SSIDs and sorting them by RSSI values. The Mesh AP establishes a link using the RSSI values in descending order. If all attempts fail, the Mesh AP scans from the beginning of the table. After 60 seconds and no link is established, the Mesh AP reboots. If the Mesh Link is using a DFS channel, then the Mesh Link has a timeout of 140 seconds to allow for DFS channel assessment. Mesh Portal selection is improved by scanning for Mesh Link SSIDs and sorting them by RSSI values. The Mesh AP establishes a link using RSSI values in descending order. If all attempts fail, the Mesh AP scans from the beginning of the table. After 60 seconds and no link is established, the Mesh AP reboots. If the Mesh Link is using a DFS channel, then the Mesh Link has a timeout of 140 seconds to allow for DFS channel assessment. Figure 1–12 illustrates how a client can connect to a network using WLAN mesh services.


WLAN Mesh Services Overview

177

Figure 1–12. WLAN Mesh Services

In the illustration, Client #2 and Client #3 are associated with a Mesh AP, an WLA without a wired interface to the network. The Mesh AP is configured to communicate with a Mesh Portal, an WLA with wired connectivity to an WLC. Communication between the Mesh AP and the Mesh Portal takes place using over a secure radio link (a Mesh Link). When associated with the Mesh AP, the client has the same connectivity to the network as an WLA with a wired link. Client #1 is associated with an AP performing the dual role of Mesh AP and Mesh Portal AP. Mesh Link #1 is the first hop of a multihop configuration and Mesh Link #2 is the second hop. Configuring a multihop deployment requires two stages: Configuring the Mesh Portal connection to the WLC and the first Mesh AP. Configuring the second Mesh AP to the middle WLA which then performs a dual role of Mesh AP and Mesh Portal AP. The Mesh AP and Mesh Portal AP are dual-radio WLAs. One radio (for example, the 802.11a radio) can be used for Mesh Link communications, using an SSID reserved for this purpose, while the Mesh AP can use the other radio for client associations in the same manner as a non-Mesh AP. The Mesh Portal AP beacons a mesh services SSID on the radio used for the Mesh Link. When the Mesh AP is booted, the AP searches for an WLA beaconing the mesh services SSID. The AP selects the Mesh Portal AP with the greatest signal strength, then establishes a secure connection to the Mesh Portal SSID. Once this connection is established, clients can associate with the Mesh AP.

178

WLAN Mesh Services Overview



WLAN mesh services is supported on the MP620, MP632, MP432, and MP422 only.

Configuring WLAN Mesh Services The basic configuration process for WLAN mesh services consists of the following tasks: Attaching the Mesh AP to the network and configuring mesh services. Configuring a service profile for mesh services. Setting security parameters to allow the Mesh AP to authenticate on the network. Optional—configuring the Mesh Portal to emit link calibration packets to aid with positioning the Mesh AP. Detaching the Mesh AP from the network and deploying the AP in a final location. After the Mesh AP is installed in a final location, and establishes a connection to the Mesh Portal, it can be configured as any other WLA on the WLC. Informational Note: The MAC address of the radio is determined as follows: If using the 802.11a radio, the MAC address is the last one printed on the label. If using the 802.11b/g radio, the MAC address is the next to the last one printed.

Configuring the Mesh AP Before a Mesh AP can be installed in a location untethered from the network, it must be preconfigured for mesh services, including the mesh services SSID, and the pre-shared key for establishing the connection between the Mesh AP and the Mesh Portal. 1. Attach the WLA to your network, apply power, and allow the WLA to boot as a regular WLA. 2. Once the WLA has booted, use the following command to enable mesh services on the WLA. set ap apnum boot-configuration mesh mode {enable | disable}[ssid ] 3. Use the following command to specify the pre-shared key: set ap apnum boot-configuration mesh {psk-phrase pass-phrase | psk-raw raw-pass} 4. When a pass-phrase is specified, it is converted into a raw hexadecimal key and stored in the WLA boot configuration. 5. Use the following command to set the TAPA control channel timeout on the WLA: set ap apnum time-out The default timeout is 10 seconds but you should increase the timeout depending on the length of the Mesh Link. If DFS is enabled, you may want to increase the timeout to 140 seconds to allow the radio to scan channels. When the Mesh WLA is booted, and attempts connect to the network, the WLA then associates with the specified mesh-ssid and authorizes using the last or next to last MAC address, if configured to use the MAC address for authorization. Mesh WLAs can also use last-resort authentication. Authentication is performed using the PSK information. Copyright © 2013, Juniper Networks, Inc.

Configuring WLAN Mesh Services

179

If there are multiple Mesh Portals advertising the Mesh Link SSID, the Mesh WLA selects the Mesh Portal with the strongest RSSI value. Once authentication is complete, the Mesh WLA searches for an WLC using the identical control packet exchanges as non-Mesh WLAs on the network. The Mesh Link is an authenticated encrypted radio link between Mesh WLAs, and once the link is established, the Mesh WLA does not switch to another Mesh Portal unless the WLA loses contact with the original Mesh Portal. When a mesh-ssid is specified, the regulatory domain of the WLC and the power restrictions are copied to the WLA flash memory. This prevents the Mesh AP from operating outside of regulatory limits after booting and before receiving a complete configuration from the WLC. Consequently, it is important that the regulatory and antenna information specified on the WLC reflects the locale where the Mesh AP is to be deployed, in order to avoid regulatory violations.

Configuring the Service Profile for Mesh Services You configure the Mesh Portal AP to beacon the mesh services SSID. To do this, create a service profile and enable mesh services using the following commands: WLC# set service-profile mesh-service-profile ssid-name mesh-ssid WLC# set service-profile mesh-service-profile mesh mode {enable | disable} The service profile can then be mapped to a radio profile that manages a radio on the Mesh Portal. Note that the radio profile mapped to the service profile cannot be configured to auto-tune power or channel settings. To map the service profile to a radio profile, use the following command: WLC# set radio-profile mesh-radio-profile service-profile mesh-service-profile Since auto-tune is enabled by default, you must disable it on the Mesh Portal using the following command: WLC# set radio-profile mesh-profile-name auto-tune channel-config disable

Configuring Security The secure connection between the Mesh AP and the Mesh Portal AP is established in a two-step process: 1) creation of an encrypted point-to-point link between the Mesh AP and the Mesh Portal AP, and2) authentication of the Mesh AP. When the Mesh AP is booted, it searches for a beacon containing the configured mesh SSID. Once the Mesh AP locates a Mesh Portal AP with the mesh SSID, it associates with the Mesh Portal AP as a client device. The Mesh AP can then be authenticated by the WLC. To configure the Mesh AP for authentication, use the following commands: set service-profile mesh-service-profile cipher-ccmp enable set service-profile mesh-service-profile rsn-ie enable set service-profile mesh-service-profile {psk-phrase pass-phrase | psk-raw raw-pass} set service-profile mesh-service-profile auth-psk enable set authentication mac ssid mesh-ssid * local

180




The pass-phrase or raw-pass is the same one configured on the Mesh AP. Optionally, the fingerprint of the Mesh AP can be configured on the WLC for additional security. You can also configure last-resort authentication for clients accessing the Mesh APs using the following commands: WLC# set service-profile mesh-service-profile auth-dot1x disable WLC# set service-profile mesh-service-profile auth-fallthru last-resort

Recommended Configuration Best Practices The following recommendations provide the most stable mesh services on a wireless network: Dedicate one radio to client services and one radio to mesh services. Juniper Networks recommends that you dedicate the 802.11a radio (radio 2) to mesh services and the 802.11b radio (radio 1) to client services. Dedicate the Mesh Portal to mesh services if you anticipate a full client load through the Mesh WLA. Limit the length of the mesh link to 3/8ths of a mile (1.09 km) or less if you have configured MSS 6.0.4 or earlier. Later versions of MSS support distances up to 1 mile (1.6 km) for Mesh Links. Enable local switching on the Mesh Portal and all Mesh WLAs. Although local switching is not related to mesh services, configuring it may improve your throughput on the WLA. You can configure a mesh network with a mesh width of 10Mesh Portal APs and a mesh depth of 4 Mesh APs per Mesh Portal AP.

Enabling Link Calibration Packets on the Mesh Portal WLA A Mesh Portal WLA can be configured to emit link calibration packets to assist with positioning the Mesh AP. A link calibration packet is an unencrypted 802.11 management packet of type Action. When enabled on an WLA, link calibration packets are sent at a rate of 5 per second. The MP620 is equipped with a connector to which an external RSSI meter can be attached during installation. When an RSSI meter is attached to an MP620 and a calibration packet is received, the MP620 emits a voltage to the RSSI meter proportional to the received signal strength of the packet. This can aid in positioning the MP620 where it has a strong signal to the Mesh Portal AP. To enable link calibration packets on an WLA radio, use the following command: set ap num radio num link-calibration mode {enable | disable} Only one radio on an WLA can be configured to send link calibration packets. Link calibration packets are intended to be used only during installation of WLAs; they are not intended to be enabled on a continual basis.

Deploying the Mesh AP After you have configured the Mesh AP with mesh services settings, detach the AP from the wired network and place it in the desired location. The Mesh Portal AP must be within radio range of the Mesh AP.



181

Configuring Wireless Bridging You can use WLAN mesh services in a wireless bridge configuration, implementing WLAs as bridge endpoints in a transparent Layer 2 bridge. Configuring a wireless bridge to connect two sites provides an alternative to installing Ethernet cable to provide bridge functionality. A typical application of wireless bridging is to provide network connectivity between two buildings using a wireless link, as shown in Figure 2. Figure 1–13. Wireless Bridging

The wireless bridge is established between a Mesh Portal AP and an associated Mesh AP. The bridged data packets are present on the Ethernet interfaces of the two WLAs. A Mesh Portal AP deployed as a bridge endpoint can support up to five Mesh APs configured as bridge endpoints. A Mesh AP serving as a bridge endpoint picks up packets from the wired port and transfers them to the other bridge endpoint. A simple source/destination learning mechanism is used to avoid forwarding packets across the bridge unnecessarily. To enable wireless bridging for a service profile, use the following command: set service-profile mesh-service-profile bridging {enable | disable}

Informational Note: You must reboot the WLAs before wireless bridging begins working on the network.

When wireless bridging is enabled for a service profile, the WLAs with the applied service profile are bridge peers. When a Mesh AP associates with a Mesh Portal AP through this service profile, the Mesh Portal AP automatically configures the Mesh AP to operate in bridge mode. The show service-profile command indicates if bridging is enabled for the service profile.

Informational Note: Active WLAs must be rebooted before bridging is enabled on the network.

182

Configuring Wireless Bridging



Displaying WLAN Mesh Services Information The show ap status verbose command indicates which WLAs are Mesh APs and which are Mesh Portal WLAs. For example: WLC# show ap status Total number of entries: 120 Operational: 1, Image Downloading: 0, Unknown: 119, Other: 0 Flags: o = operational, b = booting, d = image downloading c = configuring, f = configuration failed a = auto AP, m = mesh AP, p = mesh portal i = insecure, e = encrypted, u = unencrypt AP

Flag IP Address

Model

MAC Address

Radio1 Radio2 Uptime

--- ---- --------------- --------- ----------------- ------ ------ -----7 om-u

MP422 00:0b:0e:00:ca:c0 D 1/1

D56/1

19h47m

The show ap status command displays the mesh services attributes for an WLA and the associated BSSID of the Mesh Portal. For example: WLC# show ap status verbose AP: 1, IP-addr: 10.8.255.10 (vlan 'corp'), AP model: mp422, manufacturer: Juniper, name: AP01 ==================================================== State:

operational (not encrypt)

CPU info:

Atheros:MIPS32 speed=220000000 Hz version=AR5312, ram=16777216 s/n=111111 hw_rev=n/a

Uptime:


Uplink BSSID: 00:0b:0e:17:bb:00 Radio 1 type: 802.11g, state: configure succeed [Enabled] (802.11b protect) operational channel: 6 (Auto) operational power: 18 bssid1: 00:0b:0e:fd:fd:cc, ssid: public RFID Reports: Inactive Antenna Link Calibration: Enabled Radio 2 type: 802.11a, state: configure succeed [Enabled] operational channel: 36 operational power: 17 bssid1: 00:0b:0e:fd:fd:cd, ssid: mesh-ssid (mesh) The show mesh links command displays information about the links an WLA has to Mesh APs and Mesh Portal APs. WLC# show ap mesh-links 1 AP: 1 IP-addr: 1.1.1.3 Operational Mode: Mesh-Portal



183

Bridging:Enabled WLC# show ap mesh-links 2 AP:2 IP-addr: 1.1.1.4 Operational Mode: Mesh AP Bridging: Enabled Uplink Mesh Portal: 2049 (54 Mbps) ------------------------------------------------packets

bytes

TX:

307

44279

RX:

315

215046

Uplink Mesh Portal Candidate AP’s (* - Current Uplink Mesh Portal) Radio Mesh Portal MAC RSSI SSID ------------------------------*1 00:0b:0e:41:2d:c0 -42 mesh_services Use the show ap boot-configuration command to display information about a Mesh AP: WLC# show ap boot-configuration 7 Static Boot Configuration AP: 7 IP Address:

Disabled

VLAN Tag:

Disabled

Switch:

Disabled

Mesh:

Enabled

IP Address: Netmask: Gateway: VLAN Tag: Switch IP: Switch Name: DNS IP: Mesh SSID:mesh_services Mesh PSK:f06040b72104861a31611a854a5430dedf1c6f6d267b5e69cb13677b1a3fb93a Informational Note: For information about the fields in the output, see the Juniper Mobility System Software Command Reference

184



Configuring WLAN Outages

Configuring WLAN Outages In some network deployments, it is common to have a central network site with WLCs and remote sites with WLAs. The central and remote sites are connected by a WAN link. If the WAN link becomes unavailable, then the remote sites with WLAs should remain active and continue to provide connectivity to wireless clients. Once an outage has occurred, a periodic timer sends pings to the primary access manager (PAM) to detect when the WLC is available on the network again. This timer, called an evaluation timer, is configurable and can be used as a hold-down timer to confirm detection of the WAN outage and as a mechanism to detect when the connection is restored. A remote office can be any one of the following types of environments: Small retail store using the corporate database for inventory control and the Internet for financial transactions. Remote investment office with local servers, IP/PBX, and access to the corporate network for financial information. Remote sales office with access to the corporate network only. A temporary office at an event or exhibition with local printers and access to the corporate database across the WAN. A hotspot deployed at a retail facility, such as a coffee shop, providing Internet access only. A healthcare clinic that requires access to centralized hospital data in addition to local networking services such as printers and server.

Configuring WAN Outage using MSS To configure a WLA as a remote access point with WAN outage support, or configure the maximum duration of a WAN outage before a WLA reboots, use the set ap remote-ap wan-outage command Informational Note: For details about the set ap remote-ap wan-outage, see The Mobility System Software Command Reference.

You can use a day-hour format to set the duration. When the duration has elapsed, the WLC clears all of the WLA state and session information, and the WLA clears the session information and may reboot. In addition to configuring the extended timeout period, you can configure a timer to periodically check the state of the WLC connection on the network. During normal operation, the WLA sends announcements and pings to the WLC and receives acknowledgements in return. If the acknowledgements are not returned within a certain period, the WLA determines the status of the WLC. An initial evaluation period is used to confirm the outage and the evaluation period has a range from 25 seconds, the default value, to a maximum of 5 minutes. Once outage is confirmed, the configured evaluation period determines the keepalive interval of the pings sent to detect when the WAN link is active on the network. Copyright © 2013, Juniper Networks, Inc.

Configuring WAN Outage using MSS

185

Once the WAN link becomes available again, the WLA synchronizes the client session state with the WLC and the client sessions continue to remain active until the WLC is ready to handle new client association. However, with the introduction of Persistent Configuration feature in MSS Release 9.0, the WLAs remain active during a WAN outage. For example, this feature enables the access points to remember the configuration even after it is disconnected from the controller. This feature is available only on WLA532, WLA532E, WLA321, and WLA322.

Informational Note: You can also use Ringmaster to configure WLAs for WAN Outage. For more information see the RingMaster Configuration Guide

The following conditions apply to a WLA configured as a remote WLA: Mesh configuration is not supported. Multicast to Unicast conversion is not supported. WEP is not supported as an encryption method on WLAs in a WAN Outage configuration. WLAs cannot become active again if rebooted during a WAN outage. For example, if a WLA becomes unstable and must reboot during WAN outage, the WLA remains inactive. However, with the Persistent configuration feature support in MSS 9.0, the access points can remember their configuration once they are configured on the controller and continues to work indefinitely even after a WAN outage. The Persistent configuration feature is supported only on the access points— WLA 321, WLA322, WLA532, and WLA532E. Overlay clients do not have any connectivity during the WAN outage. As a best practice, configuring remote WLAs for DFS is not recommended. If radar is detected, the WLA shuts down, and sessions are dropped. If SNMP is configured, SNMP traps are sent when a remote WLA is in outage mode and when it returns to an active state. If remote wireless clients on a WLA need to communicate on the wireless network, it is recommended to configure local switching on the WLC. WAN outage only protects against connectivity loss between the WLA and WLC. If a remote WLA is connected to a WLC at the remote site, and the WLC is tunneled to a WLC at the main location, sessions that use the tunnel are lost if there is a connectivity issue between the two WLCs. WLAs can accept new connections during outages but this is limited to open and PSK authentication.

Configuring WLAs for WAN Outage To configure a remote WLA for the WAN Outage feature, use the following commands: WLC# set ap apnum remote-ap wan-outage mode {enable | disable} WLC# set ap auto remote-ap wan-outage mode {enable | disable}

186




To map WLAs to the remote site, use the set ap command: WLC# set ap apnum serial-number serial [remote-site site-name] model model-name To add WLAs to the remote site, create an AP list: WLC# set ap aplist remote-site site-name There are two timers that can be configured for a remote WLA. One timer sets the duration time for the WLA to be in WAN outage mode. And the second periodically checks the availability of the WLC. To set the duration of a WLA in WAN outage mode, use the following commands: WLC# set ap apnum remote-ap wan-outage extended-timeout duration WLC# set ap auto remote-ap wan-outage extended-timeout duration The variable, duration, can range from 0 to 120 hours. If the duration is 0 (zero), the WLA does not reboot and stays in outage mode indefinitely until the WAN link is re-established to the WLC. If the duration is configured between 0 (zero) and 72 hours, there is a best effort to avoid a reboot of the WLA when the WAN link is re-established to the WLA. If the duration is between 73 and 120 hours, the WLA reboots after the WLC connection is re-established because the WLA statistics are not stored for this length of time. Informational Note: If WLAs receive an IP address using DHCP, the lease time must be configured as longer than the WAN outage time. For example, if a WLA receives an IP address with a lease time of 24 hours using DHCP, and the extended outage timeout is 48 hours, the WLA does not stay in outage mode once the DHCP lease expires and a new IP address is obtained. However, it is recommended that WLAs used for Remote AP feature receive IP addresses from a local server.

You can configure the duration in day-hour format as shown in the following examples: 3 - 3 days 3d - 3 days 2d12h - 2 days 12 hours 6h - 6 hours Once the extended timeout expires, the WLC clears all WLA states and sessions. The WLA also removes any session information and reboots. The second configurable timer, eval-period, periodically checks the availability of the WLC connection. The eval-period parameter determines the interval between keepalive pings from the WLA to the WLC. It is used both as a holddown timer to confirm that the WLC is unavailable which mitigates system churn during WAN link flapping, and as a mechanism to detect when the WAN link is again available on the network. During normal operation, the WLA sends announcement packets to the WLC and receives acknowledgement of the packets from the WLC. Keepalive pings are sent to the WLC if the ack messages are missed or the WLA determines that the WLC is unavailable.



187

To enable a failover and provide new SAM link assignments before declaring the WLC is unavailable, the minimum value for the eval-period timer is 30 seconds. This allows enough time for the primary seed to react to failed PAM and SAM links and reassign new links. In order to ensure that the WLC and WLA do not remain in an inconsistent or unstable state, the maximum value for the eval-period timer is 5 minutes. You can use the following commands to configure the feature: WLC# set ap apnum remote-ap wan-outage eval-period duration WLC# set ap auto remote-ap wan-outage eval-period duration The range for the evaluation period is 5 to 86400 seconds with a default value of 300 seconds.

Roaming between WLAs at Remote Sites WLAs at a remote site need to share information when a WAN outage occurs on the WLC. Client roaming is now available at the remote site. After WLS are assigned a remote site name, a list of member WLAs is distributed between the WLAs. The distribution lists are replicated to all of the remote WLAs at the site.

Configuring Additional Remote Site Features You can configure specific SSIDs to be available only during an outage or during normal operation. If you configure the SSID to be available only during an outage, then the SSIDs become backup SSIDs for the network. To configure this feature, use the following command: WLC# set remote-site site-name backup-ssids-mode [enable | disable] To display information about a remote site, use the following command: WLC# show remote-site site-name To remove a remote site, use the clear command: WLC# clear remote-site site-name You cannot remove a remote site if WLAs are mapped to it. You must remove the WLAs first, and then remove the remote site. To remove multiple WLAs from the remote site configuration WLC# clear ap aplist remote-site site-name

Adding Limited Roaming Capabilities to the WLA The WLA implements a local session database to store information about the session locally while the WLA is in outage mode. This can be accessed by the WLA to query, read, or update information about the sessions and implemented based on the existing WLC session management database (SMDB). The entries are marked as local or foreign, if the session originated on another WLA. The foreign entries include the originating WLA IP address.

188




When a new client associates to a WLA, the WLA has data about the other WLAs who can associate with this client. Only the WLAs with data about the client receive roaming information about the client. Lookups are performed locally which allows a fast handover of a session from a WLA.

Adding Limited AAA Capability to the WLA The WLA in outage mode can process association and re-association requests, authentication, and authorization of new sessions without forwarding the requests to the WLC. The WLA performs the validity checks currently on the WLC and updates the session table accordingly.

Adding Configuration Support to the WLA The WLC sends additional configuration information to the WLA that supports WAN Outage including extended service profile information with backup SSIDs, remote site configurations, and AAA configurations.

Adding Support for 4-way Handshakes and Group Key Handshakes (GKHS) The WLA initiates the 4-way handshake message exchange with new clients joining the network. The WLA uses the 256-bit Pre-shared Key (PSK) generated from the password (PSK phrase) . The WLA also initiates the GKHS exchange, the 2-way handshake, for multicast and broadcast packets when new clients associate with the network or the GKHS timer expires.

Assigning a Different Country Code to a Remote WLA To configure a remote WLA with a different country code, use the following command: WLC# set remote-site site-name countrycode ccode APs in this remote site will get this countrycode, instead of the system/global one. This will cause the APs to reboot. Are you sure? (y/n) y Success: change accepted. Informational Note:

The country code is limited to the countries allowed by the WLA model. A WLA with -US in the model name cannot be configured for use with a different country code. However, a WLA with -WW can be configured with another country code allowed on that model.

Configuring Path MTU between a WLC and a WLA Small remote sites may require just a few users and 1 or 2 WLAs. In this scenario, the WLAs are managed by a WLC located at the central site. Since the communication between the WLC and WLA is over a WAN link, there may be a network on the route with a low MTU value which requires fragmentation of control and data packets exceeding the MTU. This fragmentation affects network performance and can cause the loss of communication between the two devices. To set the MTU fragmentation on the data path, use the following command: WLC# set remote-site site-name path-mtu [ 0 | 896 | 1024 | 1152 | 1280]



189

To configure the MTU for the data path on the WLA, use the following command: WLC# set ap apnum path-mtu [ 0 | 896 | 1024 | 1152 | 1280] The default value is 0, meaning that the parameter is not set. The WLA path-mtu value overrides the path-mtu value set for the remote site. To display the remote WLA configuration, type the following command: WLC# show ap config apnum

190




For example, to display the configuration of the remote WLA 5002, type the following command: WLC## show ap config 5002 AP 5002 (AP5002) Model: Mode: Bias: Options: Connection: Serial number: Fingerprint: Communication timeout: Extended timeout: Evaluation timeout: Location: Contact: Description: Vlan-profile: Tunnel affinity:

WLA522 remote high upgrade-firmware, led-auto network 5002 25 2h 5

The status for a remote WLA in outage mode is displayed using the following command: WLC# show ap status Flags: o= operational (219), c = configure (0), d = download (0), b = boot (0), a = auto AP, m = mesh AP, p/P = mesh portal (ena/actv), r = redundant (192), z = remote AP in outage, i = insecure, e = encrypted, u = unencrypted Radio: E = enabled - 20MHz channel, S = sentry, W/w = enabled - 40MHz wide channel (HTplus/HTminus), D = admin disabled, U = mesh uplink IP Address: * = AP behind NAT AP Flag IP Address Model MAC Address Radio 1 Radio 2 Uptime -------------------------------------------------------------------------------5002 oz-i 10.41.43.212 WLA522 00:0b:0e:50:02:00 E 1/21 E 36/18 03d05h 5003 o--1 10.41.40.56 WLA522 00:0b:0e:50:02:00 E 1/21 E 36/18 03d05h

To show details about the status of the remote WLA, use the following command: WLC# show ap status 5002 verbose AP: 5002 Name:AP5002 (remote) Model: Juniper WLA522, Rev: n/a, Serial number: 5011 F/W1: 1.0 F/W2 : 1.0 S/W : 7.5.0.0 Boot S/W: 7.5.0.0 IP-addr/mask: 10.41.46.38/255.255.248.0 (DHCP,vlan ‘NET41IP40’), Fingerprint: 8f:de:cd:8d:1e:7d:da:7b:c7:32:fe:74:57:51:af:db Port 1 MAC: 00:0b:0e:50:11:00, link 10/half, POE: 802.3af Port 2 MAC: 00:0b:0e:50:11:01, link: down, POE:802.3af State: operational (encrypted and fingerprint not verified) Remote AP: current_outage_time: 0 hours, 1 minutes, 50 seconds Uptime: 3 days, 5 hours, 12 minutes, 59 seconds



191

Remote WLA High Latency When discussing network speed, bandwidth and latency are two elements that affect network speed. Latency refers to delays typically encountered when process network data. A low latency network connection is one that has small delay times, while a high latency network typically encounters long delays. When a wireless client attempts to connect and maintain a connection to a WLA with a WLC located in a high latency network, the client association fails on the network. This may happen for two reasons: a)The wireless client waits for a response from the WLA. Because the WLA forwards the requests to the WLC, the client may time out due to the large round trip delay between the WLA and WLC. b)The WLC waits for a response from the client. Because the roundtrip delay is large, the WLC may time out before the response is returned to the client. To resolve this issue, a new feature, high latency mode, allows you to configure attributes that can mitigate the association problems on a high latency network. This feature introduces the following commands: WLC# set ap apnum high-latency-mode {enable | disable} WLC# set ap auto high-latency-mode {enable | disable}

The show command output now includes a field to indicate high latency status: WLC# show ap config verbose AP 3 (AP3) Model: WLA522 ... Connection: network High latency: enabled Serial number: 0773001007

192

Remote WLA High Latency


Enhancements to Access Points in MSS 9.0

Enhancements to Access Points in MSS 9.0 Persistent Configuration for Access Points Persistent configuration feature is an enhancement to the existing remote access point feature, which provides the ability to have the access points remember its configuration once it is configured on the controller. With this feature, the access point continues to work indefinitely without being connected to the controller. The remote sites remain connected even when an access point in the outage mode becomes unreachable to the centrally located controller and the access point reboots after the expiration of the outage expiration timer. The administrator can set extended-timeout to 0 if you do not want to access point to reboot. New clients can also join the detached access point. With the extended authorization support, the access point can authenticate sessions of new 802.1x, mac, dot1x pass-through, and last-resort sessions.

Informational Note:

This feature is supported on the following access point models: WLA532 WLA532E WLA321 WLA322.

A new command for access point is set cached-config mode. The controller sets the cache-config mode to on or off in the discovery response sent to the access point. The access point retains this setting until the next established contact with a controller. To enable cached-config on a controller for a access point, the cached-config should be configured as on when the access point is operational and also configured with remote-ap wan-outage. The existing configuration will be saved on the access point when the access point enters outage. See Figure 1–14.


Persistent Configuration for Access Points

193

Figure 1–14. Access Points in Outage mode

Access Point Discovering the Controller The access points (WLA 321, WLA322, WLA532, and WLA532E) retains the data and method which led to a successful discovery of the controller. For example, if a DNS entry is returned in DHCP Option 43, then the access point retains that information. This information is stored separately from the retained configurations so that deleting the configuration does not remove the controller discovery information. The access point retains one of the following methods to contact the controller: DNS — In a cluster, if a controller is in a different subnet, the access point uses DNS to locate the controller and requests the controller to send the IP address of the best available controller on the network. The access point then requests an image and configuration files from the best available controller. DHCP Option 43 — this option provides a list of controller IP addresses without configuring DNS servers. Static IP configuration — If DHCP is not available on the network, a distributed access point can be configured with static IP information to use as the boot device. After the access point in outage mode locates the controller, the access point updates the persistent controller discovery information. Then the access point continues in the mode sent by the controller. The access point reboots, or it gets an image, or a configuration. The access point image download mechanism has not changed from previous releases. The access point reset command has a new option that forces the controller to send a access point reboot frame to access point in outage mode. The command sends a reboot frame to a access point specified by the number and IP address. 194




The access point boot scenario now includes the following actions: If the controller is reachable by the access point at boot time, the controller has full control of the access point. If the controller is not reachable for 3 minutes at boot time, the access point boots directly using the persistent configuration stored on the access point. Cache-config is disabled by default. Only one configuration can be a persistent configuration, and multiple MSS versions are not supported. If the access point has a full file system, the flash-gbc (flash garbage collector) removes core files, backups, and log files. You must enable the following existing features to have persistent configuration work in a supported access point: Enable local switching on the access point: set remote-site remote-site name local-switching mode enable Enable access point in outage mode: set ap apnum remote-ap wan-outage mode enable Enable backup ssid mode as dual (outage-only or always-on): set service-profile service-profile name backup-ssid mode dual Enable controller polling: set remote-site remote-site name wlc-polling enable Create a VLAN profile: set vlan-profile vlan-profile name vlan vlan-name tag tag value Configure remote-site: set remote-site remote-site name Map remote site to vlan profile: set remote-site remote-site name vlan-profile vlan-profile name Enable cached config on: set remote-site remote-site name cached-config on

Supporting CLI Commands The following commands are available to support the Persistent Configuration feature: 1. To set the cached configuration mode to on for WLA35, use the following command: set ap apnum cached-config [on | off] Copyright © 2013, Juniper Networks, Inc.


195

This command enables cached configuration mode on a access point. 2. To set cached configuration to on for the remote-site satellite-lab, use the following command: set remote-site remote-site-name cached-config [on | off] This command enables cached configuration mode on a access point. 3. To force reset of access points in outage mode or not present on the controller, use the following command: reset ap [apnum | ap-list] force [ip-address] This command forces the reset of access points in outage mode or not present on the controller.

Extended Authorization Support for Access Points In order to extend support for remote access points, the access points can now act as RADIUS authenticators for sessions managed by the access points and accept mac, dot1x pass-through and last-resort connections during outage. In addition, extra functionality is added to improve the access point sessions, including certain time attributes and sharing access point managed client session information with controllers. The attributes not supported include: End Date, Start Date, and Time of Day. The access points in the remote site retain authentication fall-through settings from the controller on a SSID basis. The authentication fall-through for SSIDs is used only if the RADIUS server group is the same as the remote site RADIUS server group, and pass-through is enabled. In addition to EAP pass-through, the access point supports MAC authentication per SSID through the RADIUS server. Load balancing is not support on the access points. The access point that is enabled as a NAS accepts and responds to CoA messages from the RADIUS servers, and configured RADIUS server parameters from the controller are sent to the access point and used for authentication. In addition, the RADIUS server stores accounting information for the sessions managed by the access point, and the NAS identifier for the access point acting as a NAS is a configurable attribute per remote site. The default value is the access point name.

Informational Note:

Authentication profiles are not supported on access points in WAN outage mode.

RADIUS Client on WLA The access point acts as a RADIUS Client (NAS server) for an external RADIUS Server in order to service RADIUS authentication for WLA managed clients' sessions. When the service profile is configured to always-on, the access point acts as it is in the outage mode though it is connected to a controller. That is, the access point acts as a RADIUS client and the client traffic is switched locally by the access point. Access Point session improvements: 196

Extended Authorization Support for Access Points



Always authenticate sessions on the access point side and provide the controller (on request) with information regarding access point managed sessions. The ability to transfer session information stored on a access point to the controllers managing the remote site. Access points provide a fall-through mechanism that allows the access points to take over the management of controller authenticated sessions when the controller to access point link is down.

CLI Changes for Extended Authentication Additional commands are now available for extended authentication at remote sites: WLC# set remote-site remote-site-name radius-server-group radiusserver-group WLC# clear remote-site remote-site-name radius-server-group radiusserver-group Add or clear a RADIUS server group at a remote site. WLC# show remote-site remote-site-name Remote-site: satellite-office AP(s): 1,2,3 Vlan profile: clients Country code: US Backup SSIDs mode: Enabled Path MTU: 0 Logging server: 10.10.10.15:514 severity debug Enabled RADIUS Server Group: office-rsg (radius_1, radius_2) You can override the RADIUS attributes configured on the controller by using the following commands: WLC# set remote-site remote-site-name radius deadtime mins You can set the dead time from 0 to 1440 minutes. WLC# set remote-site remote-site-name radius timeout secs You can set the timeout from 0 to 65535 seconds. WLC# set remote-site remote-site-name radius retransmit retransmit You can set the number of retransmits from 0 to 100. WLC# set remote-site remote-site-name nas-id {ap-name|ap-serial-id}


Extended Authorization Support for Access Points

197

To display RADIUS servers visible to a access point, use the command: WLC# show remote-site remote-site-name radius ap apnum The backup-ssid mode attribute now supports always-on access point managed sessions: WLC# set service-profile profile-name backup-ssid mode {disable | dual | outage-only | always-on} A new command supports enabling or disabling controller polling: WLC# set remote-site remote-site-name wlc-polling {enable | disable} The show sessions command now includes access point managed sessions: WLC# show sessions network wla-managed [ap apnum [radio radionum]] [verbose] The clear sessions command now includes the ability to clear access point managed sessions: WLC# clear sessions network wla-managed {ap | mac-addr session-id | session-id | ssid | user | vlan}

Access Point Power Policy The access point power policy feature replaces the auto-tune transmit power feature in earlier versions of MSS and RingMaster, and addresses customer issues with the previous implementation. In dense deployments, a mechanism that allows the following features is required for setting the transmit power levels of access point radios: Facilitating good roaming decisions by setting very similar power levels between access point radios. Supporting VoIP and other clients sensitive to link balance by providing similar power levels between access point radios and client radios. Supporting client services by avoiding unnecessary power changes. Allowing an administrator to select a desired balance between signal strength and contention. The three main power tuning policies available in this feature: Maximum coverage solution—Set all the radios to maximum transmit power based on the regulatory domain limit and the access point model transmit power limitation. Cell parity power tuning—Set the same power on all radios, based on the radio capability and regulation. You can configure per-band power levels and the system accommodates these levels as allowed by regulatory constraints. For an equally spaced access point deployment, this power policy is better suited as it will not compute transmit power at run time. However, for very dense deployments, this policy may cause co-channel interference.

198

Access Point Power Policy



Maximum channel capacity tuning—This power policy automatically determines the best power levels for channel capacity, and avoids contention from other access points using the same channel. The administrator can change the parameters such as interval, minimum, and maximum power levels for the range, and the rate and degree to which power levels differ between access points in the vicinity. To configure a power policy for maximum coverage, use the following command: WLC# set radio-profile rp-name power-policy max-coverage All radios are set to the maximum transmit power permitted by the hardware and the country code. This is the default setting. To configure a cell parity power policy, sue the following command: WLC# set radio-profile rp-name power-policy cell-parity 2ghz-power 2ghz-level 5ghz-power 5ghz-level The power values for 2.4 GHz and 5 GHz are different and all radios of the same channel band are set to equal power levels as allowed by the hardware, the channel, and the country code. By default, the power level is the highest value that can be used in common by all radios under the profile. To configure the maximum channel capacity power policy, use the following commands: WLC# set radio-profile rp-name power-policy max-channel-capacity [interval minutes] [min-power min] [max-power max] [density {low | med | high}] [lockdown] In this configuration, the: Interval is the frequency at which the optimal power settings are recalculated, the default value is 10 minutes. The min-power setting places a floor under the power range that radios use when attempting to maintain power parity with each other. For instance, if the highest common power level is limited by a radio with a regulatory or hardware limit of 10 dB, and you set the min-power level to 12 dB, all radios capable of 12 dB are set to use 12dB even though it is higher than the highest common power level. If a minimum power level is configured that is higher than a configured maximum power setting, the minimum power level is rejected. If a minimum power level is configured that is higher than the upper limit of radios used by the radio profile, the configuration is accepted, but a warning is issued as displayed in the example below: set radio-profile radio1 power-policy max-channel-capacity min-power 14 Warning: some radios, on some channels, cannot set power above 10. Radios that cannot set power to 14 will set their highest permitted level.Change accepted For any power policy, setting the max-power parameter places a limit on the power levels that the access point radios are allowed to use on the network. The range is from 1 through 24, and the default value is 24. If you configure a max-power that is lower than an already-configured min-power, then the newer max-power setting is rejected.


Access Point Power Policy

199

Density is the rate and degree to which power levels differ between access points in the same vicinity. The possible values are low, medium, or high. Low indicates a small difference in power levels, the default value is medium. Lockdown variable locks down all power levels and stores the values in permanent configuration. The power policy remains the same, as explicitly configured power levels override the auto levels. In the configuration of access point radio transmit power, a new option auto is added as follows: WLC# set ap apnum radio radionum [tx-power {min | min+1 | max | auto}] The auto option indicates that the power policy settings are used. In show output, auto-tune power is replaced by power-policy as below: WLC# show radio-profile 802.11 Beacon interval: 2000

100

Max Tx lifetime:

DTIM interval: 2000

1

Max Rx lifetime:

RTS threshold: 2346

65535

Long-preamble:

disabled

Frag threshold:

11n Channel width (11na):

20MHz

Power-policy Policy:

max-coverage

Extended character support 32 characters are now supported for the names of radio profiles, port groups, and access points. However, if you downgrade to an earlier version of MSS or RingMaster, names longer than 16 characters are rejected. This feature is available on MSS and RingMaster. Mobility Domain and Cluster synchronization fails if radio profiles contain more than 16 and you attempt to synchronize with older versions of MSS.

200

Extended character support


Configuring User Encryption

Configuring User Encryption Overview Mobility System Software (MSS) encrypts wireless user traffic for all authenticated users on an encrypted SSID and then an authorized VLAN. MSS supports the following types of encryption for wireless user traffic: 802.11i Wi-Fi Protected Access (WPA) Non-WPA dynamic Wired Equivalent Privacy (WEP) Non-WPA static WEP WPA and 802.11i provide stronger security than WEP. (802.11i uses Robust Security Network (RSN), and is sometimes called WPA2.) To use WPA or RSN, a client must support the protocol. For non-WPA clients, MSS supports WEP. If your network contains a combination of WPA, RSN, clients and non-WPA clients, you can configure MSS to provide encryption for both types of clients. To configure encryption parameters for an SSID, create or edit a service profile, map the service profile to a radio profile, and add radios to the radio profile. The SSID name, advertisement setting (beaconing), and encryption settings are configured in the service profile. You can configure an SSID to support any combination of WPA, RSN, and non-WPA clients. For example, a radio can simultaneously use Temporal Key Integrity Protocol (TKIP) encryption for WPA clients and WEP encryption for non-WPA clients. The SSID type must be crypto (encrypted) for encryption to be used. If the SSID type is clear, wireless traffic is not encrypted, regardless of the encryption settings. Informational Note: MSS does not encrypt traffic in the wired part of the network. MSS does not encrypt wireless or wired traffic for users who associate with an unencrypted (clear) SSID.

Informational Note: MSS now supports mixed ciphers and you can configure ciphers per IE rather than per SSID.

Table 21 lists the encryption types supported by MSS and the default states. Table 21.

Wireless Encryption Defaults

Encryption Type

Client Support

Default State

RSN

RSN clients

Disabled

Enable the RSN information element (IE). Specify the supported cipher suites (CCMP, TKIP, 40-bit WEP, 104-bit WEP). TKIP is enabled by default when the RSN IE is enabled.

Disabled

Enable the WPA information element (IE). Specify the supported cipher suites (CCMP, TKIP, 40-bit WEP, 104-bit WEP). TKIP is enabled by default when the WPA IE is enabled.

Non-RSN clients

WPA

WPA clients Non-WPA clients


Configuration Required in MSS

Overview

201

Table 21.

Wireless Encryption Defaults (continued)

Encryption Type

Client Support

Default State

Configuration Required in MSS

Dynamic WEP

WEP clients

Enabled

None

(WPA and RSN not supported) Static WEP

WEP clients

Disabled

(WPA and RSN not supported)

Configure the static key(s). Assign keys to multicast and unicast traffic.

Figure 1–15 shows the client support when the default encryption settings are used. A radio with the default encryption settings encrypts traffic for non-WPA dynamic WEP clients but not for WPA clients or static WEP clients. The radio disassociates from these clients. Figure 1–15. Using Default Encryption

202

Overview


Configuring User Encryption Types

Configuring User Encryption Types Overview You can configure the following types of user encryption: WPA (Wi-Fi Protected Access) 802.1X RSN (802.11i) WEP (Wired Equivalent Privacy)

Configuring WPA To configure WLA access point radios to support WPA: 1. Create a service profile for each SSID that supports WPA clients. 2. Enable the WPA IE in the service profile. 3. Enable the cipher suites to support in the service profile. (TKIP is enabled by default.) Optionally, you also can change the countermeasures timer value for TKIP. 4. Map the service profile to the radio profile that controls IEEE settings for the radios. 5. Assign the radio profile to the radios and enable the radios. 6. If you plan to use PSK authentication, you also need to enable this authentication method and enter an ASCII passphrase or a hexadecimal (raw) key.

Creating a Service Profile for WPA Encryption parameters apply to all users who use the SSID configured by a service profile. To create a service profile, use the following command: set service-profile profile-name To create a new service profile named wpa, type the following command: WLC# set service-profile wpa success: change accepted.

Enabling WPA To enable WPA, you must enable the WPA information element (IE) in the service profile. To enable the WPA IE, use the following command: set service-profile profile-name wpa-ie {enable | disable} To enable WPA in service profile wpa, type the following command: WLC# set service-profile wpa wpa-ie enable success: change accepted.


Overview

203

Specifying the WPA Cipher Suites To use WPA, at least one cipher suite must be enabled. You can enable one or more of the following cipher suites: CCMP TKIP 40-bit WEP 104-bit WEP By default, TKIP is enabled and the other cipher suites are disabled. To enable or disable cipher suites, use the following commands: set service-profile name per-ie-ccmp {enable | disable} set service-profile name per-ie-tkip {enable | disable} To enable the 40-bit WEP cipher suite in service profile wpa, type the following command: WLC# set service-profile wpa per-ie-wep40 enable success: change accepted. After you type this command, the service profile supports TKIP and 40-bit WEP. Informational Note: Microsoft Windows XP does not support WEP with WPA. To configure a service profile to provide WEP for XP clients, leave WPA disabled and see “Configuring

WEP” on page 209.

Changing the TKIP Countermeasures Timer Value By default, MSS enforces TKIP countermeasures for 60,000 ms (60 seconds) after a second MIC failure within a one-minute interval. To change the countermeasures timer value, use the following command: set service-profile name tkip-mc-time wait-time To change the countermeasures wait time in service profile wpa to 30 seconds, type the following command: WLC# set service-profile wpa tkip-mc-time 30000 success: change accepted.

Enabling PSK Authentication By default, WPA uses 802.1X dynamic keying. If you plan to use static keys, you must enable PSK authentication and configure a passphrase or the raw key. You can configure the passphrase or key globally. You also can configure keys on an individual MAC client basis. By default, 802.1X authentication remains enabled when you enable PSK authentication. To enable PSK authentication, use the following command: set service-profile profile-name per-ie-psk {enable | disable} To enable PSK authentication in service profile wpa, type the following command: WLC# set service-profile wpa per-ie-psk enable success: change accepted. 204

Configuring WPA



Configuring a Global PSK Passphrase or Raw Key for All Clients To configure a global passphrase for all WPA clients, use the following command: set service-profile profile-name psk-phrase passphrase The passphrase must be from 8 to 63 characters long, including spaces. If you use spaces, you must enclose the string in quotation marks. To configure service profile wpa to use passphrase 1234567890123?=+&% The quick brown fox jumps over the lazy sl, type the following command: WLC# set service-profile wpa psk-phrase “1234567890123?=+&% The quick brown fox jumps over the lazy sl” success: change accepted. Instead of entering a passphrase, that MSS converts into a key, you can enter the key in raw hexadecimal format. To enter a PSK key in raw format, use the following command: set service-profile name psk-raw hex For hex, type a 64-bit ASCII string representing a 32-digit hexadecimal number. Enter the two-character ASCII form of each hexadecimal number. To configure service profile wpa to use a raw PSK with PSK clients, type a command such as the following: WLC# set service-profile wpa psk-raw c25d3fe4483e867d1df96eaacdf8b02451fa0836162e758100f5f6b87965e59d success: change accepted.

Disabling 802.1X Authentication for WPA To disable 802.1X authentication for WPA clients, use the following command: set service-profile name per-ie-dot1x {enable | disable}

Informational Note: his command does not disable 802.1X authentication for non-WPA clients.

To disable WPA authentication in service profile wpa, type the following command: WLC# set service-profile wpa auth-dot1x disable success: change accepted.

Displaying WPA Settings To display the WPA settings in a service profile, use the following command: show service-profile {name | ?} To display the WPA settings in effect in service profile wpa, type the following command: WLC# show service-profile wpa ssid-name: Beacon: DHCP restrict: Copyright © 2013, Juniper Networks, Inc.

private yes no

ssid-type: crypto Proxy ARP: no No broadcast: no Configuring WPA

205

Short retry limit:

5

Auth fallthru:

Long retry limit: 5

none




Custom agent-directory

Static COS:

no

CAC mode:

none

User idle timeout:

180

Keep initial vlan:

no

COS: 0 CAC sessions: 14 Idle client probing: yes Web Portal Session Timeout: 5

Web Portal ACL: WEP Key 1 value:

WEP Key 2 value:

WEP Key 3 value:

WEP Key 4 value:

WEP Unicast Index: Shared Key Auth:

1

WEP Multicast Index: 1

NO

WPA enabled: ciphers: cipher-tkip, cipher-wep40 authentication: 802.1X TKIP countermeasures time: 30000ms 11a beacon rate:

6.0


11a mandatory rate: 6.0,12.0,24.0 standard rates:9.0,18.0,36.0,48.0,54.0 11b beacon rate:

2.0



2.0


11g mandatory rate: 1.0,2.0,5.5,11.0 standard rates: 6.0,9.0,12.0,18.0,24.0, 36.0,48.0,54.0 The WPA settings appear at the bottom of the output.

Informational Note: The WPA fields appear in the show service-profile output only when WPA is enabled.

Assigning the Service Profile to Radios and Enabling the Radios After you configure WPA settings in a service profile, you can map the service profile to a radio profile, assign the radio profile to radios, and enable the radios to activate the settings. To map a service profile to a radio profile, use the following command: set radio-profile profile-name service-profile profile-name To assign a radio profile to radios and enable the radios, use the following command: set ap port-list radio {1 | 2} radio-profile profile-name mode {enable | disable}

206

Configuring WPA



To map service profile wpa to radio profile bldg1, type the following command: WLC# set radio-profile blgd1 service-profile wpa success: change accepted. To assign radio profile bldg1 to radio 1 on ports 5-8, 11-14, and 16 and enable the radios, type the following command: WLC# set ap 5-8,11-14,16 radio 1 radio-profile bldg1 mode enable success: change accepted. To assign radio profile bldg1 to radio 2 on ports 11-14 and port 16 and enable the radios, type the following command: WLC# set ap 11-14,16 radio 2 radio-profile bldg1 mode enable success: change accepted.

Configuring RSN (802.11i) Robust Security Network (RSN) provides 802.11i support. RSN uses AES encryption. You can configure a service profile to support RSN clients exclusively, or to support RSN with WPA clients, or even RSN, WPA and WEP clients. The configuration tasks for a service profile to use RSN are similar to the tasks for WPA: 1. Create a service profile for each SSID that supports RSN clients. 2. Enable the RSN IE in the service profile. 3. Enable the cipher suites to support in the service profile. (TKIP is enabled by default.) Optionally, you also can change the countermeasures timer value for TKIP. 4. Map the service profile to the radio profile that controls IEEE settings for the radios. 5. Assign the radio profile to the radios and enable the radios. If you plan to use PSK authentication, you also need to enable this authentication method and enter an ASCII passphrase or a hexadecimal (raw) key.

Creating a Service Profile for RSN Encryption parameters apply to all users who use the SSID configured by a service profile. To create a service profile, use the following command: set service-profile name To create a new service profile named rsn, type the following command: WLC# set service-profile rsn success: change accepted.

Enabling RSN To enable RSN, you must enable the RSN information element (IE) in the service profile. To enable the RSN IE, use the following command:


Configuring RSN (802.11i)

207

set service-profile name rsn-ie {enable | disable} To enable RSN in service profile wpa, type the following command: WLC# set service-profile wpa rsn-ie enable success: change accepted.

Specifying the RSN Cipher Suites To use RSN, at least one cipher suite must be enabled. You can enable one or more of the following cipher suites: CCMP TKIP 40-bit WEP 104-bit WEP By default, TKIP is enabled and the other cipher suites are disabled. To enable or disable cipher suites, use the following commands: set service-profile name per-ie-ccmp {enable | disable} set service-profile name per-ie-tkip {enable | disable} To enable the CCMP cipher suite in service profile rsn, type the following command: WLC# set service-profile rsn per-ie-ccmp enable success: change accepted. After you type this command, the service profile supports both TKIP and CCMP. Informational Note: Microsoft Windows XP does not support WEP with RSN. To configure a service profile to provide WEP for XP clients, leave RSN disabled and see “Configuring

WEP” on page 209.

Changing the TKIP Countermeasures Timer Value To change the TKIP countermeasures timer, see “Changing the TKIP Countermeasures Timer Value” on page 204. The procedure is the same for WPA and RSN.

Enabling PSK Authentication To enable PSK authentication, see “Enabling PSK Authentication” on page 204. The procedure is the same for WPA and RSN.

Displaying RSN Settings To display the RSN settings in a service profile, use the following command: show service-profile {profile-name | ?}

208

Configuring RSN (802.11i)



The RSN settings appear at the bottom of the output.

Informational Note: The RSN-related fields appear in the show service-profile output only when RSN is enabled.

Assigning the Service Profile to Radios and Enabling the Radios After you configure RSN settings in a service profile, you can map the service profile to a radio profile, assign the radio profile to radios, and enable the radios to activate the settings. To map a service profile to a radio profile, use the following command: set radio-profile profile-name service-profile profile-name To assign a radio profile to radios and enable the radios, use the following command: set ap port-list radio {1 | 2} radio-profile profile-name mode {enable | disable} To map service profile rsn to radio profile bldg2, type the following command: WLC# set radio-profile blgd2 service-profile rsn success: change accepted.

Configuring WEP Wired-Equivalent Privacy (WEP) is a security protocol defined in the 802.11 standard. WEP uses the RC4 encryption algorithm to encrypt data. To provide integrity checking, WEP access points and clients check the integrity of a frame cyclic redundancy check (CRC), generate an integrity check value (ICV), and append the value to the frame before sending it. The radio or client that receives the frame recalculates the ICV and compares the result to the ICV in the frame. If the values match, the frame is processed. If the values do not match, the frame is discarded. WEP is either dynamic or static depending on the type of encryption key generation. The WLA supports dynamic WEP and static WEP. For dynamic WEP, MSS dynamically generates keys for broadcast, multicast, and unicast traffic. MSS generates unique unicast keys for each client session and periodically regenerates (rotates) the broadcast and multicast keys for all clients. You can change or disable the broadcast or multicast rekeying interval. For static WEP, MSS uses statically configured keys typed in the WLC configuration and on the wireless client and does not rotate the keys. Dynamic WEP encryption is enabled by default. You can disable dynamic WEP support by enabling WPA and leaving the WEP-40 or WEP-104 cipher suites disabled. If you use dynamic WEP, 802.1X must also be configured on the client in addition to WEP. Static WEP encryption is disabled by default. To enable static WEP encryption, configure the static WEP keys and assign them to unicast and multicast traffic. Make sure you configure the same static keys on the clients. Copyright © 2013, Juniper Networks, Inc.

Configuring WEP

209

To support dynamic WEP in a WPA environment, enable WPA and enable the WEP-40 or WEP-104 cipher suite. (See “Configuring WPA” on page 203.) This section describes how to configure and assign static WEP keys. (To change other key-related settings, see “Managing 802.1X Encryption Keys” on page 424.) Figure 1–16 shows an example of a radio configured to provide static and dynamic WEP encryption for non-WPA clients. The radio uses dynamically generated keys to encrypt traffic for dynamic WEP clients. The radio also encrypts traffic for static WEP clients with matching keys on the radio. Figure 1–16. Encryption for Dynamic and Static WEP

Setting Static WEP Key Values MSS supports dynamic WEP automatically. To enable static WEP, configure WEP keys and assign them to unicast and multicast traffic. You can set the values of the four static WEP keys, then specify the keys to use for encrypting multicast frames and unicast frames. If you do this, MSS continues to support dynamic WEP in addition to static WEP. To set the value of a WEP key, use the following command: set service-profile profile-name wep key-index num key value The key-index num parameter specifies the index you are configuring. You can specify a value from 1 through 4.

210

Configuring WEP



The key value parameter specifies the hexadecimal value of the key. Type a 10-character ASCII string (representing a 5-byte hexadecimal number) or type a 26-character ASCII string (representing a 13-byte hexadecimal number). You can use numbers or letters. ASCII characters in the following ranges are supported: 0 to 9 A to F a to f To configure WEP key index 1 for radio profile rp1 to aabbccddee, type the following command: WLC# set service-profile rp1 wep key-index 1 key aabbccddee success: change accepted.

Assigning Static WEP Keys When static WEP is enabled, static WEP key 1 is assigned to unicast and multicast traffic by default. To assign another key to unicast or multicast traffic, use the following commands: set service-profile profile-name wep active-multicast-index num set service-profile profile-name wep active-unicast-index num The num parameter specifies the key and the value can be from 1 to 4. To configure an SSID that uses service profile wepsrvc to use WEP key index 2 for encrypting multicast traffic, type the following command: WLC# set service-profile wepsrvc wep active-multicast-index 2 success: change accepted. To configure an SSID that uses service profile wepsrvc4 to use WEP key index 4 for encrypting unicast traffic, type the following command: WLC# set service-profile wepsrvc4 wep active-unicast-index 4 success: change accepted.


Configuring WEP

211

212

Configuring WEP


Encryption Configuration Scenarios

Encryption Configuration Scenarios Overview The following scenarios provide examples of ways that you can configure encryption for network clients: “Enabling WPA with TKIP” on page 1–213 “Enabling Dynamic WEP in a WPA Network” on page 1–215 “Configuring Encryption for MAC Clients” on page 1–217

Enabling WPA with TKIP The following example shows how to configure MSS to provide authentication and TKIP encryption for 801.X WPA clients. This example assumes that pass-through authentication is used for all users. A RADIUS server group performs all authentication and authorization for the users. 1. Create an authentication rule that sends all 802.1X users of SSID mycorp in the EXAMPLE domain to the server group shorebirds for authentication. Type the following command: WLC# set authentication dot1x ssid mycorp EXAMPLE\* pass-through shorebirds 2. Create a service profile named wpa for the SSID. Type the following command: WLC# set service-profile wpa success: change accepted. 3. Set the SSID in the service profile to mycorp. Type the following command: WLC# set service-profile wpa ssid-name mycorp success: change accepted. 4. Enable WPA in service profile wpa. Type the following command: WLC# set service-profile wpa wpa-ie enable success: change accepted. TKIP is already enabled by default when WPA is enabled. 5. Display the service profile wpa to verify the changes. Type the following command: WLC# show service-profile sp1 ssid-name: Beacon: DHCP restrict: Short retry limit: Auth fallthru: Enforce SODA checks:

mycorp yes no 5 none yes

ssid-type: crypto Proxy ARP: no No broadcast: no Long retry limit: 5 Sygate On-Demand (SODA): no SODA remediation ACL:






Overview

213

Static COS:

no

CAC mode:

none

User idle timeout:

180

Keep initial vlan:

no



WEP Key 2 value:

WEP Key 3 value:

WEP Key 4 value:

WEP Unicast Index:

1

Shared Key Auth:


NO

WPA enabled: ciphers: cipher-tkip authentication: 802.1X TKIP countermeasures time: 60000ms ... 6. Map service profile wpa to radio profile rp1. Type the following commands: WLC# set radio-profile rp1 service-profile wpa success: change accepted. 7. Apply radio profile rp1 to radio 1 on port 5 and to radios 1 and 2 on port 11, enable the radios, and verify the configuration changes. Type the following commands: WLC# set ap 5,11 radio 1 radio-profile rp1 mode enable success: change accepted. WLC# set ap 11 radio 2 radio-profile rp1 mode enable success: change accepted. WLC# show ap config Port

5: AP model: mp241, POE:

enable, bias: high, name: MP05

boot-download-enable: YES force-image-download: YES Radio 1: type: 802.11a, mode: tx pwr:

enabled, channel: 36

1, profile: rp1

auto-tune max-power: default, Port



boot-download-enable: YES force-image-download: YES Radio 1: type: 802.11g, mode: tx pwr:

enabled, channel: 6

1, profile: rp1

auto-tune max-power: default Radio 2: type: 802.11a, mode: enabled, channel: 36

214

Overview



tx pwr:

1, profile: rp1

auto-tune max-power: default 8. Save the configuration. Type the following command: WLC# save config success: configuration saved.

Enabling Dynamic WEP in a WPA Network The following example shows how to configure MSS to provide authentication and encryption for 801.X dynamic WEP clients, and for 801.X WPA clients using TKIP. This example assumes that pass-through authentication is configured for all users. The commands are the same as those in “Enabling WPA with TKIP” on page 1–213, with the addition of a command to enable a WEP cipher suite. The WEP cipher suite allows authentication and encryption for both WPA and non-WPA clients that want to authenticate using dynamic WEP. 1. Create an authentication rule that sends all 802.1X users of SSID mycorp in the EXAMPLE domain to the server group shorebirds for authentication. Type the following command: WLC# set authentication dot1x ssid thiscorp EXAMPLE\* pass-through shorebirds 2. Create a service profile named wpa-wep for the SSID. Type the following command: WLC# set service-profile wpa-wep success: change accepted. 3. Set the SSID in the service profile to thiscorp. Type the following command: WLC# set service-profile wpa-wep ssid-name thiscorp success: change accepted. 4. Enable WPA in service profile wpa-wep. Type the following command: WLC# set service-profile wpa-wep wpa-ie enable success: change accepted. 5. Enable the WEP40 cipher suite in service profile wpa-wep. Type the following command: WLC# set service-profile wpa-wep cipher-wep40 enable success: change accepted. TKIP is already enabled by default when WPA is enabled. 6. Display the service profile wpa-wep to verify the changes. Type the following command: WLC# show service-profile sp1 ssid-name: Beacon: DHCP restrict: Short retry limit: Auth fallthru: Enforce SODA checks: Copyright © 2013, Juniper Networks, Inc.

mycorp yes no 5 none yes

ssid-type: crypto Proxy ARP: no No broadcast: no Long retry limit: 5 Sygate On-Demand (SODA): no SODA remediation ACL: Overview

215





Static COS:

no

CAC mode:

none

User idle timeout:

180

Keep initial vlan:

no



WEP Key 2 value:

WEP Key 3 value:

WEP Key 4 value:

WEP Unicast Index:

1

Shared Key Auth:


NO

WPA enabled: ciphers: cipher-tkip, cipher-wep40 authentication: 802.1X TKIP countermeasures time: 60000ms ... 7. Map service profile wpa-wep to radio profile rp2. Type the following commands: WLC# set radio-profile rp2 service-profile wpa-wep success: change accepted. 8. Apply radio profile rp2 to radio 1 on port 5 and to radios 1 and 2 on port 11, enable the radios, and verify the configuration changes. Type the following commands: WLC# set ap 5,11 radio 1 radio-profile rp2 mode enable success: change accepted. WLC# set ap 11 radio 2 radio-profile rp2 mode enable success: change accepted. WLC# show ap config Port





1, profile: rp2

auto-tune max-power: default Port




216

Overview

enabled, channel: 6

1, profile: rp2



auto-tune max-power: default Radio 2: type: 802.11a, mode: enabled, channel: 36 tx pwr:

1, profile: rp2


Configuring Encryption for MAC Clients The following example shows how to configure MSS to provide PSK authentication and TKIP or 40-bit WEP encryption for MAC clients: 1. Create an authentication rule that sends all MAC users of SSID voice to the local database for authentication and authorization. Type the following command: WLC# set authentication mac ssid voice * local success: configuration saved. 2. Configure a MAC user group named wpa-for-mac that assigns all MAC users in the group to VLAN blue. Type the following command: WLC# set mac-usergroup wpa-for-mac attr vlan-name blue success: configuration saved. 3. Add MAC users to MAC user group wpa-for-mac. Type the following commands: WLC# set mac-user aa:bb:cc:dd:ee:ff group wpa-for-mac success: configuration saved. WLC# set mac-user a1:b1:c1:d1:e1:f1 group wpa-for-mac success: configuration saved. 4. Verify the AAA configuration changes. Type the following command: WLC# show aaa Default Values authport=1812 acctport=1813 timeout=5 acct-timeout=5 retrans=3 deadtime=0 key=(null) author-pass=(null) Radius Servers Server

Addr

Ports


------------------------------------------------------------------Server groups Web Portal: enabled set authentication mac ssid voice * local mac-usergroup wpa-for-mac


Overview

217

vlan-name = blue mac-user aa:bb:cc:dd:ee:ff Group = wpa-for-mac mac-user a1:b1:c1:d1:e1:f1 Group = wpa-for-mac 5. Create a service profile named wpa-wep-for-mac for SSID voice. Type the following command: WLC# set service-profile wpa-wep-for-mac success: change accepted. 6. Set the SSID in the service profile to voice. Type the following command: WLC# set service-profile wpa-wep-for-mac ssid-name voice success: change accepted. 7. Enable WPA in service profile wpa-wep-for-mac. Type the following command: WLC# set service-profile wpa-wep-for-mac wpa-ie enable success: change accepted. 8. Enable the WEP40 cipher suite in service profile wpa-wep-for-mac. Type the following command: WLC# set service-profile wpa-wep-for-mac cipher-wep40 enable success: change accepted. TKIP is already enabled by default when WPA is enabled. 9. Enable PSK authentication in service profile wpa-wep-for-mac. Type the following command: WLC# set service-profile wpa-wep-for-mac auth-psk enable success: change accepted. 10. Configure a passphrase for the preshared key. Type the following command: WLC# set sce-profile wpa-wep-for-mac auth-psk enable success: changenge accepted. 11. Display the WPA configuration changes. Type the following command: WLC# show service-profile sp1 ssid-name:

voice

ssid-type:

crypto Beacon: DHCP restrict: Short retry limit: Auth fallthru: Enforce SODA checks:

no 5 none yes

Proxy ARP: no No broadcast: no Long retry limit: 5 Sygate On-Demand (SODA): no SODA remediation ACL:





Static COS: CAC mode: 218

yes

Overview

no none

COS: 0 CAC sessions: 14 Copyright © 2013, Juniper Networks, Inc.


User idle timeout:

180

Keep initial vlan:

no

Idle client probing: yes Web Portal Session Timeout: 5


WEP Key 2 value:

WEP Key 3 value:

WEP Key 4 value:

WEP Unicast Index:

1

Shared Key Auth:


NO

WPA enabled: ciphers: cipher-tkip, cipher-wep40 authentication: pre-shared key TKIP countermeasures time: 60000ms pre-shared-key: 92f99cd49e186cadee13fda7b2a2bac78975a5723a4a6b31b5b5395d6b001dbe 12. Map service profile wpa-wep-for-mac to radio profile rp3. Type the following commands: WLC# set radio-profile rp3 service-profile wpa-wep-for-mac success: change accepted. 13. Apply radio profile rp3 to radio 1 on port 4 and to radios 1 and 2 on port 6 and enable the radios, and verify the configuration changes. Type the following commands: WLC# set ap 4,6 radio 1 radio-profile rp3 mode enable success: change accepted. WLC# set ap 6 radio 2 radio-profile rp3 mode enable success: change accepted. WLC# show ap config Port

4: AP model: WLA522MP372A, POE:




1, profile: rp3

auto-tune max-power: default Port




enabled, channel: 6

1, profile: rp3

auto-tune max-power: default Radio 2: type: 802.11a, mode: enabled, channel: 36 tx pwr:

1, profile: rp3


Overview

219


220

Overview


Managing Sessions

Managing Sessions About the Session Manager A session is a related set of communication transactions between an authenticated user (client) and the specific client computer. Packets are exchanged during a session. An WLC supports the following kinds of sessions: Administrative sessions—A network administrator managing the WLC. Network sessions—A network user exchanging traffic with a network through the WLC. The WLC session manager manages the sessions for each client, but does not examine the substance of the traffic. Clearing (ending) a session deauthenticates the administrator or user from the session and disassociates wireless clients.

Displaying and Clearing Administrative Sessions 1. To display session information and statistics for a user with administrative access to the WLC, use the following command: show sessions {admin | console | mesh-ap | network | telnet} You can view all administrative sessions, or only the sessions of administrators with access to the WLC through a Telnet or SSH connection or the console port. You can also display information about administrative Telnet sessions from remote clients. 2. To clear administrative sessions, use the following command: clear sessions {admin | console | telnet client session-id}

Informational Note: Clearing administrative sessions might cause your session to be cleared.

Displaying and Clearing All WLC Administrative Sessions 1. To view information about the sessions of all administrative users, type the following command: WLC# show sessions admin Following is an example of the output of the above command. Tty

Username

Time (s)

Type

-------

--------------------

--------

----

3644

Console

tty0 tty2

tech

6

Telnet

tty3

sshadmin

381

SSH

3 admin sessions 2. To clear the sessions of all administrative users, type the following command: Copyright © 2013, Juniper Networks, Inc.

About the Session Manager

221

WLC# clear sessions admin 3. When the following prompt appears, type y, to confirm the request to clear all sessions: This will terminate manager sessions, do you wish to continue? (y|n) [n] y

Displaying and Clearing an Administrative Console Session 1. To view information about the user with administrative access to the WLC through a console plugged into the switch, type the following command: WLC# show sessions console Following is of the output of the above command: Tty

Username

Time (s)

Type

-------

--------------------

--------

----

5310

Console

tty0 1 console session

2. To clear the administrative sessions of a console user, type the following command: WLC# clear sessions console 3. When the following prompt appears, type y, to confirm the request to terminate manager sessions: This will terminate manager sessions, do you wish to continue? (y|n) [y]y

Displaying and Clearing Client Telnet Sessions 1. To view administrative sessions of Telnet clients, type the following command: WLC# show sessions telnet client Following is of the output of the above command: Session

Server Address

Server Port

Client Port

-------

--------------

------------

-----------

0

192.168.1.81

23

48000

1

10.10.1.22

23

48001

2. To clear the administrative sessions of Telnet clients, use the following command: clear sessions telnet [client [session-id]] You can clear all Telnet client sessions or a particular session. For example, the following command clears Telnet client session 1: WLC# clear sessions telnet client 1

Displaying and Clearing Mesh Sessions 1. To view current mesh sessions, use the following command: WLC# show sessions mesh-ap [session-id session-id| statistics | verbose | voice-details] 222



Managing Sessions

You can view mesh session details on a per session basis with statistics, all mesh statistics, complete details of mesh sessions, or voice configuration details. wlc1# show sessions mesh-ap 1 of 1 sessions matched Mesh ID

SessID

Type Address

Mesh-AP

AP/Radio

Number ----------------- -----------

--------------------- ----------------

00:0b:0e:5f:9d:3f

mac 00:0b:0e:5f:9d:3f

9*

1

3/2

2. To display mesh sessions on a per session basis, type the following command: *wlc1# show sessions mesh-ap session-id 9 Following is example output of the above command: 1 of 1 sessions matched Name:

00:0b:0e:5f:9d:3f

Session ID:

9

Global ID:

SESS-9-4d0d54-34702-c7b323ce

Login type:

mac

SSID:

sqa_mesh_ssid

IP:

0.0.0.0

MAC:

00:0b:0e:5f:9d:3f

AP/Radio:

3/2

State:

ACTIVE

Session tag:

2

Host name:

-

Up time:

00:04:45

Last packet rate:

54 Mb/s

Last packet RSSI:

-25 dBm

Last packet SNR:

70

Voice Queue:

IDLE

local-switching

Packets

Bytes

----------

------------

323

250930

18

2728

0

0

521

83991

Rx peak A-MSDU

0

0

Rx peak A-MPDU

0

0

Tx peak A-MSDU

0

0

Rx Unicast Rx Multicast Rx Encrypt Err Tx Unicast



223

Tx peak A-MPDU Queue

0

Tx Packets

---- Packets

0

Tx Dropped

Re-Transmit

Bytes ----------

------------

323

250930

18

2728

0

0

521

83991

Rx peak A-MSDU

0

0

Rx peak A-MPDU

0

0

Tx peak A-MSDU

0

0


Tx peak A-M Packets

Bytes

----------

------------

323

250930

18

2728

0

0

521

83991

Rx peak A-MSDU

0

0

Rx peak A-MPDU

0

0

Tx peak A-MSDU

0

0

----------

------------

323

250930

18

2728

0

0

521

83991

Rx peak A-MSDU

0

0

Rx peak A-MPDU

0

0

Tx peak A-MSDU

0

0


Tx pe Packets

Rx Dropped

Bytes


Tx peak A-MPDUak A-MPDUPDU 0

0

0

0

3. To display mesh session statistics, type the following command: wlc1# show sessions mesh-ap statistics Following is example output of the above command: 1 of 1 sessions matched

224

Name:

00:0b:0e:5f:9d:3f

Session ID:

9

SSID:

sqa_mesh_ssid



Managing Sessions

IP:

0.0.0.0

MAC:

00:0b:0e:5f:9d:3f

AP/Radio:

3/2

4. To display details of a mesh session, type the following command: wlc1# show sessions mesh-ap verbose Following is example output of the above command: 1 of 1 sessions matched Name:

00:0b:0e:5f:9d:3f

Session ID:

9

Global ID:

SESS-9-4d0d54-34702-c7b323ce

Login type:

mac

SSID:

sqa_mesh_ssid

IP:

0.0.0.0

MAC:

00:0b:0e:5f:9d:3f

AP/Radio:

3/2

State:

ACTIVE

Session tag:

2

Host name:

-

Up time:

00:05:30

local-switching

Roaming history: Switch

AP/Radio

Association time

Duration

--------------- -----------

----------------- -------------------

10.5.4.57

07/31/09 10:05:02 00:05:30

3/2

Session Start:

Fri Jul 31 10:05:02 2009 GMT

Last Auth Time:

Fri Jul 31 10:05:02 2009 GMT

Last Activity:

Fri Jul 31 10:10:18 2009 GMT

Session Timeout:

0

Idle Time-To-Live:

165

EAP Method:

NONE, using server 10.5.4.57

Protocol:

802.11

Session CAC:

disabled

Stats age:

0 seconds

Radio type:

802.11a

Last packet rate:

54 Mb/s

Last packet RSSI:

-25 dBm

Last packet SNR:

70

Voice Queue:

IDLE


( show ip https HTTPS is enabled HTTPS is set to use port 443 Last 5 Connections: IP Address

Last Connected

Last Activity (s) User

Secure

--------------- ----------------------- ----------------- ---------- -----172.16.7.84 2007/05/19 00:37:07 GMT

5076789 session

YES

172.21.36.250 2007/05/21 15:06:32 GMT

4851824 session

YES

172.21.26.91 2007/05/23 22:44:10 GMT

4651566 session

YES

172.21.26.65 2007/07/11 13:45:38 GMT

450278 session

YES


Overview

321

172.21.26.96 2007/07/16 18:48:11 GMT

125 session

YES

The command lists the TCP port number that the WLC listens for HTTPS connections. The command also lists the last 5 devices to establish HTTPS connections with the WLC, when the connections were established, last activity, user accessing through HTTPS, and if the connection is secure. If a browser connects to an WLC from behind a proxy, then only the proxy IP address is shown. If multiple browsers connect using the same proxy, the proxy address appears only once in the output.

Changing the Idle Timeout for CLI Management Sessions By default, MSS automatically terminates an console or Telnet session that is idle for more than one hour. To change the idle timeout for CLI management sessions, use the following command: set system idle-timeout seconds You can specify from 0 to 86400 seconds (one day). The default is 3600 (one hour). If you specify 0, the idle timeout is disabled. The timeout interval is in 30-second increments. For example, the interval can be 0, or 30 seconds, or 60 seconds, or 90 seconds, and so on. If you enter an interval that is not divisible by 30, the CLI rounds up to the next 30-second increment. For example, if you enter 31, the CLI rounds up to 60. This command applies to all types of CLI management sessions: console, Telnet, and SSH. The timeout change applies to existing sessions only, not to new sessions. The following command sets the idle timeout to 1800 seconds (30 minutes): WLC# set system idle-timeout 1800 success: change accepted. To reset the idle timeout to its default value, use the following command: clear system idle-timeout To display the current setting, use the show config area system command. If you are not certain whether the timeout has been changed, use the show config all command.

Setting a Message of the Day (MOTD) Banner You can configure the WLC to display a Message of the Day (MOTD) banner, a displayed string of text before the beginning of the login prompt for a CLI session. The MOTD banner can be a message to users, or legal and government-mandated warning messages. 1. To specify a MOTD banner, use the following command: set banner motd “text” The MOTD banner text can be up to 2000 alphanumeric characters in length, including tabs and carriage returns, enclosed in delimiting characters, for example double quotes (“).

Informational Note: The text cannot contain lines longer than 256 characters.

322

Changing the Idle Timeout for CLI Management Sessions


Maintaining Management Services

2. The following command sets the MOTD banner on the WLC: WLC# set banner motd “Meeting @ 4:00 p.m. in Conference Room #3” success: motd changed. 3. To display the configured MOTD banner text, use the following command: show banner motd 4. To clear the MOTD banner from the WLC configuration, use the following command: clear banner motd

Prompting the User to Acknowledge the MOTD Banner 5. Optionally, you can prompt the user to acknowledge the MOTD banner by entering y to continue. To do this, use the following commands: set banner acknowledge mode {enable | disable} set banner acknowledge message “message” The message is displayed at the end of the MOTD, and can be up to 32 characters in length. In response, the user has the option of entering y to proceed or any other key to terminate the connection. 6. The following command enables the prompt for the MOTD banner: WLC# set banner acknowledge enable success: change accepted. 7. The following command sets Do you agree? as the text to be displayed following the MOTD banner: WLC# set banner acknowledge message ‘Do you agree?’ success: change accepted. After these commands are entered, and a user logs on, the MOTD banner is displayed, followed by the text Do you agree? If the user enters y, then the login proceeds. If not, then the user is disconnected. Quotation marks can be used in the message if they are enclosed by delimiting characters. For example, to set the text “Do you agree?” (including the quotation marks) as the text to be displayed following the MOTD banner, type the following command: WLC# set banner acknowledge message ‘"Do you agree?”‘ success: change accepted.

Configuring and Managing DNS You can configure an WLC to use a Domain Name Service (DNS) server to resolve hostnames into IP addresses. This capability is useful in cases when you specify a hostname instead of an IP address in a command. For example, as an alternative to the command ping 192.168.9.1, you can enter the command ping chris.example.com. When you enter ping chris.example.com, the WLC DNS client queries a DNS server for the IP address corresponding to the hostname chris.example.com, then sends the ping request to that IP address. The DNS client on the WLC is disabled by default. To configure DNS: Copyright © 2013, Juniper Networks, Inc.

Configuring and Managing DNS

323

Enable the DNS client. Specify the IP addresses of the DNS servers. Configure a default domain name for DNS queries.

Enabling or Disabling the DNS Client The DNS client is disabled by default. To enable or disable the DNS client, use the following command: set ip dns {enable | disable}

Configuring DNS Servers You can configure an WLC to use one primary DNS server and up to five secondary DNS servers to resolve DNS queries. The WLC always sends a request to the primary DNS server first. The WLC sends a request to a secondary DNS server only if the primary DNS server does not respond.

Adding or Removing a DNS Server 1. To add a DNS server, use the following command: set ip dns server ip-addr {primary | secondary} 2. To remove a DNS server, use the following command: clear ip dns server ip-addr

Configuring a Default Domain Name You can configure a single default domain name for DNS queries. The WLC appends the default domain name to hostnames entered in commands. For example, you can configure the WLC to automatically append the domain name example.com to any hostname without a domain name. In this case, you can enter ping chris instead of ping chris.example.com, and the WLC automatically requests the DNS server to send the IP address for chris.example.com. To override the default domain name when entering a hostname in a CLI command, enter a period at the end of the hostname. For example, if the default domain name is example.com, enter chris. if the hostname is chris and not chris.example.com. Aliases take precedence over DNS. When you enter a hostname, MSS checks for an alias with that name first, before using DNS to resolve the name. Informational Note: For information about aliases, see “Configuring and Managing Aliases” on

page 1–325.

Adding or Removing the Default Domain Name Use the following steps to add or remove the default domain name 1. To add the default domain name, use the following command: set ip dns domain name

324




2. Specify a domain name of up to 64 alphanumeric characters. 3. To remove the default domain name, use the following command: clear ip dns domain

Displaying DNS Server Information To display DNS server information, use the following command: show ip dns The following example shows DNS server information on an WLC configured to use three DNS servers. WLC# show ip dns Domain Name: example.com DNS Status: enabled IP Address

Type

----------------------------------10.1.1.1

PRIMARY

10.1.1.2

SECONDARY

10.1.2.1

SECONDARY


Configuring and Managing Aliases An alias is a string that represents an IP address. You can use aliases as shortcuts in CLI commands. For example, you can configure alias pubs1 for IP address 10.10.10.20, and enter ping pubs1 as a shortcut for ping 10.10.10.20. Aliases take precedence over DNS. When you enter a hostname, the software checks for an alias with that name first, before using DNS to resolve the name.

Adding, Removing, and Displaying an Alias Use the following steps to add, remove, or display an Alias/ 1. To add an alias, use the following command: set ip alias name ip-addr 2. Specify an alias of up to 32 alphanumeric characters. 3. To add an alias HR1 for IP address 192.168.1.2, type the following command: WLC# set ip alias HR1 192.168.1.2 success: change accepted. After configuring the alias, you can use HR1 in commands in place of the IP address. For example, to ping 192.168.1.2, you can type the command ping HR1. Copyright © 2013, Juniper Networks, Inc.

Configuring and Managing Aliases

325

4. To remove an alias, use the following command: clear ip alias name 5. To display aliases, use the following command: show ip alias [name] Here is an example: WLC# show ip alias Name

IP Address

--------------------

--------------------

HR1

192.168.1.2

payroll

192.168.1.3

radius1

192.168.7.2

Configuring and Managing Time Parameters You can configure the system time and date statically or by using Network Time Protocol (NTP) servers. In each case, you can specify the offset from Coordinated Universal Time (UTC) by setting the time zone. You also can configure MSS to offset the time by an additional hour for daylight savings time or similar summertime period. Informational Note: Juniper Networks recommends that you set the time and date parameters before you install certificates on the WLC. If the WLC time and date are incorrect, the certificate may not be valid. Generally, CA-generated certificates are valid for one year beginning with the system time and date that are in effect when you generate the certificate request. Self-signed certificates generated by MSS Version 4.2.3 or later are valid for three years, beginning one week before the time and date on the WLC when the certificate is generated. If you do not install certificates, the WLC automatically generates them the first time you boot the WLC with MSS Version 4.2 or later. The automatically generated certificates are dated based on the time and date information present on the WLC when it is first booted with MSS Version 4.2 or later.

Statically setting the Time and Date Use the following steps to statically set the time and date. 1. Set the time zone (set timezone) 2. Set the summertime period (set summertime) 3. Set the time and date (set timedate)

Using NTP Servers to Set the Time and Date Use the following steps to use NTP servers to set the time and date. 1. Set the time zone (set timezone) 2. Set the summertime period (set summertime) 3. Configure NTP server information (set ntp commands)

326

Configuring and Managing Time Parameters



Setting, Displaying, and Clearing the Time Zone The time zone parameter adjusts the system date, and optionally the time, by applying an offset to UTC. 1. To set the time zone, use the following command: set timezone zone-name {-hours [minutes]} The zone name can be up to 32 alphanumeric characters long, with no spaces. The hours parameter specifies the number of hours to add to or subtract from UTC. Use a minus sign (-) in front of the hour value to subtract the hours from UTC. 2. To set the time zone to PST (Pacific Standard Time), type the following command: WLC# set timezone PST -8 Timezone is set to 'PST', offset from UTC is -8:0 hours. 3. To display the time zone, use the following command: show timezone For example, to display the time zone, type the following command: WLC# show timezone Timezone set to 'PST', offset from UTC is -8 hours 4. To clear the time zone, use the following command: clear timezone

Configuring the Summertime Period The summertime period offsets the system time +1 hour and returns it to standard time for daylight savings time or a similar summertime period that you set. Informational Note: If the date is within the summertime period, configure summertime before you set the time and date. Otherwise, the summertime adjustment sets the time incorrectly.

1. To configure the summertime period, use the following command: set summertime summername [start week weekday month hour min end week weekday month hour min] The summername can be up to 32 alphanumeric characters long, with no spaces. In addition, you can use a period (.), colon (:), underscore ( _ ), or a hyphen ( - ) in the summername.

Informational Note: The summertime name must start with an alphanumeric character.

The start and end dates and times are optional. If you do not specify a start and end time, MSS implements the time change starting at 2:00 a.m. on the first Sunday in April and ending at 2:00 a.m. on the last Sunday in October, according to the North American standard 2. To set the summertime period to PDT (Pacific Daylight Time) and use the default start and end dates and times, type the following command: Copyright © 2013, Juniper Networks, Inc.


327

WLC# set summertime PDT success: change accepted. 3. To display the summertime period, use the following command: show summertime For example, to display the summertime period, type the following command: WLC# show summertime Summertime is enabled, and set to 'PDT'. Start

: Sun Apr 04 2004, 02:00:00

End

: Sun Oct 31 2004, 02:00:00

Offset : 60 minutes Recurring : yes, starting at 2:00 am of first Sunday of April and ending at 2:00 am on last Sunday of October. Informational Note: For information about the fields in the output, see the Juniper Mobility System Software Command Reference.

4. To clear the summertime period, use the following command: clear summertime

Configuring and Managing NTP The Network Time Protocol (NTP) allows a networking device to synchronize the system time and date with the time and date on an NTP server. When used on multiple devices, NTP ensures that the time and date are consistent among those devices. The NTP implementation in MSS is based on RFC 1305, Network Time Protocol (Version 3) Specification, Implementation and Analysis. You can configure an WLC switch to consult up to three NTP servers. The WLC compares the results from the servers and selects the best response. After you enable the NTP client and configure NTP servers, MSS queries the NTP servers for an update every 64 seconds and waits 15 seconds for a reply. If the WLC does not receive a reply to an NTP query within 15 seconds, the WLC tries again up to 16 times. You can change the update interval but not the timeout or number of retries. MSS adjusts the NTP reply according to the following time parameters configured on the WLC: Offset from UTC (configured with the timezone command; see “Setting, Displaying, and Clearing the Time Zone” on page 1–327) Daylight savings time (configured with the set summertime command; see “Configuring the Summertime Period” on page 1–327)

328

Configuring and Managing NTP



The NTP client is disabled by default. Informational Note: If NTP is configured on a system whose current time differs from the NTP server time by more than 10 minutes, convergence of the WLC time may take many NTP update intervals. Juniper Networks recommends that you set the time manually to the NTP server time before enabling NTP to avoid a significant delay in convergence

Adding and Removing an NTP Server 1. To add an NTP server to the list of NTP servers, use the following command: set ntp server ip-addr 2. To configure an WLC to use NTP server 192.168.1.5, type the following command: WLC# set ntp server 192.168.1.5 3. To remove an NTP server, use the following command: clear ntp server {ip-addr | all} 4. Use the all option, to clear all NTP servers configured on the WLC.

Changing the NTP Update Interval The default update interval is 64 seconds. To change the update interval, use the following command: set ntp update-interval seconds You can specify an interval from 16 through 1024 seconds. For example, to change the NTP update interval to 128 seconds, type the following command: WLC# set ntp update-interval 128 success: change accepted.

Resetting the Update Interval to the Default To reset the update interval to the default value, use the following command: clear ntp update-interval

Enabling the NTP Client The NTP client is disabled by default. To enable the NTP client, use the following command: set ntp {enable | disable}

Displaying NTP Information To display NTP information, use the following command: show ntp Here is an example: WLC> show ntp NTP client: enabled Current update-interval: 20(secs) Copyright © 2013, Juniper Networks, Inc.


329

Current time: Sun Feb 29 2004, 23:58:12 Timezone is set to 'PST', offset from UTC is -8:0 hours. Summertime is enabled. Last NTP update: Sun Feb 29 2004, 23:58:00 NTP Server

Peer state

Local State

--------------------------------------------------192.168.1.5

SYSPEER

SYNCED

The Timezone and Summertime fields are displayed only if you change the timezone or enable summertime. Informational Note: For more information about the fields in the output, see the Juniper Mobility System Software Command Reference.

Managing the ARP Table The Address Resolution Protocol (ARP) table maps IP addresses to MAC addresses. An ARP entry enters the table in one of the following ways: Added automatically by the WLC. The WLC adds an entry for the MAC address and adds entries for addresses learned from received network traffic. When the WLC receives an IP packet, the WLC adds the packet source MAC address and source IP address to the ARP table. Added by the system administrator. You can add dynamic, static, and permanent entries to the ARP table. ARP is enabled by default on an WLC and cannot be disabled.

Displaying ARP Table Entries 1. To display ARP table entries, use the following command: show arp [ip-addr] Here is an example: WLC# show arp ARP aging time: 1200 seconds Host

HW Address

VLAN

Type

State

------------------------------ ----------------- ----- ------- --------

330

10.5.4.51

00:0b:0e:02:76:f5

1 DYNAMIC RESOLVED

10.5.4.53

00:0b:0e:02:76:f7

1 LOCAL

Managing the ARP Table

RESOLVED



This example shows two entries. The local entry (with LOCAL in the Type field) is for the WLC. The MAC address of the local entry is the WLC MAC address. The ARP table contains one local entry for each VLAN configured on the switch. The dynamic entry is obtained from traffic received by the WLC. The ARP table can also contain static and permanent entries, added by an administrator. The State field indicates whether an entry is resolved (RESOLVED) or whether MSS has sent an ARP request for the entry and is waiting for the reply (RESOLVING).

Adding an ARP Entry MSS automatically adds a local entry for an WLC and dynamic entries for addresses obtained from traffic received by the WLC. You can add the following types of entries: Dynamic—Expires based on the aging timeout. Static—Does not expire but is removed by a software reboot. Permanent—Does not expire and remains in the ARP table following a software reboot. 1. To add an ARP entry, use the following command: set arp {permanent | static | dynamic} ip-addr mac-addr To add a static ARP entry that maps IP address 10.10.10.1 to MAC address 00:bb:cc:dd:ee:ff, type the following command: WLC# set arp static 10.10.10.1 00:bb:cc:dd:ee:ff success: added arp 10.10.10.1 at 00:bb:cc:dd:ee:ff on VLAN 1

Changing the Aging Timeout The aging timeout specifies how long a dynamic entry can remain unused before the software removes the entry from the ARP table. The default aging timeout is 1200 seconds (20 minutes). The aging timeout does not affect the local entry, static entries, or permanent entries. 1. To change the aging timeout, use the following command: set arp agingtime seconds 2. You can specify from 0 to 1,000,000 seconds. To disable aging, specify 0. For example, to disable aging of dynamic ARP entries, type the following command: WLC# set arp agingtime 0 success: set arp aging time to 0 seconds

Informational Note: To reset the ARP aging timeout to the default value, use the set arp agingtime 1200 command.

Pinging Another Device 1. To verify that another device in the network can receive IP packets sent by the WLC, use the following command:


Pinging Another Device

331

ping host [count num-packets] [dnf] [flood] [interval time] [tos tos] [user user] 2. To ping a device that has IP address 10.1.1.1, type the following command: WLC# ping 10.1.1.1 PING 10.1.1.1 (10.1.1.1) from 10.9.4.34 : 56(84) bytes of data. 64 bytes from 10.1.1.1: icmp_seq=1 ttl=255 time=0.769 ms 64 bytes from 10.1.1.1: icmp_seq=2 ttl=255 time=0.628 ms 64 bytes from 10.1.1.1: icmp_seq=3 ttl=255 time=0.676 ms 64 bytes from 10.1.1.1: icmp_seq=4 ttl=255 time=0.619 ms 64 bytes from 10.1.1.1: icmp_seq=5 ttl=255 time=0.608 ms --- 10.1.1.1 ping statistics --5 packets transmitted, 5 packets received, 0 errors, 0% packet loss In this example, the ping is successful, indicating IP connectivity with the other device. Informational Note: For information about the command options, see the Juniper Mobility System Software Command Reference.

Logging Into a Remote Device From within an MSS console session or Telnet session, you can use the Telnet client to establish a Telnet client session from an WLC to another device. 1. To establish a Telnet client session with another device, use the following command: telnet {ip-addr | hostname} [port port-num] 2. To establish a Telnet session from WLC switch to 10.10.10.90, type the following command: WLC# telnet 10.10.10.90 Session 0 pty tty2.d Trying 10.10.10.90... Connected to 10.10.10.90 Disconnect character is '^t' Copyright (c) 2002, 2003 Juniper Networks, Inc. Username: When you press Ctrl+t or type exit to end the client session, the management session returns to the local WLC prompt:. WLC-remote> Session 0 pty tty2.d terminated tt name tty2.d WLC# 3. Use the following commands to manage Telnet client sessions: show sessions telnet client

332

Logging Into a Remote Device



clear sessions telnet client [session-id] These commands display and clear Telnet sessions from an WLC Telnet client to another device. 4. To display the Telnet client sessions on an WLC, type the following command: WLC# show sessions telnet client Session

Server Address

Server Port

Client Port

-------

--------------

------------

-----------

0

192.168.1.81

23

48000

1

10.10.1.22

23

48001

5. To clear Telnet client session 0, type the following command: WLC# clear sessions telnet client 0 You also can clear a Telnet client session by typing exit from within the client session.

IP Interfaces and Services Configuration Scenario This scenario configures IP interfaces, assigns the system IP address to an interface, and configures a default route, DNS parameters, and time and date parameters. 1. To configure IP interfaces on the wlc_mgmt and roaming VLANs, and verify the configuration changes, type the following commands: WLC# set interface wlc_mgmt ip 10.10.10.10/24 success: change accepted. WLC# set interface roaming ip 10.20.10.10/24 success: change accepted. WLC# show interface * = From DHCP VLAN Name

Address

Mask

Enabled State RIB

---- --------------- --------------- --------------- ------- ----- -------1 default

10.10.10.10

255.255.255.0

YES

Up

ipv4

2 roaming

10.20.10.10

255.255.255.0

YES

Up

ipv4

2. To configure the IP interface on the roaming VLAN to be the system IP address and verify the configuration change, type the following commands: WLC# set system ip-address 10.20.10.10 success: change accepted. WLC# show system =========================================================================== Product Name:

WLC

System Name:

WLC

System Countrycode: US


IP Interfaces and Services Configuration Scenario

333

System Location: System Contact: System IP:

10.02.10.10


00:0B:0E:00:04:0C

=========================================================================== Boot Time:

2000-03-18 22:59:19

Uptime:

0 days 01:12:02

=========================================================================== Fan status:


Temperature: temp1 ok

temp2 ok

temp3 ok

PSU Status:


Memory:

156.08/496.04 (31%)

Upper Power Supply missing

Total Power Over Ethernet : 105.6 =========================================================================== 3. To configure a default route through a router attached to the WLC and verify the configuration change, type the following commands: WLC# set ip route default 10.20.10.1 1 success: change accepted. WLC# show ip route Router table for IPv4 Destination/Mask

Proto

Metric NH-Type Gateway

VLAN:Interface

__________________ _______ ______ _______ _______________ _______________ 0.0.0.0/ 0 Static

1 Router

10.10.10.10/24 IP

0 Direct

10.10.10.10/32 IP vlan:1:ip:10.10.10.10/24

0 Local

10.20.10.10/24 IP

0 Direct

10.20.10.10/32 IP vlan:1:ip:10.20.10.10/24

0 Local

224.0.0.0/ 4 IP

10.20.10.1

0 Local

vlan:1:ip

vlan:1:ip

MULTICAST

Configure the DNS domain name and DNS server entries, and enable the DNS service. And verify the configuration changes. Type the following commands: WLC# set ip dns domain example.com success: change accepted. WLC# set ip dns server 10.10.10.69 PRIMARY success: change accepted. WLC# set ip dns server 10.20.10.69 SECONDARY 334




success: change accepted. WLC# set ip dns enable success: change accepted. WLC# show ip dns Domain Name: example.com DNS Status: enabled IP Address

Type

----------------------------------10.10.10.69

PRIMARY

10.20.10.69

SECONDARY

4. To configure time zone, summertime, and NTP parameters and verify the configuration changes, type the following commands: WLC# set timezone PST -8 success: change accepted. WLC# show timezone Timezone is set to 'PST', offset from UTC is -8:0 hours. WLC# set summertime PDT success: change accepted. WLC# show summertime Summertime is enabled, and set to 'PDT'. Start

: Sun Apr 04 2004, 02:00:00

End

: Sun Oct 31 2004, 02:00:00

Offset : 60 minutes Recurring : yes, starting at 2:00 am of first Sunday of April and ending at 2:00 am on last Sunday of October. WLC# set ntp server 192.168.1.5 WLC# set ntp enable success: NTP Client enabled WLC# show ntp NTP client: enabled Current update-interval: 20(secs) Current time: Sun Feb 29 2004, 23:58:12 Timezone is set to 'PST', offset from UTC is -8:0 hours. Summertime is enabled. Last NTP update: Sun Feb 29 2004, 23:58:00 NTP Server

Peer state

Local State

---------------------------------------------------



335

192.168.1.5

SYSPEER

SYNCED

WLC# show timedate Sun Feb 29 2004, 23:59:02 PST 5. To save the configuration, type the following command: WLC# save config success: configuration saved.

336




Configuring and Managing DNS You can configure an WLC to use a Domain Name Service (DNS) server to resolve hostnames into IP addresses. This capability is useful in cases when you specify a hostname instead of an IP address in a command. For example, as an alternative to the command ping 192.168.9.1, you can enter the command ping chris.example.com. When you enter ping chris.example.com, the WLC DNS client queries a DNS server for the IP address corresponding to the hostname chris.example.com, then sends the ping request to that IP address. The DNS client on the WLC is disabled by default. To configure DNS: Enable the DNS client. Specify the IP addresses of the DNS servers. Configure a default domain name for DNS queries.

Enabling or Disabling the DNS Client The DNS client is disabled by default. To enable or disable the DNS client, use the following command: set ip dns {enable | disable}

Configuring DNS Servers You can configure an WLC to use one primary DNS server and up to five secondary DNS servers to resolve DNS queries. The WLC always sends a request to the primary DNS server first. The WLC sends a request to a secondary DNS server only if the primary DNS server does not respond.

Adding or Removing a DNS Server To add a DNS server, use the following command: set ip dns server ip-addr {primary | secondary} To remove a DNS server, use the following command: clear ip dns server ip-addr

Configuring a Default Domain Name You can configure a single default domain name for DNS queries. The WLC appends the default domain name to hostnames entered in commands. For example, you can configure the WLC to automatically append the domain name example.com to any hostname without a domain name. In this case, you can enter ping chris instead of ping chris.example.com, and the WLC automatically requests the DNS server to send the IP address for chris.example.com. To override the default domain name when entering a hostname in a CLI command, enter a period at the end of the hostname. For example, if the default domain name is example.com, enter chris. if the hostname is chris and not chris.example.com.


337

Aliases take precedence over DNS. When you enter a hostname, MSS checks for an alias with that name first, before using DNS to resolve the name. Informational Note: For information about aliases, see “Configuring and Managing Aliases” on

page 338.

Adding or Removing the Default Domain Name Use the following steps to add or remove the default domain name 1. To add the default domain name, use the following command: set ip dns domain name 2. Specify a domain name of up to 64 alphanumeric characters. 3. To remove the default domain name, use the following command: clear ip dns domain

Displaying DNS Server Information To display DNS server information, use the following command: show ip dns The following example shows DNS server information on an WLC configured to use three DNS servers. WLC# show ip dns Domain Name: example.com DNS Status: enabled IP Address

Type

----------------------------------10.1.1.1

PRIMARY

10.1.1.2

SECONDARY

10.1.2.1

SECONDARY


Configuring and Managing Aliases An alias is a string that represents an IP address. You can use aliases as shortcuts in CLI commands. For example, you can configure alias pubs1 for IP address 10.10.10.20, and enter ping pubs1 as a shortcut for ping 10.10.10.20. Aliases take precedence over DNS. When you enter a hostname, the software checks for an alias with that name first, before using DNS to resolve the name.

338

Configuring and Managing Aliases



Adding, Removing, and Displaying an Alias Use the following steps to add, remove, or display an Alias/ 1. To add an alias, use the following command: set ip alias name ip-addr 2. Specify an alias of up to 32 alphanumeric characters. 3. To add an alias HR1 for IP address 192.168.1.2, type the following command: WLC# set ip alias HR1 192.168.1.2 success: change accepted. After configuring the alias, you can use HR1 in commands in place of the IP address. For example, to ping 192.168.1.2, you can type the command ping HR1. 4. To remove an alias, use the following command: clear ip alias name 5. To display aliases, use the following command: show ip alias [name] Here is an example: WLC# show ip alias Name

IP Address

--------------------

--------------------

HR1

192.168.1.2

payroll

192.168.1.3

radius1

192.168.7.2

Managing the ARP Table The Address Resolution Protocol (ARP) table maps IP addresses to MAC addresses. An ARP entry enters the table in one of the following ways: Added automatically by the WLC. The WLC adds an entry for the MAC address and adds entries for addresses learned from received network traffic. When the WLC receives an IP packet, the WLC adds the packet source MAC address and source IP address to the ARP table. Added by the system administrator. You can add dynamic, static, and permanent entries to the ARP table. ARP is enabled by default on an WLC and cannot be disabled.

Displaying ARP Table Entries 1. To display ARP table entries, use the following command: show arp [ip-addr] Here is an example:



339

WLC# show arp ARP aging time: 1200 seconds Host

HW Address

VLAN

Type

State

------------------------------ ----------------- ----- ------- -------10.5.4.51

00:0b:0e:02:76:f5

1 DYNAMIC RESOLVED

10.5.4.53

00:0b:0e:02:76:f7

1 LOCAL

RESOLVED

This example shows two entries. The local entry (with LOCAL in the Type field) is for the WLC. The MAC address of the local entry is the WLC MAC address. The ARP table contains one local entry for each VLAN configured on the switch. The dynamic entry is obtained from traffic received by the WLC. The ARP table can also contain static and permanent entries, added by an administrator. The State field indicates whether an entry is resolved (RESOLVED) or whether MSS has sent an ARP request for the entry and is waiting for the reply (RESOLVING).

Adding an ARP Entry MSS automatically adds a local entry for an WLC and dynamic entries for addresses obtained from traffic received by the WLC. You can add the following types of entries: Dynamic—Expires based on the aging timeout. Static—Does not expire but is removed by a software reboot. Permanent—Does not expire and remains in the ARP table following a software reboot. 1. To add an ARP entry, use the following command: set arp {permanent | static | dynamic} ip-addr mac-addr To add a static ARP entry that maps IP address 10.10.10.1 to MAC address 00:bb:cc:dd:ee:ff, type the following command: WLC# set arp static 10.10.10.1 00:bb:cc:dd:ee:ff success: added arp 10.10.10.1 at 00:bb:cc:dd:ee:ff on VLAN 1

Changing the Aging Timeout The aging timeout specifies how long a dynamic entry can remain unused before the software removes the entry from the ARP table. The default aging timeout is 1200 seconds (20 minutes). The aging timeout does not affect the local entry, static entries, or permanent entries. 1. To change the aging timeout, use the following command: set arp agingtime seconds 2. You can specify from 0 to 1,000,000 seconds. To disable aging, specify 0. For example, to disable aging of dynamic ARP entries, type the following command: WLC# set arp agingtime 0

340




success: set arp aging time to 0 seconds

Informational Note: To reset the ARP aging timeout to the default value, use the set arp agingtime 1200 command.

Pinging Another Device 1. To verify that another device in the network can receive IP packets sent by the WLC, use the following command: ping host [count num-packets] [dnf] [flood] [interval time] [tos tos] [user user] 2. To ping a device that has IP address 10.1.1.1, type the following command: WLC# ping 10.1.1.1 PING 10.1.1.1 (10.1.1.1) from 10.9.4.34 : 56(84) bytes of data. 64 bytes from 10.1.1.1: icmp_seq=1 ttl=255 time=0.769 ms 64 bytes from 10.1.1.1: icmp_seq=2 ttl=255 time=0.628 ms 64 bytes from 10.1.1.1: icmp_seq=3 ttl=255 time=0.676 ms 64 bytes from 10.1.1.1: icmp_seq=4 ttl=255 time=0.619 ms 64 bytes from 10.1.1.1: icmp_seq=5 ttl=255 time=0.608 ms --- 10.1.1.1 ping statistics --5 packets transmitted, 5 packets received, 0 errors, 0% packet loss In this example, the ping is successful, indicating IP connectivity with the other device. Informational Note: For information about the command options, see the Juniper Mobility System Software Command Reference.

Logging Into a Remote Device From within an MSS console session or Telnet session, you can use the Telnet client to establish a Telnet client session from an WLC to another device. 1. To establish a Telnet client session with another device, use the following command: telnet {ip-addr | hostname} [port port-num] 2. To establish a Telnet session from WLC switch to 10.10.10.90, type the following command: WLC# telnet 10.10.10.90 Session 0 pty tty2.d Trying 10.10.10.90... Connected to 10.10.10.90 Disconnect character is '^t' Copyright (c) 2002, 2003 Copyright © 2013, Juniper Networks, Inc.

Pinging Another Device

341

Juniper Networks, Inc. Username: When you press Ctrl+t or type exit to end the client session, the management session returns to the local WLC prompt:. WLC-remote> Session 0 pty tty2.d terminated tt name tty2.d WLC# 3. Use the following commands to manage Telnet client sessions: show sessions telnet client clear sessions telnet client [session-id] These commands display and clear Telnet sessions from an WLC Telnet client to another device. 4. To display the Telnet client sessions on an WLC, type the following command: WLC# show sessions telnet client Session

Server Address

Server Port

Client Port

-------

--------------

------------

-----------

0

192.168.1.81

23

48000

1

10.10.1.22

23

48001

5. To clear Telnet client session 0, type the following command: WLC# clear sessions telnet client 0 You also can clear a Telnet client session by typing exit from within the client session.

IP Interfaces and Services Configuration Scenario This scenario configures IP interfaces, assigns the system IP address to an interface, and configures a default route, DNS parameters, and time and date parameters. 1. To configure IP interfaces on the wlc_mgmt and roaming VLANs, and verify the configuration changes, type the following commands: WLC# set interface wlc_mgmt ip 10.10.10.10/24 success: change accepted. WLC# set interface roaming ip 10.20.10.10/24 success: change accepted. WLC# show interface * = From DHCP VLAN Name

Address

Mask

Enabled State RIB

---- --------------- --------------- --------------- ------- ----- --------

342

1 default

10.10.10.10

255.255.255.0

YES

Up

ipv4

2 roaming

10.20.10.10

255.255.255.0

YES

Up

ipv4




2. To configure the IP interface on the roaming VLAN to be the system IP address and verify the configuration change, type the following commands: WLC# set system ip-address 10.20.10.10 success: change accepted. WLC# show system =========================================================================== Product Name:

WLC

System Name:

WLC


10.02.10.10


00:0B:0E:00:04:0C

=========================================================================== Boot Time:

2000-03-18 22:59:19

Uptime:

0 days 01:12:02

=========================================================================== Fan status:



temp2 ok

temp3 ok

PSU Status:


Memory:

156.08/496.04 (31%)


Total Power Over Ethernet : 105.6 =========================================================================== 3. To configure a default route through a router attached to the WLC and verify the configuration change, type the following commands: WLC# set ip route default 10.20.10.1 1 success: change accepted. WLC# show ip route Router table for IPv4 Destination/Mask

Proto

Metric NH-Type Gateway

VLAN:Interface

__________________ _______ ______ _______ _______________ _______________ 0.0.0.0/ 0 Static

1 Router

10.10.10.10/24 IP

0 Direct

10.10.10.10/32 IP vlan:1:ip:10.10.10.10/24

0 Local

10.20.10.10/24 IP

0 Direct


10.20.10.1 vlan:1:ip

vlan:1:ip


343

10.20.10.10/32 IP vlan:1:ip:10.20.10.10/24

0 Local

224.0.0.0/ 4 IP

0 Local

MULTICAST

Configure the DNS domain name and DNS server entries, and enable the DNS service. And verify the configuration changes. Type the following commands: WLC# set ip dns domain example.com success: change accepted. WLC# set ip dns server 10.10.10.69 PRIMARY success: change accepted. WLC# set ip dns server 10.20.10.69 SECONDARY success: change accepted. WLC# set ip dns enable success: change accepted. WLC# show ip dns Domain Name: example.com DNS Status: enabled IP Address

Type

----------------------------------10.10.10.69

PRIMARY

10.20.10.69

SECONDARY


: Sun Apr 04 2004, 02:00:00

End

: Sun Oct 31 2004, 02:00:00

Offset : 60 minutes Recurring : yes, starting at 2:00 am of first Sunday of April and ending at 2:00 am on last Sunday of October. WLC# set ntp server 192.168.1.5 WLC# set ntp enable success: NTP Client enabled 344




WLC# show ntp NTP client: enabled Current update-interval: 20(secs) Current time: Sun Feb 29 2004, 23:58:12 Timezone is set to 'PST', offset from UTC is -8:0 hours. Summertime is enabled. Last NTP update: Sun Feb 29 2004, 23:58:00 NTP Server

Peer state

Local State

--------------------------------------------------192.168.1.5

SYSPEER

SYNCED

WLC# show timedate Sun Feb 29 2004, 23:59:02 PST 5. To save the configuration, type the following command: WLC# save config success: configuration saved.



345

346




Configuring and Managing Time Parameters Overview You can configure the system time and date statically or by using Network Time Protocol (NTP) servers. In each case, you can specify the offset from Coordinated Universal Time (UTC) by setting the time zone. You also can configure MSS to offset the time by an additional hour for daylight savings time or similar summertime period. Informational Note: Juniper Networks recommends that you set the time and date parameters before you install certificates on the WLC. If the WLC time and date are incorrect, the certificate may not be valid. Generally, CA-generated certificates are valid for one year beginning with the system time and date that are in effect when you generate the certificate request. Self-signed certificates generated by MSS Version 4.2.3 or later are valid for three years, beginning one week before the time and date on the WLC when the certificate is generated. If you do not install certificates, the WLC automatically generates them the first time you boot the WLC with MSS Version 4.2 or later. The automatically generated certificates are dated based on the time and date information present on the WLC when it is first booted with MSS Version 4.2 or later.

Statically setting the Time and Date Use the following steps to statically set the time and date. 1. Set the time zone (set timezone) 2. Set the summertime period (set summertime) 3. Set the time and date (set timedate)

Using NTP Servers to Set the Time and Date Use the following steps to use NTP servers to set the time and date. 1. Set the time zone (set timezone) 2. Set the summertime period (set summertime) 3. Configure NTP server information (set ntp commands)

Setting, Displaying, and Clearing the Time Zone The time zone parameter adjusts the system date, and optionally the time, by applying an offset to UTC. 1. To set the time zone, use the following command: set timezone zone-name {-hours [minutes]} The zone name can be up to 32 alphanumeric characters long, with no spaces. The hours parameter specifies the number of hours to add to or subtract from UTC. Use a minus sign (-) in front of the hour value to subtract the hours from UTC. 2. To set the time zone to PST (Pacific Standard Time), type the following command: WLC# set timezone PST -8


Overview

347

Timezone is set to 'PST', offset from UTC is -8:0 hours. 3. To display the time zone, use the following command: show timezone For example, to display the time zone, type the following command: WLC# show timezone Timezone set to 'PST', offset from UTC is -8 hours 4. To clear the time zone, use the following command: clear timezone

Configuring the Summertime Period The summertime period offsets the system time +1 hour and returns it to standard time for daylight savings time or a similar summertime period that you set. Informational Note: If the date is within the summertime period, configure summertime before you set the time and date. Otherwise, the summertime adjustment sets the time incorrectly.

1. To configure the summertime period, use the following command: set summertime summername [start week weekday month hour min end week weekday month hour min] The summername can be up to 32 alphanumeric characters long, with no spaces. In addition, you can use a period (.), colon (:), underscore ( _ ), or a hyphen ( - ) in the summername.

Informational Note: The summertime name must start with an alphanumeric character.

The start and end dates and times are optional. If you do not specify a start and end time, MSS implements the time change starting at 2:00 a.m. on the first Sunday in April and ending at 2:00 a.m. on the last Sunday in October, according to the North American standard 2. To set the summertime period to PDT (Pacific Daylight Time) and use the default start and end dates and times, type the following command: WLC# set summertime PDT success: change accepted. 3. To display the summertime period, use the following command: show summertime For example, to display the summertime period, type the following command: WLC# show summertime Summertime is enabled, and set to 'PDT'.

348

Start

: Sun Apr 04 2004, 02:00:00

End

: Sun Oct 31 2004, 02:00:00

Overview



Offset : 60 minutes Recurring : yes, starting at 2:00 am of first Sunday of April and ending at 2:00 am on last Sunday of October. Informational Note: For information about the fields in the output, see the Juniper Mobility System Software Command Reference.

4. To clear the summertime period, use the following command: clear summertime

Configuring and Managing NTP The Network Time Protocol (NTP) allows a networking device to synchronize the system time and date with the time and date on an NTP server. When used on multiple devices, NTP ensures that the time and date are consistent among those devices. The NTP implementation in MSS is based on RFC 1305, Network Time Protocol (Version 3) Specification, Implementation and Analysis. You can configure an WLC switch to consult up to three NTP servers. The WLC compares the results from the servers and selects the best response. After you enable the NTP client and configure NTP servers, MSS queries the NTP servers for an update every 64 seconds and waits 15 seconds for a reply. If the WLC does not receive a reply to an NTP query within 15 seconds, the WLC tries again up to 16 times. You can change the update interval but not the timeout or number of retries. MSS adjusts the NTP reply according to the following time parameters configured on the WLC: Offset from UTC (configured with the timezone command; see “Setting, Displaying, and Clearing the Time Zone” on page 1–347) Daylight savings time (configured with the set summertime command; see “Configuring the Summertime Period” on page 1–348) The NTP client is disabled by default. Informational Note: If NTP is configured on a system whose current time differs from the NTP server time by more than 10 minutes, convergence of the WLC time may take many NTP update intervals. Juniper Networks recommends that you set the time manually to the NTP server time before enabling NTP to avoid a significant delay in convergence

Adding and Removing an NTP Server 1. To add an NTP server to the list of NTP servers, use the following command: set ntp server ip-addr 2. To configure an WLC to use NTP server 192.168.1.5, type the following command: WLC# set ntp server 192.168.1.5 3. To remove an NTP server, use the following command:



349

clear ntp server {ip-addr | all} 4. Use the all option, to clear all NTP servers configured on the WLC.

Changing the NTP Update Interval The default update interval is 64 seconds. To change the update interval, use the following command: set ntp update-interval seconds You can specify an interval from 16 through 1024 seconds. For example, to change the NTP update interval to 128 seconds, type the following command: WLC# set ntp update-interval 128 success: change accepted.

Resetting the Update Interval to the Default To reset the update interval to the default value, use the following command: clear ntp update-interval

Enabling the NTP Client The NTP client is disabled by default. To enable the NTP client, use the following command: set ntp {enable | disable}

Displaying NTP Information To display NTP information, use the following command: show ntp Here is an example: WLC> show ntp NTP client: enabled Current update-interval: 20(secs) Current time: Sun Feb 29 2004, 23:58:12 Timezone is set to 'PST', offset from UTC is -8:0 hours. Summertime is enabled. Last NTP update: Sun Feb 29 2004, 23:58:00 NTP Server

Peer state

Local State

--------------------------------------------------192.168.1.5

350


SYSPEER

SYNCED



The Timezone and Summertime fields are displayed only if you change the timezone or enable summertime. Informational Note: For more information about the fields in the output, see the Juniper Mobility System Software Command Reference.


: Sun Apr 04 2004, 02:00:00

End

: Sun Oct 31 2004, 02:00:00

Offset : 60 minutes Recurring : yes, starting at 2:00 am of first Sunday of April and ending at 2:00 am on last Sunday of October. WLC# set ntp server 192.168.1.5 WLC# set ntp enable success: NTP Client enabled WLC# show ntp NTP client: enabled Current update-interval: 20(secs) Current time: Sun Feb 29 2004, 23:58:12 Timezone is set to 'PST', offset from UTC is -8:0 hours. Summertime is enabled. Last NTP update: Sun Feb 29 2004, 23:58:00 NTP Server

Peer state

Local State

--------------------------------------------------192.168.1.5

SYSPEER

SYNCED

WLC# show timedate Sun Feb 29 2004, 23:59:02 PST 6. To save the configuration, type the following command: Copyright © 2013, Juniper Networks, Inc.


351

WLC# save config success: configuration saved.

352



Configuring and Managing Ports

Configuring and Managing Ports Overview You can configure and display information for the following port parameters: Port type Name Speed and autonegotiation Port state Power over Ethernet (PoE) state Load sharing

Setting the Port Type An WLC port can be one of the following types: Network port — A network port is a Layer 2 switch port connecting the WLC to other networking devices such as switches and routers. WLA port — An WLA connects the WLC to an WLA. The port also can provide power to the WLA. Wireless users are authenticated on the network through an WLA port. Informational Note: A Distributed WLA, which is connected to WLC switches through intermediate Layer 2 or Layer 3 networks, does not use an WLA access port. To configure for a Distributed WLA, see “Configuring an WLA Connection” on page 355 and “Configuring WLA Points” on page 71

Wired authentication port — A wired authentication port connects the WLC to user devices, such as workstations, that must authenticate in order to access the network. All WLC ports are network ports by default. You must set the port type for ports directly connected to WLAs and for ports on wired user stations that must authenticate in order to access the network. When you change port type, MSS applies default settings appropriate for the port type. Table 2 lists the default settings applied for each port type. For example, the WLA column lists default settings that MSS applies when you change a port type to ap (an WLA access point). Table 2.

Port Defaults Set By Port Type Change Port type

Parameter

WLA Access


Network

VLAN membership

Removed from all VLANs. You cannot assign an WLA access port to a VLAN. MSS automatically assigns WLA access ports to VLANs based on user traffic.

Removed from all VLANs. You cannot assign a wired authentication port to a VLAN. MSS automatically assigns wired authentication ports to VLANs based on user traffic.

None


If you clear a port, MSS resets the port as a network port but does not add the port back to any VLANs. You must explicitly add the port to the desired VLAN(s).

Overview

353

Table 2.

Port Defaults Set By Port Type Change (continued) Port type

Parameter

WLA Access


Network

Spanning Tree Protocol (STP)

Not applicable

Not applicable

Based on the STP states of the VLANs for the port.

802.1X

Uses authentication parameters configured for users.

Uses authentication parameters configured for users.

No authentication.

Port groups

Not applicable

Not applicable

None

IGMP snooping

Enabled as users are authenticated and join VLANs.

Enabled as users are Enabled as the port is added to authenticated and join VLANs. VLANs.

Maximum user sessions

Not applicable

1 (one)

Not applicable

Table 3 lists how many WLAs you can configure on an WLC, and the number of WLAs that a WLC can boot up. The numbers are for directly connected and Distributed WLAs combined. Table 3.

Maximum WLAs Supported Per WLC

WLC Model

Maximum Configured

Maximum Booted

WLC2800

2048

512, depending on the license level

WLC200

768

up to 192, depending on the license leve

WLC880

2048

256, depending on the license leve

WLC800

512

128, depending on the license leve

WLC8

48

12

WLC2

16

4

Setting a Port for a Directly Connected WLA Informational Note: Before configuring a port as an WLA access port, you must use the set system countrycode command to set the IEEE 802.11 country-specific regulations on the WLC. (See “Country of Operation” on page 72.)

Some MSS features require a port number to be specified for directly connected WLAs. For this purpose, you can optionally specify the port number attached to a directly connected WLA. To set a port for an WLA, use the following command: set ap port model {2330 | 2330A | 2330B | 2332-A1 |AP-EASYA | AP1602 |AP1602C|AP2750 | AP3750 | AP3850 | AP3950 |AP3950| MP371 | MP371B| | MP372 | MP-372A| | MP372B |MP422 | MP422A |MP422B| MP422F |MP422FB | MP432 | MP432F | MP-522 | MP-522E | MP620 | MP620A | MP620B | MP622 | WLA532-US |MP-632F | MP-71 | MP-82 | WLA321-US | WLA322-US | WLA522-US | WLA522E-US | WLA532-US | WLA532E-US | WLA632-US} poe {enable | disable} [radiotype {11a | 11b| 11g}]

354

Setting the Port Type



You must specify a port list of one or more port numbers, the WLA model number, and the PoE state. (For details about port lists, see “Port Lists” on page 21.) The MP371 has a single radio that can be configured for 802.11a or 802.11b/g. Other WLA models have two radios. On two-radio models, one radio is always 802.11a. The other radio is 802.11b/g, but can be configured for 802.11b or 802.11g exclusively. If the country of operation specified by the set system countrycode command does not allow 802.11g, the default is 802.11b. Informational Note: Models MP-52, MP241, MP-422, MP262, MP341, MP352, MP-372, MP-371, MP-82, and MP-71 have been discontinued but are still supported by the command.

Informational Note: You cannot configure any gigabit Ethernet port, or port 7 or 8 on an WLC8, or port 1 on an WLCR2, or port 3 on an WLC200, as an WLA port. To manage an WLA on a WLC model that does not have 10/100 Ethernet ports, configure a Distributed WLA connection on the WLC. (See “Configuring an WLA Connection” on page 355.)

The radios for the MP620 and WLA632 require external antennas, and the following models have internal antennas but also have connectors for optional use of external antennas: MP372, MP372-JP, AP3750, AP3850, 2330, and 2330A. (Antenna support on a specific model is limited to the antennas certified for use with that model.) To specify the antenna model, use the set ap radio antennatype command. To set ports 4 through 6 for an WLA532-US and enable PoE on the ports, type the following command: WLC# set ap 1 port 4-6 model WLA532-US poe enable This may affect the power applied on the configured ports. Would you like to continue? (y/n) [n]y success: change accepted. Informational Note: Additional configuration is required to place an WLA into operation. For information, see

“Configuring WLA Points” on page 71.

Configuring an WLA Connection To configure a connection for an WLA (referred to as an AP in the CLI), use the following command: set ap apnum serial-id serial-ID model {2330 | 2330A | 2330B | 2332-A1 | AP2750 | AP3750 | AP3850 | AP1602 || AP1602C| AP3950 | MP71 | MP371 | MP371B| MP372A | MP372A | MP372-JP | MP372B | MP422 |MP422A |MP422B| MP422F |MP422FB |MP432 | MP432F | MP620 | MP620A | MP620B | MP622| WLA532-US| MP82} poe {enable | disable} [radiotype {11a | 11b| 11g}] The variable refers to an index value that identifies the WLA on the WLC. This value is not related to the port connected to the WLA. The apnum can have a value from 1-9999. For the serial-id parameter, specify the serial number of the WLA. The serial number is listed on the WLA case. To display the serial number using the CLI, use the show version details command. To configure a connection for WLA 1, which is an WLA model WLA522 with serial-ID 0322199999, type the following command: Copyright © 2013, Juniper Networks, Inc.


355

WLC# set ap 1 serial-id 0322199999 model WLA522 success: change accepted.

Setting a Port for a Wired Authentication Use To set a port for a wired authentication user, use the following command: set port type wired-auth port-list [tag tag-list] [max-sessions num] [auth-fall-thru {last-resort | none | web-portal}] [idle-timeout idle-timeout][web-portal-form url] You must specify a port list. Optionally, you also can specify a tag-list to subdivide the port into virtual ports, set the maximum number of simultaneous user sessions that can be active on the port, and change the fallthru authentication type. You can also specify how long the user is idle before the connection is terminated. You can configure a value (in seconds) of 20 to 86400 seconds. The default value is 300 seconds.

Informational Note: It is also possible to configure a URL for a customized Web Portal Login page.

By default, one user session can be active on the port at a time. The fallthru authentication type is used if the user does not support 802.1X and is not authenticated by MAC authentication. The default is none, and the user is automatically denied access if neither 802.1X authentication or MAC authentication is successful. To set port 17 as a wired authentication port, type the following command: WLC# set port type wired-auth 17 success: change accepted This command configures port 17 as a wired authentication port supporting one interface and one simultaneous user session. For 802.1X clients, wired authentication works if the clients are directly attached to the wired authentication port, or are attached through a hub that does not block forwarding of packets from the client to the PAE group address (01:80:c2:00:00:03). Wired authentication works in accordance with the 802.1X specification, which prohibits a client from sending traffic directly to an authenticator MAC address until the client is authenticated, because it is possible for multiple authenticators to acquire the same client. Instead of sending traffic to the authenticator MAC address, the client sends packets to the PAE group address. For non-802.1X clients, who use MAC authentication, WebAAA, or last-resort authentication, wired authentication works if the clients are directly or indirectly attached. Informational Note: If clients are connected to a wired authentication port through a downstream third-party switch, the WLC attempts to authenticate based on any traffic coming from the WLC, such as Spanning Tree Protocol (STP) BPDUs. In this case, disable repetitive traffic emissions such as STP BPDUs from downstream switches. If you want to provide a management path to a downstream switch, use MAC authentication.

356




Clearing a Port Warning: When you clear a port, user sessions are cleared from the port.

To change a port type from WLA access port or wired authentication port, you must first clear the port, then set the port type. Clearing a port removes all of the port configuration settings and resets the port as a network port. If the port is an WLA, clearing the port disables PoE and 802.1X authentication. If the port is a wired authenticated port, clearing the port disables 802.1X authentication. If the port is a network port, the port must first be removed from all VLANs, which removes the port from all spanning trees, load-sharing port groups, and so on.

Informational Note: A cleared port is not placed in any VLANs, not even the default VLAN (VLAN 1).

To clear a port, use the following command: clear port type port-list For example, to clear the port settings from port 5 and reset the port as a network port, type the following command: WLC# clear port type 5 This may disrupt currently authenticated users. Are you sure? (y/n) [n]y success: change accepted.

Clearing a Distributed WLA Warning: When you clear a Distributed WLA, user sessions are also cleared on the WLA

To clear a Distributed WLA, use the following command: clear ap

Configuring a Port Name Each WLC port has a number but does not have a name by default. To set a port name, use the following command: set port port name name You can specify only a single port number with the command. To set the name of port 17 to adminpool, type the following command: WLC# set port 17 name adminpool Copyright © 2013, Juniper Networks, Inc.


357


Informational Note: To avoid confusion, Juniper Networks recommends that you do not use numbers as port names

To remove a port name, use the following command: clear port port-list name

Configuring Port Operating Parameters Autonegotiation is enabled by default on an WLC 10/100 Ethernet ports and gigabit Ethernet ports. Informational Note: The 10/100 ports on the WLC8 and WLC200 switches support half-duplex and full-duplex operation.

Informational Note: Juniper Networks recommends that you do not configure the mode of an WLC port so that one side of the link is set to autonegotiation while the other side is set to full-duplex. Although MSS allows this configuration, it can result in slow throughput on the link. The slow throughput occurs because the side that is configured for autonegotiation falls back to half-duplex. A stream of large packets sent to an WLC port in such a configuration can cause forwarding on the link to cease.

You can configure the following port operating parameters: Speed Autonegotiation Port state PoE state You also can set the administrative state of a port and PoE setting to off and then back on to reset the port.

10/100 Ports—Autonegotiation and Port Speed WLC 10/100 Ethernet ports use autonegotiation, by default, to determine the appropriate port speed. To explicitly set the port speed of a 10/100 port, use the following command: set port speed port-list {10 | 100 | auto} Informational Note: If you explicitly set the port speed (by selecting an option other than auto) of a 10/100 Ethernet port, the operating mode is set to full-duplex. Informational Note: MSS allows the port speed of a gigabit port to be set to auto. However, this setting is invalid. If you set the port speed of a gigabit port to auto, the link stops working.

To set the port speed on ports 1, 7 through 11, and 14 to 10 Mbps, type the following command: WLC# set port speed 1,7-11,14 10

358

Configuring Port Operating Parameters



Gigabit Ports—Autonegotiation and Flow Control By default, WLC gigabit ports use autonegotiation to determine capabilities for 802.3z flow control parameters. The gigabit ports can respond to IEEE 802.3z flow control packets. Some devices use this capability to prevent packet loss by temporarily pausing data transmission.

Disabling Flow Control on a WLC Gigabit Port To disable flow control negotiation on an WLC gigabit port, use the following command: set port negotiation port-list {enable | disable} Informational Note: The gigabit Ethernet ports only operate at 1000 Mbps. They do not change speed to match 10-Mbps or 100-Mbps links.

Disabling a Port All ports are enabled by default. To administratively disable a port, use the following command: set port {enable | disable} port-list A port that is administratively disabled cannot send or receive packets. This command does not affect the link state of the port.

Disabling Power over Ethernet Power over Ethernet (PoE) supplies DC power to a device connected to an WLA. The PoE state depends on whether you enable or disable PoE when you set the port type. (See “Setting the Port Type” on page 353.)

Warning: Use the WLC PoE to power only Juniper Networks WLAs. If you enable PoE on ports connected to other devices, you can damage those devices.

Informational Note: PoE is supported only on 10/100 Ethernet ports. PoE is not supported on any gigabit Ethernet ports, or on ports 7 and 8 on an WLC8, or port 1 on an WLCR2, or port 3 on an WLC200.

To change the PoE state on a port, use the following command: set port poe port-list [enable | disable]

Resetting a Port You can reset a port by changing the link state and PoE state. MSS disables the port link and PoE (if applicable) for at least one second, then reenables them. This feature is useful for forcing an WLA connected to two WLC switches to reboot using the port connected to the other WLC. To reset a port, use the following command: reset port port-list


Disabling a Port

359

Displaying Port Information You can use CLI commands to display the following port information: Port configuration and status PoE state Port statistics You also can configure MSS to display and regularly update port statistics in a separate window.

Displaying Port Configuration and Status To display port configuration and status information, use the following command: show port status [port-list] To display information for all ports, type the following command: WLC# show port status Following is example output from the above command: Port

Name

Admin

Oper

Config

Actual

Type

Media

===========================================================================

360

1

1

up

up

auto

2

2

up

down

3

3

up

4

4

5

network

10/100BaseTx

auto

network

10/100BaseTx

down

auto

network

10/100BaseTx

up

down

auto

network

10/100BaseTx

5

up

down

auto

network

10/100BaseTx

6

6

up

down

auto

network

10/100BaseTx

7

7

up

down

auto

network

10/100BaseTx

8

8

up

down

auto

network

10/100BaseTx

9

9

up

up

auto

100/full

ap

10/100BaseTx

10

10

up

up

auto

100/full

network

10/100BaseTx

11

11

up

down

auto

network

10/100BaseTx

12

12

up

down

auto

network

10/100BaseTx

13

13

up

down

auto

network

10/100BaseTx

14

14

up

down

auto

network

10/100BaseTx

15

15

up

down

auto

network

10/100BaseTx

16

16

up

down

auto

network

10/100BaseTx

17

17

up

down

auto

network

10/100BaseTx

18

18

up

down

auto

network

10/100BaseTx

19

19

up

down

auto

network

10/100BaseTx

20

20

up

down

auto

network

10/100BaseTx

21

21

up

down

auto

network

no connector

Displaying Port Information

100/full



22

22

up

down

auto

network

no connector

In this example, three of the WLC ports, 1, 9, and 10, have an operational status of up, indicating the links on the ports are available. Ports 1 and 10 are network ports. Port 9 is an WLA. Informational Note: For more information about the fields in the output, see the Juniper Mobility System Software Command Reference.

Displaying PoE State To display the PoE state of a port, use the following command: show port poe [port-list] To display PoE information for ports 7 and 9, type the following command: WLC# show port poe 7,9 Following is example output from the above command: Link Port

Name

Port Status

PoE Type

PoE config

Draw

=================================================== 7

7

down

WLA

disabled

9

9

up

WLA enabled

off

1.44

In this example, PoE is disabled on port 7 and enabled on port 9. The WLA connected to port 9 is drawing 1.44 W of power from the WLC. Informational Note: For more information about the fields in the output, see the Juniper Networks Mobility System Software Command Reference.

Displaying Port Statistics To display port statistics, use the following command: show port counters [octets | packets | receive-errors | transmit-errors | collisions | receive-etherstats | transmit-etherstats] [port port-list] You can specify one statistic type with the command. For example, to display octet statistics for port 3, type the following command: WLC# show port counters octets port 3 Following is example output from the above command: Port

Status Rx Octets

Tx Octets

==========================================================



361

3

Up

27965420

34886544

Informational Note: For information about the fields in the output, see the Juniper Networks Mobility System Software Command Reference.

Informational Note: To display all types of statistics with the same command, use the monitor port counters command. (See “Monitoring Port Statistics” on page 362.)

Clearing Statistics Counters To clear all port statistics counters, use the following command: clear port counters The counters begin incrementally, starting from 0.

Monitoring Port Statistics You can display port statistics in a format that continually updates the counters. When you enable monitoring of port statistics, MSS clears the CLI session window and displays the statistics at the top of the window. MSS refreshes the statistics every 5 seconds. This interval cannot be configured. To monitor port statistics, use the following command: monitor port counters [octets | packets | receive-errors | transmit-errors | collisions | receive-etherstats | transmit-etherstats] Statistics types are displayed in the following order by default: Octets Packets Receive errors Transmit errors Collisions Receive Ethernet statistics Transmit Ethernet statistics Each type of statistic is displayed separately. Press the Spacebar on your keyboard to cycle through the displays for each type. If you use an option to specify a statistic type, the display begins with that statistic type. You can use one statistic option with the command. Use the keys listed in Table 4 to control the monitor display. Table 4. Key

Key Controls for Monitor Port Counters Display Effect on monitor display

Spacebar Advances to the next statistics type. Esc

Exits the monitor. MSS stops displaying the statistics and displays a new command prompt.

c

Clears the statistics counters for the currently displayed statistics type. The counters begin incrementing again.

To monitor port statistics beginning with octet statistics (the default), type the following command:

362




WLC# monitor port counters As soon as you press Enter, MSS clears the window and displays statistics at the top of the window. In this example, the octet statistics are displayed first. Port

Status Rx Octets

Tx Octets

=========================================================== 1

Up

27965420

34886544

To cycle the display to the next set of statistics, press the Spacebar. In this example, packet statistics are displayed next: Port

Status

Rx Unicast

Rx NonUnicast

Tx Unicast

Tx NonUnicast

============================================================================== 1

Up

54620

62144

68318

62556


Configuring Load-Sharing Port Groups A port group is a set of physical ports that function together as a single link and provide load sharing and link redundancy. Only network ports can participate in a port group. You can configure up to 16 ports in a port group, in any combination of ports. The port numbers do not need to be contiguous and you can use 10/100 Ethernet ports and gigabit Ethernet ports in the same port group.

Load Sharing An WLC balances the port group traffic among the physical ports of a group physical ports by assigning traffic flows to ports based on the traffic source and destination MAC addresses. The WLC assigns a traffic flow to an individual port and uses the same port for all subsequent traffic for that flow.

Link Redundancy A port group ensures link stability by providing redundant connections for the same link. If an individual port in a group fails, the WLC reassigns traffic to the remaining ports. When the failed port starts operating again, the WLC begins using it for new traffic flows. Traffic that previously belonged to the port the failure continues to be assigned to other ports.

Configuring a Port Group To configure a port group, use the following command: set port-group name group-name port-list mode {on | off}


Configuring Load-Sharing Port Groups

363

Enter a name for the group and the ports contained in the group. Informational Note: Do not use dashes or hyphens in a port group name. MSS does not display the name or save the port group. The port group name must start with a letter.

The mode parameter adds or removes ports for a previously configured group. To modify a group: Add ports—Enter the ports to add, then enter mode on. Remove ports—Enter the ports to remove, then enter mode off. To configure a port group named server1 containing ports 1 through 5 and enable the link, type the following command: WLC# set port-group name server1 1-5 mode on success: change accepted. After you configure a port group, you can use the port group name with commands that change Layer 2 configuration parameters and apply configuration changes to all ports in the port group. For example, Spanning Tree Protocol (STP) and VLAN membership changes affect the entire port group instead of individual ports. When you make Layer 2 configuration changes, you can use a port group name in place of the port list. Ethernet port statistics continue to apply to individual ports, not to port groups. To configure a port group named server2 containing ports 15 and 17 and add the ports to the default VLAN, type the following commands: WLC# set port-group name server2 15,17 mode on success: change accepted. WLC# set vlan default port server2 success: change accepted. To verify the configuration change, type the following command: WLC# show vlan config Admin

VLAN

Tunl

VLAN Name

Port Status State Affin Port

Tag

State

---- ---------------- ------ ----- ----- ---------------- ----- ----1 default

Up

Up

5 server2

none

Up

To indicate that the ports are configured as a port group, the show vlan config output lists the port group name instead of the individual port numbers.

Removing a Port Group To remove a port group, use the following command: clear port-group name name

Displaying Port Group Information To display port group information, use the following command: 364

Configuring Load-Sharing Port Groups



show port-group [name group-name] To display the configuration and status of port group server2, type the following command: WLC# show port-group name server2 Port group: server2 is up Ports: 15, 17

Load Sharing Groups Interoperating with Cisco Systems EtherChannel Load-sharing port groups are interoperable with Cisco Systems EtherChannel capabilities. To configure a Cisco Catalyst to interoperate with a Juniper Networks WLC, use the following command on the Catalyst: set port channel port-list mode on

Managing the Layer 2 Forwarding Database A WLC uses a Layer 2 forwarding database (FDB) to forward traffic within a VLAN. The entries in the forwarding database map MAC addresses to the physical or virtual ports connected to those MAC addresses within a particular VLAN. To forward a packet to another device in a VLAN, the WLC searches the forwarding database for the destination MAC address of the packet, then forwards the packet to the port associated with the MAC address.

Types of Forwarding Database Entries The forwarding database can contain the following types of entries: Dynamic—A dynamic entry is a temporary entry that remains in the database only until the entry is no longer used. By default, a dynamic entry ages out if it remains unused for 300 seconds (5 minutes). All dynamic entries are removed if the WLC is powered down or rebooted. Static—A static entry does not age out, regardless of how often the entry is used. And, like dynamic entries, static entries are removed if the WLC is powered down or rebooted. Permanent—A permanent entry does not age out, regardless of how often the entry is used. In addition, a permanent entry remains in the forwarding database even following a reboot or power cycle.

How Entries Are Added to the to the Forwarding Database An entry is added to the forwarding database in one of the following ways: Learned from traffic received by the WLC —When the WLC receives a packet, the WLC adds the packet source MAC address to the forwarding database if the database does not already contain an entry for that MAC address. Added by the system administrator—You can add static and permanent unicast entries to the forwarding database. (You cannot add a multicast or broadcast address as a permanent or static forwarding database entry.)


Managing the Layer 2 Forwarding Database

365

Added by the WLC—For example, the authentication protocols can add entries for wired and wireless authentication users. The WLC also adds any static entries added by the system administrator and saved in the configuration file.

Displaying Forwarding Database Information You can display the forwarding database size and the entries contained in the database. To display the number of entries contained in the forwarding database, use the following command: show fdb count {perm | static | dynamic} [vlan vlanid] For example, to display the number of dynamic entries that the forwarding database contains, type the following command: WLC# show fdb count dynamic Total Matching Entries = 2 To display the entries in the forwarding database, use either of the following commands: show fdb [mac-addr-glob [vlan vlanid]] show fdb {perm | static | dynamic | system | all} [port port_list | vlan vlanid] The mac-addr-glob parameter can be an individual address, or a portion of an address with the asterisk (*) wildcard character representing from 1 to 5 bytes. The wildcard allows the parameter to indicate a list of MAC addresses that match all the characters except the asterisk. Use a colon between each byte in the address (for example, 11:22:33:aa:bb:cc or 11:22:33:*). You can enter the asterisk (*) at the beginning or end of the address as a wildcard, on any byte boundary. To display all entries in the forwarding database, type the following command: WLC# show fdb all * = Static Entry. + = Permanent Entry. # = System Entry. VLAN TAG

Dest MAC/Route Des [CoS]

Destination Ports

[Protocol Type]

----------------------------------------1

00:01:97:13:0b:1f

1

aa:bb:cc:dd:ee:ff

1

00:0b:0e:02:76:f5

*

1

[ALL]

3

[ALL]

1

[ALL]

Total Matching FDB Entries Displayed = 3 To display all entries that begin with 00, type the following command: WLC# show fdb 00:* * = Static Entry. + = Permanent Entry. # = System Entry. VLAN TAG

Dest MAC/Route Des [CoS]

Destination Ports

[Protocol

Type] --------------------------------------------

366

1

00:01:97:13:0b:1f

1

[ALL]

1

00:0b:0e:02:76:f5

1

[ALL]




Total Matching FDB Entries Displayed = 2 Informational Note: For information about the fields in the output, see the Juniper Mobility System Software Command Reference.

Adding an Entry to the Forwarding Database To add an entry to the forwarding database, use the following command: set fdb {perm | static} mac-addr port port-list vlan vlanid [tag tag-value] To add a permanent entry for MAC address 00:bb:cc:dd:ee:ff on ports 3 and 5 in VLAN blue, type the following command: WLC# set fdb perm 00:bb:cc:dd:ee:ff port 3,5 vlan blue success: change accepted. To add a static entry for MAC address 00:2b:3c:4d:5e:6f on port 1 in the default VLAN, type the following command: WLC# set fdb static 00:2b:3c:4d:5e:6f port 1 vlan default success: change accepted.

Removing Entries from the Forwarding Database To remove an entry from the forwarding database, use the following command: clear fdb {perm | static | dynamic | port port_list} [vlan vlanid] [tag tag-value] To clear all dynamic forwarding database entries that match all VLANs, type the following command: WLC# clear fdb dynamic success: change accepted. To clear all dynamic forwarding database entries that match ports 3 and 5, type the following command: WLC# clear fdb port 3,5 success: change accepted.

Configuring the Aging Timeout Period The aging timeout period specifies how long a dynamic entry can remain unused before the software removes the entry from the database. You can change the aging timeout period on an individual VLAN basis. You can change the timeout period to a value from 0 through 1,000,000 seconds. The default aging timeout period is 300 seconds (5 minutes). If you change the timeout period to 0, aging is disabled.

Displaying and Changing the Aging Timeout Period To display the current setting of the aging timeout period, use the following command: show fdb agingtime [vlan vlanid] Copyright © 2013, Juniper Networks, Inc.


367

For example, to display the aging timeout period for all configured VLANs, type the following command: WLC# show fdb agingtime VLAN 2 aging time = 300 sec VLAN 1 aging time = 300 sec To change the aging timeout period, use the following command: set fdb agingtime vlanid age agingtime For example, to set the aging timeout period for VLAN 2 to 600 seconds, type the following command: WLC# set fdb agingtime 2 age 600 success: change accepted.

Port and VLAN Configuration Scenario This scenario assigns names to ports, and configures WLA ports, wired authentication ports, a load-sharing port group, and VLANs. To assign names to ports to identify their functions, and verify the configuration change, use the following commands: Table 5: Port assignment commands Command

Command Output

WLC# set port 1 name mx_mgmt

success: change accepted

WLC# set port 2 name finance


WLC# set port 3 name accounting


WLC# set port 4 name shipping


WLC# set port 5 name lobby


WLC# set port 6 name conf_room1


WLC# set port 7 name conf_room2


WLC# set port 8-13 name manufacturing


WLC# set port 14-18 name rsrch_dev


WLC# set port 19-20 name mobility


WLC# set port 21,22 name backbone


WLC# show port status

See WLC# show port status example below, to review the output of this command.

Following is example output of the WLC# show port status command: Port

Name

Admin

Oper

Config

Actual

Type

Media

===========================================================================

368

1

mx_mgmt

up

up

auto

2

finance

up

down

3

accounting

up

4

shipping

up

Port and VLAN Configuration Scenario

100/full

network

10/100BaseTx

auto

network

10/100BaseTx

down

auto

network

10/100BaseTx

down

auto

network

10/100BaseTx



5

lobby

up

down

auto

network

10/100BaseTx

6

conf_room1

up

down

auto

network

10/100BaseTx

7

conf_room2

up

down

auto

network

10/100BaseTx

8

manufacturing

up

down

auto

network

10/100BaseTx

9

manufacturing

up

down

auto

network

10/100BaseTx

10 manufacturing

up

down

auto

network

10/100BaseTx

11 manufacturing

up

down

auto

network

10/100BaseTx

12 manufacturing

up

down

auto

network

10/100BaseTx

13 manufacturing

up

down

auto

network

10/100BaseTx

14

rsrch_dev

up

down

auto

network

10/100BaseTx

15

rsrch_dev

up

down

auto

network

10/100BaseTx

16

rsrch_dev

up

down

auto

network

10/100BaseTx

17

rsrch_dev

up

down

auto

network

10/100BaseTx

18

rsrch_dev

up

down

auto

network

10/100BaseTx

19

mobility

up

up

auto

100/full

network

10/100BaseTx

20

mobility

up

up

auto

100/full

network 10/100BaseTx

21

backbone

up

down

22

backbone

up

down

auto auto

network network

Configure the country code for operation in the US and verify the configuration change. Type the following commands: WLC# set system countrycode US success: change accepted. WLC# show system =========================================================================== Product Name:

WLC

System Name:

WLC


0.0.0.0


00:0B:0E:00:04:0C

=========================================================================== Boot Time:

2000-03-18 22:59:19

Uptime:

0 days 00:13:45

=========================================================================== Fan status:




369


temp2 ok

temp3 ok

PSU Status:


Memory:

156.08/496.04 (31%)


Total Power Over Ethernet : 0.000 =========================================================================== Configure ports 2 through 16 for connection to WLA access point model WLA522 and verify the configuration changes. Type the following commands: WLC# set ap 2-16 model WLA522-US poe enable This may affect the power applied on the configured ports. Would you like to continue? (y/n) [n]y success: change accepted. WLC# show port status Following is example output of the above commands: Port

Name

Admin

Oper

Config

Actual

Type

Media

===========================================================================

370

1

mx_mgmt

up

up

auto

100/fullnetwork 10/100BaseTx

2

finance

up

up

auto

100/full

ap

10/100BaseTx

3

accounting

up

up

auto

100/full

ap

10/100BaseTx

4

shipping

up

up

auto

100/full

ap

10/100BaseTx

5

lobby

up

up

auto

100/full

ap

10/100BaseTx

6

conf_room1

up

up

auto

100/full

ap

10/100BaseTx

7

conf_room2

up

up

auto

100/full

ap

10/100BaseTx

8

manufacturing

up

up

auto

100/full

ap

10/100BaseTx

9

manufacturing

up

up

auto

100/full

ap

10/100BaseTx

10

manufacturing

up

up

auto

100/full

ap

10/100BaseTx

11

manufacturing

up

up

auto

100/full

ap

10/100BaseTx

12

manufacturing

up

up

auto

100/full

ap

10/100BaseTx

13

manufacturing

up

up

auto

100/full

ap

10/100BaseTx

14

rsrch_dev

up

up

auto

100/full

ap

10/100BaseTx

15

rsrch_dev

up

up

auto

100/full

ap

10/100BaseTx

16

rsrch_dev

up

up

auto

100/full

ap

10/100BaseTx

17

rsrch_dev

up

down

auto


18

rsrch_dev

up

down

auto


19

mobility

up

up

auto


20

mobility

up

up

auto


21

backbone

up

down

auto

network

22

backbone

up

down

auto

network




WLC# show port poe Port

Port

PoE

PoE

Status

Type

config

Draw(Watts)

Name

Link

=========================================================================== 1

mx_mgmt

up

-

disabled

off

2

finance

up

WLA enabled

7.04

3

accounting

up

WLA enabled

7.04

4

shipping

up

WLA enabled

7.04

5

lobby

up

WLA enabled

7.04

6

conf_room1

up

WLA enabled

7.04

7

conf_room2

up

WLA enabled

7.04

8

manufacturing

up

WLA enabled

7.04

9

manufacturing

up

WLA enabled

7.04

10

manufacturing

up

WLA enabled

7.04

11

manufacturing

up

WLA enabled

7.04

12

manufacturing

up

WLA enabled

7.04

13

manufacturing

up

WLA enabled

7.04

14

rsrch_dev

up

WLA enabled

7.04

15

rsrch_dev

up

WLA enabled

7.04

16

rsrch_dev

up

WLA enabled

7.04

17

rsrch_dev

down

-

disabled

off

18

rsrch_dev

down

-

disabled

off

19

mobility

down

-

disabled

off

20

mobility

down

-

disabled

off

21

backbone

down

-

-

invalid

22

backbone

down

-

-

invalid

Configure ports 17 and 18 as wired authentication ports and verify the configuration change. Type the following commands: WLC# set port type wired-auth 17,18 success: change accepted WLC# show port status Port

Name

Admin

Oper

Config

Actual

Type

Media

========================================================================== 1

mx_mgmt

up

up

auto


2

finance

up

up

auto

100/full

ap

10/100BaseTx

3

accounting

up

up

auto

100/full

ap

10/100BaseTx

4

shipping

up

up

auto

100/full

ap

10/100BaseTx



371

5

lobby

up

up

auto

100/full

ap

10/100BaseTx

6

conf_room1

up

up

auto

100/full

ap

10/100BaseTx

7

conf_room2

up

up

auto

100/full

ap

10/100BaseTx

8

manufacturing

up

up

auto

100/full

ap

10/100BaseTx

9

manufacturing

up

up

auto

100/full

ap

10/100BaseTx

10

manufacturing

up

up

auto

100/full

ap

10/100BaseTx

11

manufacturing

up

up

auto

100/full

ap

10/100BaseTx

12

manufacturing

up

up

auto

100/full

ap

10/100BaseTx

13

manufacturing

up

up

auto

100/full

ap

10/100BaseTx

14

rsrch_dev

up

up

auto

100/full

ap

10/100BaseTx

15

rsrch_dev

up

up

auto

100/full

ap /100BaseTx

16

rsrch_dev

up

up

auto

100/full

ap

17 rsrch_dev 10/100BaseTx

up

up

auto

100/full

wiredauth

18 rsrch_dev 10/100BaseTx

up

up

auto

100/full

wired auth

19 mobility 10/100BaseTx

up

up

auto

100/full

network

20 mobility 10/100BaseTx

up

up

auto

100/full

network

10/100BaseTx

21

backbone

up

down

auto

network

22

backbone

up

down

auto

network

Configure ports 21 and 22 as a load-sharing port group to provide a redundant link to the backbone, and verify the configuration change. Type the following commands: WLC# set port-group name backbonelink port 21,22 mode on success: change accepted. WLC# show port-group Port group: backbonelink is up Ports:

22, 21

Add port 1 to the default VLAN (VLAN 1), configure a VLAN named roaming on ports 19 and 20, and verify the configuration changes. Type the following commands: WLC# set vlan default port 1 success: change accepted. WLC# set vlan 2 name roaming port 19-20 success: change accepted. WLC# show vlan config Admin VLAN Name

372


VLAN

Tunl

Status State Affin Port

Port Tag

State



---- ---------------- ------ ----- ----- ---------------- ----- ----1 default 2 roaming

Up Up

Up Up

5 1

none Up

19

none Up

20

none Up

5

Save the configuration. Type the following command: WLC# save config



373

374



Configuring and Managing VLANs

Configuring and Managing VLANs VLAN Overview Informational Note: The CLI commands in this chapter configure VLANs on WLC network ports. The commands do not configure VLAN membership for wireless or wired authentication users. To assign a user to a VLAN, configure the RADIUS Tunnel-Private-Group-ID attribute or the VLAN-Name vendor specific attribute (VSA) for that user.

A virtual LAN (VLAN) is a Layer 2 broadcast domain that can span multiple wired or wireless LAN segments. Each VLAN is a separate logical network and, if you configure IP interfaces on the VLANs, MSS treats each VLAN as a separate IP subnet. Only network ports can be preconfigured to be members of one or more VLAN(s). You configure VLANs on WLC network ports by configuring them on the WLC and assigning a name and network ports to the VLAN. Optionally, you can assign VLAN tag values on individual network ports. You can configure multiple VLANs on network ports of an WLC network. Optionally, each VLAN can have an IP address. VLANs are not configured on WLA ports or wired authentication ports, because the VLAN membership of these types of ports is determined dynamically through the authentication and authorization process. Users who require authentication connect through WLC ports configured for WLAs or wired authentication access. Users are assigned to VLANs automatically through authentication and authorization mechanisms such as 802.1X. By default, no WLC ports are in VLANs. An WLC cannot forward traffic on the network until you configure VLANs and add network ports to those VLANs. Informational Note: A wireless client cannot join a VLAN if the physical network ports on the WLC in the VLAN are down. However, a wireless client already in a VLAN whose physical network ports go down, remains in the VLAN even though the VLAN is down.

VLANs, IP Subnets, and IP Addressing Generally, VLANs are equivalent to IP subnets. If an WLC is connected to the network by only one IP subnet, the WLC must have at least one VLAN configured. Optionally, each VLAN can have a unique IP address. However, no two IP addresses on the WLC WLC can belong to the same IP subnet. You must assign the system IP address to one of the VLANs, for communications between WLCs and for unsolicited communications such as SNMP traps and RADIUS accounting messages. Any IP address configured on an WLC can be used for management access unless explicitly restricted. (For more information about the system IP address, see “Configuring and Managing IP Interfaces and Services” on page 307.)

Users and VLANs When a user successfully authenticates to the network, the user is assigned to a specific VLAN. A user remains associated with the same VLAN throughout the user session on the network, even when roaming from one WLC to another within the Mobility Domain.


VLAN Overview

375

You assign a user to a VLAN by setting one of the following attributes on the RADIUS servers or in the local user database: Tunnel-Private-Group-ID—This attribute is described in RFC 2868, RADIUS Attributes for Tunnel Protocol Support. VLAN-Name—This attribute is a Juniper vendor-specific attribute (VSA).

Informational Note: You cannot configure the Tunnel-Private-Group-ID attribute in the local user database.

Specify the VLAN name, not the VLAN number. The examples in this chapter assume the VLAN is assigned on a RADIUS server with either of the valid attributes.

Informational Note: For more information, see “Configuring AAA for Network Users” on page 123.

VLAN Names To create a VLAN, you must assign a name to it. VLAN names must be globally unique across a Mobility Domain to ensure the intended user connectivity as determined through authentication and authorization. Every VLAN on an WLC has both a VLAN name, used for authorization purposes, and a VLAN number. VLAN numbers can vary uniquely for each WLC and are not related to 802.1Q tag values. You cannot use a number as the first character in a VLAN name.

Roaming and VLANs The WLCs in a Mobility Domain contain user traffic within an assigned VLAN. For example, if you assign a user to VLAN red, the WLCs in the Mobility Domain contain the user traffic within VLAN red. The WLC authenticating a user is not required to be a member of the VLAN assigned to the user. You are not required to configure the VLAN on all WLCs in the Mobility Domain. When a user roams to a WLC that is not a member of the user-assigned VLAN, the WLC can tunnel traffic for the user through another WLC that is a member of the VLAN. The traffic can be of any protocol type. Informational Note: For more information about Mobility Domains, see “Configuring and Managing Mobility Domains” on page 123.

Informational Note: Because the default VLAN (VLAN 1) might not be in the same subnet on each WLC, Juniper Networks recommends that you do not rename the default VLAN or use it for user traffic. Instead, configure other VLANs for user traffic.

Traffic Forwarding An WLC switches traffic at Layer 2 among ports in the same VLAN. For example, suppose you configure ports 4 and 5 to belong to VLAN 2 and ports 6 and 7 to belong to VLAN 3. As a result, traffic between port 4 and port 5 is switched, but traffic between port 4 and port 6 is not switched and must be routed by an external router.

376

VLAN Overview



802.1Q Tagging The tagging capabilities of the WLC are very flexible. You can assign 802.1Q tag values on a per-VLAN, per-port basis. The same VLAN can have different tag values on different ports. In addition, the same tag value can be used by different VLANs but on different network ports. If you use a tag value, Juniper Networks recommends that you use the same value as the VLAN number. MSS does not require the VLAN number and tag value to be the same, but other vendors’ devices may require it may require it. Informational Note: Do not assign the same VLAN multiple times using different tag values to the same network port. Although MSS does not prohibit you from doing so, the configuration is not supported.

MSS automatically assigns tag values to Distributed WLAs. Each of these tag values represents a unique combination of radio, encryption type, and VLAN. These tag values do not necessarily correspond to tag values configured on the VLAN ports connecting the Distributed WLA to the WLC.

Tunnel Affinity WLCs configured as a Mobility Domain allow users to roam seamlessly across WLAs and even across WLCs. Although a WLC that is not a member of a user VLAN cannot directly forward traffic for the user, the WLC can tunnel the traffic to another WLC that is a member of the user VLAN. If the WLC that is not in the user VLAN has a choice of more than one other WLC to tunnel the user traffic, the WLC selects the other WLC based on an affinity value. This is a numeric value that each WLC within a Mobility Domain advertises, for each of the VLANs, to all other switches in the Mobility Domain. A WLC outside the user VLAN selects the other operational WLC with the highest affinity value for the user VLAN to forward traffic for the user. If more than one WLC has the highest affinity value, MSS randomly selects one of the switches for the tunnel.

WLA Tunnels If the WLA tunnel feature is disabled, then the client can connect in overlay mode. If the WLA tunnel feature is enabled, the client does not connect in overlay mode, it creates a tunnel to a WLC or WLA with the tunnel. To enable or disable WLA tunneling, use the following commands: WLC# set ap apnum ap-tunnel mode {enable | disable} WLC# set ap auto ap-tunnel mode {enable | disable} This feature is disabled by default. When this configuration is changed, affected session are dropped and then reconnected in the correct mode. If tunnel mode is enabled and local switching is already enabled on the WLA, then overlay sessions are terminated and then reconnected in order to establish overlay sessions. Tunnel mode only takes effect if local switching is enabled on the WLA. To view a WLA configuration with tunnel mode enabled, use the show ap config command: WLC# show ap config 4


VLAN Overview

377

Configuring a VLAN You can configure the following VLAN parameters: VLAN number VLAN number Port list (the ports in the VLAN) Per-port tag value (an 802.1Q value representing a virtual port in the VLAN) Tunnel affinity (a value that influences tunneling connections for roaming) MAC restriction list (if you want to prevent clients from communicating with one another directly at Layer 2)

Creating a VLAN To create a VLAN, use the following command: set vlan vlan-num name name 1. Specify a VLAN number from 2 to 3583, and specify a name up to 16 alphabetic characters long. Juniper Networks recommends that you do not use the same name with different capitalizations for VLANs or ACLs. For example, do not configure two separate VLANs with the names red and RED. Informational Note: Juniper Networks recommends that you do not use the name default as it is already applied to VLAN 1. Juniper Networks also recommends that you do not rename the default VLAN.

2. You must assign a name to a VLAN before you can add ports to the VLAN. You can configure the name and add ports with a single set vlan command or separate set vlan commands. Once you assign a VLAN number to a VLAN, you cannot change the number. However, you can change a VLAN name. For example, to assign the name red to VLAN 2, type the following command: WLC# set vlan 2 name red After you create a VLAN, you can use the VLAN number or the VLAN name in commands. In addition, the VLAN name appears in CLI and RingMaster displays.

Adding Ports to a VLAN To add a port to a VLAN, use the following command: set vlan vlanid port port-list [tag tag-value] You can specify a tag value from 1 through 4093. Informational Note: MSS does not remove a port from other VLANs when you add the port to a new VLAN. If a new VLAN causes a configuration conflict with an older VLAN, remove the port from the older VLAN before adding the port to the new VLAN.

For example, to add ports 9 through 11 and port 21 to VLAN red, type the following command: 378

VLAN Overview



WLC# set vlan red port 9-11,21 success: change accepted. Optionally, you also can specify a tag value to be used on trunked 802.1Q ports. To assign the name marigold to VLAN 4, add ports 12 through 19 and port 22, and assign tag value 11 to port 22, type the following commands: WLC# set vlan 4 name marigold port 12-19 success: change accepted. WLC# set vlan 4 name marigold port 22 tag 11 success: change accepted.

Removing an Entire VLAN or a VLAN Port To remove an entire VLAN or a specific port and tag value from a VLAN, use the following command: clear vlan vlanid [port port-list [tag tag-value]] Warning: When you remove a VLAN, MSS completely removes the VLAN from the configuration and also removes all configuration information that uses the VLAN. If you want to remove only a specific port from the VLAN, be sure to specify the port number in the command.

The clear vlan command with a VLAN ID but without a port list or tag value clears all ports and tag values from the VLAN. 1. To remove port 21 from VLAN red, type the following command: WLC# clear vlan red port 21 This may disrupt user connectivity. Do you wish to continue? (y/n) [n]y success: change accepted. 2. To clear port 13, which uses tag value 11, from VLAN marigold, type the following command: WLC# clear vlan marigold port 13 tag 11 This may disrupt user connectivity. Do you wish to continue? (y/n) [n]y success: change accepted. To completely remove VLAN ecru, type the following command: WLC# clear vlan ecru This may disrupt user connectivity. Do you wish to continue? (y/n) [n]y success: change accepted. Informational Note: You cannot remove the default VLAN (VLAN 1). However, you can add and remove ports. You can also rename the default VLAN, but it is not recommended.


VLAN Overview

379

Configuring VLAN Pooling VLAN pooling is a new feature that allows you to associate “equivalent” VLANs to a service which then improves network scalability and reduces broadcast domains across VLANs. Multiple VLANs can be grouped to form a VLAN Pool and all VLANs in the pool are available at any time in a location. VLAN assignment is performed dynamically when a wireless client accesses the network and a VLAN is assigned to the wireless client. For example, if an enterprise network has 1000 wireless clients that can connect to the network from any location in the enterprise, five VLANs may be required to support the client load. The 5 VLANs are then placed into a VLAN pool which is available at any time on the enterprise network. When a wireless client accesses the network, the client is assigned a VLAN in the VLAN Pool by using a round robin algorithm. The VLAN pool can also be configured on an AAA server. VLAN Pools can be applied to the following attributes: Users User Groups MAC Users MAC User Groups Service Profiles

Configuring VLAN Pooling using MSS VLAN Pools can be applied to the following attributes: Users User Groups MAC Users MAC User Groups Service Profiles

VLAN Pooling Commands and Configuration Examples To configure a VLAN pool, use the following commands: set vlan-pool pool-name vlan vlan-name clear vlan-pool pool-name vlan vlan-name For example, to add the VLANs red and blue to the VLAN pool colors, use the following commands: WLC# set vlan-pool colors vlan red success: change accepted. WLC# set vlan-pool colors vlan blue success: change accepted. To remove the VLAN red from the VLAN pool, colors, use the following command:

380

VLAN Overview



WLC# clear vlan-pool colors vlan red success: change accepted. The VLAN pool is automatically deleted when the last VLAN is deleted from it. You may delete the entire VLAN pool using the following command: WLC# clear vlan-pool colors success: change accepted. To add the VLAN pool to a MAC user, use the following command: WLC# set mac-user username attr vlan-name To remove the VLAN pool attribute from a MAC user, use the following command: WLC# clear mac-user username attr vlan-name To add the VLAN pool to a MAC usergroup, use the following command: WLC# set mac-usergroup name attr vlan-name To remove the VLAN pool attribute from a MAC usergroup, use the following command: WLC# clear mac-usergroup name attr vlan-name To add the VLAN pool to a service profile that affects users on a specific SSID, use the following command: WLC# set service-profile profile-name attr vlan-name To remove the VLAN pool from the service profile, use the following command: WLC# clear service-profile profile-name attr vlan-name To enhance the VLAN pool feature, new show commands are available to display information about VLAN pools: WLC# show vlan-pool [pool-name] When set, the vlan-pool attribute is displayed like other attributes for users, usergroups, mac-users, and mac-usergroups. The vlan-pool attribute is also displayed in the output of the show service-profile profile-name command.

Enhancements to VLAN Pooling in MSS 9.0 Once there is a VLAN pool for a session during the authorization phase, a VLAN must be selected from this pool and assigned to the session. The primary goal of configuring VLAN pooling is to load balance sessions evenly across the VLANs in the pool. MSS and RingMaster supports two options: MAC Address Hashing - Assign sessions to a VLAN based on the hash computed from the MAC address. Using this method guarantees that a client gets the same VLAN every time it connects, if the VLAN configuration does not change. Load-balancing - Every controller keeps track of the number of sessions per VLAN in the Mobility Domain. When a session is assigned a VLAN pool, the session is assigned to the VLAN with the fewest sessions. Copyright © 2013, Juniper Networks, Inc.

VLAN Overview

381

In both the options, a VLAN is selected only if it has not reached the configured cap of sessions per VLAN. To configure client MAC hashing, use the following commands: WLC# set vlan-pool name selection-method {client-mac-hash | load-balancing} Client-mac-hash is the default value. To configure per-VLAN capacity for a VLAN pool, use the following command: WLC# set vlan-pool name vlan vlan-name capacity 0-4096 The default value is 0 (unlimited sessions). No more sessions are assigned to a VLAN once it has reached capacity. The local side does not assign clients to VLANs once they have reached their capacity. However, since the number of clients on a VLAN is Mobility Domain wide session count, in peak traffic, it is possible that multiple controllers try to bring up sessions on that VLAN at the same time, when a VLAN is near capacity. When the advertisement of these sessions in the mobility domain reaches the local side, no action is taken to kill the clients. To help prevent this problem, you should configure the VLAN capacity lower than the real capacity to allow for this scenario. The size of the reserved capacity depends on the traffic capacity. New fields in show output: WLC# show vlan-pool Pool1: vpool1 (client-mac-hash) VLAN Name: default VLAN Name: v2

load: 10 load: 12

capacity: 80 capacity: 0

In RingMaster, the VLAN Selection Method attributes are available in a new age, VLAN Selection Algorithm, on the Create VLAN Pool wizard.

Changing Tunneling Affinity To change the tunneling affinity, use the following command: set vlan vlanid tunnel-affinity num Specify a value from 1 through 10. The default is 5.

382

VLAN Overview



Restricting Layer 2 Forwarding Among Clients By default, clients within a VLAN are able to communicate with one another directly at Layer 2. You can enhance network security by restricting Layer 2 forwarding among clients in the same VLAN. When you restrict Layer 2 forwarding in a VLAN, MSS allows Layer 2 forwarding only between a client and a set of MAC addresses, generally the VLAN default routers. Clients within the VLAN are not permitted to communicate directly. To communicate with another client, the client must use one of the specified default routers. Informational Note: For networks with IP-only clients, you can restrict client-to-client forwarding using ACLs. (See

“Restricting Client-To-Client Forwarding Among IP-Only Clients” on page 1–929.) 1. To restrict Layer 2 forwarding in a VLAN, use the following command: set security l2-restrict vlan vlanid [mode {enable | disable}] [permit-mac mac-addr [mac-addr]] You can specify multiple addresses by listing them on the same command line or by entering multiple commands. Restriction of client traffic does not begin until you enable the permitted MAC list. Use the mode enable option with this command. 2. To change a MAC address, use the clear security l2-restrict command to remove it, then use the set security l2-restrict command to add the correct address. clear security l2-restrict vlan vlanid [permit-mac mac-addr [mac-addr] | all] Informational Note: There can be a slight delay before functions such as pinging between clients become available after Layer 2 restrictions are lifted. Even though packets are passed immediately once Layer 2 restrictions are gone, it can take 10 seconds or more for upper-layer protocols to update ARP caches and regain functionality.

3. To display configuration information and statistics for Layer 2 forwarding restriction, use the following command: show security l2-restrict [vlan vlanid | all] The following commands restrict Layer 2 forwarding of client data in VLAN abc_air to the default routers with MAC address aa:bb:cc:dd:ee:ff and 11:22:33:44:55:66, and display restriction information and statistics: WLC# set security l2-restrict vlan abc_air mode enable permit-mac aa:bb:cc:dd:ee:ff 11:22:33:44:55:66 success: change accepted. WLC# show security l2-restrict VLAN Name

En Drops

Permit MAC

Hits

---- ---------------- -- ---------- ------------------- ---------1

abc_air


Y

0

aa:bb:cc:dd:ee:ff

5947

11:22:33:44:55:66

9 VLAN Overview

383

The En field indicates if restriction is enabled. The Drops field indicates how many packets were addressed directly from one client to another and dropped by MSS. The Hits field indicates how many packets the permitted default router has received from clients. 4. To reset the statistics counters, use the following command: clear security l2-restrict counters [vlan vlanid | all]

384

VLAN Overview



Displaying VLAN Information To display VLAN configuration information, use the following command: show vlan config [vlanid] To display information for VLAN burgundy, type the following command: WLC# show vlan config burgundy Admin VLAN Name

VLAN

Tunl

Port


Tag

State

---- ---------------- ------ ----- ----- ---------------- ----- ----2 burgundy

Up

Up

5 2

none Up

3

none Up

4

none Up

6

none Up

11

none Up

Informational Note: The display can include WLA access ports and wired authentication ports, because MSS dynamically adds these ports to a VLAN when handling user traffic for the VLAN. Informational Note: For information about the fields in the output, see the Juniper Mobility System Software Command Reference.


VLAN Overview

385

386

VLAN Overview


Configuring a WLC as a DHCP Server

Configuring a WLC as a DHCP Server Overview The WLC has the ability to act as a DHCP server and can allocate IP addresses to the following items and is enabled by default: Directly connected WLAs Host connected to a new (un-configured) WLC2, WLC8, or WLC200, to configure the WLC using the Web Quick Start. Optionally, you can configure the DHCP server to also provide IP addresses to Distributed WLAs and to clients. Configuration is supported on an individual VLAN basis. When you configure the DHCP server on a VLAN, the server can distributes addresses only from the subnet with the host address assigned to the VLAN. By default, the VLAN can serve any unused address in the subnet except the VLAN host address and the network and broadcast addresses. You can also specify the address range. You can configure the DHCP server for more than one VLAN. You can configure a DHCP client and DHCP server on the same VLAN, but only the client or the server can be enabled. The DHCP client and DHCP server cannot both be enabled on the same VLAN at the same time. The MSS DHCP server is implemented according to “RFC 2131: Dynamic Host Configuration Protocol” and “RFC 2132: DHCP Options and BOOTP Vendor Extensions”, with the following exceptions: If the WLC is powered down or restarted, MSS does not retain address allocations or lease times. The MSS DHCP server does not operate properly when another DHCP server is present on the same subnet. The MSS DHCP server is configurable on an individual VLAN basis only, and operates only on the subnets that you configure it. Informational Note: Use of the MSS DHCP server to allocate client addresses is intended for temporary, demonstration deployments and not for production networks. Juniper Networks recommends that you do not use the MSS DHCP server to allocate client addresses in a production network.

How the MSS DHCP Server Works When MSS receives a DHCP Discover packet, the DHCP server allocates an address from the configured range according to RFC 2131 and sends an ARP message to the address to be sure that it is available on the network. If the address is in use, the server allocates the next address in the range, and resends ARP message again. The process continues until MSS finds an unused address. MSS then offers the address to the Distributed WLA or client that sent the DHCP Discover. If there are no unused addresses left in the range, MSS ignores the DHCP Discover and generates a log message. If the client does not respond to the DHCP Offer from the MSS DHCP server within 2 minutes, the offer becomes invalid and MSS returns the address to the pool.


Overview

387

The siaddr value in the DHCP exchanges is the IP address of the VLAN. The yiaddr value is an unused address within the range the server is allowed to use. In addition to an IP address, the Offer message from the MSS DHCP server also contains the following options: Table 6.

MSS DHSCP Server Offer Message Options

Option 54

Server Identifier, that has the same value as siaddr.

Option 51

Address Lease, which is 12 hours and cannot be configured.

Option 1

Subnet Mask of the IP interface of the VLAN.

Option 15

Domain Name. If this option is not set with the set interface dhcp-server command dns-domain option, the MSS DHCP server uses the value set by the set ip dns domain command.

Option 3

Default Router. If this option is not set with the set interface dhcp-server command default-router option, the MSS DHCP server can use the value set by the set ip route command. A default route configured by set ip route can be used if the route is in the DHCP client subnet. Otherwise, the MSS DHCP server does not specify a router address.

Option 6

Domain Name Servers. If these options are not set with the set interface dhcp-server command primary-dns and secondary-dns options, the MSS DHCP server uses the values set by the set ip dns server command.

Configuring the DHCP Server You can configure the DHCP server on an individual VLAN basis. To configure the server, use the following command: set interface vlanid ip dhcp-server [enable | disable] [start ip-addr1 stop ip-addr2] [dns-domain domain-name] [primary-dns ip-addr [secondary-dns ip-addr]] [default-router gateway] The vlanid can be the VLAN name or number. The start ip-addr1 and stop ip-addr2 options specify the beginning and ending IP addresses of the IP address range (also called the address pool). By default, all addresses except the host address of the VLAN, the network broadcast address, and the subnet broadcast address are included in the range. If you specify the range, the start address must be lower than the stop address, and all addresses must be in the same subnet. The IP interface of the VLAN must be within the same subnet but is not required to be within the range. Informational Note: For information about the other options, see the Juniper Mobility System Software Command Reference.

The following command enables the DHCP server on VLAN red-vlan to serve addresses from the 192.168.1.5 to 192.168.1.25 range: WLC# set interface red-vlan ip dhcp-server enable start 192.168.1.5 stop 192.168.1.25 success: change accepted. To remove all IP information from a VLAN, including the DHCP client and user-configured DHCP server, use the following command:

388

Configuring the DHCP Server


Configuring a WLC as a DHCP Server

clear interface vlanid ip

Informational Note: This command clears all IP configuration information from the interface.

Displaying DHCP Server Information To display information about the MSS DHCP server, use the following command: show dhcp-server [interface vlanid] [verbose] If you enter the command without the interface or verbose option, the command displays a table of all the IP addresses leased by the server. You can use the interface option to display addresses leased by a specific VLAN. If you use the verbose option, configuration and status information is displayed instead. The following command displays the addresses leased by the DHCP server: WLC# show dhcp-server VLAN Name

Address

MAC

Lease Remaining (sec)

---- -------------- --------------- ----------------- -------------------1 default

10.10.20.2

00:01:02:03:04:05

12345

1 default

10.10.20.3

00:01:03:04:06:07

2103

2 red-vlan

192.168.1.5

00:01:03:04:06:08

102

2 red-vlan

192.168.1.7

00:01:03:04:06:09

16789

The following command displays configuration and status information for each VLAN on which the DHCP server is configured: WLC# show dhcp-server verbose Interface:

0 (Direct AP)

Status:

UP

Address Range:

10.0.0.1-10.0.0.253

Interface:

default(1)

Status:

UP

Address Range:

10.10.20.2-10.10.20.254

Hardware Address:

00:01:02:03:04:05

State:

BOUND

Lease Allocation:

43200 seconds

Lease Remaining:

12345 seconds

IP Address:

10.10.20.2

Subnet Mask:

255.255.255.0

Default Router:

10.10.20.1


Displaying DHCP Server Information

389

DNS Servers:

10.10.20.4 10.10.20.5

DNS Domain Name:

mycorp.com

In addition to information for addresses leased from the VLANs where the server is configured, information for the Direct AP interface is also displayed. The Direct AP interface is an internal VLAN interface for directly connected WLAs.

390

Displaying DHCP Server Information


Configuring SNMP

Configuring SNMP MSS supports Simple Network Management Protocol (SNMP) versions 1, 2c, and 3.

Overview The MSS SNMP engine (also called the SNMP server or agent) can run any combination of the following SNMP versions: SNMPv1—SNMPv1 is the simplest and least secure SNMP version. Community strings are used for authentication. Communications are in the clear (not encrypted). Notifications are traps, which are not acknowledged by the notification target (also called a trap receiver). SNMPv2c—SNMPv2 is similar to SNMPv1, but supports informs. An inform is a notification that is acknowledged by the notification target. SNMPv3—SNMPv3 adds authentication and encryption options. Instead of community strings, SNMPv3 supports user security model (USM) users, with individually configurable access levels, authentication options, and encryption options. All SNMP versions are disabled by default.

Configuring SNMP To configure SNMP, perform the following tasks: Set the WLC IP address, if it is not already set. SNMP does not work without the system IP address. Set the system location and contact strings.(Optional) Enable the SNMP version(s) to use on the network. MSS can run one or more versions, in any combination. Configure community strings (for SNMPv1 or SNMPv2c) or USM users (for SNMPv3). Set the minimum level of security allowed for SNMP message exchanges. Configure a notification profile or modify the default one, to enable sending of notifications to notification targets. By default, notifications of all types are not sent. Configure notification targets. Enable the MSS SNMP engine. If you require compliance with the US Army TIC, configure monitor and admin as roles.

Setting the System Location and Contact Strings To set the location and contact strings for an WLC, use the following commands: set system location string set system contact string Each string can be up to 256 characters long, with no blank spaces. Copyright © 2013, Juniper Networks, Inc.

Overview

391

The following commands set an WLC location to 3rd_floor_closet and set the contact to sysadmin1: WLC# set system location 3rd_floor_closet success: change accepted. WLC# set system contact sysadmin1 success: change accepted.

Enabling SNMP Versions To enable an SNMP protocol, use the following command: set snmp protocol {v1 | v2c | usm | all} {enable | disable} The usm option enables SNMPv3. The all option enables all three versions of SNMP. The following command enables all SNMP versions: WLC# set snmp protocol all enable success: change accepted.

Configuring Community Strings (SNMPv1 and SNMPv2c Only) To configure a community string for SNMPv1 or SNMPv2c, use the following command: set snmp community name comm-string access {read-only | read-notify | notify-only | read-write | notify-read-write} The comm-string can be up to 32 alphanumeric characters long, with no spaces. You can configure up to 10 community strings. The access level specifies the read-write privileges of the community string: Table 7.

Community String Access Levels

read-only

An SNMP management application using the string can read object values on the WLC but cannot set (write) them. This is the default.

read-notify

An SNMP management application using the string can read object values on the WLC but cannot set them. The WLC can use the string to send notifications.

notify-only

The WLC can use the string to send notifications.read-write—An SNMP management application using the string can read and set object values on the WLC.

notify-read-write

An SNMP management application using the string can read and set object values on the WLC. The WLC can use the string to send notifications.

To clear an SNMP community string, use the following command: clear snmp community name comm-string The following command configures community string switchmgr1 with access level notify-read-write: WLC# set snmp community name switchmgr1 notify-read-write success: change accepted.

Creating a USM User for SNMPv3 To create a USM user for SNMPv3, use the following command:

392

Configuring SNMP


Configuring SNMP

set snmp usm usm-username snmp-engine-id {ip ip-addr | local | hex hex-string} access {read-only | read-notify | notify-only | read-write | notify-read-write} auth-type {none | md5 | sha} {auth-pass-phrase string | auth-key hex-string}encrypt-type {none | des | 3des | aes} {encrypt-pass-phrase string | encrypt-key hex-string} To clear a USM user, use the following command: clear snmp usm usm-username The usm-username can be up to 32 alphanumeric characters long, with no spaces. You can configure up to 20 SNMPv3 users. The snmp-engine-id option specifies a unique identifier for an instance of an SNMP engine. To send informs, you must specify the engine ID of the inform receiver. To send traps and to allow get and set operations, specify local as the engine ID. Table 8.

snmp-engine-ids

hex hex-string

ID is a hexadecimal string.

ip ip-addr

ID is based on the IP address of the station running the management application. Enter the IP address of the station. MSS calculates the engine ID based on the address.

local

Uses the value computed from the WLC system IP address.

The access option specifies the access level of the user. The options are identical to the access options for community strings. (See “Configuring Community Strings (SNMPv1 and SNMPv2c Only)” on page 1–392.) The default is read-only. The auth-type option specifies the authentication type used to authenticate communications with the remote SNMP engine. You can specify one of the following: none—No authentication is used. This is the default. md5—Message-digest algorithm 5 is used. sha—Secure Hashing Algorithm (SHA) is used. If the authentication type is md5 or sha, you can specify a passphrase or a hexadecimal key. To specify a passphrase, use the auth-pass-phrase string option. The string can be from 8 to 32 alphanumeric characters long, with no spaces. To specify a key, use the auth-key hex-string option. Type a 16-byte hexadecimal string for MD5 or a 20-byte hexadecimal string for SHA. The encrypt-type option specifies the encryption type used for SNMP traffic. You can specify one of the following: none—No encryption is used. This is the default. des—Data Encryption Standard (DES) encryption is used. 3des—Triple DES encryption is used. aes—Advanced Encryption Standard (AES) encryption is used. If the encryption type is des, 3des, or aes, you can specify a passphrase or a hexadecimal key.


Configuring SNMP

393

To specify a passphrase, use the encrypt-pass-phrase string option. The string can be from 8 to 32 alphanumeric characters long, with no spaces. Type a string at least 8 characters long for DES or 3DES, or at least 12 characters long for AES. To specify a key, use the encrypt-key hex-string option. Type a 16-byte hexadecimal string.

Configuring Groups and Roles for SNMP To comply with the US Army TIC, you must configure groups and roles for additional security. There are two roles for the group: Admin and Monitor. Monitor allows read access for everything but SNMP security configurations, and does not allow write access. Admin allows read access to everything and write access for a few standard objects such as sysName, sysContact, and sysLocation. To configure an SNMP group, use the following commands: WLC# set snmp group group-name description group-description To set the USM security level for the group, use the following commands: WLC# set snemp group group-name security-model usm security-level {noAuthNoPriv|noAuthNoPriv|authPriv}[write-view view-name | notify-view view-name] To apply a group, use the following commands: WLC# set snmp community name comm-string group group-name WLC# set snmp usm user-name snmp-engine-id engine-id group [monitor|admin|group-name] auth-type [none| md5 | sha] To assign a role to the SNMP group, use the following command: WLC# set snmp community name comm-string group [monitor | admin]

Defining SNMP Views You can configure SNMP views and apply them to users and communities. To create a view, use the following command: WLC# set snmp view view-name description view-description The description option allows you to add security view information that allows you to identify individual views. For instance, you may want to create two views for SNMP, such as security level 1 and security level 2. WLC# set snmp view securitylevel1 description limitedviews success: change accepted. WLC# set snmp view securitylevel2 description view-all There are three predefined views: all, hideSec, and setSys. The view, all, contains all objects that are readable or writable in the SNMP agent. The view, hideSec, does not display the SNMP security configuration information. All other objects are allowed. The view, setSys, restricts the set command to required instrumentation code such as sysName, sysLocation, and sysContact. An OID is an object identifier for an object in a Management Information Base (MIB). A newly created view does not contain any tree families so you must add tree families to the view. Use the following command: 394

Configuring SNMP


Configuring SNMP

WLC# set snmp view view-name treefamily oid-subtree To match all OIDs, use the additional root option as follows: WLC# set snmp view view-name root {included | excluded}

Displaying SNMP Group Information Use the following command to display all configured SNMP groups on the WLC: WLC# show snmp group all Sec. Group name

Sec.

model level

Read view

Write view

Notify view

---------------- ----- -------- --------------- ----------------------------*monitor

V1

-

hideSec

-

all

*monitor

V2C

-

hideSec

-

all

*monitor

USM

-

hideSec

-

all

*monitor

USM

Auth

hideSec

-

all

*monitor

USM

AuthPriv hideSec

-

all

*admin

V1

-

all

setSys

all

*admin

V2C

-

all

setSys

all

*admin

USM

-

all

setSys

all

*admin

USM

Auth

all

setSys

all

*admin

USM

AuthPriv all

setSys

all

Command Examples The following command creates USM user securesnmpmgr1, and uses SHA authentication and 3DES encryption with passphrases. This user can send informs to the notification receiver with the engine ID 192.168.40.2. WLC# set snmp usm securesnmpmgr1 snmp-engine-id ip 192.168.40.2 access notify-only auth-type sha auth-pass-phrase myauthpword encrypt-type 3des encrypt-pass-phrase mycryptpword success: change accepted.

Configuring a Notification Profile A notification profile is a named list of all the notification types that can be generated by an WLC, and for each notification type, the action, drop or send, to perform when an event occurs. A default notification profile (named default) is already configured in MSS. All notifications in the default profile are dropped by default. You can configure up to 10 notification profiles. To modify the default notification profile or create a new one, use the following command: Copyright © 2013, Juniper Networks, Inc.

Command Examples

395

set snmp notify profile {default | notify-profile-name} {drop | send} {notification-type | all} To clear a notification profile, use the following command: clear snmp notify profile profile-name The profile-name can be up to 32 alphanumeric characters long, with no spaces. To modify the default notification profile, specify default. The notification type can be one of the following: Informational Note: To apply the configuration change to all notification types, specify all. The drop or send option specifies the action that the SNMP engine takes with regard to notifications. Table 9.

SNMP Notification Types

ApNonOperStatusTraps

Generated to indicate an WLA radio is nonoperational.

ApOperRadioStatusTrap2

Generated when the status of an WLA radio changes.

ApRejectLicenseExceededTraps

Generated when the number of WLAs exceed the licensed number.

AuthenTraps

Generated when the WLC SNMP engine receives a bad community string.

AutoTuneRadioChannelChangeTraps

Generated when the RF Auto-Tuning feature changes the channel on a radio.

AutoTuneRadioPowerChangeTraps

Generated when the RF Auto-Tuning feature changes the power setting on a radio.

ClientAssociationFailureTraps

Generated when a client attempts to associate with a radio and fails.

ClientAssociationSuccessTraps

Generated when a client association is successful.

ClientAuthenticationSuccessTraps

Generated when a client is successfully authorized.

ClientAuthenticationFailureTraps

Generated when authentication fails for a client.

ClientAuthorizationFailureTraps

Generated when authorization fails for a client.

ClientAuthorizationSuccessTraps

Generated when authorization is successful for a client.

ClientClearedTraps

Generated when a client session is cleared.

ClientDeAssociationTraps

Generated when a client is dissociated from a radio.

ClientDeAuthenticationTraps

Generated when a client deauthenticates from a radio.

ClientDisconnectTraps

Generated when a client disconnects from the network.

ClientDot1xFailureTraps

Generated when a client experiences an 802.1X failure.

ClientDynAuthorChangeFailureTraps

Generated when a dynamic RADIUS client fails to authenticate.

ClientDynAuthorChangeSuccessTraps

Generated when a dynamic RADIUS client has a successful authentication.

ClientIPAddrChangeTraps

Generated when the IP address for a client changes on the network.

ClientRoamingTraps

Generated when a client roams.

ConfigurationsSavedTraps

Generated when a configuration is saved on the WLC.

CounterMeasureStartTraps

Generated when MSS begins countermeasures against a rogue access point.

CounterMeasureStopTraps

Generated when MSS stops countermeasures against a rogue access point.

DeviceFailTraps

Generated when an event with an Alert severity occurs.

DeviceOkayTraps

Generated when a device returns to its normal state.

LinkDownTraps

Generated when the link is lost on a port.

LinkUpTraps

Generated when the link is detected on a port.

MichaelMICFailureTraps

Generated when two Michael message integrity code (MIC) failures occur within 60 seconds, triggering Wi-Fi Protected Access (WPA) countermeasures.

396

Configuring a Notification Profile


Configuring SNMP

Table 9.

SNMP Notification Types

MobilityDomainFailBackTraps

Generated when a primary mobility domain seed returns to primary status after a failover to a secondary seed.

MobilityDomainFailOverTraps

Generated when a secondary mobility domain seed becomes the primary seed when a failover occurs on the network.

MobilityDomainJoinTraps

Generated when the WLC switch is initially able to contact a mobility domain seed member, or can contact the seed member after a timeout.

MobilityDomainResiliencyStatusTraps

Sent by a Mobility Domain seed to announce changes in the resilient capacity status.

MobilityDomainTimeoutTraps

Generated when a timeout occurs after an WLC switch has unsuccessfully tried to communicate with a seed member.

PoEFailTraps

Generated when a serious PoE problem, such as a short circuit, occurs.

RFDetectAdhocUserTraps

Generated when MSS detects an ad-hoc user.

RFDetectAdhocUserDisappearsTraps

Generated when an ad-hoc user is no longer detected.

RFDetectBlacklistedTraps

Generated when blacklisted WLAs are detected on the network.

RFDetectClassificationChangeTraps

Generated when the classification of a device changes.

RFDetectRogueDeviceTraps

Generated when MS detects a rogue device.

RFDetectRogueDeviceDisappearTraps

Generated when a rogue device is no longer detected.

RFDetectClientViaRogueWiredAPTraps

Generated when MSS detects, on the wired part of the network, the MAC address of a wireless client associated with a third-party AP.

RFDetectDoSPortTraps

Generated when MSS detects an associate request flood, reassociate request flood, or disassociate request flood.

RFDetectDoSTraps

Generated when MSS detects a DoS attack other than an associate request flood, reassociate request flood, or disassociate request flood.

RFDetectRogueDeviceTraps

Generated when an interfering device is detected.

RFDetectRogueDeviceDisappearTraps

Generated when an interfering device is no longer detected.

RFDetectSpoofedMacAPTraps

Generated when MSS detects a wireless packet with the source MAC address of a Juniper WLA, but without the spoofed WLA’s signature (fingerprint).

RFDetectSpoofedSsidAPTraps

Generated when MSS detects beacon frames for a valid SSID, but sent by a rogue AP.

RFDetectSuspectDeviceDisappearTraps

Generated when a suspect device disappears from the network.

RFDetectSuspectDeviceTraps

Generated when a wireless device not on the list of permitted vendors is detected.

trpzAPManagerChangeTrap

Sent by the backup WLC when the change from backup to primary link occurs.

trpzApOldMgrIP

The IP address of the former primary manager WLC for an WLA.

trpzApNewMgrIP

The IP address of the new primary manager WLC for an WLA.

trpzApMgrChangeReason

Reasons why the WLA is switching to the secondary link. Reasons include: 1) other 2) failover 3) load-balancing.

trpzMobilityDomainResiliencyStatusTrap

Sent by a Mobility Domain seed to announce changes in the resilient capacity status.

Command Examples The following command changes the action in the default notification profile from drop to send for all notification types: WLC# set snmp notify profile default send all



397

success: change accepted. The following commands create notification profile snmpprof_rfdetect, and change the action to send for all RF detection notification types: WLC# set snmp notify profile snmpprof_rfdetect send RFDetectAdhocUserTraps success: change accepted. WLC# set snmp notify profile snmpprof_rfdetect send RFDetectBlacklistedTraps success: change accepted. WLC# set snmp notify profile snmpprof_rfdetect send RFDetectClientViaRogueWiredAPTraps success: change accepted. WLC# set snmp notify profile snmpprof_rfdetect send RFDetectDoSTraps success: change accepted. WLC# set snmp notify profile snmpprof_rfdetect send RFDetectAdhocUserDisappearTraps success: change accepted. WLC# set snmp notify profile snmpprof_rfdetect send RFDetectInterferingRogueAPTraps success: change accepted. WLC# set snmp notify profile snmpprof_rfdetect send RFDetectInterferingRogueDisappearTraps success: change accepted. WLC# set snmp notify profile snmpprof_rfdetect send RFDetectRogueAPTraps success: change accepted. WLC# set snmp notify profile snmpprof_rfdetect send RFDetectRogueDisappearTraps success: change accepted. WLC# set snmp notify profile snmpprof_rfdetect send RFDetectSpoofedMacAPTraps success: change accepted. WLC# set snmp notify profile snmpprof_rfdetect send RFDetectSpoofedSsidAPTraps success: change accepted. WLC# set snmp notify profile snmpprof_rfdetect send RFDetectUnAuthorizedAPTraps success: change accepted. WLC# set snmp notify profile snmpprof_rfdetect send RFDetectUnAuthorizedOuiTraps success: change accepted.

398



Configuring SNMP

WLC# set snmp notify profile snmpprof_rfdetect send RFDetectUnAuthorizedSsidTraps success: change accepted.

Configuring a Notification Target A notification target is a remote device to which MSS sends SNMP notifications. You can configure the MSS SNMP engine to send confirmed notifications (informs) or unconfirmed notifications (traps). Some of the command options differ depending on the SNMP version and the type of notification you specify. You can configure up to 10 notification targets. To configure a notification target for informs from SNMPv3, use the following command: set snmp notify target notify-target-id ip-addr[:udp-port-number] usm inform user username snmp-engine-id {ip | hex hex-string} [profile profile-name] [security {unsecured | authenticated | encrypted}] [retries num] [timeout num] To configure a notification target for traps from SNMPv3, use the following command: set snmp notify target notify-target-id ip-addr[:udp-port-number] usm trap user username [profile profile-name] [security {unsecured | authenticated | encrypted}] To configure a notification target for informs from SNMPv2c, use the following command: set snmp notify target notify-target-id ip-addr[:udp-port-number] v2c community-string inform [profile profile-name] [retries num] [timeout num] To configure a notification target for traps from SNMPv2c, use the following command: set snmp notify target notify-target-id ip-addr[:udp-port-number] v2c community-string trap [profile profile-name] To configure a notification target for traps from SNMPv1, use the following command: set snmp notify target notify-target-id ip-addr[:udp-port-number] v1 community-string [profile profile-name] To clear a notification target, use the following command: clear snmp notify target notify-target-id The target-num is an ID for the target. This ID is local to the WLC and does not need to correspond to a value on the target. You can specify a number from 1 to 10.


Configuring a Notification Target

399

The ip-addr[:udp-port-number] is the IP address of the server. You also can specify the UDP port number to send notifications to. The default is 162. Use v1, v2c, or usm to specify the SNMP version. The inform or trap option specifies if the MSS SNMP engine expects the target to acknowledge notifications sent to the target by the WLC. Use inform if you want acknowledgements. Use trap if you do not want acknowledgements. The inform option is applicable to SNMP version v2c or usm only. The username is a USM username, and is applicable only when the SNMP version is usm. If the user sends informs rather than traps, specify the snmp-engine-id of the target. Specify ip if the target SNMP engine ID is based on the IP address. If the target SNMP engine ID is a hexadecimal value, use hex hex-string to specify the value. The community-string is applicable only when the SNMP version is v1 or v2c. The profile-name is the notification profile. The default is default. The security option specifies the security level, and is applicable only when the SNMP version is usm: unsecured—Message exchanges are not authenticated, nor are they encrypted. This is the default. authenticated—Message exchanges are authenticated, but are not encrypted. encrypted—Message exchanges are authenticated and encrypted. The retries and timeout options are applicable only when the SNMP version is v2c or usm and the notification type is inform. The retries option specifies the number of times the MSS SNMP engine resends a notification that was unacknowledged by the target. You can specify from 0 to 3 retries. The default is 0. The timeout option specifies the number of seconds MSS waits for acknowledgement of a notification. You can specify from 1 to 5 seconds. The default is 2.

Command Examples The following command configures a notification target for acknowledged notifications: WLC# set snmp notify target 1 10.10.40.9 usm inform user securesnmpmgr1 snmp-engine-id ip success: change accepted. This command configures target 1 at IP address 10.10.40.9. The target SNMP engine ID is based on the IP address. The MSS SNMP engine sends notifications based on the default profile, and requires acknowledgement from the target. The following command configures a notification target for unacknowledged notifications: WLC# set snmp notify target 2 10.10.40.10 v1 public profile pm_notify_pr success: change accepted.

Enabling the SNMP Service To enable the MSS SNMP service, use the following command: set ip snmp server {enable | disable} The following command enables the SNMP service: 400

Enabling the SNMP Service


Configuring SNMP

WLC# set ip snmp server enable success: change accepted.

Displaying SNMP Information You can display the following SNMP information: Version and status information Configured community strings User-based security model (USM) settings SNMP notification profiles Notification targets SNMP statistics counters

Displaying SNMP Version and Status Information To display SNMP version and status information, use the following command: show snmp status

Displaying the Configured SNMP Community Strings To display the configured SNMP community strings, use the following command: show snmp community

Displaying USM Settings To display USM settings, use the following command: show snmp usm

Displaying Notification Profiles To display notification profiles, use the following command: show snmp notify profile

Displaying Notification Targets To display a list of the SNMP notification targets, use the following command: show snmp notify target

Displaying SNMP Statistics Counters To display SNMP statistics counters, use the following command: show snmp counters


Displaying SNMP Information

401

402

Displaying SNMP Information


About AAA for Network Users

About AAA for Network Users Overview Network users include the following types of users: Wireless users—Users who access the network by associating with an SSID on a Juniper radio. Wired authentication users—Users who access the network over an Ethernet connection to an WLC switch port that is configured as a wired authentication (wired-auth) port. Local users that log into the WLC for administrative access. You can configure authentication rules for each type of user, on an individual SSID or wired authentication port basis. MSS authenticates users based on user information on RADIUS servers or on the local database of the WLC. The RADIUS servers or local database authorizes successfully authenticated users for specific network access, including VLAN membership. Optionally, you also can configure accounting rules to track network access information. The following sections describe the MSS authentication, authorization, and accounting (AAA) features in more detail.

Authentication When a user attempts to access the network, MSS checks for an authentication rule that matches the following parameters: For wireless access, the authentication rule must match the user-requested SSID, and the username or MAC address. For access on a wired authentication port, the authentication rule must match the username or MAC address. If a matching rule is found, MSS then checks the RADIUS servers or the local database on the WLC for credentials matching those presented by the user. Depending on the type of authentication rule that matches the SSID or wired authentication port, the required credentials are the username or MAC address, and in some cases, a password. Each authentication rule specifies the location of the user credentials. The location can be a group of RADIUS servers or the local database of the WLC. In either case, if MSS has an authentication rule that matches the required parameters, MSS checks the username or MAC address of the user and, if required, the password, to make sure this matches the information configured on the RADIUS servers or in the local database. The username or MAC address can be an exact match or can match a userglob or MAC address glob, which allow wildcards to be used for all or part of the username or MAC address.

Authentication Types MSS provides the following types of authentication:


Overview

403

IEEE 802.1X—If the network interface card (NIC) supports 802.1X, MSS checks for an 802.1X authentication rule matching the username (and SSID, if wireless access is requested), and uses the Extensible Authentication Protocol (EAP) requested by the NIC. If a matching rule is found, MSS uses the requested EAP to check the RADIUS server group or local database for the username and password entered by the user. If matching information is found, MSS grants access to the user. MAC—If the username does not match an 802.1X authentication rule, but the MAC address of the NIC or Voice-over-IP (VoIP) phone and the SSID (if wireless) do match a MAC authentication rule, MSS checks the RADIUS server group or local database for matching user information. If the MAC address (and password, if on a RADIUS server) matches, MSS grants access. Otherwise, MSS attempts the fallthru authentication type, which can be Web, last-resort, or none. (Fallthru authentication is described in more detail in “Authentication Algorithm” on page 404.) Web—A network user attempts to access a Web page over the network. The WLC intercepts the HTTP or HTTPS request and displays a login Web page to the user. The user enters the username and password, and MSS checks the RADIUS server group or local database for matching user information. If the username and password match, MSS redirects the user to the requested Web page. Otherwise, MSS denies access to the user. Last-resort—A network user associates with an SSID or connects to a wired authentication port, and does not enter a username or password. − SSID—If no 802.1X or MAC access rules are configured for the SSID, the default authorization attributes set on the SSID are applied to the user and the user is allowed onto the network. − Wired authentication port—If 802.1X or MAC authentication does not apply to the port (no 802.1X or MAC access rules have the wired option set), MSS checks for user last-resort-wired. If the user is configured, the authorization attributes set for the user are applied and the user is allowed onto the network.

Authentication Algorithm MSS can try more than one authentication type to authenticate a user. MSS tries 802.1X first. If the NIC supports 802.1X but fails authentication, MSS denies access. Otherwise, MSS tries MAC authentication next. If MAC authentication is successful, MSS grants access to the user. Otherwise, MSS tries the fallthru authentication type specified for the SSID or wired authentication port. The fallthru authentication type can be one of the following: Web Last-resort None

404

Overview



None means the user is automatically denied access. The fallthru authentication type for wireless access is associated with the SSID (through a service profile). The fallthru authentication type for wired authentication access is specified with the wired authentication port. Informational Note: The fallthru authentication type None is different from the authentication method none you can specify for administrative access. The fallthru authentication type None denies access to a network user.

Figure 1–1 shows how MSS tries the authentication types for wireless access. (The authentication process is similar for access through a wired authentication port, except last-resort access requires a last-resort-wired user.) Figure 1–1. Authentication Flowchart for Wireless Network Users


Overview

405

Authentication Chaining MSS allows multiple different authentication types for wireless clients. You can now configure authentication by requesting MAC-authentication and dot1X. This feature allows multiple authentications for a client on the network. The most common of these is MAC authentication and dot1x. In some cases, three authentications are required by the network configuration. All authentication types are supported in a chain and are allowed in any sequence except that Web authentication must be last in the chain. Authorization is required at each step of the chain and an attribute assigned in a previous step is replaced by the subsequent step. To allow authentication chaining, you can create AAA profiles and configure the authentication methods. Use the following commands: WLC# set aaa-profile profile-name WLC# set aaa-profile profile-name authen-type [dot1x auth-method-1 ] auth-method2 auth-method3 auth-method4 The authentication profile name allows a maximum of 32 characters and cannot be configured using special characters such as #$&?”\.

Summary of AAA Features Depending on your network configuration, you can configure authentication, authorization, and accounting (AAA) for network users to be performed locally on the WLC or remotely on a RADIUS server. The number of users that the local WLC database can support depends on the WLC model. AAA for network users controls and monitors their use of the network: Classification for customized access. As with administrative and console users, you can classify network users through username globbing. Based on the structured username, different AAA types can be assigned to different classes of user. For example, users in the human resources department can be authenticated differently from users in the sales department. Authentication for full or limited access. IEEE 802.1X network users are authenticated when they identify themselves with a credential. Authentication can be passed through to RADIUS, performed locally on the WLC, or only partially “offloaded” to the WLC. Network users without 802.1X support can be authenticated by the MAC addresses of their devices. If neither 802.1X nor MAC authentication apply to the user, they can still be authenticated by a fallthru authentication type, either WebAAA or last-resort authentication. The default fallthru type is None, which denies access to users that do not match an 802.1X or MAC authentication rule. Authorization for access control. Authorization provides access control by per-user security access control lists (ACLs), VLAN membership, Mobility Domain assignment, and timeout enforcement. Because authorization is always performed on users accessing a particular VLAN, the WLC automatically uses the same AAA method (RADIUS server group or local database) for authorization that you define for a user authentication. Local authorization control. You can override any AAA assignment of VLAN or security ACL for individual network users on a particular WLC by configuring the location policy on the WLC.

406

Overview



SSID default authorization attributes. You can configure service profiles with a set of default AAA authorization attributes that are applied when the normal AAA process or a location policy does not provide them. Accounting for tracking users and resources. Accounting collects and sends information used for billing, auditing, and reporting—for example, user identities, connection start and stop times, the number of packets received and sent, and the number of bytes transferred. You can track sessions by using accounting information stored locally or on a remote RADIUS server. As network users roam throughout a Mobility Domain, accounting records track them and their network usage. Accounting for administrative access sessions—Accounting records can be stored and displayed locally or sent to a RADIUS server. Accounting records provide an audit trail of the number of administrative login instances, administrator username, number of bytes transferred, and the start and stop time of user sessions.

AAA Tools for Network Users Authentication verifies network user identity and is required before granting access to the network. An WLC authenticates user identity by username-password matching, digital signatures and certificates, or other methods such as MAC addresses. You must decide whether to authenticate network users locally on the WLC, remotely via one or more external RADIUS server groups, or both locally and remotely.

“Globs” and Groups for Network and Local User Classification “Globbing” lets you classify users by username or MAC address for different AAA treatments. A user glob is a string used by AAA and IEEE 802.1X or WebAAA methods to match a user or set of users. MAC address globs match authentication methods to a MAC address or set of MAC addresses. User globs and MAC address globs can make use of wildcards. A user group is a named collection of users or MAC addresses sharing a common authorization policy. For example, you might group all users on the first floor of building 17 into the group bldg-17-1st-floor, or group all users in the IT group into the group infotech-people.

Wildcard “Any” for SSID Matching Authentication rules for wireless access include the SSID name, and must match the user-requested SSID name to authenticate the user for that SSID. To have an authentication rule match an any SSID string, specify the SSID name as any in the rule.

Configuring the SSID Name “Any” In authentication rules for wireless access, you can specify the name any for the SSID. This value is a wildcard that matches any SSID string requested by the user. For 802.1X and WebAAA rules that match on SSID any, MSS checks the RADIUS servers or local database for the username (and password, if applicable) entered by the user. If the user information matches, MSS grants access to the SSID requested by the user, regardless of the SSID name.


Overview

407

For MAC authentication rules that match on SSID any, MSS checks the RADIUS servers or local database for the MAC address (and password, if applicable) of the user device. If the address matches, MSS grants access to the SSID requested by the user, regardless of the SSID name.

About Last-Resort Processing One of the fallthru authentication types you can set on a service profile or wired authentication port is last-resort. If no 802.1X or MAC access rules are configured for a service profile SSID, and the SSID fallthru type is last-resort, MSS allows users onto the SSID or port without prompting for a username or password. The default authorization attributes set on the SSID are applied to the user. For example, if the vlan-name attribute on the service profile is set to guest-vlan, last-resort users are placed in guest-vlan. If no 802.1X or MAC access rules are configured for wired, and the wired authentication port fallthru type is last-resort, MSS allows users on the port without prompting for a username or password. The authorization attributes set on user last-resort-wired are applied to the user.

User Credential Requirements The user credentials are checked by MSS on RADIUS servers or in the local database differ depending on the type of authentication rule assigned to the SSID or wired access requested by the user. For a user to be successfully authenticated by an 802.1X or WebAAA rule, the username and password entered by the user must be configured on the RADIUS servers or in the local database. For a user to be successfully authenticated by a MAC address, the MAC address must be configured on the RADIUS servers used by the authentication rule or in the WLC local database. If the MAC address is configured in the local database, no password is required. However, since RADIUS requires a password, if the MAC address is on the RADIUS server, MSS checks for a password. The default password is “trapeze” on MXs, and “juniper” on WLCs, but is configurable. For a user to be successfully authenticated for last-resort access on a wired authentication port, the RADIUS servers or local database must contain a user named last-resort-wired. If the last-resort-wired user is configured in the local database, no password is required. However, since RADIUS requires a password, if the last-resort-wired user is on the RADIUS server, MSS checks for a password. The default password is “trapeze” on MXs, and “juniper” on WLCs, but is configurable. Last-resort access to an SSID does not require a special user (such as last-resort-ssid) to be configured. Instead, if the fallthru authentication type on the SSID service profile is set to last-resort, and the SSID does not have any 802.1X or MAC access rules, a user can access the SSID without entering a username or password. Informational Note: If wireless clients are configured to use proxy servers and WebAAA, only ports 80, 8000, and 8080 are supported by MSS on the proxy server.

408

Overview



Authorization If the user is authenticated, MSS then checks the RADIUS server or local database for the authorization attributes assigned to the user. Authorization attributes specify the network resources available to the user. The Virtual LAN (VLAN) name is a required attribute in order to place the user in the appropriate network. RADIUS and MSS have additional optional attributes. For example, you can provide further access controls by specifying the times during which the user can access the network, by applying inbound and outbound access control lists (ACLs) to user traffic, and so on. To assign attributes on the RADIUS server, use the standard RADIUS attributes supported on the server. To assign attributes in the WLC local database, use the MSS vendor-specific attributes (VSAs). The RADIUS attributes supported by MSS are described in the “Supported RADIUS Attributes” on page 973. MSS provides the following VSAs, that you can assign to users in the local database or on a RADIUS server: COA-username — Change of authorization request sent by a Dynamic Authorization Server (DAS). Command-Audit — Specifies if command auditing is enabled for the user. Encryption-Type—Specifies the type of encryption required for access by the client. End-Date—Date and time after which the user is no longer allowed on the network. Mobility-Profile—Controls the WLC ports that a user can access. For wireless users, an MSS Mobility Profile specifies the WLA access points through which the user can access the network. For wired authentication users, the Mobility Profile specifies the wired authentication ports for a user to access to the network. Qos-Profile — Name of the QoS profile used by the authorized client. Simultaneous-logins — If enabled for a user or service profile, multiple logins are allowed. SSID — SSID the user is allowed to access after authentication. Start-Date—Date and time that the user becomes eligible to access the network. MSS does not authenticate the user unless the attempt to access the network occurs at or after the specified date and time, but before the end-date (if specified). Time-of-Day—Day(s) and time(s) that the user is permitted to log onto the network. URL—URL to redirect the user after successful WebAAA. User-Group-Name — Name of a user group used by the authorized client. VLAN-Name—the VLAN for placement of the user. You also can assign the following RADIUS attributes to local database users. Filter-Id—Security ACL that permits or denies traffic received or sent from the WLC. Service-Type—Type of access requested by the user, which can be network access, administrative access to the configuration mode of the MSS CLI, or administrative access to the nonconfiguration mode of the CLI. Session-Timeout—Maximum number of seconds allowed for the user session.


Overview

409

The VLAN attribute is required for configuration. The other attributes are optional. In addition to configuring user authorization attributes on RADIUS servers or the WLC local database, you can also configure attributes within a service profile. These authorization attributes are applied to users accessing the SSID managed by the service profile (in addition to any attributes supplied by a RADIUS server or the WLC local database).

Accounting Accounting collects and sends information used for billing, auditing, and reporting: User identities Connection start and stop times Number of packets received and sent Number of transferred bytes You can track sessions through accounting information stored locally or on a remote RADIUS server. As network users roam throughout a Mobility Domain, accounting records track them and their network usage.

AAA Methods for IEEE 802.1X and Web Network Access The following AAA methods are supported by Juniper Networks for 802.1X and Web network access mode: Client certificates issued by a certificate authority (CA) for authentication. (For this method, you assign an authentication protocol to a user. For protocol details, see “IEEE 802.1X Extensible Authentication Protocol Types” on page 413.) The WLC local database of usernames and user groups for authentication. A named group of RADIUS servers. The WLC supports up to four server groups. Each server group can contain one to four servers. You can use the local database or RADIUS servers for MAC access as well. If you use RADIUS servers and you have a MX, be sure to change the default authorization password, trapeze, to a secure one for your network.If you have a WLC, be sure to change the default authorization password, juniper, to a secure one for your network.

AAA Rollover Process A WLC attempts AAA methods in the order that they are entered in the configuration: 1. The first AAA method in the list is used unless that method results in an error. If the method results in a pass or fail, the result is final and the WLC tries no other methods. 2. If the WLC receives no response from the first AAA method, the WLC tries the second method in the list.

410

Overview



3. If the WLC receives no response from the second AAA method, the WLC tries the third method. This evaluation process is applied to all methods in the list. Informational Note: If a AAA rule specifies local as a secondary AAA method, to be used if the RADIUS servers are unavailable, and MSS authenticates a client with the local method, MSS starts again at the beginning of the method list when attempting to authorize the client. This can cause unexpected delays during client processing and can cause the client to time out before completing logon.

Local Override Exception There is one exception to the AAA operation that takes place if the local database is the first method in the list and is fllowed by a RADIUS server group method. If the local method fails to find a matching username entry in the local database, the WLC tries the next RADIUS server group method. This exception is referred to as local override. If the local database is the last method in the list, however, local authentication must either accept or deny the user, because there are no more available methods for authentication.

Remote Authentication with Local Backup You can use a combination of authentication methods, for example, Protected Extensible Authentication Protocol (PEAP) offload and local authentication. When PEAP offload is configured, the WLC offloads all EAP processing from server groups, and the RADIUS servers are not required to communicate using the EAP protocols. (For details, see “Implementing EAP on an WLC” on page 414.) In the event that RADIUS servers are unavailable, local authentication takes place using the database on the WLC. If an administrator wants to rely on RADIUS servers but also wants to ensure that a certain group of users always gets access, the administrator can enable PEAP offload. Authentication is performed by a RADIUS server group as the first method for these users, and local authentication is configured last, in case the RADIUS servers are unavailable. (See Figure 1–2.) 1. To configure server-1 and server-2 at IP addresses 192.168.253.1 and 192.168.253.2 with the password chey3nn3, the administrator enters the following commands: WLC# set radius server server-1 address 192.168.253.1 key chey3nn3 WLC# set radius server server-2 address 192.168.253.2 key chey3nn3 2. To configure server-1 and server-2 into server-group-1, the administrator enters the following command: WLC# set server group server-group-1 members server-1 server-2 3. To enable PEAP offload plus local authentication for all users of SSID mycorp at @example.com, the administrator enters the following command: WLC# set authentication dot1x ssid mycorp *@example.com peap-mschapv2 server-group-1 local Figure 1–2 shows the results of this combination of methods.


Overview

411

Figure 1–2. Remote Authentication with PEAP Offload using Local Authentication as Backup

Authentication proceeds as follows: 1. When user @example.com attempts authentication, the WLC sends an authentication request to the first AAA method, which is server-group-1. Because server-group-1 contains two servers, the first RADIUS server, server-1, is contacted. If this server responds, the authentication proceeds using server-1. 2. If server-1 fails to respond, the WLC retries the authentication using server-2. If server-2 responds, the authentication proceeds using server-2. 3. If server-2 does not respond, because the WLC has no more servers to try in server-group-1, the WLC attempts to authenticate using the next AAA method, which is the local method. 4. The WLC consults its local database for an entry that matches [email protected].

412

Overview



5. If a suitable local database entry exists, the authentication proceeds. If not, authentication fails and [email protected] is not allowed to access the network. Informational Note:

If one of the RADIUS servers in the group responds, but it indicates that the user does not exist on the RADIUS server, or that the user is not permitted on the network, then authentication for the user fails, regardless of any additional methods. If all the RADIUS servers in the server group do not respond then the WLC attempts to authenticate using the next method in the list. If the primary authentication method is local and the secondary method is RADIUS, but the user does not exist in the local database, then the WLC does attempt to authenticate using RADIUS. See “Local Override Exception” on page 1–411. Using pass-through authentication as the primary authentication method and the local database as the secondary authentication method is not supported.

IEEE 802.1X Extensible Authentication Protocol Types Extensible Authentication Protocol (EAP) is a generic point-to-point protocol that supports multiple authentication mechanisms. EAP has been adopted as a standard by the Institute of Electrical and Electronic Engineers (IEEE). IEEE 802.1X is an encapsulated form for carrying authentication messages in a standard message exchange between a user (client) and an authenticator. Table 10 summarizes the EAP protocols supported by MSS. Table 10.

EAP Authentication Protocols for Local Processing

EAP Type

Description

EAP-MD5

Authentication algorithm that uses a Wired authentication challenge-response mechanism to compare only a hashes

(EAP with Message Digest Algorithm 5)

EAP-TLS (EAP with Transport Layer Security)

Protocol that provides mutual authentication, integrity-protected encryption algorithm negotiation, and key exchange. EAP-TLS provides encryption and data integrity checking for the connection.

Use

Wireless and wired authentication. All authentication is processed on the WLC.

Considerations This protocol provides no encryption or key establishment. This protocol requires X.509 public key certificates on both sides of the connection. Requires use of local database. Not supported for RADIUS.

Wireless and wired authentication: PEAP-MSCHAP-V2 (Protected EAP with Microsoft Challenge Handshake Authentication Protocol version 2)


The wireless client authenticates the server (either the WLC switch or a RADIUS server) using TLS to set up an encrypted session. Mutual authentication is performed by MS-CHAP-V2.

The PEAP portion is processed on the WLC. The MS-CHAP-V2 portion is processed on the RADIUS server or locally, depending on the configuration.

Only the server side of the connection requires a certificate. The client needs only a username and password.

IEEE 802.1X Extensible Authentication Protocol Types

413

a.EAP-MD5 does not work with Microsoft wired authentication clients.

Implementing EAP on an WLC Network users with 802.1X support cannot access the network unless authenticated. You can configure an WLC to authenticate users with EAP on a group of RADIUS servers or in a local user database on the WLC, or to offload some authentication tasks from the server group. Table 11 details these three basic WLC authentication approaches. Table 11.

Three Methods for EAP Authentication

Approach

Description

Pass-through

An EAP session is established directly between the client and RADIUS server, passing through the WLC. User information resides on the server. All authentication information and certificate exchanges pass through the switch or use client certificates issued by a certificate authority (CA). In this case, the switch does not need a digital certificate, although the client may require a certificate.

Local

The WLC performs all authentication using information in a local user database, or using a client-supplied certificate. No RADIUS servers are required. In this case, the switch needs a digital certificate. If you plan to use the EAP with Transport Layer Security (EAP-TLS) authentication protocol, the clients also need certificates.

Offload

The WLC offloads all EAP processing from a RADIUS server by establishing a TLS session between the WLC and the client. In this case, the WLC needs a digital certificate. When you use offload, RADIUS can still be used for non-EAP authentication and authorization. EAP-TLS cannot be used with offload.

Effects of Authentication Type on Encryption Method Wireless users who are authenticated for an encrypted service set identifier (SSID) can have data traffic encrypted by the following methods: Wi-Fi Protected Access (WPA) encryption Non-WPA dynamic Wired Equivalent Privacy (WEP) encryption Non-WPA static WEP encryption The authentication method assigned to a user determines the available encryption. Users configured for EAP authentication, MAC authentication, Web, or last-resort authentication can have their traffic encrypted as follows: Table 12. EAP Authentication

MAC Authentication

Last-Resort

WebAAA

WPA encryption

Static WEP

Static WEP

Static WEP

Dynamic WEP encryption

No encryption (if SSID is unencrypted)



Wired users are not encrypted in the same way as wireless users, but they can be authenticated by an EAP method, a MAC address, or a Web login page served by the WLC.

414

IEEE 802.1X Extensible Authentication Protocol Types


Configuring 802.1X Authentication

Configuring 802.1X Authentication Overview The IEEE 802.1X standard is a framework for sending EAP protocols over a wired or wireless LAN. Within this framework, you can use TLS, PEAP-TTLS, or EAP-MD5. Most EAP protocols can be sent through the WLC to the RADIUS server. Some protocols can be processed locally on the WLC. The following 802.1X authentication command allows authentication treatments for multiple users to be different: set authentication dot1x {ssid ssid-name | wired} user-glob [bonded] protocol method1 [method2] [method3] [method4] For example, the following command authenticates wireless user Tamara, when requesting SSID wetlands, as an 802.1X user using the PEAP-MS-CHAP-V2 method via the server group shorebirds, which contains one or more RADIUS servers: WLC# set authentication dot1x ssid wetlands Tamara peap-mschapv2 shorebirds When a user attempts to connect through 802.1X, the following events occur: 1. For each 802.1X login attempt, MSS examines each entry in the configuration file in strict configuration order. 2. The first entry with a SSID and user glob matching the SSID and incoming username is used to process this authentication. The entry determines exactly how the WLC processes the login attempt.

Configuring EAP Offload You can configure the WLC to offload all EAP processing from server groups. In this case, the RADIUS server is not required to communicate using the EAP protocols. For PEAP-MS-CHAP-V2 offload, you define a complete user profile in the local WLC database and only a username and password on a RADIUS server. For example, the following command authenticates all wireless users who request SSID marshes at example.com by offloading PEAP processing onto the WLC, while still performing MS-CHAP-V2 authentication via the server group shorebirds: WLC# set authentication dot1x ssid marshes *@example.com peap-mschapv2 shorebirds To offload both PEAP and MS-CHAP-V2 processing onto the WLC, use the following command: WLC# set authentication dot1x ssid marshes *@example.com peap-mschapv2 local

Using Pass-Through The pass-through method causes EAP authentication requests to be processed entirely by remote RADIUS servers in server groups. For example, the following command enables users at EXAMPLE to be processed via server group shorebirds or swampbirds: Copyright © 2013, Juniper Networks, Inc.

Overview

415

WLC# set authentication dot1X ssid marshes EXAMPLE/* pass-through shorebirds swampbirds The server group swampbirds is contacted only if all the RADIUS servers in shorebirds do not respond.

Authenticating Users in a Local Database To configure the WLC to authenticate and authorize a user against the local database in the WLC, use the following command: set authentication dot1x {ssid ssid-name | wired} user-glob [bonded] protocol local For example, the following command authenticates 802.1X user user for wired authentication access via the local database: MX-20# set authentication dot1X user wired peap-mschapv2 local success: change accepted.

Binding User Authentication to Computer Authentication Bonded Auth™ (bonded authentication) is a security feature that binds an 802.1X user authentication to authentication of the user’s computer. When this feature is enabled, MSS authenticates a user only if the user’s computer is authenticated separately. By default, MSS does not bind user authentication to machine authentication. A trusted user can log on from any computer attached to the network. You can use Bonded Auth™ with Microsoft Windows clients that support separate 802.1X authentication for the computer and for a user. Network administrators sometimes use computer authentication in a Microsoft Active Directory domain to run login scripts, and to control defaults, application access and updates, and so on. Bonded Auth™ provides an added security measure, by ensuring that a trusted user can log onto the network only from a trusted computer known to Active Directory. For example, if user bob.mycorp.com has a trusted laptop for work purposes, but also has a personal laptop you can bind Bob’s authentication with the authentication of his workplace laptop, host/bob-laptop.mycorp.com. In this case, Bob can log onto the company network only from his work laptop. When Bonded Auth is enabled, MSS retains information about the computer session when a user logs on from that computer. MSS authenticates the user only if there has already been a successful computer authentication. Evidence of the computer session in MSS indicates that the computer has successfully authenticated and is therefore trusted by MSS. If MSS does not have session information for the computer, MSS refuses to authenticate the user and does not allow the user onto the network from the unauthenticated computer. Informational Note: If the 802.1X reauthentication parameter or the RADIUS Session-Timeout parameter is applicable, the user must login before the 802.1X reauthentication timeout or the RADIUS session-timeout for the computer session expires. Normally, these parameters apply only to clients that use dynamic WEP, or use WEP-40 or WEP-104 encryption with WPA or RSN.

416

Overview



Authentication Rule Requirements Bonded Auth requires an 802.1X authentication rule for the computer, and a separate 802.1X authentication rule for the user(s). Use the bonded option in the user authentication rule, but not in the computer authentication rule. The computer authentication rule must be higher in the list of authentication rules than the user authentication rule. You must use 802.1X authentication rules. The computer 802.1X authentication rule must use pass-through as the protocol. Juniper Networks recommends that you also use pass-through for the user authentication rule. The computer rule and the user rule must use a RADIUS server group as the method. (Generally, in a Bonded Auth configuration, the RADIUS servers use a user database stored on an Active Directory server.) Informational Note: For a configuration example, see “Bonded Authentication Configuration Example” on page 1–418.

It is recommended to make the rules as general as possible. For example, if the Active Directory domain is mycorp.com, the following userglobs match on all machine names and users in the domain: host/*.mycorp.com (userglob for the machine authentication rule) *.mycorp.com (userglob for the user authentication rule) If the domain name has more nodes (for example, nl.mycorp.com), use an asterisk in each node that you want to match globally. For example, to match on all machines and users in mycorp.com, use the following userglobs: host/*.*.mycorp.com (userglob for the computer authentication rule) *.*.mycorp.com (userglob for the user authentication rule) Use more specific rules to direct computers and users to different server groups. For example, to direct users in nl.mycorp.com to a different server group than users in de.mycorp.com, use the following userglobs: host/*.nl.mycorp.com (userglob for the computer authentication rule) *.nl.mycorp.com (userglob for the user authentication rule) host/*.de.mycorp.com (userglob for the computer authentication rule) *.de.mycorp.com (userglob for the user authentication rule)

Bonded Authentication Period The Bonded Authentication period is the number of seconds MSS allows a Bonded Auth user to reauthenticate. After successful computer authentication, a session appears in the session table in MSS. When the user logs on and is authenticated, the user session replaces the computer session in the table. However, since the user authentication rule contains the bonded option, MSS remembers that the computer was authenticated. Copyright © 2013, Juniper Networks, Inc.

Overview

417

If a Bonded Authentication user session is ended due to 802.1X reauthentication or the RADIUS Session-Timeout parameter, MSS can allow time for the user to reauthenticate. The amount of time that MSS allows for reauthentication is controlled by the Bonded Authentication period. If the user does not reauthenticate within the Bonded Authentication period, MSS deletes the information about the computer session. After the computer session information is deleted, the Bonded Authentication user cannot reauthenticate. When this occurs, the user must log off, and then log back on, to access the network. After multiple failed reauthentication attempts, the user might need to reboot the computer before logging on. By default, the Bonded Authentication period is 0 seconds. MSS does not wait for a Bonded Authentication user to reauthenticate. You can set the Bonded Authentication period to a value up to 300 seconds. Juniper Networks recommends that you try 60 seconds, and change the period to a longer value only if clients are unable to authenticate within 60 seconds. To set the Bonded Authentication period, use the following command: set dot1x bonded-period seconds To reset the Bonded Authentication period to the default value (0), use the following command: clear dot1x bonded-period

Bonded Authentication Configuration Example To configure Bonded Authentication: Configure separate authentication rules for the computer and for the user(s). Set the Bonded Authentication period. Verify the configuration changes. The following commands configure two 802.1X authentication rules for access to SSID mycorp. The first rule is for authentication of all trusted laptops at mycorp.com (host/*-laptop.mycorp.com). The second rule is for bonded authentication of all users at mycorp.com (*.mycorp.com). Both rules use pass-through as the protocol, and use RADIUS server group radgrp1. WLC# set authentication dot1x ssid mycorp host/*-laptop.mycorp.com pass-through radgrp1 success: change accepted. WLC# set authentication dot1x ssid mycorp *.mycorp.com bonded pass-through radgrp1 success: change accepted. The following command sets the Bonded Authentication period to 60 seconds, to allow time for WEP users to reauthenticate: WLC# set dot1x bonded-period 60 success: change accepted.

Displaying Bonded Authentication Configuration Information To display Bonded Auth configuration information, use the following command: 418

Overview



show dot1x config In the following example, user.mycorp.com uses Bonded Authentication, and the Bonded Authentication period is set to 60 seconds. WLC# show dot1x config 802.1X user policy ---------------------'host/user-laptop.mycorp.com' on ssid 'mycorp' doing PASSTHRU 'user.mycorp.com' on ssid 'mycorp' doing PASSTHRU (bonded) 802.1X parameter

setting

----------------

-------

supplicant timeout

30

auth-server timeout

30

quiet period

60

transmit period

5

reauthentication period

3600

maximum requests

2

key transmission

enabled

reauthentication

enabled

authentication control

enabled

WEP rekey period

1800

WEP rekey

enabled

Bonded period

60

Information for the 802.1X authentication rule for the computer (host/user-laptop.mycorp.com) is also displayed. However, the bonded option is configured only for the user authentication rule. The bonded option applies only to the authentication rules for users, not the authentication rules for computers.

Configuring Authentication and Authorization by MAC Address Users are sometimes authenticated using the MAC addresses of devices rather than a username-password or certificate. For example, some Voice-over-IP (VoIP) phones and personal digital assistants (PDAs) do not support 802.1X authentication. If a client does not support 802.1X, MSS attempts to perform MAC authentication of the client instead. The WLC discovers the device MAC address from received frames and can use the MAC address instead of a username for the client.


Configuring Authentication and Authorization by MAC Address

419

Users authorized by MAC address require a MAC authorization password if RADIUS authentication is desired. The default password is “trapeze” on MXs, and “juniper” on WLCs.. Caution: Use this method with care. IEEE 802.11 frames can be forged and can result in unauthorized network access if MAC authentication is implemented on the network.

Adding and Clearing MAC Users and User Groups Locally MAC users and groups can gain network access only through the WLC. They cannot create administrative connections to the WLC. A MAC user is created in a similar manner as other local users except that a MAC address is used instead of a username. MAC user groups are created in a similar manner as other local user groups. (To create a MAC user profile or MAC user group on a RADIUS server, see the documentation for your RADIUS server.)

Adding MAC Users and Groups To create a MAC user group in the local WLC database, you must associate it with an authorization attribute and value. Use the following command: set mac-usergroup group-name attr attribute-name value For example, to create a MAC user group called mac-easters with a 3000-second Session-Timeout value, type the following command: WLC# set mac-usergroup mac-easters attr session-timeout 3000 success: change accepted. To configure a MAC user in the local database and optionally add the user to a group, use the following command: set mac-user mac-addr [group group-name] For example, type the following command to add MAC user 01:0f:03:04:05:06 to group macfans: WLC# set mac-user 01:0f:03:04:05:06 group macfans success: change accepted. To configure MAC user ranges, use the following command: set mac-user mac-glob For example, to add the MAC user range 00:11:*, type the following command: set mac-user 00:11:*

Clearing MAC Users and Groups To clear a MAC user from a user group, use the following command: clear mac-user mac-addr group For example, the following command removes MAC user 01:0f:03:04:05:06 from the user group: WLC# clear mac-user 01:0f:03:04:05:06 group

420




success: change accepted. The clear mac-usergroup command removes the group. To remove a MAC user profile from the local database on the WLC, type the following command: clear mac-user mac-address For example, the following command removes MAC user 01:0f:03:04:05:06 from the local database: WLC# clear mac-user 01:0f:03:04:05:06 success: change accepted.

Configuring MAC Authentication and Authorization The set authentication mac command defines the AAA methods used for authentication by MAC addresses. You can configure authentication for users through the MAC addresses of their devices with the following command: set authentication mac {ssid ssid-name | wired} mac-addr-glob method1 [method2] [method3] [method4] MAC addresses can be authenticated by either the WLC local database or by a RADIUS server group. For example, the following command sets the authentication for MAC address 01:01:02:03:04:05 when requesting SSID voice, on the local database: WLC# set authentication mac ssid voice 01:01:02:03:04:05 local success: change accepted If the WLC configuration does not contain a set authentication mac command matching a non-802.1X client MAC address, the WLC attempts MAC authentication by default. You can also configure globs for MAC addresses. For example, the following command locally authenticates all MAC addresses that begin with the octets 01:01:02: WLC# set authentication mac ssid voice 01:01:02:* local success: change accepted You can add authorization attributes to authenticated MAC users with the following command: set mac-user mac-addr attr attribute-name value For example, to add the MAC user 00:01:02:03:04:05 to VLAN red: WLC# set mac-user 00:01:02:03:04:05 attr vlan-name red success: change accepted To change the value of an authorization attribute, reenter the command with the new value. To clear an authorization attribute from a MAC user profile in the local database, use the following command: clear mac-user mac-addr attr attribute-name For example, the following command clears the VLAN assignment from MAC user 01:0f:02:03:04:05: WLC# clear mac-user 01:0f:03:04:05:06 attr vlan-name



421


Informational Note: For a complete list of authorization attributes, see Table 15 on page 457.

Changing the MAC Authorization Password for RADIUS To authenticate and authorize MAC users using RADIUS, you must configure a single predefined password for MAC users, called the outbound authorization password. The same password is used for all MAC user entries in the RADIUS database. Set this password by typing the following command: set radius server server-name author-password password The default password is “trapeze” on MXs, and “juniper” on WLCs. Informational Note: Before setting the outbound authorization password for a RADIUS server, you must set the address for the RADIUS server.

For example, the following command sets the outbound authorization password for MAC users on server bigbird to h00per: WLC# set radius server bigbird author-password h00per success: change accepted Informational Note: A MAC address must be dash-delimited in the RADIUS database. For example, 00-00-01-03-04-05. However, the MSS always displays colon-delimited MAC addresses.

If the MAC address is in the database, MSS uses the VLAN attribute and other attributes associated with it for user authorization. Otherwise, MSS tries the fallthru authentication type, which can be last-resort, Web, or none.

422



Managing 802.1X on the WLC

Managing 802.1X on the WLC Certain settings for IEEE 802.1X sessions on the WLC are enabled by default. For best results, change the settings only if you are aware of a problem with the WLC 802.1X performance. For settings that you can reset with a clear command, MSS reverts to the default value. See “Managing WEP Keys” on page 1–425 for information about changing the settings for Wired-Equivalent Privacy protocol (WEP) key rotation (rekeying).

Warning: 802.1X parameter settings are global for all SSIDs configured on the WLC.

Managing 802.1X on Wired Authentication Ports A wired authentication port is an Ethernet port with 802.1X authentication enabled for access control. Like wireless users, users connected to an WLC by Ethernet wire can be authenticated before authorizing use of the network. One difference between a wired authenticated user and a wireless authenticated user is that data for wired users is not encrypted after the users are authenticated. By default, 802.1X authentication is enabled for wired authenticated ports, but you can disable it. You can also set the port to unconditionally authorize, or unconditionally reject, all users.

Enabling and Disabling 802.1X Globally The following command globally enables or disables 802.1X authentication on all wired authentication ports on an WLC: set dot1x authcontrol {enable | disable} The default setting is enable, which permits 802.1X authentication to occur as determined by the set dot1X port-control command for each wired authentication port. The disable setting forces all wired authentication ports to unconditionally authorize all 802.1X authentication attempts by users with an EAP success message. To reenable 802.1X authentication on wired authentication ports, type the following command: WLC# set dot1x authcontrol enable success: dot1x authcontrol enabled.

Setting 802.1X Port Control The following command describes the method that user 802.1X authentication attempts are managed by a wired authentication port or a group of ports: set dot1x port-control {forceauth | forceunauth | auto} port-list The default setting is auto, which allows the WLC to process 802.1X authentication normally according to the authentication configuration. Alternatively, you can set a wired authentication port or ports to either unconditionally authenticate or unconditionally reject all users.


Managing 802.1X on Wired Authentication Ports

423

For example, the following command forces port 19 to unconditionally authenticate all 802.1X authentication attempts with an EAP success message: WLC# set dot1x port-control forceauth 19 success: authcontrol for 19 is set to FORCE-AUTH. Similarly, the following command forces port 12 to unconditionally reject any 802.1X attempts with an EAP failure message: WLC# set dot1x port-control forceunauth 12 success: authcontrol for 12 is set to FORCE-UNAUTH. The set dot1x port-control command is overridden by the set dot1x authcontrol command. The clear dot1x port-control command returns port control to the default auto value. Type the following command to reset port control for all wired authentication ports: WLC# clear dot1x port-control success: change accepted.

Managing 802.1X Encryption Keys By default, the WLC sends encryption key information to a wireless supplicant (client) in an Extensible Authentication Protocol over LAN (EAPoL) packet after authentication is successful. You can disable this feature or change the time interval for key transmission. The Wired-Equivalent Privacy protocol (WEP) keys used by MSS on WLAs for broadcast communication on a VLAN are automatically rotated (rekeyed) every 30 minutes to maintain secure packet transmission. You can disable WEP key rotation for debugging purposes, or change the rotation interval.

Enabling 802.1X Key Transmission The following command enables or disables the transmission of key information to the supplicant (client) in EAPoL key messages, after authentication: set dot1x key-tx {enable | disable} Key transmission is enabled by default. The WLC switch sends EAPoL key messages after successfully authenticating the supplicant (client) and receiving authorization attributes for the client. If the client is using dynamic WEP, the EAPoL Key messages are sent immediately after authorization. Type the following command to reenable key transmission: WLC# set dot1x key-tx enable success: dot1x key transmission enabled.

Configuring 802.1X Key Transmission Time Intervals The following command sets the number of seconds the WLC waits before retransmitting an EAPoL packet of key information: set dot1x tx-period seconds 424

Managing 802.1X Encryption Keys



The default is 5 seconds. The range for the retransmission interval is from 1 to 65,535 seconds. For example, type the following command to set the retransmission interval to 300 seconds: WLC# set dot1x tx-period 300 success: dot1x tx-period set to 300. Type the following command to reset the retransmission interval to the 5-second default: WLC# clear dot1x tx-period success: change accepted.

Configuring 802.1X Rekey Timers To maintain secure wireless access to the network, keys used to encrypt packets should be difficult to guess or hack by a third party. The following requirements are now in MSS 7.1: Adding the option to enable or disable unicast periodic rekeying with a configurable interval value. When the timer expires, the client unicast key (PTK) is changed when a 4-way handshake is initiated. Adding the option to enable multicast periodic rekeying with a configurable interval value. When the timer expires, all VLAN keys (GTK) is changed by initiating a 4-way or 2-way handshake. To configure the rekey times, use the following commands: WLC# set dot1x unicast-rekey-period [seconds] success: change accepted. WLC# set dot1X multicast-rekey-period [seconds] success: change accepted. The timer is set in seconds with a value from 30 to 86400. To enable or disable rekeying times, use the following commands: WLC# set dot1x unicast-rekey [enable | disable] WLC# set dot1x multicast-rekey [enable | disable] To clear the configuration, use the following commands: WLC# clear dot1x unicast-rekey-period success: change accepted. WLC# clear dot1X multicast-rekey-period success: change accepted.

Managing WEP Keys Wired-Equivalent Privacy (WEP) is part of the system security of 802.1X, and MSS uses WEP to provide confidentiality to packets as sent over the wireless network. WEP operates on the WLA. WEP uses a secret key shared between the communicators. WEP rekeying increases the security of the network, and new unicast keys are generated every time a client performs 802.1X authentication.


Managing 802.1X Encryption Keys

425

The rekeying process can be performed automatically on a periodic basis. By setting the Session-Timeout RADIUS attribute, the reauthentication is transparent to the client, who is unaware that reauthentication is occurring. A good value for Session-Timeout is 30 minutes. WEP broadcast rekeying causes the broadcast and multicast keys for WEP to be rotated every WEP rekey period for each radio to each connected VLAN. The WLC generates the new broadcast and multicast keys and pushes the keys to the clients via EAPoL key messages. WEP keys are case-insensitive. Use the set dot1x wep-rekey and the set dot1x wep-rekey-period commands to enable WEP key rotation and configure the time interval for WEP key rotation.

Configuring 802.1X WEP Rekeying WEP rekeying is enabled by default on the WLC. Disable WEP rekeying only if you need to debug your 802.1X network. Use the following command to disable WEP rekeying for broadcast and multicast keys: WLC# set dot1x wep-rekey disable success: wep rekeying disabled Informational Note: Reauthentication is not required for using this command. Broadcast and multicast keys are always rotated at the same time, so all members of a given radio and VLAN receive the new keys at the same time.

To reenable WEP rekeying, type the following command: WLC# set dot1x wep-rekey enable success: wep rekeying enabled

Configuring the Interval for WEP Rekeying The following command sets the interval for rotating the WEP broadcast and multicast keys: set dot1x wep-rekey-period seconds The default is 1800 seconds (30 minutes). You can set the interval from 30 to 1,641,600 seconds (19 days). For example, type the following command to set the WEP-rekey period to 900 seconds: WLC# set dot1x wep-rekey-period 900 success: dot1x wep-rekey-period set to 900

Setting EAP Retransmission Attempts The following command sets the maximum number of times the WLC retransmits an 802.1X-encapsulated EAP request to the supplicant (client) before it times out the authentication session: set dot1x max-req number-of-retransmissions The default number of retransmissions is 2. You can specify from 0 to 10 retransmit attempts. For example, type the following command to set the maximum number of retransmission attempts to 3: WLC# set dot1x max-req 3 success: dot1x max request set to 3. 426

Setting EAP Retransmission Attempts



To reset the number of retransmission attempts to the default setting, type the following command: WLC# clear dot1x max-req success: change accepted. Informational Note: o support SSIDs that have both 802.1X and static WEP clients, MSS sends a maximum of two ID requests, even if this parameter is set to a higher value. Setting the parameter to a higher value does affect all other types of EAP messages.

The interval of time before retransmitting an 802.1X-encapsulated EAP request to the supplicant is the same number of seconds as one of the following timeouts: Supplicant timeout (configured by the set dot1x timeout supplicant command) RADIUS session-timeout attribute If both timeouts are set, MSS uses the shorter of the two. If the RADIUS session-timeout attribute is not set, MSS uses the timeout specified by the set dot1x timeout supplicant command, by default 30 seconds.

Managing 802.1X Client Reauthentication Reauthentication of 802.1X wireless clients is enabled on the WLC by default. By default, the WLC waits 3600 seconds (1 hour) between authentication attempts. You can disable reauthentication or change the defaults. Informational Note: You also can use the RADIUS session-timeout attribute to set the reauthentication timeout for a specific client. In this case, MSS uses the timeout that has the lower value. If the session-timeout is set to fewer seconds than the global reauthentication timeout, MSS uses the session-timeout for the client. However, if the global reauthentication timeout is shorter than the session-timeout, MSS uses the global timeout instead.

Informational Note:

Enabling and Disabling 802.1X Reauthentication The following command enables or disables the reauthentication of supplicants (clients) by the WLC: set dot1x reauth {enable | disable} Reauthentication is enabled by default. Type the following command to reenable reauthentication of clients: WLC# set dot1x reauth enable success: dot1x reauthentication enabled.

Setting the Maximum Number of 802.1X Reauthentication Attempts The following command sets the number of reauthentication attempts that the WLC makes before the supplicant (client) becomes unauthorized: set dot1x reauth-max number-of-attempts The default number of reauthentication attempts is 2. You can specify from 1 to 10 attempts. For example, type the following command to set the number of authentication attempts to 8: Copyright © 2013, Juniper Networks, Inc.

Managing 802.1X Client Reauthentication

427

WLC# set dot1x reauth-max 8 success: dot1x max reauth set to 8. Type the following command to reset the maximum number of reauthorization attempts to the default: WLC# clear dot1x reauth-max success: change accepted. Informational Note: If the number of reauthentications for a wired authentication client is greater than the maximum number of reauthentications allowed, MSS sends an EAP failure packet to the client and removes the client from the network. However, MSS does not remove a wireless client from the network under these circumstances.

Setting the 802.1X Reauthentication Period The following command configures the number of seconds before attempting reauthentication: set dot1x reauth-period seconds The default is 3600 seconds (1 hour). The range is from 60 to 1,641,600 seconds (19 days). This value can be overridden by user authorization parameters. MSS reauthenticates dynamic WEP clients based on the reauthentication timer. MSS also reauthenticates WPA clients if the clients use the WEP-40 or WEP-104 cipher. For each dynamic WEP client or WPA client using a WEP cipher, the reauthentication timer is set to the lesser of the global setting or the value returned by the AAA server with the rest of the authorization attributes for the client. For example, type the following command to set the number of seconds to 100 before reauthentication is attempted: WLC# set dot1x reauth-period 100 success: dot1x auth-server timeout set to 100. Type the following command to reset the default timeout period: WLC# clear dot1x reauth-period success: change accepted.

Setting the Bonded Authentication Period The following command sets the Bonded Auth™ (bonded authentication) period, the number of seconds MSS retains session information for an authenticated computer while waiting for the 802.1X client on the computer to start (re)authentication for the user. Normally, the Bonded Auth period needs to be set only if the network has Bonded Auth clients that use dynamic WEP, or use WEP-40 or WEP-104 encryption with WPA or RSN. These clients can be affected by the 802.1X reauthentication parameter or the RADIUS Session-Timeout parameter. To set the Bonded Auth period, use the following command: set dot1x bonded-period seconds The Bonded Auth period applies only to 802.1X authentication rules that contain the bonded option. To reset the Bonded Auth period to the default value, use the following command: clear dot1x max-req

428

Managing 802.1X Client Reauthentication



(For more information about Bonded Auth, see “Binding User Authentication to Computer Authentication” on page 1–136.)

Managing Other Timers By default, the WLC waits 60 seconds before responding to a client whose authentication failed, and times out a request to a RADIUS server or an authentication session with a client after 30 seconds. You can modify these defaults.

Setting the 802.1X Quiet Period The following command configures the number of seconds an WLC is unresponsive to a client after a failed authentication: set dot1x quiet-period seconds The default is 60 seconds. The acceptable range is from 0 to 65,535 seconds. For example, type the following command to set the quiet period to 300 seconds: WLC# set dot1x quiet-period 300 success: dot1x quiet period set to 300. Type the following command to reset the 802.1X quiet period to the default: WLC# clear dot1x quiet-period success: change accepted.

Setting the 802.1X Timeout for an Authorization Server Use this command to configure the number of seconds before the WLC times out a request to a RADIUS authorization server. set dot1x timeout auth-server seconds The default is 30 seconds. The range is from 1 to 65,535 seconds. For example, type the following command to set the authorization server timeout to 60 seconds: WLC# set dot1x timeout auth-server 60 success: dot1x auth-server timeout set to 60. To reset the authorization server timeout to the default, type the following command: WLC# clear dot1x timeout auth-server success: change accepted.

Setting the 802.1X Timeout for a Client Use the following command to set the number of seconds before the WLC times out an authentication session with a supplicant (client): set dot1x timeout supplicant seconds The default is 30 seconds. The range of time is from 1 to 65,535 seconds.


Managing Other Timers

429

For example, type the following command to set the number of seconds for a timeout to 300: WLC# set dot1x timeout supplicant 300 success: dot1x supplicant timeout set to 300. Type the following command to reset the timeout period: WLC# clear dot1x timeout supplicant success: change accepted.

Setting the 802.1X Timeout for the Handshake The timeout for the 4-way handshake and the group-key handshake is derived indirectly through the configured supplicant timeout and the configured TX period. The timeout is now globally configurable as part of the 802.1X configuration and is configurable on a per service profile basis. To configure the timeout for the handshake, type the following command: WLC# set dot1x timeout handshake milliseconds The default value is 2000 milliseconds (2 seconds) with a range of 20-5000 milliseconds. To clear the configuration and reset the timeout to the default value, use the following command: WLC# clear dot1x timeout handshake To configure the handshake timeout on a service profile, use the following command: WLC# set service-profile profile-name dot1x-handshake-timeout timeout The default value is 0, no configuration and the global dot1x value is used, with a range from 20-5000 milliseconds.

Displaying 802.1X Information This command displays 802.1X information for clients, statistics, VLANs, and configuration. show dot1x {clients | stats | config} show dot1x clients displays the username, MAC address, VLAN, and state of active 802.1X clients. show dot1x config displays a summary of the current configuration. show dot1x stats displays global 802.1X statistical information associated with connecting and authenticating.

Viewing 802.1X Clients Type the following command to display active 802.1X clients: WLC# show dot1x clients MAC Address -------------

430

State -------

Vlan

Identity

------

----------

00:20:a6:48:01:1f

Connecting

(unknown)

00:05:3c:07:6d:7c

Authenticated

vlan-it

EXAMPLE\smith

00:05:5d:7e:94:83

Authenticated

vlan-eng

EXAMPLE\jgarcia

Displaying 802.1X Information



00:02:2d:86:bd:38

Authenticated

vlan-eng

[email protected]

00:05:5d:7e:97:b4

Authenticated

vlan-eng

EXAMPLE\hosni

00:05:5d:7e:98:1a

Authenticated

vlan-eng

EXAMPLE\tsmith

00:0b:be:a9:dc:4e

Authenticated

vlan-pm

[email protected]

00:05:5d:7e:96:e3

Authenticated

vlan-eng

EXAMPLE\geetha

00:02:2d:6f:44:77

Authenticated

vlan-eng

EXAMPLE\tamara

00:05:5d:7e:94:89

Authenticated

vlan-eng

EXAMPLE\nwong

00:06:80:00:5c:02

Authenticated

vlan-eng

EXAMPLE\hhabib

00:02:2d:6a:de:f2

Authenticated

vlan-pm

[email protected]

00:02:2d:5e:5b:76

Authenticated

vlan-pm

EXAMPLE\natasha

00:02:2d:80:b6:e1

Authenticated

vlan-cs

[email protected]

00:30:65:16:8d:69

Authenticated

vlan-wep

MAC authenticated

00:02:2d:64:8e:1b

Authenticated

vlan-eng

EXAMPLE\jose

Viewing the 802.1X Configuration Type the following command to display the 802.1X configuration: WLC# show dot1x config 802.1X user policy ---------------------'EXAMPLE\pc1' on ssid 'mycorp' doing EAP-PEAP (EAP-MSCHAPv2) 'EXAMPLE\bob' on ssid 'mycorp' doing EAP-PEAP (EAP-MSCHAPv2) (bonded) 802.1X parameter

setting

----------------

-------

supplicant timeout

30

auth-server timeout

30

quiet period

5

transmit period

5

reauthentication period

3600

maximum requests

2

key transmission

enabled

reauthentication

enabled

authentication control

enabled

WEP rekey period

1800

WEP rekey

enabled

Bonded period

60



431

port 5, authcontrol: auto, max-sessions: 16 port 6, authcontrol: auto, max-sessions: 1 port 7, authcontrol: auto, max-sessions: 1 port 8, authcontrol: auto, max-sessions: 1 port 9, authcontrol: auto, max-sessions: 1 port 10, authcontrol: auto, max-sessions: 1 port 11, authcontrol: auto, max-sessions: 1 port 12, authcontrol: auto, max-sessions: 1 port 13, authcontrol: auto, max-sessions: 1 port 14, authcontrol: auto, max-sessions: 1 port 15, authcontrol: auto, max-sessions: 1 port 16, authcontrol: auto, max-sessions: 1 port 22, authcontrol: auto, max-sessions: 16 Viewing 802.1X Statistics Type the following command to display 802.1X statistics about connecting and authenticating: WLC# show dot1x stats 802.1X statistic

value

----------------

-----

Enters Connecting:

709

Logoffs While Connecting:

112

Enters Authenticating:

467

Success While Authenticating:

0

Timeouts While Authenticating:

52

Failures While Authenticating:

0

Reauths While Authenticating:

0

Starts While Authenticating:

31

Logoffs While Authenticating:

0

Starts While Authenticated:

85

Logoffs While Authenticated:

1

Bad Packets Received:

0

For information about the fields in the output, see the Juniper Networks Mobility System Software Command Reference.

432



Configuring Web Portal WebAAA

Configuring Web Portal WebAAA Overview WebAAA provides a simple and universal way to authenticate any user or device using a Web browser. A common application of WebAAA is to control access for guests on your network. When a user requests access to an SSID or attempts to access a Web page before logging onto the network, MSS displays a login page to the user’s browser. After the user enters a username and password, MSS validates the user information on the local database or RADIUS servers and grants or denies access based on whether the user information is found. MSS redirects an authenticated user back to the requested web page, or to a page specified by the administrator. WebAAA, like other types of authentication, is based on an SSID or on a wired authentication port. You can use WebAAA on both encrypted and unencrypted SSIDs. If you use WebAAA on an encrypted SSID, you can use static WEP or WPA with PSK as the encryption type. MSS provides a default Juniper Networks login page but you can add custom login pages to the WLC nonvolatile storage, and configure MSS to display these pages instead. Informational Note: If using a proxy server to support Web Portal services, the only ports that are supported are 80, 8000, and 8080.

How Web Portal WebAAA Works 1. A WebAAA user attempts to access the network. For a wireless user, this begins when the network interface card (NIC) associates with an SSID from a Juniper WLA. For a wired authentication user, this begins when the user NIC sends data on the wired authentication port. 2. MSS starts a portal session for the user, and places the user in a VLAN. If the user is wireless (associated with an SSID), MSS assigns the user to the VLAN set by the vlan-name attribute for the SSID service profile. If the user is on a wired authentication port, the web-portal-wired VLAN is assigned to the user. 3. The user opens a Web browser. The Web browser sends a DNS request for the IP address of the home page or a URL requested by the user. 4. MSS does the following: First, MSS intercepts the DNS request, and uses MSS DNS proxy to obtain the URL IP address from the network DNS server. Then MSS sends the IP address to the user’s browser. MSS then serves a login page to the WebAAA user. (Also see “Display of the Login Page” on page 1–434.) 5. The user enters a username and password in the WebAAA login page.


Overview

433

6. MSS authenticates the user by checking RADIUS or the WLC local database for the username and password. If the user information is present, MSS authorizes the user based on the authorization attributes set for the user. Informational Note: MSS ignores the VLAN-Name or Tunnel-Private-Group-ID attribute associated with the user, and leaves the user in the VLAN associated with the SSID service profile (if wireless) or with the web-portal-wired user (if the user is on a wired authentication port).

7. After authentication and authorization are complete, MSS changes the user session from a portal session with the name web-portal-ssid or web-portal-wired to a WebAAA session with the user name. The session remains connected, but now the session is identity-based instead of a portal session. 8. MSS redirects the browser to the URL initially requested by the user or, if the URL VSA is configured for the user, redirects the user to the URL specified by the VSA. 9. The Web page for the URL that the user is redirected appears in the browser window.

Display of the Login Page When a WebAAA client first tries to access a Web page, the client browser sends a DNS request to obtain the IP address mapped to the domain name requested by the client browser. The WLC proxies this DNS request to the network DNS server, then proxies the reply back to the client. If the DNS server has a record for the requested URL, the request is successful and the WLC displays a Web login page to the client. However, if the DNS request is unsuccessful, the WLC displays a message informing the user and does not serve the login page. If the WLC does not receive a reply to a client DNS request, the WLC spoofs a reply to the browser by sending the WLC IP address as the resolution to the browser DNS query. The WLC also serves the Web login page. This behavior simplifies use of the WebAAA feature in networks that do not have a DNS server. However, if the requested URL is invalid, the behavior gives the appearance that the requested URL is valid, since the browser receives a login page. Moreover, the browser might cache a mapping of the invalid URL to the WLC IP address. If the user enters an IP address, most browsers attempt to contact the IP address directly without using DNS. Some browsers interpret numeric strings as IP addresses (in decimal notation) if a valid address could be formed by adding dots (dotted decimal notation). For example, 208194225132 would be interpreted as a valid IP address, when converted to 208.194.225.132.

WLC Web AAA Requirements and Recommendations Informational Note: MSS Version 5.0 does not require or support special user web-portal-ssid, where ssid is the SSID the Web-Portal user associates with. Previous MSS Versions required this special user for Web-Portal configurations. Any web-portal-ssid users are removed from the configuration during upgrade to MSS Version 5.0. However, the web-portal-wired user is still required for Web Portal on wired authentication ports.

The WLC WebAAA requirements and recommendations discussed in this section are: “WebAAA Certificate” on page 435

434

WLC Web AAA Requirements and Recommendations



“User VLAN” on page 435 “Fallthru authentication type” on page 435 “Authorization attributes” on page 436 “Portal ACL” on page 436 “Authentication rules” on page 436

WebAAA Certificate A WebAAA certificate must be installed on the WLC. You can use a self-signed (signed by the WLC) WebAAA certificate automatically generated by MSS, manually generate a self-signed one, or install one signed by a trusted third-party certificate authority (CA). If you decide to install a self-signed WebAAA certificate, use a common name (a required field in the certificate), that resembles a Web address and contains at least one dot. When MSS displays the login page in the Web browser, the page URL is based on the common name in the WebAAA certificate. Here are some examples of common names in the recommended format: webaaa.login webaaa.customername.com portal.local

User VLAN An IP interface must be configured on the user VLAN. The interface must be on the subnet that the DHCP server places the user, so that the WLC can communicate with both the client and the client preferred DNS server. If users roam from the WLC where they connect to the network to other WLC switches, the system IP addresses of the switches should not be in the Web-portal VLAN. Although the default VLAN of the SSID and the user VLAN must be the same, you can configure a location policy that allows the service profile of the user to roam to another VLAN. The other VLAN is not required to be statically configured on the WLC. The VLAN does have the same requirements as other user VLANs. For example, the user VLAN on the roamed-to WLC must have an IP interface, the interface must be in the subnet that has DHCP, and the subnet must be the same one the DHCP server places the user.

Fallthru authentication type The fallthru authentication type for each SSID and wired authentication port supporting WebAAA, must be set to web-portal. The default authentication type for wired authentication ports and for SSIDs is None (no fallthru authentication is used). To set the fallthru authentication type for an SSID, use the set service-profile auth-fallthru parameter of the set port type wired-auth command.command. To set it on a wired authentication port, use the auth-fall-thru web-portal p



435

Authorization attributes Wireless Web-Portal users get their authorization attributes from the SSID service profile. To assign wireless Web-Portal users to a VLAN, use the set service-profile name attr vlan-name vlanid command. Web-Portal users on wired authentication ports get their authorization attributes from the special user web-portal-wired. To assign wired Web-Portal users to a VLAN, use the set user web-portal-wired attr vlan-name vlanid command. By default, web-portal-wired users are assigned to the default VLAN.

Portal ACL The Portal ACL is created by MSS automatically. The portalacl ACL captures all the portal user traffic except for DHCP traffic. The portalacl has the following ACEs: set security acl ip portalacl permit udp 0.0.0.0 255.255.255.255 eq 68 0.0.0.0 255.255.255.255 eq 67 set security acl ip portalacl deny 0.0.0.0 255.255.255.255 capture MSS automatically creates the portalacl ACL the first time you set the fallthru authentication type on any service profile or wired authentication port to web-portal. The ACL is mapped to wireless Web-Portal users through the service profile. When you set the fallthru authentication type on a service profile to web-portal, portalacl is set as the Web-Portal ACL. The ACL is applied to a Web-Portal user traffic when the user associates with the service profile SSID. The ACL is mapped to Web-Portal users on a wired-authentication port by the Filter-id.in attribute configured on the web-portal-wired user. When you set the fallthru authentication type on a wired authentication port to web-portal, MSS creates the web-portal-wired user. MSS sets the filter-id attribute on the user to portalacl.in. Warning: Without the Web-Portal ACL, WebAAA users are placed on the network without any filters. Warning: Do not change the deny rule at the bottom of the Web-Portal ACL. This rule must be present and the capture option must be used with the rule. If the rule does not have the capture option, the Web Portal user never receives a login page. If you need to modify the Web-Portal ACL, create a new one instead, and modify the service profile or web-portal-wired user to use the new ACL. (See “Portal ACL and User ACLs” on page 1–436.)

Authentication rules A Web authentication rule must be configured for the WebAAA users. The Web rule must match on the username entered by the WebAAA user on the WebAAA login page. (The match can be on a userglob or individual username.) The Web rule also must match on the SSID the user uses to access the network. If the user accesses the network on a wired authentication port, the rule must match on wired. To configure authentication rules, use the set authentication web command. Web Portal WebAAA must be enabled, using the set web-portal command. The feature is enabled by default.

Portal ACL and User ACLs The portalacl ACL, which MSS creates automatically, applies only when a user session is in the portal state. After the user is authenticated and authorized, the ACL is no longer applicable.

436




To modify user access while the user is still being authenticated and authorized, you can configure another ACL and map that ACL to the service profile or the web-portal-wired user. Make sure to use the capture option for unauthorized traffic. Juniper Networks recommends that you do not change the portalacl ACL. Leave the ACL as a backup in case you need to refer to it or you need to use it again. For example, if a user is allowed to access a credit card server while MSS is still authenticating and authorizing the user, create a new ACL, add ACEs that are the same as the ACEs in portalacl, and add a new ACE before the last one, to allow access to the credit card server. Make sure the last ACE in the ACL is the deny ACE that captures all traffic that is not allowed by the other ACEs. To modify WebAAA user access after a user is authenticated and authorized, map an ACL to the individual WebAAA user. Changes made to the ACL mapped to the service profile or web-portal-wired user do not affect user access after authentication and authorization are complete. Informational Note: The filter-id attribute in a service profile applies only to authenticated users. If this attribute is set in a service profile for an SSID accessed by Web-Portal users, the attribute applies only after users have been authenticated. While a Web-Portal user is still being authenticated, the ACL set by the web-portal-acl applies instead.

Network Requirements The VLAN where users are placed must have an IP interface, and the subnet of the interface must have access to DHCP and DNS servers.

WLC Recommendations Consider installing a WebAAA certificate signed by a trusted CA, instead of one signed by the WLC. Unless the client browser is configured to trust the signature of the WebAAA certificate, display of the login page can take several seconds longer than usual, and might be interrupted by a dialogue box about the untrusted certificate. Generally, the browser is already configured to trust certificates signed by a CA.

Client NIC Recommendations Configure the NIC to use DHCP to obtain an IP address.

Client Web Browser Recommendations Use a well-known browser, such as Internet Explorer (Windows), Firefox (Mozilla-based), or Safari (Macintosh). If the WebAAA certificate on the WLC is self-signed, configure the browser to trust the signature by installing the certificate on the browser, so that the browser does not display a dialog about the certificate each time the user tries to log onto the network.

Configuring Web Portal WebAAA To configure Web Portal WebAAA: 1. Configure an SSID or wired authentication port and set the fallthru authentication type to web-portal. The default for SSIDs and for wired authentication ports is none.


Network Requirements

437

2. Configure individual WebAAA users. Because the VLAN is assigned based on the service profile with an attr vlan-name vlanid or web-portal-wired user (default), MSS ignores the VLAN-Name and Tunnel-Private-Group-ID attributes. However, MSS does assign other attributes if set. 3. Configure Web authentication rules for the WebAAA users. 4. Save the configuration changes.

Web Portal WebAAA Configuration Example This example configures Web-Portal access to SSID mycorp. 1. Configure the user VLAN on ports 2 and 3, and configure an IP interface on the VLAN: WLC# set vlan mycorp-vlan port 2-3 success: change accepted. WLC# set interface mycorp-vlan ip 192.168.12.10 255.255.255.0 success: change accepted. Informational Note: The VLAN does not need to be configured on the WLC with the Web Portal configuration but the VLAN does need to be configured on a WLC somewhere in the Mobility Domain. The user traffic is tunneled to the WLC with the VLAN configuration.

2. Configure the service profile for SSID mycorp. The configuration steps includes the following: Set the SSID name. Change the fallthru authentication type to web-portal. Set the default VLAN to mycorp-vlan (created in step 1.) MSS places Web-Portal users into this VLAN. Enable RSN (WPA2) data encryption with CCMP. (This example assumes clients support this encryption type.) TKIP is enabled by default and is left enabled in this example. WLC# set service-profile mycorp-srvcprof ssid-name mycorp success: change accepted. WLC# set service-profile mycorp-srvcprof auth-fallthru web-portal success: change accepted. WLC# set service-profile mycorp-srvcprof attr vlan-name mycorp-vlan success: change accepted. WLC# set service-profile mycorp-srvcprof rsn-ie enable success: change accepted. WLC# set service-profile mycorp-srvcprof cipher-ccmp enable success: change accepted. 3. Display the service profile to verify the changes: WLC# show service-profile mycorp-srvcprof ssid-name: Beacon: 438


mycorp yes

ssid-type: crypto Proxy ARP: no Copyright © 2013, Juniper Networks, Inc.


DHCP restrict:

no


5 none


yes

No broadcast: no Long retry limit: 5 Sygate On-Demand (SODA): no SODA remediation ACL:





Static COS: CAC mode:

no none

User idle timeout:

180

Keep initial vlan:

no

Web Portal ACL:


portalacl

WEP Key 1 value:

WEP Key 2 value:

WEP Key 3 value:

WEP Key 4 value:


1


NO

RSN enabled: ciphers: cipher-tkip, cipher-ccmp authentication: 802.1X TKIP countermeasures time: 60000ms vlan-name = mycorp-vlan 4. Configure individual WebAAA users. WLC# set user alice password alicepword success: change accepted. WLC# set user bob password bobpword success: change accepted. 5. Configure a Web authentication rule for WebAAA users. The following rule uses a wildcard (**) to match on all user names. The ** value makes all usernames eligible for authentication. In this case by searching the local database on the WLC for the matching usernames and passwords. If a username does not match on the access rule userglob, the user is denied access without searching the local database for the username and password. WLC# set authentication web ssid mycorp ** local success: change accepted. 6. Display the configuration: WLC# show config # Configuration nvgen'd at 2006-6-13 13:27:07 # Image 5.0.0.0.62 # Model WLCR-2



439

# Last change occurred at 2006-6-13 13:24:46 ... set service-profile mycorp-srvcprof ssid-name mycorp set service-profile mycorp-srvcprof auth-fallthru web-portal set service-profile mycorp-srvcprof rsn-ie enable set service-profile mycorp-srvcprof cipher-ccmp enable set service-profile mycorp-srvcprof web-portal-acl portalacl set service-profile mycorp-srvcprof attr vlan-name mycorp-vlan ... set authentication web ssid mycorp ** local ... set user alice password encrypted 070e2d454d0c091218000f set user bob password encrypted 110b16070705041e00 ... set radio-profile radprof1 service-profile mycorp-srvcprof set ap 7 radio 2 radio-profile radprof1 mode enable set ap 8 radio 2 radio-profile radprof1 mode enable ... set vlan corpvlan port 2-3 set interface corpvlan ip 192.168.12.10 255.255.255.0 ... set security acl ip portalacl permit udp 0.0.0.0 255.255.255.255 eq 68 0.0.0.0 255.255.255.255 eq 67 set security acl ip portalacl deny 0.0.0.0 255.255.255.255 capture commit security acl portalacl

External Captive Portal Support The ability to redirect Web portal authentication to a Web server on a network rather than a local WLC database or RADIUS is now available in MSS 7.0. The feature works in the following manner: A user connects to the local WLC with Web portal enabled. The WLC redirects the user via http or https to an external authentication Web server. Once the user credentials are verified, the external server sends a Change of Attribute (CoA) to the WLC. The CoA requests a change in the session username on the WLC. The Web server can also change or set any other allowed CoAs at the same time.

440

External Captive Portal Support



CLI Changes WLC200# set service-profile profile-name web-portal-form

Displaying Session Information for Web Portal WebAAA Users To display user session information for Web Portal WebAAA users, use the following command: show sessions network [user user-glob | mac-addr mac-addr-glob | ssid ssid-name | vlan vlan-glob | session-id session-id | wired] [verbose] You can determine if a Web Portal WebAAA user has completed the authentication and authorization process, by the username displayed in the session table. The following command shows the sessions for SSID mycorp. WLC# show sessions network ssid mycorp User Port/

Sess

Name Radio

ID

------------------------------ -------alice

IP or MAC

VLAN

Address

Name

----------------- ---------------

4* 192.168.12.101

corpvlan

5

corpvlan

3/1 web-portal-mycorp 3/1

192.168.12.102

2 sessions total This example shows two sessions. The session for alice has the user name and is flagged with an asterisk ( * ). The asterisk indicates that the user has completed authentication and authorization. The session for web-portal-mycorp indicates that a WebAAA user is on the network but is still being authenticated. The user alice has all the access privileges configured for the user, whereas the user on the portal session with the name web-portal-mycorp has limited access to resources. By default, this user can send and receive DHCP traffic only. Everything else is captured by the Web portal. After authentication and authorization are complete, the web-portal-mycorp username is replaced with the username entered by the WebAAA user during login. The following example shows session information for the same user, but after the user is authorized to access resources on the network: WLC# show sessions network ssid mycorp User

Sess

Name

ID

------------------------------ ----

IP or MAC

VLAN Port/

Address

Name Radio

----------------- ---------------

alice

4* 192.168.12.101

corpvlan

bob

5* 192.168.12.102

corpvlan

3/1 3/1

2 sessions total



441

Using a Custom Login Page By default, MSS displays the login page for Web login. Figure 1–3. Smart Mobile webAAA Login Page

MSS uses the following process to locate the login page to display to a user: If the user is attempting to access an SSID and a custom page is specified in the service profile, MSS serves the custom page. If the WLC nonvolatile storage has a page in web named wba_form.html (web/wba_form.html), MSS serves this page. This applies to all wired authentication users. The wba_form.html page also is served to SSID users if the SSID service profile does not specify a custom page. If there is no wba_form.html page and no custom page in the service profile of an SSID, MSS serves the default page.

442




Copying and Modifying the Web Login Page To copy and modify the Juniper Web login page: 1. Configure an unencrypted SSID on an WLC. The SSID is temporary and does not need to be one you intend to use in your network. To configure the SSID, use the following commands: set service-profile name ssid-name ssid-name set service-profile name ssid-type clear set service-profile name auth-fallthru web-portal set radio-profile name service-profile name set ap apnum radio {1 | 2} radio-profile name mode enable Informational Note: Use the first two commands to configure a temporary SSID and temporary radio profile. Use the last command to map the temporary radio profile with the disabled radio, and enable the radio.

Informational Note: If the radio you plan to use is already in service, you first disable the radio profile for the radio and remove the radio from the profile.

2. From your computer, attempt to access the temporary SSID. The WLC serves the login page. 3. Use your browser to save a copy of the page. 4. Use a Web page editor or text editor to modify the page title, greeting, logo, and warning text. 5. Save the modified page. Informational Note: Filenames and paths for image source files must be relative to the HTML page. For example, if login page mycorp-login.html and image file mylogo.gif are located in subdirectory mycorp/, specify the image source as mylogo.gif, not mycorp/mylogo.gif.

Customizing the Login Page Scenario 1. Do the following on the WLC: a. Create a temporary service profile and configure a temporary, clear SSID on it: WLC# set service-profile tempsrvc success: change accepted. WLC# set service-profile tempsrvc ssid-name tempssid success: change accepted. WLC# set service-profile tempsrvc ssid-type clear success: change accepted. WLC# set service-profile tempsrvc auth-fallthru web-portal success: change accepted. b. Create a temporary radio profile and map the temporary service profile to it: WLC# set radio-profile temprad service-profile tempsrvc success: change accepted. c.

Map a radio to the temporary radio profile and enable it: WLC# set ap 2 radio 1 radio-profile temprad mode enable



443

success: change accepted. d. From your PC, attempt to directly access the temporary SSID. The WLC serves the login page. e. In the browser, select File > Save As to save the login page. 2. Delete the temporary SSID, along with the temporary service profile and radio profile. WLC# set ap 2 radio 1 radio-profile temprad mode disable success: change accepted. WLC# clear radio-profile temprad success: change accepted. WLC# clear service-profile tempsrvc success: change accepted. 3. Edit the login page: a. Change the page title: My Corp webAAA b. Change the logo: c.

Change the greeting:
Welcome to Mycorp’s Wireless LAN

d. Change the warning statement if desired: WARNING: My corp’s warning text. e. Do not change the form (delimited by the and tags. The form values are required for the page to work properly. 4. Save the modified page. 5. On the WLC, create a new subdirectory for the customized page. (The files must be on a TFTP server that the WLC can access over the network.) WLC# mkdir mycorp-webaaa success: change accepted. 6. Copy the files for the customized page into the subdirectory: WLC# copy tftp://10.1.1.1/mycorp-login.html mycorp-webaaa/mycorp-login.html success: received 637 bytes in 0.253 seconds [ 2517 bytes/sec] WLC# copy tftp://10.1.1.1/mylogo.gif mycorp-webaaa/mylogo.gif success: received 1202 bytes in 0.402 seconds [ 2112 bytes/sec] WLC# dir mycorp-webaaa ========================================================================

444




file: Filename

Size

Created

file:mycorp-login.html

637 bytes

Aug 12 2004,

15:42:26 file:mylogo.gif

1202 bytes

Aug 12 2004,

15:57:11 Total:


7. Use the following command to configure the SSID to use the custom page: set service-profile name web-portal-form url For the url, specify the full path; for example, mycorp-webaaa/mycorp-login.html. If the custom login page includes *.gif or *.jpg images, their path names are interpreted relative to the directory from which the page is displayed. 8. Configure WebAAA users and rules as described in “Configuring Web Portal WebAAA” on page 1–437.

Using Dynamic Fields in WebAAA Redirect URLs You can include variables in the URL to redirect a WebAAA client. Table 13 lists the variables you can include in a redirect URL. Table 13.

Variables for Redirect URLs

Variable

Description

$u

Username of the Web AAA user

$v

VLAN assigned to the user during authorization

$s

SSID of the user

$p

Service profile name that manages the parameters for the SSID.

A URL string can also contain the literal characters $ and ?, if you use the values listed in Table 14. Table 14.

Values for Literal Characters

Variable

Description

$$

The literal character $

$q

The literal character ?

You can configure a redirect URL for a group of users or for an individual user. For example, the following command configures a redirect URL containing a variable for the username: WLC# set usergroup ancestors attr url http://myserver.com/$u.html success: change accepted. The variable applies to all WebAAA users in user group ancestors. When user zinjanthropus is successfully authenticated and authorized, MSS redirects the user to the following URL: http://myserver.com/zinjanthropus.html When user piltdown is successfully authenticated and authorized, MSS redirects the user to the following URL:



445

http://myserver.com/piltdown.html The following example configures a redirect URL that contains a script argument using the literal character ?: WLC# set usergroup ancestors attr url https://saqqara.org/login.php$quser=$u success: change accepted. When user djoser is successfully authenticated and authorized, MSS redirects the user to the following URL: https://saqqara.org/login.php?user=djoser To verify configuration of a redirect URL and other user attributes, use the show user command.

Logging Out of Web Portal Standardizing the logout URL serves as a backup for users to logout in case the logout window is closed inadvertently. However, the user is required to enter the username and password to logout because the logout window refers to a URL that contains a unique identifier for the session as a URL parameter. This identifier is not available to the WLC when the standard logout URL is accessed. Username and password are required to uniquely identify the login session. If there are more than one session with the same username, the WLC does not end any session. An administrator certificate is required on the WLC so that the logout process works.

Using an ACL Other Than portalacl By default, when you set the fallthru authentication type on a service profile or wired authentication port to web-portal, MSS creates an ACL called portalacl. MSS uses the portalacl ACL to filter Web-Portal user traffic while users are authenticating. To use another ACL: 1. Create a new ACL and add the first rule contained in portalacl: set security acl ip portalacl permit udp 0.0.0.0 255.255.255.255 eq 68 0.0.0.0 255.255.255.255 eq 67 set security acl ip portalacl deny 0.0.0.0 255.255.255.255 capture 2. Add the additional rules required for your application. For example, if you want to redirect users to a credit card server, add the necessary ACEs. 3. Add the last rule contained in portalacl: set security acl ip portalacl deny 0.0.0.0 255.255.255.255 capture 4. Verify the new ACL configuration, before committing it, using the following command: show security acl info [acl-name | all] [editbuffer]

446

Logging Out of Web Portal



5. Commit the new ACL to the configuration, using the following command: commit security acl 6. Change the Web-Portal ACL name set on the service profile, using the following command: set service-profile name web-portal-acl aclname 7. Verify the change by displaying the service profile. 8. Save the configuration changes.

Configuring the Web Portal WebAAA Session Timeout Period When a client that has connected through Web Portal, WebAAA enters standby or hibernation mode, and MSS may place the Web Portal WebAAA client session in the Disassociated state. A Web Portal WebAAA session can be placed in the Disassociated state under the following circumstances: The client has been idle for the User idle-timeout period. The client explicitly deassociates from the WLA by sending an 802.11 disassociate message The WLA handling the client session appears to be inoperative from the WLC. When a Web Portal WebAAA session enters the Disassociated state, it stays in that state until one of the following takes place: The client reappears on this WLA or another WLA managed by an WLC switch, at which time the Web Portal WebAAA session enters the Active state. The Web Portal WebAAA session is terminated by an administrator. The Web Portal WebAAA session timeout period expires, then the Web Portal WebAAA session is terminated automatically. By default, the Web Portal WebAAA session timeout period is 5 seconds. You can optionally change the length of the Web Portal WebAAA Session Timeout period. This can be useful if you want to allow a client connecting through Web Portal WebAAA to enter standby or hibernation mode, then resume the session after waking up, without logging in again. To change the Web Portal WebAAA session timeout period, use the following command: set service-profile name web-portal-session-timeout seconds You can specify from 5 – 28,800 seconds. The default is 5 seconds. Note that the Web Portal WebAAA session timeout period applies only to Web Portal WebAAA sessions already authenticated with a username and password. For all other Web Portal WebAAA sessions, the default Web Portal WebAAA session timeout period of 5 seconds is used.


Configuring the Web Portal WebAAA Session Timeout Period

447

Configuring the Web Portal WebAAA Logout Function You can configure Web Portal WebAAA to allow a user to manually terminate the session. When this feature is enabled, after a Web Portal WebAAA user is successfully authenticated and redirected to the requested page, a window appears behind the user browser. The window displays a button labeled “End Session”. When you click End Session, a URL is requested that terminates the user session on the Mobility Domain. The user logout request is sent to one of the WLC switches in the Mobility Domain. It does not have to be the WLC switch that the user was authenticated on, or the WLC where the user session currently resides. The WLC receiving the logout request determines which WLC has the user session. If it is a local session, the session is terminated. If another WLC in the Mobility Domain has the session, then the request is redirected to that WLC. Web Portal users no longer wait for the session to timeout before logging out of the WebAAA session, but manually log out of the network instead. To enable the Web Portal logout functionality, use the following command: set service-profile profile-name web-portal-logout mode {enable | disable} To specify a Web Portal logout URL, use the following command: set service-profile profile-name web-portal-logout logout-url url The URL should have the format https://host/logout.html. By default, the logout URL uses the IP address of the WLC as the host part of the URL. The host can be either an IP address or a hostname. Specifying the logout URL can be useful if you want to standardize across your network. For example, you can configure the logout URL on all of the WLC switches in the Mobility Domain as wifizone.trpz.com/logout.html, where wifizone.trpz.com resolves to one of the WLC switches, ideally the seed, in the Mobility Domain. To log out of the network, the user can click “End Session” in the window, or request the logout URL directly. Standardizing the logout URL provides a backup method for the user to log out if the window is closed inadvertently. Note that if you requests the logout URL, you must enter a username and password in order to identify the session on the WLC. (This is not necessary when you click “End Session” in the pop-under window.) Both the username and password are required to identify the session. If there is more than one session with the same username, then requesting the logout URL does not end any session. Also an administrative certificate must be configured on the WLC switches in order for the Web Portal WebAAA logout process to work.

448

Configuring the Web Portal WebAAA Logout Function



Configuring Last-Resort Access Users who are not authenticated and authorized by 802.1X methods or a MAC address can gain limited access to the network as guest users. You can configure an SSID to allow anonymous guest access, by setting the fallthru authentication type to last-resort. The authorization attributes assigned to last-resort users come from the default authorization attributes set on the SSID. To configure an SSID to allow last-resort access: Set the SSID name, if not already set. Set the fallthru access type of the SSID service profile to last-resort. Set the vlan-name and other authorization attributes on the SSID service profile. If the SSID type will be crypto (the default), configure encryption settings. You do not need to configure an access rule for last-resort access. Last-resort access is automatically enabled on all service profiles and wired authentication ports that have the fallthru authentication type set to last-resort. (The set authentication last-resort and clear authentication last-resort commands are not needed and are not supported in MSS Version 5.0 and later.) The authentication method for last-resort is always local. MSS does not use RADIUS for last-resort authentication. The following commands configure last-resort access for SSID guest-wlan. The service profile is configured to encrypt user traffic on the SSID using 40-bit dynamic WEP, WPA, or RSN, depending on the client configuration. WLC# set service-profile last-resort-srvcprof ssid-name guest-wlan success: change accepted. WLC# set service-profile last-resort-srvcprof auth-fallthru last-resort success: change accepted. WLC# set service-profile last-resort-srvcprof attr vlan-name guest-vlan success: change accepted. WLC# set service-profile last-resort-srvcprof rsn-ie enable success: change accepted. WLC# set service-profile last-resort-srvcprof wpa-ie enable success: change accepted. WLC# set service-profile last-resort-srvcprof cipher-ccmp enable success: change accepted. WLC2# set service-profile last-resort-srvcprof cipher-wep40 enable success: change accepted. WLC# show service-profile last-resort-srvcprof ssid-name: Beacon: DHCP restrict:


guest-wlan yes no

ssid-type: crypto Proxy ARP: no No broadcast: no

Configuring Last-Resort Access

449


5 last-resort


yes

Long retry limit: 5 Sygate On-Demand (SODA): no SODA remediation ACL:





Static COS: CAC mode:

no none

User idle timeout:

180

Keep initial vlan:

no



WEP Key 2 value:

WEP Key 3 value:

WEP Key 4 value:


1


NO

WPA and RSN enabled: ciphers: cipher-tkip, cipher-ccmp, cipher-wep40 authentication: 802.1X TKIP countermeasures time: 60000ms vlan-name = guest-vlan Informational Note: Beginning with MSS Version 5.0, the special user last-resort-ssid, where ssid is the SSID name, is not required and is not supported. If you upgrade a WLC with an earlier version of MSS to 5.0, the last-resort-ssid users are automatically removed from the configuration during the upgrade.

Configuring Last-Resort Access for Wired Authentication Ports To configure a wired authentication port to allow last-resort access: Set the fallthru authentication type on the port to last-resort. Create a user named last-resort-wired in the WLC local database. The following commands configure wired authentication port 5 for last-resort access and add the special user: WLC# set port type wired-auth 5 auth-fall-thru last-resort success: change accepted. WLC# set user last-resort-wired attr vlan-name guest-vlan2 success: change accepted.

450

Configuring Last-Resort Access


Configuring AAA for Users of Third-Party APs

Configuring AAA for Users of Third-Party APs Overview An WLC can provide network access for users associated with a third-party AP that has authenticated the users with RADIUS. You can connect a third-party AP to an WLC and configure the WLC to provide authorization for clients who authenticate and access the network through the AP. Figure 1–4 shows an example. Figure 1–4. WLC Serving as RADIUS Proxy

Authentication Process for Users of a Third-Party AP 1. MSS uses MAC authentication to authenticate the AP. 2. The user contacts the AP and negotiates the authentication protocol. 3. The AP, acting as a RADIUS client, sends a RADIUS access-request to the WLC. The access-request includes the SSID, the user MAC address, and the username. 4. For 802.1X users, the AP uses 802.1X to authenticate the user, using the WLC as its RADIUS server. The WLC proxies RADIUS requests from the AP to a RADIUS server, depending on the authentication method specified in the user proxy authentication rule. 5. After successful RADIUS authentication of the user (or special username, for non-802.1X users), MSS assigns authorization attributes to the user from the RADIUS server access-accept response. 6. When the user session ends, the third-party AP sends a RADIUS stop-accounting record to the WLC. The WLC then removes the session.

Third-Party AP Requirements The third-party AP must be connected to the WLC through a wired Layer 2 link. MSS cannot provide data services if the AP and WLC are in different Layer 3 subnets. The AP must be configured as a RADIUS client of the WLC. Copyright © 2013, Juniper Networks, Inc.

Overview

451

The AP must be configured so that all traffic for a given SSID is mapped to the same 802.1Q tagged VLAN. If the AP has multiple SSIDs, each SSID must use a different tag value. The AP must be configured to send the following information in a RADIUS access-request, for each user who wants to connect to the WLAN through the WLC switch: - SSID requested by the user. The SSID can be attached to the end of the called-station-id (per

Congdon), or can be in a VSA (for example, cisco-vsa:ssid=r12-cisco-1). - Calling-station-id that includes the user’s MAC address. The MAC address can be in any of the

following formats: - Separated by colons (for example, AA:BB:CC:DD:EE:FF) - Separated by dashes (for example, AA-BB-CC-DD-EE-FF) - Separated by dots (for example, AABB.CCDD.EEFF)

Username The AP must be configured to send a RADIUS stop-accounting record when a user session ends.

WLC Requirements The WLC port connected to the third-party AP must be configured as a wired authentication port. If SSID traffic from the AP is tagged, the same VLAN tag value must be used on the wired authentication port. A MAC authentication rule must be configured to authenticate the AP. The WLC must be configured as a RADIUS proxy for the AP. The WLC is a RADIUS server to the AP but remains a RADIUS client to the real RADIUS servers. Informational Note: The WLC system IP address must be the same as the IP address configured on the VLAN that contains the proxy port.

An authentication proxy rule must be configured for the AP clients. The rule matches based on SSID and username, and selects the authentication method (a RADIUS server group) for proxying.

RADIUS Server Requirements For 802.1X users, the usernames and passwords must be configured on the RADIUS server. For non-802.1X users of a tagged SSID, the special username web-portal-ssid or last-resort-ssid must be configured, where ssid is the SSID name. The fallthru authentication type (web-portal or last-resort) specified for the wired authentication port connected to the AP determines which username you need to configure. For any users of an untagged SSID, the special username web-portal-wired or last-resort-wired must be configured, depending on the fallthru authentication type specified for the wired authentication port.

452

Third-Party AP Requirements



Configuring Authentication Third-Party APs with Tagged SSIDs To configure MSS to authenticate 802.1X users of a third-party AP, use the following commands to do the following: Configure the port connected to the AP as a wired authentication port. Use the following command: set port type wired-auth port-list [tag tag-list] [max-sessions num] [auth-fall-thru {last-resort | none | web-portal}] Configure a MAC authentication rule for the AP. Use the following command: set authentication mac wired mac-addr-glob method1 Configure the WLC port connected to the AP as a RADIUS proxy for the SSID supported by the AP. If SSID traffic from the AP is tagged, assign the same tag value to the WLC port. Use the following command: set radius proxy port port-list [tag tag-value] ssid ssid-name Add a RADIUS proxy entry for the AP. The proxy entry specifies the IP address of the AP and the UDP ports that the WLC listens for RADIUS access-requests and stop-accounting records from the AP. Use the following command: set radius proxy client address ip-address [port udp-port-number] [acct-port acct-udp-port-number] key string Configure a proxy authentication rule for users on the AP. Use the following command: set authentication proxy ssid ssid-name user-glob radius-server-group For the port-list of the set port type wired-auth and set radius proxy port commands, specify the WLC port(s) connected to the third-party AP. For the ip-address of the set radius proxy client address command, specify the IP address of the RADIUS client (the third-party AP). For the udp-port-number, specify the UDP port on which the WLC listens for RADIUS access-requests. The default is UDP port 1812. For the acct-udp-port-number, specify the UDP port on which the WLC listens for RADIUS stop-accounting records. The default is UDP port 1813. The following command configures WLC ports 3 and 4 as wired authentication ports, and assigns tag value 104 to the ports: WLC# set port type wired-auth 3-4 tag 104 success: change accepted. You can specify multiple tag values. Specify the tag value for each SSID you plan to support.


Configuring Authentication Third-Party APs with Tagged SSIDs

453

The following command configures a MAC authentication rule that matches on the third-party AP MAC address. Because the AP is connected to the WLC on a wired authentication port, the wired option is used. WLC# set authentication mac wired aa:bb:cc:01:01:01 srvrgrp1 success: change accepted. The following command maps SSID mycorp to packets received on port 3 or 4, using 802.1Q tag value 104: WLC# set radius proxy port 3-4 tag 104 ssid mycorp success: change accepted. Enter a separate command for each SSID, and the tag value supported by the WLC. The following command configures a RADIUS proxy entry for a third-party AP RADIUS client at 10.20.20.9, sending RADIUS traffic to the default UDP ports 1812 and 1813 on the WLC: WLC# set radius proxy client address 10.20.20.9 key radkey1 success: change accepted. The IP address is the IP address of the AP. The key is the shared secret configured on the RADIUS servers. MSS uses the shared secret to authenticate and encrypt RADIUS communication. The following command configures a proxy authentication rule that matches on all usernames associated with SSID mycorp. MSS uses RADIUS server group srvrgrp1 to proxy RADIUS requests and hence to authenticate and authorize the users. WLC# set authentication proxy ssid mycorp ** srvrgrp1

Informational Note: MSS also uses the server group specified with this command for accounting.

To verify the changes, use the show config area aaa command.

Configuring Authentication — Non-802.1X Users of a Third-Party AP, Tagged SSIDs To configure MSS to authenticate non-802.1X users of a third-party AP, use the same commands as those required for 802.1X users. Additionally, when configuring the wired authentication port, use the auth-fall-thru option to change the fallthru authentication type to last-resort or web-portal. On the RADIUS server, configure username web-portal-ssid or last-resort-ssid, depending on the fallthru authentication type you specify for the wired authentication port.

454

Configuring Authentication — Non-802.1X Users of a Third-Party AP, Tagged SSIDs



Configuring Access for Any Users of a Non-Tagged SSID If SSID traffic from the third-party AP is untagged, use the same configuration commands as the ones required for 802.1X users, except the set radius proxy port command. This command is not required and is not applicable to untagged SSID traffic. In addition, when configuring the wired authentication port, use the auth-fall-thru option to change the fallthru authentication type to last-resort or web-portal. On the RADIUS server, configure the username web-portal-wired or last-resort-wired, depending on the fallthru authentication type specified for the wired authentication port.


Configuring Access for Any Users of a Non-Tagged SSID

455

456

Configuring Access for Any Users of a Non-Tagged SSID


Assigning Authorization Attributes

Assigning Authorization Attributes Overview Authorization attributes can be assigned to users in the local database, on remote servers, or in the service profile of an SSID. The attributes, which include access control list (ACL) filters, VLAN membership, encryption type, session time-out period, and other session characteristics, let you control how and when users access the network. When a user or group is authenticated, the local database, RADIUS server, or service profile passes the authorization attributes to MSS to characterize the user session. If attributes are configured for a user and also for a user group, the attributes assigned to the individual user take precedence. For example, if the start-date attribute configured for a user is earlier than the start-date configured for the user group, network access for the user can begin as soon as the user start-date. The user does not need to wait for the user group start date. The VLAN attribute is required. A user can access the network only if the user VLAN is specified. Table 15 lists the authorization attributes supported by MSS. (For brief descriptions of all the RADIUS attributes and Juniper vendor-specific attributes supported by MSS, as well as the vendor ID and types for Juniper VSAs configured on a RADIUS server, see the Juniper Networks Mobility System Software Basic Configuration Guide.) Table 15.

Authentication Attributes for Local Users

Attribute

Description

Valid Value(s) One of the following numbers that identifies an encryption algorithm:

encryption-type

Type of encryption required for access by the client. Clients who attempt to use an unauthorized encryption method are rejected.

end-date

Date and time after which the user is no longer allowed on the network.

1—AES_CCM (Advanced Encryption Standard using Counter with CBC-MAC) 2—Reserved 4—TKIP (Temporal Key Integrity Protocol) 8—WEP_104 (the default) (Wired-Equivalent Privacy protocol using 104 bits of key strength) 16—WEP_40 (Wired-Equivalent Privacy protocol using 40 bits of key strength) 32—NONE (no encryption) 64—Static WEP In addition to these values, you can specify a sum of them for a combination of allowed encryption types. For example, to specify WEP_104 and WEP_40, use 24. Date and time, in the following format:


YY/MM/DD-HH:MM You can use end-date alone or with start-date. You also can use start-date, end-date, or both in conjunction with time-of-day.

Overview

457

Table 15.

Authentication Attributes for Local Users (continued)

Attribute

Description

filter-id

Security access control list (ACL), to Name of an existing security ACL, up to 253 alphanumeric permit or deny traffic received (input) or characters, with no tabs or spaces. sent (output) by the WLC switch. Use acl-name.in to filter traffic that enters the WLC from users via an WLA access port or wired authentication port, or from the (For more information about security network via a network port. ACLs, see “Configuring and Managing Use acl-name.out to filter traffic sent from the WLC to users via an Security ACLs” on page 1–903.) WLA access port or wired authentication port, or from the network via a network port.

(network access mode only)

Valid Value(s)

Note: If the Filter-Id value returned through the authentication and authorization process does not match the name of a committed security ACL in the WLC, the user fails authorization and is unable to authenticate. idle-timeout

This option is not implemented in the current MSS version.

mobility-profile

Mobility Profile attribute for the user. (For more information, see “Configuring a Mobility Profile” on page 1–479.)

(network access mode only)

service-type

Type of access the user is requesting.

Name of an existing Mobility Profile, which can be up to 32 alphanumeric characters, with no tabs or spaces.

Note: If the Mobility Profile feature is enabled, and a user is assigned the name of a Mobility Profile that does not exist on the WLC switch, the user is denied access. One of the following numbers: 2—Framed; for network user access 6—Administrative; for administrative access to the WLC, with authorization to access the enabled (configuration) mode. The user must enter the enable command and the correct enable password to access the enabled mode. 7—NAS-Prompt; for administrative access to the nonenabled mode only. In this mode, the user cannot enter the enable command and the enable password to access the enabled mode. For administrative sessions, the WLC always sends 6 (Administrative). The RADIUS server can reply with one of the values listed above. If the service-type is not set on the RADIUS server, administrative users receive NAS-Prompt access, and network users receive Framed access.

Note: MSS quietly accepts Callback Framed but you cannot select this access type in MSS. session-timeout (network access mode only)

Maximum number of seconds for the user’s session.

Number between 0 and 4,294,967,296 seconds (approximately 136.2 years).

Note: If the global reauthentication timeout (set by the set dot1x reauth-period command) is shorter than the session-timeout, MSS uses the global timeout instead. ssid (network access mode only)

458

Overview

SSID the user is allowed to access after authentication.

Name of the SSID for the user. The SSID must be configured in a service profile, and the service profile must be used by a radio profile assigned to Juniper radios in the Mobility Domain.



Table 15.


Attribute

start-date

Description

Valid Value(s)

Date and time at which the user becomes eligible to access the network.

Date and time, in the following format:

YY/MM/DD-HH:MM MSS does not authenticate the user unless the attempt to access the You can use start-date alone or with end-date. You also can use network occurs at or after the specified start-date, end-date, or both in conjunction with time-of-day. date and time, but before the end-date (if specified). One of the following: never—Access is always denied. any—Access is always allowed. al—Access is always allowed. One or more ranges of values that consist of one of the following day designations (required), and a time range in hhmm-hhmm 4-digit 24-hour format (optional): − mo—Monday − tu—Tuesday − we—Wednesday

time-of-day (network access mode only)

Day(s) and time(s) during which the user is permitted to log into the network. After authorization, the user session can last until either the Time-Of-Day range or the Session-Timeout duration (if set) expires, whichever is shorter.

− th—Thursday − fr—Friday − sa—Saturday − su—Sunday − wk—Any day between Monday and Friday

Separate values or a series of ranges (except time ranges) with commas (,) or a vertical bar (|). Do not use spaces. The maximum number of characters is 253. For example, to allow access only on Tuesdays and Thursdays between 10 a.m. and 4 p.m., specify the following: time-of-day tu1000-1600,th1000-1600 To allow access only on weekdays between 9 a.m and 5 p.m., and on Saturdays from 10 p.m. until 2 a.m., specify the following: time-of-day wk0900-1700,sa2200-0200

Note: You can use time-of-day in conjunction with start-date, end-date, or both. Web URL, in standard format. For example: http://www.example.com

Note: You must include the http:// portion. url (network access mode only)

URL to which the user is redirected after successful WebAAA.

You can dynamically include any of the variables in the URL string: $u—Username $v—VLAN $s—SSID $p—Service profile name To use the literal character $ or ?, use the following: $$ $q


Overview

459

Table 15.


Attribute

Description

Valid Value(s)

Virtual LAN (VLAN) assignment. vlan-name (network access mode only)

Note: On some RADIUS servers, you might need to use the standard RADIUS attribute Tunnel-Pvt-Group-ID, instead of VLAN-Name.

Name of a VLAN for the user. The VLAN must be configured on an WLC within the Mobility Domain.

Number between 180 and 3,600 seconds, or 0 to disable periodic accounting updates. acct-interim-interv al

Interval in seconds between accounting updates, if start-stop accounting mode is enabled.

The WLC ignores the acct-interim-interval value and issues a log message if the value is below 60 seconds.

Note: If both a RADIUS server and the WLC supply a value for the acct-interim-interval attribute, then the value from the WLC takes precedence.

Assigning Attributes to Users and Groups You can assign authorization attributes to individual users or groups of users. Use any of the following commands to assign an attribute to a user or group in the local WLC database and specify the value: set user username attr attribute-name value set usergroup group-name attr attribute-name value set mac-user mac-addr attr attribute-name value set mac-usergroup group-name attr attribute-name value To change the value of an authorization attribute, reenter the command with the new value. If configured, usernames are now part of the show output command such as show sessions: WLC# show sessions UserName-----------------SessID--------Type----------Adress-------VLANName------AP/Radio--engineering-05:0c:78 5/1

28*

open

10.7.255.2

engineering-79:86:73 red 2/1

29*

open

10.7.254.3

engineering-1a:68:78 red 7/1

30*

open

10.7.254.8

engineering-45:12:34 blue 2/1

35*

open

10.9.254.7

yellow

Since the session username is replaced by the user-name attribute, the show sessions output displays this attribute as the username for the session. When the attribute is obtained from a user group, the user name of all users in the group appears the same and you cannot differentiate between them. However, the MAC address is added to the user group name in the output. The corresponding clear commands are also available: 460

Overview



WLC# clear user username attr user-name success: change accepted WLC# clear usergroup name attr attribute value To assign an authorization attribute to a user configuration on a RADIUS server, see the documentation for your RADIUS server.

Adding Accounting Interval Attribute You can now add the attribute, acct-interim-interval, to a service profile. The value can be from 180 to 3600 seconds. As with other AAA attributes, the value received from AAA overrides the value configured in the service profile. To add the attribute to a service profile, use the following command: WLC# set service-profile profile-name attr acct-interim-interval 180 If you set the interval to zero (0), the feature is disabled and no periodic updates are received.

Simultaneous Login Support As part of the AAA enhancements to this version of software, you can now limit the number of concurrent sessions that a user can have on the network. You can use a Vendor-specific Attribute (VSA) on a RADIUS server or configure it as part of a service profile. You can also apply the attribute to users and user groups. To configure simultaneous login events for a user, enter the following command: WLC# set user username attr simultaneous-logins If you set the attribute to 0, then the user is locked out of the network. The default value is unlimited access. In addition, setting this value applies only to user session in the mobility domain and not a specific WLC. Additional commands include the following: WLC200# set usergroup group attr simultaneous-logins 0-1000 WLC200# set service-profile profile-name attr simultaneous-logins 0-1000 To clear the configuration, enter WLC200# clear user username> attr simultaneous-logins


Overview

461

Assigning SSID Default Attributes to a Service Profile You can configure a service profile with a set of default AAA authorization attributes used when the normal AAA process or a location policy does not provide them. These authorization attributes are applied by default to users accessing the SSID managed by the service profile. Use the following command to assign an authorization attribute to a service profile and specify a value: set service-profile profile-name attr attribute-name value By default, a service profile contains no SSID default authorization attributes. When specified, attributes in a service profile are applied in addition to any attributes supplied for the user by the RADIUS server or the local database. When the same attribute is specified both as an SSID default attribute and through AAA, then the attribute supplied by the RADIUS server or the local database takes precedence over the SSID default attribute. If a location policy is configured, the location policy takes precedence over both AAA and SSID default attributes. The SSID default attributes serve as a fallback when neither the AAA process, nor a location policy, provides them. For example, a service profile might be configured with the service-type attribute set to 2. If a user accessing the SSID is authenticated by a RADIUS server, and the RADIUS server returns the vlan-name attribute set to orange, then that user has a total of two attributes set: service-type and vlan-name. If the service profile is configured with the vlan-name attribute set to blue, and the RADIUS server returns the vlan-name attribute set to orange, then the attribute from the RADIUS server takes precedence; the user is placed in the orange VLAN. You can display the attributes for each connected user and whether they are set through AAA or through SSID defaults by entering the show sessions network verbose command. You can display the configured SSID defaults by entering the show service-profile command. All of the authorization attributes listed in Table 15 on page 457 can be specified in a service profile except ssid.

Assigning a Security ACL to a User or a Group Once a security access control list (ACL) is defined and committed, it can be applied dynamically and automatically to users and user groups through the 802.1X authentication and authorization process. When you assign a Filter-Id attribute to a user or group, the security ACL name value is entered as an authorization attribute into the user or group record in the local WLC database or RADIUS server. Informational Note: If the Filter-Id value returned through the authentication and authorization process does not match the name of a committed security ACL in the WLC, the user fails authorization and cannot be connected.

Informational Note: For details about security ACLs, see “Configuring and Managing Security ACLs” on page 1–903

462

Assigning SSID Default Attributes to a Service Profile



Assigning a Security ACL Locally To use the local WLC database to restrict a user, a MAC user, or a group of users or MAC users to the permissions stored within a committed security ACL, use the following commands: Table 16.

Security ACL Commands

Security ACL Target

Commands

User authenticated by a password

set user username attr filter-id acl-name.in set user username attr filter-id acl-name.out

Group of users authenticated by a password

set usergroup groupname attr filter-id acl-name.in

User authenticated by a MAC address

set mac-user username attr filter-id acl-name.in

set usergroup groupname attr filter-id acl-name.out

set mac-user username attr filter-id acl-name.out Group of users authenticated by a MAC address

set mac-usergroup groupname attr filter-id acl-name.in set mac-usergroup groupname attr filter-id acl-name.out

You can set filters for incoming and outgoing packets: Use acl-name.in to filter traffic that enters the WLC from users via an WLA access port or wired authentication port, or from the network via a network port. Use acl-name.out to filter traffic sent from the WLC to users via an WLA access port or wired authentication port, or from the network via a network port. For example, the following command applies security ACL acl-101 to packets coming into the WLC from user joe: WLC# set user joe attr filter-id acl-101.in success: change accepted. The following command applies the incoming filters of acl-101 to the users who belong to the group eastcoasters: WLC# set usergroup eastcoasters attr filter-id acl-101.in success: change accepted.

Assigning a Security ACL on a RADIUS Server To assign a security ACL name as the Filter-Id authorization attribute of a user or group record on a RADIUS server, see the documentation for your RADIUS server.

Clearing a Security ACL from a User or Group To clear a security ACL from the profile of a user, MAC user, or group of users or MAC users in the local WLC database, use the following commands: clear user username attr filter-id clear usergroup groupname attr filter-id clear mac-user username attr filter-id clear mac-usergroup groupname attr filter-id



463

If you have assigned both an incoming and an outgoing filter to a user or group, enter the appropriate command twice to delete both security ACLs. Verify the deletions by entering the show commands for each component and checking the output. To delete a security ACL from a user configuration on a RADIUS server, see the documentation for your RADIUS server.

Assigning Encryption Types to Wireless Users When a user turns on a wireless laptop or PDA, the device attempts to find an access point and associate with it. Because WLAs support wireless traffic encryption, clients can select an encryption type to use on their device. You can configure WLAs to use the encryption algorithms supported by the Wi-Fi Protected Access (WPA) security enhancement to the IEEE 802.11 wireless standard. If you have configured WLAs to use specific encryption algorithms, you can enforce the type of encryption a user or group must have to access the network. When you assign the Encryption-Type attribute to a user or group, the encryption type or types are entered as an authorization attribute into the user or group record in the local WLC database or on the RADIUS server. Encryption-Type is a Juniper vendor-specific attribute (VSA). Clients attempting to use an unauthorized encryption method are rejected.

Assigning and Clearing Encryption Types Locally To restrict wireless uses or groups with user profiles in the local WLC database to particular encryption algorithms for accessing the network, use one of the following commands: set user username attr encryption-type value set usergroup groupname attr encryption-type value set mac-user username attr encryption-type value set mac-user mac-glob attr value set mac-usergroup groupname attr encryption-type value MSS supports the following values for Encryption-Type, listed from most secure to least secure. Table 17.

Encryption-Type Values

Encryption-Type Value

Encryption Algorithm Assigned

1

Advanced Encryption Standard using Counter with Cipher Block Chaining Message Authentication Code (CBC-MAC)— or AES_CCM.

2

Reserved.

4

Temporal Key Integrity Protocol (TKIP).

8

Wired-Equivalent Privacy protocol using 104 bits of key strength (WEP_104). This is the default.

16

Wired-Equivalent Privacy protocol using 40 bits of key strength (WEP_40).

32

No encryption.

64

Static WEP

For example, the following command restricts the MAC user group mac-fans to access the network by using only TKIP: 464




WLC# set mac-usergroup mac-fans attr encryption-type 4 success: change accepted. You can also specify a combination of allowed encryption types by adding the values together. For example, the following command allows mac-fans to associate using either TKIP (4) or WEP_104 (8): WLC# set mac-usergroup mac-fans attr encryption-type 12 success: change accepted. To clear an encryption type from the profile of a use or group of users in the local WLC database, use one of the following commands: clear user username attr encryption-type clear usergroup groupname attr encryption-type clear mac-user username attr encryption-type clear mac-user mac-glob clear mac-usergroup groupname attr encryption-type

Assigning and Clearing Encryption Types on a RADIUS Server To assign or delete an encryption algorithm as the Encryption-Type authorization attribute in a user or group record on a RADIUS server, see the documentation for your RADIUS server.

Keeping Users on the Same VLAN Even After Roaming In some cases, a user is assigned to a different VLAN after roaming to another WLC. Table 18 lists the ways a VLAN is assigned to a user after roaming from one WLC to another. Table 18.

VLAN Assignment After Roaming from One WLC to Another

Location Policy

AAA

keep-initial-vlan

SSID

VLAN Assigned By...

Yes

Yes or No

Yes or No

Yes or No

location policy

No

Yes

Yes or No

Yes or No

AAA

No

No

Yes

Yes or No

keep-initial-vlan

No

No

No

Yes

SSID

No

No

No

No

Not set—authentication error

Yes in the table means the VLAN is set on the roamed-to WLC, by the mechanism indicated by the column header. No means the VLAN is not set. Yes or No means the mechanism does not affect the outcome, because another mechanism is set. The VLAN Assigned By column indicates the mechanism used by the roamed-to WLC to assign the VLAN, based on the various ways the VLAN is set on that WLC. Location Policy means the VLAN is assigned by a location policy on the roamed-to WLC. (The VLAN is assigned by the vlan vlanid option of the set location policy permit command.) AAA means the Vlan-name attribute is set on for the user or the user group, in the roamed-to WLC local database or on a RADIUS server used by the roamed-to WLC to authenticate the user. (The VLAN is assigned by the vlan-name vlanid option of the set user attr, set usergroup attr, set mac-user, or set mac-usergroup command.) Copyright © 2013, Juniper Networks, Inc.


465

keep-initial-vlan means that the VLAN is not reassigned. Instead, the VLAN assigned on the first WLC is retained. (The keep-initial-vlan option is enabled by the set service-profile name keep-initial-vlan enable command, entered on the roamed-to WLC. The name is the name of the service profile for the associated user SSID.) SSID means the VLAN is set on the roamed-to WLC, in the service profile for the associated user SSID. (The Vlan-name attribute is set by the set service-profile name attr vlan-name vlanid command, entered on the roamed-to WLC. The name is the name of the service profile for the SSID the user is associated with.) As shown in Table 18, even when keep-initial-vlan is set, a user VLAN can be reassigned by AAA or a location policy. Informational Note: The keep-initial-vlan option does not apply to Web-Portal clients. Instead, VLAN assignment for roaming Web-Portal clients automatically works as when keep-initial-vlan is enabled. The VLAN initially assigned to a Web-Portal user is not changed except by a location policy, AAA, or SSID default setting on the roamed-to switch.

To enable keep-initial-vlan, use the following command: set service-profile name keep-initial-vlan {enable | disable} Enter this command on the WLC configured for roaming by users. The following command enables the keep-initial-vlan option on service profile sp3: WLC# set service-profile sp3 keep-initial-vlan enable success: change accepted.

Overriding or Adding Attributes Locally with a Location Policy During the login process, the AAA authorization process is started immediately after clients are authenticated on the WLC. During authorization, MSS assigns the user to a VLAN and applies optional user attributes, such as a session timeout value and one or more security ACL filters. A location policy is a set of rules that enables you to locally set or change user authorization attributes after the user is authorized by AAA, without making changes to the AAA server. For example, you might want to enforce VLAN membership and security ACL policies on a particular WLC based on a client organization or physical location, or assign a VLAN to users without AAA assignment. For these situations, you can configure the location policy on the WLC. You can use a location policy to locally set or change the Filter-Id and VLAN-Name authorization attributes obtained from AAA.

About the Location Policy Each WLC can have one location policy. The location policy consists of a set of rules. Each rule contains conditions, and an action to perform if all conditions in the rule match. The location policy can contain up to 150 rules. The action can be one of the following:

466

Overriding or Adding Attributes Locally with a Location Policy



Deny access to the network. Permit access, but set or change the user VLAN assignment, inbound ACL, outbound ACL, or any combination of these attributes. The conditions can be one or more of the following: AAA-assigned VLAN Username WLA access port, Distributed WLA number, or wired authentication port through which the user accessed the network SSID name with which the user is associated Day of the week or time of day Conditions within a rule are inclusive. All conditions in the rule must match in order for MSS to take the specified action. If the location policy contains multiple rules, MSS compares the user information to the rules one at a time, in the order the rules appear in the WLC configuration file, beginning with the rule at the top of the list. MSS continues comparing until a user matches all conditions in a rule or until there are no more rules. Any authorization attributes not changed by the location policy remain active.

How the Location Policy Differs from a Security ACL Although structurally similar, the location policy and security ACLs have different functions. The location policy on an WLC can be used to locally redirect a user to a different VLAN or locally control the traffic to and from a user. In contrast, security ACLs are packet filters applied to the user throughout a Mobility Domain.

Setting the Location Policy To enable the location policy function on an WLC, you must create at least one location policy rule with one of the following commands: set location policy deny if {ssid operator ssid-name | time-of-day operator time-of-day | vlan operator vlan-glob | user operator user-glob | port port-list | ap apnum [before rule-number | modify rule-number] set location policy permit {vlan vlan-name | inacl inacl-name | outacl outacl-name} if {ssid operator ssid-name | vlan operator vlan-glob | user operator user-glob | port port-list | ap apnum [before rule-number | modify rule-number] Informational Note: Asterisks (wildcards) are not supported in SSID names. You must specify the complete SSID name.

You must specify whether to permit or deny access, and you must identify a VLAN, username, or access port to match. Use one of the following operators to specify how the rule must match the VLAN or username: Copyright © 2013, Juniper Networks, Inc.


467

eq—Applies the location policy rule to all users assigned VLAN names matching vlan-glob or having usernames that match user-glob. neq—Applies the location policy rule to all users assigned VLAN names not matching vlan-glob or having usernames that do not match user-glob. For example, the following command denies network access to all users matching *.theirfirm.com, causing them to fail authorization: WLC# set location policy deny if user eq *.theirfirm.com The following command authorizes access to the guest_1 VLAN for all users who do not match *.ourfirm.com: WLC# set location policy permit vlan guest_1 if user neq *.ourfirm.com The following command places all users who are authorized for SSID tempvendor_a into VLAN kiosk_1: WLC# set location policy permit vlan kiosk_1 if ssid eq tempvendor_a success: change accepted.

Applying Security ACLs in a Location Policy Rule When reassigning security ACL filters, specify if the filter is an input or an output filter, as follows: Input filter—Use inacl inacl-name to filter user traffic that enters the WLC on an WLA access port or wired authentication port, or from the network via a network port. Output filter—Use outacl outacl-name to filter traffic sent from the WLC to users via an WLA access port or wired authentication port, or from the network via a network port. For example, the following command authorizes users at *.ny.ourfirm.com to access the bld4.tac VLAN, and applies the security ACL tac_24 to the traffic they receive: WLC# set location policy permit vlan bld4.tac outacl tac_24 if user eq *.ny.ourfirm.com The following command authorizes access to users on VLANs with names matching bld4.* and applies security ACLs svcs_2 to the traffic they send and svcs_3 to the traffic they receive: WLC# set location policy permit inacl svcs_2 outacl svcs_3 if vlan eq bldg4.* You can optionally add the suffixes .in and .out to inacl-name and outacl-name for consistency with entries stored in the local WLC database.

Displaying and Positioning Location Policy Rules The order of location policy rules is significant. MSS checks a location policy rule that is higher in the list before those lower in the list. Rules are listed in the order that you create them, unless you move the rule. To position location policy rules within the location policy, use before rule-number and modify rule-number in the set location policy command, or use the clear location policy rule-number command. For example, suppose you have configured the following location policy rules: WLC show location policy Id Clauses

468




---------------------------------------------------------------1) deny if user eq *.theirfirm.com 2) permit vlan guest_1 if vlan neq *.ourfirm.com 3) permit vlan bld4.tac inacl tac_24.in if user eq *.ny.ourfirm.com 4) permit inacl svcs_2.in outacl svcs_3.out if vlan eq bldg4.* To move the first rule to the end of the list and display the results, type the following commands: WLC clear location policy 1 success: clause 1 is removed. WLC set location policy deny if user eq *.theirfirm.com WLC show location policy Id Clauses ---------------------------------------------------------------1) permit vlan guest_1 if vlan neq *.ourfirm.com 2) permit vlan bld4.tac inacl tac_24.in if user eq *.ny.ourfirm.com 3) permit inacl svcs_2.in outacl svcs_3.out if vlan eq bldg4.* 4) deny if user eq *.theirfirm.com

Clearing Location Policy Rules and Disabling the Location Policy To delete a location policy rule, use the following command: clear location policy rule-number Type show location policy to display the numbers of configured location policy rules. To disable the location policy on an WLC, delete all the location policy rules.



469

470



Configuring Accounting for Wireless Network Users

Configuring Accounting for Wireless Network Users Overview Accounting records come in three types: start, stop, and update. MSS generates these records based on the configured accounting mode, either start-stop or stop-only: When start-stop mode is configured, a start record is generated when a user is first connected, and an update record is generated when a user roams from one WLA access point to another. A stop record is generated when a user terminates the session. When stop-only mode is configured, a stop record is generated when a user terminates the session. Optionally, MSS can be configured to send update records at periodic intervals, and also generate an Accounting-On message when the WLC starts, and an Accounting-Off message when the WLC is administratively shut down. This functionality can be used in conjunction with billing systems that require periodic accounting messages. To set accounting, type the following command: set accounting {admin | console | dot1x | mac | web | last-resort} {ssid ssid-name | wired} {user-glob | mac-addr-glob} {start-stop | stop-only} method1 [method2] [method3] [method4] For example, to store start-stop accounting records at example.com for 802.1X users of SSID mycorp in the local database, type the following command: WLC# set accounting dot1x ssid mycorp *@example.com start-stop local success: change accepted. The accounting records can contain the following session information: Table 19.

Accounting Record Session Information

Start Records

Update and Stop Records

Session date and time

Session date and time

Location of authentication (if any): RADIUS server (1) or local database (2)

Location of authentication (if any): RADIUS server (1) or local database (2)

ID for related sessions

ID for related sessions

Username

Username

Session duration

Session duration

Timestamp

Timestamp

VLAN name

VLAN name

Client MAC address

Client’s MAC address

WLA port number and radio number

WLA port number and radio number WLA access point’s MAC address Number of octets received by the WLC

WLA access point MAC address

Number of octets sent by the WLC Number of packets received by the WLC Number of packets sent by the WLC


Overview

471

Informational Note: For details about show accounting statistics output, see the Juniper Mobility System Software Command Reference. For information about accounting update records, see “Viewing Roaming Accounting Records” on page 1–473. To configure accounting on a RADIUS server, see the documentation for your RADIUS server.

Configuring Periodic Accounting Update Records If you have configured MSS to use start-stop mode, by default accounting update records are generated when a user roams from one WLA to another. Optionally, MSS can generate update records at specified periodic intervals. This can be done in one of the following ways: By specifying a value for the acct-interim-interval attribute on the RADIUS server. If the RADIUS server access-accept response contains this attribute, then MSS generates update records for the user session at the specified interval. By specifying a value for the acct-interim-interval attribute for the user on the WLC. See the description of the acct-interim-interval attribute in Table 15, “Authentication Attributes for Local Users,” on page 457. If both the RADIUS server and the WLC supply a value for the user acct-interim-interval attribute, then the value from the WLC takes precedence. If there is no acct-interim-interval attribute value set, or it is set to zero on the WLC, then accounting update records are generated only when a user roams from one WLA to another.

Enabling System Accounting Messages You can configure MSS to send an Accounting-On message (Acct-Status-Type = 7) to the RADIUS server when the WLC switch starts, and an Accounting-Off message (Acct-Status-Type = 8) to the RADIUS server when the WLC switch is administratively shut down. To do this, use the following command: set accounting system method1 [method2] [method3] [method4] For example, the following command causes Accounting-On and Accounting-Off messages to be sent to RADIUS server group shorebirds: WLC# set accounting system shorebirds success: change accepted. Note that local is not a valid method for this command. When you enter this command, an Accounting-On message is generated and sent to the specified server or server group. Subsequent Accounting-On messages are generated each time the WLC starts. When the WLC is administratively shut down, an Accounting-Off message is generated. Accounting-Off messages are sent only when the WLC is administratively shut down, not when a critical failure causes the WLC to reset. The WLC does not wait for a RADIUS server to acknowledge the Accounting-Off message; the switch makes one attempt to send the Accounting-Off message, then shuts down. Accounting-On and Accounting-Off messages are disabled by default. If, after enabling these messages, you want to disable them, use the following command: clear accounting system For example:

472

Overview



WLC# clear accounting system success: change accepted. When you enter this command, an Accounting-Off message is generated and sent to the server or server group specified with the set accounting system command. No further Accounting-On or Accounting-Off messages are generated.

Viewing Local Accounting Records To view local accounting records, type the following command: show accounting statistics

Viewing Roaming Accounting Records During roaming, accounting is treated as a continuation of an existing session, rather than a new session. The following sample output shows a wireless user roaming from one WLC to another WLC. From the accounting records, you can determine user activities by viewing the Acct-Status-Type, which varies from START to UPDATE to STOP, and the Called-Station-Id, which is the MAC address of the WLA access point through which the wireless user accessed the network. The Acct-Multi-Session-Id is guaranteed to be globally unique for the client. By entering show accounting statistics commands on each WLC involved in the roaming, you can determine the user movements between WLC switches when accounting is configured locally. The user started on WLC0013: WLC0013# show accounting statistics May 21 17:01:32 Acct-Status-Type=START Acct-Authentic=2 [email protected] Acct-Multi-Session-Id=SESSION-4-1106424789 Event-Timestamp=1053536492 Vlan-Name=default Calling-Station-Id=00-06-25-09-39-5D Nas-Port-Id=1/1 Called-Station-Id=00-0B-0E-76-56-A8 The user roamed to WLC0017. WLC0017# show accounting statistics May 21 17:05:00 Acct-Status-Type=UPDATE Acct-Authentic=2 Acct-Multi-Session-Id=SESSION-4-1106424789 [email protected]


Overview

473

Acct-Session-Time=209 Acct-Output-Octets=1280 Acct-Input-Octets=1920 Acct-Output-Packets=10 Acct-Input-Packets=15 Event-Timestamp=1053536700 Vlan-Name=default Calling-Station-Id=00-06-25-09-39-5D Nas-Port-Id=2/1 Called-Station-Id=00-0B-0E-76-56-A0 The user terminated the session on WLC0017: WLC0017# show accounting statistics May 21 17:07:32 Acct-Status-Type=STOP Acct-Authentic=2 Acct-Multi-Session-Id=SESSION-4-1106424789 [email protected] Acct-Session-Time=361 Event-Timestamp=1053536852 Acct-Output-Octets=2560 Acct-Input-Octets=5760 Acct-Output-Packets=20 Acct-Input-Packets=45 Vlan-Name=default Calling-Station-Id=00-06-25-09-39-5D Nas-Port-Id=2/1 Called-Station-Id=00-0B-0E-76-56-A0 If you configured accounting records to be sent to a RADIUS server, you can view the records of user roaming at the RADIUS server. For information about requesting accounting records from the RADIUS server, see the documentation for your RADIUS server.

Displaying the AAA Configuration To view the output of the configured AAA commands, you must use the show command for each configurable part of AAA. For instance, to display information about mac-users, use the show mac-user verbose command.

474

Displaying the AAA Configuration



For information about show commands and descriptions of the output, see the Juniper Mobility System Software Command Reference.

Avoiding AAA Problems in Configuration Order You can avoid AAA problems in configuration order by: “Using the Wildcard “Any” as the SSID Name in Authentication Rules” on page 475 “Using Authentication and Accounting Rules Together” on page 475

Using the Wildcard “Any” as the SSID Name in Authentication Rules You can configure an authentication rule to match on all SSID strings by using the SSID string any in the rule. For example, the following rule matches on all SSID strings requested by all users: set authentication web ssid any ** sg1 MSS checks authentication rules in the order they appear in the configuration file. As a result, if a rule with SSID any appears in the configuration before a rule matching a specific SSID for the same authentication type and userglob, the rule with any always matches first. To ensure the authentication behavior that you expect, place the most specific rules first and place rules with SSID any last. For example, to ensure that users who request SSID corpa are authenticated using RADIUS server group corpasrvr, place the following rule in the configuration before the rule with SSID any: set authentication web ssid corpa ** corpasrvr Here is an example of a AAA configuration where the most-specific rules for 802.1X are first and the rules with any are last: WLC# show authentication ... set authentication dot1x ssid mycorp Geetha eap-tls set authentication dot1x ssid mycorp * peap-mschapv2 sg1 sg2 sg3 set authentication dot1x ssid any ** peap-mschapv2 sg1 sg2 sg3

Using Authentication and Accounting Rules Together When you use accounting commands with authentication commands and identify users with user globs, MSS might not process the commands in the order you entered them. As a result, user authentication or accounting might not proceed as you intend, or valid users might fail authentication and are denied access to the network. You can prevent these problems by using duplicate user globs for authentication and accounting and entering the commands in pairs.

Configuration Producing an Incorrect Processing Order For example, suppose you initially set up start-stop accounting as follows for all 802.1X users via RADIUS server group 1: Copyright © 2013, Juniper Networks, Inc.

Avoiding AAA Problems in Configuration Order

475

WLC# set accounting dot1x ssid mycorp * start-stop group1 success: change accepted. You then set up PEAP-MS-CHAP-V2 authentication and authorization for all users at EXAMPLE/ at server group 1. Finally, you set up PEAP-MS-CHAP-V2 authentication and authorization for all users in the local WLC database, with the intention that EXAMPLE users are to be processed first: WLC# set authentication dot1x ssid mycorp EXAMPLE/* peap-mschapv2 group1 success: change accepted. WLC# set authentication dot1x ssid mycorp * peap-mschapv2 local success: change accepted. The following configuration order results. The authentication commands are reversed, and MSS processes the authentication of all 802.1X users in the local database and ignores the command for EXAMPLE/ users. WLC# show accounting ... set accounting dot1x ssid mycorp * start-stop group1 WLC# show authentication ... set authentication dot1x ssid mycorp * peap-mschapv2 local set authentication dot1x ssid mycorp EXAMPLE/* peap-mschapv2 group1

Configuration for a Correct Processing Order To avoid processing errors for authentication and accounting commands that include order-sensitive user globs, enter the commands for each user glob in pairs. For example, to set accounting and authorization for 802.1X users as you intended, enter an accounting and authentication command for each user glob in the order in which you want them processed: WLC# set accounting dot1x ssid mycorp EXAMPLE/* start-stop group1 success: change accepted. WLC# set authentication dot1x ssid mycorp EXAMPLE/* peap-mschapv2 group1 success: change accepted. WLC# set accounting dot1x ssid mycorp * start-stop group1 success: change accepted. WLC# set authentication dot1x ssid mycorp * peap-mschapv2 local success: change accepted. The configuration order now shows that all 802.1X users are processed as you intended: WLC# show accounting ... set accounting dot1x ssid mycorp EXAMPLE/* start-stop group1 set accounting dot1x ssid mycorp * start-stop group1

476




WLC# show authentication set authentication dot1x ssid mycorp EXAMPLE/* peap-mschapv2 group1 set authentication dot1x ssid mycorp * peap-mschapv2 local



477

478



Configuring a Mobility Profile

Configuring a Mobility Profile Overview A Mobility Profile is a way of specifying, on a per-user basis, those users allowed access to specified WLA access ports and wired authentication ports on an WLC. In this way, you can constrain the roaming areas for users. You first create a Mobility Profile, assign the profile to one or more users, and finally enable the Mobility Profile feature on the WLC.

Warning: When Mobility Profile attributes are enabled, a user is denied access if assigned a Mobility-Profile attribute in the local WLC database or RADIUS server and no Mobility Profile of that name exists on the WLC

Use the following command to create a Mobility Profile by giving it a name and identifying the accessible port or ports: set mobility-profile name name {port {none | all | port-list}} | {ap {none | all | apnum} Specifying none prevents users assigned to the Mobility Profile from accessing any WLA access ports, Distributed WLAs, or wired authentication ports on the WLC. Specifying all allows the users access to all of the ports or Distributed WLAs. Specifying an individual port or Distributed WLA number or a list limits access to those ports or WLAs. For example, the following command creates a Mobility Profile named roses-profile that allows access through ports 2 through 4, port 7, and port 9: WLC# set mobility-profile name roses-profile port 2-4,7,9 success: change accepted. You can then assign this Mobility Profile to one or more users. For example, to assign the Mobility Profile roses-profile to all users at EXAMPLE\, type the following command: WLC# set user EXAMPLE\* attr mobility-profile roses-profile success: change accepted. During 802.1X authorization for clients at EXAMPLE\, MSS must search for the Mobility Profile named roses-profile. If it is not found, the authorization fails and clients with usernames like EXAMPLE\jose and EXAMPLE\tamara are rejected. If roses-profile is configured for EXAMPLE\ users on your WLC, MSS verifies the port list. If, for example, the current port for EXAMPLE\jose’s connection is on the list of allowed ports specified in roses-profile, the connection is allowed to proceed. If the port is not in the list (for example, EXAMPLE\jose is on port 12, which is not in the port list), the authorization fails and client EXAMPLE\jose is rejected. The Mobility Profile feature is disabled by default. You must enable Mobility Profile attributes on the WLC to use it. You can enable or disable the feature for the whole WLC only. If the Mobility Profile feature is disabled, all Mobility Profile attributes are ignored. To put Mobility Profile attributes into effect on an WLC, type the following command:


Overview

479

WLC# set mobility-profile mode enable success: change accepted. To display the name of each Mobility Profile and the ports, type the following command: WLC# show mobility-profile Mobility Profiles Name

Ports

========================= roses-profile AP 2 AP 3 AP 4 AP 7 AP 9 To remove a Mobility Profile, type the following command: clear mobility-profile name

Network User Configuration Scenarios The following scenarios provide examples of ways in which you use AAA commands to configure access for users: • “General Use of Network User Commands” on page 1–480 • “Enabling RADIUS Pass-Through Authentication” on page 1–482 • “Enabling PEAP-MS-CHAP-V2 Authentication” on page 1–483 • “Enabling PEAP-MS-CHAP-V2 Offload” on page 1–483 • “Combining EAP Offload with Pass-Through Authentication” on page 1–483 • “Overriding AAA-Assigned VLANs” on page 1–484

General Use of Network User Commands The following example illustrates how to configure IEEE 802.1X network users for authentication, accounting, ACL filtering, and Mobility Profile assignment: 1. Configure all 802.1X users of SSID mycorp at EXAMPLE to be authenticated by server group shorebirds. Type the following command: MX-20# set authentication dot1x ssid mycorp EXAMPLE\* pass-through shorebirds 2. Configure stop-only accounting for all mycorp users at EXAMPLE, for accounting records to be stored locally. Type the following command: WLC# set accounting dot1x ssid mycorp EXAMPLE\* stop-only local 480

Network User Configuration Scenarios



success: change accepted. 3. Configure an ACL to filter the inbound packets for each user at EXAMPLE. Type the following command for each user: WLC# set user EXAMPLE\username attr filter-id acl-101.in This command applies the access list named acl-101 to each user at EXAMPLE. 4. To display the ACL, type the following command: WLC# show security acl info acl-101 set security acl ip acl-101 (hits #0 0) ---------------------------------------------------1. permit IP source IP 192.168.1.1 0.0.0.255 destination IP any enable-hits Informational Note: For more information about ACLs, see “Configuring and Managing Security ACLs” on page 1–903.

5. Create a Mobility Profile called tulip by typing the following commands: WLC# set mobility-profile name tulip port 2,5-9 success: change accepted. WLC# set mobility-profile mode enable success: change accepted. WLC# show mobility-profile Mobility Profiles Name

Ports

========================= tulip AP 2 AP 6 AP 7 AP 8 AP 9 6. To assign Mobility Profile tulip to all users at EXAMPLE, type the following command for each EXAMPLE\ user: WLC# set user EXAMPLE\username attr mobility-profile tulip Users at EXAMPLE are now restricted to ports 2 and 5 through 9, as specified in the tulip Mobility Profile configuration. 7. Use the show configuration command to verify your configuration. Type the following command: WLC# show configuration ... Copyright © 2013, Juniper Networks, Inc.


481

Default Values authport=1812 acctport=1813 timeout=5 acct-timeout=5 retrans=3 deadtime=0 key=(null) author-pass=(null) Radius Servers Server

Addr

Ports


------------------------------------------------------------------Web Portal: enabled set accounting dot1x ssid mycorp EXAMPLE\* stop-only local set authentication dot1x ssid mycorp EXAMPLE\* pass-through shorebirds user tech Password = 1315021018 (encrypted) user EXAMPLE/nin filter-id = acl.101.in mobility-profile = tulip user EXAMPLE/tamara filter-id = acl.101.in mobility-profile = tulip ... 8. Save the configuration: WLC save config success: configuration saved.

Enabling RADIUS Pass-Through Authentication The following example illustrates how to enable RADIUS pass-through authentication for all 802.1X network users: 1. Configure the RADIUS server r1 at IP address 10.1.1.1 with the string sunny for the key. Type the following command: 2. WLC# set radius server r1 address 10.1.1.1 key sunny 3. Configure the server group sg1 with member r1. Type the following command: WLC# set server group sg1 members r1 4. Enable all 802.1X users of SSID mycorp to authenticate via pass-through to server group sg1. Type the following command: WLC# set authentication dot1x ssid mycorp * pass-through sg1 5. Save the configuration: WLC save config success: configuration saved.

482




Enabling PEAP-MS-CHAP-V2 Authentication The following example illustrates how to enable local PEAP-MS-CHAP-V2 authentication for all 802.1X network users. This example includes local usernames, passwords, and membership in a VLAN. This example includes one username and an optional attribute for session-timeout in seconds. 1. To set authentication for all 802.1X users of SSID thiscorp, type the following command: WLC# set authentication dot1x ssid thiscorp * peap-mschapv2 local 2. To add user Natasha to the local database on the WLC switch, type the following command: WLC# set user Natasha password moon 3. To assign Natasha to a VLAN named red, type the following command: WLC# set user Natasha attr vlan-name red 4. To assign Natasha a session timeout value of 1200 seconds, type the following command: WLC# set user Natasha attr session-timeout 1200 5. Save the configuration: WLC save config success: configuration saved.

Enabling PEAP-MS-CHAP-V2 Offload The following example illustrates how to enable PEAP-MS-CHAP-V2 offload. In this example, all EAP processing is offloaded from the RADIUS server, but MS-CHAP-V2 authentication and authorization are performed on a RADIUS server. The MS-CHAP-V2 lookup matches users against the user list on a RADIUS server. 1. Configure the RADIUS server r1 at IP address 10.1.1.1 with the string starry for the key. Type the following command: WLC# set radius server r1 address 10.1.1.1 key starry 2. Configure the server group sg1 with member r1. Type the following command: WLC# set server group sg1 members r1 3. Enable all 802.1X users of SSID thiscorp using PEAP-MS-CHAP-V2 to authenticate MS-CHAP-V2 on server group sg1. Type the following command: WLC# set authentication dot1x ssid thiscorp * peap-mschapv2 sg1 4. Save the configuration: WLC save config success: configuration saved.

Combining EAP Offload with Pass-Through Authentication The following example illustrates how to enable PEAP-MS-CHAP-V2 offload for the marketing (mktg) group and RADIUS pass-through authentication for members of engineering. This example assumes that engineering members are using DNS-style naming, such as is used with EAP-TLS. An WLC server certificate is also required. Copyright © 2013, Juniper Networks, Inc.

Enabling PEAP-MS-CHAP-V2 Authentication

483

1. Configure the RADIUS server r1 at IP address 10.1.1.1 with the string starry for the key. Type the following command: WLC# set radius server r1 address 10.1.1.1 key starry 2. Configure the server group sg1 with member r1. Type the following command: WLC# set server group sg1 members r1 3. To authenticate all 802.1X users of SSID bobblehead in the group mktg using PEAP on the WLC and MS-CHAP-V2 on server sg1, type the following command: WLC# set authentication dot1x ssid bobblehead mktg\* peap-mschapv2 sg1 4. To authenticate all 802.1X users of SSID aircorp in @eng.example.com via pass-through to sg1, type the following command: WLC# set authentication dot1x ssid aircorp *@eng.example.com pass-through sg1 5. Save the configuration: WLC save config success: configuration saved.

Overriding AAA-Assigned VLANs The following example shows how to change the VLAN access of wireless users in an organization located in multiple buildings. Suppose the wireless users on the faculty of a college English department have offices in building A and are authorized to use that building’s bldga-prof- VLANs. These users also teach classes in building B. Because you do not want to tunnel these users back to building A from building B when they use their wireless laptops in class, you configure the location policy on the WLC to redirect them to the bldgb-eng VLAN. You also want to allow writing instructors normally authorized to use any -techcomm VLAN in the college to access the network through the bldgb-eng VLAN when they are in building B. 1. Redirect bldga-prof- VLAN users to the VLAN bldgb-eng: WLC# set location policy permit vlan bldgb-eng if vlan eq bldga-prof-* 2. Allow writing instructors from -techcomm VLANs to use the bldgb-eng VLAN: WLC# set location policy permit vlan bldgb-eng if vlan eq *-techcomm 3. Display the configuration: WLC# show location policy Id Clauses ----------------------------------------------------1) permit vlan bldgb-teach if vlan eq bldga-prof-* 2) permit vlan bldgb-eng if vlan eq *-techcomm

484

Overriding AAA-Assigned VLANs



4. Save the configuration: WLC save config success: configuration saved.



485

486




Network User Configuration Scenarios Overview The following scenarios provide examples of ways in which you use AAA commands to configure access for users: • “General Use of Network User Commands” on page 487 • “Enabling RADIUS Pass-Through Authentication” on page 489 • “Enabling PEAP-MS-CHAP-V2 Authentication” on page 489 • “Enabling PEAP-MS-CHAP-V2 Offload” on page 490 • “Combining EAP Offload with Pass-Through Authentication” on page 490 • “Overriding AAA-Assigned VLANs” on page 491

General Use of Network User Commands The following example illustrates how to configure IEEE 802.1X network users for authentication, accounting, ACL filtering, and Mobility Profile assignment: 1. Configure all 802.1X users of SSID mycorp at EXAMPLE to be authenticated by server group shorebirds. Type the following command: MX-20# set authentication dot1x ssid mycorp EXAMPLE\* pass-through shorebirds 2. Configure stop-only accounting for all mycorp users at EXAMPLE, for accounting records to be stored locally. Type the following command: WLC# set accounting dot1x ssid mycorp EXAMPLE\* stop-only local success: change accepted. 3. Configure an ACL to filter the inbound packets for each user at EXAMPLE. Type the following command for each user: WLC# set user EXAMPLE\username attr filter-id acl-101.in This command applies the access list named acl-101 to each user at EXAMPLE. 4. To display the ACL, type the following command: WLC# show security acl info acl-101 set security acl ip acl-101 (hits #0 0) ---------------------------------------------------1. permit IP source IP 192.168.1.1 0.0.0.255 destination IP any


Overview

487

enable-hits Informational Note: For more information about ACLs, see “Configuring and Managing Security ACLs” on page 1–903.

5. Create a Mobility Profile called tulip by typing the following commands: WLC# set mobility-profile name tulip port 2,5-9 success: change accepted. WLC# set mobility-profile mode enable success: change accepted. WLC# show mobility-profile Mobility Profiles Name

Ports

========================= tulip AP 2 AP 6 AP 7 AP 8 AP 9 6. To assign Mobility Profile tulip to all users at EXAMPLE, type the following command for each EXAMPLE\ user: WLC# set user EXAMPLE\username attr mobility-profile tulip Users at EXAMPLE are now restricted to ports 2 and 5 through 9, as specified in the tulip Mobility Profile configuration. 7. Use the show configuration command to verify your configuration. Type the following command: WLC# show configuration ... Default Values authport=1812 acctport=1813 timeout=5 acct-timeout=5 retrans=3 deadtime=0 key=(null) author-pass=(null) Radius Servers Server

Addr

Ports


------------------------------------------------------------------Web Portal: enabled set accounting dot1x ssid mycorp EXAMPLE\* stop-only local set authentication dot1x ssid mycorp EXAMPLE\* pass-through shorebirds 488

Overview



user tech Password = 1315021018 (encrypted) user EXAMPLE/nin filter-id = acl.101.in mobility-profile = tulip user EXAMPLE/tamara filter-id = acl.101.in mobility-profile = tulip ... 8. Save the configuration: WLC save config success: configuration saved.

Enabling RADIUS Pass-Through Authentication The following example illustrates how to enable RADIUS pass-through authentication for all 802.1X network users: 1. Configure the RADIUS server r1 at IP address 10.1.1.1 with the string sunny for the key. Type the following command: 2. WLC# set radius server r1 address 10.1.1.1 key sunny 3. Configure the server group sg1 with member r1. Type the following command: WLC# set server group sg1 members r1 4. Enable all 802.1X users of SSID mycorp to authenticate via pass-through to server group sg1. Type the following command: WLC# set authentication dot1x ssid mycorp * pass-through sg1 5. Save the configuration: WLC save config success: configuration saved.

Enabling PEAP-MS-CHAP-V2 Authentication The following example illustrates how to enable local PEAP-MS-CHAP-V2 authentication for all 802.1X network users. This example includes local usernames, passwords, and membership in a VLAN. This example includes one username and an optional attribute for session-timeout in seconds. 1. To set authentication for all 802.1X users of SSID thiscorp, type the following command: WLC# set authentication dot1x ssid thiscorp * peap-mschapv2 local 2. To add user Natasha to the local database on the WLC switch, type the following command: WLC# set user Natasha password moon 3. To assign Natasha to a VLAN named red, type the following command: Copyright © 2013, Juniper Networks, Inc.


489

WLC# set user Natasha attr vlan-name red 4. To assign Natasha a session timeout value of 1200 seconds, type the following command: WLC# set user Natasha attr session-timeout 1200 5. Save the configuration: WLC save config success: configuration saved.

Enabling PEAP-MS-CHAP-V2 Offload The following example illustrates how to enable PEAP-MS-CHAP-V2 offload. In this example, all EAP processing is offloaded from the RADIUS server, but MS-CHAP-V2 authentication and authorization are performed on a RADIUS server. The MS-CHAP-V2 lookup matches users against the user list on a RADIUS server. 1. Configure the RADIUS server r1 at IP address 10.1.1.1 with the string starry for the key. Type the following command: WLC# set radius server r1 address 10.1.1.1 key starry 2. Configure the server group sg1 with member r1. Type the following command: WLC# set server group sg1 members r1 3. Enable all 802.1X users of SSID thiscorp using PEAP-MS-CHAP-V2 to authenticate MS-CHAP-V2 on server group sg1. Type the following command: WLC# set authentication dot1x ssid thiscorp * peap-mschapv2 sg1 4. Save the configuration: WLC save config success: configuration saved.

Combining EAP Offload with Pass-Through Authentication The following example illustrates how to enable PEAP-MS-CHAP-V2 offload for the marketing (mktg) group and RADIUS pass-through authentication for members of engineering. This example assumes that engineering members are using DNS-style naming, such as is used with EAP-TLS. An WLC server certificate is also required. 1. Configure the RADIUS server r1 at IP address 10.1.1.1 with the string starry for the key. Type the following command: WLC# set radius server r1 address 10.1.1.1 key starry 2. Configure the server group sg1 with member r1. Type the following command: WLC# set server group sg1 members r1 3. To authenticate all 802.1X users of SSID bobblehead in the group mktg using PEAP on the WLC and MS-CHAP-V2 on server sg1, type the following command: WLC# set authentication dot1x ssid bobblehead mktg\* peap-mschapv2 sg1 4. To authenticate all 802.1X users of SSID aircorp in @eng.example.com via pass-through to sg1, type the following command: 490




WLC# set authentication dot1x ssid aircorp *@eng.example.com pass-through sg1 5. Save the configuration: WLC save config success: configuration saved.

Overriding AAA-Assigned VLANs The following example shows how to change the VLAN access of wireless users in an organization located in multiple buildings. Suppose the wireless users on the faculty of a college English department have offices in building A and are authorized to use that building’s bldga-prof- VLANs. These users also teach classes in building B. Because you do not want to tunnel these users back to building A from building B when they use their wireless laptops in class, you configure the location policy on the WLC to redirect them to the bldgb-eng VLAN. You also want to allow writing instructors normally authorized to use any -techcomm VLAN in the college to access the network through the bldgb-eng VLAN when they are in building B. 1. Redirect bldga-prof- VLAN users to the VLAN bldgb-eng: WLC# set location policy permit vlan bldgb-eng if vlan eq bldga-prof-* 2. Allow writing instructors from -techcomm VLANs to use the bldgb-eng VLAN: WLC# set location policy permit vlan bldgb-eng if vlan eq *-techcomm 3. Display the configuration: WLC# show location policy Id Clauses ----------------------------------------------------1) permit vlan bldgb-teach if vlan eq bldga-prof-* 2) permit vlan bldgb-eng if vlan eq *-techcomm 4. Save the configuration: WLC save config success: configuration saved.



491

492



Device Fingerprinting

Device Fingerprinting DHCP Fingerprinting Overview This feature supports the ability of MSS to detect the type of device used by a client when authenticating on the wireless LAN. Devices include iPads, iPhones, Windows PC, tablets, etc. This feature implements the DHCP fingerprinting method.

DHCP Fingerprint A DHCP fingerprint is almost a unique identifier for a specific operating system or device type. Due to the broadcast and pervasive nature of DHCP, DHCP fingerprinting provides a low cost and minimal effort method of passive system identification and inventory. MSS examines the DHCP message from various devices and identifies unique characteristics for each device. This information is used to compile a fingerprint database which is then used to identify the device type for clients as they join the network.

When a mobile device attempts to connect to the wireless network, it sends a DHCP Discover packet in an attempt to locate a DHCP server on the network. This is a “conversation starter” between the device and the DHCP server. The second phase of the conversation is the return of a DHCP Offer packet from the DHCP server to the mobile device. After reserving an IP address for the client, the DHCP server sends a DHCP Offer packet with the client MAC address, the IP Address, lease duration, and the IP address of the DHCP server sending the Offer packet. In the third phase, the mobile client returns a DHCP Request packet to the DHCP server accepting the IP address. And in the final fourth phase, the DHCP Server sends a DHCP Acknowledgement packet with the lease duration and any other information requested by the mobile device client. The Role of DHCP in Device Fingerprinting


DHCP Fingerprinting Overview

493

When a DHCP client of an operating system sends a DHCP request Discover or Request), the request contains DHCP options such as DNS server, WINS server, or default gateway, and the WLA looks for DHCP options. The option order is relatively unique and identifies the specific operating system version. Option 55, Parameter Request List, contains the options requested by the client. The DHCP Discover or Request packet is inspected for Option 55, and the option list is matched against the database to determine the client type. DHCP Option 55 is not unique and the same parameters may be sent by different clients. In this case, other DHCP options are inspected by MSS.

Figure 1: An example of a DHCP Packet Exchange

In the diagram, you can see the different DHCP Options that are communicated during the process. Once the DHCP Discover information is exchanged, a DHCP Request packet is sent from the mobile device.

494




In addition, there are differences between an initial DHCP request packet and a DHCP Request packet sent after a mobile device “wakes up”.

Figure 2: An Example of a DHCP Request Packet

If a mobile device receives the information it needs to connect to the network, and successfully connects, it retains the information for the active session. If the device “goes to sleep”, and then “wakes up”, it sends a DHCP Request packet asking if the initial information is still available. If it is, the mobile device reconnects using that information. Table 20.

Common DHCP Options Code Name

Length

12

Host Name

minimum of 1 octet

50

Requested IP address

4 octets

51

IP Address Lease Time

4 octets

53

DHCP Message Type

1 octet

54

Server Identifier

4 octets

55

Parameter Request List

minimum of 1 octet

57

Maximum DHCP Message Size

2 octets

58

Renewal (T1) Time Value

4 octets

60

Vendor class identifier

minimum of 1 octet

61

Client-identifier

minimum of 2 octets

81

FQDN Option

1 octet



495

Option 55 Parameter Request List

It possible to configure device fingerprint rules based on the Parameter Request List in DHCP Option 55. You can put them in the order of priority but the DHCP server may not process them specifically in the requested order. The table lists DHCP Option 55 parameters: Table 21.

DHCP Option 55 Parameters

Parameter Number

Definition

1

Subnet Mask

2

Time Offset

3

Router

6

Domain Name Server

31

Perform Router Discover

33

Static Route

43

Vendor-specific information

44

NetBIOS over TCP/IP Server

47

NetBIOS over TCP/IP Node Type

78

Directory Agent Information

79

Service Location Agent Scope

95

Lightweight Directory Access Protocol

112

NetInfo Parent Server Address

113

NetInfo Parent Server Tag

249

Classless Static Route

252

Proxy autodiscovery

When a device attempts to join the wireless LAN, information is gathered from the device and matched against the fingerprint database to identify the device type. Once the device type is detected, that information is used to apply policies or report information useful to the network administrator.

Informational Note:

The WLA captures the device fingerprint information and sends it to the WLC to determine policy enforcement. Also, when the WLA sends DHCP Discover and Request packets, DHCP Option 12 now contains the WLA serial number, and DHCP Option 77 contains “WLA” (without the quotes).

Informational Note:

The WLAs that support the device finger printing feature includes the newer access points such as WLA321, WLA322, WLA522, WLA532, and WLA632. This feature is not supported on older access points such as MP-422 and MP-372.

496




By default, MSS has a database with 19 fingerprints that identify the following devices: iPhone iPad PC with Windows XP Android-based phones including Samsun, Motorola, HTC, LG, etc. OSX devices (Apple) WiFi-enabled game consoles such as PS3, Xbox, Wii for detection in school dorms. WinMobile and Nokia phones Kindle Fire Nook Printers

Figure 3: An Example of Wireless Access based on Device Fingerprinting

Device fingerprints are processed in the configured order by MSS, and the MSS fingerprint database has the following characteristics: Maximum of 50 fingerprints supported Fingerprints must be uniquely named You can add, modify, or delete entries. The following information is required by the device fingerprinting feature: Device type - used to identify the device.



497

Rules - each rule defines these parameters: Number - used to identify the rule Type - the type of rule such as MAC address. Data - contains the data from the packet. Value - the value to match against the data. Method - matching method used for the data and value. The following rule types are supported: MAC Address Data - the device MAC address Value - MAC “glob” using the existing MAC rules in MSS Method - MAC “glob” comparison DHCP Flags Data - DHCP flags field Value - 2 byte mask Method - Bitwise AND DHCP Option Data - Byte data from the specified DHCP option. − Option number is an integer. − Option content is a string of consisting of either a string, hex, or an order sensitive list of DHCP option numbers. − Method - “eq” or “neq” based on the current MSS implementation. It matches if both are “eq”. “Contains” and “Not Contains” are also supported/ DHCP Options List Data - List of DHCP Options from the DHCP packet Value - list of desired DHCP options in a format consistent with Options content list. Method - one of “eq” or “neq” or “contains” or “not contain” Combination of rules - rules are not used directly in the detection process but combined to gether to create a rule expression. This consists of a logical expression specified as a string and can contain the following tokens: rule number - one of the defined rules for this fingerprint “and” and “or” used for logical tests “(“and”)” used for grouping white space - used for separation of the tokens.

498




Interactions between the User Policy and the Device Policy Who wins? All attributes from a device policy and user policy are applied to a session except when there are conflicts. When there is a conflict, device policies take precedence over user policies by default. You can change the precedence in the CLI.

Other Functionalities Supported by Device Fingerprinting Device detection works in parallel with AAA, so all AAA methods are compatible. It is also supported in a cluster (high availability) environment.

Configuring Device Fingerprinting Device fingerprinting is enabled on a per service-profile basis. With the introduction of device fingerprinting, a new concept is introduced called “device profile”, a collection of attributes that apply to a device. This information is stored on the WLC and each device profile can be assigned to a fingerprint. Different fingerprints can share the same device profile. Syntax set device-profile name attr [vlan-name name | filter-id acl-name | time-of-day time-of-day | qos-profile profile-name] deny-session name

The name assigned to the device profile.

vlan-name name

The name of the VLAN assigned to the profile which places the device on that VLAN.

filter-id acl-name

The ACL assigned to the profile that provides security policies for the device.

time-of-day time-of-day

A character string that denotes the time limitations for the device.

qos-profile profile-name

The name of the QoS profile assigned to the device.

deny session

Prevent certain devices from access the wireless network.

If you configure the attribute, deny-session, the session is stopped. This attribute takes precendence over other attributes. A maximum of 50 profiles can be configured. Changes to the device-profile configuration are not applied immediately, but new sessions are affected. Existing sessions are affected when the client sends a new DHCP request or roam on the network. You can use the show config area device-profile command to display the configuration. Examples To assign the device profile, ipad-users, to the VLAN ipad, use the following command:

WLC# set device-profile ipad-users attr vlan-name ipad success: change accepted. Any user with an iPad is assigned to the VLAN ipad after connecting to the network.



499

Syntax set service-profile name device-detect mode {disable | detect-only | enforce-policy} name

The name of the service profile that you want associated with device detection.

disable

Disables device detection if already enabled.

detect-only

Device detection is performed but no policies are applied to the device.

enforce-policy

Both detection and policy enforcement is enabled.

Applying a Device Fingerprint A device fingerprint can be configured or you can select from a list of preconfigured fingerprints. You can also apply device profiles to multiple device fingerprints. Syntax set device-fingerprint [ipad2 | iphone4 | htc-explorer |

android-generic | samsung-galaxy-s-plus | mac-osx-lion | nokia-generic | windows-mobile6 | windows-xp | name] ipad2

Apple iPad 2

iphone4

Apple iPhone 4

htc-explorer

HTC Explorer smart phone

android-generic

Includes not only android phones, tablets, but also Kindle Fire and Nook

samsung-galaxy-s-plus

Samsung mobile devices

mac-osx-lion

Macbooks running MacOS Lion

nokia-generic

Nokia mobile devices

windows-mobile6

Windows-based mobile devices

windows-xp

Laptops running Windows XP

name

A custom fingerprint up to 32 characters in length

Configuring Custom Device Fingerprints A custom device fingerprint can be configured and is identified by the device-type string of up to 32 characters. A device profile can be specified if policy enforcement is required. The same device profile can be applied to multiple fingerprints. set device-fingerprint device-type device-profile profile-name You can also configure a device-group consisting of a 32 character string. A device group is a set of devices that you want to group together under a single name. set device-fingerprint device-type device-group string

Adding Rules to Device Profiles To completely configure device fingerprinting, you can apply up to 20 numbered rules to each fingerprint. You can create a rule for matching the MAC address of the client with a configured MAC glob which is useful for OUI-based devices. Other rules can support DHCP-based device detection.

500




set device-fingerprint device-type rule num mac-addr mac-glob MAC glob follows the current MSS implementation of globs. “Globbing” is a way of using a wildcard pattern to expand a single element into a list of elements that match the pattern. MSS accepts user globs, MAC address globs, and VLAN globs. The order in which globs appear in the configuration is important, because once a glob is matched, processing stops on the list of globs. There can be only one asterisk (*) and it must be the last character of the glob. The rest of the string can be up to 6 “:” separated bytes including the asterisk. For example, WLC# set device-fingerprint iphone rule 1 mac-addr 00:1b:63:* DHCP-based device detection rules are rules that examine flags or options in a DHCP packet. This can be useful in some cases where the client always broadcasts this information. Since the flags field is only two bytes in the DHCP packet, the dhcp flags attribute only accepts hexadecimal characters up to two bytes. It is a mask to match particular bits, and not an exact match of the flags field. set device-fingerprint device-type rule num type dhcp flags num To allow matching of specific DHCP options, you can set the following command to either match (eq) or not match (neq) a specific option. The option value must be a number between 1 and 254. set device-fingerprint device-type rule num type dhcp option num {eq | neq | contains | not-contains} string For the attribute, option num, the only valid format is a comma separated ordered list of DHCP options in the range of 1 to 254. The attribute, string, cannot exceed 255 characters which is the maximum length of a DHCP option. An option can only be specified once in a rule. Different DHCP options contain different kinds of data. Option 55 (Parameter List) contains a list of option numbers, and Option 12 (Host Name) contains free-form text. All options are allowed in the command. set device-fingerprint device-type rule num type option-list {eq |neq | contains |not-contains} string Once you’ve created your rules, you have to specify the combination of rules for each device fingerprint. For example, you can match all rules or any one of the configured rules. Or, match one rule and either of one of the remaining rules. If no combination is specified, then the default behavior is match all of the rules configured for the fingerprint. set device-fingerprint device-type rule-expression string You must configure rules before using this command. To use this command with rules 1, 2, 3 and an iPhone, use the following syntax: set device-fingerprint iphone rule-expression “1 and 2” set device-fingerprint iphone rule-expression “1 or 2” set device-fingerprint iphone rule-expression “1 and (2 or 3)”

Configuration Example for a Complete Device Fingerprint This example assumes that you have a group of iPhones used by employees who want access to your wireless LAN. You have the MAC address 00:1b:63:* to use as the MAC glob. WLC# set device-fingerprint iphone device-group iPhone4S WLC# set device-fingerprint iphone rule 1 mac-addr 00:1b:63:b*



501

WLC# set device-fingerprint iphone rule 2 type dhcp option eq option 12 WLC# set device-fingerprint iphone rule 3 type dhcp option eq 55 WLC# set device-fingerprint iphone rule-expression “((1 and 3)or 2)” WLC# set device-fingerprint iphone device-profile iphone-policy You can delete the device fingerprint configuration by starting with the device type: WLC# clear device-fingerprint iphone

New VSAs for RADIUS There are four new RADIUS VSAs added as part of the device fingerprint configuration: Device-Profile Device-Type Device-Group Allowed-Devices Of these, Device-Type and Device-Group, are required only for accounting updates. Device-Profile and Allowed-Devices are returned by a AAA server in an Access-Accept message. When the device profile is used as an attribute, it functions as a fallthrough device profile. If MSS does not detect the device type for a given session then the device profile is applied. If there is no device profile configured, then the session remains unmodified. Informational Note: In this release, you can only apply the device-profile attribute to service profiles, mac-user, and mac-usergroup.

set mac-user name attr device-profile profile-name set mac-usergroup name attr device-profile profile-name set service-profile name attr device-profile profile-name If the attribute allowed-devices is used, network access is allowed on a device type basis. The attribute allowed-devices is a comma-delimited list of device-type strings. Maximum allowed length is 250 characters. For example, WLC# set mac-user 00:11:* attr allowed-devices iPhone This rule allows users matching the MAC glob to connect to the wireless LAN using only an iPhone. If you want to allow access for multiple devices for MAC users, use the following command: WLC# set mac-user 00:11:* attr allowed-devices iPhone, Windows If the mac-user has an iPhone and an iPad, but you don’t want to allow access for these devices, use the following command: WLC# set mac-user 00:11:* attr allowed-devices not:iPhone, not:iPad

502




Device Profile Attributes Preference When the device profile attribute is received as part of a AAA request, other attributes may be present as well. For instance, filter-id, time of day, and other attributes can be added to the configureation. By default, the device profile attribute should have preference over other attributes. However, you can configure the preference of device profiles over other attributes by using the following command: WLC# set authorization preference {device-profile | attr} This command also applies to cluster configurations. As an example, let’s say that the RADIUS server returned the following information as part of an Access-Accept packet: Device-Profile=iphone Qos-profile=low-bw Filter-id=device-detect-acl The WLC is configured with this device profile: WLC# set device-profile iphone attr qos-profile high-bw By default, the qos-profile high-bw is applied to the device profile, iphone. The filter-id is always applied to the configuration. However, if you give preference to the attribute, then the qos-profile attribute low-bw is applied to the device profile. WLC# set authorization preference attr

Configuring the Device Detect ACL The Device Detect ACL is configured automatically when you enable device policy enforcement on a service profile. This is similar to how the portalacl is configured when the parameter auth-fallthru is set to web-portal. The default configuration looks like this: WLC# set security acl name deviceacl permit udp 0.0.0. 255.255.255.255 eq 68.0.0.0 255.255.255.55 eq 67 WLC# set security acl name device acl deny 0.0.0.0 255.255.255.255 WLC# commit security acl deviceacl

Configuring Device Detect Timeout To configure the length of time for device detection on the network, use the following command: WLC# set service-profile name device-detect-timeout seconds The default value is 5 seconds with a range of 1 to 60 seconds.



503

Example Rules for Different Mobile Devices When this feature was tested, various mobile devices were used to validate device rules, profiles, and fingerprints. These example rules are included so that you can see how the rules are configured for a variety of devices. Informational Note:

Device fingerprinting rules must be configured in a specific order and the option-list must be configured in the order that the device sends the DHCP options. Even though it looks like the same options are used in different rules, the order of the options is critical to the implementation of the rules. iOS Rules

This group of rules can be used to recognize iPhones, iPads, and iPods that do not use DHCP Option 12 or sends Option 12 but the string does not contain iPhone, iPad, or iPod: set device-fingerprint ios-generic device-group ios set device-fingerprint ios-generic rule-expression “(((1 or 2) and (1 or 3) and (1 or 4)) and (5 or 6 or 7))” set device-fingerprint ios-generic rule 1 type dhcp option-list not-contains 12 set device-fingerprint ios-generic rule 2 type dhcp option 12 not-contains “iPhone” set device-fingerprint ios-generic rule 3 type dhcp option 12 not-contains “iPad” set device-fingerprint ios-generic rule 4 type dhcp option 12 not-contains “iPod” set device-fingerprint ios-generic rule 5 type dhcp option-list contains 53,55,57,61,51 set device-fingerprint ios-generic rule 6 type dhcp option-list eq 53,55,57,61,50,51 set device-fingerprint ios-generic rule 7 type dhcp option list eq 53,55,57,61,50,54

504




iPad Rules

set device-fingerprint ipad device-group ios set device-fingerprint ipad rule-expression “(1 and (2 or 3 or 4))” set device-fingerprint ipad rule 1 type dhcp option 12 contains “iPad” set device-fingerprint ipad rule 2 type dhcp option-list eq 53,55,57,61,50,51,12 set device-fingerprint ipad rule 3 type dhcp option-list eq 53,55,57,61,51,12 set device-fingerprint ipad rule 4 type dhcp option-list eq 53,55,57,61,50,54,12

iPhone Rules

set device-fingerprint iphone device-group ios set device-fingerprint iphone rule-expression “(1 and (2 or 3 or 4))” set device-fingerprint iphone rule 1 type dhcp option 12 contains “iPhone” set device-fingerprint iphone rule 2 type dhcp option-list eq 53,55,57,61,51,12 set device-fingerprint iphone rule 3 type dhcp option-list eq 53,55,57,61,50,51,12 set device-fingerprint iphone rule 4 type dhcp option-list eq 53,55,57,61,50,54,12 iPod Rules

set device-fingerprint ipod device-group ios set device-fingerprint ipod rule-expression “(1 and (2 or 3 or 4))” set device-fingerprint ipod rule 1 type dhcp option contains “iPod” set device-fingerprint ipod rule 2 type dhcp option-list eq 53,55,57,61,51,12



505

set device-fingerprint ipod rule 3 type dhcp option-list eq 53,55,57,61,50,51,12 set device-fingerprint ipod rule 4 type dhcp option-list eq 53,55,57,61,50,54,12 Android Rules

set device-fingerprint android-generic device-group android set device-fingerprint android-generic rule-expression “((1 or 2) and 3)” set device-fingerprint android-generic rule 1 type dhcp option-list EQ 53,57,60,12,55 set device-fingerprint android-generic rule 2 type dhcp option-list EQ 53,50,54,57,60,12,55 set device-fingerprint android-generic rule 3 type dhcp option 55 eq 1,121,33,3,6,15,28,51,58,59,119

MacOS on MacBook Pro and MacBook Air

set device-fingerprint macos-generic device-group macosx set device-fingerprint mac-os rule-expression "((1 or 2 or 4 or 5 or 6) and (3 or 7))" set device-fingerprint macos-generic rule 1 type dhcp option-list EQ 53,55,57,61,51 set device-fingerprint macos-generic rule 2 type dhcp option-list EQ 53,55,57,61,50,54 set device-fingerprint macos-generic rule 3 type dhcp option 55 EQ 1,3,6,15,119,95,252,44,46 set device-fingerprint macos-generic rule 4 type dhcp option-list EQ 53,55,57,61,51,12

506




set device-fingerprint macos-generic rule 5 type dhcp option-list EQ 53,55,57,61,50,54,12 set device-fingerprint macos-generic rule 6 type dhcp option-list EQ 53,55,57,61,50,51 set device-fingerprint macos-generic rule 8 type dhcp option 55 EQ 1,3,6,15,119,95,252,44,46,47 Blackberry Bold 9700

set device-fingerprint blackberry device-group blackberry set device-fingerprint blackberry rule-expression "(1 or 2)" set device-fingerprint blackberry rule 1 type dhcp option-list EQ 53,12,60,61,55 set device-fingerprint blackberry rule 2 type dhcp option-list EQ 53,54,50,12,60,61,55 Windows Computers and Phones

set device-fingerprint windows-generic device-group windows set device-fingerprint windows-generic rule-expression "((1 or 2 or 3) and (4 or 5)and 6)" set device-fingerprint windows-generic rule 1 type dhcp option-list EQ 53,116,61,50,12,60,55,43 set device-fingerprint windows-generic rule 2 type dhcp option-list EQ 53,116,61,12,60,55 set device-fingerprint windows-generic rule 3 type dhcp option-list EQ 53,61,50,54,12,81,60,55,43 set device-fingerprint windows-generic rule 4 type dhcp option 55 EQ 1,15,3,6,44,46,47,31,33,249,43 set device-fingerprint windows-generic rule 5 type dhcp option 55 EQ 1,15,3,6,44,46,47,31,33,121,249,43



507

set device-fingerprint windows-generic rule 6 type dhcp option 60 EQ "MSFT 5.0" Windows XP Rules set device-fingerprint windows-xp device-group windows set device-fingerprint windows-xp rule-expression "((1 or 2 or 3 or 4) and 5 and 6)" set device-fingerprint windows-xp rule 1 type dhcp option-list EQ 53,116,61,50,12,60,55,43 set device-fingerprint windows-xp rule 2 type dhcp option-list EQ 53,116,61,12,60,55,43 set device-fingerprint windows-xp rule 3 type dhcp option-list EQ 53,61,50,12,60,55,43 set device-fingerprint windows-xp rule 4 type dhcp option-list EQ 53,116,61,50,12,60,55 set device-fingerprint windows-xp rule 5 type dhcp option 55 EQ 1,15,3,6,44,46,47,31,33,249,43 set device-fingerprint windows-xp rule 6 type dhcp option 60 EQ "MSFT 5.0" Windows7 Rules set device-fingerprint windows7 device-group windows set device-fingerprint windows7 rule-expression "((1 or 2 or 3 or 4 or 5) and 6 and 7)" set device-fingerprint windows7 rule 1 type dhcp option-list EQ 53,61,50,54,12,81,60,55 set device-fingerprint windows7 rule 2 type dhcp option-list EQ 53,61,50,12,60,55 set device-fingerprint windows7 rule 3 type dhcp option-list EQ 508




53,61,50,12,81,60,55 set device-fingerprint windows7 rule 4 type dhcp option-list EQ 53,61,50,12,60,55 set device-fingerprint windows7 rule 5 type dhcp option-list EQ 53,61,50,54,12,60,55 set device-fingerprint windows7 rule 6 type dhcp option 55 EQ 1,15,3,6,44,46,47,31,33,121,249,43 set device-fingerprint windows7 rule 7 type dhcp option 60 EQ "MSFT 5.0" Windows 8

set device-fingerprint windows8 device-group windows set device-fingerprint windows8 rule-expression “((1 or 2 or 3) and 4 and 5)” set device-fingerprint windows8 rule 1 type dhcp option-list eq 53,61,12,60,55 set device-fingerprint windows8 rule 2 type dhcp option-list eq 53,61,50,12,81,60,55 set device-fingerprint windows8 rule 3 type dhcp option-list eq 53,61,50,54,12,81,60,55 set device-fingerprint windows8 rule 4 type dhcp option 55 eq 1,15,3,6,44,46,47,31,33,121,249,252,43 set device-fingerprint windows8 rule 5 type dhcp option 60 eq “MSFT 5.0” Windows Mobile Phone OS

set device-fingerprint windows-phone7 device-group windows-phone set device-fingerprint windows-phone7 rule-expression "((1 or 2 or 3 or 4 or 5 or 6)and (7 or 8)" set device-fingerprint windows-phone7 rule 1 type dhcp option-list EQ 53,61,50,54,12,81,60,55



509

set device-fingerprint windows-phone7 rule 2 type dhcp option-list EQ 53,61,50,12,60,55 set device-fingerprint windows-phone7 rule 3 type dhcp option-list EQ 53,61,50,12,81,60,55 set device-fingerprint windows-phone7 rule 4 type dhcp option-list EQ 53,61,50,12,60,55 set device-fingerprint windows-phone7 rule 5 type dhcp option-list EQ 53,61,55 set device-fingerprint windows-phone7 rule 6 type dhcp option-list EQ 53,54,50,61,55 set device-fingerprint windows-phone7 rule 7 type dhcp option-list not-contains 60 set device-fingerprint windows-phone7 rule 8 type dhcp option 60 not-contains “MSFT 5.0” Printer Rules

set device-fingerprint printer device-group printer set device-fingerprint printer rule-expression "((1 or 2 or 3 or 4 or 5 or 6) and (7 or 8))" set device-fingerprint printer rule 1 type dhcp option-list EQ 53,61,55 set device-fingerprint printer rule 2 type dhcp option-list EQ 53,61,50,12,55 set device-fingerprint printer rule 3 type dhcp option-list EQ 3,6,15,44,47 set device-fingerprint printer rule 4 type dhcp option-list EQ 1,3,6,15,44,47 set device-fingerprint printer rule 5 type dhcp option-list EQ 1,3.12,23,6,15 510




set device-fingerprint printer rule 6 type dhcp option-list EQ 53,61,50,55 set device-fingerprint printer rule 7 type dhcp option 55 eq 6,3,1,15,66,67,13,44,12,81 set device-fingerprint printer rule 8 type dhcp option 55 eq 1,3,6 Gaming Console Rules

Playstation set device-fingerprint playstation device-group game-console set device-fingerprint playstation rule-expression "((1 or 2) and (3 or 4))" set device-fingerprint playstation rule 1 type dhcp option-list EQ 53,61,60 set device-fingerprint playstation rule 2 type dhcp option-list EQ 53,50,54,55,61,60 set device-fingerprint playstation rule 3 type dhcp option 60 CONTAINS "PS Vita" set device-fingerprint playstation rule 4 type dhcp option 60 CONTAINS "PS3"

Wii set device-fingerprint wii device-group game-console set device-fingerprint wii rule-expression “((1 or 2 or 3) and 4)” set device-fingerprint wii rule 1 type dhcp option-list EQ 53,61,50,12,55 set device-fingerprint wii rule 2 type dhcp option-list EQ 53,61,12,55 set device-fingerprint wii rule 3 type dhcp option-list EQ 53,54,61,50,12,55



511

set device-fingerprint wii rule 4 type dhcp option 12 CONTAINS "Wii" xBox

set device-fingerprint xbox device-group game-console set device-fingerprint xbox rule-expression “((1 or 2) and 3)” set device-fingerprint xbox rule 1 type dhcp option-list EQ 53,61,60,55 set device-fingerprint xbox rule 2 type dhcp option-list EQ 53,61,60,55,50,54 set device-fingerprint game-generic rule 3 type dhcp option 60 CONTAINS "Xbox 360" Linux (Ubuntu) Rules

set device-fingerprint linux device-group other set device-fingerprint linux rule-expression "(1 or 2 or 3)" set device-fingerprint linux rule 1 type dhcp option-list EQ 53,12,55 set device-fingerprint linux rule 2 type dhcp option-list EQ 53,54,50,12,55 set device-fingerprint linux rule 3 type dhcp option-list EQ 53,50,12,55 Streaming Media Devices such as Roku

set device-fingerprint streaming device-group other set device-fingerprint streaming rule-expression "((1 or 2 or 3 or 4 or 5) and (6 or 7))" set device-fingerprint streaming rule 1 type dhcp option-list EQ 53,61,60,57,55 set device-fingerprint streaming rule 2 type dhcp option-list EQ 512




53,61,60,50,54,55 set device-fingerprint streaming rule 3 type dhcp option-list EQ 53,61,60,55 set device-fingerprint streaming rule 4 type dhcp option-list EQ 53,50,55,12 set device-fingerprint streaming rule 5 type dhcp option-list EQ 53,50,54,55,12 set device-fingerprint streaming rule 6 type dhcp option 55 EQ 1,3,6,15,28,42 set device-fingerprint streaming rule 7 type dhcp option 55 EQ 1,3,6,15,12 Hewlett-Packard Tablet with WebOS

set device-fingerprint webos device-group other set device-fingerprint webos rule-expression "((1 or 2) and 3)" set device-fingerprint webos rule 1 type dhcp option-list EQ 53,50,55 set device-fingerprint webos rule 2 type dhcp option-list EQ 53,54,50,55 set device-fingerprint webos rule 3 type dhcp option 55 EQ 1,28,2,3,15,6,12



513

Show Sessions Enhancements New parameters are available to filter sessions by device profile, device type, or device group. For example, show sessions network device-profile 17 sessions total Device profile: (none) User Name

SessID

Type

Address

VLAN

AP/Rdo

------------------

------

----

------------ -------

------

LR-ck-wpa2psk-4249

2079*

open

172.16.1.194 black

1/1

LR-ck-wpa2psk-4251

2080*

open

172.16.1.197 black

1/1

AP/Rdo

Device profile: android-dp User Name

SessID

Type

Address

VLAN

------------------

------

----

------------ -------

------

asus-tf101

2045*

mac

172.16.1.195 black

1/1

asus-tf102

2045*

mac

172.16.1.181 black

1/1

htc-wildfire-phone

2050*

mac

172.16.1.189 black

1/1

samsung-galaxy-tab

2046*

mac

172.16.1.184 black

1/1

AP/Rdo

Device profile: apple-dp User Name

SessID

Type

Address

VLAN

------------------

------

----

------------ -------

------

ipad2

2053*

mac

172.16.1.196 black

1/2

ipad3

2054*

mac

172.16.1.187 black

1/2

ipod-touch

2052*

mac

172.16.1.192 black

1/1

show sessions network device-group

514




17 sessions total

Device group: android User Name

SessID

Type

Address

VLAN

AP/Rdo

------------------

------

----

------------ -------

------

asus-tf101

2045*

mac

172.16.1.195 black

1/1

asus-tf102

2045*

mac

172.16.1.181 black

1/1

htc-wildfire-phone

2050*

mac

172.16.1.189 black

1/1

samsung-galaxy-tab

2046*

mac

172.16.1.184 black

1/1

User Name

SessID

Type

Address

AP/Rdo

------------------

------

----

------------ -------

------

ipad2

2053*

mac

172.16.1.196 black

1/2

ipad3

2054*

mac

172.16.1.187 black

1/2

ipod-touch

2052*

mac

172.16.1.192 black

1/1

AP/Rdo

Device group: apple VLAN

Device group: blackberry User Name

SessID

Type

Address

VLAN

------------------

------

----

------------ -------

------

blackberry

2077*

mac

172.16.1.198 black

1/1

AP/Rdo

Device group: windows User Name

SessID

Type

Address

------------------

------

----

------------ -------

------

windows8-tablet

2078*

mac

172.16.1.160 black

1/2

windowsxp-laptop

2059*

mac

172.16.1.179 black

1/2


VLAN


515

show sessions network device-type

17 sessions total

Device type: android User Name

SessID

Type

Address

VLAN

AP/Rdo

------------------

------

----

------------ -------

------

LG-VM670-phone

2081*

mac

172.16.1.180 black

1/1

asus-tf101

2045*

mac

172.16.1.195 black

1/1

asus-tf102

2045*

mac

172.16.1.181 black

1/1

htc-wildfire-phone

2050*

mac

172.16.1.189 black

1/1

samsung-galaxy-tab

2046*

mac

172.16.1.184 black

1/1

User Name

SessID

Type

Address

AP/Rdo

------------------

------

----

------------ -------

------

ipad2

2053*

mac

172.16.1.196 black

1/2

ipad3

2054*

mac

172.16.1.187 black

1/2

User Name

SessID

Type

Address

AP/Rdo

------------------

------

----

------------ -------

------

ipod-touch

2052*

mac

172.16.1.192 black

1/1

AP/Rdo

Device type: ipad VLAN

Device type: ipod VLAN

Device type: blackberry

516

User Name

SessID

Type

Address

------------------

------

----

------------ -------

------

blackberry

2077*

mac

172.16.1.198 black

1/1


VLAN



Device type: windows8 User Name

SessID

Type

Address

VLAN

AP/Rdo

------------------

------

----

------------ -------

------

windows8-tablet

2078*

mac

172.16.1.160 black

1/2

AP/Rdo

Device type: windows-xp User Name

SessID

Type

Address

VLAN

------------------

------

----

------------ -------

------

windowsxp-laptop

2059*

mac

172.16.1.179 black

1/2

Use Cases Controlling Network Access on a Corporate WLAN for a Personal iPad — A user joins the network through an 802.1X authentication process while using his personal iPad. Authentication is performed through a RADIUS server, credentials accepted, and an attribute is returned to the user allowing him to join VLAN1. The WLC detects that the user’s device is an iPad and applies a new ACL that only allows the user access to an e-mail server, and public internet access. Controlling User Bandwidth by Applying Different QoS Levels per Device Type — You want to apply a different CoS lelvel when an authorized user authenticates onto the WLAN with an iPhone instead of a corporate device. A device-profile, iphone, is configured with an attribute that caps the bandwidth at 2 Mbps. When an iPhone user authenticates successfully using 802.1X and a RADIUS server, an attribute is sent that allows the user to access VLAN RED. The WLC detects that the user has an iPhone and applies the QoS profile restricting bandwidth to 2 Mbps.



517

518



Configuring Device Fingerprinting Device fingerprinting is enabled on a per service-profile basis. With the introduction of device fingerprinting, a new concept is introduced called “device profile”, a collection of attributes that apply to a device. This information is stored on the WLC and each device profile can be assigned to a fingerprint. Different fingerprints can share the same device profile. Syntax set device-profile name attr [vlan-name name | filter-id acl-name | time-of-day time-of-day | qos-profile profile-name] deny-session name

The name assigned to the device profile.

vlan-name name

The name of the VLAN assigned to the profile which places the device on that VLAN.

filter-id acl-name

The ACL assigned to the profile that provides security policies for the device.

time-of-day time-of-day

A character string that denotes the time limitations for the device.

qos-profile profile-name

The name of the QoS profile assigned to the device.

deny session

Prevent certain devices from access the wireless network.

Defaults None, but you can configure a profile name with up to 32 characters. Access Enable History New in MSS 8.0 Usage Use this command to create a device profile that applies parameters based on the fingerprint of a device. You can create up to 50 different device profiles. If you configure more than one attribute, all of those attributes are applied to the session. If you configure the attribute, deny-session, the session is stopped. This attribute takes precendence over other attributes. A maximum of 50 profiles can be configured. Changes to the device-profile configuration are not applied immediately, but new sessions are affected. Existing sessions are affected when the client sends a new DHCP request or roam on the network. You can use the show config area device-profile command to display the configuration. Examples To assign the device profile, ipad-users, to the VLAN ipad, use the following command: WLC# set device-profile ipad-users attr vlan-name ipad success: change accepted. Any user with an iPad is assigned to the VLAN ipad after connecting to the network.


Configuring Device Fingerprinting

519

Syntax set service-profile name device-detect mode {disable | detect-only | enforce-policy} name

The name of the service profile that you want associated with device detection.

disable

Disables device detection if already enabled.

detect-only

Device detection is performed but no policies are applied to the device.

enforce-policy

Both detection and policy enforcement is enabled.

Defaults detect-only Access Enable History New in MSS 8.0 Usage Enables device fingerprinting on a service profile. Examples To enable device fingerprinting and enforce associated policies on the service profile, corp-byod, use the following command: WLC# set service-profile corp-byod device-detect mode enforce-policy success: change accepted.

Applying a Device Fingerprint A device fingerprint can be configured or you can select from a list of preconfigured fingerprints. You can also apply device profiles to multiple device fingerprints. Syntax set device-fingerprint [ipad2 | iphone4 | htc-explorer | android-generic | samsung-galaxy-s-plus | mac-osx-lion | nokia-generic | windows-mobile6 | windows-xp | name] ipad2

Apple iPad 2

iphone4

Apple iPhone 4

htc-explorer

HTC Explorer smart phone

android-generic

Includes not only android phones, tablets, but also Kindle Fire and Nook

samsung-galaxy-s-plus

Samsung mobile devices

mac-osx-lion

Macbooks running MacOS Lion

nokia-generic

Nokia mobile devices

windows-mobile6

Windows-based mobile devices

windows-xp

Laptops running Windows XP

name

A custom fingerprint up to 32 characters in length

Syntax

set device-fingerprint name device-profile profile-name

Defaults None Access Enabled History New in MSS 8.0 520



Usage Used to apply fingerprints to device profiles. Up to 50 fingerprints can be configured. Examples To set the fingerprint ipad-personal, use the following command: WLC# set device-fingerprint ipad-personal device-profile ipad success: change accepted.

Configuring Custom Device Fingerprints A custom device fingerprint can be configured and is identified by the device-type string of up to 32 characters. A device profile can be specified if policy enforcement is required. The same device profile can be applied to multiple fingerprints. set device-fingerprint device-type device-profile profile-name You can also configure a device-group consisting of a 32 character string. A device group is a set of devices that you want to group together under a single name. set device-fingerprint device-type device-group string

Adding Rules to Device Profiles To completely configure device fingerprinting, you can apply up to 20 numbered rules to each fingerprint. You can create a rule for matching the MAC address of the client with a configured MAC glob which is useful for OUI-based devices. Other rules can support DHCP-based device detection. set device-fingerprint device-type rule num mac-addr mac-glob MAC glob follows the current MSS implementation of globs. “Globbing” is a way of using a wildcard pattern to expand a single element into a list of elements that match the pattern. MSS accepts user globs, MAC address globs, and VLAN globs. The order in which globs appear in the configuration is important, because once a glob is matched, processing stops on the list of globs. There can be only one asterisk (*) and it must be the last character of the glob. The rest of the string can be up to 6 “:” separated bytes including the asterisk. For example, WLC# set device-fingerprint iphone rule 1 mac-addr 00:1b:63:* DHCP-based device detection rules are rules that examine flags or options in a DHCP packet. This can be useful in some cases where the client always broadcasts this information. Since the flags field is only two bytes in the DHCP packet, the dhcp flags attribute only accepts hexadecimal characters up to two bytes. It is a mask to match particular bits, and not an exact match of the flags field. set device-fingerprint device-type rule num type dhcp flags num To allow matching of specific DHCP options, you can set the following command to either match (eq) or not match (neq) a specific option. The option value must be a number between 1 and 254. set device-fingerprint device-type rule num type dhcp option num {eq | neq | contains | not-contains} string For the attribute, option num, the only valid format is a comma separated ordered list of DHCP options in the range of 1 to 254. The attribute, string, cannot exceed 255 characters which is the maximum length of a DHCP option. An option can only be specified once in a rule. Different DHCP options contain different kinds of data. Option 55 (Parameter List) contains a list of option numbers, and Option 12 (Host Name) contains free-form text. All options are allowed in the command. Copyright © 2013, Juniper Networks, Inc.


521

set device-fingerprint device-type rule num type option-list {eq |neq | contains |not-contains} string Once you’ve created your rules, you have to specify the combination of rules for each device fingerprint. For example, you can match all rules or any one of the configured rules. Or, match one rule and either of one of the remaining rules. If no combination is specified, then the default behavior is match all of the rules configured for the fingerprint. set device-fingerprint device-type rule-expression string You must configure rules before using this command. To use this command with rules 1, 2, 3 and an iPhone, use the following syntax: set device-fingerprint iphone rule-expression “1 and 2” set device-fingerprint iphone rule-expression “1 or 2” set device-fingerprint iphone rule-expression “1 and (2 or 3)”

Configuration Example for a Complete Device Fingerprint This example assumes that you have a group of iPhones used by employees who want access to your wireless LAN. You have the MAC address 00:1b:63:* to use as the MAC glob. WLC# set device-fingerprint iphone device-group iPhone4S WLC# set device-fingerprint iphone rule 1 mac-addr 00:1b:63:b* WLC# set device-fingerprint iphone rule 2 type dhcp option eq option 12 WLC# set device-fingerprint iphone rule 3 type dhcp option eq 55 WLC# set device-fingerprint iphone rule-expression “((1 and 3)or 2)” WLC# set device-fingerprint iphone device-profile iphone-policy You can delete the device fingerprint configuration by starting with the device type: WLC# clear device-fingerprint iphone

New VSAs for RADIUS There are four new RADIUS VSAs added as part of the device fingerprint configuration: Device-Profile Device-Type Device-Group Allowed-Devices Of these, Device-Type and Device-Group, are required only for accounting updates. Device-Profile and Allowed-Devices are returned by a AAA server in an Access-Accept message. When the device profile is used as an attribute, it functions as a fallthrough device profile. If MSS does not detect the device type for a given session then the device profile is applied. If there is no device profile configured, then the session remains unmodified. Informational Note: In this release, you can only apply the device-profile attribute to service profiles, mac-user, and mac-usergroup.

522



set mac-user name attr device-profile profile-name set mac-usergroup name attr device-profile profile-name set service-profile name attr device-profile profile-name If the attribute allowed-devices is used, network access is allowed on a device type basis. The attribute allowed-devices is a comma-delimited list of device-type strings. Maximum allowed length is 250 characters. For example, WLC# set mac-user 00:11:* attr allowed-devices iPhone This rule allows users matching the MAC glob to connect to the wireless LAN using only an iPhone. If you want to allow access for multiple devices for MAC users, use the following command: WLC# set mac-user 00:11:* attr allowed-devices iPhone, Windows If the mac-user has an iPhone and an iPad, but you don’t want to allow access for these devices, use the following command: WLC# set mac-user 00:11:* attr allowed-devices not:iPhone, not:iPad

Device Profile Attributes Preference When the device profile attribute is received as part of a AAA request, other attributes may be present as well. For instance, filter-id, time of day, and other attributes can be added to the configureation. By default, the device profile attribute should have preference over other attributes. However, you can configure the preference of device profiles over other attributes by using the following command: WLC# set authorization preference {device-profile | attr} This command also applies to cluster configurations. As an example, let’s say that the RADIUS server returned the following information as part of an Access-Accept packet: Device-Profile=iphone Qos-profile=low-bw Filter-id=device-detect-acl The WLC is configured with this device profile: WLC# set device-profile iphone attr qos-profile high-bw By default, the qos-profile high-bw is applied to the device profile, iphone. The filter-id is always applied to the configuration. However, if you give preference to the attribute, then the qos-profile attribute low-bw is applied to the device profile. WLC# set authorization preference attr

Configuring the Device Detect ACL The Device Detect ACL is configured automatically when you enable device policy enforcement on a service profile. This is similar to how the portalacl is configured when the parameter auth-fallthru is set to web-portal. The default configuration looks like this: WLC# set security acl name deviceacl permit udp 0.0.0. 255.255.255.255 eq 68.0.0.0 255.255.255.55 eq 67 Copyright © 2013, Juniper Networks, Inc.


523

WLC# set security acl name device acl deny 0.0.0.0 255.255.255.255 WLC# commit security acl deviceacl

Configuring Device Detect Timeout To configure the length of time for device detection on the network, use the following command: WLC# set service-profile name device-detect-timeout seconds The default value is 5 seconds with a range of 1 to 60 seconds.

524



Example Rules for Different Mobile Devices

Example Rules for Different Mobile Devices When this feature was tested, various mobile devices were used to validate device rules, profiles, and fingerprints. These example rules are included so that you can see how the rules are configured for a variety of devices. Informational Note:

Device fingerprinting rules must be configured in a specific order and the option-list must be configured in the order that the device sends the DHCP options. Even though it looks like the same options are used in different rules, the order of the options is critical to the implementation of the rules. iOS Rules

This group of rules can be used to recognize iPhones, iPads, and iPods that do not use DHCP Option 12 or sends Option 12 but the string does not contain iPhone, iPad, or iPod: set device-fingerprint ios-generic device-group ios set device-fingerprint ios-generic rule-expression “(((1 or 2) and (1 or 3) and (1 or 4)) and (5 or 6 or 7))” set device-fingerprint ios-generic rule 1 type dhcp option-list not-contains 12 set device-fingerprint ios-generic rule 2 type dhcp option 12 not-contains “iPhone” set device-fingerprint ios-generic rule 3 type dhcp option 12 not-contains “iPad” set device-fingerprint ios-generic rule 4 type dhcp option 12 not-contains “iPod” set device-fingerprint ios-generic rule 5 type dhcp option-list contains 53,55,57,61,51 set device-fingerprint ios-generic rule 6 type dhcp option-list eq 53,55,57,61,50,51 set device-fingerprint ios-generic rule 7 type dhcp option list eq 53,55,57,61,50,54


525

iPad Rules

set device-fingerprint ipad device-group ios set device-fingerprint ipad rule-expression “(1 and (2 or 3 or 4))” set device-fingerprint ipad rule 1 type dhcp option 12 contains “iPad” set device-fingerprint ipad rule 2 type dhcp option-list eq 53,55,57,61,50,51,12 set device-fingerprint ipad rule 3 type dhcp option-list eq 53,55,57,61,51,12 set device-fingerprint ipad rule 4 type dhcp option-list eq 53,55,57,61,50,54,12

iPhone Rules

set device-fingerprint iphone device-group ios set device-fingerprint iphone rule-expression “(1 and (2 or 3 or 4))” set device-fingerprint iphone rule 1 type dhcp option 12 contains “iPhone” set device-fingerprint iphone rule 2 type dhcp option-list eq 53,55,57,61,51,12 set device-fingerprint iphone rule 3 type dhcp option-list eq 53,55,57,61,50,51,12 set device-fingerprint iphone rule 4 type dhcp option-list eq 53,55,57,61,50,54,12 iPod Rules

set device-fingerprint ipod device-group ios set device-fingerprint ipod rule-expression “(1 and (2 or 3 or 4))” set device-fingerprint ipod rule 1 type dhcp option contains “iPod” set device-fingerprint ipod rule 2 type dhcp option-list eq 53,55,57,61,51,12

526



set device-fingerprint ipod rule 3 type dhcp option-list eq 53,55,57,61,50,51,12 set device-fingerprint ipod rule 4 type dhcp option-list eq 53,55,57,61,50,54,12 Android Rules

set device-fingerprint android-generic device-group android set device-fingerprint android-generic rule-expression “((1 or 2) and 3)” set device-fingerprint android-generic rule 1 type dhcp option-list EQ 53,57,60,12,55 set device-fingerprint android-generic rule 2 type dhcp option-list EQ 53,50,54,57,60,12,55 set device-fingerprint android-generic rule 3 type dhcp option 55 eq 1,121,33,3,6,15,28,51,58,59,119

MacOS on MacBook Pro and MacBook Air

set device-fingerprint macos-generic device-group macosx set device-fingerprint mac-os rule-expression "((1 or 2 or 4 or 5 or 6) and (3 or 7))" set device-fingerprint macos-generic rule 1 type dhcp option-list EQ 53,55,57,61,51 set device-fingerprint macos-generic rule 2 type dhcp option-list EQ 53,55,57,61,50,54 set device-fingerprint macos-generic rule 3 type dhcp option 55 EQ 1,3,6,15,119,95,252,44,46 set device-fingerprint macos-generic rule 4 type dhcp option-list EQ 53,55,57,61,51,12


527

set device-fingerprint macos-generic rule 5 type dhcp option-list EQ 53,55,57,61,50,54,12 set device-fingerprint macos-generic rule 6 type dhcp option-list EQ 53,55,57,61,50,51 set device-fingerprint macos-generic rule 8 type dhcp option 55 EQ 1,3,6,15,119,95,252,44,46,47 Blackberry Bold 9700

set device-fingerprint blackberry device-group blackberry set device-fingerprint blackberry rule-expression "(1 or 2)" set device-fingerprint blackberry rule 1 type dhcp option-list EQ 53,12,60,61,55 set device-fingerprint blackberry rule 2 type dhcp option-list EQ 53,54,50,12,60,61,55 Windows Computers and Phones

set device-fingerprint windows-generic device-group windows set device-fingerprint windows-generic rule-expression "((1 or 2 or 3) and (4 or 5)and 6)" set device-fingerprint windows-generic rule 1 type dhcp option-list EQ 53,116,61,50,12,60,55,43 set device-fingerprint windows-generic rule 2 type dhcp option-list EQ 53,116,61,12,60,55 set device-fingerprint windows-generic rule 3 type dhcp option-list EQ 53,61,50,54,12,81,60,55,43 set device-fingerprint windows-generic rule 4 type dhcp option 55 EQ 1,15,3,6,44,46,47,31,33,249,43 set device-fingerprint windows-generic rule 5 type dhcp option 55 EQ 1,15,3,6,44,46,47,31,33,121,249,43

528



set device-fingerprint windows-generic rule 6 type dhcp option 60 EQ "MSFT 5.0" Windows XP Rules set device-fingerprint windows-xp device-group windows set device-fingerprint windows-xp rule-expression "((1 or 2 or 3 or 4) and 5 and 6)" set device-fingerprint windows-xp rule 1 type dhcp option-list EQ 53,116,61,50,12,60,55,43 set device-fingerprint windows-xp rule 2 type dhcp option-list EQ 53,116,61,12,60,55,43 set device-fingerprint windows-xp rule 3 type dhcp option-list EQ 53,61,50,12,60,55,43 set device-fingerprint windows-xp rule 4 type dhcp option-list EQ 53,116,61,50,12,60,55 set device-fingerprint windows-xp rule 5 type dhcp option 55 EQ 1,15,3,6,44,46,47,31,33,249,43 set device-fingerprint windows-xp rule 6 type dhcp option 60 EQ "MSFT 5.0" Windows7 Rules set device-fingerprint windows7 device-group windows set device-fingerprint windows7 rule-expression "((1 or 2 or 3 or 4 or 5) and 6 and 7)" set device-fingerprint windows7 rule 1 type dhcp option-list EQ 53,61,50,54,12,81,60,55 set device-fingerprint windows7 rule 2 type dhcp option-list EQ 53,61,50,12,60,55 set device-fingerprint windows7 rule 3 type dhcp option-list EQ Copyright © 2013, Juniper Networks, Inc.

529

53,61,50,12,81,60,55 set device-fingerprint windows7 rule 4 type dhcp option-list EQ 53,61,50,12,60,55 set device-fingerprint windows7 rule 5 type dhcp option-list EQ 53,61,50,54,12,60,55 set device-fingerprint windows7 rule 6 type dhcp option 55 EQ 1,15,3,6,44,46,47,31,33,121,249,43 set device-fingerprint windows7 rule 7 type dhcp option 60 EQ "MSFT 5.0" Windows 8

set device-fingerprint windows8 device-group windows set device-fingerprint windows8 rule-expression “((1 or 2 or 3) and 4 and 5)” set device-fingerprint windows8 rule 1 type dhcp option-list eq 53,61,12,60,55 set device-fingerprint windows8 rule 2 type dhcp option-list eq 53,61,50,12,81,60,55 set device-fingerprint windows8 rule 3 type dhcp option-list eq 53,61,50,54,12,81,60,55 set device-fingerprint windows8 rule 4 type dhcp option 55 eq 1,15,3,6,44,46,47,31,33,121,249,252,43 set device-fingerprint windows8 rule 5 type dhcp option 60 eq “MSFT 5.0” Windows Mobile Phone OS

set device-fingerprint windows-phone7 device-group windows-phone set device-fingerprint windows-phone7 rule-expression "((1 or 2 or 3 or 4 or 5 or 6)and (7 or 8)" set device-fingerprint windows-phone7 rule 1 type dhcp option-list EQ 53,61,50,54,12,81,60,55

530



set device-fingerprint windows-phone7 rule 2 type dhcp option-list EQ 53,61,50,12,60,55 set device-fingerprint windows-phone7 rule 3 type dhcp option-list EQ 53,61,50,12,81,60,55 set device-fingerprint windows-phone7 rule 4 type dhcp option-list EQ 53,61,50,12,60,55 set device-fingerprint windows-phone7 rule 5 type dhcp option-list EQ 53,61,55 set device-fingerprint windows-phone7 rule 6 type dhcp option-list EQ 53,54,50,61,55 set device-fingerprint windows-phone7 rule 7 type dhcp option-list not-contains 60 set device-fingerprint windows-phone7 rule 8 type dhcp option 60 not-contains “MSFT 5.0” Printer Rules

set device-fingerprint printer device-group printer set device-fingerprint printer rule-expression "((1 or 2 or 3 or 4 or 5 or 6) and (7 or 8))" set device-fingerprint printer rule 1 type dhcp option-list EQ 53,61,55 set device-fingerprint printer rule 2 type dhcp option-list EQ 53,61,50,12,55 set device-fingerprint printer rule 3 type dhcp option-list EQ 3,6,15,44,47 set device-fingerprint printer rule 4 type dhcp option-list EQ 1,3,6,15,44,47 set device-fingerprint printer rule 5 type dhcp option-list EQ 1,3.12,23,6,15 Copyright © 2013, Juniper Networks, Inc.

531

set device-fingerprint printer rule 6 type dhcp option-list EQ 53,61,50,55 set device-fingerprint printer rule 7 type dhcp option 55 eq 6,3,1,15,66,67,13,44,12,81 set device-fingerprint printer rule 8 type dhcp option 55 eq 1,3,6 Gaming Console Rules

Playstation set device-fingerprint playstation device-group game-console set device-fingerprint playstation rule-expression "((1 or 2) and (3 or 4))" set device-fingerprint playstation rule 1 type dhcp option-list EQ 53,61,60 set device-fingerprint playstation rule 2 type dhcp option-list EQ 53,50,54,55,61,60 set device-fingerprint playstation rule 3 type dhcp option 60 CONTAINS "PS Vita" set device-fingerprint playstation rule 4 type dhcp option 60 CONTAINS "PS3"

Wii set device-fingerprint wii device-group game-console set device-fingerprint wii rule-expression “((1 or 2 or 3) and 4)” set device-fingerprint wii rule 1 type dhcp option-list EQ 53,61,50,12,55 set device-fingerprint wii rule 2 type dhcp option-list EQ 53,61,12,55 set device-fingerprint wii rule 3 type dhcp option-list EQ 53,54,61,50,12,55

532



set device-fingerprint wii rule 4 type dhcp option 12 CONTAINS "Wii" xBox

set device-fingerprint xbox device-group game-console set device-fingerprint xbox rule-expression “((1 or 2) and 3)” set device-fingerprint xbox rule 1 type dhcp option-list EQ 53,61,60,55 set device-fingerprint xbox rule 2 type dhcp option-list EQ 53,61,60,55,50,54 set device-fingerprint game-generic rule 3 type dhcp option 60 CONTAINS "Xbox 360" Linux (Ubuntu) Rules

set device-fingerprint linux device-group other set device-fingerprint linux rule-expression "(1 or 2 or 3)" set device-fingerprint linux rule 1 type dhcp option-list EQ 53,12,55 set device-fingerprint linux rule 2 type dhcp option-list EQ 53,54,50,12,55 set device-fingerprint linux rule 3 type dhcp option-list EQ 53,50,12,55 Streaming Media Devices such as Roku

set device-fingerprint streaming device-group other set device-fingerprint streaming rule-expression "((1 or 2 or 3 or 4 or 5) and (6 or 7))" set device-fingerprint streaming rule 1 type dhcp option-list EQ 53,61,60,57,55 set device-fingerprint streaming rule 2 type dhcp option-list EQ Copyright © 2013, Juniper Networks, Inc.

533

53,61,60,50,54,55 set device-fingerprint streaming rule 3 type dhcp option-list EQ 53,61,60,55 set device-fingerprint streaming rule 4 type dhcp option-list EQ 53,50,55,12 set device-fingerprint streaming rule 5 type dhcp option-list EQ 53,50,54,55,12 set device-fingerprint streaming rule 6 type dhcp option 55 EQ 1,3,6,15,28,42 set device-fingerprint streaming rule 7 type dhcp option 55 EQ 1,3,6,15,12 Hewlett-Packard Tablet with WebOS

set device-fingerprint webos device-group other set device-fingerprint webos rule-expression "((1 or 2) and 3)" set device-fingerprint webos rule 1 type dhcp option-list EQ 53,50,55 set device-fingerprint webos rule 2 type dhcp option-list EQ 53,54,50,55 set device-fingerprint webos rule 3 type dhcp option 55 EQ 1,28,2,3,15,6,12

534



Show Sessions Enhancements New parameters are available to filter sessions by device profile, device type, or device group. For example, show sessions network device-profile 17 sessions total Device profile: (none) User Name

SessID

Type

Address

VLAN

AP/Rdo

------------------

------

----

------------ -------

------

LR-ck-wpa2psk-4249

2079*

open

172.16.1.194 black

1/1

LR-ck-wpa2psk-4251

2080*

open

172.16.1.197 black

1/1

AP/Rdo

Device profile: android-dp User Name

SessID

Type

Address

VLAN

------------------

------

----

------------ -------

------

asus-tf101

2045*

mac

172.16.1.195 black

1/1

asus-tf102

2045*

mac

172.16.1.181 black

1/1

htc-wildfire-phone

2050*

mac

172.16.1.189 black

1/1

samsung-galaxy-tab

2046*

mac

172.16.1.184 black

1/1

AP/Rdo

Device profile: apple-dp User Name

SessID

Type

Address

VLAN

------------------

------

----

------------ -------

------

ipad2

2053*

mac

172.16.1.196 black

1/2

ipad3

2054*

mac

172.16.1.187 black

1/2

ipod-touch

2052*

mac

172.16.1.192 black

1/1

show sessions network device-group


535

17 sessions total

Device group: android User Name

SessID

Type

Address

VLAN

AP/Rdo

------------------

------

----

------------ -------

------

asus-tf101

2045*

mac

172.16.1.195 black

1/1

asus-tf102

2045*

mac

172.16.1.181 black

1/1

htc-wildfire-phone

2050*

mac

172.16.1.189 black

1/1

samsung-galaxy-tab

2046*

mac

172.16.1.184 black

1/1

User Name

SessID

Type

Address

AP/Rdo

------------------

------

----

------------ -------

------

ipad2

2053*

mac

172.16.1.196 black

1/2

ipad3

2054*

mac

172.16.1.187 black

1/2

ipod-touch

2052*

mac

172.16.1.192 black

1/1

AP/Rdo

Device group: apple VLAN

Device group: blackberry User Name

SessID

Type

Address

VLAN

------------------

------

----

------------ -------

------

blackberry

2077*

mac

172.16.1.198 black

1/1

AP/Rdo

Device group: windows

536

User Name

SessID

Type

Address

VLAN

------------------

------

----

------------ -------

------

windows8-tablet

2078*

mac

172.16.1.160 black

1/2

windowsxp-laptop

2059*

mac

172.16.1.179 black

1/2



show sessions network device-type

17 sessions total

Device type: android User Name

SessID

Type

Address

VLAN

AP/Rdo

------------------

------

----

------------ -------

------

LG-VM670-phone

2081*

mac

172.16.1.180 black

1/1

asus-tf101

2045*

mac

172.16.1.195 black

1/1

asus-tf102

2045*

mac

172.16.1.181 black

1/1

htc-wildfire-phone

2050*

mac

172.16.1.189 black

1/1

samsung-galaxy-tab

2046*

mac

172.16.1.184 black

1/1

User Name

SessID

Type

Address

AP/Rdo

------------------

------

----

------------ -------

------

ipad2

2053*

mac

172.16.1.196 black

1/2

ipad3

2054*

mac

172.16.1.187 black

1/2

User Name

SessID

Type

Address

AP/Rdo

------------------

------

----

------------ -------

------

ipod-touch

2052*

mac

172.16.1.192 black

1/1

AP/Rdo

Device type: ipad VLAN

Device type: ipod VLAN

Device type: blackberry User Name

SessID

Type

Address

------------------

------

----

------------ -------

------

blackberry

2077*

mac

172.16.1.198 black

1/1


VLAN

537

Device type: windows8 User Name

SessID

Type

Address

VLAN

AP/Rdo

------------------

------

----

------------ -------

------

windows8-tablet

2078*

mac

172.16.1.160 black

1/2

AP/Rdo

Device type: windows-xp User Name

SessID

Type

Address

VLAN

------------------

------

----

------------ -------

------

windowsxp-laptop

2059*

mac

172.16.1.179 black

1/2

Use Cases Controlling Network Access on a Corporate WLAN for a Personal iPad — A user joins the network through an 802.1X authentication process while using his personal iPad. Authentication is performed through a RADIUS server, credentials accepted, and an attribute is returned to the user allowing him to join VLAN1. The WLC detects that the user’s device is an iPad and applies a new ACL that only allows the user access to an e-mail server, and public internet access. Controlling User Bandwidth by Applying Different QoS Levels per Device Type — You want to apply a different CoS lelvel when an authorized user authenticates onto the WLAN with an iPhone instead of a corporate device. A device-profile, iphone, is configured with an attribute that caps the bandwidth at 2 Mbps. When an iPhone user authenticates successfully using 802.1X and a RADIUS server, an attribute is sent that allows the user to access VLAN RED. The WLC detects that the user has an iPhone and applies the QoS profile restricting bandwidth to 2 Mbps.

538


Part 4 - Adding Enterprise Functionality to the Wireless Network


695

696


About Mobility Domains

About Mobility Domains A Mobility Domain is a system of WLC switches and WLAs working together to support roaming wireless clients. Tunnels and virtual ports between the WLC switches in a Mobility Domain allow users to roam without any disruption to network connectivity. Informational Note: Juniper Networks recommends that you run the same MSS version on all the WLC switches in a Mobility Domain.

About the Mobility Domain Feature A Mobility Domain enables users to roam geographically across the system while maintaining data sessions and VLAN or subnet membership, including IP address, regardless of connectivity to the network backbone. As users move from one area of a building or campus to another, client associations with servers or other resources appears the same. When users access an WLC in a Mobility Domain, they become members of the VLAN designated through their authorized identity. If a native VLAN is not present on the accessed WLC, the WLC forms a tunnel to an WLC in the Mobility Domain that includes the native VLAN. In a Mobility Domain, one WLC acts as a seed device, and distributes information to the WLC switches defined in the Mobility Domain. Otherwise, the seed WLC operates as any other Mobility Domain member.

Smart Mobile Virtual Controller Cluster (Network Resiliency) Network Resiliency is the ability of the network to provide and maintain an acceptable level of service when interruptions occur during normal network operation. Juniper Networks uses innovative clustering technology between WLC switches to ensure mobility across an entire wireless network. With clustering, you can effortlessly create logical groups of WLC switches and WLAs, which proactively share network and user information for hitless failover support. You can also create a single point of configuration for small and large WLAN deployments to reduce the cost of installation and network management. Adding WLCs and WLAs is seamless and does not require an interruption of connectivity in your existing network. Smart Mobile Virtual Controller Clustering provides distributed network intelligence that enables fast, transparent failover to overcome network and device interruptions and provides a means of central configuration and distribution for WLCs and WLAs on the network. The features of cluster configuration include the following: Centralized configuration of WLCs and WLAs. Autodistribution of configuration parameters to WLAs. “Hitless” failover on the network if an WLC is unavailable.


About the Mobility Domain Feature

697

Automatic load balancing of WLAs across any WLCs in the cluster. AP Affinity groups on each cluster member. The WLA establishes a backup link on a cluster member when the WLC system IP is different from the WLA IP address without the need for a Layer 3 device. The ability to view WLA information for all WLAs in the cluster configuration using CLI commands on the cluster seed. Informational Note: The number of WLAs supported on a cluster member is limited to the number supported on an WLC. It is recommended to use larger capacity WLCs, such as WLC200s or WLC2800s in your configuration to obtain the maximum benefits of cluster configuration. Informational Note: To configure Virtual Controller Cluster services to your network, see “Smart Mobile Virtual Controller Cluster Configuration” on page 703.

698

Smart Mobile Virtual Controller Cluster (Network Resiliency)


Configuring a Mobility Domain

Configuring a Mobility Domain The WLC switches in a Mobility Domain use a system IP address for Mobility Domain communication. To support the services of the Mobility Domain, the WLC system IP address requires basic IP connectivity to the system IP address of every other WLC. (For information about setting the system IP address for the WLC switch, see Configuring and Managing IP Interfaces and Services on page 307) To create a Mobility Domain: 1. Designate a seed WLC. 2. Create a list of the member WLC switches. 3. Configure each member WLC to point to the seed WLC. 4. Optionally configure a redundant seed WLC. You can view the status and configuration of a Mobility Domain, clear members, and clear all Mobility Domain configuration from an WLC.

Configuring the Seed You must explicitly configure only one WLC per domain as the primary seed. All other WLC switches in the domain receive their Mobility Domain information from the seed. Use the following command to set the current WLC as the seed device and name the Mobility Domain: set mobility-domain mode seed domain-name mob-domain-name For example, the following command sets the current WLC as the seed and names the Mobility Domain Pleasanton: WLC# set mobility-domain mode seed domain-name Pleasanton success: change accepted. The Mobility Domain name is assigned to the seed WLC only. The WLC system IP address is used as the source IP address for all Mobility Domain communications. If the system IP address is not set, MSS issues a warning when you enter the set mobility-domain mode seed domain-name command, stating that the Mobility Domain is not operational until the system IP is set. Optionally, you can configure a redundant seed WLC, which takes over seed duties if the primary seed becomes unavailable. See “Configuring Mobility Domain Seed Redundancy” on page 700.

Configuring Member WLC Switches on the Seed To configure the list of members on the Mobility Domain seed for distribution to other member WLC switches, use the following command on the seed WLC switch: set mobility-domain member ip-addr For example, the following commands add two members with IP addresses 192.168.12.7 and 192.168.15.5 to a Mobility Domain whose seed is the current WLC: WLC# set mobility-domain member 192.168.12.7 success: change accepted. WLC# set mobility-domain member 192.168.15.5 Copyright © 2013, Juniper Networks, Inc.

699

success: change accepted. Each command adds a member identified by an IP address to the list of Mobility Domain members. If the WLC is not configured as a seed, the command is rejected.

Configuring a Member To configure a member WLC in the Mobility Domain, enter the following command when logged in to the nonseed member WLC switch: set mobility-domain mode member seed-ip ip-addr This command configures the IP destination address used to communicate with the seed WLC. For example, the following command configures the current WLC as a member of the Mobility Domain whose seed is 192.168.253.6: WLC# set mobility-domain mode member seed-ip 192.168.253.6 success: change accepted. This command sets the WLC as a member of the Mobility Domain defined on the seed device at the identified address. If the WLC is currently part of another Mobility Domain or using another seed WLC, this command overwrites that configuration. After you enter this command, the member WLC obtains a new list of members from the new seed IP address.

Configuring Mobility Domain Seed Redundancy You can optionally specify a secondary seed in a Mobility Domain. The secondary seed provides redundancy for the primary seed switch in the Mobility Domain. If the primary seed becomes unavailable, the secondary seed assumes the role of the seed WLC. This allows the Mobility Domain to continue functioning if the primary seed becomes unavailable. Specifying a secondary seed for a Mobility Domain is useful since it eliminates the single point of failure if connectivity to the seed WLC is lost. When the primary seed switch fails, the remaining members form a Mobility Domain, with the secondary seed taking over as the primary seed WLC. If countermeasures are in effect on the primary seed, the functionality ceases while the secondary seed gathers RF data from the member switches. Once the secondary seed has rebuilt the RF database, countermeasures can be restored. VLAN tunnels (other than those between the member switches and the primary seed) continue to operate normally. Roaming and session statistics continue to be gathered, providing that the primary seed is uninvolved with roaming. When the primary seed is restored, it resumes its role as the primary seed WLC in the Mobility Domain. The secondary seed returns to the role of a regular Mobility Domain member. Use the following commands to configure a Mobility Domain consisting of a primary seed, secondary seed, and one or more member switches: On the primary seed: set mobility-domain mode seed domain-name domain-name 700


Configuring a Mobility Domain

set mobility-domain member ip-addr (for each member WLC) On the secondary seed: set mobility-domain mode secondary-seed domain-name domain-name seed-ip primary-seed-ip-addr set mobility-domain member ip-addr (for each member WLC) On the other member WLC switches in the Mobility Domain: set mobility-domain mode member seed-ip primary-seed-ip-addr set mobility-domain mode member secondary-seed-ip secondary-seed-ip-addr

Displaying Mobility Domain Status To view the status of the Mobility Domain for the WLC, use the show mobility-domain command. For example: WLC# show mobility-domain Mobility Domain name:

Mobility1

Flags: u = up[2], d = down[2], c = cluster enabled[1], p = primary seed, s = secondary seed, m = member, a = active seed, y = syncing, w = waiting to sync, n = sync completed, f = sync failed Member

Flags

Model

Version

NoAPs

APLic

---------------

-----

--------

----------

-----

-----

10.8.107.1

upacn

WLC20

7.0.1.0

0

40

10.2.28.71

dm---

Unknown

Unknown

0

0

10.2.28.72

dm---

Unknown

Unknown

0

0

10.2.28.74

um---

WLC20

7.0.1.0

0

40

Displaying the Mobility Domain Configuration To view the configuration of the Mobility Domain, use the show mobility-domain config command on either the seed or a nonseed member. To view Mobility Domain configuration on the seed: MX-20#show mobility-domain config This WLC is the seed for domain Pleasanton. 192.168.12.7 is a member 192.168.15.5 is a member To view Mobility Domain configuration on a member: MX-20#show mobility-domain config This WLC is a member, with seed 192.168.14.6

Clearing a Mobility Domain from an WLC You can clear all Mobility Domain configuration from an WLC.


701

You might want to clear the Mobility Domain information to change an WLC from one Mobility Domain to another, or to remove an WLC from the Mobility Domain. To clear the Mobility Domain, type the following command: MX-20#clear mobility-domain success: change accepted

Clearing a Mobility Domain Member from a Seed You can remove individual members from the Mobility Domain on the seed WLC. To remove a specific member of the Mobility Domain, type the following command: clear mobility-domain member ip-addr This command has no effect if the WLC member is not configured as part of a Mobility Domain or the current WLC is not the seed.

702



Smart Mobile Virtual Controller Cluster (Network Resiliency) Network Resiliency is the ability of the network to provide and maintain an acceptable level of service when interruptions occur during normal network operation. Juniper Networks uses innovative clustering technology between WLC switches to ensure mobility across an entire wireless network. With clustering, you can effortlessly create logical groups of WLC switches and WLAs, which proactively share network and user information for hitless failover support. You can also create a single point of configuration for small and large WLAN deployments to reduce the cost of installation and network management. Adding WLCs and WLAs is seamless and does not require an interruption of connectivity in your existing network. Smart Mobile Virtual Controller Clustering provides distributed network intelligence that enables fast, transparent failover to overcome network and device interruptions and provides a means of central configuration and distribution for WLCs and WLAs on the network. The features of cluster configuration include the following: Centralized configuration of WLCs and WLAs. Autodistribution of configuration parameters to WLAs. “Hitless” failover on the network if an WLC is unavailable. Automatic load balancing of WLAs across any WLCs in the cluster. AP Affinity groups on each cluster member. The WLA establishes a backup link on a cluster member when the WLC system IP is different from the WLA IP address without the need for a Layer 3 device. The ability to view WLA information for all WLAs in the cluster configuration using CLI commands on the cluster seed. Informational Note: The number of WLAs supported on a cluster member is limited to the number supported on an WLC. It is recommended to use larger capacity WLCs, such as WLC200s or WLC2800s in your configuration to obtain the maximum benefits of cluster configuration. Informational Note: To configure Virtual Controller Cluster services to your network, see “Smart Mobile Virtual Controller Cluster Configuration” on page 1–703.

Smart Mobile Virtual Controller Cluster Configuration This section discusses the following configurations: “Virtual Controller Cluster Configuration Terminology” on page 704 “Centralized Configuration Using Virtual Controller Cluster Mode” on page 704 “Autodistribution of WLAs on the Virtual Controller Cluster” on page 705 “Hitless Failover with Virtual Controller Cluster Configuration” on page 705 “Dot1X Settings in a Cluster Configuration” on page 711


Smart Mobile Virtual Controller Cluster Configuration

703

“CLI Enhancements for Network Resiliency” on page 711

Virtual Controller Cluster Configuration Terminology Domain configuration – Wireless parameters in the configuration file, including radio profiles, service profiles, AP configuration, and more. The Domain configuration is typically duplicated among more than one WLC in a cluster. Configuration Cluster – The cluster subset of WLCs in a Mobility Domain that share a domain configuration. Primary AP Manager (PAM) – The WLC in the cluster responsible for actively managing APs that receive configuration information from the PAM. Secondary AP Manager (SAM) – The WLC in the cluster acting as the hot standby for an AP. Resiliency — Every WLA in the Mobility Domain has a secondary backup link. If the primary WLC for a WLA fails, the WLA and its sessions failover to the backup link. Degraded — Only some WLAs have backup links to WLCs. If the primary WLC of a WLA without a backup link fails, the WLA reboots and loses its sessions.

Centralized Configuration Using Virtual Controller Cluster Mode Cluster mode is a subset of a Mobility Domain. A predetermined set of configuration parameters are distributed from the primary seed to members of the cluster in a load balanced manner. The WLA parameters are then distributed to the WLAs on each WLC. A member of a configuration cluster does not have a local copy of the domain configuration unless it is the primary or secondary seed. − An WLC cannot boot an AP without network connectivity to the primary or secondary seed. − The domain configuration is created and managed by the active seed. − The secondary seed provides redundancy for configuration management to the primary seed. − The primary seed takes precedence over the secondary seed if there are conflicting configurations between them. The only exception is if you explicitly override the configuration. − Changes to the secondary seed are not allowed while the primary seed is active on the network. Adding more WLCs to the cluster to increase WLA booting capacity is seamless and requires no configuration changes to more than one WLC in the cluster. Configuration changes for WLCs can only be performed on the primary seed of the Mobility Domain, or the secondary seed if one is configured and the primary seed is unavailable. The single point of configuration now extends to include most of the AAA-related configuration in cluster mode. Enables upgrades while the cluster is active on the network. Support connections to the WLC IP address other than the local WLC IP address.

704




Autodistribution of WLAs on the Virtual Controller Cluster Load balancing of WLAs is supported across the cluster without any explicit configuration. The maximum number of configured WLAs on the cluster is restricted by the maximum number of configured WLAs on the primary or secondary seed. Larger capacity WLCs should be used for larger deployments of WLAs. Client session states are shared among WLCs in the cluster configuration.

Hitless Failover with Virtual Controller Cluster Configuration You can seamlessly upgrade to a newer version of MSS without experiencing service interruption if there is sufficient WLA capacity in the cluster configuration. WLCs are upgraded one at a time and then synchronized with the primary seed. WLAs are upgraded with minimal impact on sessions. If the WLC detects a different software version from the primary seed, the WLC sends the information to the Primary Seed during the initial synchronization process. The Primary Seed also sends the information to the Secondary Seed if preempt mode is enabled on the Secondary Seed.

Informational Note: However, the configuration changes made on the primary seed during a cluster upgrade of MSS gets synchronized only to the upgraded members on the cluster and not to the yet to be upgraded members. But they will get synchronized once the member gets upgraded to the same version of MSS as that of the primary seed. It is recommended not to make any configuration changes during a cluster upgrade.

The WLC upgrades multiple WLAs at the same time in order to speed up the upgrade process, but the WLC does not simultaneously upgrade neighboring WLAs. This way, client connections can roam to another WLA while the neighboring WLA upgrades. However, if a WLA is isolated, client sessions are dropped anyway. The WLC selects a few WLAs at a time to reset for the upgrade process. This is repeated every few minutes until all WLAs are reset. WLAs without sessions are the primary targets for upgrading and are reset first. WLAs with sessions are reset in subsequent cycles. If there are only WLAs with sessions on the network, the WLC uses the RF Neighbor feature to compile a list of WLAs to reset in that cycle to try and ensure that at clients have at least one other WLA to roam to during the upgrade. At least one WLA is selected per cycle. The WLC sends an AP_LOAD_BALANCE TLV (Type-length-value) packet with an infinite duration time to selected WLAs with sessions. Even if load balancing is disabled, and the WLA receives the TLV packet, the WLA stops responding to client requests including probes, association requests, or other requests. Once the WLA is clear, it is reset. Once the WLAs are reset, the Primary Seed ensures that the WLA is assigned to an upgraded WLC in order to get the latest version of software. Failure of an WLC has no adverse impact on the current installation. Existing clients and WLAs remain active on the network and there is no impact on the ability to make cluster configuration changes while the WLC is in a failure state. WLAs connected to an WLC failover to another WLC in the cluster without resetting on the network.



705

Existing client sessions on an WLA are not disconnected if the WLC is in the process of failing. Client session states are shared between WLCs with a configuration profile for an WLA. This ensures proper network resiliency capability. Keepalive packets are sent between the primary seed and the cluster members to ensure that all members are available. As an example, let's assume that your network consists of a Primary Seed (PS), a Secondary Seed (SS), one Member (M1), and a second Member (M2.) You then follow this process for upgrading software versions: 1. Install the software image on all WLCs in the cluster, and set the boot partition accordingly. 2. Inform the PS to upgrade the cluster by using the upgrade cluster command or using RingMaster. An error is returned if any of the following conditions exist on the network: The cluster configuration is not resilient. For example, there are WLAs without backup links on the network. In this case, use the upgrade cluster force command. There are unsaved changes on the network. The "force" option ignores unsaved changes. The SS is down. The PS adds an entry in a cluster database (shared with the SS) for each cluster member. This database tracks the progress of the upgrade process Upgrade State PS Upgrading SS Pending M1 Pending M2 Pending The PS then reboots. 3. After the PS rejoins the cluster, MSS detects, based on the cluster database entries sent by the SS, that a cluster upgrade is in progress, and does not assign any WLAs to the PS while the WLAs are load balancing on the network. The reason for this behavior is that the PS is now running a different version of MSS than the other WLCs. If the cluster is operating at or near capacity, some WLAs may not have backup links even though the PS is up. Cluster Upgrade Status now has the following status: Upgrade State PS Upgraded SS Pending M1 Pending M2 Pending 4. The next WLC to upgrade is the SS. Once the SS successfully upgrades, the PS selects one member at a time for upgrading until all members are upgraded. 5. To upgrade the next member, the PS sends an AP-UPGRADE message to the next WLC in the configuration. After the SS is upgraded, members are upgraded in the order they were added to the PS seed configuration.

706




6. The member resets all of the WLAs. When all of the WLAs are reset, the SS or member notifies the PS. The PS sends a message to the SS or member to reboot. 7. The PS waits for the SS or reboot and synchronize with the PS. The PS notifies the next WLC to upgrade . The PS and subsequent upgraded WLCs then load balance the WLAs between them. This process is repeated until all members are upgraded. During the upgrade process, the cluster configuration may not be resilient to WLC failures. Since a WLA cannot have a primary link with a WLC running one version and a backup link on another WLC with a different version, the upgrade process causes some WLAs to lose the backup link even though there is capacity on the network. If the PS fails during the upgrade process, the upgrade is stopped, and the SS maintains the existing upgrade state at the time and provides it to the PS when the PS is again operational. The Upgrade Status is displayed as Upgrade Failed. Downgrading the MSS version works in the manner as the Upgrade process.

Configuring AP Affinity for Cluster Members AP Affinity groups are configured on each cluster member. This information is shared in the cluster database so that seeds have information on the AP affinity group memberships of all cluster members. Based on the IP address of the AP, the seed selects the PAM and SAM from the group of WLCs with a configured affinity for that subnet. In the event of an WLC failure, the AP fails over to a controller outside of a preferred group. When the WLC is restored, the AP reverts back to the preferred WLC. If a WLA does not belong to an affinity group, it is load balanced between all available cluster members. If there is no capacity on the affinity group members, the WLA is assigned to members of other groups. If there is no capacity on the affinity group members, the WLA is assinged to members of other groups.

By default, all WLAs in a cluster configuration are members of a single ap affinity group. If you configure an ap affinity group on one WLC without configuring ap affinity groups on other members, then all WLAs move to the WLCs with the default ap affinity group configuration. The cluster seed interacts with the WLA Affinity Group in the following manner: The Seed receives a "Find WLC" message from a WLA. The seed assigns the WLA to a WLC in its affinity group provided there is enough capacity. If the WLA sending the message belongs to a subnet affinity group, and the assigned PAM in the WLC selection database does not belong to that group, the current assignments are maintained until the next load balancing algorithm runs and re-assigns the WLA as needed. The current selection is cleared if the WLA has an IP address different from the one in the existing selection record. It is desirable that WLA backup links are on a WLC outside of the affinity group to ensure WLA operation if there is a data center failure. For example, in a cluster configuration with two WLCs and 50 WLAs, all WLAs belong to a single default ap affinity group. If you configure an ap affinity group on WLC#1 and add 20 WLAs to it, the rest of the WLAs move to WLC#2 with the default ap affinity group configuration. This is the expected behavior unless you explicitly configure ap affinity groups on each WLC.



707

A cluster member becomes active and synchronizes with the seed. This initiates a series of WLA load balancing algorithms that moves any WLAs with affinity to the subnets configured for the WLC, but assigned to WLCs outside of the current affinity group to this WLC as long as there is available capacity. Affinity configuration is changed. When there are changes to the affinity configuration, load balancing is triggered which reassignes the WLAs based on the new affinity configuration. To configure AP Affinity, use the following commands: WLC# set mobility-domain ap-affinity-group address {ipaddress/masklength | ipaddress} netmask netmask To clear an AP affinity configuration, use the following command: WLC# clear mobility-domain ap-affinity-group {ipaddress/masklength | ipaddress} netmask netmask

Load Balancing in a Cluster Configuration The WLA selects the PAM based on the following information: If the WLA belongs to an Affinity group, PAM is selected from the affinity group members. If the WLA does not belong to an affinity group or there is no capacity left among the affinity group members, the PAM is selected from the default affinity group which contains WLCs not specifically assigned to an affinity group. If these conditions are not met, the PAM is selected from the members of other affinity groups. The WLA selects the SAM based on the following information: The SAM is selected from the default affinity group members. If that fails, the SAM is selected from members of other affinity groups. For example members that belong to other affinity groups except WLA affinity groups. If that fails, the SAM is selected from the members of the WLA affinity group.

Additional Information Only one cluster can be configured on a Mobility Domain. The maximum number of WLAs supported in a cluster is 2048. WLA-WLC load balancing automatically occurs on the Mobility Domain to ensure maximum failover capability. Cluster configuration is not supported on releases earlier than MSS 7.0. All WLCs configured as part of a cluster must have MSS 7.0 or higher as the operating software. Directly attached WLAs cannot be configured on any WLC in a cluster configuration. NAT is not supported for WLAs in a cluster configuration.

708




Be sure that you have not configured the maximum number of WLAs for each WLC. If you have already configured the maximum number of WLAs and you enable cluster mode, auto-WLAs do not behave correctly. Informational Note: It is recommended to backup the existing configuration on each WLC that is a member of the cluster configuration. If you disable cluster mode, you can return to the previous configuration without reconfiguring the WLC.

Configuring Smart Mobile Cluster Configuration on a Mobility Domain On the primary seed for the Mobility Domain, enter the following commands: WLC_PS# set cluster mode enable success:change accepted On the secondary seed for the Mobility Domain, enter the following command to provide cluster redundancy on the network: WLC SS# set cluster mode enable On each Mobility Domain member, enter the following command: WLC1# set cluster mode enable success:change accepted WLC2# set cluster mode enable success:change accepted WLC3# set cluster mode enable success:change accepted The command set cluster preempt enable can be configured on the secondary seed WLC, if you have configured one as part of the Mobility Domain, to override the primary seed configuration if the primary and secondary seed become disconnected. The command is executed on the secondary seed when the connection to the primary seed is lost and the configuration changes on the secondary seed. If enabled, the primary seed, after reconnecting, synchronizes with the secondary seed to update the configuration. If disabled, the configuration on the primary seed overrides the configuration on the secondary seed. This command is not persistent and you must set preempt again if the WLC resets.

Complete Virtual Controller Cluster Command Syntax set cluster mode {enable |disable [restore-backup-config]} preempt {enable | disable} The restore-backup-config command restores the previous configuration on the WLC before cluster mode was enabled. To save the cluster configuration in a backup file, use the following command: WLC# save config cluster success: change accepted



709

This command is only allowed on a Mobility Domain member when Virtual Controller Cluster is enabled. To save the local configuration as a local file, use the following command: WLC# save config local filename This command is only allowed on a Mobility Domain member when Virtual Controller Cluster is enabled. To save the configuration, use the following command: WLC# save config filename When Virtual Controller Cluster is enabled, this command is only allowed on the Mobility Domain seeds. To load a previous cluster configuration, use the following command: WLC# load config cluster This command is only allowed on a Mobility Domain member when Virtual Controller Cluster is disabled. To load a previous cluster configuration from a file, use the following command: WLC# load config local filename This command is only allowed on a Mobility Domain member when Virtual Controller Cluster is disabled. To load a cluster configuration stored on the WLC, use the following command: WLC# load config filename This command is only allowed on a Mobility Domain member when Virtual Controller Cluster is enabled. The following commands can only be executed on the active seed within the cluster configuration: WLC# set ap WLC# set service-profile WLC# set radio-profile WLC# set security acl map name ap aplist {in | out} WLC# set location policy WLC# set mobility-profile WLC# set vlan-profile WLC# set rfdetect WLC# set system countrycode WLC# set load-balancing WLC# set qos-profile WLC# set snoop

Other Virtual Controller Cluster Configuration Parameters The following configuration parameters are also shared as part of the cluster configuration: ACLs – are implemented as follows: ACLs that refer to an AP must be configured on the seed WLC. ACLs defined on a seed WLC are shared with members. ACL mapping to ports, VLANs, and vports can be defined on the member WLCs for locally defined ACLs. 710




If there are conflicting ACL names, the local ACL takes precedence and the incident is logged to the event log. Mobility profiles – have the following configuration constraints: Mobility profiles must be configured on the Primary seed. Mobility profiles that reference ports are not accepted by the configuration. Location policies – can be configured as follows: Must be configured on the seed WLC. Profiles with port references are not allowed. QoS profiles

Hitless Software Upgrade for Cluster Configurations You can perform an in-service software upgrade across the cluster configuration. A coordinated upgrade of all controllers and APs in the cluster allows minimal service interruption for your clients on the network. The upgrade procedure assumes both old and new MSS versions are 7.1 or later. This feature is not supported in earlier releases of MSS. To upgrade the cluster, follow these instructions: 1. Install the software image on all WLCs in the cluster and set the boot partition appropriately. 2. Use the CLI on the Primary seed to enter the upgrade command. WLC# upgrade cluster [force]

Dot1X Settings in a Cluster Configuration All AAA-related configurations to be performed centrally at the cluster seed. You can configure options such as RADIUS servers and authentication rules at one location and apply it to the entire network. The Dot1X setting in a cluster configuration adds the type attribute, AAA-METHOD-REF to allow you to distinguish between RADIUS and LDAP methods.

CLI Enhancements for Network Resiliency A cluster configuration requires CLI commands that allow you to configure and monitor a cluster configuration. AP status commands are now available at the global level. MSS 7.1 allows you to view AP status information for all APs configured in the cluster. The following commands are an example of data that is now available for cluster: WLC# show ap status options cluster [member-ipaddr] Table 1 lists the CLI commands cluster options: Table 1.

Cluster Option CLI Commands

Command

Description

apnum

Shows status of AP list

all

Shows status of all APs (including down ones)

boot-state

Literal value



711

Table 1.

Cluster Option CLI Commands

Command

Description

ip

Literal value

mac

Literal value

model

Literal value

names

Shows AP status with AP names

verbose

Show all details for AP status

WLA Network Resiliency Roaming Enhancements When the network is configured for the network resiliency feature, WLAs boot up on the network and then send the WLC request that is sent to the seed. The seed selects a Primary Access Manager (PAM) and a Secondary Access Manager (SAM) for a booting WLA. Over a period of time, the WLA can move to different WLCs on the network for various reasons, including the following: Connectivity - losing contact with the PAM or SAM, and if the WLA loses both, the WLA reboots. Configuration - changing the Mobility Domain affinity attribute can trigger the WLA to move to a preferred controller. Changing the data path encryption (DPE) attribute can also trigger the WLA to move to another controller. Load balancing - when member WLCs are removed or added to the network, the seed may move WLAs to other active member WLCs. The seed keeps track of all WLAs active on the MoDo. The data includes the PAM, SAM, WLA IP address, and other information that is shared with the secondary seed. The verbose option is now available as part of the existing command show cluster ap. This command is only available on the active seed. Only the last four WLA moves are displayed in the output. WLC# show cluster ap 5 verbose AP MAC Address IP Address PAM MX IP SAM MX IP Co P S ----------------------------------------------------------------------------------5 00:0b:0e:94:9e:80 10.8.255.17 10.7.115.171 10.7.116.166 Y Y Record Creation: Tue Aug 28 08:00:00 2012 PDT Total Duration: 3 day+ -9:53:30

Last 4 AP Moves: Move Reason: I = Initial Assignment; P = Lost PAM, LB = Load Balance C = Configuration relocation PAM 10.7.116.171 10.7.116.166 10.7.116.165 10.7.116.166

Assignment Time 08/31/11 17:40:59 08/31/11 17:32:31 08/31/11 17:01:10 08/31/11 12:00:00

Duration 00:12:31 00:08:28 00:31:21 05:01:00

Reason P LB LB LB

Cumulative Moves Load Balance Lost PAM Configuration -------------------------------------------------------------------8 6 (75%) 9 (60%) 0 (0%)

712




Configuring WLC-WLC Security You can enhance security on your network by enabling WLC-WLC security. WLC-WLC security encrypts management traffic exchanged by WLC switches in a Mobility Domain. When WLC-WLC security is enabled, management traffic among WLC switches in the Mobility Domain is encrypted using AES. The keying material is dynamically generated for each session and passed among switches using configured public keys. MSS supports 2048-bit keys in addition to 128-bit keys. Use the following steps to configure WLC-WLC security: 1. Set Mobility Domain security on each WLC to required. The default setting is none. WLC-WLC security can be disabled or enabled on a Mobility Domain basis. The feature must have the same setting (required or none) on all switches in the Mobility Domain. Use the following command on the seed and on each member to enable WLC-WLC security: set domain security required This command also creates a certificate. 2. On the seed and on each member, generate a private key. Use the following command: crypto generate key domain 128 3. On the Mobility Domain seed, display the generated key by using the following command: show crypto key domain Copy the key in order to use it on other mobility domain members. 4. On the Mobility Domain seed, specify the public key for each member. Use the following command: set mobility-domain member ip-addr key hex-bytes Specifies the key as 16 hexadecimal bytes, separated by colons. Here is an example: 91:3e:ef:48:76:ff:fc:8b:52:ef:58:04:1e:51:1e:25 5. On each member WLC, specify the seed IP address and the public key. Use the following command: set mobility-domain mode member seed-ip ip-addr key hex-bytes This command does not need to be entered on the seed WLC.

Monitoring the VLANs and Tunnels in a Mobility Domain Tunnels connect WLC switches across a network. Tunnels are formed automatically in a Mobility Domain to extend a VLAN to the WLC with an associated roaming station. A single tunnel can carry traffic for many users and many VLANs. The tunnel port can carry traffic for multiple VLANs by means of multiple virtual ports. MSS automatically adds virtual ports to VLANs as needed to preserve the associations of users to the correct subnet or broadcast domain as they roam across the Mobility Domain. Although tunnels are formed by IP between WLC switches, the tunnels can carry user traffic of any protocol type. MSS provides the following commands to display the roaming and tunneling of users within Mobility Domain groups:


Monitoring the VLANs and Tunnels in a Mobility Domain

713

show roaming station (See Displaying Roaming Stations.) show roaming vlan (See “Displaying Roaming VLANs and Affinities” on page 1–714.) show tunnel (See “Displaying Tunnel Information” on page 1–715.)

Displaying Roaming Stations The command show roaming station displays a list of the stations roaming to the WLC through a VLAN tunnel. To display roaming stations (clients), type the following command: WLC# show roaming station User Name

Station Address

VLAN

State

---------------------- ----------------- --------------- ----example\geetha

192.168.15.104

vlan-am

Up

[email protected]

192.168.15.1990

vlan-am

Up

example\tamara

192.168.11.200

vlan-ds

Up

example\jose

192.168.14.200

vlan-et

Up

[email protected]

192.168.15.194

vlan-am

Up

Informational Note: For more information about this command and the fields in the output, see the Juniper Mobility System Software Command Reference.

Displaying Roaming VLANs and Affinities The command show roaming vlan displays all VLANs in the Mobility Domain, the WLC switches configured for the VLANs, and the tunnel affinity values configured on each WLC. The member WLC that offers the requested VLAN reports the affinity number. If multiple WLC switches have native attachments to the VLAN, the advertised affinity values attract tunneled traffic to a particular WLC for that VLAN. A higher value represents a preferred connection to the VLAN. (For more information, see the Mobility System Software Basic Configuration Guide Version 6.2.) To display roaming VLANs, type the following command: WLC# show roaming vlan VLAN

SwitchIP Address

---------------- ---------------

Affinity

Load

--------

------

vlan-eng

192.168.12.7

5

0

vlan-fin

192.168.15.5

5

0

vlan-pm

192.168.15.5

5

0

vlan-wep

192.168.12.7

5

0

vlan-wep

192.168.15.5

5

0


714




Displaying Tunnel Information The command show tunnel displays the tunnels hosted on the WLC and distributes to a locally attached VLAN. To display tunnel information, type the following command: WLC# show tunnel VLAN

Local Address

Remote Address

State

Port

LVID

---------------- --------------- --------------- ------- ----- ----

RVID ---

vlan-eng

192.168.12.7

192.168.15.5

UP

1024

130

4103

vlan-eng

192.168.12.7

192.168.14.6

DORMANT

1026

130

4097

vlan-pm

192.168.12.7

192.168.15.5

UP

1024

4096

160

Informational Note: For more information about this command and the fields in the output, see the Juniper Networks Mobility System Software Command Reference.

Understanding the Sessions of Roaming Users When a wireless client successfully roams from one WLA to another, the sessions are affected in the following ways: The WLC treats this client session as a roaming session and not a new session. RADIUS accounting is handled as a continuation of an existing session. The session with the roamed-from WLA is cleared from the WLC, even if the client does not explicitly disassociate from the and the IEEE 802.1X reauthentication period has not expired. Informational Note: For more information about this command and the fields in the output, see the Juniper NetworksMobility System Software Command Reference.

Roaming requires certain conditions and can be affected by some of the WLC timers. You can monitor a wireless client roaming sessions with the show sessions network verbose command.


Understanding the Sessions of Roaming Users

715

Requirements for Roaming to Succeed For roaming to take place, the roaming client must associate or reassociate with another WLA in the Mobility Domain after leaving an existing session on an WLA in the Mobility Domain in one of the following states: Table 2.

Mobility Domain States

ACTIVE

The normal state for a client leaving radio range without sending a request to disassociate.

DEASSOCIATED

The state of a client sending an 802.11 disassociate message, but has not roamed or aged out yet.

In addition, the following conditions must exist for roaming to succeed: Mobility Domain communications must be stable. Generally, the communications required for roaming are the same as those required for VLAN tunneling. A client can also roam among ports on an WLC when a Mobility Domain is inaccessible or not configured. Client authentication and authorization on the roamed-to must be successful on the first attempt. . Informational Note: For more information about this command and the fields in the output, see the Juniper NetworksMobility System Software Command Reference.

If authentication or authorization fails, MSS clears the client session. If the failure occurs, roaming can be disqualified or delayed. The client must use the same authorization parameters for the roamed-to as for the roamed-from WLA. . Informational Note: For more information about this command and the fields in the output, see the Juniper NetworksMobility System Software Command Reference.

If the client changes the encryption type or VLAN name, MSS might record a new session rather than a roamed session.

Effects of Timers on Roaming An unsuccessful roaming attempt might be caused by the following timers. You cannot configure either timer. Grace period. A disassociated session has a grace period of 5 seconds during which MSS can retrieve and forward the session history. After 5 seconds, MSS clears the session, and the accounting is stopped. MAC address search. If MSS cannot find the client MAC address in a Mobility Domain within 5 seconds, the session is treated as a new session rather than a roaming session.

716




In contrast, the 802.1X reauthentication timeout period has little effect on roaming. If the timeout expires, MSS performs 802.1X processing on the existing association. Accounting and roaming history are unaffected when reauthentication is successful, because the client is still associated with the same WLA. If reauthentication fails, MSS clears the session so it is not eligible for roaming. If the client associates with the same WLA, the session is recorded as a new session. (To change the reauthentication timeout, see “Enabling and Disabling 802.1X Reauthentication” on page 427.)

Monitoring Roaming Sessions To monitor the state of roaming clients, use the show sessions network verbose command. For example, the following command displays information about the sessions of a wireless client who roamed between ports on an WLC. The output shows that the client SHUTTLE\2\exmpl roamed from the WLA connected to port 3 to the WLA connected to port 6 on the same WLC, and then roamed back to the WLA connected to port 3. WLC> show sessions network verbose User Sess Name ID ------------------------------ ----

IP or MAC VLAN Address Name ---------------- ------------

SHUTTLE2\exmpl

6*

10.3.8.55

Client MAC: 00:06:25:13:08:33

GID: SESS-4-000404-98441-c807c14b

State: ACTIVE

default

Port/ Radio ---3/1

(prev AUTHORIZED)

now on: WLC 10.3.8.103, AP/radio

3/1, AP 00:0b:0e:ff:00:3a, as of

00:00:24 ago from: WLC 10.3.8.103, AP/radio

6/1, AP 00:0b:0e:00:05:d7, as of


3/1, AP 00:0b:0e:ff:00:3a, as of

00:01:53 ago 1 sessions total Informational Note: For more information about this command and the fields in the output, see the Juniper NetworksMobility System Software Command Reference.

Displaying NAT Information Remote sites may want to have WLCs on site to support multiple WLAs on a remote network. Frequently, the remote site is located behind a firewall device that supports Network Address Translation (NAT). NAT is supported on WLCs located remotely behind a firewall device. There is no configuration necessary; the WLC automatically detects NAT on the network. To see if NAT was detected, use the following command: WLC# show mobility-domain



717

Mobility Domain Scenario The following scenario illustrates how to create a Mobility Domain named sunflower consisting of three members from a seed WLC at 192.168.253.21: 1. Set the current WLC as the Mobility Domain seed. Type the following command: WLC# set mobility-domain mode seed domain-name sunflower success: change accepted. 2. On the seed, add the members of the Mobility Domain. Type the following commands: WLC# set mobility-domain member 192.168.253.11 success: change accepted. WLC# set mobility-domain member 192.168.111.112 success: change accepted. 3. For each member WLC, configure the IP address to reach the seed WLC. Type the following commands: WLC# set mobility-domain member seed-ip 192.168.253.21 4. Display the Mobility Domain status. Type the following command: WLC# show mobility-domain Mobility Domain name:

*sunflower*

Flags: u = up[1], d/e = down/config error[1], c = cluster enabled[0], p = primary seed, s = secondary seed (S = cluster preempt mode enabled), a = mobility domain active seed, A = cluster active seed (if different), m = member, y = syncing, w = waiting to sync, n = sync completed, f = sync failed Member

Flags

Model

Version

NoAPs

APLic

---------------

-----

--------

----------

-----

-----

10.8.112.211

upa--

Unknown

Unknown

0

0

10.7.112.110

um---

WLC20

7.1.1.3 0

40

5. To display statistics for the Mobility Domain, type the following command: WLC# show mobility-domain statistics Mobility Domain name:sunflower Flags: u = up[1], d/e = down/config error[1], c = cluster enabled [0], p = primary seed, s = secondary seed, (S = cluster preempt mode enabled), a = mobility domain active seed, A= cluster active seed (if different), m = member, y = syncing, w = waiting to sync, n = sync completed, f = sync failed, Member

718

Mobility Domain Scenario

Flag

Uptime

Avg latency(ms

Tot MoDo flaps(KA)



--------------------------------------------------------------------------192.168.253.11

ipacn

12d04h

105

12(8)

192.168.111.111 us-cn

12d04h

170

4(3)

192.168.253.21

13m08s

95

4(3)

um-cn

The Tot MoDo flaps field displays the total flaps due to keepalive misses in parentheses. You can use the command, clear mobility-domain statistics, to clear the current counters. 6. To display the Mobility Domain configuration, type the following command: WLC# show mobility-domain config This WLC is the seed for domain sunflower. 192.168.253.11 is a member 192.168.111.112 is a member 7. To display the WLC switches that are hosting VLANs for roaming, type the following command: WLC# show roaming vlan VLAN

Switch IP Address

---------------- ---------------

Affinity --------

vlan-eng

192.168.12.7

5

vlan-fin

192.168.15.5

5

vlan-pm

192.168.15.5

5

vlan-wep

192.168.12.7

5

vlan-wep

192.168.15.5

5

8. To display active roaming tunnels, type the following command: WLC# show tunnel VLAN

Local Address

Remote Address

State

Port

LVID

RVID

-------------- --------------- --------------- ------- ----- ----- ----vlan-eng

192.168.12.7

192.168.15.5

UP

1025

130

4096

vlan-eng

192.168.12.7

192.168.14.6

UP

1024

130

4096



719

720



Configuring WLC-WLC Security

Configuring WLC-WLC Security You can enhance security on your network by enabling WLC-WLC security. WLC-WLC security encrypts management traffic exchanged by WLC switches in a Mobility Domain. When WLC-WLC security is enabled, management traffic among WLC switches in the Mobility Domain is encrypted using AES. The keying material is dynamically generated for each session and passed among switches using configured public keys. MSS supports 2048-bit keys in addition to 128-bit keys. Use the following steps to configure WLC-WLC security: 1. Set Mobility Domain security on each WLC to required. The default setting is none. WLC-WLC security can be disabled or enabled on a Mobility Domain basis. The feature must have the same setting (required or none) on all switches in the Mobility Domain. Use the following command on the seed and on each member to enable WLC-WLC security: set domain security required This command also creates a certificate. 2. On the seed and on each member, generate a private key. Use the following command: crypto generate key domain 128 3. On the Mobility Domain seed, display the generated key by using the following command: show crypto key domain Copy the key in order to use it on other mobility domain members. 4. On the Mobility Domain seed, specify the public key for each member. Use the following command: set mobility-domain member ip-addr key hex-bytes Specifies the key as 16 hexadecimal bytes, separated by colons. Here is an example: 91:3e:ef:48:76:ff:fc:8b:52:ef:58:04:1e:51:1e:25 5. On each member WLC, specify the seed IP address and the public key. Use the following command: set mobility-domain mode member seed-ip ip-addr key hex-bytes This command does not need to be entered on the seed WLC.

Monitoring the VLANs and Tunnels in a Mobility Domain Tunnels connect WLC switches across a network. Tunnels are formed automatically in a Mobility Domain to extend a VLAN to the WLC with an associated roaming station. A single tunnel can carry traffic for many users and many VLANs. The tunnel port can carry traffic for multiple VLANs by means of multiple virtual ports. MSS automatically adds virtual ports to VLANs as needed to preserve the associations of users to the correct subnet or broadcast domain as they roam across the Mobility Domain. Although tunnels are formed by IP between WLC switches, the tunnels can carry user traffic of any protocol type.



721

MSS provides the following commands to display the roaming and tunneling of users within Mobility Domain groups: show roaming station (See Displaying Roaming Stations.) show roaming vlan (See “Displaying Roaming VLANs and Affinities” on page 1–722.) show tunnel (See “Displaying Tunnel Information” on page 1–723.)


Station Address

VLAN

State

---------------------- ----------------- --------------- ----example\geetha

192.168.15.104

vlan-am

Up

[email protected]

192.168.15.1990

vlan-am

Up

example\tamara

192.168.11.200

vlan-ds

Up

example\jose

192.168.14.200

vlan-et

Up

[email protected]

192.168.15.194

vlan-am

Up


Displaying Roaming VLANs and Affinities The command show roaming vlan displays all VLANs in the Mobility Domain, the WLC switches configured for the VLANs, and the tunnel affinity values configured on each WLC. The member WLC that offers the requested VLAN reports the affinity number. If multiple WLC switches have native attachments to the VLAN, the advertised affinity values attract tunneled traffic to a particular WLC for that VLAN. A higher value represents a preferred connection to the VLAN. (For more information, see the Mobility System Software Basic Configuration Guide Version 6.2.) To display roaming VLANs, type the following command: WLC# show roaming vlan VLAN

SwitchIP Address

---------------- ---------------

722

Affinity

Load

--------

------

vlan-eng

192.168.12.7

5

0

vlan-fin

192.168.15.5

5

0

vlan-pm

192.168.15.5

5

0

vlan-wep

192.168.12.7

5

0




vlan-wep

192.168.15.5

5

0



Local Address

Remote Address

State

Port

LVID

---------------- --------------- --------------- ------- ----- ----

RVID ---

vlan-eng

192.168.12.7

192.168.15.5

UP

1024

130

4103

vlan-eng

192.168.12.7

192.168.14.6

DORMANT

1026

130

4097

vlan-pm

192.168.12.7

192.168.15.5

UP

1024

4096

160






723



ACTIVE


DEASSOCIATED






724







SHUTTLE2\exmpl

6*

10.3.8.55

Client MAC: 00:06:25:13:08:33

GID: SESS-4-000404-98441-c807c14b

State: ACTIVE

default

Port/ Radio ---3/1

(prev AUTHORIZED)


3/1, AP 00:0b:0e:ff:00:3a, as of


6/1, AP 00:0b:0e:00:05:d7, as of


3/1, AP 00:0b:0e:ff:00:3a, as of





725


*sunflower*


Flags

Model

Version

NoAPs

APLic

---------------

-----

--------

----------

-----

-----

10.8.112.211

upa--

Unknown

Unknown

0

0

10.7.112.110

um---

WLC20

7.1.1.3 0

40


726


Flag

Uptime

Avg latency(ms

Tot MoDo flaps(KA)



--------------------------------------------------------------------------192.168.253.11

ipacn

12d04h

105

12(8)

192.168.111.111 us-cn

12d04h

170

4(3)

192.168.253.21

13m08s

95

4(3)

um-cn


Switch IP Address

---------------- ---------------

Affinity --------

vlan-eng

192.168.12.7

5

vlan-fin

192.168.15.5

5

vlan-pm

192.168.15.5

5

vlan-wep

192.168.12.7

5

vlan-wep

192.168.15.5

5


Local Address

Remote Address

State

Port

LVID

RVID

-------------- --------------- --------------- ------- ----- ----- ----vlan-eng

192.168.12.7

192.168.15.5

UP

1025

130

4096

vlan-eng

192.168.12.7

192.168.14.6

UP

1024

130

4096



727

728




Monitoring the VLANs and Tunnels in a Mobility Domain Tunnels connect WLC switches across a network. Tunnels are formed automatically in a Mobility Domain to extend a VLAN to the WLC with an associated roaming station. A single tunnel can carry traffic for many users and many VLANs. The tunnel port can carry traffic for multiple VLANs by means of multiple virtual ports. MSS automatically adds virtual ports to VLANs as needed to preserve the associations of users to the correct subnet or broadcast domain as they roam across the Mobility Domain. Although tunnels are formed by IP between WLC switches, the tunnels can carry user traffic of any protocol type. MSS provides the following commands to display the roaming and tunneling of users within Mobility Domain groups: show roaming station (See Displaying Roaming Stations.) show roaming vlan (See “Displaying Roaming VLANs and Affinities” on page 1–729.) show tunnel (See “Displaying Tunnel Information” on page 1–730.)


Station Address

VLAN

State

---------------------- ----------------- --------------- ----example\geetha

192.168.15.104

vlan-am

Up

[email protected]

192.168.15.1990

vlan-am

Up

example\tamara

192.168.11.200

vlan-ds

Up

example\jose

192.168.14.200

vlan-et

Up

[email protected]

192.168.15.194

vlan-am

Up


Displaying Roaming VLANs and Affinities The command show roaming vlan displays all VLANs in the Mobility Domain, the WLC switches configured for the VLANs, and the tunnel affinity values configured on each WLC. The member WLC that offers the requested VLAN reports the affinity number. If multiple WLC switches have native attachments to the VLAN, the advertised affinity values attract tunneled traffic to a particular WLC for that VLAN. A higher value represents a preferred connection to the VLAN. (For more information, see the Mobility System Software Basic Configuration Guide Version 6.2.) To display roaming VLANs, type the following command: Copyright © 2013, Juniper Networks, Inc.

729

WLC# show roaming vlan VLAN

SwitchIP Address

---------------- ---------------

Affinity

Load

--------

------

vlan-eng

192.168.12.7

5

0

vlan-fin

192.168.15.5

5

0

vlan-pm

192.168.15.5

5

0

vlan-wep

192.168.12.7

5

0

vlan-wep

192.168.15.5

5

0



Local Address

Remote Address

State

Port

LVID

---------------- --------------- --------------- ------- ----- ----

RVID ---

vlan-eng

192.168.12.7

192.168.15.5

UP

1024

130

4103

vlan-eng

192.168.12.7

192.168.14.6

DORMANT

1026

130

4097

vlan-pm

192.168.12.7

192.168.15.5

UP

1024

4096

160



730







731



ACTIVE


DEASSOCIATED






732







SHUTTLE2\exmpl

6*

10.3.8.55

Client MAC: 00:06:25:13:08:33

GID: SESS-4-000404-98441-c807c14b

State: ACTIVE

default

Port/ Radio ---3/1

(prev AUTHORIZED)


3/1, AP 00:0b:0e:ff:00:3a, as of


6/1, AP 00:0b:0e:00:05:d7, as of


3/1, AP 00:0b:0e:ff:00:3a, as of





733


*sunflower*


Flags

Model

Version

NoAPs

APLic

---------------

-----

--------

----------

-----

-----

10.8.112.211

upa--

Unknown

Unknown

0

0

10.7.112.110

um---

WLC20

7.1.1.3 0

40


734


Flag

Uptime

Avg latency(ms

Tot MoDo flaps(KA)



--------------------------------------------------------------------------192.168.253.11

ipacn

12d04h

105

12(8)

192.168.111.111 us-cn

12d04h

170

4(3)

192.168.253.21

13m08s

95

4(3)

um-cn


Switch IP Address

---------------- ---------------

Affinity --------

vlan-eng

192.168.12.7

5

vlan-fin

192.168.15.5

5

vlan-pm

192.168.15.5

5

vlan-wep

192.168.12.7

5

vlan-wep

192.168.15.5

5


Local Address

Remote Address

State

Port

LVID

RVID

-------------- --------------- --------------- ------- ----- ----- ----vlan-eng

192.168.12.7

192.168.15.5

UP

1025

130

4096

vlan-eng

192.168.12.7

192.168.14.6

UP

1024

130

4096



735

736



About Network Domains

About Network Domains About the Network Domain Feature A Network Domain allows functionality found in Mobility Domains to be extended over a multiple-site installation. A user configured to be on a VLAN at the home site can travel to a remote site, connect to the network, and placed in the native VLAN. To do this, the accessed WLC forms a tunnel to an WLC at the home site of a user. Figure 1–1 illustrates a sample Network Domain configuration consisting of Mobility Domains at six sites connected over a WAN link. Figure 1–1. Network Domain

In a Network Domain, one or more WLC switches acts as a seed device. A Network Domain seed stores information about all of the VLANs on the Network Domain members. The Network Domain seeds share this information to create an identical database on each seed. In the example above, one WLC at each site is a Network Domain seed. Each Network Domain member maintains a TCP connection to one of the seeds. When a Network Domain member needs information about a VLAN in a remote Mobility Domain, the member consults the a connected Network Domain seed. If the seed has information about the remote VLAN, it responds with the IP address of an WLC with the VLAN. A VLAN tunnel is then created between the WLC and the remote WLC.


About the Network Domain Feature

737

Figure 1–2 illustrates how user Bob, based at Sales Office C connects and is placed in a VLAN when he visits the Corporate Office. Figure 1–2. Connecting to a Remote VLAN in a Network Domain

In this example, Bob establishes connectivity as follows: 1. Bob connects to the wireless network at the Corporate Office. The WLC contacts the local Mobility Domain seed and finds that the VLAN configured for Bob, VLAN Red, does not exist in the Corporate Office Mobility Domain. 2. Unable to find VLAN Red in the local Mobility Domain, the WLC then contacts the local Network Domain seed. The Network Domain seed contains a database of all the VLANs configured on all the members of the Network Domain. 3. The Network Domain seed checks the local database and finds that VLAN Red exists in the Mobility Domain at Sales Office C. The Network Domain seed then responds with the IP address of the remote WLC configured with VLAN Red. 4. A VLAN tunnel is created between the WLC at the Corporate Office and the WLC at Sales Office C. 5. Bob establishes connectivity on the network at the corporate office and is placed in VLAN Red.

738



About Network Domains

Network Domain Seed Affinity When there are multiple Network Domain seeds in an installation, a Network Domain member connects to the seed with the highest configured affinity. If that seed is unavailable, the Network Domain member connects to the seed with the next-highest affinity. Figure 1–3 illustrates how an WLC connects to a Network Domain seed based on the configured affinity for the seed. Figure 1–3. Configuring an WLC affinity for a Network Domain seed

In the example above, an WLC in the Mobility Domain at the corporate office is configured as a member of a Network Domain with a local seed, as well as seeds at the two branch offices and the three sales offices. The WLC has an affinity value of 10 (highest) for the local seed, and an affinity value of 7 for the seed at Branch Office 1. The WLC has an affinity of 5 (the default) for the other seeds in the Network Domain. In the event that the local Network Domain seed becomes unavailable, the WLC then attempts to connect to the seed at Branch Office 1, the next-highest-affinity seed. Once connected to this seed, the WLC then periodically attempts to connect to the local seed. When the WLC is able to connect to the local seed again, the connection to the Branch Office seed is dropped. When you configure an WLC to be a member of a Network Domain, you specify the connecting seed(s). As part of this configuration, you can also specify the seed affinity for the WLC.



739

740



Configuring a Network Domain

Configuring a Network Domain Network Domain Tasks To configure a Network Domain: 1. Designate one or more Network Domain seed WLC switches. (See Configuring Network Domain Seeds on page 741.) 2. Specify seed members in the Network Domain. (See “Specifying Network Domain Seed Peer Relationships” on page 742.) 3. Configure WLC switches to be part of the Network Domain. (See “Configuring Network Domain Members” on page 742.) You can view the status of a Network Domain, clear members, and clear all Network Domain configuration from an WLC.

Configuring Network Domain Seeds In a Network Domain, a member WLC consults a seed WLC to determine a user VLAN membership in a remote Mobility Domain. Use the following command to set the current WLC as a seed device within a specified Network Domain: set network-domain mode seed domain-name net-domain-name For example, the following command sets the current WLC as a seed with the Network Domain California: WLC# set network-domain mode seed domain-name California success: change accepted. If the seed in a Network Domain is also intended to be a member of the Network Domain, you must enter the following command on the seed, with the specified IP address of the seed. set network-domain mode member seed-ip ip-addr [affinity num] For example, the following command sets the current WLC as a member of a Network Domain and the WLC with IP address 192.168.9.254 as the seed: WLC# set network-domain mode member seed-ip 192.168.9.254 success: change accepted. You can configure multiple seeds in a Network Domain. When multiple Network Domain seeds are configured, a member consults the seed with the highest configured affinity. If you are configuring multiple seeds in the same Network Domain (for example, a seed on each physical site in the Network Domain), you must establish a peer relationship among the seeds.


Network Domain Tasks

741

Specifying Network Domain Seed Peer Relationships When multiple WLC switches are configured as seed devices in a Network Domain, they establish a peer relationship to share information about the VLANs configured on the member devices to create identical VLAN databases. Sharing information in this way provides redundancy in case one of the seed peers becomes unavailable. Use the following command on a Network Domain seed to specify another seed as a peer: set network-domain peer ip-addr You enter this command on all of the seed devices in the Network Domain, specifying each seed to every other seed, so that all of the Network Domain seeds are aware of each other. For example, the following command sets the current WLC as a peer of the Network Domain seed with IP address 192.168.9.254: WLC# set network-domain peer 192.168.9.254 success: change accepted. This command is valid on Network Domain seeds only.

Configuring Network Domain Members In a Network Domain, at least one seed device must be aware of each member device. The seed maintains an active TCP connection with the member. To configure an WLC as a member of a Network Domain, you specify one or more Network Domain seeds. Use the following command to set the current WLC as a member of a Network Domain where a specified WLC is a seed: set network-domain mode member seed-ip ip-addr [affinity num] You can enter this command multiple times on an WLC, specifying different Network Domain seeds with different affinity values. The affinity value can range from 1 – 10, with 10 being the highest affinity. The default affinity value is 5. Informational Note: If the Network Domain seed is also intended to be a member of the Network Domain, you must also enter this command on the Network Domain seed.

For example, the following command sets the current WLC as a member of a Network Domain where the WLC with IP address 192.168.9.254 is a seed: WLC# set network-domain mode member seed-ip 192.168.9.254 success: change accepted. To specify 10.8.107.1 as an additional Network Domain seed for the WLC to connect to if the 192.168.9.254 seed is unavailable, enter the following command: WLC# set network-domain mode member seed-ip 10.8.107.1 affinity 2 success: change accepted.

742



Configuring a Network Domain

Displaying Network Domain Information To view the status of Network Domains configured on the WLC, use the show network-domain command. The output of the command differs if the WLC is a member of a Network Domain or a Network Domain seed. For example, an WLC that is a Network Domain member only, output such as the following is displayed: WLC# show network-domain Member Network Domain name: California Member

State

Mode

Mobility-Domain

---------------

-------------

------

---------------

10.8.107.1

UP

SEED

default

On an WLC that is a Network Domain seed, information is displayed about the Network Domain seeds with a peer relationship to an WLC, as well as the Network Domains with the WLC as a member. For example: WLC# show network-domain Network Domain name: California Peer

State

---------------

-------------

10.8.107.1

UP

Member

State

Mode

Mobility-Domain

---------------

-------------

------

---------------

10.1.0.0

DOWN

SEED

Member Network Domain name: Member

State

Mode

Mobility-Domain

---------------

-------------

------

---------------

10.8.107.1

UP

MEMBER

default

10.1.0.0

DOWN

SEED

(For more information about this command and the fields in the output, see the Juniper Mobility System Software Command Reference.)

Clearing Network Domain Configuration from an WLC You can clear all Network Domain configuration from an WLC. You may want to do this in order to change an WLC from one Network Domain to another, or to remove an WLC entirely from a Network Domain. To clear the Network Domain configuration from the WLC, type the following command: clear network-domain This command has no effect if the WLC is not configured as part of a Network Domain.

Clearing a Network Domain Seed from an WLC You can remove individual Network Domain seeds from an WLC configuration. To remove a specific Network Domain seed, type the following command: Copyright © 2013, Juniper Networks, Inc.


743

clear network-domain seed-ip ip-addr When you enter this command, the Network Domain TCP connections between the WLC and the specified Network Domain seed are closed.

Clearing a Network Domain Peer from a Network Domain Seed On an WLC configured as a Network Domain seed, you can clear the configuration of individual Network Domain peers. To remove a specific Network Domain peer from a Network Domain seed, type the following command: clear network-domain peer ip-addr This command has no effect if the WLC is not configured as a Network Domain seed.

Clearing Network Domain Seed or Member Configuration from an WLC Switch You can remove the Network Domain seed or member configuration from the WLC. To do this, enter the following command: clear network-domain mode {seed | member} Use the seed parameter to clear Network Domain seed configuration from the WLC. Use the member parameter to clear Network Domain member configuration from the WLC.

744



Network Domain Configuration Example


Overview Network Domain Scenario The following scenario illustrates how to create a Network Domain named globaldom consisting of three Mobility Domains at two geographically separated sites. Figure 1–4 below illustrates this scenario. Figure 1–4. Network Domain Scenario

In this scenario, there are three Mobility Domains: A, B, and C. Mobility Domain A is located at Site 1, and Mobility Domains B and C are located at Site 2. There are two Network Domain seeds, one at each site, that share information about the VLANs in the three Mobility Domains. The Network Domain seed at Site 1 is also the seed for Mobility Domain A. The Network Domain seed at Site 2 is used by both Mobility Domains B and C. At least one Network Domain seed is aware of each WLC in the installation and maintains an active TCP connection with it. The following is the Network Domain configuration for this scenario: 1. Set the WLC with IP address 10.10.10.1 as a seed of a Network Domain called globaldom and establish a peer relationship with the WLC with IP address 20.20.20.1. Type the following commands: Copyright © 2013, Juniper Networks, Inc.

Overview

745

WLC# set network-domain mode seed domain-name globaldom success: change accepted. WLC# set network-domain peer 20.20.20.1 success: change accepted. 2. Set the WLC with IP address 20.20.20.1 as a seed of a Network Domain called globaldom and establish a peer relationship with the WLC with IP address 10.10.10.1. Type the following commands: WLC# set network-domain mode seed domain-name globaldom success: change accepted. WLC# set network-domain peer 10.10.10.1 success: change accepted. 3. Set the three WLC switches in Mobility Domain A as members of the Network Domain, specifying WLC 10.10.10.1 as the Network Domain seed. Type the following command on all three WLC switches: WLC# set mobility-domain mode member seed-ip 10.10.10.1 success: change accepted. 4. Set the WLC switches in Mobility Domains B and C members of the Network Domain, specifying WLC 20.20.20.1 as the Network Domain seed. Type the following command on all of the WLC switches in both Mobility Domains: WLC# set mobility-domain mode member seed-ip 20.20.20.1 success: change accepted. 5. Display the Network Domain status. Type the following command on the WLC with IP address 10.10.10.1: WLC# show network-domain Network Domain name: globaldom

746

Peer

State

---------------

-------------

20.20.20.1

UP

Member

State

Mode

Mobility-Domain

---------------

-------------

------

---------------

10.10.10.1

UP

SEED

Modo A

10.10.10.2

UP

MEMBER

Modo A

10.10.10.3

UP

MEMBER

Modo A

20.20.20.1

UP

SEED

Modo B

20.20.20.2

UP

MEMBER

Modo B

20.20.20.3

UP

MEMBER

Modo B

30.30.30.1

UP

MEMBER

Modo C

30.30.30.2

UP

MEMBER

Modo C

Overview



Member Network Domain name: globaldom Member

State

Mode

Mobility-Domain

---------------

-------------

------

---------------

10.10.10.1

UP

SEED

Modo A

10.10.10.2

UP

MEMBER

Modo A

10.10.10.3

UP

MEMBER

Modo A

20.20.20.1

UP

SEED

Modo B

20.20.20.2

UP

MEMBER

Modo B

20.20.20.3

UP

MEMBER

Modo B

30.30.30.1

UP

MEMBER

Modo C

30.30.30.2

UP

MEMBER

Modo C


Overview

747

748

Overview


Part 5 - Configuring Network Protocols on the Wireless Network


789

790


Configuring and Managing Spanning Tree Protocol

Configuring and Managing Spanning Tree Protocol Spanning Tree Protocol (STP) is a link management protocol that provides path redundancy while preventing undesirable loops in the network. A loop-free path is accomplished when a device recognizes a loop in the topology and blocks one or more redundant paths. Mobility System Software (MSS) supports 802.1D and Per-VLAN Spanning Tree protocol (PVST+). MSS uses 802.1D bridge protocol data units (BPDUs) on untagged VLAN ports. However, each VLAN still runs an instance of STP, even if two or more VLANs contain untagged ports. To run a single instance of STP in 802.1D mode on the entire WLC, configure all network ports as untagged members of the same VLAN. MSS does not support running 802.1D on multiple tagged VLANs. MSS uses PVST+ BPDUs on VLAN ports that are tagged. PVST+ BPDUs include tag information in the 802.1Q field of the BPDUs. MSS runs a separate instance of PVST+ on each tagged VLAN. Informational Note: STP does not run on WLA access ports or wired authentication ports and does not affect traffic flow on these port types.

Informational Note: When you create a VLAN, STP is disabled on the new VLAN by default, regardless of the STP state of other VLANs on the device. Informational Note: The IEEE 802.1D spanning tree specifications refer to networking devices that forward Layer 2 traffic as bridges. In this context, an WLC is a bridge. Where this manual or the product interface uses the term bridge, you can assume the term is applicable to the WLC.

Enabling the Spanning Tree Protocol To enable STP, use the following command: set spantree {enable | disable} [{all | vlan vlanid | port port-list vlanid}] To enable STP on all VLANs configured on an WLC, type the following command: WLC# set spantree enable success: change accepted. To verify the STP state and display the STP parameter settings, enter the show spantree command. For information, see “Displaying Spanning Tree Information” on page 798.

Changing Standard Spanning Tree Parameters You can change the following standard STP parameters: Bridge priority Port cost Port priority


Enabling the Spanning Tree Protocol

791

Bridge Priority The bridge priority determines the WLC eligibility to become the root bridge. You can set this parameter globally or on individual VLANs. The root bridge is elected based on the bridge priority of each device in the spanning tree. The device with the highest bridge priority is elected to be the root bridge for the spanning tree. The bridge priority is a numeric value from 0 through 65,535. Lower numeric values represent higher priorities. The highest priority is 0, and the lowest priority is 65,535. The default bridge priority for all devices is 32,768. If more than one device has the highest bridge priority (lowest numeric value), the device with the lowest MAC address becomes the root bridge. If the root bridge fails, STP elects a new root bridge based on the bridge priorities of the remaining bridges.

Port Cost Port cost is a numeric value that STP adds to the total cost of a path to the root bridge. When a designated bridge has multiple equal-cost paths to the root bridge, the designated bridge uses the path with the lowest total cost. You can set this parameter on an individual port basis, for all VLANs the port is in, or for specific VLANs. You can specify a value from 1 through 65,535 for the port cost. The default depends on the port speed and link type. Table 1 lists the defaults for STP port path cost. Table 1.

SNMP Port Path Cost Defaults

Port Speed

Link Type

Default Port Path Cost

1000 Mbps

Full Duplex Aggregate Link (Port Group)

19

1000 Mbps

Full Duplex

4

100 Mbps


19

100 Mbps

Full Duplex

18

100 Mbps

Half Duplex

19

10 Mbps


19

10 Mbps

Full Duplex

95

10 Mbps

Half Duplex

100

Port Priority Port priority is the eligibility of the port to be the designated port to the root bridge, and thus part of the path to the root bridge. When the WLC has more than one link to the root bridge, STP uses the link with the lowest priority value. You can set this parameter on an individual port basis, for all VLANs the port is in, or for specific VLANs. Specify a priority from 0 (highest priority) through 255 (lowest priority). The default is 128.

Changing the Bridge Priority To change the bridge priority, use the following command: set spantree priority value {all | vlan vlanid}

792

Changing Standard Spanning Tree Parameters



Specify a bridge priority from 0 through 65,535. The default is 32,768. The all option applies the change globally to all VLANs. Alternatively, specify an individual VLAN. To change the bridge priority of VLAN pink to 69, type the following command: WLC# set spantree priority 69 vlan pink success: change accepted.

Changing STP Port Parameters You can change the STP cost and priority of an individual port, on a global basis or an individual VLAN basis.

Changing the STP Port Cost To change the cost of a port, use one of the following commands. set spantree portcost port-list cost cost set spantree portvlancost port-list cost cost {all | vlan vlanid} The set spantree portcost command changes the cost for ports in the default VLAN (VLAN 1) only. The set spantree portvlancost command changes the cost for ports in a specific other VLAN or in all VLANs. Specify a value from 1 through 65,535 for the cost. The default depends on the port speed and link type. (See Table 1 on page 792.) The all option applies the change to all VLANs. Alternatively, specify an individual VLAN. To change the cost on ports 3 and 4 in the default VLAN to 20, type the following command: WLC# set spantree portcost 3,4 cost 20 success: change accepted. To change the cost for the same ports in VLAN mauve, type the following command: WLC# set spantree portvlancost 3,4 cost 20 vlan mauve success: change accepted.

Resetting the STP Port Cost to the Default Value To reset the STP port cost to the default value, use one of the following commands: clear spantree portcost port-list clear spantree portvlancost port-list {all | vlan vlanid} The command applies only to the ports you specify. The port cost on other ports remains unchanged. To reset the cost of ports 3 and 4 in the default VLAN to the default value, type the following command: WLC# clear spantree portcost 3-4 success: change accepted. To reset the cost of ports 3 and 4 for VLAN beige, type the following command: WLC# clear spantree portvlancost 3-4 vlan beige success: change accepted.



793

Changing the STP Port Priority To change the priority of a port, use one of the following commands: set spantree portpri port-list priority value set spantree portvlanpri port-list priority value {all | vlan vlanid} The set spantree portpri command changes the priority for ports in the default VLAN (VLAN 1) only. The set spantree portvlanpri command changes the priority for ports in a specific other VLAN or in all VLANs. Specify a priority from 0 (highest priority) through 255 (lowest priority). The default is 128. The all option applies the change to all VLANs. Alternatively, specify an individual VLAN. To set the priority of ports 3 and 4 in the default VLAN to 48, type the following command: WLC# set spantree portpri 3-4 priority 48 success: change accepted. To set the priority of ports 3 and 4 to 48 in VLAN mauve, type the following command: WLC# set spantree portvlanpri 3-4 priority 48 vlan mauve success: change accepted.

Resetting the STP Port Priority to the Default Value To reset the STP port priority to the default value, use one of the following commands: clear spantree portpri port-list clear spantree portvlanpri port-list {all | vlan vlanid} The command applies only to the ports you specify. The port cost on other ports remains unchanged.

Changing Spanning Tree Timers You can change the following STP timers: Hello interval—The interval between configuration messages sent by an WLC when the WLC is acting as the root bridge. You can specify an interval from 1 through 10 seconds. The default is 2 seconds. Forwarding delay—The period of time a bridge other than the root bridge waits after receiving a topology change notification to begin forwarding data packets. You can specify a delay from 4 through 30 seconds. The default is 15 seconds. (The root bridge always forwards traffic.) Maximum age—The period of time that an WLC acting as a designated bridge waits for a new hello packet from the root bridge before determining that the root bridge is no longer available and initiating a topology change. You can specify an age from 6 through 40 seconds. The default is 20 seconds.

794




Changing the STP Hello Interval To change the hello interval, use the following command: set spantree hello interval {all | vlan vlanid} Specify an interval from 1 through 10 seconds. The default is 2 seconds. The all option applies the change to all VLANs. Alternatively, specify an individual VLAN. To change the hello interval for all VLANs to 4 seconds, type the following command: WLC# set spantree hello 4 all success: change accepted.

Changing the STP Forwarding Delay To change the forwarding delay, use the following command: set spantree fwddelay delay {all | vlan vlanid} Specify a delay from 4 through 30 seconds. The default is 15 seconds. The all option applies the change to all VLANs. Alternatively, specify an individual VLAN. To change the forwarding delay on VLAN pink to 20 seconds, type the following command: WLC# set spantree fwddelay 20 vlan pink success: change accepted. Changing the STP Maximum Age To change the maximum age, use the following command: set spantree maxage aging-time {all | vlan vlanid} Specify an age from 6 through 40 seconds. The default is 20 seconds. The all option applies the change to all VLANs. Alternatively, specify an individual VLAN. To change the maximum acceptable age for root bridge hello packets on all VLANs to 15 seconds, type the following command: WLC# set spantree maxage 15 all success: change accepted.

Configuring and Managing STP Fast Convergence Features The standard STP timers delay traffic forwarding briefly after a topology change. The interval that a port requires before changing from the listening state to the learning state or from the learning state to the forwarding state is called the forwarding delay. In some configurations, this delay is unnecessary. The WLC provides the following fast convergence features to bypass the forwarding delay: Port fast Backbone fast Uplink fast


Configuring and Managing STP Fast Convergence Features

795

Port Fast Convergence Port fast convergence bypasses both the listening and learning stages and immediately places a port in the forwarding state. You can use port fast convergence on ports that are directly connected to servers, hosts, or other MAC stations.

Informational Note: Do not use port fast convergence on ports connected to other bridges.

Backbone Fast Convergence Backbone fast convergence accelerates a port recovery following the failure of an indirect link. Normally, when a forwarding link fails, a bridge that is not directly connected to the link does not detect the link change until the maximum age timer expires. Backbone fast convergence enables the WLC to listen for bridge protocol data units (BPDUs) sent by a designated bridge when the designated bridge link to the root bridge fails. The WLC immediately verifies whether BPDU information stored on a port is still valid. If not, the bridge immediately starts the listening stage on the port. Informational Note: If you plan to use the backbone fast convergence feature, you must enable it on all the bridges in the spanning tree.

Uplink Fast Convergence Uplink fast convergence enables an WLC with redundant links to the network core to immediately change the state of a backup link to forwarding if the primary link to the root fails. Uplink fast convergence bypasses the listening and learning states to immediately enter the forwarding state. Informational Note: The uplink fast convergence feature is applicable to bridges acting as access switches to the network core (distribution layer) but are not in the core themselves. Do not enable the feature on WLC switches in the network core.

Configuring Port Fast Convergence To enable or disable port fast convergence, use the following command: set spantree portfast port port-list {enable | disable} To enable port fast convergence on ports 9, 11, and 13, type the following command: WLC# set spantree portfast port 9,11,13 enable success: change accepted.

Displaying Port Fast Convergence Information To display port fast convergence information, use the following command: show spantree portfast [port-list] To display port fast convergence information for all ports, type the following command: WLC# show spantree portfast

796




Port

Vlan

Portfast

------------------------- ----

----------

1

1

disable

2

1

disable

3

1

disable

4

1

enable

5

1

disable

6

1

disable

7

1

disable

8

1

disable

10

1

disable

15

1

disable

16

1

disable

17

1

disable

18

1

disable

19

1

disable

20

1

disable

21

1

disable

22

1

disable

11

2

enable

12

2

disable

13

2

disable

14

2

enable

In this example, port fast convergence is enabled on ports 11 and 14 in VLAN 2 and port 4 in VLAN 1.

Configuring Backbone Fast Convergence To enable or disable backbone fast convergence, use the following command: set spantree backbonefast {enable | disable} To enable backbone fast convergence on all VLANs, type the following command: WLC# set spantree backbonefast enable success: change accepted.

Displaying the Backbone Fast Convergence State To display the state of the backbone fast convergence feature, use the following command: show spantree backbonefast Here is an example: WLC# show spantree backbonefast



797

Backbonefast is enabled In this example, backbone fast convergence is enabled. Configuring Uplink Fast Convergence To enable or disable uplink fast convergence, use the following command: set spantree uplinkfast {enable | disable}

Displaying Uplink Fast Convergence Information To display uplink fast convergence information, use the following command: show spantree uplinkfast [vlan vlanid] The following command displays uplink fast convergence information for all VLANs: WLC# show spantree uplinkfast VLAN

port

list

-----------------------------------------------------------------------1

1(fwd),2,3

In this example, ports 1, 2, and 3 provide redundant links to the network core. Port 1 is forwarding traffic. The remaining ports block traffic to prevent a loop.

Displaying Spanning Tree Information You can use CLI commands to display the following STP information: Bridge STP settings and individual port information Blocked ports Statistics Port fast, backbone fast, and uplink fast convergence information Informational Note: For information about the show commands for the fast convergence features, see

“Configuring and Managing STP Fast Convergence Features” on page 1–795

Displaying STP Bridge and Port Information To display STP bridge and port information, use the following command: show spantree [port port-list | vlan vlanid] [active] By default, STP information for all ports and all VLANs is displayed. To display STP information for specific ports or a specific VLAN only, enter a port list or a VLAN name or number. For each VLAN, only the ports contained in the VLAN are listed in the command output. To list only the ports that are in the active (forwarding) state, enter the active option. To display STP information for VLAN mauve, type the following command: WLC# show spantree vlan mauve

798

Displaying Spanning Tree Information



VLAN

3

Spanning tree mode

PVST+

Spanning tree type

IEEE

Spanning tree enabled Designated Root

00-02-4a-70-49-f7

Designated Root Priority

32768

Designated Root Path Cost

19

Designated Root Port

1

Root Max Age

20 sec

Hello Time 2 sec

Forward Delay 15 sec

Bridge ID MAC ADDR

00-0b-0e-02-76-f7

Bridge ID Priority

32768

Bridge Max Age 20 sec Port

Vlan

Hello Time 2 sec STP-State

Forward Delay 15 sec Cost

Prio

Portfast

--------------------------------------------------------------------------1

1

Forwarding

19

128

Disabled

2

1

Blocking

19

128

Disabled

3

1

Blocking

19

128

Disabled

10

1

Forwarding

19

128

Disabled

15

1

Blocking

19

128

Disabled

16

1

Blocking

19

128

Disabled

In this example, VLAN mauve contains ports 1 through 3, 10, 15 and 16. Ports 1 and 10 are forwarding traffic. The other ports are blocking traffic. (For more information about the fields in the output, see the Juniper Mobility System Software Command Reference.)

Displaying the STP Port Cost by VLAN To display a brief list of the STP port cost for a port in each of the VLANs, use the following command: show spantree portvlancost port-list This command displays the same information as the show spantree command Cost field in a concise format for all VLANs. The show spantree command lists all the STP information separately for each VLAN. To display the STP port cost of port 1, type the following command: WLC# show spantree portvlancost 1 port 1 VLAN 1 have path cost 19

Displaying Blocked STP Ports To display information about ports that are in the STP blocking state, use the following command: show spantree blockedports [vlan vlanid] Copyright © 2013, Juniper Networks, Inc.


799

To display information about blocked ports on an WLC for the default VLAN (VLAN 1), type the following command: WLC# show spantree blockedports vlan default Port

Vlan

Port-State

Cost

Prio

Portfast

-----------------------------------------------------------------------22

190

Blocking

4

128

Disabled

Number of blocked ports (segments) in VLAN 1 : 1 (For information about the fields in the output, see the Juniper Mobility System Software Command Reference.)

Displaying Spanning Tree Statistics To display STP statistics, use the following command: show spantree statistics [port-list [vlan vlanid]] To display STP statistics for port 1, type the following command: WLC# show spantree statistics 1 BPDU related parameters Port 1

VLAN 1

spanning tree enabled for VLAN = 1 port spanning tree

enabled

state

Forwarding

port_id

0x8015

port_number

0x15

path cost

0x4

message age (port/VLAN)

0(20)

designated_root

00-0b-0e-00-04-30

designated cost

0x0

designated_bridge

00-0b-0e-00-04-30

designated_port

38

top_change_ack

FALSE

config_pending

FALSE

port_inconsistency

none

Port based information statistics

800

config BPDU's xmitted(port/VLAN)

0 (1)

config BPDU's received(port/VLAN)

21825 (43649)

tcn BPDU's xmitted(port/VLAN)

0 (0)

tcn BPDU's received(port/VLAN)

2 (2)

forward transition count (port/VLAN)

1 (1)




scp failure count

0

root inc trans count (port/VLAN)

1 (1)

inhibit loopguard

FALSE

loop inc trans count

0 (0)

Status of Port Timers forward delay timer

INACTIVE

forward delay timer value

15

message age timer

ACTIVE

message age timer value

0

topology change timer

INACTIVE

topology change timer value

0

hold timer

INACTIVE

hold timer value

0

delay root port timer

INACTIVE

delay root port timer value

0

delay root port timer restarted is

FALSE

VLAN based information & statistics spanning tree type

ieee

spanning tree multicast address

01-00-0c-cc-cc-cd

bridge priority

32768

bridge MAC address

00-0b-0e-12-34-56

bridge hello time

2

bridge forward delay

15

topology change initiator:

0

last topology change occurred:

Tue Jul 01 2003 22:33:36.

topology change

FALSE

topology change time

35

topology change detected

FALSE

topology change count

1

topology change last recvd. from

00-0b-0e-02-76-f6

Other port specific info dynamic max age transition

0

port BPDU ok count

21825

msg age expiry count

0

link loading

0

BPDU in processing

FALSE

num of similar BPDU's to process

0



801

received_inferior_bpdu

FALSE

next state

0

src MAC count

21807

total src MAC count

21825

curr_src_mac

00-0b-0e-00-04-30

next_src_mac

00-0b-0e-02-76-f6

(For information about the fields in the output, see the Juniper Mobility System Software Command Reference.)

Clearing STP Statistics To clear the STP statistics counters, use the following command. clear spantree statistics port-list [vlan vlanid] As soon as you enter the command, MSS resets the STP counters for the specified ports or VLANs to 0. The software then begins the counters again.

Spanning Tree Configuration Scenario This scenario configures a VLAN named backbone for connections from a WLC to the network backbone, adds ports 21 and 22 to the VLAN, and enables STP on the VLAN to prevent loops. 1. Remove the network cables from ports 21 and 22 or use MSS to disable the ports,. This prevents a loop until you complete the STP configuration. To disable the ports and verify the results, type the following commands: WLC# set port disable 21-22 success: set “disable” on port 21-22 WLC# show port status Port

Name

Admin

Oper

Config

Actual

Type

Media

===========================================================================

802

1 10/100BaseTx

up

up

auto

2 10/100BaseTx

up

down

auto

network

3 10/100BaseTx

up

down

auto

network

4 10/100BaseTx

up

down

auto

network

5 10/100BaseTx

up

down

auto

network

6 10/100BaseTx

up

down

auto

network

Spanning Tree Configuration Scenario

100/full

network



7 10/100BaseTx

up

down

auto

network

8 10/100BaseTx

up

down

auto

network

9 10/100BaseTx

up

down

auto

network

10 10/100BaseTx

up

down

auto

network

11 10/100BaseTx

up

down

auto

network

12 10/100BaseTx

up

down

auto

network

13 10/100BaseTx

up

down

auto

network

14 10/100BaseTx

up

down

auto

network

15 10/100BaseTx

up

down

auto

network

16 10/100BaseTx

up

down

auto

network

17 10/100BaseTx

up

down

auto

network

18 10/100BaseTx

up

down

auto

network

19 10/100BaseTx

up

down

auto

network

20 10/100BaseTx

up

down

auto

network

21

down

down

auto

network

22

down

down

auto

network

2. Configure a backbone VLAN and verify the configuration change. Type the following commands: WLC# set vlan 10 name backbone port 21-22 success: change accepted. WLC# show vlan config Admin VLAN Name

VLAN

Tunl

Port


Tag

State

---- --------------- ------ ----- ----- --------------- ----- ----1 default

Up

Up

5 1

10 backbone


Up

Down

none

Up

5


803

21

none

Down

22

none

Down

3. Enable STP on the backbone VLAN and verify the change. Type the following commands: WLC# set spantree enable vlan backbone success: change accepted. WLC# show spantree vlan 10 VLAN

10

Spanning tree mode

PVST+

Spanning tree type

IEEE


00-0b-0e-00-04-0c


32768


0

We are the root Root Max Age

20 sec

Hello Time 2 sec


Bridge ID MAC ADDR

00-0b-0e-00-04-0c

Bridge ID Priority

32768

Bridge Max Age 20 sec Port

Hello Time 2 sec

Vlan

STP-State

Forward Delay 15 sec Cost

Prio

Portfast

-------------------------------------------------------------------21

10

Disabled

4

128

Disabled

22

10

Disabled

4

128

Disabled

4. Reconnect or reenable ports 21 and 22 and verify the change. Type the following commands: WLC# set port enable 21-22 success: set “enable” on port 21-22 WLC# show port status Port

Name

Admin

Oper

Config

Actual

Type

Media

===========================================================================

804

1 10/100BaseTx

up

up

auto

2 10/100BaseTx

up

down

auto

network

3 10/100BaseTx

up

down

auto

network

4 10/100BaseTx

up

down

auto

network

5 10/100BaseTx

up

down

auto

network


100/full

network



6 10/100BaseTx

up

down

auto

network

7 10/100BaseTx

up

down

auto

network

8 10/100BaseTx

up

down

auto

network

9 10/100BaseTx

up

down

auto

network

10 10/100BaseTx

up

down

auto

network

11 10/100BaseTx

up

down

auto

network

12 10/100BaseTx

up

down

auto

network

13 10/100BaseTx

up

down

auto

network

14 10/100BaseTx

up

down

auto

network

15 10/100BaseTx

up

down

auto

network

16 10/100BaseTx

up

down

auto

network

17 10/100BaseTx

up

down

auto

network

18 10/100BaseTx

up

down

auto

network

19 10/100BaseTx

up

down

auto

network

20 10/100BaseTx

up

down

auto

network

21

up

up

auto

1000/full

network

22

up

up

auto

1000/full

network

5. Wait for STP to complete the listening and learning stages and converge, then verify that STP is operating properly and blocking one of the ports in the backbone VLAN. Type the following command: WLC# show spantree vlan 10 VLAN

10

Spanning tree mode

PVST+

Spanning tree type

IEEE


00-0b-0e-00-04-0c


32768



805


0

We are the root Root Max Age

806

20 sec


Hello Time 2 sec



Configuring Quality of Service

Configuring Quality of Service This chapter describes the Quality of Service (QoS) features supported in MSS and how to configure and manage them.

About QoS Quality of Service (QoS) protocols on a network can guarantee a certain level of throughput for a specific path, connection, or type of traffic. This makes it possible to ensure that critical network applications receive priority handling. MSS supports Layer 2 and Layer 3 classification and marking of traffic, and prioritized forwarding of wireless traffic for time-sensitive applications such as voice and video. For more information on QoS, consult any networking protocol reference available on the Internet or in book format.

Summary of QoS Features QoS features are configured in radio profiles and service profiles. Table 2 lists the QoS features in MSS. Table 2.

QoS Parameters

QoS Feature

Description

Configuration Command

QoS parameters configured in the radio profile QoS mode

Method used to set contention window parameters of forwarding queues on WLAs. One of the following modes can be enabled: SpectraLink Voice Priority Wi-Fi Multimedia WMM must be configured in order to accept WMM clients.

WMM powersave support

set radio-profile qos-mode See the following: “End-to-End QoS” on page 810 “Changing the QoS Mode” on page 820

Unscheduled Automatic Powersave Delivery (U-APSD).

set radio-profile wmm-powersave

U-APSD enables clients that use powersave mode to more efficiently request buffered unicast packets from WLA radios.

See the following: “WMM QoS in a Juniper Network with Local Switching” on page 817 “Enabling U-APSD Support” on page 820

QoS parameters configured in service profiles CAC mode

Call Admission Control, which regulates addition of new sessions on WLA radios. One of the following modes can be enabled: None (default) Session-based

Using client Differentiated Services Code Point (DSCP) value

Whether the WLA classifies the QoS level for IP packets from a client based on the DSCP value, instead of the 802.11 WMM user priority.


set service-profile cac-mode See the following: “Call Admission Control” on page 819 “Configuring Call Admission Control” on page 820

set qos-profile trust-client-dscp See “Using the Client DSCP Value to Classify QoS Level” on page 822.

About QoS

807

Table 2.

QoS Parameters (continued)

QoS Feature

Description

Configuration Command

Transmit rates

Data transmission rates supported by each radio type. The following categories are specified:

set service-profile transmit-rates

Beacon Multicast Mandatory (a client must support at least one of these rates to associate) Disabled Standard (valid rates that are not disabled and are not mandatory) Defaults: Mandatory: 802.11a—6.0, 12.0, 24.0 802.11b—5.5, 11.0 802.11g—1.0, 2.0, 5.5, 11.0 Disabled—None. All rates applicable to the radio type are supported by default. Beacon: 802.11a—6.0 802.11b—5.5 802.11g—5.5 Multicast—auto for all radio types (highest rate that can reach all associated clients is used) Broadcast control

Mechanisms to reduce overhead caused by wireless broadcast traffic or traffic from unauthenticated clients. One or more of the following can be enabled: Proxy ARP No-Broadcast DHCP Restrict All three options are disabled by default.

Session timers

set service-profile proxy-arp set service-profile no-broadcast set service-profile dhcp-restrict See the following:

“Broadcast Control” on page 819 “Enabling Broadcast Control” on page 822

set service-profile user-idle-timeout user idle timeout—Period a client can remain idle set service-profile idle-client-probing before being disassociated (default: 180

Keepalives and timeouts for client sessions. The following timeout parameters can be configured:

seconds) idle-client probing—keepalives sent to clients (enabled by default) Bandwidth Management

808

About QoS

Maximum bandwidth for aggregates of access categories.

set qos-profile profile-name max-bw



SIP Awareness Integrated SIP awareness in a wireless network adds a new level of intelligence that allows granular and dynamic control of voice applications between wireless clients. The current approach of using static ACLs (Access Control Lists) to prioritize voice traffic without awareness of the network application layer forces you to implement very specific policies which are either too restrictive or too open. With the emergence of converged applications and clients (clients that support voice and data applications), classification of each traffic flow per application and applying flow policies such as traffic marking and bandwidth management for traffic flow at the source of traffic, wireless to wired, in both directions. A QoS flow is a set of packets used by an application that needs a QoS policy. QoS flows are discovered by packet inspection in the forwarding path and some QoS flows, such as telnet, can be recognized by a particular UDP or TCP port. Other QoS flows, such as SIP data, require stateful protocol analysis. The following QoS flow is defined: SIP-data — An RTU/UDP flow defined by the client IP address, the SIP server IP address, and a pair of UDP ports. WLC# set qos traffic-class voip-data flow sip-data WLC# set qos-profile profile-name traffic-class voip-data Up to eight traffic class and policy pairs can be added to a QoS profile. Each policy consists of the following: Minimum bandwidth (Kbps) Maximum bandwidth (Kbps) Class of Service (CoS) WLCs receive voice call state information from APs. WLCs do not store SIP call data locally, but can be configured to send Call Data Records (CDRs) as accounting requests to a RADIUS server group. CDRs are sent for successful call starts and completions. A CDR and an SNMP trap are sent for call rejections. To enable the SNMP failure trap, use the following command: WLC# set snmp notify profile notify-profile-name send MultimediaCallFailureTraps success:change accepted. To enable CDR accounting, use the following command: WLC# set accounting cdr radius-server-group RADIUS attributes included in the accounting requests: On successful call start: AAA_SESS_TYPE_ACCT_START On successful call completion or rejection: AAA_SESS_TYPE_ACCT_STOP Acct-Session-time: call duration in seconds. Sent only in call complete CDRs. NAS-Port_id: AP number and radio Calling-Station-Id: MAC address of the wireless client. Juniper VSA SIP-Call-Record: This string attribute is used to send SIP information such as call status, call quality, SIP local and remote endpoints (SIP id, IP address, port), and SIP registrar. Copyright © 2013, Juniper Networks, Inc.

About QoS

809

To display sessions for a specific QoS profile, use the following command: WLC# show sessions network qos-profile profile-name To display session information about SIP flows, use the following command: WLC# show sessions network sip [statistics | verbose | voice-details]

End-to-End QoS WLC switches and WLAs each perform classification on ingress to determine a CoS value for the packet. This CoS value is used to mark the packet at the egress interface and to determine priority treatment on egress from the WLA. CoS values range from 0 to 7. Differentiated Services Code Point (DSCP) is a 6-bit value in IP-TOS with a range from 0 to 63WLC switches and WLAs each provide classification and marking for QoS: WLC switches and WLAs classify wired traffic based on the 802.1p tag value (for tagged VLAN traffic) or DSCP value. Tunnel packets are classified using the DSCP of the tunnel header (TH), other packets with the inner or 'client' DSCP. WLAs classify ingress traffic from wireless clients based on the user priority value in the 802.11 header. If the trust-client-dscp option is enabled for a QoS profile, WMM QoS is ignored, and the QoS level is classified based on the DSCP value. 802.11 data packets without WMM are classified as QoS level 0 unless static CoS is enabled or the trust-client-dscp option is enabled. WLCs and WLAs mark CoS for wired traffic in 802.1p and TH DSCP. WLAs place traffic to a wireless client in a forwarding queue, based on the CoS value, and mark user priority for WMM clients. The traffic is then forwarded based on the queue priority.

QoS Mapping The mapping between DSCP and CoS values is configurable. An ingress map determines how DSCP values are classified into CoS values. An egress map determines how CoS values are marked in the TH DSCP. The WLC and associated WLAs share the same set of maps.

Informational Note: It is recommended to configure the same ingress and egress maps across the mobility domain.

Mapping from 802.1p, WMM user priority to CoS is static. Also, mapping from CoS to access category (AC) on the WLA is static. Table 3 shows how WMM priority information is mapped across the network. Table 3.

WMM Priority Mappings

CoS

WMM User Priority

802.1p

IP ToS

IP Precedence

DSCP

WLA Forwarding Queue

0

0

0

0

0

0

Best Effort

1

1

1

0x20

1

8

Background

2

2

2

0x40

2

16

Background

3

3

3

0x60

3

24

Best Effort

810

About QoS



Table 3.

WMM Priority Mappings (continued)

CoS

WMM User Priority

802.1p

IP ToS

IP Precedence

DSCP

WLA Forwarding Queue

4

4

4

0x80

4

32

Video

5

5

5

0xa0

5

40

6

6

6

0xc0

6

48

7

7

7

0xe0

7

56

Voice

Table 4 lists the default mappings between internal CoS values on an WLA and the forwarding queues. Table 4.

CoS-to-WLA-Forwarding-Queue Mappings WLA Forwarding Queue

CoS

(Access Category)

1 or 2

Background

0 or 3

Best Effort

4 or 5

Video

6 or 7

Voice

To display CoS mappings and queue usage statistics on an WLA, see “Displaying WLA Forwarding Queue Statistics” on page 826. Figure 1–1 on page 813 describes classifying ingress traffic. Figure 1–2 on page 814 describes marking egress traffic. The figures also describe the default mappings between DSCP and CoS. (For information about changing CoS mappings, see “Changing CoS Mappings” on page 822.)

QoS Mode The WLA has four forwarding queues, one per access category, for unicast packet traffic. The queue behavior is based on the QoS mode. The following QoS modes are supported: Wi-Fi Multimedia (WMM)—Provides wireless QoS for time-sensitive applications such as voice and video. WMM QoS is enabled by default and does not require any configuration. SpectraLink Voice Priority (SVP)—Provides optimized forwarding of SVP voice traffic. SVP QoS is disabled by default. The SVP QoS mode optimizes the forwarding of SVP traffic for voice by setting the contention window on an WLA radio to 0 microseconds. Normally, an WLA radio waits an additional number of microseconds following the fixed wait time, before forwarding a queued packet or frame. Each forwarding queue has a different range of possible random wait times. The Voice queue has the narrowest range, whereas the Background and Best Effort queues have the widest range. The random wait times ensure that the Voice queue gets statistically more access to the air than the other queues. By setting the random wait time to 0 for SVP, the SVP QoS mode provides SVP traffic the greatest possible access to the air, on a statistical basis. The QoS mode affects forwarding of SVP traffic only. The random wait times for other types of traffic are the same as those used when the QoS mode is WMM.


About QoS

811

Static CoS You can configure MSS to mark all wireless traffic on an SSID with a specific CoS value. When static CoS is enabled, the WLA marks all traffic between clients and the WLC for a given SSID with the static CoS value. The static CoS value must be configured on the SSID QoS profile. Static CoS has the easiest configuration of CoS. However, the static CoS value applies to all traffic regardless of traffic type. To instead assign CoS based on specific traffic types within an SSID, use an ACL. Informational Note: When static CoS is enabled, you cannot override the static CoS value by using ACLs to mark CoS.

CoS ACLs You can configure an ACL that marks packets matching the ACL with a CoS value. CoS is not changed in packets that do not match the ACL rule. In local switching mode, ACLs affect the packet flow within the WLA. For more information, see “Using ACLs to Change CoS” on page 921.

812

About QoS



Figure 1–1. QoS—Classification of Ingress Packets


About QoS

813

Figure 1–2. QoS—Marking of Egress Packets

Figure 1–3 shows an example of end-to-end QoS in a Juniper network. In this example, voice traffic is prioritized based on WMM. This example assumes that the QoS mappings are set to the default values.

814

About QoS



Figure 1–3. WMM QoS in a Juniper Overlay Network

Figure 1–3 shows the following process: 1. A user sends voice traffic from a WMM VoIP phone. The phone marks the CoS field of the packet with user priority 7, indicating that the packet is for high priority (voice) traffic. 2. WLA A receives the voice packet and classifies the packet by mapping the user priority in the 802.11 header to an internal CoS value. In this example, the user priority is 7 and maps to internal CoS 7. The WLA encapsulates the data in an IP tunnel packet, and marks the DSCP value in the tunnel header based on the internal CoS value. In this example, the WLA maps internal CoS 7 to DSCP 56 and marks the IP tunnel header DSCP field with value 56. The WLA then sends the packet to the WLC switch. 3. WLC A receives the packet on the IP tunnel connecting the WLC to WLA A. The WLC classifies the packet based on the DSCP value in the IP header of the tunnel packet (in this example, DSCP 56), and maps this value to an internal CoS value (in this example, 7). Informational Note: In this example, the WLC interface with the WLAWLA is untagged, so the WLC does not classify the packet based on the 802.1p value.


About QoS

815

WLC A marks the packet based on the packet internal CoS value. In this example, the egress interface is in a VLAN and has an 802.1Q VLAN tag. Therefore, the WLC marks both the 802.1p value (with 7) and DSCP value (with 56) of the tunnel header. WLC A sends the packet to WLC B on the IP tunnel that connects the two switches. Informational Note: An ACL can override marking on a packet. If a packet matches a permit ACL mapped to the outbound traffic direction on the WLA port, Distributed WLA, or user VLAN, and the ACL sets the CoS value, the tunnel header DSCP value is marked based on the CoS value in the ACL instead.

1. WLC B receives the packet from the Layer 3 cloud. The packet has an 802.1Q VLAN tag, so the WLC classifies the packet by mapping its 802.1p value (in this example, 7) to the matching internal CoS value (also 7). 2. WLC B encapsulates the packet in an IP tunnel packet and marks the DSCP value in the tunnel header based on the internal CoS value of the packet. In this example, the WLC marks the tunnel header with DSCP 56. WLC B sends the packet to WLA B on the IP tunnel that connects them. 3. WLA B receives the packet and does the following: Maps the DSCP value in the tunnel header (56) to an internal CoS value (7). Marks the packet user priority based on the internal CoS value (7). Places the packet in a forwarding queue (Voice) based on the internal CoS value (7). In this example, the WLA places the packet in the Voice forwarding queue. The Voice queue has statistically more access to the air than the other queues, so voice traffic receives priority treatment.

816

About QoS



Figure 1–4. WMM QoS in a Juniper Network with Local Switching

Figure 1–4 shows the following process: 4. A user sends voice traffic from a WMM VoIP phone. The phone marks the CoS field of the packet with user priority 7, indicating that the packet is for high priority (voice) traffic. 5. WLA A receives the voice packet and classifies the packet by mapping the user priority in the 802.11 header to an internal CoS value. 6. The WLA marks the 802.1p value as 7 based on the internal CoS value (7), and then uses the internal CoS value to set the 802.1p value in the VLAN tag. 7. The WLA sends the data in an IP packet to the Layer 3 network. 8. Because the network is configured for local switching, the packet is then sent directly to WLA B. 9. WLA B receives the packet and does the following: Classifies the packet using 802.1p tag to mark an internal CoS value (7). Marks the packet user priority based on the internal CoS value (7). Places the packet in a forwarding queue (Voice) based on the internal CoS value (7). In this example, the WLA places the packet in the Voice forwarding queue. The Voice queue has statistically more access to the air than the other queues, so voice traffic receives priority treatment.


About QoS

817

Bandwidth Management for QoS You can configure maximum bandwidth (full duplex rate) for aggregates of access categories (ACs) for a wireless client. Downstream packets are shaped and upstream packets are policed. The WLA has one queue per AC and each queue is a finite size (