WLAN Architecture - Considerations
•Download as PPTX, PDF•
2 likes•2,589 views
Some enterprise WLAN history, Explaining the three working planes of a WLAN, Centralized architecture, pros and cons, Distributed architecture, pros and cons,Summary and an extra slide on redundancy.
Recommended
Recommended
More Related Content
What's hot
Viewers also liked
Viewers also liked (20)
Similar to WLAN Architecture - Considerations
Similar to WLAN Architecture - Considerations (20)
More from Aruba, a Hewlett Packard Enterprise company
More from Aruba, a Hewlett Packard Enterprise company (20)
Recently uploaded
Recently uploaded (20)
WLAN Architecture - Considerations
- 1. WLAN Architecture - Considerations Christoffer Jacobsson
- 2. What will I talk about? • Some enterprise WLAN history. • Explaining the three working planes of a WLAN. • Centralized architecture, pros and cons. • Distributed architecture, pros and cons. • Summary and an extra slide on redundancy.
- 3. Where did enterprise WLAN begin? • Fat/Autonomous APs • Secondary access method • Unique solutions for every need • Limited coverage • Little or no visibility • Management nightmare
- 4. The three working planes of a WLAN Data plane Management plane Control plane • Data Forwarding • Configuration • Firmware • Monitoring/Reporting • Dynamic radio control • Mobility/Roaming • Load balancing • Encryption/Decryption • QoS tagging • Data filtering
- 5. How do we leverage these working planes? Management plane Control plane Data plane Management plane Control plane Data plane Management plane Control plane Data plane Management plane Control plane Data plane SSID: Awsome-Company Security: WPA2-PSK SSID: Awsome-Company Security: WPA2-PSK SSID: Awsome-Company Security: WPA2-PSK company Wireless Network Management System (WNMS) SSID: Awsome-Company Security: WPA2-PSK
- 6. Centralized architecture – ”The overlay implementation” YeahBaby Inc. WLAN project. 500 employees, 2 devices per person. 7 floor building. Trunk port including new WLAN client WLANs • New VLANs exist only in controller and Core/Distribution • Seamless roaming accross all floors • Centralized channel and power dynamics • Encryption from client to controller • One RADIUS client • One point of management s Management Control Data
- 7. Centralized architecture for a distributed company NearYou AB WLAN project. 20 Offices spread out over the country All internet and server access goes through HQ • New VLANs exist only in HQ • All APs configured the same way • Client traffic encrypted to HQ • One RADIUS client • One point of management Management Control Data
- 8. Drawbacks of a centralized architecture NearYou AB WLAN project. 20 Offices spread out over the country All internet and server access goes through HQ • Dependancy on controllers • Possible traffic U-turns and bottlenecks • Scalability issues • Controllers and licenses are expensive Management Control Data
- 9. Distributed architecture – Optimizing traffic flows UpUpAndAway Inc. WLAN project. 4 offices globally. Demands local survivability. • Client traffic forwarded locally • Local RADIUS client • Central management on premises or in the cloud • Local shared control plane • Distributed architecture is redundant by design Data Management Control Control Data Control Data
- 10. Distributed architecture – an MSPs perspective Aranya AB, WLAN as a service. Customers totally separated from eachother. No operational dependencies on Aranya datacenter Management Control Control Data Control Data Data Data Data Control Data Data Data
- 11. Drawbacks of a distributed architecture Management Data Control Control Data Data Data • Alot of more wired side management • More RADIUS clients • Wireless encryption ends at AP • Changing architecture can sometimes require hardware replacement.
- 12. Extra redundancy considerations • Who and where are your RADIUS clients and servers? • Are those server certificates under control? • Are you querying more than one LDAP server? • Who and where are your DHCP servers and IP-helpers? • Always test your redundancy!
- 13. Questions and comments are welcome! Mail: Christoffer@aranya.se Phone: +46700 92 10 92
Editor's Notes
- Welcome the audience and introduction of me and my presentation.
- Go through the agenda with the audience. Tell the audience that it´s not forbidden to take notes, you just don´t have to. Get my email in the end to get the presentation.
- Talk about Fat/Autonomous APs, how they were deployed and the challenges associated with it. Clicks: Brings out another line of how old WLAN was to talk about. Next: The three working planes of a WLAN.
- Explain the three working planes of a WLAN. Click1: Data plane appears with Data forwarding. Click2: Management plane appears with Configuration, Firmware and Monitoring Click3: Control Plane appears with Dynamic radio control, Roaming, Load balancing, Encryption, QoS, Data filtering Next: Autonomous APs configured with a WNMS
- An old implementation of Autonomous accesspoints where one is misconfigured. Explain what the effects of this is and how it can be hard to find. Click1: X marks the error. Click2: WNMS is installed. Click3: Management plane is centralized. Click4: Error is corrected. Next: Centralized Architecture, the overlay implementation.
- Explain how you would rarely want wireless devices mixed up with wired devices in a VLAN and the roaming issues involved with changing VLANs when roaming. A new group of VLANs are needed for this implementation and configuring them on all the access switches and trunk ports to APs can be a pain. Click1: Brings out the units on the design drawing Explain how easily a centralized architecture solves these issues and makes this implementation very quick and easy. Click2: Brings out the benefits of this setup. Next: Centralized architecture for a distributed company
- Explain the setup with centralized resources and internet access. No local resources on site. Click1: Brings out the devices on the design drawing. Explain how simply we can deploy remote APs like this using DNS / DHCP options and centrally configure them in one place. Talk about how you could centrally separate them into their own configuration groups and VLANs to be able to make changes per site. Click2: Brings out the benefits of this setup. Next: Drawbacks of a centralized architecture
- Click1: Brings out the possible drawbacks of this centralized setup. Explain the single point of failure scenario of this setup and how to implement redundancy. Pretend that they implement a file server in Maastricht branch and how traffic would then U-turn in HQ. Explain how the controller uplink can be a bottleneck traffic wise with the high throughputs of 802.11n and 802.11ac. (maybe not in this picture) Explain the continual scalability issue with a controller based architecture. Sit with a big empty controller and wait for growth or buy small controllers as you go? Neither is good or effective. Explain the big costs associated with controllers and licenses. Next: Distributed architecture: Optimizing traffic flow
- Explain how there offices all have their own internet access and local file/application/authentication servers. Explain how moving in with a centralized architecture in one site is out of the question and deploying controllers everywhere maybe is unnecessary. Click1: Brings out the devices in the design drawing. Explain that I´ve chosen to go with a distributed architecture to handle Data plane and control plane locally while maintaining a centralized point of configuration with a WNMS in own datacenter or in the cloud. Click2: Bring out the benefits of this setup. Explain how distributed architecture is redundant by design. Explain what happens when management server is unreachable.
- Explain what a managed services provider is and how they want to be able to add and expand customers freely. Click1: Adds Customer A Click2: Adds the working planes of this setup. Explain why this setup works good for MSPs and how it´s redundant by design. Also explain how the customer WLAN isn´t dependant on Aranya datacenter to be up and running. Click3: Add Customer B Explain that with less central hardware limitations we can add customers and sites of existing customers easily. Next: Extra redundancy considerations
- Explain what a managed services provider is and how they want to be able to add and expand customers freely. Click1: Adds Customer A Click2: Adds the working planes of this setup. Explain why this setup works good for MSPs and how it´s redundant by design. Also explain how the customer WLAN isn´t dependant on Aranya datacenter to be up and running. Click3: Add Customer B Explain that with less central hardware limitations we can add customers and sites of existing customers easily. Next: Extra redundancy considerations
- Quote the picture and tell something about the redundancies we´ve discussed so far. Click1: Who and where are your RADIUS clients and servers? Explain that in a centralized architecture the controller is most commonly the RADIUS client while in a distributed architecture it´s mostly the APs or a virtual IP on the APs. You should be aware and configure your RADIUS servers accordingly. Click2: Are those server certificates under control? Explain how it´s one of the biggest reasons for ”WLAN down” scenarios that the server certificates expire. Even though it´s a server issue, the customer will blame the WLAN and plug in a cable. Click3: Are you querying more than one LDAP server? Explain how it´s commonly seen to point functionality to one LDAP server and then never implement a backup one. Make sure you do! The AD administrators won´t feel bad for you when it fails over. Click4: Who and where are your DHCP servers and IP-helpers? Explain that you mean plural, redundancy is important even when it comes to DHCP servers. Make sure you know where the DHCP packet from your client will end up, who will forward this packet and who´re the servers that will be answering this request. Avoid those incidents regarding full scopes by monitoring them. Click5: Always test your redundancy! Next: Questions? The end.
- Thank the audience and take questions etc.