|
Listen to post:
|
Software-Defined Wide Area Networks (SD-WANs) promised to address the high costs, rigidity and limitations of private MPLS services. Like so many technologies, though, there are the promises of SD-WANs and then there are the realities of SD-WANs. SD-WANs reduce bandwidth costs, no doubt, but enterprises are still left having to address important issues around cloud, mobility, and security.
The Problem of MPLS
Bandwidth costs remain the most obvious problem facing MPLS services. Anyone who’s purchased MPLS bandwidth for their business and Internet DSL for their home has endured the surreal experience of paying 3 times or even 10 times more per megabit for MPLS bandwidth. High per megabit pricing is out-of-step with today’s tendency towards video-oriented, bandwidth-intensive Internet-and cloud-bound data flows. Spending precious MPLS bandwidth to backhaul this traffic to a centralized Internet hub makes no economic sense, particularly when direct Internet access could be available from the office or within region.
Less pronounced, but perhaps equally important, is the rigidity of MPLS services. Provisioning new MPLS locations can require three to six months, depending on the service provider. Bandwidth upgrades and changes can also take weeks. Contrast that with Internet connections, where activation requires just days, even minutes, in the case of 4G.
Yes, there are good reasons for MPLS’ higher costs. As managed services, MPLS services are backed with service level agreements (SLAs) governing downtime, latency, packet loss, time to repair, and more. MPLS uptime is typically high, on the order of 99.99% per year depending on the service.
Additionally, MPLS loss and latency statistics are more consistent and generally lower than those of the Internet. Internet performance has improved significantly over the years, no doubt. As this post notes, overall Internet packet loss rates steadily improved since 1999, reducing by as much as 88 percent.
The problem, though, is the consistency of path performance, particularly as connections cross between Internet providers. In our recent survey of more than 700 networking, security, and IT executives and professionals from around the globe, 43% of respondents indicated that latency (along with cost of buying and managing appliances) was their number one WAN challenge. While MPLS providers minimize latency by running their own routing end-to-end (or by negotiating premium connections with other MPLS providers), Internet routing optimizes for economics. Internet providers dump packets on peering networks depending on the economic realities, adversely impacting application performance.
However, the additional value of MPLS doesn’t improve the IT balance sheet. With CIOs seeking budgets to drive new initiatives, finding ways to reduce WAN costs to free up budget is driving many enterprises to consider SD-WANs.
The Promise of SD-WANs
SD-WAN providers have argued that organizations can reduce costs and increase their agility by augmenting and, at times, replacing MPLS with Internet services.
To achieve those aims, SD-WAN nodes form an encrypted overlay across the underlying data services, such as xDSL and 4G Internet services, or private services, such as MPLS circuits. As traffic enters the SD-WAN, application-aware routing algorithms evaluate the end-to-end path performance across the available underlying services, selecting the optimum path based on application-constraints, business priority and other metrics. Email replication, or file transfers and other bandwidth-intensive, latency-tolerant applications may be sent across an Internet path, while VoIP sessions, which are sensitive to jitter and packet loss, would be sent across MPLS (or an Internet path with low jitter and packet loss).
It is possible to achieve to similar capabilities across MPLS by combining Dynamic Multipoint VPN (DMVPN), Cisco Performance Routing (PfR), and real-time quality measurements. However, those measures add complexity to the configuration. Tools, such as PfR, can be tricky to deploy and maintain. Adding new applications to the WAN, for example, may force updates to router configs. SD-WANs automate these and other steps.
Enterprises have long improved site availability by pairing MPLS with backup Internet connections. Active-active configurations are possible with routing, but can lead to imbalanced connections. Path failover is also too long to sustain a session. Policies are also needed to prioritize traffic flows in the event of an outage. Practically, most enterprises leave their secondary connections dormant.
SD-WANs make using dormant Internet connections trivial. Minor policy configurations allow SD-WANs to balance traffic across connections. In the event of a brownout or blackout, additional policy details determine access to the primary link. Improved uptime by dual-homing locations is simplified further with SD-WAN by using xDSL and 4G from different providers. Again, it’s not that this was impossible beforehand without SD-WANs; it’s just made more accessible.
The Prospect for the New WAN
Moving away from the physical WAN to a virtual overlay is a first step towards addressing the needs of the modern enterprise. SD-WANs, however, don’t go far enough, leaving the enterprise dependent on MPLS and fail to address today’s cloud, security and mobility challenges.
While the Internet performance has improved, latency and packet loss rates can and do fluctuate significantly moment-to-moment and day-to-day. This is particularly true when connections reach between continents or dense Internet regions. Unpredictable performance poses a significant challenge to delivering mission critical services and real-time applications. As such, many enterprises invest in purchasing and engineering their SD-WANs, but can never abandon MPLS, forced to maintain those services to handle their “sensitive” traffic.
If continued dependence on MPLS was the only challenge for SD-WANs that’s one thing. After all, Internet connectivity is continuing to improve and, perhaps, in another life time it will provide the consistent performance on long-distance and inter-backbone connections we find on MPLS. But the greater challenge with SD-WANs is that they fail to adapt to fundamental changes to the enterprise..
When we first built our MPLS-based backbones, the WAN was synonymous with site-to-site connectivity. We connected offices and headquarters, factories and data centers. Applications resided in datacenters and sites we controlled. Our perimeter and our responsibilities were demarcated by the company’s final hop beyond which was nothingness of pre-Internet days or the big bad world of the Internet.
Remote and teleworkers were the exception. They’re connectivity challenges were often addressed by a different IT group and certainly a different product set than the one we used to build our WANs. Nearly half of all organizations still force their mobile users to connect to an appliance in a specific location in order to gain access to public cloud applications.
Today, the network perimeter is all but gone, thanks to mobility and the cloud. Yet, IT must still provide mobile users with access to cloud applications and services without compromising on performance, security, manageability and control. Mobile users are still concerned (whether they know it or not) with selecting the optimum path for their traffic. They still need to have their traffic secured end-to-end. Operations teams still want to know mobile users traffic patterns and more. Forcing separate remote access equipment with its own set of policies and controls makes little fiscal or operational sense when those policies and controls are already needed for the SD-WAN.
Most SD-WANs do not address mobile workers or, for that matter, the cloud. There is no “SD-WAN mobile client” or mechanism for the mobile worker to connect into the SD-WAN. As for the cloud, most cannot situate their SD-WAN nodes in or near the datacenter running the company’s cloud instance(s) or housing the user’s data. Consequently, enterprises lose out on SD-WAN benefits in both cases: user traffic may be unencrypted, path selection is impossible, and any management insight and control is gone.
Cloud and Internet access also increase the costs of SD-WANs. Breaking traffic out at the branch or regional Internet portals makes fiscal sense, but increases a company’s attack surface. SD-WANs lack the tools to address those risks. Their security is limited to encrypting traffic in transit and, in some cases, hardening their devices against attack. Firewalling, URL filtering, anti-malware –threat protection tools needed to protect the enterprise are not part of the SD-WAN, which is why some SD-WAN vendors partner with security vendors. Enterprises are left purchasing, deploying, and maintain security equipment and software, costs often ignored when SD-WAN providers tout SD-WAN’s savings.
Bottom Line
SD-WANs are a valuable first step in developing a more easily deployed and managed WAN. But enterprises adopting SD-WANs must be prepared to address unmet performance and security challenges for offices, the cloud, and mobile users. What will that new SD-WAN look like? We’ll dive into find out in our next blog post.