Johannesburg, 04 Oct 2019
SD-WAN is at the leading edge of software-based networking deployments. It offers significant business value for organisations in terms of business agility and the ability to leverage Internet bandwidth economics. The question was asked how well SD-WAN will perform over a satellite network. We tested SD-WAN to show that this was possible and that SD-WAN can be used over a satellite network.
What is SD-WAN?
SD-WAN is an acronym for software-defined WAN and is used in a wide area network. SD-WAN simplifies the management and operation of a WAN by decoupling the networking hardware from its control mechanism. It allows companies to connect remote branch offices to data centres and each other and deliver the applications and services required to perform business functions.
A key application of SD-WAN is to allow companies to build higher-performance WANs using lower-cost and commercially available Internet access, enabling businesses to partially or wholly replace more expensive private WAN connection technologies such as MPLS.
SD-WAN replaces traditional branch routers with products that simplify the set-up process and provide zero-touch deployment. Products can be physical appliances or virtual appliances. A centralised controller is used to manage and configure the network and set policies and prioritise traffic.
An SD-WAN appliance is basically a combination of traditional routers, firewalls, caching server and WAN optimisation built into one appliance. It uses VPN-type technology to create a virtual network over Internet links or other connectivity methods, and use policies to route traffic over specific tunnels or use redundancy methods to reroute traffic in case of link failure.
Using an SD-WAN solution provides benefits that simplify management, give businesses agility, utilises more cost-effective links, improves the user experience and increases security.
SD-WAN over satellite
Because the SD-WAN solution builds tunnels, with IPsec encryption for security over the WAN links, these tunnels will negate the optimisation techniques provided by the satellite platform as seen with normal VPN links.
Therefore, the SD-WAN equipment will need to provide functionality to enhance the user experience and provide a business-like quality to the WAN.
Testing of SD-WAN
The following picture shows the network topology used for the tests conducted.
Network set-up
On the remote site, an iDirect modem was used, connecting to the SD-WAN appliance with a PC behind it. L2OS (Layer2 over Satellite) was configured from the modem to the hub. From the hub, traffic was sent over a backhaul link, also on Layer2, to Teraco. In Teraco, the traffic was handed over to the client’s network over a Layer2 interconnect. The VSAT link was configured as 500kbps/2.5Mbps (uplink/downlink).
This established a Layer2 connection end-to-end, from the SD-WAN appliance at the remote site to the SD-WAN appliance in the client’s core network, and allowed them to set up a PPPOE connection between the SD-WAN appliances. iPerf was used to establish a TCP session between the end-points and generated the traffic that we monitored during the tests to provide the statistics below.
Test 1 – Benchmark test
The first test was done just over the L2OS link, without any SD-WAN functionality configured. This was to establish a benchmark for normal traffic over VSAT, where the VSAT link was doing the acceleration and optimisation of the traffic.
Graph 1 on the right shows that the specified VSAT bandwidth could be used.
Test 2 – PPPOE, without L2TP
Next, PPPOE was enabled between the SD-WAN equipment, but this showed a big reduction in performance, see graph 2 on the right. The PPPOE results only showed 550kbps/1.25Mbps, which was worse than expected.
The main reason for the degradation is that the traffic is now inside a tunnel and the VSAT equipment cannot optimise the traffic anymore, therefore there's a change in colour on the graph from blue to orange. The colour change shows that the traffic type changed from reliable (TCP) to unreliable traffic (non-TCP).
Test 3 – L2TP over PPPOE
Then standard SD-WAN configuration was applied, which uses an L2TP tunnel inside the PPPOE, and the SD-WAN appliances now performed the traffic optimisation on the link. Only download was tested and a rate of 2.1Mbps was achieved, which was better than normal PPPOE connection, see graph 3 on the right.
When multiple connections were opened, we found this value increased to 3Mbps.
Downstream QOS
The Downstream QOS results correlate with the Remote Sat traffic statistics. The spike to 4Mbps (showed in the red square in graph 4) was achieved when five parallel iPerf streams were opened.
The average platform utilisation was around 6.5Mbps and the max achievable utilisation for the platform is 9Mbps, which left 2.5Mbps open for the test. The results with the SD-WAN on L2OS was around 2Mbps – 2.5Mbps, which means that SD-WAN on VSAT performance is about 10%-15% less than standard VSAT performance.
One thing that was noticed was that the keep-alive requests needed to be prioritised in the L2TP tunnel, or else the link would flap. Unfortunately, this is not something that can be configured on the iDirect side, because the traffic is encrypted, so the hub will not be able to identify the keep-alive in order to prioritise the packet. This was tested and it worked perfectly.
Conclusion
The theory is that the UDP nature of the L2TP did not affect the acceleration of the iDirect platform and that L2TP can handle TCP window scaling better than PPPOE. If a site opens multiple TCP sessions over the link, the site will be able to utilise the max MIR of the VSAT link.
Even without compression and caching on the SD-WAN configuration, the acceleration over the L2TP tunnel created by the SD-WAN configuration proved to be very good, and a single TCP session showed only 10%-15% less throughput. With only a couple of sessions over the SD-WAN link, the full bandwidth could be utilised.
Share