A friend of mine has just ordered a shiny new packet generator for his network lab. I’ve spent some time working as a QA engineer in a network lab and wanted to share some advice.
You can purchase stateful and stateless packet generators from major vendors like Spirent, IXIA or Agilent. If you just need to test throughput, latency or loss, a stateless packet generator will do the trick. The test hardware will use an ASIC to produce line-rate 10G traffic or higher. The Cisco Enterprise Testing Book calls this a ‘bit-blaster’ which I love. In the wrong hands it can also be a ‘network-melter’. Continue reading →
I’ve had an interesting few months doing WAN circuit turn-ups for a new Data Centre. I dealt with three major carriers, and each experience was worse than the next. I’m not sure why I held such high expectations but I was surprised by their hopeless inefficiency in delivering what should have been a standard product. In this post I’ll examine the problems I saw and their root causes.
In all three situations, 1Gbps Layer-2 ethernet circuit was ordered with a copper ethernet handoff from a rack-installed NID/NTU/whatever-you-call-it-yourself. Lets look at the five issues I hit whilst troubleshooting. Continue reading →
East/west segmentation is required in the data center to protect backend networks from each other. Segmentation is often implemented using ACLs between VLANS on your core switch. The ACLS are maintained by network or security engineers but define the flows permitted between hosts or host classes. Continue reading →
Scenario: You are an engineer who runs a managed network on behalf of a customer. Your manager has asked you to create a change control process. Your customer and your manager will measure you only by the uptime or outages they experience, and don’t care what your process looks like.
Nothing sparks engineering debate quite as much as ‘network change control’. It’s one of those topics we love to hate. We feel buried by useless bureaucracy. We ask, ‘Why can’t our managers just trust us, instead of weighing us down with meaningless process and red tape’?
This may be a controversial perspective but I think we’ve gotten exactly what we deserve. We endure heavyweight change control procedures because when we make network changes we break stuff. We break stuff in truly spectacular ways, in ways we could never have predicted. We hit weird bugs, asymmetric configuration, faulty hardware, poor process, or we just have a brain fart/fat-finger/etc.
Sometimes the phrase ‘working the ticket queue’ is code for ‘doing meaningless work’. If you find yourself playing whack-a-mole with your ticket queue, then this is the post for you. You should strive to do meaningful work and this post discusses some ways to get more value out of the trouble ticketing process. Continue reading →