In the 802.11 service sets lesson, you learned how an AP provides a BSS for wireless clients. You also learned how we use an ESS with multiple APs to create a larger wireless network. In this lesson, we’ll take a look at different Cisco wireless architectures we can use for enterprise networks.
Autonomous AP ArchitectureWe use most wireless networks as an extension of the wired network. Wireless and wired clients are on the same LAN and can communicate with each other. An autonomous AP has all the required intelligence to serve wireless clients and to connect to the wired network. The AP can offer one or more BSSes and connect VLANs to SSIDs. Below is a picture of what this looks like on an enterprise network: I highlighted the connections for one of the APs. Our autonomous AP is on the access layer and connected with a trunk. We have three VLANs:
We need the 802.1Q trunk to the switch; this is how the AP has access to all required VLANs. The autonomous AP also has a management IP address; we need this to SSH into the AP so we can configure things like:
We want to separate management and data traffic, which is why we use a separate management VLAN. Wireless users in the same VLAN can communicate directly with each other; this traffic doesn’t have to cross the wired network. You configure each autonomous AP individually. This can be a pain; let me explain. Let’s say you want the capability that wireless users can roam from one AP to another without losing their connection and DHCP assigned IP address. This is no problem, but it means you have to configure the same SSID and VLAN on all APs. You also need to configure RF parameters like the channel you want to use and the transmit power. With multiple APs, you have to figure out which channels and what transmit power to use, so there is enough overlap and (almost) no interference between APs. You also need to ensure that when an AP fails, other APs can take over, so there is no coverage hole. Requiring VLANs everywhere introduces an issue on the switched network; stretched VLANs. Take a look at the following picture: When a wireless user wants to roam from one AP to an AP that is connected to the access layer of another distribution layer, you’ll have to cross the core layer. This means your VLAN has to span the entire network. If you want to configure a new SSID, you have to configure it on all APs. You also need to configure a new VLAN on all APs and switches. You could make your life a bit easier and use a management platform to configure the APs. You could do this with Cisco Prime Infrastructure. There is also no central point in the network to monitor wireless traffic and do things like policing, QoS, or intrusion detection. Another term for the autonomous AP solution is the local MAC architecture. As you see, there are some limitations and problems with the autonomous AP setup. It’s a fine solution for a small network, but when the network grows, it doesn’t scale very well. Split-MAC ArchitectureAutonomous APs work alone; we configure them one by one. As explained, this decentralized architecture has some drawbacks:
To overcome these problems, we move some functions from the AP to a central location, the Wireless LAN Controller (WLC): With wireless networking, we have real-time and management functions. The AP should handle real-time functions, but everything that is not delay-sensitive can do from a central location. We separate the following management and real-time functions of the AP:
Since these functions are not real-time, we can move them to a central point, the WLC. We take away some of the intelligence of the AP, which is why we call them lightweight APs (LAP). We move this intelligence to the WLC. The WLC controls many APs in the network. The lightweight AP requires a WLC; it can’t function on its own. Splitting functions between the AP and WLC is what we call the split-MAC architecture. One exception is the FlexConnect architecture. This AP connects to a WLC but can also work standalone. When a lightweight AP boots, it uses discovery mechanisms to search and connect to a WLC. Before the AP and WLC connect, they have to authenticate each other. We do this with pre-installed X.509 certificates on the AP and WLC. This prevents someone from adding an unauthorized AP to your network. CAPWAPThe AP and WLC connect with a tunneling protocol, the Control And Provisioning of Wireless Access Points (CAPWAP) tunneling protocol. CAPWAP encapsulates all data between the lightweight AP and the WLC. CAPWAP is a standard, defined in RFC 5415, 5416, 5417, and 5418. It’s based on the Lightweight Access Point Protocol (LWAPP), a legacy Cisco proprietary solution. There are two tunnel types:
Each uses a different UDP port. Tunneled traffic can be switched or routed. Using a tunnel means the lightweight APs and WLC don’t have to be in the same VLAN. This is useful since APs are typically on the access layer, and the WLC is in a central location (core layer or data center attached to the core). Because of the CAPWAP tunnel, the AP and WLC are not only physically separated but also logically separated. This requires some more explanation. Take a look at the following picture: The tunnel is between the IP address of the lightweight AP and the WLC. As long as they can reach each other, they can establish the tunnel. The lightweight AP connects to an access mode switchport in VLAN 11. The lightweight AP offers two SSIDs:
How can the lightweight AP offer an SSID that uses VLAN 20 or 30 while it’s connected to a switchport in VLAN 11? That’s what the CAPWAP tunnel is for; it tunnels VLAN 20 and 30 traffic from the lightweight AP to the WLC. |