Engineers are often unstuck by poor planning and get hit with large financial penalties as a result. Projects can become mired in delays and complications due to unforeseen costs and expenses. There are some unavoidable bumps in the road, but most could be foreseen and eliminated in advance. I want to share a few tips based on some experiences I’ve had over the years. Continue reading
Designed to fail
Security audits are a fantastic way to improve the security of your network. A good auditor can highlight critical flaws in your design and configuration before they are launched into the big bad world. However I think there is a massive issue with security audits; they are designed to fail.
We’re in the midst of a networking boom at the moment and new technologies are being released at a rapid pace. So much so that network engineers need a suite of knowledge management tools to navigate the daily deluge of articles, documents, twikis and notes.
That said, how much of your day-to-day activities are markedly different than they were two years ago? As I see it, the role of the network engineer is largely unchanged. One still has to gather requirements, write designs docs, order, ship, build, configure and troubleshoot. Design reviews are still required and change procedures are still needed before touching the live network.
All too often we engineers end up blindly actioning tasks without questioning the true requirements driving the request. Even if you are ‘efficient’ at deployment, doing the wrong task well is not ‘effectiveness’.
Picture the scene when a project manager walks into your workspace. “Hey junior-engineer-I’ve-never-seen-before, I need to you to install a 3750E-48TS in the Phoenix branch office. It’s a straighforward task, so I expect it complete by Friday.”
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.
Imagine you’ve just designed and deployed a data center. It was hell but you are smiling. Your design is homogenous, simple and elegant. A greenfield datacenter full of shiny, identical network devices. Because the design was so consistent and repeatable you scripted the generation of the device configurations without too much hassle. This is a network with an easily ‘provisioned’ network configuration.
But day-one provisioning is only one part of the puzzle. The real prize is a centrally ‘controlled’ network configuration, where all config changes happen centrally and a configuration policy is enforced for the lifetime of the network. Whilst this seems like the holy grail, you need to understand that you will have to trade some flexibility to reach this easy-to-operate nirvana.