Amazon Web Services (AWS) is the most popular public cloud infrastructure in the market, but not much is known about the AWS infrastructure itself. Because of this, there is a huge need for AWS users to test the AWS infrastructure before deployment. Additionally, other virtualized network functions such as vRouters and vFirewalls, which run in AWS, also need to be tested. Spirent’s Cloud and Virtualization solutions can help you with test in and on the AWS environment.
Putting the AWS to the Test
To run on AWS, Spirent uses Spirent TestCenter Virtual, which can be downloaded as a software application (either .deb or .rpm format) and installed on the Hypervisor of your choice.
The above topology represents the simplest setup to test an AWS. It has several components that you may recognize, several that are new for AWS, which are detailed below.
Instances: I used two Spirent TestCenter instances. These two instances were created from Centos6.5 publicly available AWS instances and installed the STCanywhere software. After installing it once, the instance was registered and named STCany. This allows the image to be shared. Some of the key things to notice are the number of interfaces in each instance, the elasticIP and the VPC subnet. I used an m3.medium instance with 1VCPU and 3.75 GiB of RAM for this.
VPC subnet: VPC in Amazon lingo stands for Virtual Private Cloud. It is the way you create virtual network connections between instances. A “VPC subnet” creates a L2 network between any two ports. At least two VPC subnets are required for any test. The first subnet would be the management subnet which connects the application to the STCany instances. The second VPC subnet is the DUT.
Network connections: Each instance should have at least two vNICs. One vNIC should be in the management VPC subnet and the other NICs (the test ports) can be connected to the DUT. Ensure that the “Change Source/Dest. Check” is set to “Disabled” to spoof MAC addresses and IP addresses. If “Enabled”, you can only use the default IP address assigned by DHCP and the MAC address provided by the hypervisor. To see the full power of the STC test capabilities, a test tool test tool that can emulate thousands of MACs and IPs, ensure “Source/Dest. Chec” is “Disabled” for the test port as shown.
ElasticIPs: I added ElasticIPs to the management ports of the instances for the GUI to access the VMs. Alternatively, one can have the GUI running in AWS on a Windows instance, in which case there is no need to assign ElasticIPs.
Note: You cannot connect more than one vNIC from one instance to a single VPC subnet.
Application: The application or the GUI was running on a laptop for this setup. This is the Spirent TestCenter application that is used for both hardware and virtual products. This is a big convenience for folks like me, because, I am used to the STC GUI and this GUI works seamlessly for Spirent TestCenter Virtual. The basic RFC 2544 test from the wizard was used in this instance.
Note: The STC application/GUI is the same for hardware or virtual.
This is the result for a simple UDP test with 200 Byte packets, expecting 75 Mbps. Below are the results from the chart. There is packet loss, but it’s not continuous and happens at irregular intervals. Is your AWS application resilient to intermittent packet loss?
There are certain use cases like VOIP and HD streaming that very sensitive to packet loss and delays. However, 70 Mbps is above what you would require for these applications. Online gaming that requires real-time data transfer and high resolution may be the one impacted by this. So, these applications might want to use an instance flavor with “Enhanced Networking” which are SR-IOV enabled, and also utilize “Placement groups” to minimize latency and create high-throughput networks. Be aware of the cost of these higher end instances.
Whatever your choice is, make sure you test it. Let me know how your test goes.