Resources Archived Articles Designing Wireless LANs, Part 2
| Designing Wireless LANs, Part 2 |
| Monday, 07 February 2005 21:00 | ||||||
|
Introduction
This month continues the theme of WLAN design, based on things I've seen in recent WLAN consulting settings. Last month's article should be read first. It can be found at Designing Wireless LANs. This material was presented in slide form at "Cisco U" sessions in Herndon, VA and Columbia, MD, on February 3-4, 2005. You can find the PDF version of my seminar slides at Wireless LAN (WLAN) Design. I provided some cautions last month. They still apply:
The Cisco Airespace acquisition is still fresh as I write this, and communications events with partners about market positioning are coming up. So I'll remain silent on that topic for now. The general intent of these articles is to pass along the thought that WLAN can be more than just plugging in the WAP's and making them work. If that's all you need, fine. If you go beyond that, there's several ways security, mobility, and future requirements can interact, and several different design approaches depending on what's most important to you or your customer. Last month's article listed some of the possible customer (internal) requirements to consider. I've found that knowing Cisco WAP capabilities (representing the cutting edge in a number of ways), and knowing typical designs, can be helpful in thinking through what's the right approach for a given situation. More DesignsThe bulk of last month's article looked at some of the designs folks have used for WLAN over the last couple of years. They were drawn from a taxonomy of designs I prepared for the seminar. The designs discussed included:
Note that in a sense this month's designs are moving beyond Design3 (Infrastructure) to more sophisticated variations of infrastructure, the logical evolution as the technology matures. Do you want to have and maintain multiple infrastructures, one wired, one wireless? 4A: SSID's and VLAN'sCisco's original technical approach was to tie multiple SSID's to multiple VLAN's. The reason for doing this was not to allow VLAN's in and of themselves, but because different wireless devices have different levels of authentication and encryption capability, and different connectivity needs. A VLAN can be thought of as a group of users. Lately VLAN's have been mostly based on user location in building / campus in my designs, but originally they were thought of as reflecting workgroup membership, with a bit of security flavoring added (shaken, not stirred).
The simplest variation on this theme is to broadcast SSID CORP-GUEST, and quietly provide CORP-EMPLOYEE for employees. If somebody can authenticate into the CORP-EMPLOYEE SSID, then that VLAN (and access lists, ACL's) allows full network access. Whereas authenticated, or perhaps any, user of the GUEST SSID and VLAN, is limited by ACL's so they can only access the Internet. When you add WLAN IP phones to this, you might say add a CORP-PHONE SSID and VLAN, with ACL so that the phones can only talk to (a) Signaling Servers (Call Manager or IP PBX), (b) voice gateways for PSTN etc., (c) other WLAN or wired phones. The latter is a reasonable task if you did go ahead and use AUX VLAN's, as is recommended with Cisco Call Manager. (You can still do this via DHCP with Nortel IP phones, and perhaps with Avaya). The point is that even if somebody manages to authenticate to the VoWLAN VLAN, it doesn't get them much access. Yes, they might still be able to conduct Denial of Service on the voice side of things. 4B: 802.1x and Dynamic VLAN'sThe previous approach has users messing about with SSID's, which some might prefer not to have to support. So another approach uses 802.1x logins, say via a Cisco Wireless Domain Server (designated WAP per L2 pocket of WAP's, or 2800/3800 ISR router, or WLSM blade). The WDS can verify login via RADIUS to CiscoSecure ACS, which can in turn refer user credentials to LDAP, Windows, etc. User groups from Windows can then be associated in ACS with RADIUS attributes, which end up telling the WAP what VLAN to put the user into. Note that this approach over-rides the SSID to VLAN assignment you may have configured into the WAP.This may sound technically complex, but it isn't that bad, once you've got it working once, it's easily propagated. (Debug has been my friend on this). More of the complexity is hidden from the user, and can be centrally controlled off CiscoSecure ACS, which can really help with scaling. This also should fit nicely with Cisco Network Admission Control. (NAC) going forward. 4C: Bradford Campus ManagerThe Bradford Campus Manager software seems to be moderately successful on smaller college campuses (up to 5000 students or so). See http://www.bradford-sw.com/.There's been some email list grumbling about the product as of Fall 2004 semester, but some (most?) of that seems to represent less-prepared campuses and overloaded tech support due to hot sales. It does a patch level pre-scan and assigns a VLAN based on user login/group and passing the registration pre-scan. The VLAN assigned may be a Quarantine VLAN if the student is required to remediate the problem. Bradford Campus Manager then subsequently uses retained MAC address to speed up wired and wireless connections. This is a commericalization of the NetReg freeware approach, with what looked like a good web-based front-end to manage it all. My one real concern is the scalability of the method used to detect students connecting to wired or wireless ports: SNMP traps. From talking to their tech support, the dynamic VLAN assignment approach has some clever tweaks to help it scale to some degree.
Routed Core
Let's suppose you're using one of these approaches, perhaps with a VLAN for guests, one for employees, maybe one for contractors. I've run into this sort of thing where two financial accounting firms were on site, say A and B. They needed connectivity to (a) the Internet (for VPN or SPOP email to their corporate HQ), (b) limited access to a small number of servers on site, and (c) each other. If the site is small to medium in size, you can run VLAN's up to the collapsed core or trunk them out to a firewall. Some ACL's may then provide the rest of a workable solution. But what do you do if your network has a substantial L3 routed core between the pockets of guests or A or B contractors, also betwen them and the Internet connections? See the following figure:
The problem is that any L3 device provides a chance for the traffic to go where it's not allowed. I think of this a routing permits untrusted traffic with an opportunity to "escape containment". Putting an ACL on every other interface on every device between the guest and the Internet gets very messy, very fast. Putting an ACL on the guest VLAN L3 interface that controls all the locations they are allowed to reach can also get messy. And can you really be sure you trust it when you're done? Miss one, and the untrusted folks are free to send traffic where they shouldn't. The MPLS-related "VRF-Lite" feature set could be used to build a separate set of routing tables for the various user groups (think Guest Routing Table versus Employee or Contractor A or B). You can do that without the full set of MPLS tools and complexity, but it too can get moderately complex. That makes VRF Lite not an optimal approach for solving this problem. There's a second issue that crops up here. If users need to roam, they're going between L3 subnets. That means re-DHCP'ing, which greatly slows the re-association process. My question lately: do they use the device while this is happening? For example, few people type on laptops while going between buildings or floors. So maybe roaming for laptop users doesn't impose stringent timing constraints or any real need for a more L2-centric approach. Consider PDA's. People might expect to thumb something into a PDA while waiting for an elevator. People definitely expect phone calls to persist while they are walking around or moving between floors. 5: Wireless LAN Services Module (WLSM)That brings us to the Cisco WLSM, Wireless LAN Services Module, for 6500 switch with 720 engine. If you're big enough to need WLSM, you've probably already got some of these around anyway.I see the WLSM as meeting the two needs just discussed:
That is, just because you have a big network with WLAN, you may still not need WLSM. But if you have a big network and need to do one or both of the two above items, then you'll want to take a look at WLSM. The main point to WLSM is that it plus the 720 engine allow your WAP's to belong to a multipoint-GRE tunnel. This layers a giant subnet on top of the existing L2 and L3 infrastructure, solely for purposes of connecting WAP users back to the WLSM and switch that it resides in. No matter which WAP the user connects to, they are securely logically connected back to the WLSM. If they roam, they stay in the same subnet, obviating the potential DHCP delays. WLSM also acts as WDS for up to 300 WAP's. That is, the WAP's all authenticate users by WDS messages to WLSM, which uses RADIUS back to CiscoSecure ACS to authenticate. Since the WLSM can cache this information, this allows faster re-associating with the controlled WAP's. The logical L3 subnet layered on top of your wired network is referred to by mobility group number. WLSM can work with up to 16 of these, tied to SSID's. Think Guests, VoWLAN phones, Contractor A, Contractor B, etc. Employees might use a different SSID and connected directly into the infrastructure for optimal performance. Multicast is sent without going through the m-GRE mechanism, which protects performance when substantial multicast flows (perhaps video) are present. Here's a diagram suggesting how this works:
The m-GRE tunneling provides security: all the user traffic can do is go to or from the WLSM. Furthermore, if you want it to, all access from wireless to wired network goes through the WLSM, so it gives you a single point you can connect to firewall, IDS, Internet, etc. That sure beats "plumbing" via L2 access ports from a remote floor back to the firewall, or some other such approach to contain the traffic across the L3 core. You can do redundant WLSM's (one per chassis in two chassis) but failover is not stateful and does require re-association. See the URL's below for more details.
Summary
I've found that WLSM links can seem well-hidden, since they are a joint offering between the Wireless and Switching Business Units. Some are under switch services modules, some under WAP 1200. One good alternative is to use Search to find them. Here are some of the best URL's I've found. The latter two are both excellent documents, very readable, very informative!
Networkers 2004 presentations ACC-2011 and RST-2506 also had good sections about WLSM, but the URL's I had no longer work, and the site in general says "Under Construction". Your comments, questions, and suggestions for future articles are of course welcome! See below to decipher my email address.
2/7/2005 |
