20 Configuring Wireless Technologies Flashcards
Stand-Alone Model
Autonomous APs use the same internetworking operating system (IOS) that your Cisco routers do, except they also have more wireless features built into the code. You configure them individually, and there’s no centralized administration point. And let me tell you—managing several Autonomous Access Points can get out of control fast because not only do you have to keep the configuration consistent between the AAPs. You also have to manually handle the security policies on each one and also potentially tune the wireless channels and features to improve performance and reliability—no small thing! Cisco came up with a couple of solutions that focused on helping with configuration and management issues, but those fixes are nothing compared with the lightweight solution. I’ll only talk about them briefly here. Basically, you can configure a feature called Wireless Domain Services (WDS) on an AP or Cisco switch that will allow for at least some crumbs to centralize services for autonomous APs. There’s also an older solution called the Wireless Solution Engine (WLSE) that can give you limited centralized control and monitoring.
Lightweight Model
Practically every the issue with the standalone model can be solved with central management! With centralized management, a controller can push configurations to APs and also intelligently tune the wireless performance for you since it can see the bigger picture of the wireless network. The CUWN lightweight model definitely requires centralized control, which we gained via Cisco WLAN controllers (WLCs)… more on these in a bit. For now, know that APs are controlled and monitored by the WLC. All clients and APs transmit information back to the WLC, including stats about coverage, interference and even client data. Figure 20.2 illustrates the lightweight model. All transmitted data is sent between the APs and the WLCs via a mouthful of an encapsulation protocol called Control And Provisioning of Wireless Access Point (CAPWAP). CAPWAP carries and encapsulates control information between the APs and the WLC over an encrypted tunnel over UDP 5246 for control traffic and UDP 5247 for the data. Client data is encapsulated with an CAPWAP header that contains vital information about the client’s received signal strength indicator (RSSI) and signal-to-noise ratio (SNR). Once the data has arrived at the WLC, it can be forwarded as needed, which is how the real-time processes I talked about earlier become available. A couple of great benefits gained through this kind of centralized control are improved security and traffic conditioning. For example, traffic is redirected directly to the WLC so you only need a central firewall to secure all wireless traffic instead of needing to secure each and every site! Physical and logical security becomes a lot tighter in the CUWN because to ensure only authorized APs connect to the WLC, both devices exchange a certificate and mutually authenticate. Any APs found not to be CAPWAP capable are classified as rogues. So basically, the network forces CAPWAP-capable APs to be authenticated before they’ll be permitted to download any configuration from a WLC, which helps mitigate rogue APs. For physical security reasons, the configuration of the AP resides only in RAM while in operation and connected to the WLC. That way, the configuration can’t be nicked from the AP once that device has been removed from the network. The CUWN consists of five elements that work together to provide a unified enterprise solution:
■■ Client devices
■■ APs
■■ Network unification
■■ Network management
■■ Mobility services
There’s a variety of devices around that support these elements. Among them are Cisco Aironet client devices, the Cisco Secure Services Client (CSSC), and other Cisco-compatible devices. For APs, we can choose between the type configured and managed by a WLC and those that operate in stand-alone mode. While it’s good to know that a single Cisco WLC can manage many APs, know that you’ll get to savor a major increase in capacity with a few additional Cisco WLCs in the mix. You can incorporate other devices into your basic CUWN to add more features and management capabilities too like the Cisco Wireless Control System (WCS), which facilitates the centralized management of multiple WLCs. You also need WCS in order to add a Cisco Wireless Location Appliance. These are very cool tools that provide features like real-time location tracking of clients and RFID tags. And that’s not all…Cisco also offers Mobility Express controllers—a scaled-down wireless controller that can run on a Cisco switch like the 3850 or on certain Cisco Access Points to provide virtual management. The newest type of Wireless Controller is the Cisco 9800, which is entirely built into IOS-XE instead of running AireOS like WLC uses.
Split MAC
Even more good news about lightweight architecture is that it allows for the splitting of 802.11 Data Link layer functions between the lightweight AP and the WLC. The lightweight AP handles real-time portions of the communication, and the Cisco WLC handles the items that aren’t time sensitive. This technology is typically referred to as split MAC. Here’s a list of the real-time portions of the protocol that are handled by the AP:
■■ Frame exchange handshake between the client and AP performed during each frame transfer
■■ Beacon frame transmission
■■ Handling of frames for clients operating in power save mode (including both buffering and transmission)
■ Responses to probe request frames from clients and the relaying of received probe requests to the controller
■ Transmission to the controller of real-time signal quality information for every received frame
■ RF channel monitoring for noise, interference, other WLANs and rogue APs
■ Encryption and decryption (Layer 2 wireless only), with the exception of VPN and IPSec clients
The remaining tasks that aren’t time-sensitive are handled by the WLC. Some of the MAC-layer functions provided by WLC include:
■ 802.11 authentication
■ 802.11 association and reassociation (mobility)
■ 802.11 to 802.3 frame translation and bridging
■ The termination of all 802.11 frames at the controller
Cloud Model
A slick new way to manage your wireless infrastructure is by using Cisco’s APs - Donald. Meraki is entirely managed by the cloud, so all you have to do is ensure the access points are able to reach the internet. From there you can now manage your entire Meraki network from a publicly accessible web interface. This means you can make changes to your network from anywhere. Check out Figure 20.3 : A control plane is formed to the cloud to allow for management, which provides monitoring information to help with troubleshooting as well as aid to other features. The cloud provides automatic fi rmware upgrades, analytics, security features and updates, plus a central point for automation. The data plane remains on the premises, so end-user traffi c isn’t affected by cloud management at all. The downside to the cloud model is that APs just don’t offer much local management on the devices—they don’t support command line interfaces (CLI). So if the Internet connection goes down at the offi ce, you won’t be able to make many changes to your network until the Meraki device can get back online! Another caveat with Meraki is because its focus is ease of use, it doesn’t offer as many features as other Cisco controllers offer. So basically, Meraki can be a great tool for companies that don’t have a highly skilled IT team to deploy more complex solutions. It would also work for branches that just don’t have IT staff to help with confi gurations or troubleshooting.
WLC Port Types
■ Console port
■ Service port
■ Redundancy port
■ Distribution system port
■ Management interface
■ Redundancy management
■ Virtual interface
■ Service port interface
■ Dynamic interface
Console Port
This port works the same way as when you’re dealing with a router or a switch by allowing you to configure the WLC through the CLI using out of baud access. You can connect via a console cable and the following settings by default:
■ 9600 baud
■ 8 data bits
■ 1 stop bit
■ No Flow Control
■ No Parity
You need to use the console port for initially setting up the WLC or if the WLC loses its network access for some reason. If you want to change the serial port settings, do so by clicking Serial Port in the Management menu
Service Port
This port is used for out of baud management of the WLC. I’ve got to say that this port can be a bit annoying to use though because it uses a separate routing table and can’t use a default gateway. This means you’ve got to add static routes to use the port so it knows how to reach your management network.
Redundancy Port
This port can connect to a second WLC to get you high availability, ensuring your WLC is always available to serve your wireless networking needs. I’ll cover this one more deeply in the interface type section.
Distribution System Port
This is just a fancy name for regular interfaces on the WLC, which can be either ethernet or SFP connections depending on the type of WLC controller you’ve got. You can view the Distribution System Ports, or just ports for short, via the controller page where you just click on Ports.
Management interface
Used for normal management traffic including RADIUS user authentication, WLC-to-WLC communication, web-based and SSH sessions, SNMP, Network Time Protocol (NTP), syslog and so on. The management interface is also used to terminate CAPWAP tunnels between the controller and its APs.
Redundancy management
This is the management IP address of a redundant WLC that’s part of a high availability pair of controllers. The active WLC uses the management interface address, while the standby WLC uses the redundancy management address.
Virtual interface
This is the IP address facing wireless clients when the controller is relaying client DHCP requests, performing client web authentication, and supporting client mobility.
Service port interface
Bound to the service port and used for out-of-band management.
Dynamic interface
Used to connect a VLAN to a WLAN.
AP Modes - Local
This is the default mode an AP will run in. In this mode, all traffic will be carried back to the wireless controller through a CAPWAP tunnel. This is handy if you want to have a central firewall at your main office to handle all wireless traffic for all your sites. Also, when the AP isn’t busy transmitting traffic, it’ll actually keep itself busy by scanning the other channels for interference, measuring the noise level, checking for rogue devices, and looking for intrusion detection events. This mode can also run a Wireless Intrusion Prevention System submode, which enhances wireless security by comparing wireless traffic to IPS events and preventing bad traffic.
