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.
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