Wireless World: 5 Things IT Pros Need to Know

Posted on
Like what you see? Share it.Share on Google+Share on LinkedInShare on FacebookShare on RedditTweet about this on TwitterEmail this to someone

It’s impossible to cover everything IT pros need to know about wireless LANs in a short space. What we have done is narrow this vast chasm of expertise down to five things that will enable an IT pro to implement, manage and troubleshoot an enterprise wireless LAN without getting completely lost.



  1. Learn Where and How Wi-Fi Lives Within the OSI Model
    Wi-Fi is a Layer 2, or Data Link layer, technology. A very common misconception is that Wi-Fi operates at Layer 2 and Layer 3. Though you can design WLANs from Layer 3, Wi-Fi operates at Layer 2 of the OSI model.

    In order to manage an enterprise wireless LAN, you had better know the ins and outs of the OSI model, and remember that 802.11 (a, b, g, etc.) is at Layer 2. If you don’t get the OSI model, you won’t understand how to design functional, secure wireless LANs, because you can build a wireless LAN at Layer 2 but also at Layer 3 using wireless routers.

    As for how Wi-Fi operates at Layer 2, there are several points to remember. First, if a protocol will run on Ethernet, chances are it will run on Wi-Fi. Second, Wi-Fi is half-duplex. Translated, that means 11 Mbps really translates to 5.5 Mbps (if you’re lucky), using optimal setups with no interference and perfect RF coverage all the time. As if that weren’t enough, you’re sharing that throughput among all wireless LAN clients on a channel. In other words, 5.5 Mbps is a pipe dream on an 802.11b system, just as 21 Mbps would be a dream on an 802.11g or 802.11a system. Reality typically says that you’ll get about 5 Mbps on 802.11b and 19 Mbps on 802.11a/g.

  2. Understand Layer 2 and Layer 3 Security Architectures
    It is possible to design enterprise wireless LANs at both Layer 2 and Layer 3. The Wi-Fi market is divided between Layer 2 and Layer 3 solutions. Vendors of both enterprise wireless gateways (EWGs) and Wi-Fi routers control wireless LAN systems from a Layer 3 perspective. However, vendors of access points and WLAN switches approach design from Layer 2.

    Let’s look at some examples. Cisco’s access points are strictly Layer 2 bridging devices, but can be managed using a bridged virtual interface (BVI) by assigning an IP address. They simply bridge frames from the wired interface to the wireless interface like an Ethernet switch. This is how it has been done since the beginning of Wi-Fi, and other vendors like Proxim, Intermec and NetGear all do it the same way. Layer 3 functionality is performed on other network devices such as firewalls, VPN concentrators, etc.

    EWG vendors, such as Vernier Networks and Bluesocket, and wireless router vendors, such as Colubris, perform many Layer 3 services directly on their appliances. Both are combination units that perform such functions as VPN concentration, firewalling, rate limiting, IP routing, role-based access control (RBAC), NAT, secure management and many others. From a design perspective, you have to make the decisions of where the network layer services should be performed and how that will affect performance and security.

    Furthermore, roaming, which is what 802.11 technologies were designed to do in the first place, can be designed for Layer 2 or Layer 3. When Wi-Fi LANs were first introduced, roaming was very much proprietary, and it still presents problems at Layer 2 due to an overall lack of standards and a lack of implementation of the standards that are currently available. IEEE 802.11f is not a standard, but a “recommended practice,” and few vendors currently use it. Additionally, 802.11f has shortcomings such as slow handoff and no cross-subnet roaming support. Most enterprise-class access-point vendors have implemented a proprietary roaming mechanism on their access points and clients, and those that have not are typically supporting 802.11f. In contrast, EWG and wireless router vendors typically support subnet roaming and, even better, VPN roaming. Certainly there is significant overhead to using VPN technology, but it can perform many of the same tasks at Layer 3 that traditional access points can perform at Layer 2. Subnet roaming is implemented as either MobileIP or a proprietary mechanism, and to date, VPN roaming is always proprietary.

  3. Understand Everything About Authentication
    If appropriate security mechanisms, including proper authentication procedures, are not in place on a wireless LAN, anyone can access that network and the data behind it. Hence, the network should have the proper tools for “validating the authenticity of someone” who is attempting to access the network.
    Below are three points to remember when determining and implementing an authentication solution for your enterprise wireless LAN:

    • RADIUS is king. 802.1x/EAP solutions have become very popular across both wired and wireless networks, and RADIUS services can scale easily. Since every access point on the market that supports 802.1x/EAP can use RADIUS as an authentication server, sales of RADIUS server applications/appliances have dramatically increased in the industry. Also, RADIUS servers are known for being able to proxy authentication to almost any user database type in existence, including LDAP, NDS/eDirectory, Active Directory, SQL and many others. EWGs and wireless routers also support RADIUS, and now you’ll even see integrated RADIUS-compliant services internal to some enterprise-class access points on the market. Such functionality is great for both remote-site survivability and small-office EAP-based authentication solutions.
    • RADIUS isn’t always required. Suppose that your EWG, wireless router or access point can directly query an LDAP-compliant or LDAP-compatible user database for authentication of a wireless user. In a scenario like this, there is no need to spend the money on RADIUS, because it’s just one more thing to manage and one more thing that can break in your network. If your organization is an Internet service provider, you may use a native RADIUS database, but if your organization is a small- or medium-sized enterprise, chances are that you currently have Novell’s eDirectory, Microsoft’s Active Directory or an LDAP database that contains your user list. Why not leverage this database directly?
    • Designing enterprise WLAN authentication schemes can be tough because there are so many choices on the market. Suppose your organization has a central office with a couple of Microsoft Active Directory Domain Controllers (DCs) and several branch offices, each with one DC. Let’s further imagine that each branch office wants to implement a secure wireless LAN with user-based authentication. The questions the administrator now faces are: Should I implement a RADIUS server at each site, and if so, should it simply proxy to the local DC? Should I implement a RADIUS server at the central site and have each access point query the centralized RADIUS server for wireless user authentication? If so, should RADIUS then proxy to the centralized DC? Should I purchase equipment that does not require use of a RADIUS server for authentication or proxy authentication? If so, what solutions are available to authenticate wireless users directly against the DC? Do Layer 2 or Layer 3 wireless solutions give me more flexibility in using my DC for authentication instead of RADIUS?
  4. Practice Building Enterprise-Class Wireless LAN Architectures
    The best way to learn how to implement any wireless LAN is simply to do it. Nobody we know of has the luxury of being able to fiddle with a production (aka “live”) network in order to enhance their skills in networking. That means you need to get your hands on some enterprise-class wireless LAN equipment.
    For some, that in itself ca
Like what you see? Share it.Share on Google+Share on LinkedInShare on FacebookShare on RedditTweet about this on TwitterEmail this to someone


Posted in Archive|


Leave a comment

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>