Aruba EdgeConnect: FEC in Action!
The network throughput of a network is impacted by the loss, delay, and bandwidth of the links. Loss and delay are the reality of any network and cannot be escaped, I mean these are always there. For example, international connections can have up to 200 milliseconds of delay.
Satellite connections have
more than 500ms of delay which is normal for these circuits. The agreement has
acceptable loss over the circuit whenever you get a connection from the service
provider. For example, an MPLS link can have up to 0.5% of the loss. Of course,
the Internet circuit has more loss and can be higher during peak time.
In this article, we’ll see the live impact of the loss and
the negative application performance due to this. After that we’ll cover enabling
FEC can solve this problem. Aruba EdgeConnect Enterprise solution capability is
utilized here to demonstrate the after-FEC enablement. It’s going to be more on
the configuration part. If you need more information on FEC, please go to this link.
As per the network setup below, we have two sites connected
through MPLS & Internet Circuit. Each site has a host (Ubuntu System) and
we are going to run the iperf between Workstation 1 & Workstation 2. During
the iperf transfer, we’ll increase the loss, and we’ll see how two different
applications (UDP_5001, UDP_5002) behave.
Figure 1: LAB Setup
One of the applications (UDP_5001) is protected by the High
Availability Path Conditioning configuration while another application (UDP_5002)
is not protected and uses the High Bandwidth Path Conditioning configuration
setting.
Initiate iperf transfer between Workstation 1 &
Workstation 2. During this traffic transfer using port 5001 we’ll see that underlay
links are getting impacted but due to FEC, packets are recovered at destination
using parity packets and there was no impact observed for Real-time applications
like the one we are simulating using UDP port 5001.
Workstation 1 is the server in the setup and below out says
the iperf server is enabled for a 5001 UDP port. We can see there is a 0% loss
during normal conditions where all links have a 0% loss.
Figure 2: Workstation 1 (iperf Server)
Workstation 2 is our client and uses the same port as displayed in Figure 2.
Figure 3: Workstation 2 (iperf Client)
You can see there is no loss introduced to the network. All
conditions are ideal here.
Figure 4: WAN Emulator No Loss over Primary link
Figure 5: Traffic Flow Information
Let’s introduce the 5% loss on the MPLS link as it is the
primary link for traffic transfer for RealTime Business Intent Overlay. As the
application needs to use the premium reliable link for all data transfer and
the Parity packet over the next link.
Figure 6: 5% Packet Loss Introduced on Primary Link
(MPLS)
In Figure 7, you can clearly see the 5% packet loss is reflected
on both the links in the Appliance Live View window. You can also see that the
whole traffic is moved to another link (INET1) as the loss was introduced to the
primary link (MPLS) first. One thing to note here is, traffic transfer from the
primary to the next circuit was hitless we don’t see any drop in the graph.
Figure 7: Appliance Live Chart 5% Loss on MPLS
Let’s do more with setup and now this time, introduce a loss
of 10% for the links. The figure below shows the loss increased to both links.
Figure 8: 10% Packet Loss Introduced on WAN (MPLS & Internet)
As the loss was introduced to
both the links, now we can see some sub% loss was observed by the Server. We can see with a 10% loss for both the physical links, introduce only a 0.2% of negative
impact on the application.
Figure 9: Server Out with up to 0.2% of Loss with 10%
underlay Loss
The Appliance live view below for RealTime BIOS is showing the 10% loss on the physical links. However, there is no impact on the application running in RealTime overlay (still Green).
Figure 10: Appliance Live Chart 10%
Loss on MPLS
As already mentioned, a Loss test will be performed for both RealTime
Applications that are protected using FEC and Default Applications where FEC is
not enabled. We have already seen that there was no impact for RealTime applications.
Now it’s turn for Default Applications.
Default application traffic has been simulated using the UDP port 5002. Workstation 1 is the iperf server and Workstation 2 is the client.
Workstation 1 is configured
as Server running UDP 5002 Service (Default Application). In a normal scenario
with no loss on links, the server is showing 0% loss for traffic transfer.
Figure 11: iperf Test for UDP 5002 Port
(server)
Workstation 2 is configured as the client transferring traffic to
Workstation 1 over UDP port 5002.
Figure 12: iperf Test for UDP 5002 Port
(Client)
As per the output below, traffic for UDP 5002 port is
categorized into Default BIO. This BIO’s traffic is not protected from packet
loss events in the network. We’ll see the negative impact as the loss is introduced
to the network.
Figure 13: Traffic Flow Information
The WAN emulator is now configured to introduce a 5% loss over both links. As per the output below it’s showing a 5% loss for MPLS & Internet links.
Figure 14: 5% Loss over both the links
As the loss is introduced on the links, we can see the impact first on the application itself. See the output below captured from the iperf server, we can see the same loss (5%) is observed for data transfer.
Figure 15: iperf Server Output w/ 5%
loss
We see how the loss over links impacts the application
performance. As per the Figure 16, Aruba Orchestrator Appliance Live View chart
shows both physical links, as well as overlay applications, are impacted due to
loss when there is no FEC enabled.
Figure 16: Appliance Live View Chart w/ 5% loss
Let’s go little further and introduce
10% loss on links. Below output shows links are with 10% loss now.
Figure 17: Traffic Emulator 10% loss on
links
Immediately the loss is reflected in the Server window below.
Figure 18: iperf Server 10% loss observed
As per the output below, Appliance
Live View chart reflect the same output.
Figure 19: Appliance Live View w/ 10%
loss
During this specific test, it is observed
UDP 5001 port traffic was recovered even though there was a 10% loss. As per the report
below, the underlay experiences a 10% loss but it was only 0.09% for the actual
application (UDP 5001) as it was recovered by FEC.
The below report also highlights when
there was default application (UDP 5002) testing, there was no recovery as both
the pre-FEC and post-FEC values are the same.
Figure 20: Appliance Report - Network
& Application Loss Recovery
In short, we can say a useful
feature where the network links are noisy. Features like FEC, Packet Order
Correction, and TCP Acceleration make Aruba SD-WAN a unique solution when it comes to
performance over any transport.
I hope you find this informative
and impressed with the power of the solution to display things preciously in a simple
dashboard.
Continue Reading...
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
A Quick Intro - Aruba EC-10104 Appliance - The Network DNA
Aruba SD-WAN: BOOST Feature - The Network DNA
Aruba SD-WAN: Dynamic Path Control - The Network DNA
Aruba EdgeConnect: Path Conditioning - The Network DNA
Aruba EdgeConnect Enterprise : An overview of Traffic Handling Features - The Network DNA
An Introduction to Aruba SD-WAN: Business Intent Overlays - The Network DNA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
