Our irregular War Stories returns, with a story about a network I worked on with strict change control, but high technical debt. What should have been a simple fix became far more pain than it should have been. Lesson learned: next time just leave things alone. I’m sure the ITIL true believers loved their process, but did they realise it stopped people fixing problems?
I spotted a duplex mismatch with one of the services I was responsible for. Throughput was low, and the NIC was showing late collisions. Classic mismatch. Should be an easy enough fix, right? Whoa there son. This is an ITIL shop. No changes without an approved change request!
Change policy at this company was for a lead time for one week for most systems, or two weeks for some ‘important’ systems. Changes had to be submitted and approved before the deadline. There was no reason for the delay. Nothing happened during those two weeks, there was no extra review, you just had to wait, because that was the process.
This company had a Change Management system built on top of a main-frame application. Seriously? Yes, seriously. But it was Continue reading
Rift.io and CENX get additional funding, while F5 and Ciena have personnel changes.
ETSI NFV reaches out to the rest of the open networking community.
CloudFlare turns 5 years old this September. It's been an amazing ride since our launch. Before we launched at TechCrunch Disrupt on September 27, 2010, we'd signed up about 1,000 beta customers. It took us nine months to get those first customers. (By comparison, today we typically sign up 1,000 customers every 3 hours.)
Those first beta customers were instrumental. They put up with us when we were had only one data center (in Chicago). They put up with us as we brought traffic online in our next facilities in Ashburn, Virginia and San Jose, California — and had the routing challenges that came along with running a distributed network for the first time. They sent us bug reports, provided us feature requests, and were instrumental to building the foundation that grew into what is CloudFlare today.
Archival Footage
When we launched, we wanted to feature their stories and experience about CloudFlare so we had them submit their stories by video. Here's the video we included as part of our launch presentation.
I'm proud of the fact that more than 80% of those original 1,000 customers are still using CloudFlare five years later.
Send Us Your Stories
As we Continue reading
In recent months the news of Chris Roberts alleged hacking of an inflight entertainment system and possibly other parts of the Boeing 737 have sparked a wave of controversy. Public opinion was originally on Roberts' side, but the recent publication of the FBI affidavit changed that drastically. According to the affidavit, Roberts admitted to doing a live "pen-test" of a plane network in mid-air.
Whether this is true or not, it raises some valid concerns over the ethical implications of white hat hacking. In the case of Roberts, who, according to the affidavit, was able to steer the airplane off the intended course, the consequences could have been dire. It is not believed that Roberts had any intention of hurting either himself or any of the passengers, but if the affidavit is in fact true, the possibility was real.
To read this article in full or to leave a comment, please click here
Who owns ONIE security?
A favorite topic among network engineers, documentation is a source of both wonder and horror. Network documentation is difficult to get right. How much detail is enough? How old is that diagram, really? Can't this be automated? Wait, the automated generator spit out *that*? In this show, the Packet Pushers along with former guest Dominik discuss their documentation experiences, good and bad. What have we gotten right? What have we gotten wrong? What's been worth the trouble? What was a waste of time? What did we wish we'd documented before we really needed it?
The post Show 250 – How To Document A Network appeared first on Packet Pushers.