Editor's note: This is part two of a two-part series examining the steps needed to unify wireless and wired networking....
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
Part one discussed traditional access and distribution core networks. In this installment, Glen Kemp examines topologies in which the wireless and wired world can be more efficiently integrated.
What has changed for campus edge deployments is that virtual chassis (VC) and stacking switches are now viably priced. Vendor implementations differ, but with either approach, several physical switches can be configured as a single logical device. This means that there are fewer logical devices for the administrator to oversee, but this also means that uplinks can be aggregated across multiple switches using bonded 802.11ad link aggregation group (LAG). For example, four fiber uplinks can be bonded to create a single 4 Gbps link back to the core.
Prior to VC or stacking, if you had four physical switches, each with a single connection to the core, a link failure would knock out perhaps 25% of devices. With a VC or stack in place, if a single switch lost its local uplink, traffic could still be switched via a peer node back to the data center with only a fractional increase in latency. The majority of traffic from the campus edge will still be northbound and forwarded to the core network; however, print and voice traffic will still need to be switched locally. With a VC or stack, some of the load can be moved from the uplinks and core network back to the edge.
From an efficiency perspective, it is also recommended that wireless access points (APs) be directly connected to edge switches. Depending on switch capacity and the capabilities within the wireless deployment, there may be a separate switch stack for powering and connecting the APs back to the core.
On paper, separate switch stacks do provide a level of resilience; if one goes down completely, the other may continue. Yet there are several problems with this argument, and this approach could indeed increase the number and severity of failures. First, disparate switch stacks are ultimately more work to maintain. They will cost more to power and cool and will sting you twice when it comes to service contracts. Given that wired and wireless cannot totally replace the other's function, you will always need both.
Second, with two switch stacks, it is tempting to skimp on power supply redundancy, use cheaper upstream links or swap same-day hardware cover for a less costly next-day contract.
By using fewer, more efficient devices, then, you are less likely to encounter a failure. If you do, you'll be glad of the safety net of a four-hour replacement contract.
Merging the distribution layer into the access layer
Figure1 illustrates our optimized network. The function of the distribution layer has in effect been merged into the access layer as east/west switching is handled within the closet by a VC or stacked link. Northbound connectivity is via an 802.11ad LAG direct to the core. The APs, meantime, should be geographically distributed across the access switches. If a switch loses power and takes its APs with it, the neighboring APs are connected to alternate and still-powered switches. Overall, this design has fewer moving components than our historical design and has several layers of increased capacity and resilience.
Don't forget to standardize security policies
There is scant point in enabling strong authentication and access control on a wireless network if a user can just plug into a wired port and get straight onto the LAN. The expectation should be that 802.1x authentication is enabled on all wired access ports. For the sake of sanity of both users and administrators, digital certificates over Extensible Authentication Protocol-Transport Layer Security (EAP-TLS) should be the preferred authentication mechanism for most organizations.
EAP-TLS management tools (especially for Windows and iOS devices) have improved dramatically, so this is not the headache it once was. Guest users should receive similar treatment regardless of whether they are connecting via wired or wireless. On the wired LAN, if they fail to authenticate with a correctly configured 802.1x supplicant, they should be dumped into a guest VLAN with a captive portal. Wireless guest users should have access to an open service set identifier that does the same. Some vendor platforms (such as Aruba's ClearPass) also use these portals to apply bring your own device policies to various devices.
Unifying IP addressing schemes also key consideration
It is tempting to put all your users, wired and wireless, onto the same dynamic host configuration protocol scope and VLAN in order to provide that "truly unified" feel. This methodology, however, has implications for the rest of the network. There are circumstances where separation of the two is actually helpful. For example, WAN optimization devices create acceleration policies based upon source and destination subnet pairs that they assume to be LAN connected. The inherent instability of wireless connections makes this approach less than ideal; if the WAN optimizer cannot easily distinguish between wired and wireless by policy, it will have a much tougher job enhancing traffic for those clients. The reverse is true for laptops with software WAN optimization; the client software relies on location awareness rules set by the administrator. If the policy specifies that optimization should be disabled on internal LAN subnets, the user will not get the possible benefits of client-to-server optimization. Conversely, if optimization is enabled for the same subnets, it's likely that both licenses and resources will be wasted attempting to accelerate uncontended Ethernet connections.
Implementing Quality of Service and Class of Service
It is standard practice to provide traffic on voice VLANS with expedited forwarding over normal LAN traffic; for wireless networks with much less aggregate bandwidth and less assured connections, this becomes even more critical. While Voice over Wi-Fi (VoWi-Fi) is not a common occurrence, many companies rely on Skype and its corporate cousin, Lync, far more than they are probably aware.
Demystifying unified network management
Unified management: Is it real yet?
How vendor approaches differ
Erasing the gaps between wired, wireless management
These kinds of chatty, latency-sensitive protocols need special attention with regards to wireless deployment. This is another example where a single vendor handling both your wired and wireless network is more likely to have a common configuration template designed to support both mediums seamlessly.
The examples and diagrams I've used here are just that: examples. But there should be more than a few grains of truth regarding the design and performance challenges you face today. I've made no special effort to single out a vendor that provides the best combined wired and wireless platform, but certainly you should consider all the factors detailed here when assessing your options. The maturity and stability of both the wired and wireless mediums varies considerably. Some vendor portfolios have competence in one at the expense of the other. The worst-case scenario is that one aspect is exclusively favored over another and key infrastructure is merely thrown in as part of the deal. As is often the case, by understanding your needs and priorities before you involve a vendor or reseller, it is likely you will be able to negotiate much more effectively and get the equipment you need at a cost you are willing to bear.
Glen Kemp is an enterprise solutions architect for a U.K.-based managed services provider. He designs and deploys network and application security tools, including access control, remote access, firewalls and other "keep the bad guys out" technologies. He is also an experienced professional services consultant, delivering elephants and not hunting unicorns. His blogs can be found at sslboy.net and at the Packet Pushers Podcast. Follow him on Twitter @ssl_boy.