imelamory - Fotolia
While discussions about software-defined WAN tend to focus on its features and benefits, IT teams need to carefully consider and compare underlay connectivity. SD-WAN direct internet access, or DIA, is used to describe the underlay connectivity, which may consist of Ethernet leased lines, broadband and LTE. With the ability to deploy SD-WAN across these various options, what should IT teams consider?
Key considerations before choosing SD-WAN DIA
Cost savings. One of the main tenets of SD-WAN marketing revolves around the total cost of ownership cost savings of SD-WAN versus traditional MPLS networks. Most enterprises achieve cost savings with SD-WAN by using low-cost internet providers to serve branch office locations. While IT teams shouldn't shun such an approach, they must consider the implications across application performance, network uptime and support.
Bandwidth, security and deployment. Internet leased lines are typically delivered to headquarters and branch sites, which require predictable and highly available bandwidth. Where remote users and smaller branch offices are concerned, SD-WAN delivery may take the form of a client-based VPN application across broadband, 4G and 5G. Teams should evaluate the VPN client for factors like how the client deploys security and how easily teams can manage users. If deployment is difficult and protracted, the business experience could be frustrating.
Feature set. When evaluating broadband, 4G and 5G, IT teams must also consider the SD-WAN feature set to assess how the offering will meet the demands of severe performance changes from packet loss and other related issues. For example, teams may consider forward error correction with packet duplication for delay-sensitive applications to ensure an alternative link is always available to maintain the call, as in the case of VoIP.
Common SD-WAN DIA architectures
1. Internet only, multiple ISPs SD-WAN underlay. When enterprises use multiple ISPs, applications must transit across more than one network, which increases the possibility of hop-to-hop latency. While this may not create a big issue in national networks, global enterprises must consider how their mission-critical and delay-sensitive traffic will ultimately perform.
This architecture can also result in potential support delays. Regardless of whether a provider, vendor or team is monitoring and liaising with the various ISPs, it can often be difficult to pinpoint where performance issues occur. From an admin point of view, managing the contact and support tickets can often create an overall point of weakness for an otherwise feature-rich SD-WAN offering. To compound issues, this architecture results in multiple billing entities to manage.
2. Internet only, single ISP SD-WAN underlay. An alternative to seeking out local ISP connectivity is to use the capability of a single public IP backbone. Unlike in the multi-ISP strategy, latency and jitter service-level agreements (SLAs) associated with the internet product make performance more predictable.
3. Internet, single ISP with core private backbone. In addition to using multiple ISPs or single ISP services, certain SD-WAN vendors also offer a private backbone. In many ways, accessing an SD-WAN platform with core network capability offers a good transition from private WAN services, such as MPLS. Any IP packets traveling along the private IP backbone are covered by an SLA.
4. Private MPLS. While many vendors may try to predict the demise of MPLS, private circuits remain a component of good hybrid architecture for some use cases and organizations. As an underlay technology, however, MPLS is no longer the choice for almost all enterprise businesses, due to the feature-rich, secure and agile nature of internet-based SD-WAN.
Business needs dictate product outcome
Any business deploying an SD-WAN DIA underlay should carefully consider all aspects, including support, performance and uptime SLA. The danger occurs when IT teams brush away any concerns regarding internet access to the SD-WAN vendor feature set. The core of a good WAN procurement process is network design, which must include how uptime can be architected via delivery of the right offering. While it might be tempting to procure dual low-cost ISP circuits, the business could be better served by some form of diverse access from a single provider.
As with all procurement projects, the business needs should dictate the product outcome. If IT teams focus on cost reduction, key elements of the service may cause downtime.