A few weeks back I posted about my experience using VirtualBox to create running Arista vEOS instances. I loved how VirtualBox made is so easy to create VMs. However it seemed unwieldy and error prone to rely upon the VirtualBox console to attach each vEOS interface to a particular LAN segment. My last post explored using the CLI to create these mappings. I had planned to generate topologies using a script to create the appropriate vboxmanage commands at some later date.
I did manage to create a python script that read a topology file and create the right links between the VirtualBox vEOS VMs. I thought it would be cool to control that script via a GUI of some sort. You know, like using GNS3 for drag an drop link creation. I downloaded the latest version of GNS3 to test IOS and noticed that it had a new VirtualBox category. Woot! Continue reading
Sometimes it’s best not to trust network vendor datasheets. Nothing quite beats a controlled test of a network device in your lab with your config and your required features. But if you want to load test multiple ports on your 10G device-under-test (or DUT), then things can get very expensive, very fast. In this post I’ll show a test topology that will help you turn 10Gbps of test traffic into 640Gbps or more.
Corrupted frames are the devils spawn. A few noisy links causing frame corruption can quickly degrade network performance, and troubleshooting them is getting harder. These integrity errors generally occur when signal noise causes a binary ‘1’ to be mistaken for a binary ‘0’ or vice-versa. This post takes a look at integrity errors and the impacts of corrupted frames in a cut-through switched network. Throughout this post I’ll use the term ‘CRC errors’ term to refer to frame integrity errors which were detected by CRC comparison.
A few years ago, I had the chance to attend an IXIA training course in our Dublin office. I had seen the time-suck of network test gear before. So I said, “I’m not spending a week trying to learn a test-set. It’ll be cool, but what’s the point. I won’t get the time to apply those skills, then I’ll forget, and it will be a wasted week.” I declined the training.
Photo by http://www.flickr.com/photos/clemmac/ – some rights reserved
We have a network lab?
Spirent presented their new lab-management software, called iTest Lab Optimizer, at network field day 4 recently. Their product name isn’t catchy, but it is very descriptive and addresses a market need. The simple fact is that most lab networks don’t get optimised to their full potential for some of the following reasons:
- Nobody knows what is in the lab (or that one exists) – Inventory Management
- The availability of the lab devices is unknown – Availability and scheduling
- The patching status of the devices is uncertain – Fixed undocumented patching.
- Setting up your device-under-test is hard and takes time, so you try to prevent other users from mangling your config. – DUT config management