Author Profile - Tommy Landry is the Manager of Product Marketing for Anue Systems, joining the company in September of 2008. Tommy brings 18 years of broad marketing experience in the high tech arena, focused on technologies including semiconductors/microprocessors, database integration, embedded databases, CRM, digital warehousing, distributed temperature sensing, and IT Admin tools. Prior to Anue Systems, Tommy was the Director of Worldwide Marketing for SensorTran, the technology leader in fiber optic-based distributed temperature sensing solutions for clean energy applications. Tommy holds an MBA in Information Management and Marketing from the University of Texas at Austin and a BA from Louisiana State University.
Author Profile - Steve Mitchell is the Manager of the Integrated Systems Test Team for F5 Networks, and leads the performance and sizing test efforts for the entire organization. In addition, Steve is responsible for the organization's strategy, tools, and solutions for performance and stress testing. While at F5 Networks, he has been involved in engineering and design, performance testing, test and lab automation, and facilities design and deployment. Steve is very active in the performance testing community, having provided guidance on optimizing their use of automation for many organizations. His 17 years of experience includes time at F5 Networks, as well as ETM Entertainment Network, Sierra On-Line, Sagem Morpho, and Frank Russell.
Tommy Landry - If you are like most organizations in today's network-centric world, you need to ensure that your applications run properly over private and public Wide Area Networks (WANs) or clouds. This is particularly challenging for applications that are sensitive to network conditions, such as real-time transactions, enterprise storage, streaming media, IPTV, and VoIP.
The only way to have confidence that a particular application, solution, or service will operate within acceptable performance parameters is to test under realistic expected (or even unexpected) production network conditions prior to deployment. Conditions such as latency, bandwidth limitations, bit errors, dropped packets, and packet jitter all impact application performance. Fortunately, you can achieve this goal by emulating your own network environment in a lab.
Every day we discuss LAN testing methods in many hundreds of ways, but we can often forget that we all use the WAN to transport all that data outside of our LAN world. WAN conditions such as latency, bandwidth limitations, and jitter all impact application performance. Testing how your applications will run on the WAN is essential, as discussed by Steve Mitchell of the F5 Team.
Fortunately, you can achieve this goal by emulating your own network environment in a lab using a WAN/Network Emulator. Network emulators are hardware devices that can duplicate network conditions under user control, allowing you to precisely control the amount of errors, delay, and other impairments that you add to the network traffic. Hardware-based emulation is superior to fiber spool approaches and software-based emulators, because only hardware based emulation can test against real world conditions with the highest of accuracy and precision.
Like all testing, the quality of the testing and the data it provides will come down to ease of use, accuracy, and reliability of the testing tools. The F5 Team has tested several solutions, and they settled on the Anue WAN emulation solution, which they employ regularly.
If your WAN is down, or even worse just an inefficient transport, you are wasting money!!!
So, exactly how efficient is your WAN?
Are you getting what you are paying for?
Can your new or expanded applications work on your network?
Steve Mitchell - "The level of accuracy of the Anue [Network Emulator] is amazing. We’ve compared it against other solutions and Anue wins hands down."
At work (F5 Systems) we use the Anue Systems Ethernet Network Emulator for testing various parts of our products. Most typically, we use them for emulating a WAN between various products – they allow us to precisely simulate network conditions including loss, latency, jitter, and many other properties. They’re also useful when you want to see how a web interface deals with these sorts of scenarios.
The Anue has been rock-solid and very reliable. It’s integrated into our automation via their TCL interface, and we step through many different scenarios this way. We also gather a wealth of information from the Anue to back up the statistics we are also gathering from the network test harness, and the product under test. Overall it’s been one of the least problematic pieces of test gear we’ve ever used.
It boots super fast, and has one of the most to-the-point and speedy web UI’s. No client software required, and everything is very clearly labeled and easy to read. I like graphical UI’s to do initial setup when learning, but not when using frequently. Many test vendors provide drag and drop functionality which I find impedes general test creation when you’re doing things frequently.
One of the nicest things I like about their web UI is when you make a change to a value; the value and field around it turn yellow, so you know you need to submit your changes before things will become active. This is an excellent visual cue that things aren’t done yet.
The level of accuracy of the Anue is amazing. We’ve compared it against other solutions and Anue wins hands down. This undoubtedly has to do with their detailed FPGA hardware architecture and is also why they can maintain line rate without any issues. The configurability and features are matched with many of the other vendors, and in many areas much easier to use in Anue. They have the ability to change just about anything in the packets flowing through them, if you want.
We also use the Anue as a router within our test harnesses in some cases. It has the ability to emulate router IP addresses and act as a default gateway. This functionality was added in the last few years to their product, and was a requirement for our testing to simplify the amount of equipment involved. Previously we had been using an actual router for this functionality.