The wide area network (WAN) has always been a sore spot for change, but SD-WAN really does make a difference to application performance. As with any technology, you need to have a safety net, and that safety net is interoperability and ease of integration. This is where Ecessa has focused its efforts over the years, culminating in its SD-WAN approach.
One of the main challenges encountered in the early days of the wide area network (WAN) was that anyone trying to control their WAN required advanced border gateway protocol (BGP) CLI configurations.
The scripting approach comes with numerous operational and architectural challenges. It takes skilled staff to architect and troubleshoot this static method of designing such an important module of the network.
The BGP model requires applications to fit into a set network topology that is already built and designed. In earlier times, there was no convenient way to manage the WAN with the ability to use advanced features, such as active-active or bandwidth aggregation. The BGP WAN edge lacked flexibility and agility. Hence, one of the major issues was how to route or steer sessions over multiple WAN lines easily and without complex failover rules.
The other major issue, in the words of some users, was that you were “held hostage” by the service providers. Any problems you faced, you had to work with the service provider and abide by their processes, whether or not you thought they were savvy. The WAN is a major part of your business, yet at that time you had no direct control over it.
Ecessa – Architecture – Origins
During the year 2002, Ecessa sought to find a new and easier solution to the BGP WAN edge. This was long before the emergence of SD-WAN in 2015. Ecessa’s mission at that time was to find a way to evolve the fixed network approach so that the application could control the network design and meet business needs. That’s what they did with their initial load balancing and automatic failover WAN controllers. They created the original never down network.
Ecessa took a Gentoo Linux-based kernel and added userspace applications on top of it. The open source approach allowed them to formulate customized routines and features that enabled the easy manipulation of multiple WANs along with advanced features.
Back in those days, they were revolutionary in presenting the market with an innovative product that allowed the customization of up to 25 WAN interfaces and unlimited local area networks (LANs).
Ecessa produced a Layer 3 router that could create a purpose-built WAN and LAN. This was just like enabling a Swiss Army Knife of advanced features that could easily be inserted into any type of complex network.
As higher bandwidth public internet circuits became available for business use, the capacity for organizations to increase bandwidth more affordably – albeit not securely, as with MPLS – created new opportunities and requirements. Needs to integrate different services, needs to secure public links for private use, improve call failover and so on.
Ecessa’s research and development empowered the addition of more features, such as server failover, firewall capabilities, SIP proxy and encapsulated tunnels, to name a few. As the product matured and improved to meet customer requirements and solve their challenges, Ecessa maintained its focus on interoperability, ease of integration, flexibility and control.
An Evolution from Session-level to Packet-level Control
Throughout the 2000s, we witnessed an evolution from session-level to packet-level control products. There was an expectation that customers never wanted to drop a packet. A failover scenario with session-level load balancing could result in some packet loss as connections were reestablished. The only way to avoid dropping a single packet was to send multiple copies across a multi-connection using a packet duplication traffic routing option.
Not only did customers want to steer clear of dropping a single packet, but they also wanted to route and steer packets more efficiently. They wanted the application to control the network instead of the network controlling the application.
This demanded the ability to route and steer different application types over different links depending on the network conditions. This was Ecessa’s next big challenge. As a result of the evolution, the Ecessa product range matured from a session-based to a packet-based load balancing solution. This added a new dimension to the architecture.
Entering the Cloud Era
In 2002, most enterprises hosted applications locally in the private data center, co-location space or in the private cloud–essentially in a central location.
Branch offices had direct, private access to the corporate headquarters where applications were hosted. As a result, the common topology was a hub and spoke design. However, the recent macro shift to cloud-based services has created more reliance on connectivity to the Internet. Vendors began to offer nearly everything as a service in the cloud and we entered an era of SaaS acceleration.
Now that we operate largely in the cloud, the best point of access is not always in a centralized location. Backhauling traffic to a centralized location can be inefficient. It can cause traffic tromboning and increase latency. As a result, we started to see the introduction of a topology known as a mesh design.
Challenges with Mesh Architectures
Mesh architectures can be a nightmare to manage with the potential for hundreds of VPN configurations across the network. WANs are traditionally created and managed using protocols based on point-to-point architecture, not site-to-site. This ultimately leads to complexity when you have a dual connected site, with a number of uplinks to different service providers. Worse still, think about the complexity created when you have redundant connections coming in from multiple locations to each branch – the essence of a mesh. A traditional approach is, for many organizations, not the most efficient or right choice when you have redundant uplinks.
Secondly, there are a lot of variables that are required to guarantee interoperability from one location to another. When you want to establish connections you may encounter challenges, such as interoperability between vendors, issues with IKEv1 and IKEv2, dead peer detection and the burden of refreshing keys on a regular basis. Scripting this is burdensome.
Also, when one WAN fails you are bound to establish another connection. This can result in downtime and failover of anything between 30 – 90 seconds, depending on how complex the connection is.
In a nutshell, doing in-house scripting is problematic for complex, multi-site interconnectivity and high availability designs, especially when using multiple protocols (IPsec, PPP, GRE, etc.) to create advanced, agile architectures. Once you have a large number of endpoints, managing discrete VPNs can be overwhelming and prone to error. WAN solution providers, like Ecessa, looked for ways to automate and simplify WAN management. Out of that search, technologies like WAN Virtualization – and ultimately SD-WAN — were born.
Corporate Networks Are Like Snowflakes
Every network is unique in some way or the other, since there are different ways to configure similar services. Never will you see two identical networks. In light of this, networks are often referred to as snowflakes.
This uniqueness crops up network complexity, which somehow needs to be managed. And doing so is rarely straightforward.
Sometimes network administrators are surprised to find no structured process in place as to how design documents were translated and implemented at their organization. If they don’t fully understand what is in the network or lack current documentation, they are at a disadvantage when it comes to improving network performance.
Even when the system architecture is well documented, changes to the WAN edge can carry with them a high level of risk.
Therefore, selecting an SD-WAN vendor that provides maximum interoperability and ease of integration offers distinct advantages. This is the value proposition Ecessa offers — flexibility and control – which is leveraged by its Layer 3 router architecture.
The Interoperability Challenge
All the while Ecessa was developing advanced WAN technologies, other vendors were, too. In fact, today over 60 vendors market SD-WAN functionality. A key differentiator between them is the ability to integrate seamlessly without having to change the current network architecture or orchestration levels and where the control plane resides.
Integrating additional orchestration levels and control planes takes careful planning and support. It’s not a job for a novice. An architecture that can integrate with no changes would be welcome by most network administrators.
Challenges Facing Network and Security Teams
Some SD-WAN architectures require firewall rip and replace, which is something not all organizations are willing to do. If you are confident in your current premises-based firewall and security policies, moving to a cloud-based firewall may not suit your needs.
Security and network teams don’t usually work side by side. They are often physically separated and wear different technical hats. Bringing the network and security teams together on one platform has often been a challenge for even the most experienced project manager.
A Methodical Migration
Whenever you adopt a new technology, such as SD-WAN, many factors come in play. There is a learning curve, support concerns, proof of concept (PoC) and validation that the technology is performing as expected. All these factors need to be managed.
A competent SD-WAN vendor should have an answer to all the queries of the client and have the capability to guide their customers through a methodical deployment, while pushing for the proper change management, along with pre and post-change testing.
Customers must trust the advisor so that they can be successful in the deployment. Even the smartest and brightest technology in the world may not cut it if it can’t be installed successfully. Thence the SD-WAN needs to be installed smoothly, without adversely affecting other parts of the network.
Move with care when deploying your SD-WAN. Ideally, your vendor will guide you through a proven process for installation. It’s unlikely that you’ll be able to automate everything. Processes need to be followed and they vary from one IT organization to the other. Because, you know, snowflakes.
Vendor Technology and Deployment Experience
The market is full of SD-WAN vendors, with each offering their own value propositions. Newer SD-WAN vendors may have flashy user portals; they may also lack the experience you want supporting you, not just for a functioning technology, but for a successful, long term deployment.
Look for excellence in pre-deployment system architecture, project management, responsive technical support and a cultural fit to ensure your vendor will serve as a lasting, trusted advisor.
A few primary architectures dominate the SD-WAN landscape: cloud-based, premises-based and managed services-based. When evaluating technologies, you may uncover strengths and weaknesses with each and find one architecture will work better for you than the others.
A cloud-based service may be relatively simple to deploy, however you must sign up for their subscription model and may get locked into their IP address scheme. If you want to move to a different SD-WAN vendor later, you would bear the heavy burden of major IP rework and downtime.
Latency may also be an issue. As a matter of fact, proximity will never be on your side. It’s highly unlikely that the cloud-based vendor has PoPs that adequately serve all your branch locations. Your traffic may end up getting routed thousands of miles out of the way.
For high bandwidths you may pay extremely high prices, since the cloud-based SD-WAN vendor controls the bandwidth. Overall, you have less control of the network and rely on externals for change management. You are reliant on their architecture. If the cloud-based provider has not architected the network very well and a cloud instance goes down, you will either lose connectivity or at a minimum suffer from suboptimal routing.
Managed SD-WAN offerings are cropping up from every carrier, it seems. The carrier or ISP licenses SD-WAN technology from another vendor and offers a bundled service to businesses. While this may seem easier from a billing standpoint, there is a loss of control in this scenario and reliance on the carrier for changes and updates. Let’s face it, many carriers have weak reputations when it comes to customer service…
Premises-based SD-WAN solutions are best for organizations that desire control over their WAN and want to be able to make changes on their timeframe, using their staff or trusted advisors. Often, when security is a concern, using a premises-based SD-WAN is preferred so the network administrators can maintain control all aspects of security policies and traffic routing. Many organizations prefer working with a trusted advisor to provision circuits at the best cost and for the lowest latency. This level of hands-on control isn’t right for every organization. This is the space Ecessa fills, and they work closely with their clients to make sure they get it right.
Wide area networking has evolved over the past 20 years. The SD-WAN market is filled with vendors all claiming competitive advantage. Anyone with experience will understand that track record is key. If you can’t install with ease and on-time you might as well stay with the burden of the traditional WAN architecture. Interoperability, ease of integration, flexibility and control are key for successful SD-WAN deployments.
To learn more about Ecessa WAN solutions, visit www.ecessa.com/products or call 800.669.6242.
Matt Conran has more than 19 years of networking industry with entrepreneurial start-ups, government organizations and others. He is a lead architect and successfully delivered major global greenfield service provider and data center networks. Core skill set includes advanced data center, service provider, security and virtualization technologies. He loves to travel and has a passion for landscape photography.