SD-LAN FAQ: You Have Questions, We Have Answers
We’ve been writing about the topic of SD-LAN quite a bit lately, which has spurred some interesting and/or probing questions that we’ve been busy answering. In the interest of sharing what we know, we’ve gathered up the questions for Mat Edwards to answer.
Q: What are the differences between SD-LAN and SD-WAN, and why SD-LAN over SD-WAN?
A: SD-WAN leverages the principles of software defined architectures and the cloud to deliver more flexible, adapatble, and cost-effective wide area networks, rather than deploying expensive leased lines. SD-WAN is focused on connecting multiple sites/buildings, whereas SD-LAN concentrates on the access network, where your client devices (laptops, phones etc) connect via Wi-Fi or wired.
SD-LAN, much like SD-WAN, builds on the attributes of SD archiectures to ensure orgranizations have access networks that can easily adapt to change, better scale, have simpler management, and more easily integrate with the rest of the network. Therefore SD-WAN and SD-LAN solutions are complementary, taking different areas of your network into the future.
Q: I’m a bit fuzzy on the concept. Do you have any examples of SD-LAN for applications? Also, will this affect the WAN as it would likely be cloud-based?
A: Check out this great blog by Craig Mathias: What is SD-LAN? In short, SD-LAN is a new market category that helps to define what a modern access network should deliver for users. In reality, many enterprise Wi-Fi solutions have been delivering software-defined categories for a number of years, but until recently had yet to be formally categorized as such.
From an application standpoint, there are a couple of SD-LAN cases. The first is the flow control of existing applications at the edge of the network i.e. identiying and prioritizing/restricting/blocking certain apps. So blocking torrents, restricting bandwidth-intensive apps such as OS updates, then QoS tagging voice- or video-web apps such as Skype or YouTube to ensure a consistent end-to-end experience. Adminsitrators should be able to centrally set policies (through the cloud) then the access layer will dynammically take care of the rest.
In terms of building applications on top of the infrastructure, we have seen organizations build customized IT and business apps that leverage location, presense, monitoring, identity APIs for guest access, location tracking, MSP dashboards, and maintenance operations such as building utilziation … all apps that leverage the Wi-Fi for value beyond connectivity.
Finally, the SD-LAN APIs can be used to integrate the access layer with the rest of the network, rather than building out specific code builds i.e simplier interaction between the Wi-Fi and the NAC, firewall etc.
On your question around the WAN connectivity, if the data/control/management planes have been sufficiently split, there should be relatively small amounts of traffic that hit the cloud; control/data remain local at the access layer, and it is only management (i.e config and reporting) that is centralized.
— Aerohive Networks (@Aerohive) October 11, 2016
Q: I am still a little fuzzy on what hardware / software this replaces?
A: Great question. On the Wi-Fi side, SD-LAN removes the requirement for a wireless LAN controller, as the control plane is actually a function of a protocol – a bit like OSPF for routing, or STP for switches. By decoupling the control plane from the physical or virtual controller, the access points (APs) have increased speed, scale, and resiliency. The typical components required are simpy an AP and cloud, that’s it.
A cloud-operated access layer has many benefits, but beware, not all Wi-Fi clouds are equal – especially when it comes to the SD data/control/management functions. For example, Aerohive uses the cooperative control protocol to scale from 1 to thousands of access points on a single platform, and the cloud is simply there to provide centralized management.
Other players in the market with ‘cloud’ approach things differently, which is not always clear to the customer. For example, some vendors can only support a certain number of APs when operating in ‘controllerless’ mode, as one AP might be acting as a virtual controller. Or the cloud may be used as both controller and management, increasing dependancy on that vendor’s cloud service for the operation of your network.
Always good to compare the credentials – especially scalability and whether or not there are both public and private cloud options – between one vendor’s cloud and another.
Q: What makes the Aerohive SD-LAN offering different than anyone else’s?
A: Great question! First of all, I advise you to check out this page for an overview of Aerohive in the SD-LAN world. At the access layer, Aerohive fully distributes the control plane using our cooperative control, increasing resiliency and scale without increasing cost and complexity. Through the software intelligence residing at the access layer, the APs are then able to provide QoS, app flow control, and identity services right at the edge, rather than relying on additional, centralized services.
Although control is pushed to the edge, management is still centralized – Aerohive has been doing public and private cloud for nearly a decade. Most WLAN vendors have only recently entered the cloud space and target their solutions at SMBs, given they are generally much more immature than their current controller-based offerings.
Today, while most cloud Wi-Fi solutions are focused on management, Aerohive has matured its cloud platform to build an abstracted layer of open APIs so that customers can create, or leverage production applications that reduce IT operational complexity, or utilise network data for greater insights and engagement through mobile devices.
Q: It always used to be hardware, hardware, hardware. Whether it was VPN, Firewall, RAID, or whatever, the rule of thumb was always to have hardware doing the configuration and not the software … why now, all of a sudden, is going the reverse way with SD-LAN more practical? Why rely on the software to control this?
A: The world is definitely changing, and as a network engineer, it means I have to play nicely with app engineers 😉 One of the main reasons for the software-driven world is agile development and scale. SDN was first adopted in the DC with the likes of Amazon and Google wanting an easier way to scale and manage multiple sites under heavy growth, throwing more hardware at the problem would help. But they turned to SDN for virtualization and better VLAN management.
The same then happened with SD-WAN. Companies like Velocloud and Silverpeek realized there was a smarter and more cost-effective approach to networks than leased lines – through the cloud. At the access layer, this has slowly been taking shape over the last decade. With more software intelligence driving the decisions and behavior of the hardware components, it is simply now better understood and articulated.
Q: Is this only available with HiveManager NG? HiveManager NG still doesn’t have some of the feature sets of classic that we need, so we won’t be upgrading for a while.
A: Cooperative control access layer, identity-driven policies, application prioritization, and centralized management/automation through the cloud are key parts of SD-LAN, which you have today. Once you move over to NG, you will start seeing the additional benefits of the open API platform, which increases programmability.
Q: Will there be any protocol standardization, or will vendors require lock-in from end-to-end with their equipment?
A: SD-LAN is certainly heading in the right direction for better integration with the network as a whole, with a wide variety of APIs available. With Aerohive’s HiveManager NG (NMS) for example, it is built entirely on APIs which would in theory allow anyone to build their own version of HiveManager to manage Aerohive devices. Plus if other vendors did the same, that same 3rd party app could also manage those solutions too!
Q: Is this just another cloud SaaS?
A: A key part of the SD-LAN is cloud, which can be either public or private by most vendors. The cloud piece is there for two reasons: First – management/automation, which reduces the complexity of operations when networks have to cope with more mobile users, devices, and apps. The second is open APIs. These APIs allow customers to either use production apps that leverage their network data for IT or business value, or customers can build apps themselves that use location, presence, monitoring, or identity data from their own users, devices, and apps. The APIs can also be used for better integration with the rest of the network.
Q: Is this just marketing?
A: SD-LAN is a new market category that helps identify and define the key attributes that enterprise Wi-Fi solutions should be providing customers today. For many years, many vendors have already been implementing SD capabilities into their solutions (not all though) for a software/protocol-driven architecture that offers QoS, identity services, app prioritization, open APIs, and cloud management/automation. SD-LAN enables a baseline to be established when comparing one solution to another by laying out the key layers of intelligence beyond the hardware alone, as we know it’s not enough to simply compare the speed of one access point to another to determine suitability these days.
Q: Where does this fit with the current Hivemanager on prem version. Migrating to a new architecture without impacting current Wi-Fi deliverables is key.
A: Software-defined capabilities have always existed within Aerohive’s architecture. For example: Way back when we introduced the distributed control protocol (cooperative control), abstracting the control plane from hardware. Cloud is also a key component of the SD-LAN architecture, as is intelligent layers of identity services (user profiles, authentication, firewall etc), app flow control, and open APIs.
Mathew Edwards is a Senior Product Marketing Manager with Aerohive.