basic participant

Basic Installation and Configuration of a Meru Network

Participant Guide

Release 3.6.1

Document Number: 883-00006 Rev A Rel 3.6.1-41 Ver 1Basic Installation and Configuration Participant Guide

Revision History

Copyright © Meru Networks, Inc., 2009. All rights reserved.

Other names and brands may be claimed as the property of others.

Author: Tom Berry

AcknowledgementsBrooks Graham, Robert Ferruolo, and Ben Dunsbergen contributed materially to the creation of this course.

Revision Date Revision Description

November 2009 Rev A Ver 1 Initial 3.6.1 Release

Contents

Preface

Module 1 What’s Different in a Meru Network?The Four Problems of Ordinary Wireless Networks . . . . . . . . . . . . . . . 2

Advantages of the Meru Architecture . . . . . . . . . . . . . . . . . . . . . 4What a Meru AP Does . . . . . . . . . . . . . . . . . . . . . . . . . 5

Density in a Meru Network . . . . . . . . . . . . . . . . . . . . . . . . . 6Non-contention for a Single AP . . . . . . . . . . . . . . . . . . . . . . 6What a Meru Controller Does . . . . . . . . . . . . . . . . . . . . . . 7Multiple AP Effects . . . . . . . . . . . . . . . . . . . . . . . . . . 8802.11n Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . 10802.11n Coverage is Unpredictable . . . . . . . . . . . . . . . . . . . . 11

Predictable Airtime Access . . . . . . . . . . . . . . . . . . . . . . . . . 13Reliability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13Density . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15Advantages of a Meru Network . . . . . . . . . . . . . . . . . . . . . . 16

Meru Virtual Cell Roaming . . . . . . . . . . . . . . . . . . . . . . . . . 17

The Four (No-Longer) Problems . . . . . . . . . . . . . . . . . . . . . . . 19

Module 2 Getting Started: Initial SetupInitial Connection to the Controller . . . . . . . . . . . . . . . . . . . . . . 22

setup Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23Activating the Inference Engines . . . . . . . . . . . . . . . . . . . . . 24Turning Off the Controller . . . . . . . . . . . . . . . . . . . . . . . . 25Default Login Accounts . . . . . . . . . . . . . . . . . . . . . . . . . 26Adding Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

Upgrading the System . . . . . . . . . . . . . . . . . . . . . . . . . . . 28Upgrading System Software . . . . . . . . . . . . . . . . . . . . . . . 28Upgrading Access Points . . . . . . . . . . . . . . . . . . . . . . . . 29Importing a License File. . . . . . . . . . . . . . . . . . . . . . . . . 30

Deploying APs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31Configuring Controller Discovery . . . . . . . . . . . . . . . . . . . . . 32

Saving Your Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33Backing up Controller Configuration Files . . . . . . . . . . . . . . . . . 34Restoring Controller Configuration Files . . . . . . . . . . . . . . . . . . 35Rebooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

Lab Preview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Contents iii

Getting Started: Initial Setup (continued) Lab Exercises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Perform an Initial Setup. . . . . . . . . . . . . . . . . . . . . . . . . 38Upgrade System Software . . . . . . . . . . . . . . . . . . . . . . . . 40Start the Web User Interface . . . . . . . . . . . . . . . . . . . . . . . 41Adding Administrative Groups and Users. . . . . . . . . . . . . . . . . . 42Preserve Configuration Changes . . . . . . . . . . . . . . . . . . . . . 43Back Up the Controller Configuration File . . . . . . . . . . . . . . . . . 43Connect to the Command Line Interface . . . . . . . . . . . . . . . . . . 44Adjust AP Parameters (CLI) . . . . . . . . . . . . . . . . . . . . . . . 44Adjust AP Parameters (WebUI) . . . . . . . . . . . . . . . . . . . . . 45Back Up the Controller Configuration File to a Remote System . . . . . . . . . 46

Module 3 Build a Test NetworkESSIDs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

Virtual Cell Types . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

Security Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50Wireless Authentication Methods . . . . . . . . . . . . . . . . . . . . . 51Creating an ESSID. . . . . . . . . . . . . . . . . . . . . . . . . . . 52

VLANs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53Configuring VLANs . . . . . . . . . . . . . . . . . . . . . . . . . . 54ESS Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

Lab Preview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

Lab Exercises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57Create an ESS (WebUI). . . . . . . . . . . . . . . . . . . . . . . . . 57Create a VLAN Profile . . . . . . . . . . . . . . . . . . . . . . . . . 58Restore a Controller Configuration . . . . . . . . . . . . . . . . . . . . 59

Module 4 Installation Pre-PlanningSite Characterization . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

Site Report Forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

Wireless Spectrum Scanning . . . . . . . . . . . . . . . . . . . . . . . . 64

AP Range . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65AP Placement Simulation . . . . . . . . . . . . . . . . . . . . . . . . 66

Density Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . 70

Scan for Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

AP Placement Process . . . . . . . . . . . . . . . . . . . . . . . . . . . 72Sample AP Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

Deployment Best Practices . . . . . . . . . . . . . . . . . . . . . . . . . 74802.11n Deployments . . . . . . . . . . . . . . . . . . . . . . . . . 75

Integrate with Wired LAN . . . . . . . . . . . . . . . . . . . . . . . . . 76

Ekahau Site Survey . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

Lab Exercises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78Placing APs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

iv Basic Installation and Configuration of a Meru Network

Module 5 Build a Voice NetworkIntroduction to VoIP. . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

SIP Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85Example VoIP Network . . . . . . . . . . . . . . . . . . . . . . . . . 85Session Initiation Protocol (SIP) Description . . . . . . . . . . . . . . . . 86Typical SIP Session . . . . . . . . . . . . . . . . . . . . . . . . . . 87

Over-the-Air Quality of Service (QoS) . . . . . . . . . . . . . . . . . . . . 88Call Admission Control . . . . . . . . . . . . . . . . . . . . . . . . . 89Call Load Balancing . . . . . . . . . . . . . . . . . . . . . . . . . . 90

Quality of Service. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91QoS Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92QoS Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93Monitoring QoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

Deploying VoIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95Obtaining Performance Characteristics . . . . . . . . . . . . . . . . . . . 95VoIP Setting Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . 96Typical ESS Configuration . . . . . . . . . . . . . . . . . . . . . . . 97

Lab Preview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

Lab Exercises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100Create an ESS (using the CLI) . . . . . . . . . . . . . . . . . . . . . 100Create a VLAN Profile . . . . . . . . . . . . . . . . . . . . . . . . 102Calling with a SIP Phone . . . . . . . . . . . . . . . . . . . . . . . 105Examining QoS Performance Characteristics . . . . . . . . . . . . . . . 106

Module 6 Build a Data NetworkWEP to WPA2 Evolution . . . . . . . . . . . . . . . . . . . . . . . . 108

The 802.1x RADIUS Authentication Process . . . . . . . . . . . . . . . . . 109RADIUS Protocol Example . . . . . . . . . . . . . . . . . . . . . . 109RADIUS Configuration Considerations. . . . . . . . . . . . . . . . . . 111Common RADIUS Server Configuration Problems . . . . . . . . . . . . . 112

Firewalling and Rate Limiting . . . . . . . . . . . . . . . . . . . . . . . 113QoS Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114QoS Action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115QoS Apportion . . . . . . . . . . . . . . . . . . . . . . . . . . . 116QoS Apportion Example . . . . . . . . . . . . . . . . . . . . . . . 117Firewall Rules - Exampls . . . . . . . . . . . . . . . . . . . . . . . 118

Per-ESS Firewall Policies. . . . . . . . . . . . . . . . . . . . . . . . . 122Per-Group Firewall Policies . . . . . . . . . . . . . . . . . . . . . . 123

Lab Preview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

Lab Exercises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125Removing a User from Your Network . . . . . . . . . . . . . . . . . . 125Create a WPA2PSK ESS . . . . . . . . . . . . . . . . . . . . . . . 127Create an 802.1x ESS. . . . . . . . . . . . . . . . . . . . . . . . . 127Configure the Wireless Network Client . . . . . . . . . . . . . . . . . 128Log Into the 802.1x Network . . . . . . . . . . . . . . . . . . . . . . 133

Contents v

Module 7 Build a Guest NetworkCaptive Portal Configuration . . . . . . . . . . . . . . . . . . . . . . . . 136

Guest Network Types . . . . . . . . . . . . . . . . . . . . . . . . . 136Guest VLANs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137Using Captive Portal . . . . . . . . . . . . . . . . . . . . . . . . . . 138Creating Local Captive Portal (CP) Users. . . . . . . . . . . . . . . . . . 139

Lab Preview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140

Lab Exercises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141Configure Captive Portal for Local Users . . . . . . . . . . . . . . . . . . 141Configure Captive Portal for RADIUS-Authenticated Users . . . . . . . . . . 143Creating Guest-Isolating Firewall Rules . . . . . . . . . . . . . . . . . . 144

Module 8 TroubleshootingWhat to Do When Things Go Wrong . . . . . . . . . . . . . . . . . . . . . 148

Stages of Connection . . . . . . . . . . . . . . . . . . . . . . . . . . . 149Connection Transactions . . . . . . . . . . . . . . . . . . . . . . . . 150

Information Facilities . . . . . . . . . . . . . . . . . . . . . . . . . . . 151

Station Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152Station Buffered Diagnostics. . . . . . . . . . . . . . . . . . . . . . . 152Interactive Station Logging . . . . . . . . . . . . . . . . . . . . . . . 153Historical Station Logging. . . . . . . . . . . . . . . . . . . . . . . . 154Syslog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155

Inference Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156Activating the Inference Engine . . . . . . . . . . . . . . . . . . . . . 157Station Counters . . . . . . . . . . . . . . . . . . . . . . . . . . . 158

Capturing Packets . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159Filtering Packets . . . . . . . . . . . . . . . . . . . . . . . . . . . 160Where to Measure Wireless Networks . . . . . . . . . . . . . . . . . . . 161Wireshark . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162Saving Captures . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163

diagnostics Command . . . . . . . . . . . . . . . . . . . . . . . . . 164

Lab Preview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165

Lab Exercises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166Station Diagnostics . . . . . . . . . . . . . . . . . . . . . . . . . . 166Capture Packets . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166Capture a SIP Session . . . . . . . . . . . . . . . . . . . . . . . . . 168Capture a WPA Session. . . . . . . . . . . . . . . . . . . . . . . . . 169Capture a RADIUS Session . . . . . . . . . . . . . . . . . . . . . . . 169Troubleshoot a RADIUS Session . . . . . . . . . . . . . . . . . . . . . 170

Appendix A Job AidsCLI Command Reference-Lab . . . . . . . . . . . . . . . . . . . . . . . 175

What to Do When Things Go Wrong – Installation . . . . . . . . . . . . . . . 177

vi Basic Installation and Configuration of a Meru Network

What to Do When Things Go Wrong – RADIUS . . . . . . . . . . . . . . . 179Review Customer Traces on the Controller . . . . . . . . . . . . . . . . 179Verify Configuration of the Controller . . . . . . . . . . . . . . . . . . 180Perform Packet Capture of Wired RADIUS Flow . . . . . . . . . . . . . . 181Perform Packet Capture of Wireless EAPOL Flow . . . . . . . . . . . . . 182Perform Packet Capture of Complete RADIUS Transaction . . . . . . . . . . 182

What to Do When Things Go Wrong – VoIP . . . . . . . . . . . . . . . . . 183Verify call is treated as QoS . . . . . . . . . . . . . . . . . . . . . . 183Verify configuration of Controller . . . . . . . . . . . . . . . . . . . . 184Debug why a call is not treated as QoS . . . . . . . . . . . . . . . . . . 185

Appendix B ResourcesAdditional References . . . . . . . . . . . . . . . . . . . . . . . . . . 187

Wireless Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 187Voice over IP (VoIP) and Quality of Service (QoS) . . . . . . . . . . . . . 188Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . 188

Controller Discovery Process . . . . . . . . . . . . . . . . . . . . . . . 189Capture vs. Forward Behavior . . . . . . . . . . . . . . . . . . . . . 190

Subnet Masks: CIDR to Octet Conversion . . . . . . . . . . . . . . . . . . 192Meru System Port Usage . . . . . . . . . . . . . . . . . . . . . . . 192

Packet Capture Filters . . . . . . . . . . . . . . . . . . . . . . . . . . 194

Appendix C Troubleshooting ReferencesClients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197

Station Cannot See SSID or Associate . . . . . . . . . . . . . . . . . . 197Client Cannot Authenticate with 802.1x . . . . . . . . . . . . . . . . . 197Captive Portal Clients Cannot Authenticate . . . . . . . . . . . . . . . . 197Clients Cannot get DHCP Address . . . . . . . . . . . . . . . . . . . 198Voice Quality is Bad . . . . . . . . . . . . . . . . . . . . . . . . . 198

AP Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . 199AP Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199Upgrading/Replacing APs . . . . . . . . . . . . . . . . . . . . . . . 199UI Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200Deployment Issues . . . . . . . . . . . . . . . . . . . . . . . . . . 200

Appendix D Hardware ReferenceControllers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201

MC5000 Features . . . . . . . . . . . . . . . . . . . . . . . . . . 201MC4100 Features . . . . . . . . . . . . . . . . . . . . . . . . . . 203MC3000 Features . . . . . . . . . . . . . . . . . . . . . . . . . . 205MC1500 Features . . . . . . . . . . . . . . . . . . . . . . . . . . 206MC1000 Features . . . . . . . . . . . . . . . . . . . . . . . . . . 207MC500 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . 208Comparison of Controller Features . . . . . . . . . . . . . . . . . . . 208SA1000 Features . . . . . . . . . . . . . . . . . . . . . . . . . . 209

Contents vii

Hardware Reference (continued) Access Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211

AP150 Connectors. . . . . . . . . . . . . . . . . . . . . . . . . . . 211AP150 Status LEDs . . . . . . . . . . . . . . . . . . . . . . . . . . 211AP180 (OAP180) Connectors . . . . . . . . . . . . . . . . . . . . . . 213AP180 Status LEDs . . . . . . . . . . . . . . . . . . . . . . . . . . 213AP201/208 Connectors . . . . . . . . . . . . . . . . . . . . . . . . . 214AP201/208 Status LEDs . . . . . . . . . . . . . . . . . . . . . . . . 215How to Identify AP 200 Revision Number . . . . . . . . . . . . . . . . . 217AP300 Ports and Connectors . . . . . . . . . . . . . . . . . . . . . . . 218AP300 Status LEDs . . . . . . . . . . . . . . . . . . . . . . . . . . 219RS4000 Connectors . . . . . . . . . . . . . . . . . . . . . . . . . . 221RS4000 Status LEDs . . . . . . . . . . . . . . . . . . . . . . . . . . 221

Installing the MC5000 Controller Chassis . . . . . . . . . . . . . . . . . . . 222About the Shelf Manager . . . . . . . . . . . . . . . . . . . . . . . . 225MC5000 Blade Insertion and Removal . . . . . . . . . . . . . . . . . . . 226

Controller Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . 227

Powering Off the Controller . . . . . . . . . . . . . . . . . . . . . . . . 228

LED Status Indicators . . . . . . . . . . . . . . . . . . . . . . . . . . . 228Controller LED Status Indicators . . . . . . . . . . . . . . . . . . . . . 229Ethernet LED Status Indicators . . . . . . . . . . . . . . . . . . . . . . 230Navigating the Status Panel Information . . . . . . . . . . . . . . . . . . 231

Module E Wireless OverviewWhat is Wireless Trying to Do? . . . . . . . . . . . . . . . . . . . . . . . 236

How Does 802.3 Wired (Ethernet) Work? . . . . . . . . . . . . . . . . . . . 237

How Does Wireless Work? . . . . . . . . . . . . . . . . . . . . . . . . . 238

Radio Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239

Antennas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241

Wireless Terminology Review . . . . . . . . . . . . . . . . . . . . . . . 242

Association Process Review . . . . . . . . . . . . . . . . . . . . . . . . 243

Wireless Authentication Methods . . . . . . . . . . . . . . . . . . . . . . 244802.1x Authentication Concepts . . . . . . . . . . . . . . . . . . . . . 245

Rogues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246

Comparison of Wired LANs and Wireless LANs (WLANs) . . . . . . . . . . . . 247

What’s Different with Wireless? . . . . . . . . . . . . . . . . . . . . . . . 248Physical Media . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249Contention for Shared Medium . . . . . . . . . . . . . . . . . . . . . . 250Mixed b/g Client Effects . . . . . . . . . . . . . . . . . . . . . . . . 251Co-channel Interference . . . . . . . . . . . . . . . . . . . . . . . . 252Ordinary Wireless Roaming . . . . . . . . . . . . . . . . . . . . . . . 255

The Four Problems of Wireless . . . . . . . . . . . . . . . . . . . . . . . 259

Index

viii Basic Installation and Configuration of a Meru Network

Preface

This module serves as a starting point for the course.

Preface vii

Introductions

Introductions

3© 2009 Meru Networks, Inc. All rights reserved.

Introductions

Name Experience

How I got associated with Meru

What I want to get out of this session is…

viii Basic Installation and Configuration of a Meru Network

Schedule

Schedule


Schedule

IntroductionsController SetupBuild a Test Network Installation Pre-planning

Build a Voice Network Build a Data Network Build a Guest NetworkTroubleshooting

Preface ix

Administrivia

Administrivia


Administrivia

Breaks 10 minutes each hour

Typography: Names of buttons and hyperlinks appear in bold text displayed on screen by computer text you type in variAbles you type in that requires substitution Checkoff icons ( ) – You must ask Instructor to

check certification progress at these points.

x Basic Installation and Configuration of a Meru Network

Lab Overview

Lab Overview


Lab Overview

Labs start detailed, get more generalWhen you see this icon

during your exercises, have the instructor check your progress (required for certification)

Preface xi

Lab Overview

xii Basic Installation and Configuration of a Meru Network

Module 1What’s Different in a Meru Network?

This module describes some core concepts used in Meru technology. Familiarity with these concepts will help you as you design, install and configure Meru networks.

At the end of this module, you’ll be able to:

Describe the advantages of a Meru network

What’s Different in a Meru Network? 1

The Four Problems of Ordinary Wireless Networks


Contention: It's a “free-for-all”. Ordinary APs have to compete for airtime just like all the rest of the nodes.

Mixed b/g: Inherently most other wireless networks are unfair. The g clients do not get a “g experience” but the b clients do -this means that the most efficient interfaces pay the penalty.

Co-Channel Interference: The “solution of deploying on channels 1/6/11 is not ever mentioned in the 802.11 spec. It's a hack so that 802.11 implementations can scale to more than one AP in a conference room (which is what 802.11 was originally designed for). Picturing the radio footprint of channel 1/6/11 “circles on whiteboards” is a fallacy. Radio propagates beyond the circles and nearby APs on the same channel *do* interfere with each other. Microcell can't help; the physics of radio transmission guarantee interference at any power level.

© 2009 Meru Networks, Inc. All rights reserved.


Contention for shared medium

Mixed b/g clients

Co-channel interference

Clients control association

2 Basic Installation and Configuration of a Meru Network


Client Control of Network: clients are always looking for “greener grass” but don't have nearly enough information to make good decisions. Some clients get sticky, some ping-pong: it's a mess. Cellphone infrastructure does not allow individual cellphones to determine how the cell network will operate but “ordinary” wireless networks allow clients to manage the operation of the wireless network.


Advantages of the Meru Architecture


The Meru AP's strict timing control makes the wireless network behave in a much more deterministic way. This is analogous to Time Division Multiplexing (TDM), though this is only an analogy. The Meru implementation adheres strictly to the relevant standards - nothing proprietary, no client software necessary.

Fairness: b clients get enough airtime to have a “b” experience, but g clients get their fair share and get a “g” experience.

Virtual Cell: Since there only appears to be one AP in the air, the clients stop looking for “greener grass”. No “sticky client” or ping-pong problems. Handoffs are transparent to the client and almost instantaneous. (On “ordinary” wireless networks, roaming takes between 50ms and 2000ms)


Meru Architecture

Meru’s Simple Secret: Control the uncontrolled

AP coordinates client transmissions Clients don’t transmit at same time Standards-based fairness

Controller coordinates between APs Single Channel – APs don’t transmit at same time

- APs far enough apart can transmit at the same time

Quality of Service across network Virtual Cell – all APs appear to be one AP



What a Meru AP Does

A Meru AP:

Manges contention between stations, deciding when each station can transmit and splitting the amount of air time fairly between stations.

Continuously monitors the available bandwidth so it can honor (or decline) bandwidth requests form the controller.

Allocates bandwidth for upstream QoS.

Services its internal packet queues to provide guaranteed bandwidth.

Meru APs are neither “fat APs” nor “thin APs”. Really, they’re the best of both worlds with none of the drawbacks.


What a Meru AP Does

Manages station contention

Monitors available bandwidth

Recognizes QoS flows Allocates bandwidth for

upstream packets

Delivers prioritized downstream packets


Density in a Meru Network


Non-contention for a Single AP

Meru's Air Traffic Control (ATC) technology works at the 802.11 MAC layer to manage contention and effectively allow the infrastructure to exert more control over client access.

By implementing MAC layer algorithms in the AP, and coordinating these across APs, Meru’s technology reduces collisions and the resultant loss in channel utilization, thus managing contention far more effectively than other schemes.

Performance is optimized regardless of the number of actual clients.

A significant advantage of the Meru approach is that the aggregate (that is, total) effective bandwidth does not degrade when user density increases.

The Meru solution is fully Wi-Fi compliant and NO changes are required for client devices.



Number of Contenders (Devices in interference range)

20

Tota

l Ban

dwid

th a

t Pea

k (M

bps)

5

8

11

1

3

Baseband + Protocol overhead

802.11b Peak Aggregate Throughput in Single Cell Environment

Ordinary APPerformance

• Aggregate effective bandwidth does not degrade when user density increases.

• The overall number of active users an AP can support increases 5X as compared to other WLAN solutions.

ContentionLoss

Active Users Per AP

Ordinary Meru

10-20

100+

5X5X

Meru AP Performance

RegainedThroughput



What a Meru Controller Does

A controller manges contention between APs, especially when they are used as a Virtual Call.

Controllers maintain a view not only of the total available bandwidth, but of each client’s needs and how heavily each AP is loaded. When needed, the controller shifts a station’s association to another AP where it can get better bandwidth.

The controller creates virtual tunnels to each AP, freeing them of the constraints of being connected to physical VLANs. One consequence is that VLANs are *only* configured on the controller’s Ethernet port. Meru APs don't deal with VLAN tagging at all - they don't need to.

A Meru AP (in L3 mode) need not be concerned about the wired network at it's own Ethernet port, as long as it can contact the controller and build the tunnel back to it. This eliminates the arduous task of having to specially configure the wired network ports where APs plug in.


What a Meru Controller Does

Manages AP contention Coordinates across APs

Controls client association

Enforces global policies for APs Security Quality of Service (QoS)

Segregates wireless communication Supports dotQ tagging



Multiple AP Effects

These pretty circles seem to show RF magically stopping at the edge of the circle. Nothing could be further from the truth. RF will propagate forever and follow the inverse-square rule unless further impeded by various materials like walls and floors. Any remaining signal above the noise floor is co-channel interference.

In “ordinary” wireless networks, the result of the overlap in signal is co-channel interference and greatly reduced throughput. In a Meru network, it merely results in more/better coverage.

When multiple stations are attempting to broadcast at the same time, recovering from collisions can eat up a majority of the bandwidth.

What’s clearly needed here is a way to avoid the contention problem.

Microcells cannot solve the problem because lowering the transmit power on an AP will force you to place them closer together and the net effect is identical to operating at full power and further apart. (The “power curve” does not change its shape.)


Single Channel Eliminates Co-Channel Interference

All APs operate on the same channel, yet interference is virtually eliminated

Throughput is massively increased

Extremely high density coverage can be achieved by using multiple layered channels.

111

6

611

6

111

6

1

11

11

1111

1111

1111

1111



Another factor not usually mentioned by the microcell proponents is that just because you lowered the transmit power of the AP, the clients are probably still transmitting at full power and the resulting co-channel interference can actually be worse!

It sells more APs, though.



802.11n Planning

Unlike the doughnut shape of the typical 802.11a/b/g AP, coverage from an 802.11n AP more resembles a porcupine.


802.11n Coverage and High Data RatesCan Fluctuate

11a/b/g: Coverage Doughnut-like

11n: Coverage Porcupine-like

Illustrative



802.11n Coverage is Unpredictable

In an 802.11n network, receivers are able to decode weak and distorted signals, so co-channel interference is significantly enhanced with 802.11n. This means that though range increases, so does the interference region.

While range is improved, predictable coverage plans are significantly harder to construct using predictive models, because range improvement leverages multipath, which is highly time and location sensitive and (even more than attenuation) is almost impossible to predict accurately using pre-populated maps.

It is important to note that the inability to predict 802.11n coverage is a universal phenomenon. It impacts “ordinary” wireless vendors in the same way it does Meru. However, due to Meru's single-channel deployment model, fixing coverage problems with 802.11n is a very simple affair: simply add APs as necessary.

The “ordinary” wireless deployments are going to have a very difficult time doing channel planning due to the irregular signal propagation characteristics of 802.11n.


Typical Coverage Pattern for 802.11n Rate/Range is Unpredictable

Highrate

Lowrate

Deployment Considerations

Coverage in 802.11n at higher data rates is unpredictable due to multipath

Higher co-channel interference; coordinated APs needed to mitigate these effects

Predictive tools cannot be effective; Lack of good planning tools for 802.11n is a deterrent to deploying using micro cell architecture

Meru allows you to easily add APs during deployment without having to rebalance channel layouts

Sample coverage from an installation



Indeed, when operating in the 2.4 range, 802.11n can require a much broader allocation of the spectrum than 802.11b or 802.11g, consuming either channel 1 & 6, or 6 & 11. This means that “ordinary” wireless vendors can either do b/g or n at 2.4, but not both. Meru can do both at 2.4 using the remaining channel for b/g.


Predictable Airtime Access


Reliability

The illustration shows (numbered) device access to the channel (both stations and AP) as a function of time. Note that in an ordinary network channel access is unpredictable - thus there cannot be over-the-air QoS. Also note that in an ordinary network, the AP is contending for air time along with the stations. In a Meru network the AP is guaranteed enough airtime to service all the clients.

802.11e ia an upcoming standard for QoS; it will be supported by Meru. However, while 802.11e allows clients to be more aggressive while fighting for airtime, it does so by using a method which is not scalable beyond four client nodes in any given airspace. Also, it is not actually providing anything resembling true QoS, it just allows client nodes to become airtime hogs and will potentially have the adverse side effect of *reducing* the aggregate bandwidth available to clients when the client density exceeds four clients. This is due to the certainty of a substantial increase in collisions.



Sta

tion

I D

• Predictable channel access, latency, jitter

• AP gets a greater amount of channel access

5.56

AP

5

3

7

9

11

5.36 5.38 5.4 5.44 5.46 5.48 5.5 5.52 5.545.42

Channel Access with Meru AP for QoS

Time (Sec)

Near-Deterministic Channel Access

11

9

7

5

3

5.46 5.48 5.5 5.52 5.54 5.56Time (Sec)

• Unpredictable channel access, latency, jitter

• AP gets the same share of channel as one of the clients

Free-for-all

Channel Access with Today’s 802.11 APChannel Access with Today’s 802.11 AP

AP

5

3

7

9

11

5.36 5.38 5.4 5.445.42

Sta

tion

I D



Meru's Over the Air QoS is true QoS and is enterprise-scalable. It provides true isochronous access to wireless clients and eliminates the jitter introduced by “ordinary” wireless networks.



Density

Meru is the only wireless vendor today providing over-the-air QoS both from the AP to the client and from the client to the AP.

Most other wireless vendors only provide QoS on the wired Ethernet port when a packet reaches the AP. They do not provide the foundation to support predictable service over the air to minimize latency and jitter (as depicted previously).

Over-the-air QoS is a key requirement in supporting latency and jitter sensitive applications such as video and voice over wireless LANs.

Meru’s over-the-air QoS allows for prioritization based on client as well as applications and can be applied per-application, per-user, per-system or per-flow.

Over-the-air QoS functionality and application flow detection is automatically enabled within Meru’s wireless solutions.


Today’s APProprietary Client

Typically data and voice on separate channels/network

Today’s APStandard Client

7-10< 5

AP

No over-the-air

QoS Wired QoS

Over-the-Air Quality of Service

Meru APStandard Client

Dynamic mix of voiceand data on same channels

20+

4X4X 4X Voice Calls Per Access Point

Wired QoS

Over-the-air QoS

Meru AP



Advantages of a Meru Network

Additional advantages of a Meru network are ease of deployment and ease of administration.

Unlike the “fat AP” model, there is very little persistent configuration in a Meru AP. This is a good thing, as it allows you to reconfigure your network easily, on an as-needed basis.


More Advantages of a Meru Network

Ease of Deployment Minimal RF planning: Plan for coverage, not for

co-channel interference Need more coverage or more total bandwidth?

Add more APs. Need even more? Add layered channels.

Ease of Administration Global control of security policies, automatically

posted to APs

Clients are automatically associated with the optimal AP


Meru Virtual Cell Roaming


Recall how roaming works in an “ordinary” network.

In a Virtual Call, each AP reports the same BSSID to the stations. When a station moves...


Wired LAN (Ethernet)

Channel 6 Channel 6

Meru Roaming – Shared Virtual Cell

APs 1 and 2 are in a Virtual Cell (they report the same BSSID) Station A is associated with AP 1 and moves toward AP 2.

Station A



...the moving station does not see a different BSSID with which to associate as it moves, it just notices a change in signal strength.

There's no “greener grass” for the station to find.

In ordinary wireless networks, roaming times can range from 50ms to 2000ms. Meru APs transparently handoff in ~4ms. The clients are unaware that handoff has happened.

Recall that the Meru controller is tracking the signal quality from all APs that can hear the station and it (the controller) makes the determination to reassociate the station to a different AP based not only on signal strength but also the resource requirements and loads on the neighboring APs.

Because the station does not have to take the time to de- then re-associate, the handoff time is essentially zero (~4 msec vs. 50 msec).



Channel 6 Channel 6

Meru Roaming – Shared Virtual Cell

As Station A moves, its signal strength changes, but it does notsee a different BSSID, so it doesn’t dissociate.

The Meru controller decides which AP will service which clients;it adjusts based on resource requirements and load balance.

Station A


The Four (No-Longer) Problems


How does Meru handle contention for airtime, a shared medium?

How does Meru handle mixed b and g clients?

How does Meru handle cochannel interference?

How does Meru handle problems arising when clients control association?


The Four No-Longer Problems of Ordinary Wireless Networks


Mixed b/g clients




Module 2Getting Started: Initial Setup

To begin our investigations, we’ll start by configuring the controller.



Set up a controller

Activate the Inference Engines

Configure users

Upgrade the system software

Add a license (optional)

Tools

The tools you’ll use in this section include:

Meru Web interface

Meru CLI References

Getting Started: Initial Setup 21

Initial Connection to the Controller


The initial installation requires the serial cable, which is not shipped with the controller.

The controller's serial port is a DTE device, the same as on a PC.

The bit rate of the serial port is not configurable.


Connecting to the Controller

Serial connectivity required for initial configuration Null-modem serial cable with DB9 (MC500, 1000,

3000, 4100) or RJ-45 (MC5000) connector

115200 bps, 8 bits, no parity, 1 stop bit, no flow control

Have Ethernet link established before powering up controller



setup Command

The setup command is a simple way to initialize, or re-initialize, a controller. With it, you set enough parameters to be able to use the Web interface.

A best-practice for all networking gear is to statically assign an IP address.

In a multi-controller production environment, it is a good idea to utilize NTP, although we won't be doing that in the labs. Timestamps in the event logs can then be easily reconciled across controllers.

SSH2 is the current standard for communicating with the controller. Telnet access is available, though disabled by default.


setup script

Simple way to set basic controller parameters Hostname Admin password IP address

- Static vs. DHCP

TimezoneThen, administration can

be performed through: SSH Web (using https)

Set controller index



Activating the Inference Engines

To enable the inference engines, you will turn them on right after running setup. You will already have used these engines previously, and we will discuss the purpose of these engines in the troubleshooting section.


Activating the Inference Engines

The diag-log command configures logging

admin [ station | controller | ap ] [ on | off ]

Turns logging on or off



Turning Off the Controller

The controller software writes its memory content only occasionally, so just turning the power off without this command risks file corruption.


Turning Off the Controller

Issue the command:poweroffcontroller Unmounts files

gracefully

After System halted/Power down message appears on console, turn the power switch off.



Default Login Accounts

During an actual installation the admin password should be changed. However, during this course do *not* change the admin password.

You can reset the password of a controller during startup.

1. Watch for the message “Accepting reset requests”.

2. When message is displayed, type reset.

The controller will be set back to default its values.

Note: Typing the reset command must be done before the controller displays “No longer accepting reset requests” during its boot sequence.


Admin Users

Default Admin Login Account Username –admin

Password – admin- setup script

suggests change from default



Adding Users

If you’re going to have multiple people running the system, it’s a good idea to have individual user accounts.

The Java applet used for User Management requires Java version 1.6.1 or later.

There is a CLI command, guest-user, that duplicates the functionality of this screen.


Adding Groups and Users

Add Group first Add Group ID Add Group Number Set permissions at

group level- Java applet may

require additional permission

Add Users Set User ID Set password Select Group ID


Upgrading the System


Upgrading System Software


Upgrading the System Software

Backup the configuration Copy the flash image to the controller Verify the date setting on the controllerUse the upgrade system command

This command reboots the controller after the upgrade is complete

Use the downgrade system command to revert

For installations with more than 30 APs Turn off auto AP upgrade featureUse the upgrade controller command



Upgrading Access Points

A new feature in Release 3.0 allows you to preserve the configuration parameters, such as location information, of individual APs.

Colons are used as the delimiter when entering the MAC addresses.

On the AP itself, the MAC address is included as part of the serial number.


Upgrading APs

Use upgrade ap same range | all range is a list of one or more AP indexes,

separated by commas and dashes, in ascending order

Upgrade APs about 30 at a time

This command reboots the APs after the upgrade



Importing a License File

Licenses are required to use more than five APs. Licensing limits are based on the number of live APs on the network.

Also, various added capabilities are controlled by licenses. Some of these are:

Air Firewall

Call Admission Control

Policy Enforcement Module


Uploading a License File

Have license file ready on ftp server (or scp, tftp)

Maintenance button Select Controller

Type Upload license file

(locate through navigation)

Import License button


Deploying APs

Deploying APs

General tab

AP Name - by encoding location information into the AP name, you will have a better idea of where clients are connecting when you look at station tables.

Location/Building/Floor/Contact

LED mode (normal/nodeID/blink)

Wireless Interfaces tab

Channel (varies with band)

Short Preamble enabled (on/off)

RF Band selection (a/b/g/bg/bgn/agn)

AP mode (AP 200/300 series only; normal/scanning)

These parameters also available through Wireless Interface configuration


Deploy APs

Add location information Name AP using location

Select channel and virtualization Bulk update

Select connectivity


Deploying APs

Configuring Controller Discovery

When multiple controllers are deployed on an L2 subnet and a new AP is added, we can’t predict which AP that controller will associate to. By using AP redirection, you can add more predictability to your networks. We can specify AP redirection either by specifying each AP’s MAC address, or by specifying a subnet on which all APs will be redirected to a specific controller.

An alternative in an L3 network is to configure the APs themselves to define which controller they will discover first. This can be done in three ways:

Using AP redirection

Specifying on each AP the controller IP address to which it should connect

Specifying on each AP the controller DNS name to which it should connect

The full discovery process is described in the section “Controller Discovery Process” on page 189.


Configuring APs for Controller Discovery

L2/L3: Use AP Redirect APs can be

“assigned” to a specific controller

L3: Configure APs for L3 discovery while on L2 subnet IP address, or DNS name

(wlan-controller)


Saving Your Work

Saving Your Work

Current operational parameters are stored in the flash file running-config.

Boot-up parameters stored in the read-only file startup-config. Constantly updating the startup-config may not be a good idea.

Changes to the running-config file must be stored to be persistent across reboots.

To determine the difference between the running-config and the startup-config, copy both files off-box and use a text utility such as diff on unix systems or Macs. Some high-end text editors used by professional programmers have this feature built in as well.


Saving Your Work

Current operational parameters are stored in running-config

Boot-up parameters are viewable in startup-config

Changes to the running-config file must be saved to be persistent across rebooting Use copy command Use Save link


Saving Your Work

Backing up Controller Configuration Files

The copy command uses the named protocols as part of the filename specification, we’ll see how in the lab. The copy command does more than just copy, for example, if you’re copying a system image to the controller, it decompresses the file.

The copy command uses the familiar “copy <source> <destination>” syntax and supports using a URI as either the <source> or <destination>.


Backing Up Controller Configurations

copy running-config ftp://[email protected]/file.cg

Use the CLI Copy to local

(controller) file

Copy to remote (client) file through ftp or scpprotocols with copycommand


Saving Your Work

Restoring Controller Configuration Files

Notice that copies of the startup-config file are scripts containing valid CLI commands.


Restoring Controller Configurations

copy ftp://[email protected]/file.cg running-config

Use the CLI Copy from remote

file to running-config with copycommand

Save changes when asked (part of the reload command)


Saving Your Work

Rebooting

You won’t usually have to use these commands.

The setup command must be run after a reload default. The controller's host information is not stored in the config files in order so that they can be ported across controllers.


Rebooting

Reboot Controller reload controller

Reboot AP reload ap [n]

Restore defaults Used only in the rare case of corrupted startup-config files.

reload default


Lab Preview

Lab Preview


Lab Preview

Lab instructionsLab handouts

Not a list of tasks, but support for the instructions in your books.

Enter parameters in bold type, skip ones in light type

Lab Checklists


Lab Exercises

Lab Exercises

In this lab exercise, you will:

Setup your system

— setup

— controller index


Set up an additional group and user

Upgrade your software

Set up AP parameters

Backup your system

— locally

— remotely

Use the settings specified on your Getting Started configuration sheet.

Perform an Initial Setup

In this first section you’ll provide initial configuration information to your controller.

1. Set up a serial connection from your laptop to the controller. For the initial Controller configuration, you must connect to the controller using the controller’s serial port and a null modem serial cable.

2. On the laptop, set up a terminal session with the following settings:

— 115200 baud

— 8 bits

— no parity

— 1 stop bit

The terminal emulator must be ANSI or VT100 compatible.

3. Log in as admin using the default password:

default login: admin

Caution!Only one serial connection is supported at a time. Making multiple serial connections causes signalling conflicts, resulting in damage or loss of data.


Lab Exercises

Password: admin

Run the setup command

4. Run the initial configuration script using the command:

default# setup

5. Use your Lab Configuration Form to obtain the information for your controller:

Note: It is important that the IP address be set according to your configuration form; proper operation of routing within the lab environment depends on it.

Country code: [see your configuration sheet]hostname: [see your configuration sheet] Change admin password: no Change guest password: no configure networking: yes use DHCP? [see your configuration sheet] IP address: [see your configuration sheet] netmask: [see your configuration sheet] default gateway: [see your configuration sheet] configure a Domain Name Server? [see your configuration sheet] configure Controller Index: [see your configuration sheet] configure timezone: [see your configuration sheet] synchronize time with NTP:? [see your configuration sheet]

6. Reboot your system when prompted.

7. When the reboot is complete, log back into your controller using your serial connection.


To enable the system to make inferences about failure events, you’ll activate logging for each of the Inference Engines and send the inference information to both the station log and the syslog system.

1. Log back into your controller using the default admin credentials. You can use the serial connection or an ssh connection.

2. Enter the configure terminal command in the terminal window.

3. Enter the diag-log command at the config prompt.


Lab Exercises

4. Enter the following commands:

name(diag-log-config)# admin controller on name(diag-log-config)# admin ap on name(diag-log-config)# admin station on name(diag-log-config)# exit

5. Enter the station-log command at the config prompt.

6. Enter the following commands:

name(config-station-log)# filelog on name(config-station-log)# syslog on name(config-station-log)# end

Upgrade System Software

In this section you’ll upgrade the controller’s software version, much the way you will in the field. You’ll start by ftping an image file to your controller. If your system does not have an ftp server, you can use freeware like the 3CServer/3CDaemon software to add one. If you’re using your own ftp software to connect, make sure you have setup anonymous access.

Note: Your Instructor will tell you the location from which you can ftp a software image. This may be listed on your configuration sheet.

Download New Controller Software

1. Enter the following command to make sure you’re in the correct part of the directory structure:

name# cd images

2. Verify the current software image(s) with the command:

name# show flash 3.6.1-xxx

The available images are displayed.

Note: Make sure there is only one image in the flash; otherwise you may run out of space when trying to upload the new version.

Warning! If two people are working on one controller, only one person should download and install the new software at a time. If time permits, both members of a pair can re-install the new software.


Lab Exercises

3. Locate the image file for your controller using a command similar to:

name# dir ftp://anonymous@clientIPaddress/

Typically, you will use the ftp software already installed on your system.

Note: It’s hard to see, but there’s a period ( . ) at the end of the following command.

4. Copy an image file to your controller using a command similar to:

name# copy ftp://anonymous@clientIPaddress/imagefile .

You will need to enter an appropriate username and password for the ftp server.

Install New Controller Software

5. Verify the new software version with the command:

name# show flash 3.6.1-xxx

The available images are displayed.

6. Upgrade your software using a command similar to:

name# upgrade system new_system_version

7. Confirm that you want to overwrite all system images.

You will see an upgrade progress display, first for APs then the controller itself.

8. Confirm that you want to overwrite all system images.

9. When the controller reboots, confirm that you are using a new software version.

Note: If an AP was skipped, perhaps because it was unplugged, the AP can be upgraded separately from the system. To upgrade all APs to the same software version as the controller, use the command:

name# upgrade ap same all

Start the Web User Interface

In this section, you’ll verify the correct settings of your controller by connecting through the web interface and an ssh session.

1. Configure your laptop for IP access to your subnet.


Lab Exercises

2. Confirm that you can receive and transmit information by using your browser to connect to the controller’s web interface

a. If you have the equipment in front of you, use the address: http://controllerIPaddress

b. If you are using a Remote Lab, the address will already have been provided to you.

3. Accept any security alerts that arise.

4. Enter the default administrator names and password, then click the OK button.

5. Accept the display of nonsecure items, if asked.

Display the Controller Configuration

1. By default, the page that loads is the Controller Dashboard display. General controller statistics can be observed from this page, including a list of Access Points (APs) and associated stations.

Adding Administrative Groups and Users

In this section you’ll add an administrative user.

1. Click on the Configuration button in the left navigation bar.

2. Click on the Web Users link under the User Management heading in the left navigation bar (near the bottom of the bar; you may need to scroll down to see it)

3. Answer Yes (or Run) to any security warnings that appear.

4. Log into the applet, if required. Use the admin credentials.

5. Click on the Group Management tab near the top of the screen.

6. Click on the Add... button near the bottom of the screen.

A dialog box appears that will allow you to set permission levels.

7. Enter the Group ID parameter from your configuration sheet.

8. Enter the Group Number parameter from your configuration sheet.

9. Select the options to give the group full monitoring capabilities, but no configuration, maintenance or other capabilities.

10. Click on the Apply button near the bottom of the dialog box.


Lab Exercises

11. Click on the OK button in the confirmation dialog box.

12. Click on the User Management tab near the top of the screen.

13. Click on the Add... button near the bottom of the screen.

A dialog box appears that will allow you to add users to the group.

14. Enter the User ID parameter from your configuration sheet.

15. Enter the User Password parameter from your configuration sheet (twice).

16. Select the Group ID parameter from your configuration sheet.

17. Click on the Apply button near the bottom of the dialog box.

18. Click on the OK button in the confirmation dialog box.

Preserve Configuration Changes

Preserve Configuration Changes (using the Web interface)

Click on the Save button at the top of the Web interface screen to save your changes to the startup-config file so they will be persistent through reboots.

Preserve Configuration Changes (using the CLI)

1. Connect to the CLI.

2. Save your configuration changes with the command:

name# copy running-config startup-config

Back Up the Controller Configuration File

To back up your configuration file, you can copy it to another file on the controller. You must do this through the CLI; you can use the following procedure.

Note: You can also back up your configuration file to a remote system using ftp or scp; see the section “Back Up the Controller Configuration File to a Remote System” on page 46 for instructions.



Lab Exercises

2. Back up your configuration changes with a command similar to:

name# copy running-config backupFileName

Refer to your configuration information form for the appropriate file name to use.

Connect to the Command Line Interface

1. Open an SSH connection to the controller. Your can use a freeware SSH program such as PuTTY if you need one.

2. Log in using the default administrator username (admin) and password (admin).

Display the Controller Configuration

3. Enter the show controller command to verify your connection to the controller interface. The controller configuration is displayed. (You may need to press the space bar to see the next page of the display.)

Scan the display for your controller’s software version and write it here: ______________________________________

This command provides the quickest way to check your controller’s status.

4. Enter the show ap command to verify your connection to at least one AP. A list of access points that have discovered this controller is displayed. The operational state of each AP is listed.

Adjust AP Parameters (CLI)

Adjust Radio Channel

5. Enter the configure terminal command in the SSH terminal window.

Notice how the prompt changes.

6. Locate the wireless interface configuration information for a specific AP ID by entering this command:

name(config)# do show interfaces Dot11Radio

7. Enter the AP’s wireless interface configuration mode for a specific AP ID by entering a command similar to:

name(config)# interface Dot11Radio APid ifIndex


Lab Exercises

8. Press the TAB key to display the commands available in this mode.

9. Change the channel to 1 (one) by entering this command:

name(config-if-802)# channel channelNumber

10. Enter the end command save your changes and return to the exec mode.

Note: Changing the channel of an AP to which you are connected will terminate your connection to that network. You will need to restart any SSH sessions and refresh browser windows that were using that connection.

Adjust AP Parameters (WebUI)

Adjust AP Operation

1. Bring the browser showing the Web interface to the front.

2. Click on the Configuration button near the top left of the page, if it is not already selected.

3. Click on the APs hyperlink under the Devices heading in the left column.

4. Click on the settings arrow to the left of the listing for the AP you want to modify (try the first AP).

The AP Table opens in Update mode.

5. Add some text in the AP Name text box such as “West Wing Hallway 3”.

6. Add some text in the Location text box.

7. Click on the OK button.

The information is written to the AP; its status light begins blinking.

Adjust Radio Channel on Multiple APs

8. Click on the Radio hyperlink under the Wireless heading in the left column.

9. Select all the Wireless Interfaces in the 2.4 GHz (bg) band.

10. Click on the Bulk Update button near the bottom right of the window.

11. Click on the Channel checkbox.

12. Enter the number channelNumber (from your configuration sheet) in the text box to the right of the Channel checkbox.

13. Click on the OK button at the bottom of the table.


Lab Exercises

The APs reboot, then returns to normal operation. All the selected bg wireless interfaces should now be on your selected channel.

Note: Changing the channel of an AP to which you are connected will terminate your connection to that network. You will need to restart any SSH sessions and refresh browser windows that were using that connection.

Back Up the Controller Configuration File to a Remote System

To back up your configuration file, copy it to a system other than the Controller. You can do this using ftp or scp by following this procedure.

Note: You will need to have an ftp server running before you attempt this procedure.

1. Determine the IP address of your client station. Write it here: _______________

This is the value you will use in the ftpServer variable below.



name# copy running-config ftp://username@ftpServer/remoteFileName

For this exercise, you can use the username “anonymous” with no password.

Check: Have your instructor check off your progress at this point.


Module 3Build a Test Network

In this module you’ll build a test network. A test network has only the simplest of configurations, for example, no authentication. You’ll usually use these kinds of networks only for troubleshooting.


Create a security profile

Create an ESS (wireless subnet)

Connect wireless clients

Restore a controller configuration

Tools


Meru Web interface

Meru CLI References

Build a Test Network 47

ESSIDs

ESSIDs

Most of the components of an ESSID can (but are not required to) be used in multiple ESSes: The Security Profile, the RADIUS profile, and the VLAN settings.

The configuration objects in a Meru system are modular and re-usable. This makes for cleaner configurations and simpler administration. For example, you can create a single WPAPSK security profile which can be used by multiple ESS profiles. If a change to the security settings needs to be made, it is done only in one location. This can reduce the likelihood of introducing errors in the configuration.

Before you can create an ESSID, a security profile needs to exist first. If you will be using the optional profiles, the a VLAN and the RADIUS profile also need to be created before creating the ESSID.

By default, there is a security profile already created on the controller.


ESSIDs

ESSID stands for Extended Service Set IDentifier Network name

There are four main components to an ESSID An ESSID name A security profile A RADIUS profile

(optional) A VLAN (optional)


ESSIDs

Virtual Cell Types

There are two forms of virtual cell in the Meru system; these are selected on a per-ESSID basis. The first, shared BSSID, distributes a single BSSID across the entire set of APs. The second, VIrtual Port (labeled per-station in the interfaces), creates a unique BSSID for each station. This provides a more switch-like behavior.


Virtualization Level

Virtual Cell All APs have same BSSID

Virtual Port Each client sees a unique

BSSID

System controls which AP broadcasts the unique BSSID

ESS setting and AP Radio setting must match

AP300

AP200

AP150

VPVC


Security Profiles

Security Profiles

There can be multiple ESSes, each with its own security profile running on a single AP.

Also, a single Security Profile can be shared by multiple ESS Profiles.

When first powering on the controller, there is a single default security profile that is defined. It allows “clear” (that is, unauthenticated) Layer 2 access with no encryption or cipher suite.


Security Profiles

A list of parameters that define how traffic is handled within an ESS

Can define different layer 2 security methods, cipher suites, and other parameters.

Supports multiple authentication and encryption methods within the same WLAN infrastructure

Supports the ability to define multiple security profiles that can be assigned to different wireless LAN ESSes


Security Profiles

Wireless Authentication Methods

Different wireless networks have different security needs. Differing levels of authentication and encryption work to meet the required security.

When there is no authentication used, this is also said to be “clear”.

WEP - Wired Equivalence Protocol (too insecure for data; fundamentally flawed, but okay for use with isolated voice networks.)

WPA, WPA2 - WiFi Protected Access. We’ll discuss the difference between WPA and WPA2 in a later module.

One constraint is that there can’t be multiple authentication methods on a single ESS.



None (“clear”)Controller authenticates

WEP MAC address filtering

- System-wide ACL; enabled on a per-ESS basis

WPA-PSK, WPA2-PSK (WPA Personal)

Third-party (e.g. RADIUS) authenticates WPA, WPA2 802.1x

- Username/password- MAC address


Security Profiles

Creating an ESSID

The process for creating an ESSID using the command line is covered in the hands-on portion of this module.

While there may seem to be many points of configuration in an ESS Profile, only one is required; the name of the ESS.

It is usually a good idea to take default values for configuration elements unless you know that you want to change them - and especially if you aren't sure what they do.


Creating an ESSID

Configuration Button

ESS hyperlink Add button

Enter the ESSID name and click the “OK”button


VLANs

VLANs

What advantages are there to using a VLAN to segregate wireless clients? Typically, you'll want to use a VLAN to segregate out access to wired-side resources. (This is much the same reason that you use VLANs on wired networks.)


VLANs

You can create a one-to-one mapping of ESSID to VLAN or map multiple ESSIDs to one VLAN.

VLANs allow you to support multiple independent wireless networks on a single access point.

You can create up to 512 VLANs for the WLAN system.

Can be assigned dynamically through a RADIUS server


VLANs

Configuring VLANs

The key thing to remember is that only the controller needs to have its Ethernet port capable of receiving (dotQ) tagged packets from each subnet.

To restate: the controller has to be on a trunk port; and it needs to be on a port tagged with all the dotQ tags to be used in the wireless LAN.

All the AP’s Ethernet connections need to be on untagged ports.

The tags defined in the VLANs on the controller must match the tags used by the switches and routers in the wired network.

The controller builds its own tunnel to each AP, so the controller essentially strips off the VLAN tags and sends the packets to the correct AP as though the packets were still tagged.


VLAN Virtual Interface

Before DHCP assignment

After DHCP assignment


VLANs

ESS Table

This table defines which ESSes are broadcast by the AP.

This is one of the two places in the interface where you adjust which ESSes are broadcast on which AP. In this case, you’re adjusting on an AP-by-AP basis. If you go through the ESS configuration interface, you can adjust multiple APs at the same time.


Configuring WVLANs at the Switch


Lab Preview

Lab Preview


Configuring ESS Distribution Across APs

ESS-AP Table ESS Profile configuration (shown)

AP configuration


Lab Exercises

Lab Exercises


Create a security profile

Create an ESS (wireless subnet)

Connect wireless clients

Restore a controller configuration

Use the settings specified on your Test Network configuration sheet.

Create an ESS (WebUI)

1. Click on the Configuration button near the top left corner of the Web interface page.

Create a Security Profile (WebUI)

2. Click on the Profile link under the Security heading in the left navigation bar.

3. Click on the Add button near the bottom of the screen.

4. Consult your configuration information form and use the parameters on it to enter the parameters of the test security profile.

Note: If your configuration form does not specify a particular parameter, use the default setting.

5. Click the OK button near the right bottom corner of the display. After a moment, your new security profile is added to the table of existing profile.

Create an ESSID (WebUI)

6. If the Configuration hyperlinks aren’t showing in the column at the left edge of the page, click on the Configuration button near the top left corner of the display.

7. Click on the ESS hyperlink, under the Wireless heading in the left column.

8. Click on the Add button.


Lab Exercises

9. Consult your configuration information form and use the parameters on it to enter the parameters of the test ESS.

10. Click on the OK button. Your new ESS is added to the table of existing ESSes.

Verify Client (Station) Connectivity

1. If your station’s wireless capabilities aren’t already configured, insert the wireless receiver card into your station. The operating system may respond noting that it has discovered new hardware.

2. Scan the available networks and select the test ESS that you just created.

3. Verify that your wireless interface has been assigned an IP address. (Use the ipconfig /all command from a Windows command line.)

4. Click on the Monitor button near the top left corner of the display.

5. Verify that there is at least one station in the “Stations” graphs.

Create a VLAN Profile

Create a VLAN Profile (WebUI)

1. Click on the Configuration button near the top left of the page, if it is not already selected.

2. Click on the VLAN hyperlink under the Wired heading in the left column.

3. Click on the Add button.

4. Consult your configuration sheet and use the parameters on it to enter the second VLAN on your configuration sheet.

5. Click on the OK button. After a moment, your new VLAN is added to the table of existing VLANs.

Save and Backup your Configuration

6. Click the Save button near the top right corner of the WLAN Management page to save your changes to the startup-config file.

7. Click on the OK button on the dialog box that appears.


Lab Exercises

After a moment, the “Configuration has been Saved!” status message briefly appears, then you are returned to the ESS Profile table.


name# copy running-config backupFileName

Use the backup file name you used in the previous module.

Restore a Controller Configuration

1. Backup your controller configuration using the Save hyperlink at the top right corner of the Web interface.

2. Remove your test ESS with commands similar to:

name# configure terminal name(config)# no essid test name(config)# endname# copy running-config startup-configname# reload controller

Refer to your configuration information form for the name of the test ESS to remove.

3. Confirm that you want to restart the system.

4. Copy the backed-up configuration file to the running configuration with the command:

name# copy backupFileName running-config name# reload controller

Refer to your configuration information form for the appropriate file name to use.

Note: You may get an error message starting “One or more commands...”. These can be safely ignored.

5. Agree to save to the startup configuration.

6. Verify that all your ESSIDs have been reestablished.

Check: Have your instructor observe your progress after your system has rebooted.



Lab Exercises


Module 4Installation Pre-Planning

To make an installation go as smoothly as possible, you can obtain information about the network prior to arriving on site and pre-plan how you’ll integrate into the current network.


Describe factors to be considered prior to installation

Estimate correct positioning of APs

Tools


Floor plan drawings

Installation Pre-Planning 61

Site Characterization


Site surveys are a critical component of a successful installation. Without knowing what you are getting into, it will be impossible to set the expectations for the installation, let alone meet them.

Installing a wireless system is an excellent ways to uncover problems that already exist in a network, but are masked by overperforming equipment.



Identify network layout/topologyDraw network topology mapIdentify security policies in useIdentify desired security policiesIdentify required data rates – including

density requirements Does everyone *really* need 54MB/sec? Or 300?

Obtain floor plansPlan AP placementDesign WLAN and integrate with existing

network


Site Report Forms

Site Report Forms

These forms, and there are blank copies of the spreadsheet in your class materials, are designed to collect the basic information you’ll need to install the Meru system.


Site Report Forms

Assist you in collecting the information you (and Tech Support) will need.

Provided in spreadsheet format


Wireless Spectrum Scanning

Wireless Spectrum Scanning

Your deployments will go much smoother if you take just a little time to walkabout and scan the wireless spectrum. This will help you choose an optimum channel to use.

There are spectrum scanning tools available in several different price ranges.


Scan the Wireless Spectrum

Identify strongest channel(s)

Tools: Wi-Spy - $

Cognio - $$$ Fluke - $$$$


AP Range

AP Range

Without interference, the range of a single AP is quite large. However, recall that interference can have profound effects. We’ll look at some of these effects in the next few slides.

This plot was created with the Ekahau Site Survey tool.


AP Range

Data rate is a function of distance

Plot is for 100mW ERP (default), 2.4GHz band, free space

Scale is ~10m grid


AP Range

AP Placement Simulation

Floor Plan

For the purposes of illustration, let’s look at a simulated deployment. This will let us show the effects of different pieces of the whole picture in a way we could never duplicate in the real-world.

We’ll start with the floor plan of a typical hotel.

Our goal is to plan sufficient AP coverage so that the lobby and meeting rooms have 54 Mbps coverage.


AP Range – SimulationFloor Plan

Take a typical floor plan


AP Range

AP Coverage

Here we’ve calibrated signal strength in terms of data rate.

As we’ve seen, the range of AP in free air is large, so three APs would provide full 54Mb coverage, were there no walls. But, there are…


AP Range – SimulationNo Walls


Add APs for coverage

Data Rate (in Mbps)


AP Range

Outer Walls

If we add in the effects of the outer walls only, we begin to see that outside the building the signals are mostly reduced in strength, but a person can still get a usable signal even though the outer walls.

For this simulation we’ve assumed concrete outer walls.


AP Range – SimulationOuter Walls



Note the effect of outer walls (only)

Data Rate (in Mbps)


AP Range

All Walls

When we add in the effects of internal walls, we see that the signals are reflected, refracted, and attenuated in not-real-predictable ways. This is why testing the coverage during a deployment is critically important. This simulation shows that we won’t get 54Mbps coverage in all the meeting rooms without additional APs.

There are still signals present outside the building; this reinforces whey having at least minimal security is required.

For this simulation we’ve assumed the internal walls are all dry wall construction and the elevator shafts are metal.


AP Range – SimulationFull Walls



Note the effect of outer walls (only)

With all walls, the signals are quite scattered

Data Rate (in Mbps)


Density Considerations


One of our considerations is how many users we can support per AP. Generally, providing sufficient coverage will also provide sufficient user density, but this needs to be validated during deployment.

There are spreadsheets that will help calculate coverage parameters. These will be covered in the VoIP module.

MOS - Mean Opinion Score.



AP150 Up to 100 simultaneous active data users per AP

AP201/208 Up to 128 simultaneous active data users per AP Up to 22 simultaneous toll-quality voice calls per

AP with MOS score of 4.3.

Use spreadsheets to calculate optimal calls per AP

AP300 Up to 256 simultaneous active data users per AP


Scan for Coverage

Scan for Coverage

Integration into the existing network can reveal borderline problems that already exist.

Make sure you can connect with the client card most popular at the deployment site, if they are known.

Because Meru APs require a wired Ethernet connection, they are not always the best choice of AP to use when you’re experimenting with APs placement to assure good coverage. Stand-alone APs, such as Netgear (WG602; US$80) or Belkin (F5D7130; US$80) can be used to establish coverage, then the Meru APs can be placed and the Ethernet connections made.


Scan for Coverage

Scanning Tools Ekahau Site Survey (passive)

NetStumbler (active)- Scan using multiple client cards

e.g. Cisco, D-Link, Linksys, Netgear, Orinoco

Coverage can be established using non-Meru APs e.g. Belkin, Linksys, Netgear


AP Placement Process


Here are some guidelines for what to expect from various building materials:



Map the layout where coverage is planned.Overlay a grid on the sketch, scaled for the kind

of environment. Grid spacing varies with maximum data rate

Survey for background radio signals; select an unused channel

Place the APs in the center of each grid square.Test (survey) for coverage.Iterate placement (add APs if needed) and test.

RF Barrier description: RF Barrier severity: Examples

Air Minimal

Wood Low partitions

Plaster Low inner walls

Synthetic material Low partitions

Asbestos Low ceilings

Glass Low windows

Water Medium damp wood, aquarium

Bricks Medium inner and outer walls

Marble Medium inner walls

Paper rolls High paper on a roll

Concrete High floors, outer walls

Metal Very high desks, metal partitions, re-enforced concrete



Sample AP Plan

This is a floor plan of the second floor of Meru’s old headquarters building. The red icons are the predicted placement. The green circles are the actual placement.

Note locations of possible interference

Solid walls (metal or concrete; not drywall)

Elevators

HVAC shafts

For a first approximation, overlay a grid on the sketch, scaled for the kind of environment

70ft by 70ft for open space

60ft by 60ft for open offices with cubicles

50ft by 50ft for brick/plaster offices


Sample AP Plan

60 ft.60 ft.


Deployment Best Practices


Here are some simple rules of thumb that can save you a lot of time.



Scan for RF interference firstSurvey areas where you anticipate

problemsConfigure AP location informationSurvey for coverage after deployment

With normal people and equipment in place and functioning

Especially for 11n



802.11n Deployments

Due to the wide bandwidth requirements of 802.11n, many vendors are suggesting that n deployments occur on the a band. Meru provides an excellent solution in the b/g (2.4 GHz) band.

Deployment of a high-speed wireless network may reveal stress problems with the existing backbone network.

The problems that ordinary wireless networks have with co-channel interference, clients associating with high-traffic APs, and “b” clients reducing the speed of the network to “b” speeds are all magnified with 802.11n.


802.11n Deployments

Use 20MHz channel(s) in 2.4GHz band, unless you need massive throughputAnticipate problems with backbone

network; it may not have been stressed before e.g. AP reboots due to lost keepalives


Integrate with Wired LAN

Integrate with Wired LAN

Part of the planning process is to figure out, in advance, how the wireless network will integrate with the current wired network. We’ll cover more on VLANs in the Basic module.

Meru Controllers tunnel all the packets to their APs, so the following UDP ports need to be open between them:

Data: 9393

Discovery: 9292

Control: 5000


Design WLAN and Integrate

What IP address ranges will wireless clients use?What wired VLAN(s) will the Controller

be a part of? Tag controller port(s) Do not tag APs ports


Ekahau Site Survey

Ekahau Site Survey

Ekahau’s Site Survey is an excellent tool for seeing what’s really happening at the site. It can help plan deployment by estimating where APs should be put to achieve the desired coverage; it’s also used during and after deployment to validate coverage.


Ekahau Site Survey

RF Coverage “Snapshot” Visualize

Coverage Capacity ESSID locations Network performance Signal to noise

Channel info

Represents Meru Virtual Cell info Valuable for:

Planning Validation

Optimization - combine surveyed data with planned data


Lab Exercises

Lab Exercises

In this exercise you will plan the placement of APs, given several sketches of deployments. Your goal is to place the APs for sufficient coverage, taking into account:

User density

The type of access needed (data and/or voice)

The office layout and any indicated interfering structures

Placing APs

In this exercise you will plan the placement of APs, given several sketches of deployments. Your goal is to place the APs for sufficient coverage, taking into account the user density, the type of access needed (data and/or voice), the office layout and any indicated interfering structures.


Lab Exercises

Exercise 1

Design the AP placement for a small company’s branch office. Assume that all offices will need wireless phone access. All areas except the Lunch Room will need wireless data access. The office walls are made of brick.

80 ft.


Lab Exercises

Exercise 2

Design the AP placement for this floor of a medium-sized software company. Plan for a total of 190 wireless computers. Each cubicle will have one computer with wireless access and there may be additional guest users in the conference rooms.

100 ft.

Load-bearing walls


Lab Exercises

Exercise 3

a) You have been asked to provision a nearby hotel. Layout the AP placement and explain why you chose the layout you did. Make sure there is provision for 300 simultaneous data users in the Grand Ballroom.

b) How would your design change if there were a maximum of 50 wireless users in the Grand Ballroom?

130 ft.

38 ft.


Lab Exercises


Module 5Build a Voice Network

Meru believes that VoIP is a technology whose time has come. Fortunately, Meru is uniquely prepared to face the peculiar challenges presented by VoIP thanks to it’s unique architecture. In this module you’ll configure a Meru network to perform over-the-air Quality of Service.


Construct a voice ESS

Make wireless phone calls

Examine Quality of Service (QoS) parameters

Distribute an ESS to a single AP

Build a Voice Network 83

Introduction to VoIP


The Meru solution provides the unique ability to perform over-the-air QoS that scales beyond the limits of 802.11e.

The Meru network knows to provision for QoS because, by default, it watches port traffic on port 5060 (SIP default) and 1720 (H.323 [e.g. NetMeeting] services) and has pre-configured settings for assigning priorities to each packet passing through these ports. (The port assignments can be changed.)



VoIP packets have different timing constraints than data packets.

This implies the need for Quality of Service (QoS) capabilities.

AP200s and AP300s are designed to provide these capabilities.

An AP200 or AP300 network automatically provisions appropriately for VoIP QoS. (By default, QoS is enabled.)

This QoS is customizable to accommodate any need, from voice to over-the-air video streaming.


SIP Overview

SIP Overview

Example VoIP Network

This shows the simplest of SIP networks, just to point out the elements that interact with the controller and APs.


Example VoIP Network

Meru Controller

PRI

WiFi Phone

Public Switched Telephone Network (PSTN)

SIP (Proxy) Server

SIP Gateway

Voice ESS


SIP Overview

Session Initiation Protocol (SIP) Description

SIP is a request-response protocol, not unlike http. Let’s examine a simple scenario where a Caller is trying to call a Callee.

First, the Caller sends an Invite request to the SIP proxy, asking it to locate the Callee’s address. (The Caller will have previously registered it’s own address information with the proxy.) Next, the proxy forwards that Invite to the Callee. The Callee responds to the proxy including any modifications is wants to make (For example, the Callee might not support all the features that the Caller is requesting). Finally, the session is created and the Caller and Callee can communicate directly.

There are several kinds of SIP proxies: stateless, stateful, and redirect, but for our class purposes we don’t need to know which is being used.


Session Initiation Protocol (SIP)

Message-based Requests Responses

Session-oriented Senders Receivers State

Utilizes UDP

21

4

Caller Callee

SIP Proxy

3


SIP Overview

Typical SIP Session

This is an example of transactions typical when using a stateless server.

The numbers are status numbers that are visible in a packet capture.

Notice that after the Caller acknowledges the Callee, the SIP Proxy gets out of the way and the Caller and Callee converse using a Real Time protocol (RTP).

When we are troubleshooting we will watch these transactions through captured packets.


Typical SIP Session

INVITE

100 Trying

INVITE

100 Trying

180 Ringing

180 Ringing

200 OK

200 OKACK

Caller SIP Proxy Callee

RTP Streams

Call Initiated

Call Answered

BYE

200 OK

Call Terminated


Over-the-Air Quality of Service (QoS)


One of the most powerful features of the Meru system is that the controller can select which AP is the best AP for connection to a station.


Over-the-Air QoS (AP200/AP300 only)

Controller selects the right AP for the destination packets based on signal strength and available bandwidthEach packet inspected and tagged with

QoS parameters based on the content




Call Admission control allows a “reasonable” behavior for virtualized connections when an AP is too busy to handle more calls. Generally, there are only two parameters we need to set:

Maximum Calls per AP

Maximum Stations per AP

There are two conditions: when you have a single-channel deployment or a multi-channel deployment. In the first case, we can issue a Network Busy signal. In the second case we can move the call to an alternate channel.



Allows a defined maximum number of active calls

Upon reaching limit, call can either be: Rejected with

Network Busy (similar to PSTN), or

Moved to alternate channel that has available resources.



Call Load Balancing

Call loads can be balanced across APs and across channels.

This approach balances data/voice devices within and across multi-channel deployments in dense networks.

Devices can be spread between channels using a “round-robin” assignment to ensure equal distribution.

Dynamically re-balance phones during call setup to achieve peak call density in an area (3X other vendors).

Where would this be useful? Imagine workers congregating in a break area or conference room and all place calls simultaneously.


Call Load Balancing

Channel 1 VirtualCell

Channel 6 VirtualCell

Example Settings:Max Stations per AP = 7Max Stations per VirtualCell = 10

AP1 AP2

AP3 AP4


Quality of Service

Quality of Service

When QoS is enabled (and by default it is enabled), as every packet comes into the controller, it is examined and a priority is assigned to it. This priority is written into the packet itself.

“Rules” define how priorities are assigned to individual packets.

Default rules are provided for SIP and H.323 traffic patterns (i.e. voice over WiFi can be enabled with no additional controller configuration required).


Quality of Service

Classifier examines this 5-tuple for each packet: Source IP, Destination IP, Source port,

Destination port, Protocol

and compares it with a set of QoS “rules”

Two priority schemes Defined priority

- Used for email, Oracle and other Enterprise apps- Levels 0 (best-effort) to 7

Reserved bandwidth- Used for voice, video. - Specified by Token Bucket Rate (bytes/sec) and

Average Packet Rate (packets/sec)


Quality of Service

QoS Actions

When a packet is examined, the controller will do one of three things with it: Drop (or discard) it, Forward it after applying a priority to it obtained from a static QoS rule, or Capture it for examination and then send it on after calculating a priority for it.

The packets, now carrying priority information, are forwarded to the appropriate AP (based on the packet’s destination), which examines the priority of the packet and places it in a queue for transmission. The highest priority queues are used for the packets with bandwidth reservations; here priority is based on the required bandwidth.

Dropping packets can be used to implement a firewall; we’ll see how that’s done later in the course.


QoS Actions

ClassifierIncomingpackets

Drop Forward/Capture

Examine Add priority tagOutgoingpackets


Quality of Service

QoS Rules

Non-SIP clients will need to have custom rules built for them; here are the WMM mappings with the DiffServ Codepoint settings to use:

WMM 0 = AC_BK - background (CS 0 - 1 dec or 000 - 001 bin)

WMM 1 = AC_BE - best effort (CS 2 - 3 dec or 010 - 011 bin)

WMM 2 = AC_VI - video (CS 4 - 5 dec or 100 - 101 bin)

WMM 3 = AC_VO - voice (CS 6 - 7 dec or 110 - 111 bin)


QOS Rules


Quality of Service

Monitoring QoS

We can monitor phone call and flows at the controller (refer to the icons at the bottom of the interface). We can also monitor flows at the AP itself if needed; we’ll do this in the Troubleshooting module.


Monitoring QoS

Voice DashboardQoS FlowsCAC per APCAC per

Virtual Cell


Deploying VoIP

Deploying VoIP

Obtaining Performance Characteristics

Before we can know how to configure the system, we’ll need to know what the performance parameters are.

The average and peak number of calls will drive the density of APs needed. An included spreadsheet, VoIP_Calls_v3.xls, can be used to calculate the number of APs required.

The size of the deployment area will affect how many APs are needed to cover the number of required calls.

For many phones the sample rate is settable; it should be configured as close to 50ms as possible


Deploying Wireless VoIP

Obtain performance requirements Average number of calls

- (Phones x usage ratio)

Peak number of calls (VoIP_Calls_v3.xls) Size of deployment area IP address range for phones

Obtain phone characteristics Sample rate (adjust for minimum packets

per second) Short-preamble capable


Deploying VoIP

VoIP Setting Guidelines

These are typical “best practices” for setting up VoIP.

Usually, you’ll want to deploy VoIP in a virtual cell. However, one exception to using virtual cells is with Spectralink phones. Spectralink assumes that the network has multi-channel APs. It uses the BSSIDs to limit the number of calls per access point, so multichannel APs need to be set up or you may only be able to have 10 calls in the entire network.

Another exception to using Virtual Calls is high phone densities. After calculating the number of APs needed, you may need to use a multichannel deployment to increase total bandwidth. In this case, the APs may be even closer together than 60ft/18m.

Note: Do not place Meru APs closer than 6ft/2m to one another even if they are on separate channels. Placing APs too close together creates cross-channel interference.

We typically use a different ESS for voice because most phones only understand WEP security, and this is inadequate for protecting data.


VoIP Setting Guidelines

System Deploy as Virtual Cell (for zero handoff)

- Exception: Spectralink phones

APs fairly close together (~60 ft./18m.)- SNR of 25db- Min. distance is 6ft./2m.- Exception: High phone density

APs configured for L3 operation

ESS Use a separate voice ESS (some phones only

do WEP)


Deploying VoIP

Typical ESS Configuration

This is a typical deployment scenario, where you have essentially distributed the ESSes geographically. In lab, we’ll configure your network so that the voice ESS is only being transmitted on one AP.


Yoyodyne Inc: Typical Wireless Architecture

Voice Data Guest


Lab Preview

Lab Preview

We’ll be making calls in the lab using softphones. We’ll also observe the system statistics.


Lab Preview

Continue building familiarity with interfaces Web interface CLI (and CLI assistance tools)

Distribute an ESS to a single AP

Connect a wireless call

Observe system statistics during call


Lab Preview


VLAN Effects in Lab

When you connect to an ESS with a VLAN, you’ll lose connectivity to the controller. Problems are designed into the lab.

- Remember: You have two networks and Ethernet available.

Use the VLAN address as the new controller IP address. ssh browser


Lab Exercises

Lab Exercises


Construct a voice ESS

Make wireless phone calls

Examine Quality of Service (QoS) parameters

In this module, please use the CLI as directed. This provides practice you may need if you’re unable to use the Web UI (for example, you can only use an SSH connection). In later modules, you can use whichever interface you prefer.

Use the settings specified on your Voice Network configuration sheet.

Create an ESS (using the CLI)

Consult the reference “CLI Command Reference-Lab” on page 175.

Create a Security Profile (using the CLI)

Consult your configuration information form and use the parameters on it in the following steps to add the wep security profile.

1. Enter the configure terminal command in the SSH terminal window, if you haven’t already done so.

2. Enter the following command to create a new security profile and access the profile configuration commands.

name(config)# security-profile ProfileName name(config-security)#

3. Using this format (and referring to your CLI reference, set the allowed L2 modes of your profile to wep. The L2 modes essentially define the authentication method to use.

Note: The command below uses the term “l2” (ell-two) not “12” (one-two).

name(config-security)# allowed-l2-modes ? <mode> Set the permitted L2 security mode.802.1x 802.1x clear Clear


Lab Exercises

wep Static WEP keys wpa WPA wpa-psk WPA PSK wpa2 WPA2 wpa2-psk WPA2 PSK name(config-security)# allowed-l2-modes wep

4. Consult your Configuration Information Form, your CLI reference, and the CLI help system to figure out and enter the commands to:

a. Set the encryption mode. (Hint: try encryption-modes ?)

b. Set the static wep key. (Hint: try ?)

c. Set the static wep key index.

5. Enter the exit command save your changes and return to the configuration mode.

name(config-security)# exit name(config)#

6. Verify the creation of your security profile with the show command:

name(config)# do show security-profile

Note: When you’re in the configuration mode, you must preface any show commands with the command do.

7. Verify the parameters of your latest security profile with the show command:

name(config)# do show security-profile ProfileName

Create an ESSID (using the CLI)

Consult your configuration information form and use the parameters on it in the following steps to add the ESS.

8. Enter the configure terminal command, if you haven’t already done so.

9. Enter the following command (from the configuration prompt) to create a new ESS and access the configuration commands:

name(config)# essid ProfileName name(config-essid)#


Lab Exercises

10. Display the available security profiles with the following command:

name(config-essid)# security-profile ?

11. Complete the command to set the security profile to the one you created in the previous section.

12. Enter the exit command save your changes.

13. Verify the creation of your ESS with the do show command.

Create a VLAN Profile

Create a VLAN Profile (CLI)

Consult the reference “CLI Command Reference-Lab” on page 175.

1. Enter the configure terminal command to access the configuration commands. Note that the prompt changes to include the (config) indication.

2. Consult your configuration sheet for this module and use the parameters on it in the following steps to add the VLAN listed.

3. Enter the following command to create a new VLAN and access the VLAN configuration commands:

name(config)# vlan VlanName tag TagNumber

Note: The tag number used here must match the (dotQ) tag used by the switches and routers in the network.

Observe that the prompt changes to include the (config-vlan) indication.

4. Enter the following commands to set the IP address of your VLAN:

name(config-vlan)# ip address IPaddress Netmask

5. Using this format (and referring to your CLI reference), set the default gateway of your VLAN.

6. Using this format (and referring to your CLI reference), set the DHCP server of your VLAN.

7. Using this format (and referring to your CLI reference), activate the DHCP override of your VLAN.

8. Enter the exit command to save your changes and return to the configuration mode.


Lab Exercises

9. Verify the creation of your VLANs with the do show command:

name(config)# do show vlan

10. Verify the parameters of the VLAN you just created with the show command:

name(config)# do show vlan vlanName

Add a VLAN to an ESSID (CLI)

11. Identify your wireless network:

name(config)# do show essid

12. Enter the following command modify your voice wireless network:

name(config)# essid essidName

Observe that the prompt changes to include the (config-essid) indication.

13. Enter the following command to add your new VLAN to your voice wireless network:

name(config-essid)# vlan name vlanName

14. Enter the following command to turn on VLAN support for your wireless network:

name(config-essid)# tunnel-type configured-vlan-only

15. Enter the exit command to save your changes and return to the configuration mode.

Note: Adding a VLAN to a wireless network to which you are connected will terminate your connection to that network. You will need to reconnect to obtain a new IP address (within the VLAN) for your SSH client. Consult your configuration sheet for the address to use.

16. Reconnect to the wireless network.

17. Verify the addition of your VLAN with the show command:

name(config)# do show essid essidName

18. Enter the exit command to return to the exec mode.


Lab Exercises


19. Scan the available networks and connect to the ESS that you just created.

20. Verify that your wireless interface has been assigned an IP address. (Use the ipconfig /all command from a Windows command line.)

21. Verify the connection of your client with the show command:

name(config)# do show station

22. Reload the WLAN Management web page by using the VLAN’s interface.

a. If you have the equipment in front of you , use the address: http://controllerVLANaddress

b. If you are using a remote lab, you will need to use the browser on your remote client (through VNC). Open up your VNC window, then use the address: http://controllerVLANaddress

Adjust ESS Distribution across APs

23. Enter the command to adjust the parameters of the ESS. Start with the following command:

name(config)# essid ProfileName

24. Enter the command to adjust the ESS-AP table.

name(config-essid)# do show ess-ap

25. Enter in the AP ID number and the interface index (IfIndex) of the radio from which you want to remove the ESS.

name(config-essid)# no ess-ap ap-id IfIndex

If your chosen AP has two radios, remove the ESS from all the radios on that AP.

26. Enter the end command save your changes and return to the topmost command level (called exec mode in the documentation).

27. Verify your reconfiguration with the command:

name# show ess-ap

28. Verify the parameters of your ESS with the show command.



Lab Exercises

Calling with a SIP Phone

While working with a partner, one of you will perform the following steps to connect a call between two phones.

1. Connect to the voice ESS, if you’re not connected already.

2. Launch the SIP phone.

Verify that the phone registers correctly.

3. Exchange phone numbers with someone else in the class.

4. Click on the front of the phone to enter your partner’s phone number.

5. Click on the Call button.

6. Keep the call connected while you examine the QoS statistics (in the next section).

Menu Button

Call Button


Lab Exercises

Examining QoS Performance Characteristics

You can examine the behavior of the QoS system either through the Web interface or the CLI. You may want to refer to the section “What to Do When Things Go Wrong – VoIP” on page 183.

Examining QoS Performance Characteristics (using the Web Interface)


2. Click on the Monitor button.

3. Click on the Voice hyperlink under the Dashboard heading in the left margin. The Voice dashboard displays.

4. Verify that you can see the call connection data

5. Click on the QoS Counters hyperlink under the Global Statistics heading in the left margin. A page listing the current QoS statistics displays.

6. Verify that you can see non-zero values for the Session Count and Active Flow counters.

7. Click on the QoS Flows hyperlink under the QoS/Voice heading in the left margin. A page listing the current QoS flows displays.

8. Make a call to another participant’s phone.

9. Click on the Refresh button in the lower right corner of the page to update the QoS Flows page.

10. What is different? ___________________________________________

Examining QoS Performance Characteristics (using the CLI)


2. Display the current QoS statistics with the command:

name# show qosstats

3. Create a call between two phones, if you don’t already have a call connected.

4. Redisplay the current QoS statistics.

name# show qosstats

5. Which parameters have increased?



Module 6Build a Data Network

With this module you’ll configure more advanced authentication, more like what you’ll run into at larger deployments. You’ll get practice in setting up connections across routed networks.


Set up 802.1x security

Create data-quality networks

Build a Data Network 107

WEP to WPA2 Evolution

WEP to WPA2 Evolution

As wireless has evolved, so have the needs for security.

In the beginning, WEP was sufficient for wireless communication. The encryption routines were implemented in hardware but, unfortunately, a means was found to break WEP security because the keys were reused too often.

WPA attempted to patch over these problems without requiring hardware changes by using the Temporal Key Integrity Protocol (TKIP) effectively generating a new key every 10,000 packets (amongst other fixes) but eventually this too was found to be insecure.

The WEP2 protocol requires not only strong encryption in hardware, but new routines that essentially change the key with every packet.


WEP->WPA->WPA2

WEP: First attempt at wireless security Fundamentally flawed as keys are reused to

about every hour

WPA: Uses TKIP to change keys every few minutes

(10,000 packets)

WPA2: Latest and Greatest Strong encryption (AES) required in hardware


The 802.1x RADIUS Authentication Process


RADIUS Protocol Example

You can use this diagram to troubleshoot the transactions between the players to determine where the communication breakdown takes place.

The exchanges can pinpoint which component is misconfigured.

Prerequisite Configuration

To setup 802.1x there is some items that need to be setup before hand.

A RADIUS server:

— Need the IP address of the RADIUS Server.

— Need to setup on the RADIUS server the controller’s IP address as a RADIUS Client. Need the secret that was used when setting up the controller’s IP address as a RADIUS Client.

— The Port number that is used on the RADIUS server (usually 1812).


RADIUS Protocol - 802.1X User

RADIUS

EAPOL Start

Identity request

Identify Response

EAP request

EAP Response

EAP success

EAPOW key

Access request

Access challenge

Access request

Access Accept(with VLAN)



An EAP client capable of 802.1x authentication. Generally, operating systems have these included, but there are some commercial versions that offer enhanced features.

The EAP type is not important for setting up the controller since this is transparent in the Authentication process, but it is important for wireless client configuration and the RADIUS Server.

For example, if you’re using EAP-TLS you will need:

— A Certificate Server will need to be installed to store and distribute user and computer certificates.

— A certificate installed on the wireless client before the user attempts to use the WLAN.

Protocol Description

1. Depending on the EAP type, the end user may first need to obtain a digital certificate from the Certificate Server.

2. Using EAP as end user, contact the Meru AP in order to be authenticated.

3. The Meru AP forwards the request to the controller.

4. The Meru controller acts as a RADIUS client and sends the request to the RADIUS server.

5. Depending on the EAP type, the RADIUS server may challenge the end user for a password, or the user may present a digital certificate that he has previously obtained from a Certificate Server.

6. The RADIUS server authenticates the end user and the access point, and opens a port to accept the data from the end user.



RADIUS Configuration Considerations

There are configurations for both RADIUS authentication servers and accounting servers. Please don’t confuse them. The authentication servers are just called “RADIUS servers” in the web interface, but the accounting servers are identified specifically with the word “accounting”. Authentication servers are configured security profiles; accounting servers are configured in ESS profiles.


Creating RADIUS Profiles

On the Controller specify: Primary RADIUS

authentication server

Secondary RADIUS authentication server

Primary RADIUS accounting server

Secondary RADIUS accounting server



Common RADIUS Server Configuration Problems

When configuring for RADIUS server, there are several details that need to be correctly aligned for the system to work correctly.

Of course, each RADIUS software manufacturer has their own way of setting these parameters.

See also “What to Do When Things Go Wrong – RADIUS” on page 179.


Common RADIUS Server Configuration Problems

Controller needs to be added to RADIUS server entries.RADIUS parameters are misconfigured

Port Secret

Beware of cached credentials


Firewalling and Rate Limiting


Firewalls are particularly important when the authentications standards are looser than normal, such as in guest networks.

Make sure you use the Match checkboxes to the right of the parameter list; if a parameter is unchecked, it functions as a wildcard.


QoS System: Firewalling and Rate Limiting

Configuration a 3-step process Selection

- Static ranges

- ESS-based - Per-group “firewall”

Action Apportion



QoS Selection

When creating a firewall rule, you must first select the packets on which the firewall will be applied.


QoS Selection

Match checkboxes Unchecked

= wild card

SELECTION



QoS Action

Next, you choose what will happen to the selected packets.


QoS Action

QoStreatmentDrop/

Forward/CaptureRate Limit

ACTION



QoS Apportion

Finally, you choose how, or if at all, the selected packets will be apportioned.



QoS Apportion Example


Apportion Example

Rate limiting source to 1Mbsec

Rate limiting destination to 1Mbsec

1Mbsec

1Mbsec

0.5Mbsec

0.5Mbsec



Firewall Rules - Example 1

What will this example do when used as a firewall?


Firewall Rules – Example 1


Per-ESS Firewall Policies


Firewall rules can be written that constrain users to address ranges of the system to which they need access. In this example, users that have joined a voice network can only reach the IP PBX and each other; they cannot access the corporate server.

Multiple firewall rules can be grouped together under a single Firewall Filter ID, and that ID can be applied to a security profile.



Per-Group Firewall Policies

Similar to per-ESS firewall policies, groups of users can be segmented to particular portions of the network. A typical example is guest users that only have access to the Internet. This feature is separately licensed (as the Policy Enforcement Module).

Group membership is controlled by authentication to a RADIUS server that passes back a firewall ID number. This firewall ID number maps to a set of firewall rules that control access.


Lab Preview

Lab Preview

In the lab exercises, you’ll create several levels of security measures.


Lab Preview

Removing a user from your network MAC filtering

WPA2-PSK authenticated connection

RADIUS authenticated connection RADIUS server configuration Windows client configuration Username / password


Lab Exercises

Lab Exercises


Set up 802.1x security

Create data-quality networks

Use the settings specified on your Data Network configuration sheet.

Removing a User from Your Network

In this section you’ll use MAC filtering to make sure a suspect user can’t connect to your network. The directions in this section are provided for the Web interface; there are equivalent CLI commands available.

Disconnect the User

In this section you’ll see the effects of simply disconnecting a user.

1. Connect your client station to one of your wireless networks, if it isn’t already connected. Leave the wireless client window showing.


3. Click on the Monitor button near the top left of the page.

4. Click on the All Stations hyperlink under the Devices heading in the left column.

5. Select your connected station.

6. Click on the Delete button at the bottom of the page.

7. Immediately observe your client station to see what happens to its wireless connection.

8. Note what happens here: __________________________________________

Activate MAC Filtering

In this section you’ll see the effects of using MAC filtering.



Lab Exercises

2. Click on the Configuration button near the top left of the page, if it’s not already selected.

3. Click on the MAC Filtering hyperlink under the Security heading in the left column.

4. Set the ACL Environment State to Deny List Enabled.

5. Click on the OK button at the bottom of the page.

6. Click on the ACL Deny Access Configuration tab to near the top of the page.

7. Click on the Add button at the bottom of the page.

8. Enter the MAC address of your wireless client.


10. Identify the ESS your client is connected to. Write it here: ________________

11. Open the security profile used by the ESS to which your wireless station is connected.

12. Click on the Security Profiles tab just below the ESS Profile - Update heading at the top of the page.

13. Scroll down the page to reveal the MAC Filtering drop-down box.

14. Set the drop-down selection of MAC Filtering to On.


16. Is your wireless client still connected? ________________

17. Try to connect to the wireless network again. What happens? ______________________________________________________________

Deactivate MAC Filtering

Caution! If two people are working on one controller, only one person should set the ACL Environment State at a time.


Caution! If two people are working on one controller, only one person should set the ACL Environment State at a time.


Lab Exercises

1. Use whichever interface you prefer to globally deactivate MAC filtering.

Create a WPA2PSK ESS

In this section you’ll create a wpa2-psk wireless network using your configuration information form.

1. Create the security profile of the wpa2-psk wireless network using the information on your configuration sheet.

If you want to be reminded how to do this, see “Create a Security Profile (WebUI)” on page 57 or “Create a Security Profile (using the CLI)” on page 100.

2. Create the ESS for the wpa2-psk wireless network.

If you want to be reminded how to do this, see “Create an ESSID (WebUI)” on page 57 or “Create an ESSID (using the CLI)” on page 101.


1. Scan the available networks and connect to the wpa2-psk ESS that you just created.

2. Verify that there is at least one station in the “Stations” graph.

3. Verify you can see your connection in the All Stations table (use the AllStations hyperlink under the Devices heading in the left navigation bar).

Create an 802.1x ESS

In this section you’ll create an ESS for 802.1x authentication, including a new security profile. The configuration parameters are available on the configuration information form.

Create a Radius Profile

1. Create the RADIUS profile from your configuration sheet using whichever interface you prefer.



Lab Exercises

Note that the RADIUS login information is also on this sheet.

Create a Security Profile

2. Create the security profile for 802.1x access (as specified on your configuration sheet) using whichever interface you prefer.

Create an ESS

3. Create the ESS for 802.1x access (again, as specified on your configuration sheet) using whichever interface you prefer.

Configure the Wireless Network Client

You must tell your Windows operating system how to use 802.1x for your rad network.

Note: These directions are for a Windows XP operating system. If you are using another OS, the steps will be different.

1. Double click on the Wireless Network Connection icon in the lower-right taskbar.

A window containing your Wireless Network Connections opens.

2. Click on the Change Advanced Settings link in the Related Tasks Group.


Lab Exercises

The Wireless Network Connections Properties window opens.

3. Click on the Wireless Networks tab.

The Wireless Networks information appears.

4. Select the ESSID (rad) that represents the network you configured to use 802.1x authentication.

Note: If you cannot see the ESSID in the Preferred Networks list, click the Add button and add it to the list.

5. Click on the Properties button.


Lab Exercises

The ESSID properties window opens.

6. Verify the Network Authentication is set to Open.

7. Verify the Data Encryption is set to WEP.

8. Verify that the The key is provided for me automatically checkbox is checked.

9. Click on the Authentication tab.

The wireless network properties window opens.

10. Verify that the Enable IEEE 802.1x authentication for this network checkbox is checked.

11. Verify that the Authenticate as computer when computer information is available checkbox is unchecked.

12. Verify that the Authenticate as guest when user or computer information is unavailable checkbox is unchecked.

13. Select Protected EAP (PEAP) from the EAP Type drop-down list.

14. Click on the Properties button.


Lab Exercises

The Protected EAP properties window opens.

15. Uncheck the Validate server certificate checkbox.

16. Select Secured Password (EAP-MSCHAP v2) from the Select Authentication drop-down list.

17. Click on the Configure button.

The EAP MSCHAPv2 Properties window opens.

18. Uncheck the Automatically use my Windows logon name and password (and domain if any) checkbox.



Lab Exercises

You are returned to the Protected EAP properties window.


You are returned to the wireless network properties window.



Lab Exercises

You are returned to the Wireless network Connection Properties window.


Log Into the 802.1x Network

After you have configured the network connection properties, this information bubble will appear:

Then, this bubble will appear.

1. Click on the informational bubble where is says “Click here”.


Lab Exercises

2. Enter the RADIUS user name and password information for your login account (refer to your Configuration Information form).


The system reports that you are Connected.

Note: Due to delays in the system, you may need to enter the user name and password a second time.



Module 7Build a Guest Network

With this module you’ll configure a very common configuration; guest access through a captive portal.


Create guest-isolating firewall rules

Create captive portal ESSes, using both

— Local authentication

— RADIUS authentication

Add temporary captive portal users

Build a Guest Network 135

Captive Portal Configuration


Guest Network Types


Guest Network Types

Open access

Captive portal



Guest VLANs

VLANs can be assigned on a per-ESS basis, or can be assigned from a RADIUS server. Your particular security needs will define which is better for you.


Guest VLANs

Configured Use “Tunnel

Type” VLAN

RADIUS-assigned Use “Tunnel

Type” RADIUS Use Firewall

Filter ID Licensed

Feature



Using Captive Portal

Captive portal is an authentication method that isolates stations until they are authorized through a RADIUS server.

Browser-based supplicants are presented a Web Authorization page to facilitate authentication.

Only a limited set of protocols can traverse a captive portal until the station is authenticated, for example, ping doesn’t get through.

Uses a set of customizable web pages to communicate with stations.


Using Captive Portal (CP)

Username/password authentication via https Only traffic allowed

is ARP, DNS, DHCPLocal or RADIUS

authentication



Creating Local Captive Portal (CP) Users

You can create up to 32 temporary guest users that to be authenticated via captive portal. (Of course, these credentials could be shared amongst real people.)


Creating Local CP Users

Up to 32 local users Guest User name Guest Password Start time End time


Lab Preview

Lab Preview

During lab we’ll use some more advanced topics that are relevant to building guest networks.


Lab Preview

Configuring local captive portal usersConfiguring captive portal

authentication Local RADIUS

Configuring firewall rules Add firewall rules to previous test network

- Add VLAN- Add firewall rules


Lab Exercises

Lab Exercises


Create captive portal ESSes

— Local authentication

— RADIUS authentication

Add temporary captive portal users

Create a guest-isolating firewall rule

Use the settings specified on your Guest Network configuration sheets.

Configure Captive Portal for Local Users

In this section you’ll set up the captive portal to use the guest user accounts on the controller.

Set up Guest User Accounts

Follow these directions to set up controller-based guest user accounts.

1. Click on the Configuration button near the top left of the page.

2. Click on the Guest Users hyperlink under the Security heading in the left navigation bar.

3. Click on the Add button at the bottom of the page.

4. Enter the Guest User Name and the Guest User Password.

5. Enter the Service Start Time as 24 hours prior to the current time.

6. Enter the Service End Time as 24 hours later than the current time.


Create a Captive Portal Security Profile

8. Click on the Configuration button near the top left of the page (if you’re not already in the configuration mode).


Lab Exercises

9. Click on the Profile hyperlink under the Security heading in the left navigation bar.

10. Create a security profile with the parameters shown in your configuration worksheet. Use whichever interface (WebUI or CLI) you prefer.


Create a Captive Portal ESS


13. Click on the ESS hyperlink, under the Wireless heading in the left column.

14. Create an ESS profile with the parameters shown in your configuration worksheet. Use whichever interface (WebUI or CLI) you prefer.


Activate Local Captive Portal Authentication


17. Click on the Captive Portal hyperlink under the Security heading in the left navigation bar.

18. View the settings of the SSL Server.

The SSL Server page opens.

19. Verify the setting of the CaptivePortal Authentication Type drop-down box and change it to local (if needed).


Verify client (station) connectivity

Configure your system to connect to the captive portal ESS you just created.

1. Connect to the ESS.

2. Open a web page to the Target Address shown on your configuration sheet.


Lab Exercises

You should see the captive portal web page, sent to you by your controller.

3. Enter your Guest User login information.

You should see the class web page.

Configure Captive Portal for RADIUS-Authenticated Users

In this section you’ll set up the captive portal to authenticate using the RADIUS accounts you used previously.

Activate RADIUS Captive Portal Authentication


5. Click on the Captive Portal hyperlink under the Security heading in the left navigation bar.

6. View the settings of the SSL Server.

The SSL Server page opens.

7. Change the setting of the Primary RADIUS Profile Name drop-down box to the RADIUS profile you previously set up.

8. Verify the setting of the CaptivePortal Authentication Type drop-down box and change it to radius (if needed).


Verify client (station) connectivity

Configure your system to connect to the captive portal ESS you just created.

1. Connect to the ESS.

2. Open a web page to the Target Address shown on your configuration sheet.



Lab Exercises

You should see the captive portal web page, sent to you by your controller.

3. Enter your RADIUS User login information.

You should see the class web page.

Creating Guest-Isolating Firewall Rules

You can add a firewall rule to enhance the security of your test network.

This example shows a configuration where we do not want guests on an otherwise open network to have access to particular protocols. We will deny ping access to the class clients, which in this lab is a stand-in for the Internet.

Create a Guest VLAN

1. Create and attach a guest VLAN to your test network using the parameters on your configuration sheet.

2. Connect to your test network. What is your station’s IP address on that test network? Write it here: ___________________________

Test Cross-station connectivity

In this section you’ll set up a test ping to validate the firewall rule.

1. Work with another person in your class to exchange your stations’ IP addresses within the VLAN.

2. Open up a terminal window on your station.

3. Start a ping between your and your partner’s stations. (Hint: use the command: ping -n 200 IPaddress )


Check: Have your instructor observe your progress at this point.


Lab Exercises

Add Firewall Rules (using the Web Interface)


2. Click on the Configuration tab.

3. Click on the System Settings hyperlink under the QoS heading in the left margin.

4. Click on the QoS and Firewall Rules tab near the top margin. A page listing the current (default) QoS rules displays.

5. Click on the Add button at the bottom of the page to create the firewall rule.

6. Enter the parameters for the firewall rule listed on your configuration sheet.

7. When you are done changing the parameters, click on the OK button near the bottom of the page.

8. Examine your rule and verify the parameters are correct.

Test Cross-station connectivity (again)

1. Open up a terminal window on your station.

2. Start a ping between your and your partner’s stations. What happens this time?

3. Disconnect from your wireless network and reconnect to it.

4. Start a ping between your and your partner’s stations. What happens this time?



Lab Exercises


Module 8Troubleshooting

Let’s face it, things don’t always go smoothly and there are times we need to have additional information about the system operation to figure out what’s not working. This module provides the basics in obtaining this information so you can work effectively with Tech Support to resolve problems quickly.


Obtain logged station information from the system.

Capture packets from the system.

Filter for certain packets after you have captured them.

Tools


CLI Reference Chart

“What to Do When Things Go Wrong – Installation” on page 177

“What to Do When Things Go Wrong – RADIUS” on page 179

“What to Do When Things Go Wrong – VoIP” on page 183

Troubleshooting 147

What to Do When Things Go Wrong


By asking these simple questions to locate the problem, and thinking about the answers to them, you can reduce your troubleshooting effort by 80%.



Ask: One client, several, or all?

One AP, several, or all (locations affected)?

Controller contactable?

APs contactable? Stations observable?


Stages of Connection


Each time a station connects to the wireless network, the process proceeds in stages. Some of the stages always happen, some only happen in certain conditions. Fro example, the only time MAC filtering is checked is if it is enabled.

By tracking the stages that a connection has gone through, you can quickly isolate station problems from network problems.



Troubleshooting 149


Connection Transactions

Another way to view the stages of connection is through this transaction diagram.


DHCP request/ Response

EPOL Key Exchange

Radius Request/ Response

ID request/ response

Association Response

Association Request

Auth response

Auth Request

Probe response

Probe Request

RadiusControllerWAPUser Machine

If Mac Radius is used

Client can initiate (EOPL-Start)

Mult iple packet exchange




Information Facilities


There are extensive logging capabilities built into the System Director software, which allow us not only to view the logs but store sufficient information for the controllers to infer various kinds of failures. Packet capture is, as its name implies, the capture of packets from either the controller or AP.

The controller has an on-board packet sniffer to assist you in troubleshooting and characterizing network traffic flows.

You can capture packets from the following sources:

Controller Ethernet interface (G1 only)

From APs

Over the air using a wireless laptop

You can see packet captures in real-time or save them to a file for future offline analysis. Use the CLI copy command to transfer the captured file to another system.



Station Diagnostics Event logging Station logging Syslog

InferencesPacket Capture and Analysis

From a controller From an AP (AP200/300) From a wireless laptop

Troubleshooting 151

Station Logging

Station Logging

Station Buffered Diagnostics

Through the GUI you can easily get to the Station logs for a particular station. You can then track the progress of a station’s connection. If desired, you can filter the log to show only a subset of the connection stages.


Station Buffered Diagnostic


Station Logging

Interactive Station Logging

The stations logs are not only available in teh GUI, bu tin the command line as well. You can use the interactive station logging shell to start logging the events of one or more MAC addresses.


Interactive Station Logging

Used to track stations

Troubleshooting 153

Station Logging

Historical Station Logging

You can access the historical station log and filter the list by MAC address. If you don’t filter by MAC address, you get the log entries for all stations. You can also choose to look at only the last xxx messages that were stored.


Historical Station Logging

Used to track stations in the pastSame as buffered diagnosticsstation-log show

–mac=rr:ss:tt:uu:vv:yy

–since=xxx


Station Logging

Syslog

Failures arise when one piece of equipment isn’t communicating with another. We’ll use the facilities of this module to see how we can follow those communications to determine where the failure occurs.


Syslog Diagnostics

Enable Security logging on the Security Profile of interest Syslog shows Captive Portal messages not

seen elsewhere

Troubleshooting 155

Inference Engine

Inference Engine

The on-board diagnostics of System Director version 3.6.1 (and later releases) have been greatly enhanced by building numerous counters into the system to track operation and report on anomalous situations by drawing failure inferences from multiple areas of the system’s operating environment.


Inference Engine

Essentially a bunch of counters Triggers an alert when thresholds are

reached

Automated reporting available when working with Support


Inference Engine

Activating the Inference Engine

The Inference Engine combines information from these areas to draw its conclusions. To obtain the maximum benefit from the Inference Engine, activate all three areas at installation time.

After you have turned on the inference areas, you can also send the inference messages to the station log, syslog, or both.


Inference Facilities

Three Areas Tracked Station, Controller, AP (AP300)

Turn on at Installation

Send to station log and/or syslog

Troubleshooting 157

Inference Engine

Station Counters

Amongst several of the counters used by the system, the station counter is perhpas the most useful. by simply scanning the table, you can get a feel for those statinos that are having problems and may warrant further investigation.


Inference Counters

Station counter IP discovery count

Soft handoff count Key exchange count

Tx and Rx counts


Capturing Packets

Capturing Packets

The Meru system has the tethereal packet capture software built into it, so you always have a multi-sourced packet sniffing tool. Indeed, until recently, this was the only way to do 11n sniffing.

Captured packets are displayed a page at a time. While the page is being displayed, the capture continues in the background.

There is (roughly) a 30-line buffer in the command, so you may not see output immediately after you invoke the command.

When capturing, it is usually best to get a full capture, then filter it out later, though there is only 10MB available to capture files. Captured files are saved in the capture directory on the controller.

Using different chipsets when capturing will give you different results. Your maximum probability for success is to use a dedicated solution.


Capturing Packets

From the Controller Use the capture-packets commandname # capture-packets

Use –w to save a capture (must be last option)name# capture-packets -w filename

From APs (AP200/300 only) Use the –i option of the capture-packets

command. name# capture-packets -i ap_num

To stop real-time packet capture, press Ctrl-C

Move captured files to laptop and use Wiresharkto filter

Troubleshooting 159

Capturing Packets

Filtering Packets

Generally we try to capture the minimum amount of information that is adequate to troubleshoot a problem. This is simply so we don’t have to wade through heaps of data to find what we’re looking for.

Note: The “help” function for capture-packets gives erroneous results, but has to because of the GPL.


Filtering Packets

The built-in Ethereal sniffer lets you filter packets.Syntax:

-R primitive[[equivalence value]

No spaces are allowed in filter specification Equivalences are: == (equal to), != (not equal to)

Capture only SIP packets from AP 1: name# capture-packets –i 1 -R sip

Capture traffic from an IP address: name# capture-packets -R ip.addr==192.168.10.50

For more complex filtering, capture files to laptop and use Wireshark


Capturing Packets

Where to Measure Wireless Networks

Failures arise when one piece of equipment isn’t communicating with another. We’ll use the facilities of this module to see how we can follow those communications to determine where the failure occurs.


Where to Measure Wireless Networks

MAC/IP of Controller Ethernet Port

MAC/IP of AP Ethernet PortBSSID of ESS

Controller

A P2 00

NETWORKS

A P2 00

NETWORKS

Ethereal PC

sni ff Configured A P

Destination L2 M AC address

L3 IP address

Troubleshooting 161

Capturing Packets

Wireshark

The GUI-based Wireshark (formerly Ethereal) has far more advanced filtering capabilities than the command-line version, so it’s usually better to capture a bit more data than we need and use the GUI to filter it further.

21© 2009 Meru Networks Inc All rights reserved

Wireshark

Help

1. Click on the Expression button to create a filter.

2. Create the filter, click OK

3. Click on the Apply button.


Capturing Packets

Saving Captures

Because the controller only has 10MB of space reserved for captures, we can use the ISDS system to route packets directly to Wireshark running on a computer.

Don’t forget to disable the IDS once you’re done.

Note: This technique shows only what is received by the AP!


Saving Captures with Wireshark

Synchronize clocks with Controller and Wireshark PC

Set up IDS Point to Wireshark PC’s IP address Use port 9177 Specify index number(s) of L3-connected APs

Set up and activate Wireshark Set up Capture Options...

When you’re done, restore IDS to original state

Troubleshooting 163

diagnostics Command

diagnostics Command

The diagnostics command is only run at the request of Support, typically only for very involved problems. No tools are provided to use the data collected.


diagnostics Command

When you need to capture the entire system state, use the command “diagnostics” Takes snapshot of system state

Essential for reporting problems

Does not affect operation Need to copy off the controller

If you run it again, it will overwrite the previous copy


Lab Preview

Lab Preview


Lab Preview

Examine station logs

Capture and examine packets SIP RADIUS

Troubleshooting 165

Lab Exercises

Lab Exercises


Examine the station logs to track a station’s connection.

Capture packets from the system.

Filter for certain packets after you have captured them.

Station Diagnostics

Filtered View

1. Set up station diagnostics to record the events of your station.

2. Connect your station to your test network.

3. Looking at the station log and one of the connection stages diagrams, trace the progress of your connection.

4. Connect your station to your network that uses 802.1x authentication.

5. Looking at the station log and one of the connection stages diagrams, trace the progress of your connection.

Filtered View

1. Set up station diagnostics your controller to capture DHCP events.

2. Connect your station to your test network.

3. Display the messages that indicate IP address assignment.

Capture Packets

From a controller

1. Open a terminal session to your controller.



Lab Exercises

2. Change the default number of lines that the command line displays using the command: terminal length 0.

3. Capture packets from the controller.

What command did you use? ________________________________________

4. Observe the packets flowing by.

5. Stop the capture by pressing Control-C.

From an AP using IDS and Wireshark

In this section reminds you’ll practice capturing packets using the IDS facility and Wireshark.

1. Close the web browser currently running the Web interface.

2. Launch Wireshark and configure it to collect information from the Ethernet interface of the station on which it is running.

3. Disconnect from all wireless networks.

4. Open an SSH terminal session to your controller.

5. Identify the IP address of your recording system.

6. Open the IDS configuration page in the Web interface (Configuration > IDS [under the Wireless IDS/IPS heading]).

7. Enter the number 9177 in the Server Port text box.

8. Enter the index numbers of both your APs, separated by a comma, in the AP selection box.

You can capture packets from a single AP by entering its index number only in the AP selection box.

Note: Note: the AP from which you want to record must be configured for L3 access.


Data should begin streaming to the Wireshark application from the AP.

10. Have your partner connect to your wireless network.

11. Collect data while your partner authenticates, then stop the capture.

12. Disable the IDS facility.

Troubleshooting 167

Lab Exercises

13. Filter the data display so you can see only the packets from your partner’s station.

What filter term (or terms) did you use?

________________________________

________________________________

________________________________

14. Close Wireshark.

Capture a SIP Session

During a SIP Call

1. Capture packet traces for a SIP session on the controller. Use the command: controller# capture-packets -R sip

You will see something like:

There should be a symmetry of communication between the two devices.

11.391697 192.168.10.131 -> 10.6.6.103 SIP Request: REGISTER sip:10.6.6.103 12.067072 10.6.6.103 -> 192.168.10.131 SIP Status: 200 OK (1 bindings) 17.190306 192.168.10.130 -> 10.6.6.103 SIP Request: REGISTER sip:10.6.6.103 17.717009 10.6.6.103 -> 192.168.10.130 SIP Status: 200 OK (1 bindings)

41.081454 192.168.10.130 -> 10.6.6.103 SIP/SDP Request: INVITE sip:[email protected], with session description 41.084611 10.6.6.103 -> 192.168.10.131 SIP/SDP Request: INVITE sip:[email protected], with session description 41.237828 192.168.10.131 -> 10.6.6.103 SIP Status: 180 Ringing 41.240878 10.6.6.103 -> 192.168.10.130 SIP Status: 180 Ringing 42.276537 192.168.10.131 -> 10.6.6.103 SIP/SDP Status: 200 OK, with session description 42.278801 10.6.6.103 -> 192.168.10.130 SIP/SDP Status: 200 OK, with session description 42.520909 192.168.10.130 -> 10.6.6.103 SIP Request: ACK sip:[email protected]:5060 42.524012 10.6.6.103 -> 192.168.10.131 SIP Request: ACK sip:[email protected]

Call Setup

Phone registrationon powerup

192.168.10.130 initiates a call


Lab Exercises

2. Capture packet traces for a SIP session on the AP to which the phone is associated. You can use either the IDS method or the capture-packets command:

controller# capture-packets -i apId -R sip

In this command, substitute the number of the AP you want to capture from for the term “apId”.

3. Show your instructor the traces you have captured.

Capture a WPA Session

In this section you will use the troubleshooting techniques you have learned and the references you have to construct a troubleshooting command for a WPA authentication session.

1. Create an appropriate packet capture command.

What command did you use?

________________________________________

2. Run the command, then attempt authentication through the WPA2PSK-secured ESS you constructed earlier.

Capture a RADIUS Session

Capture a Wired RADIUS Flow using Wireshark

The next two steps involve capturing packets for analysis. Either the IDS method or the capture-packets command can be used.

1. Capture packets destined for the RADIUS server coming from the controller into a file (in this example: filename.cap). For a file capture, use a command like:

controller# capture-packets -R radius -w filename.cap

or, to filter on the IP address of the RADIUS server (172.17.17.7, in this example), use:

controller# capture-packets -R ip.addr==172.17.17.7 -w filename.cap


Troubleshooting 169

Lab Exercises

You’ll see something like:

2. Verify that Access Accept is returned.

Capture a Wireless EAPOL Flow

3. Capture packet traces for the session from a specific AP. Use the command: controller# capture-packets -i apId -R eapol

a. Verify that Access Accept is returned.

Capture a Complete RADIUS Transaction

4. Capture packets from the RADIUS transactions into a file (in this example: filename.cap). For file capture, use a command like:

controller# capture-packets -R radius -w filename.cap

a. Verify that the entire RADIUS transaction can be seen by reviewing the capture.

See the illustration “RADIUS Protocol Example” on page 109 for an example of the required information exchanges.

b. Verify that Access Accept is returned.

Troubleshoot a RADIUS Session

Your instructor will borrow your system and put a typical problem in it. Your job is to locate the problem using the troubleshooting techniques you have learned.

1. Ask you instructor to configure your system.

2. Once configured, use the techniques you have learned to isolate the problem.

yoyodyne-wifi# capture-packets -R "radius" …17 10.009528 172.17.17.253 -> 172.17.17.7 RADIUS Access Request(1) (id=177, l=170)18 10.010387 172.17.17.7 -> 172.17.17.253 RADIUS Access challenge(11) (id=177, l=877)19 10.060602 172.17.17.7 -> 172.17.17.253 RADIUS Access challenge(11) (id=178, l=115)20 10.078463 172.17.17.253 -> 172.17.17.7 RADIUS Access Request(1) (id=179, l=170)21 10.079215 172.17.17.7 -> 172.17.17.253 RADIUS Access challenge(11) (id=179, l=126)22 10.098579 172.17.17.7 -> 172.17.17.253 RADIUS Access challenge(11) (id=181, l=166)23 10.110311 172.17.17.253 -> 172.17.17.7 RADIUS Access Request(1) (id=182, l=271)24 10.116440 172.17.17.7 -> 172.17.17.253 RADIUS Access challenge(11) (id=182, l=166)25 10.128559 172.17.17.7 -> 172.17.17.253 RADIUS Access challenge(11) (id=183, l=126)26 10.139293 172.17.17.253 -> 172.17.17.7 RADIUS Access Request(1) (id=184, l=170)27 10.140425 172.17.17.7 -> 172.17.17.253 RADIUS Access Accept(2) (id=184, l=232)


Lab Exercises

3. Show your instructor the traces you have captured and explain your reasoning used to isolate the problem.


Troubleshooting 171

Lab Exercises


Appendix AJob Aids

This section lists various additional resources that you may find helpful.

Job Aids 173

Exec Modename#capture-packets cd (directory) clear configure terminalcopydebug default delete dir (directory) exithelp more no ping ip_address poweroff controllerpwd reload {ap| controller| default}run scriptsetup show upgrade

Configuration Modename(config)#access-list ap id autochannel boot-script do (show)essid name exithigh-availability hostname name interface Dot11Radio ap_id ap_index ip no passwd usernameqosrule id qosrule id netprotocol n qosprotocol {none|...} rogue-ap security-profile namestation mac_address vlan name tag tag_number

Copy Commandscopy source destination copy running-config startup-configcopy running-config

Show Commandsshow alarm show ap (id)show ap-assigned show ap-connectivity show ap-discovered show controller show essid (name) show flash show memory show qosflows show qosstats show rogue-ap {acl| blocked| globals}show security-profile (name)show security-rule show station show topoap show topoapap show topostaap show topostation show vlan name

VLAN Configuration Mode(config-vlan)#do (show)exitip address ip_address netmaskip default-gateway ip_address ip dhcp-server ip_address

CLI Command Reference-Lab

Legend

- no prefix works - shows options

Security Configuration Mode(config-security)#8021x-network-initiation allowed-l2-modes do (show) encryption-modes end exit no radius-server rekey security-rule static-wep

ESS Configuration Mode(config-essid)#ap-discovery beacon do (show) end ess-ap ap_id ap_index exit no publish-essid security-profile

upgrade Commandsupgrade ap {version|same} upgrade controller versionupgrade system version

<Tab> - completes command

QoS Configuration Mode(config-qosrule)#action avgpacketrate rate default do (show) droppolicy {head| tail} dscp dstip ip_address dstmask netmask dstport portend exit no priority srcip ip_address srcmask netmask srcport port tokenbucketrate rate trafficcontrol trafficcontrol-enable

(Station) Access-list Commandsaccess-list deny mac_address access-list permit mac_address access-list state {deny| disabled| permit}

ap Configuration Mode(config-ap)#boot-scriptbuildingconnectivitycontactdefault connectivitydescriptiondo (show)endexitfloorhigh-density-enableled {Blink| NodeID| Normal} locationmac-address mac_addressno show ess-ap

Interface Configuration Mode(config-if-802)#antenna- channel id do (show) end exit fixed-channel mode (normal | scan-ning) no preamble-short rf-mode

Rogue AP Commandsrogue-ap acl bssid rogue-ap blocked bssid rogue-ap detection rogue-ap logrogue-ap mitigation {all| none| selected}

Exec Modename#capture-packets cd (directory) clear configure terminalcopydebug default delete dir (directory) exithelp more no ping ip_address poweroff controllerpwd reload {ap| controller| default}run scriptsetup show upgrade

Configuration Modename(config)#access-list ap id autochannel boot-script do (show)essid name exithigh-availability hostname name interface Dot11Radio ap_id ap_index ip no passwd usernameqosrule id qosrule id netprotocol n qosprotocol {none|...}rogue-ap security-profile namestation mac_address vlan name tag tag_number

Legend

- no prefix works - shows options

Editing the Command Line<Tab> – completes commandHome – position cursor at the beginning of command lineEnd – position cursor at the end of the command lineRight Arrow – move cursor to the rightLeft Arrow – move cursor to the leftDel, Backspace – remove the character to the left of the cursorUp Arrow, Down Arrow – scroll through command historyESC – clear the command line

What to Do When Things Go Wrong – Installation

This procedure covers most of the problems that arise during an installation. As you check each point, if you can verify the requested state, or the answer to the posed question is “yes”, continue on with the next numbered (or lettered) step. If you cannot verify the requested state, or the answer to the posed question is “no”, perform the sub-steps.

1. Verify that you can log in to the Controller.

a. Verify connection through the RS-232 port.

Note: The baud rate is 115k, not anything else.

b. Verify connection through the web interface.

2. Verify there are the correct number of APs in the GUI configuration table. If not, there’s a problem with AP discovery, which is initiated by the AP.

a. Identify the MAC address of one of the missing APs (its serial number is also its MAC address).

b. Activate traces on that AP to capture the discovery process. Use the command:

controller# capture-packets -i apId

c. Disconnect the AP for 10 seconds; the AP reboots and you get trace entries.

3. Verify all the APs are enabled and online.

If the AP is enabled and offline:

a. Verify you can contact the AP.

b. Verify the software version matches the controller.

c. Examine the ESSes that are on the AP.

d. Activate traces on that AP to capture the discovery process.

e. Disconnect the AP for 10 seconds; the AP reboots and you get trace entries.

If you can’t log into the AP:

a. Put the AP on the same subnet as the controller.

b. Log into the AP.

c. Verify that the AP is set for the correct discovery (L2 or L3).

d. Verify that the AP is sending out discovery packets.

177

What to Do When Things Go Wrong – Installation

4. Try to connect with the configured ESSIDs.

5. Test DHCP

a. Is router the DHCP server or is the router forwarding?

b. If it doesn’t work, check IP connectivity.

c. Use static IP addresses to see if controller can be reached through subnets.

d. Look at AP’s database; see if client is associated with that AP.

6. Turn on WEP to see if shared key works.

7. Configure RADIUS.

a. What is shared secret and controller IP address?

b. What is RADIUS IP address and port number?

c. What are allowed NAS addresses? (The controller is considered a NAS device.)

d. Look at RADIUS log files to see if there’s info from the Controller IP address.

e. Start looking at packet traces. Where are they lost?

Note: RADIUS negotiation is a Level-2 support issue.


What to Do When Things Go Wrong – RADIUS


This procedure covers most of the authenticating problems that arise during an installation. As you check each point, if you can verify the requested state or the answer to the posed question is “yes”, continue on with the next numbered (or lettered) step. If you cannot verify the requested state, or the answer to the posed question is “no”, perform the sub-steps.

The most common issues are:

Mis-matched RADIUS secret Incorrect configuration on Controller Interop issues with the controller between different vendor servers and EAP types

Here are the general steps for troubleshooting an 801.x authentication problem:

Review customer traces on the controller Verify configuration of the controller Perform packet capture of wired RADIUS flow Perform packet capture of wireless EAPOL flow Enable support/engineering traces on the controller

Review Customer Traces on the Controller

These traces let you follow the authentication progress without potentially overwhelming detail.

1. Capture high-level traces for the session on the controller. Use the these commands (in order):

controller# debug module sec controller# debug controller

You’ll see something like: yoyodyne-wifi# debug module secOK!yoyodyne-wifi# debug controller Real-time trace display enabled for severity >= 0.yoyodyne-wifi# [03/09 10:19:54.189] SEC: Sending EAPOL-EAP Request-Identity to client (00:05:3c:08:c5:9e), ID (71).[03/09 10:19:57.219] SEC: Sending EAPOL-EAP Request-Identity to client (00:0e:35:7f:34:98), ID (10).[03/09 10:20:03.279] SEC: Sending EAPOL-EAP Request-Identity to client (00:00:4c:1a:18:4d), ID (16).[03/09 10:20:04.289] SEC: Sending EAPOL-EAP to client (00:00:4c:1a:18:4d), ID (16).[03/09 10:20:04.289] SEC: Sending EAPOL-EAP Request-Identity to client (00:00:4c:1a:18:4d), ID (17).[03/09 10:20:04.289] SEC: Sending EAPOL-EAP Request-Identity to client (00:00:4c:1a:18:4d), ID (17).[03/09 10:20:05.298] SEC: Removing ATS key for client = (00:00:4c:1a:18:4d)no debug controllerReal-time trace display disabled.yoyodyne-wifi# no debug module secOK!

179


a. Verify that all required information exchanges occur for authentication.


b. Identify the component that is not sending the required information. That is most likely the misconfigured component.

c. When you are finished, turn off the debug routines: controller# no debug controller controller# no debug module sec

Verify Configuration of the Controller

2. Verify the security profile in use at the Controller. Use the command: controller# show security-profile profileName


a. Verify that L2 Modes Allowed is either 802.1x or WPA.

b. Verify that Cipher Suites is one of wep128, wep64 or tkip.

c. Verify the Primary RADIUS IP Address matches that used by the RADIUS server.

d. Verify the Primary RADIUS Port matches that used by the RADIUS server.

The current standard is 1812, but some implementations use a different port.

Note: On the RADIUS server you must configure a client, with its own IP address and secret, for each controller in your network.

e. Verify the Primary RADIUS Secret matches that used by the RADIUS server.

yoyodyne-wifi# show security-profile 1xpeap Security Profile Table

Security Profile Name : 1xpeapL2 Modes Allowed : 802.1xPrivacy Bit : autoCipher Suites : wep128Enable Primary RADIUS Server : onPrimary RADIUS IP Address : 10.0.0.40Primary RADIUS Port : 1812Primary RADIUS Secret : *****Primary RADIUS VLAN Name : Enable Secondary RADIUS Server : offSecondary RADIUS IP Address : 0.0.0.0Secondary RADIUS Port : 1812Secondary RADIUS Secret : *****Secondary RADIUS VLAN Name : …802.1X Network Initiation : onEnable Shared Authentication : offEnable Fast Handoff : on



Mismatched secrets are the most common form of configuration error.

f. Verify the VLAN tag has been created on the controller and the RADIUS server is accessible through that VLAN.

RADIUS VLANs are usually only used when interoperating with third-party products, though in high-security situations they can be used as well.

g. If a secondary RADIUS server is configured, verify the Secondary RADIUS IP Address, Port, Secret and VLAN matches those used by the secondary server.

Note: If a secondary RADIUS server is configured and the primary fails, the secondary will be used until the secondary fails (or the controller is rebooted).

h. Verify that 802.1X Network Initiation is on.

This should only be off when using a (non-compliant) legacy device that does not respond well when the Controller initiates the authentication process.

i. Verify that Enable Shared Authentication is off.

j. Note the setting of the Enable Fast Handoff parameter.

When this is set to “on” and a client hands off between one Virtual Cell and another, or changes channel, then the key for encryption will be passed over to the new AP. Thus the client does not have to go through reauthentication, it can start just sending with that same key.

Perform Packet Capture of Wired RADIUS Flow

The next two steps involve capturing packets for analysis. The capture-packets command is used; for a reference on the available options see the Troubleshooting Commands chapter of the Command Reference book.

3. Capture packets destined for the RADIUS server coming from the controller into a file (in this example: filename.cap). Use a command like:

controller# capture-packets -R "radius" -w filename.cap

or, to filter on the IP address of the RADIUS server (172.17.17.7, in this example), use:

controller# capture-packets -R "ip.addr==172.17.17.7 && radius" -w filename.cap

181



4. Verify that Access Accept is returned.

Perform Packet Capture of Wireless EAPOL Flow

5. Capture packet traces for the session from a specific AP. Use the command: controller# capture-packets -i apId -R "eapol"

a. Verify that Access Accept is returned.

Perform Packet Capture of Complete RADIUS Transaction

6. Capture packets from the RADIUS transactions into a file (in this example: filename.cap). Use a command like:

controller# capture-packets -R "eapol && radius" -w filename.cap

a. Verify that the entire RADIUS transaction can be seen.


yoyodyne-wifi# capture-packets -R "radius" …17 10.009528 172.17.17.253 -> 172.17.17.7 RADIUS Access Request(1) (id=177, l=170)18 10.010387 172.17.17.7 -> 172.17.17.253 RADIUS Access challenge(11) (id=177, l=877)19 10.060602 172.17.17.7 -> 172.17.17.253 RADIUS Access challenge(11) (id=178, l=115)20 10.078463 172.17.17.253 -> 172.17.17.7 RADIUS Access Request(1) (id=179, l=170)21 10.079215 172.17.17.7 -> 172.17.17.253 RADIUS Access challenge(11) (id=179, l=126)22 10.098579 172.17.17.7 -> 172.17.17.253 RADIUS Access challenge(11) (id=181, l=166)23 10.110311 172.17.17.253 -> 172.17.17.7 RADIUS Access Request(1) (id=182, l=271)24 10.116440 172.17.17.7 -> 172.17.17.253 RADIUS Access challenge(11) (id=182, l=166)25 10.128559 172.17.17.7 -> 172.17.17.253 RADIUS Access challenge(11) (id=183, l=126)26 10.139293 172.17.17.253 -> 172.17.17.7 RADIUS Access Request(1) (id=184, l=170)27 10.140425 172.17.17.7 -> 172.17.17.253 RADIUS Access Accept(2) (id=184, l=232)


What to Do When Things Go Wrong – VoIP


This procedure covers most of the voice problems that arise during installation and operation. As you check each point, if you can verify the requested state or the answer to the posed question is “yes”, continue on with the next numbered (or lettered) step. If you cannot verify the requested state, or the answer to the posed question is “no”, perform the sub-steps.

Symptom: Poor Voice Quality

Here are the general steps for troubleshooting a voice problem:

Verify call is treated as QoS Verify configuration of Controller Debug why call is not treated as QoS Debug why QoS is not performing well

Verify call is treated as QoS

1. With no phones making calls, verify that you have zeroed QoS stats on the Controller. Use the command:

controller# show qosstats

2. While one phone is making a call to another, check the QoS stats. Use the command:

controller# show qosstats


a. Verify the Session Count has increased by at least 1 (one).

b. Verify the Active Flows has increased by 2 for a voice-only call. If bi-directional video is involved, the number of active flows would be 4.

yoyodyne-wifi# sh qosstats Global Quality-of-Service Statistics

Session Count : 1H.323 Session Count : 0SIP Session Count : 1Rejected Session Count : 0Rejected H.323 Session Count : 0Rejected SIP Session Count : 0Pending Session Count : 0Pending H.323 Session Count : 0Pending SIP Session Count : 0Active Flows : 2Pending Flows : 0

183


Verify configuration of Controller

1. Verify that the QoS rules for the protocol are configured as ‘capture’ on the proper port. Use the command:

controller# show qosrules You’ll see something like:

The rules that have source (SPort) and destination (DPort) ports of 5060 are the SIP-configured ones. Both must be configured as “capture”.

Note: Some SIP servers, for example Fujitsu, may use a different port for SIP messages. In this case the QoS rules that use that port number must be set up to “capture”.

2. Verify the QoS Codec is configured for the proper flowspec based on your phone sample rate (Packet Rate) (for example. 20msec., 30msec., 50msec.; refer to the spreadsheet planner qoscodec_Parameters.xls to calculate the values for your packetization rate). Use the rule IDs that you identified in the previous step, and the command:

controller# show qoscodec id You’ll see something like:

3. If you have a dense Virtual Cell environment, make sure that the beacons are in “safe” mode.

a. Copy the AP initialization script timsync.scr to the ATS/scripts directory.

ID Dst IP Dst Mask DPort Src IP Src Mask SPort Port Qos Action Drop

3 0.0.0.0 0.0.0.0 5060 0.0.0.0 0.0.0.0 0 17 sip capture tail 4 0.0.0.0 0.0.0.0 0 0.0.0.0 0.0.0.0 5060 17 sip capture tail

yoyodyne-wifi# sh qoscodec 1QoS Codec Rules

ID : 1Codec : g711uToken Bucket Rate (0-1,000,000 bytes/second) : 10000Token Bucket Size (0-16,000 bytes) : 400Peak Rate (0-1,000,000 bytes/second) : 11000Maximum Packet Size (0-1,500 bytes) : 200Minimum Policed Unit (0-1,500 bytes) : 0Reservation Rate (0-1,000,000 bytes/second) : 1000Reservation Slack (0-1,000,000 microseconds) : 20000Packet Rate (0-200 packets/second) : 50QoS Protocol : sip



Debug why a call is not treated as QoS

4. Capture packet traces for the session on the controller. Use the command: controller# capture-packets -n -R "sip"

You will see something like:

There should be a symmetry of communication between the two devices.

5. Capture packet traces for the session on the AP. Use the command: controller# capture-packets -i apId -n -R "sip"

In this command, substitute the number of the AP you want to capture from for the term “apId”.

11.391697 192.168.10.131 -> 10.6.6.103 SIP Request: REGISTER sip:10.6.6.103 12.067072 10.6.6.103 -> 192.168.10.131 SIP Status: 200 OK (1 bindings) 17.190306 192.168.10.130 -> 10.6.6.103 SIP Request: REGISTER sip:10.6.6.103 17.717009 10.6.6.103 -> 192.168.10.130 SIP Status: 200 OK (1 bindings)

41.081454 192.168.10.130 -> 10.6.6.103 SIP/SDP Request: INVITE sip:[email protected], with session description 41.084611 10.6.6.103 -> 192.168.10.131 SIP/SDP Request: INVITE sip:[email protected], with session description 41.237828 192.168.10.131 -> 10.6.6.103 SIP Status: 180 Ringing 41.240878 10.6.6.103 -> 192.168.10.130 SIP Status: 180 Ringing 42.276537 192.168.10.131 -> 10.6.6.103 SIP/SDP Status: 200 OK, with session description 42.278801 10.6.6.103 -> 192.168.10.130 SIP/SDP Status: 200 OK, with session description 42.520909 192.168.10.130 -> 10.6.6.103 SIP Request: ACK sip:[email protected]:5060 42.524012 10.6.6.103 -> 192.168.10.131 SIP Request: ACK sip:[email protected]

Call Setup

Phone registrationon powerup

192.168.10.130 initiates a call

185

Appendix BResources


Additional References

Wireless Overview

General References

802.11 Wireless Networks: the Definitive Guide (2nd Ed.; 2004) by Matthew Gast

Wi-Foo: the Secrets of Wireless Hacking by Andrew A. Vladimirov, Konstantin V. Gavrilenko, Andrei A. Mikhailovsky (www.wi-foo.com)

Microsoft’s FAQ on Wireless LAN support in Windows: http://www.microsoft.com/technet/network/wifi/wififaq.mspx

Antenna References

The following are sites that have general information on antennas and their use.

TilTek at http://www.tiltek.com/technical/app_notes.html

Especially:

Antenna Seminar (PDF)

Astron Wireless at http://www.astronwireless.com/library.html

Especially:

Antenna Selection Made Easy

Understanding and Using Antenna Radiation Patterns

Cushcraft at http://www.cushcraft.com/comm/support/technical-papers.htm

Resources 187

Additional References

Especially:

Antenna Performance Issues for Wireless LANs

# In Building Propagation Measurements at 2.4 GHz

Times Microwave at http://www.timesmicrowave.com/cable_calculators/

Voice over IP (VoIP) and Quality of Service (QoS)

SIP Overview

http://www.iptel.org/ser/doc/sip_intro/sip_introduction.html

http://www.vnunet.com/networkitweek/features/2059672/rtfm-does-sip-work

Request for Comments (RFCs)

Bernet, Y., et.al., “A Framework for Integrated Services Operation over Diffserv Networks”, RFC 2998, November 2000.

Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. Weiss, “An Architecture for Differentiated Services”, RFC 2475, December 1998.

Wroclawski, J., “The Use of RSVP with IETF Integrated Services”, RFC 2210, September 1997.

Braden, R., Clark, D. and S. Shenker, “Integrated Services in the Internet Architecture: an Overview”, RFC 1633, June 1994.

Troubleshooting

Packet Sniffers

http://sectools.org/sniffers.html


Controller Discovery Process


This section contains a description of the discovery process that an AP goes though as it is booting up.

1. AP boots up and enters Layer 3 discovery mode unless it was configured as “l2-preferred.”

2. AP sends DHCP request.

3. If DHCP assigns address, then

a. AP sends DNS lookup for “wlan-controller”

b. If DNS does not reply with IP address then GOTO step 3, repeating for L3 discovery for a maximum of 16 seconds after which GOTO step 4 instead.

4. AP sends IP unicast discovery packet to Controller IP.

5. If Controller responds to discovery request:

a. AP and Controller perform mutual authentication and establish session key for encrypting management packets.

b. AP receives configuration settings from Controller and starts normal operation.

6. If no response from Controller, then GOTO step 4, repeating L3 discovery for a maximum of 16 seconds after which GOTO step 7 instead (unless AP configured for “l2-only” in which case we keep repeating L3 discovery).

7. AP reverts to Layer 2 discovery mode

8. AP sends broadcast L2 discovery packet

9. If Controller responds to discovery request

a. AP and Controller perform mutual authentication and establish session key for encrypting management packets.

b. AP receives configuration settings from Controller and starts normal operation.

10. If no response from Controller, then GOTO step 8, repeating L2 discovery for a maximum of 16 seconds after which GOTO step 2 instead (unless AP configured for “l2-only” in which case we keep repeating L2 discovery).

Resources 189


Capture vs. Forward Behavior

The rules for forwarding are sometimes called “static” rules in the documentation.

Three global options handle the case that bandwidth has been requested but is not available: Admit All: All QoS flows are allowed in the QoS traffic class anyway. This can

result in a degradation of the entire QoS traffic class.



Request Pending: The new QoS flows are moved to the best-effort traffic class. When enough bandwidth is released from other QoS flows, the flows that were placed in the best-effort traffic class are upgraded to the QoS traffic class.

Reject Request: Requests for resources are rejected, though not the flows themselves. QoS flows are permanently moved to the best-effort traffic class. If additional bandwidth is available at a later time, these QoS flows are not moved to the QoS traffic class, though new QoS flows would be allocated the available bandwidth.

Resources 191

Subnet Masks: CIDR to Octet Conversion


Meru System Port Usage

Note: Note the conflict with the Network Manager tftp port and other tftp servers that may be running on the customer’s infrastructure network.

CIDR value

Octet value Number of Addresses

20 255.255.240.0 4096

21 255.255.248.0 2048

22 255.255.252.0 1024

23 255.255.254.0 512

24 255.255.255.0 256

25 255.255.255.128 128

26 255.255.255.192 64

27 255.255.255.224 32

28 255.255.255.240 16

29 255.255.255.248 8

30 255.255.255.252 4

31 255.255.255.254 2

32 255.255.255.255 1

Service Port(s)

Aeroscout UDP/6091

Captive Portal TCP/8081



Captive Portal logout TCP/9090

E(z)RF Location Manager (requires capture-packets)

TCP/8003

E(z)RF Location Manager communication UDP/37008

E(z)RF Network Manager client server connectivity TCP/9090

E(z)RF Network Manager RMI TCP/1099

E(z)RF Network Manager SNMP traps UDP/162

ftp TCP/20 and TCP/21

HA keepalives UDP/9980

HTTP TCP/8080

HTTPS TCP/443

Inter-controller roaming UDP/9394

Meru L3 AP COMM UDP/5000

Meru L3 AP Data UDP/9393

Meru L3 AP Discovery/Keepalive UDP/9292

NP1 advertisements / config UDP/9980

NTP UDP/123

Radius accounting UDP1813 / 1646

Radius auth UDP1812 / 1645

IDS/Location Manager/capture-packets UDP/9177

SNMP UDP/161 and 162

SSH TCP/22

Syslog UDP/514

Telnet TCP/23

Service Port(s)

Resources 193

Packet Capture Filters


This table lists the syntax and common options to the capture-packets command.

capture-packets [-c count] [-f capture-filter] [-F file-format] [-i apId1[, apId2, ...]] [-N [-n] [-N {m,n,t}] ] [-p] [-q] [-r infile] [-R filter] [-S] [-s snaplen][-t r|a|ad|d] [-V] [-v frame] [-w savefile -a stop-condition] [-x]

TFTP/Network Manager tftp UDP/69

UDP broadcast up to upstream/downstream configurable UDP/xxx

Service Port(s)

Table 1: Options to the capture-packets command

-c count count specifies the default number of packets to read when capturing live data.

-i apId1[, apId2, ...] Captures packets from an AP (specified by its number), followed by optionally, a list of additional APs.

-n Disables network object name resolution (such as hostname, TCP, and UDP port names).

-N {m,n,t} Enables name resolution for particular types of addresses and port numbers, with name resolving for other types of addresses and port numbers turned off. The argument is a string that can contain the letters m to enable MAC address resolution, n to enable network address resolution, and t to enable transport-layer port number resolution. This argument overrides the -n argument if both -N and -n are present.

-q Do not display count of packets captured.



The following table lists the filters that can be used with the -R argument for the capture-packets command:

-r infile Reads in a previously captured file with an additional field (frame number) in the first column. Can be used with the -V option to examine the protocol tree.

-R ‘filter’ Applies a filter before displaying captures. See the table that follows for a list of filters you can use with this argument.

-S Record Record/summarize with frame number for playback.

-s snaplen snaplen defines the default snapshot length of live data.

-t r|a|ad|d Defines the format of the packet timestamp displayed in the packet list window. The format can be one of r (relative), a (absolute), ad (absolute with date), or d (delta). The relative time is the time elapsed between the first packet and the current packet. The absolute time is the actual time the packet was captured, with no date displayed; the absolute with date is the time the packet was captured. The delta time is the time since the previous packet was captured. The default is relative.

-V Prints the protocol tree.

-v frame Play back with frame number.

-w savefile -a stop-condition

Writes capture information to a file and limits the file size. The -w option must be the last one on the command line. We recommend that you use the -w and -a arguments together, using filesize:5000 as the stop-condition parameter, which limits the file size to 5 MB.

-x Displays packet capture in hexadecimal format.

Table 1: Options to the capture-packets command

Resources 195


Table 2: Useful Packet Filters

Filter String Description

wlan.bssid==00:0c:e6:01:00 Capture from a specific BSSID

wlan.addr==00:0c:e6:01:00 Capture from a specific wireless MAC address

eth.addr==00:0c:e6:xx:xx:xx Capture from a specific ethernet MAC address, either an AP or a client

ip.addr==10.220.3.15 Capture from a specific IP address

bootp Capture dhcp and bootp traffic

dns Capture DNS traffic

radius Capture RADIUS traffic

eapol Capture EAPOL traffic


Appendix CTroubleshooting References


Clients

Station Cannot See SSID or Associate

For some phones, RSSI is too low, or beacon period is not 100ms

Beacons are spaced far apart or colliding

Coordinator is 100% utilized

Client Cannot Authenticate with 802.1x

Controller not configured as client on RADIUS server

RADIUS secret mismatch

AP dropping packets (powersave mode or RF problem)

Captive Portal Clients Cannot Authenticate

Local vs. Remote setting for auth incorrect

Controller IP not added to RADIUS client list

User was not given remote access permissions in dial-in settings, or secret is mismatched

Max connections per username has been exceeded (either on server or in captive portal settings on controller)

Incorrect binding of radius profile to ssl server

Troubleshooting References 197

Clients

Clients Cannot get DHCP Address

Incorrect DHCP relay/passthrough settings

If wireless clients are in VLAN, VLAN settings not set correctly. Check:

override default DHCP server flag

DHCP server IP address

DHCP relay pass-through

DHCP range is not defined for VLAN range in DHCP server

Ping DHCP server from controller

Configure client to static (to prove this is a DHCP issue, not connectivity)

Ping out the VLAN interface using the following:

ping –I meru.<tag> <gateway IP address>

On controller, run

capture-packets -R bootp.dhcp

Voice Quality is Bad

Connection did not get QoS flow (port is not 5060, protocol is not SIP)

SIP interop issue (call does not complete, incoming call not received)

Performance in air is poor due to overload

Client is far away or RSSI (SNR) is low

Too many beacons/deauths (management) frames back-to-back


AP Troubleshooting

AP Troubleshooting

AP Problems

Disabled Offline

No LED: check PoE

LED red-green-red-blue: AP cannot discover controller

In L3 mode, make sure DNS entry is populated

AP150: attempt software reload manually

Disabled Online

Don't believe version on sh ap; go to AP and look at sys version (upgrade if version is inconsistent)

Look at trace log for issues

FPGA version mismatch (there is an AP alarm)

Manually upgrade AP (connect to AP if needed)

Other issues: collect diagnostics

Upgrading/Replacing APs

Identify AP, if needed

Set AP's LED Mode parameter to "blink"

Create an AP "swap table"

Maps configuration info from "old" MAC address to "new" MAC address

Preserves configuration information

Updates relevant parameters

Troubleshooting References 199

AP Troubleshooting

When the new AP discovers the controller, the “swap table” entry is automatically removed.

UI Problems

Cannot connect: make sure cookies are enabled

Pages don't refresh correctly: avoid caching web pages, set browser to “refresh on every visit”.

Frozen or unreachable UI (e.g. graphs and tables not updating): go to cli and run reload-gui.

UI error: Object does not support this object or method: ws is being killed in the middle of a request. Look at /opt/meru/var/log/ws.log and /opt/meru/var/log/monit.log

Deployment Issues

Look for AP siblings: too many can be a problem - contact support.

Look at HW Tx Power settings for range: less than 15dBm is a problem.

In multi-floor or dense material buildings, check with Support for antenna selection.

802.11a coverage is slightly different from 802.11bg coverage.

Look for large number of data clients when phones are on: there are bootscripts optimized for different situations.


Appendix DHardware Reference

This section contains portions of the documentation that you will find useful.

Controllers

The following sections describe the features on the specific Meru controller models.

MC5000 Features

The MC5000 blade can also be upgraded with the AMC accelerator module to increase the Ethernet port count to 4, and performance to 4 Gbps line rate.

Each MC5000 Controller blade in the chassis is configured and operates as a fully-functional, stand-alone Controller running System Director. Each Controller blade must be configured with a separate management IP address, as performed in the setup procedure in the Meru System Director Getting Started Guide. Dual Ethernet port functionality is supported if the second port is configured, as described in the Dual Ethernet feature in System Director documentation.

The MC5000 Controller Chassis is well suited for redundant controller configurations using either the standard N+1 feature (with 1 master and 1 backup controller) or the optional N+1 Redundant Controller feature (one slave controller for up to four master controllers). See the System Director documentation for details.

The MC5000 Controller Chassis for the Meru Wireless LAN System supports:

A maximum of five MC5000 Controller blades

Each MC5000 Controller blade supports a maximum of 200 APs, and with the optional accelerator module, a maximum of 300 APs

Complete support of System Director standard and optional features such as N+1 Redundant Controller, Dual-Ethernet, Per-User Firewall, and so forth.

Controllers can be configured and managed using the System Director Web UI.

Hardware Reference 201

Controllers

Figure 1: MC5000 Chassis Components (Front View)

Figure 2: MC5000 Chassis (Rear View)00

219

Fan Tray

Power Supply Bay

Shelf Manager MC5000 Controller Blade Slots

5

4

3

1

Grounding Plug

Fan Tray

2

00213

Power Port Input A

Grounding Screws

Input APower Switch

Input BPower Switch and Port


Controllers

MC4100 Features

The MC4100 controller supports medium and large-scale deployments with Ethernet network connectivity up to 4 Gbps line rate supporting as many as 300 Access Points and 3000 clients.

Figure 3: MC4100 Chassis (Front view)

Use the ports marked G1 through G4 for management, control, and data. At this time, you cannot place a management address for out of band management on the X1 or X2 ports. These ports are for future use.

Port bonding is configured using the command bonding single (for all ports into a single logical port of 4G) or bonding dual (for 2 ports each with 2G where G1-G2 are bonded together and G3-G4 are bonded together). Logically, after bonding the ports are the same as the current MC1000/MC3000 where there are either 1 or 2 Etherports for N+1.

The USB port is used for recovery purposes.

When power is on, the LCD screen and LCD buttons glow blue. Use the four LCD buttons to navigate through the LCD functions illustrated below in Figure 4.

MC 4100

USB CONSOLE X1 X2

G1 G2 G3 G4

0022

0

G1 G2 G3 G4

Power USB

LCD

1G EthernetLED

LinkIndicator Indicator


Activity

Activity

Ports (X1, X2)future use

Powerindicator

Port DB9SerialConsolePort


Controllers

Figure 4: LCD Navigation Tree

The first time that MC4100 is turned on, you must turn on the two back power switches shown below before powering on with the power button on the front panel.

Figure 5: MC4100 Back

4 Fans - 2 per power supply

2 Power 2 On/Off Power Connectors Switches

0022

1


Controllers

MC3000 Features

The MC3000 wireless LAN controller is designed for large-scale enterprise deployments and provides comprehensive security, gigabit scalability in its Ethernet interface, service flexibility, and reliable performance. The MC3000 can support up to 150 APs.

Figure 6 and Figure 7 show the front and the back of the MC3000, respectively.

Figure 6: MC3000 Controller Front Panel

Figure 7: MC3000 Controller Back Panel

0002

0

LCD Informational Panel

Navigational Keys

10/100/1000

Ethernet PortG1

Ethernet Port

10/100/1000

Serial Port

G1 Speed

Power/StatusLEDs

G2 (reserved)

Up Arrow

Left Arrow

Down Arrow

RightArrow

Activity/Link LEDs

G2 Speed Activity/Link LEDs(reserved)

Powerinlet

Powerswitch

Air Outlets


Controllers

MC1500 Features

The MC1500 is designed for small to medium-scale site deployments, such as small offices or remote branch sites. It supports customers requiring Layer 1-4 security, Fast Ethernet, and affordable performance. The MC1500 can support up to 30 APs.

The MC1500 measures 16.7x1.1x10.6 inches. The front and back of the MC1500 are shown below.

Figure 8: MC1500 Front Panel

Figure 9: MC1500 Rear Panel

00228

USB Ethernet

LEDs:

ActivityIndicators Indicators

Link

Ports

PowerStatus (not used)

Ports ConsolePort

hard disk drive (not used)

00

22

9PowerSwitch

PowerConnector

Fans


Controllers

MC1000 Features

The MC1000 controller was optimized for medium-scale enterprises and education customers providing Layer 1-4 security, gigabit Ethernet interface scalability, and affordable performance. At this writing the MC1000 is not available for purchase.

The MC1000 controller supports up to 30 APs.

The front and back of the MC1000 are shown in Figures 10 and 11.


Figure 11: MC1000 Controller Back Panel

10/100/1000

LINK/ACT

LCD Informational Panel

Navigational Keys

10/100/1000

Ethernet PortG2 (reserved)

Ethernet Port

10/100/1000

Serial Port G1 Speed

Power/StatusLEDs

G1

Up Arrow

Left Arrow

Down Arrow

RightArrow

Link/Activity LEDs

G2 SpeedLink/Activity LEDs(reserved)

Powerinlet

Powerswitch

Air Outlets


Controllers

MC500 Features

The MC500 controller was designed for small-scale site deployments, such as small offices or Remote branch sites. It supports customers requiring Layer 1-4 security, Fast Ethernet, and affordable performance. The MC500 controller can support up to 5 APs. At this writing the MC500 is not available for purchase.

The MC500’s small footprint is 1.3" H by 9.5" W by 5.8" D and it is powered by an external power brick. The front and back of the MC500 are shown in FIgures 12 and 13.


Figure 13: MC500 Controller Rear Panel

Comparison of Controller Features

A comparison of the features for the various controllers is provided in Table 1.

0016

4

Power LED

Power On/Off Button

LAN1 Speed/Activity LED

LAN2 Speed/Activity LED(reserved)

0016

3

Power Inlet Serial Port

LAN1 10/100 Ethernet Port

LAN2 10/100 Ethernet Port(reserved)

Reset Button


Controllers

SA1000 Features

The SA1000 appliance is used to run the E(z)RF Network Manager and E(z)RF Location Manager products.

Figure 14: SA1000 Chassis (Front view)

Use the pors marked X1 for management, control, and data. At this time, you cannot place a management address for out of band management on the X1 or X2 ports. These ports are for future use.

Port bonding is configured using the command bonding single (for all ports into a single logical port of 4G) or bonding dual (for 2 ports each with 2G where G1-G2 are bonded together and G3-G4 are bonded together). Logically, after bonding the ports are the same as the current MC1000/MC3000 where there are either 1 or 2 Etherports for N+1.

The USB port is used for recovery purposes.

Table 1: Controller Feature Comparison

Controller Model Number of Ethernet Connections

Number of Supported APs

MC500 1 (supporting 10/100 Mbps) Up to 5

MC1000/MC15001 (supporting 10/100/1000 Mbps)

Up to 30

MC30001 (supporting 10/100/1000 Mbps)

Up to 150

SA 1000

USB CONSOLE X1 X2 0022

2

Power USB

LCD

1G EthernetLED


Activity

Ports (X1, X2)Powerindicator

Port DB9SerialConsolePort


Controllers

When power is on, the LCD screen and LCD buttons glow blue. Use the four LCD buttons to navigate through the LCD functions illustrated in the following tree.

Figure 15: LCD Navigation Tree

The first time that the SA1000 appliance is turned on, you must turn on the two back power switches shown below before powering on with the power button on the front panel.

Figure 16: SA1000 Back

4 Fans - 2 per power supply

2 Power 2 On/Off Power Connectors Switches

0022

1


Access Points

Access Points

AP150 Connectors

Figure 17: AP150 Connector Panel

AP150 Status LEDs

The following illustrations depict the AP 150 access point.

Four LEDs on the face of the AP150 indicate status, as shown below..

Figure 18: AP150 Status LEDs

ANT1 ANT2

LANDC 5V CONSOLE RESET RELOAD

0017

3

Power Ethernetconnection

Consoleport Reset

buttonReload

Antenna 1 Antenna 2

(reserved) (reserved)

PWR

LAN

RADIO2

RADIO1

Status LEDs

0016

6


Access Points

When the AP150 is first connected to the controller and any time the access point is rebooted thereafter, the AP initializes with and then is programmed by the controller. The Status LED (see above) color reflects the various operating states (see the table below).

Table 2: AP150 LED Descriptions

LED Function

Power The Power status LED status is as follows:

off—power is off

solid red—when power is applied, system initializes for 40 seconds and then the LED turns amber; after discovering the controller the LED turns green. Otherwise, the system is in an abnormal state (notify Customer Support).

solid amber—at any time, if this LED state persists longer than 40 seconds, notify Customer Support

solid green—system is fully operational

Radio I The Radio I LED is lit when radio packets are being transmitted and when the radio is beaconing.

Radio II The Radio II LED is lit when radio packets are being transmitted and when the radio is beaconing.

Ethernet The Ethernet LED status is as follows:

off—no link

solid green—100Mbps connection

blinking green—transmit or receive activity at 100Mbps

solid amber—10Mbps connection

blinking amber—transmit or receive activity at 10Mbps


Access Points

AP180 (OAP180) Connectors

Figure 19: OAP180 Connectors

AP180 Status LEDs

Figure 20: OAP180 LEDs

The grey LEDs in the illustration are not currently used. The following chart explains the meanings for the remaining LEDs.

0019

5

Top panel view Bottom panel view

ConsolePort

ConsolePort CoverAttachment

Ethernet/PoEConnector

2.4G 2.4G5G 5G

N-Type ExternalAntenna Connector(5 GHz)

N-Type ExternalAntenna Connector(2.4 GHz)

Console PoE

Water-TightTest Point

0019

4

Console PoE

Ethernet linkLED

Power OnLED

These 4 LEDsare not used

Transmission LEDs (radio packets transmitting)


Access Points

Table 3: AP180 LED Description

AP201/208 Connectors

Figure 21: AP201/208 Connector Panel

Note: DC input is only available on Rev 1 AP200s.

LEDs Function

Power When power is applied to the system this LED initially turns amber, then blinks green when the system power check is applied, and then is a steady green when power is on.

The Ethernet Link LED blinks green when a link has been detected and is in use.

The 11bg connection LED blinks amber when radio packets are being transmitted and when the radio is beaconing. If there is traffic over the air on this radio, the blinking rate increases.

Ethernet Link

Radio 1 11bg

Radio 2 11a

The 11a connection LED blinks green when radio packets are being transmitted and when the radio is beaconing. If there is traffic over the air on this radio, the blinking rate increases.

CONSOLEANT 1 ANT 2

3.3 VDCETHERNET

0010

8

100/1000Ethernet

(Reserved) Console

portAntenna 1 Antenna 2Power

inlet

Reset (Push to restore default settings)

(Currently unsupported)


Access Points

AP201/208 Status LEDs

Four LEDs on the face of the AP201/208 indicate status, as shown below...

Figure 22: AP200 Status LEDs

The functions of the status LEDs are described in the table below.

When the AP200 is first connected to the controller and any time the access point is rebooted thereafter, the AP initializes with and then is programmed by the controller. When the AP is first powered up, all LEDs are green. Thereafter, the Status LED (see the figure above) color reflects the various operating states (see the table below).

AP200

RF2

RF1

STATUS

POWER

00

11

3


Access Points

Table 4: AP201/208 LED Descriptions

Table 5: AP201/208 Controller Status Information

LED Function

RF 2 The status LED for Radio 2 is a follows:

off—no radio present

yellow—radio initializing

red—radio failure

solid green—radio OK

blinking green—radio activity

RF 1 The status LED for Radio 1 is a follows:

off—no radio present

yellow—radio initializing

red—radio failure

solid green—radio OK

blinking green—radio activity

Status AP-Controller operational status (see Table 5)

Power green—presence of power

State Interpretation AP201/208 LED Cycle

Attempting to discover Controller

In the process of discovering the controller. The AP is connected but not associated with the con-troller. If the AP does not associate with the con-troller after a period of time, verify that the connection between the AP and the switch or the switch and the controller is unbroken.

Green/Red/Blue/Red

Connected Normal operation without security. Blue/Blue/Blue/RedBlue/Blue/Blue/Red, for 2 seconds.

Authenticated Normal operation with security. Blue blinka

Disconnected Access point was once connected to a controller and configured by the controller, but can no longer find that controller

Green/Purple/Green/Purple

Standalone Access point is operating in a standalone mode Purple blink


Access Points

How to Identify AP 200 Revision Number

There are three ways in which customers can identify the AP revision:

• Using CLI

• Using Web UI

• Physically looking at the AP

Using CLI

Use the command show interfaces Dot11Radio at the Controller command line interface prompt to identify whether the AP is Rev1 or Rev2. In the command output, look at the “Radio Type” parameter and compare it with values in Table 2. In the sample screen capture below, the Radio Type shows RF2. Comparing it with the values in Table 2 indicates this is a Rev1 AP.

controller# show interfaces Dot11Radio 2 1Wireless Interface ConfigurationAP ID : 2AP Name : AP-2Interface Index : 1AP Model : AP201Description : ieee80211-2-1Administrative Status : UpOperational Status : EnabledLast Change Time : 2007/01/05 14:12:23Radio Type : RF2MTU (bytes) : 2346….

Downloading Downloading image or configuration from the controller

Green/BlueGreen/Blue

Error State Access point is in an error state.

Call Meru technical support

Red (blinking or solid)

a. The AP200 LEDs cycle from bright to dim for each “blink.”

State Interpretation AP201/208 LED Cycle

Radio Type AP Revision

RF2 Rev1

RF4 Rev2

RFxx Rev3


Access Points

Using the Web UI

The Web UI can also be used to identify whether the AP is Rev1 or Rev2. Look at the “Radio Type” parameter and comparing it with values in the table above.

From the Web UI, go to the Detailed -> Configuration -> WLAN Wireless Interfaces -> settings for interface 1 of AP200 and check the value.

Physically Looking at the AP

There is no DC input available on the Rev2 APs. Therefore, if the AP is missing the DC input, it is a Rev2 AP.

AP300 Ports and Connectors

The AP300 features the following ports and connectors:

10/100/1000 Ethernet port, copper

1 Serial console port (reserved)

DC power input (5 Volts)

6 RPSMA external antenna connectors

Figure 23: AP300 Connectors

A5

A6

5V DCCON LAN

00209

Ethernet Port

serialport

power antenna (5 of 6)

antenna (6 of 6)

lock reset


Access Points

AP300 Status LEDs

After the AP300 is connected, the LEDs should light

Figure 24: AP300 LED Location

The functions of the five LEDs are described below.

When the AP300 is first connected to the controller and any time the access point is rebooted, the AP initializes with and then is programmed by the controller. When the AP is first powered up, all LEDs are green. Thereafter, the Status LED color reflects the various operating states described in below.

A3

A2

L AN

S T

TAP

WR

R F1

R F2

0021

7

PWR

STAT

LAN

RF1

RF2


Access Points

Table 6: AP300 LED Descriptions

LED Function

Poweroff—no powergreen—presence of power

Status

off—no powergreen—booting stage 1blinking green and off—booting stage 2blinking green and white—discovering the controllerblinking green and blue—downloading a configuration from the controllerblinking blue and off—AP is online and enabled, working stateblinking red and yellow—failure; consult controller for alarm state

LAN

off—no power, or no linkgreen—link status OK (at any speed)green/blinking—activity (at any speed)red—auto negotiation failure

Radio 1Radio 2

off—no radio presentgreen—radio enabledgreen blinking—data activityyellow—disabled or in scanning modered—failure


Access Points

RS4000 Connectors

Figure 25: RS4000 with Antenna Attached

RS4000 Status LEDs

LEDs on the face of the RS4000 indicate status, as shown below..

Figure 26: RS4000 Status LEDs

K

0018

2

ANT1 ANT2

ETH1

ETH2

ANT1ANT2

(Meru logo is upside down)

POWER

RADIO I

RADIO II

ETHERNET

POWER

RADIO I

RADIO II

ETHERNET

00185

Status LEDs


Installing the MC5000 Controller Chassis

The RS4000 uses 4 LEDs. The functions of the status LEDs are described the table below.

Table 7: RS4000 LED Descriptions


Perform the procedures in the following sections to install and configure the MC5000 Controller Chassis.

The MC5000 Controller Chassis can be set on a flat surface or rack-mounted in a standard 19” telco rack.

The MC5000 Controller blades and Chassis frame are packaged separately. For the initial installation, use the following procedure:

LED Function

Power The Power status LED status is as follows:

off—power is off

solid red—when power is applied, system initializes for 40 seconds and then the LED turns amber; after discovering the controller the LED turns green. Otherwise, the system is in an abnormal state (notify Customer Support).

solid amber—at any time, if this LED state persists longer than 40 seconds, notify Customer Support

solid green—system is fully operational

Radio I The Radio I LED is lit when radio packets are being transmitted and when the radio is beaconing.

Radio II The Radio II LED is lit when radio packets are being transmitted and when the radio is beaconing.

Ethernet The Ethernet LED status is as follows:

off—no link

solid green—100Mbps connection

blinking green—transmit or receive activity at 100Mbps

solid amber—10Mbps connection

blinking amber—transmit or receive activity at 10Mbps



1. Unpack the shipping containers and verify the following items are included:— Chassis frame with installed Shelf Manager card(s), 2 fans, and power supply

— Chassis power cord

— Number of blades ordered

— Release 3.4 documentation CD

2. Install the chassis in a 19” standard rack, if so desired. The following must be considered when installing the chassis in a rack:— Elevated Operating Ambient Temperature—If installed in a closed or multi-unit rack

assembly, the operating ambient temperature of the rack environment may be greater than room ambient. Therefore, consideration should be given to installing the equipment in an environment compatible with the manufacturer's maximum rated ambient temperature (Tmra) of 40oC (104oF).

— Reduced Air Flow—Installation of the equipment in a rack should be such that the amount of air flow required for safe operation of the equipment is not compromised.

— Mechanical Loading—Mounting of the equipment in the rack should be such that a hazardous condition is not created due to uneven mechanical loading.

— Circuit Overloading—Consideration should be given to the connection of the equipment to the supply circuit and the effect that overloading circuits might have on overcurrent protection and supply wiring. Appropriate consideration of equipment nameplate ratings should be used when addressing this concern.

— Reliable Earthing—Reliable earthing of rack mounted equipment should be maintained. Particular attention should be given to supply connections other than direct connections to the branch circuit (such as using a power strip and so forth).

a. To install MC5000 chassis in rack:Move the MC5000 chassis to the rack or cabinet where it will be installed. Remove any packing materials from the chassis.

b. Lift the MC5000 into position and attach the chassis to the rack rails. Ensure that all mounting screws (both sides) are installed to secure the MC5000 to the mounting rails.

3. Attach a ground wire to the chassis and to a grounded location.

4. To install an MC5000 blade:

a. To properly ground yourself, attach a grounding strap to the grounding plug on the front (top left corner) of the MC5000 chassis.

b. Slots are numbered starting with 1 on the bottom and 5 on top, below the Shelf Manager. For the slot where the MC5000 blade will installed, remove the filler panel. Store the filler panel in a safe place.

Warning! Installing an MC5000 chassis is a 2-person task. The base chassis with filler panels weighs 50 pounds, and a fully loaded chassis weighs up to 75 pounds. At least 2 installers are required to do this task safely.



c. Insert the MC5000 blade by following the directions MC5000 Blade Insertion and Removal.

5. Connect the first Ethernet cable to the primary Ethernet port (the left-most Ethernet port) on the front of the MC5000 blade and to a switch, as described in the Installation and Quick Start Guide.

Figure 27: Primary and Secondary Ethernet Ports

If a secondary Ethernet connection is required, connect it to the Ethernet port indicated in Figure 1. The MC5000 blades can be configured to the same subnet or different subnets, depending on the type of network configured that is required.

6. Connect the power cord to the Input A receptacle on back of the chassis and to the wall AC power source. (Input B is used if the optional power supply has been purchased.)

7. Power up the chassis by flipping the On/Off switch on the back of the chassis to On. Ensure that the fans are running, and cool air is flowing through the chassis.

8. Perform controller configuration as described in the Installation and Quick Start Guide.

Caution!

Electrostatic Discharge—The blades contain ESD-sensitive devices, and can be damaged if not handled in accordance with approved ESD guidelines. Do not remove any blade from its ESD packaging until you are ready to install it in the MC5000 chassis.

Caution! Seating this blade properly can be tricky. Be sure to look at the directions.

primary

primary

secondary



About the Shelf Manager

The shelf manager monitors the power, cooling and operation of the chassis. Status is visible via the LEDs located on the shelf manager blade and on the Shelf Alarm Panel, located in the center of the Shelf Manager blade.

The Shelf Manager LED location and status are shown in the following figure. The green LED, shown in location 9 in the following figure, displays with normal operation.

Figure 28: Shelf Manager Status LED Location and Description



Checking the Shelf Manager Alarm Panel LEDs

The LEDs on the Shelf Manager Alarm Panel convey status about chassis alarms. The following shows the location of the LEDs and the serial ports on the Shelf Manager Alarm Panel:

Figure 29: Shelf Manager Alarm Panel LEDs

Serial and Alarm Card Relays

The incoming signals for the alarm board are SELV and are not more than 30V dc/1A the rating for the contact.

MC5000 Blade Insertion and Removal

To install a card in a chassis:

1. Remove the filler panel of the slot.

2. Ensure the board is configured properly.

3. Carefully align the PCB edges in the bottom and top card guide.

4. Insert the board in the system until it makes contact with the backplane connectors.

5. Using both ejector handles, engage the board in the backplane connectors until both ejectors are locked.

6. Fasten screws at the top and bottom of the faceplate.

To remove an MC5000 blade:

1. Unscrew the top and the bottom screw of the front panel.

2. Unlock the lower handle latch. This may initiate a clean shutdown off the operating system.

3. Wait until the blue LED is fully ON; this means that the hot swap sequence is ready for board removal.

Caution!

Electrostatic Discharge—The blades contain ESD-sensitive devices, and can be damaged if not handled in accordance with approved ESD guidelines. Do not remove any blade from its ESD packaging until you are ready to install it in the MC5000 chassis.


Controller Installation

4. Use both ejectors to disengage the board from the backplane.

5. Pull the board out of the chassis.

Controller Installation

The form factor for the MC3000 and MC1000 controllers are 1U chassis that have been designed for a 19" rack. The MC4100 has a 2 U chassis. Airflow enters from the front chassis and exits through the back. Care should be taken to ensure that there are no obstructions around the controller chassis that could reduce or block airflow.

The MC500 is a mini-desktop unit that may be placed in a convenient location in a small office or data center. The MC500 is powered by a separate power adapter.

To install the controller:

1. If you opt to install the controller in a rack, choose a location in the rack that accepts the clearance for a 1U high chassis.

2. Insert the chassis into the chosen rack location and mount the unit.

3. Make the ground connection.

4. Ensuring proper ground should always be the first connection to the controller during installation.

5. Connect the power cord to the chassis and a wall outlet.

Note: The power cord(s) provided with the Meru controllers is for use only with that Meru Networks product. It is not for use with any other Meru Networks product or other brands of equipment.

6. Press the power switch to the On position for the MC500, MC1000 and MC3000. For the MC4100, first turn on both power supplies on the back of the chassis (see Figure 5:), then press the power button on the front left of the unit.If the MC4100 beeps continuously, you have not turned on all 3 switches.

For the MC1000 and MC3000, the Power On System Test runs and completes with one of the following codes, depending on the system status.

Table 8: MC1000 and MC3000 POST Results

Beep Code Description

1 Short beep Normal POST, controller status is normal


Powering Off the Controller

The hardware installation is now complete.

Powering Off the Controller

Should it become necessary to power off the controller, it is recommended you use the CLI command poweroff controller before switching the controller off with the Power On/Off switch. The command gracefully brings the controller down to a state where power can safely be removed using the power switch.

LED Status Indicators

Monitor the status of the controller and the Ethernet connection using the various LED status indicators, located on the front of the chassis.

2 Short beeps CMOS error

One long and one short beep DRAM error

One long and two short beeps Video (Mono/CGA Display Circuitry) issue

One long and three short beeps

Keyboard/Keyboard card error

One long and nine short beeps

ROM error

Continuous long beep DRAM problem

Repeating short beeps There are some problem with the Power source.

Table 8: MC1000 and MC3000 POST Results

Caution! Failure to use the poweroff controller command before removing power from the controller can cause Flash card corruption and result in the controller becoming non-operational.



Controller LED Status Indicators

The controller status indicator LEDs are located on the front of the chassis, as shown in the figures in the previous chapter. The description of the LED states are shown in the following tables.

Table 9: MC4100 LED Status Information

Each of the MC4100 G1-G4 ports has a link LED on the right of the port and an activity LED on the left of the port. There is also a solid green light to the right of all four ports that indicates the power of the network accelerator (this should always be solid green).

LED Color Description

Power

Unlit

Green solid

Red solid

Unit is off

Unit is on, power good

Unit is on, but one of the dual-redundant power supplies has a failure and needs to be replaced.



Table 10: MC1000 and MC3000 LED Status Information

Table 11: MC500 LED Status Information

Ethernet LED Status Indicators

The RJ-45 connector provides information about the Ethernet connection.


PowerAmber SolidUnlit

Powered onPowered off

StatusUnlitGreen

UnimplementedUnimplemented

G1 10/100/1000

UnlitGreen solidAmber solid

LAN Speed 10 MbpsLAN Speed 100 MbpsLAN Speed 1000 Mbps

Link/ActUnlitGreen solidGreen blinking

Link Down/ No ActivityLink UpRx/Tx Activity


PowerGreen blinkingGreen solidUnlit

Powered onWhile booting or after shutdownPowered off

100UnlitRed solid

100 Mbps Link Down100 Mbps Link Up

10UnlitRed solid

10 Mbps Link Down10 Mbps Link Up

ActUnlitAmber blinking

No ActivityRx/Tx Activity



Figure 30: RJ-45 Status Indicators

Table 12: Ethernet Status Information

Navigating the Status Panel Information

The MC1000, MC3000, and MC4100 LCD status panels on the front of the chassis displays information about the system and the network. The following diagrams show the structural organization of the information. Use the up and down navigational buttons to move from one level to the next and the left and right buttons to move through items on the same level.

LED Activity Description

Network Status

Green solid Network connection

Green blinking Network activity

Port Speed

Off 10 MB/second

Green 100 MB/second

Yellow 1000 MB/second

Ethernet activityLink present

0012

9

Note: The layout of the navigational buttons are not intuitive. For example, the button pointing up moves left and the button pointing down moves up; the button pointing right moves down and the button pointing left moves right. Refer to Figures 31 and 32 for a description of these buttons.



Figure 31: Navigating the MC1000 and MC3000 Status Panel Information

Figure 32: Navigating the MC4100 Status Panel Information

System IDSerial

NumberSoftwareVersion

PhysicalAddress

DefaultGatewayHost Name IP Address

Network MenuRunning SystemMenu

Controller Information

Meru Networks, Inc.MC1000 or MC3000

Date and Time

Up

Arro

w K

ey

Dow

n Ar

row

Key

Left or Right Arrow Key

0010

6


Module EWireless Overview

In this module, you’ll get to demonstrate your knowledge of wireless terms and concepts. A grounding in this information is important for understanding how a Meru network differs from ordinary wireless networks.


Compare and contrast wired and wireless networks

Wireless Overview 235

How Does 802.3 Wired (Ethernet) Work?

How Does 802.3 Wired (Ethernet) Work?


How does 802.3 Wired Work?

Basic 802.3 Ethernet CSMA/CD Layer2 Fundamentals

- MAC-to-MAC address communication- Bridging

Layer3 Fundamentals- IP-to-IP address communication- Routing


How Does Wireless Work?

How Does Wireless Work?


How does 802.11 Wireless Work?

Basic 802.11 “WiFi” Similar to, but not Ethernet (802.3)

- Uses same MAC addr format- 4 used: Source, Destination, Transmitter, Receiver

CSMA/CA- Collision Avoidance comes at a cost- But using Collision Detection would be worse

Simple AP acts as single 802.3<->802.11 bridge Multi-APs acts as single 802.3<->802.11 bridge Controller/Multi-APs act as single 802.3<->802.11

bridge 802.11 has unique packet types (only “seen” in

the air)


Radio Review

Radio Review


Radio Review - 1

Radio Frequency (RF) Channels A channel is a specific chunk of RF spectrum 802.11 b/g has 14 “unique” but overlapping

channels*

* Actual total number varies by country

Channel 1

Total 802.11b/g Allocated Spectrum

Channel 2

Channel 3

Channel 4

Channel 5

Channel 6

Channel 7


Radio Review


Radio Review - 2

Interference Created by using two ________ channels Interference shows up as __________

- Wave Applet

Antennas Change _______ ________ _______ the radio signal

Power levels and limits Equals transmit power _____ antenna gain Are __________ regulated


Antennas

Antennas


Antennas

Create a shaped 3-dimensional field

Effective radiated power (ERP) changes with different antennas


Wireless Terminology Review


BSS – Basic Service Set A set of stations that ________________________________ A BSS is identified by its BSSID, typically this is the

________________________________ of the AP. A set of stations that ________________________________ ESS – Extended Service Set Created by combining BSSs with a ________ Mobile connections preserved as long as the ________backbone is an

________L2 subnet or ________VLAN Advantage here is the ability to

________________________________________ Identified by an id called ________



BSS

ESS


Association Process Review




Scanning Beacons from AP Probe request from

station for specific SSID, probe response from AP

JoiningAssociation

Authentication






Controller authenticates None (“clear”) WEP MAC address filtering WPA-PSK (“Personal WPA”)

Third-party (e.g. RADIUS) authenticates WPA, WPA2 802.1x

- Username/password- MAC address



802.1x Authentication Concepts


802.1x Authentication Concepts

Supplicant

Authenticator

Authentication Server

EAP Traffic(only seen in 802.11 frames)

RADIUS Traffic(only seen in 802.3 frames)


Rogues

Rogues


Security: Rogues

An AP that is not authorized to connect to the network (ESS) is called a “rogue”.

Rogues are possible entry points into your network.

Meru includes software to detect and mitigate rogues.


Comparison of Wired LANs and Wireless LANs (WLANs)

Comparison of Wired LANs and Wireless LANs (WLANs)


How are Wireless LANs (WLANs) Similar to (wired) LANs?


What’s Different with Wireless?




Shared medium

Connect “anywhere” Ethernet switch vs. radio transceiver

Roaming Association is a more dynamic process “Handoff” must be < 30msec for VoIP

(most ordinary handoffs are > 50msec)



Physical Media



Range

Interference

Channels 3 for 802.11b/g (at any one time) 8-19 for 802.11a (all available)



Contention for Shared Medium


Contention for Shared Medium

Number of Contenders (Devices in interference range)

20

Tot

al B

andw

idth

at

Pea

k (M

bps)

5

8

11

1

3

Baseband + Protocol overhead

802.11b Peak Aggregate Throughput in Single Cell Environment

Contention Limits Throughput and User Density in Traditional 802.11 Networks

• Peak aggregate capacity of 5-6 Mbps with 3 or fewer contending stations

• Very limited user density– Capacity drops precipitously to

<1Mbps with ~10 contending stations– Effective lack of connectivity with 20 stations

Standard CSMA Curve

• CSMA (Ethernet and 802.11) designed for low contentionand low load

• Contention penalty in 802.11 is even worse because there is no collision detection; all transmissions must be acknowledged

ContentionLoss



Mixed b/g Client Effects


Mixed b/g Client Effects

From Mathew Gast: http://www.oreillynet.com/pub/a/wireless/2003/08/08/wireless_throughput.html



Co-channel Interference


Co-Channel Interference

SignalStrength

Distance

-68dBm

-95dBm

54Mbps

1Mbps

There are 3 non-overlapping channels in 802.11b/g(Ch 1, 6, 11)

x x

x

xx

x



11n Effects


802.11n Coverage and High Data RatesCan Fluctuate

11a/b/g: Coverage Doughnut-like

11n: Coverage Porcupine-like

Illustrative




Typical Coverage Pattern for 802.11n Rate/Range is Unpredictable

Highrate

Lowrate

Sample coverage from an 802.11n installation



Ordinary Wireless Roaming



As Station A is associated with AP 1 and decides to move away from AP 1.


Channel 6 Channel 1

Station A





Channel 6 Channel 1


When a (low) signal threshold is passed, a sweep starts. Station A maintains its association to AP 1 since no

other AP offers a better signal (following a sweep)

Station A





Channel 6 Channel 1


Station A now sees AP 2 offers a better signal and is a different BSSID on the same ESSID

Station A now creates an association with AP 2

Station A




Ordinary Wireless Roaming Summary

For a station to begin to seek out another AP, the signal strength must fall below a set threshold

Once in the sweep mode, only other APs with the same Network Name (SSID) will be considered

Once a better signal is found then an association will be made with that AP

The station is in control of association, but it can’t make good throughput decisions!


The Four Problems of Wireless





Mixed b/g clients




Index

Numerics802.1x authentication concepts 245

Aadding

ESSIDs (CLI) 101guest users 27security profiles (CLI) 100VLANs (CLI) 102, 103

APsbroadcast specific ESSes 104capturing packes from 163defining ESSes for 55ESS distribution on 104replacing 29upgrading 29, 41

APs. See also rogue APsauthentication

802.1x concepts 245RADIUS 109wireless methods of 51, 244

Bbacking up configuration files 43, 46backing up configuration files, described 33, 34BSS, described 242Bulk Update button 45

Ccaptive portal, described 138capture directory 159capture packets

IDS method 167capture-packets

location of saved files 159CLI

command reference 175commands

CLI reference 175do show 101

Configuration button, location 57configuration files

backing up 33, 34, 43, 46restoring 59

configurationssaving with the CLI 43saving with the Web interface 43

configuringrouters for wireless VLANs 54

Controllerscopying system software 40displaying configuration of (CLI) 44initial configuration of 39powering off 25turning off 25

copyingsystem software 40

creatingESSIDs (CLI) 101ESSIDs (WebUI) 57security profiles (CLI) 100security profiles (WebUI) 57VLANs (CLI) 102VLANs (WebUI) 58

Ddisplaying

QoS performance characteristics with CLI 106

QoS performance characteristics with Web interface 106

do show command 101

EESS table, configuring 55ESSes

broadcast from specific APs 104described 242distribution on APs 104

ESSIDsadding (CLI) 101creating (CLI) 101creating (WebUI) 57

Gguest users, adding 27guest-user command 27

Index 261

26

IIDS method of capturing packets 167initial setup, procedure for 38

Llines, displayed in terminal window 167login accounts, default 26

MMonitor button, location 58

Ppassword, resetting a controller 26powering off a controller 25

QQoS

actions 92, 93QoS performance characteristics, displaying

with CLI 106QoS performance characteristics, displaying

with Web Interface 106

RRADIUS authentication process 109RADIUS protocol example, illustrated 109replacing, APs 29resetting a controller password 26restoring a Controller configuration 59rogue APs

described 246See also APs

routers, configuration for wireless VLANs 54

Ssaving configurations

with the CLI 43with the Web interface 43

security profilesadding (CLI) 100creating (CLI) 100creating (WebUI) 57default 50

setup command, described 23setup command, running the 39sniff command 163system configuration files

backing up 43, 46system software

copying to controller 40upgrading 40

Ttag numbers, VLAN 102terminal length setting 167terminal windows, length setting of 167troubleshooting

RADIUS protocol example 109troubleshooting VoIP 183turning off a controller 25

Uupgrading

access points 29APs 29, 41system software 40

VVLANs

adding (CLI) 102, 103adding to an ESSID (CLI) 103creating (CLI) 102creating (WebUI) 58routing configuration 54tag numbers 102

VoIPintroduction 84troubleshooting 183

WWeb interface, starting the 41


basic participant

Documents