CloudGenix SD-WAN | WAN Virtualization
Deploying and managing the Wide Area Network (WAN) has become more challenging. Engineers are faced with a number of design challenges such as traffic flow decentralizing, inefficient WAN link utilization, routing protocol convergence and application performance issues with active – active WAN edge designs.
Active – active WAN designs that spray and pray over multiple active links present technical and business challenges. To do this efficiently you have to understand application flows. There may also be performance problems. When packets get to the other end there maybe out-of-order packets as each one of the link propagates at different speeds. The remote end has to reassemble and put back together, causing jitter and delay. Both high jitter and delay are bad for network performance.
Spray and pray method over two links increases bandwidth but decreases “goodput.” It also affects firewalls as they will see asymmetric routes coming in. When you want an active – active model, you need application session awareness and a design that eliminates asymmetric routing. You need a way to slice properly up the WAN so applications flows can work efficiently over either links.
Decentralizing traffic from data centre to branch requires more bandwidth out to edges of the network. We are seeing a lot of high bandwidth applications running to remote sites. This is what business are now trying to accomplish. Traditional branch sites usually rely on hub sites for majority of services and generally do not host bandwidth intensive applications. Today, remote locations now require extra bandwidth and bandwidth does not get cheaper every year.
Inefficient WAN utilization
Redundant WAN links usually require a dynamic routing protocol for traffic engineering and failover. Routing protocols require complex tuning to load balance traffic between border devices. Border Gateway Protocol (BGP) is the primary protocol for connecting sites to external networks. It relies on path attributes to choose the best path based on availability and distance. Although these attributes allow granular policy control they do not cover aspects relating to path performance, such as Round Trip Time (RTT), delay and jitter. BGP does not always choose the “best” path, while the “best” path may have different meaning for different customers. For example, customer A might consider path via provider A as the best due to price of links. Default routing does not take this into account.
Packet-level routing protocols are not designed to handle complexities of running over multiple transport agnostic links. A solution needs to arise that eliminates the need for packet-level routing protocols.
Routing Protocol Convergence
WAN designs can also be active – standby, which requires routing protocol convergence in the event of primary link failure. Routing protocol convergence is slow and to speed up additional features, such as Bidirectional Forwarding Detection (BFD) are implemented that may stress network’s control plane. Although mechanisms exist to speed up convergence and failure detection, there are; still, a number of convergence steps, such as a) detecting the topology change, b) notifying the rest of the network about the change, c) calculate a new best path d) switching to the new best path.
Branch Office Security Parameter
With traditional network solutions, branches connect back to the data centre with the data centre typically providing Internet access. The application world has evolved and application such as office 365 in cloud are directly consumed by branches. This drives a need for branches to access directly these services over the Internet, without going to data centre for Internet access or security scrubbing. There should be an option to extend the security diameter into the branches without requiring onsite firewalls / IPS and other security paradigm changes. A solution must exist that allows you to extend your security domain down to the branch sites without having costly security appliance at each branch. Essentially, building a dynamic security fabric.
What is the solution? – CloudGenix
The solution to all these problems is SD-WAN ( software-defined WAN ) and CloudGenix product offering is based around solving these challenges. SD-WAN is a transport-independent overlay software based networking deployment. It uses software and cloud-based technologies to simplify delivery of WAN services to branch offices. Similar to Software Defined Networking (SDN), SD-WAN works by abstraction. It abstracts network hardware into a control plane with multiple data planes used to make up one large WAN fabric.
SD-WAN change the DNA in where networks are built.
SD-WAN in a Nutshell
At a basic level, when we consider Wide Area Network (WAN) environment, we are connecting data centres to a number of branch offices to deliver packets between those sites; supporting transport of application transactions and services. CloudGenix SD-WAN platform allows you to pull in Internet connectivity into those sites so that is becomes part of one large transport-independent WAN fabric. CloudGenix monitors the paths and the application performance on each of the links (Internet, MPLS, LTE ) and chooses the best path based on performance.
There are many different forms of Internet connectivity (cable, DSL, and Ethernet). They are quick to deploy and at a fraction of the cost of a private MPLS circuits. SD-WAN provide the benefit of using all these links and monitoring, which one is best for what applications. Application performance is continuously monitored across all eligible paths—direct internet, internet VPN, and private WAN. It creates an active-active network and eliminates the need to use and maintain traditional routing protocols for active – standby setups. No reliance on the active – standby model and associated problems.
Server virtualization and automation in the data centre is prevalent but WANs are stalling in this space. It is the last bastion of hardware models that has complexity. Similar to how hypervisors have transformed data centres, CloudGenix aims to transform the way WAN network are built and managed. When server virtualization and hypervisor came along we did not have to worry about the underlying hardware. Simply, provision Virtual Machine (VM) and run an application of choice. Similar methodology to what CloudGenix are doing in SD-WAN. Today’s WAN environment require you to manage details of carrier infrastructure, routing protocols, and encryption. SD-WAN pulls on all WAN resources together and slices up the WAN to match the applications that site on them.
Spraying packets down both links can result in 20% drops or packet reordering. SD-WAN makes packets better utilized, no reorder, better “goodput.” SD-WAN increases your buying power and results in buying lower bandwidth links and running them more efficiently. Over-provision is not necessary as you are making better use of the existing WAN bandwidth.
CloudGenix don’t want to mend routing, and they want to end it. They want to provide a centralized control model opposed to the fragmented control that you have today. CloudGenix never have the application data flows, flow through the central controller and if the control plan is not reachable the network still operates. Only time you need the controller for new sites or policy changes. They are taking the fragmented control approach, centralizing it while also having the benefits of a distributed system. Now, that you are a flow-based system and not packet-based the controller provides visibility tools. You can publish back to the controller a level of visibility that wasn’t possible before.
Rather, than relying on bits, bytes jitter and latency, they start looking at application transactions. CloudGenix product do all the network traffic engineering so the SLA they apply is the best. They are monitoring RTT, sliding windows, ACK delays for each flow. Not just the IP or TCP packet but the application suites too. This creates a good view of performance for the application. They perfectly understand the applications flowing in the network and apply QoS to those flow to treat some traffic differently than the other. For example, they treat rich media different from transactional applications.