Image by AustinEvan on Flickr

I changed jobs at the end of October and while leaving many of my colleagues behind was difficult it’s been great to get stuck into learning a new network and working with some different technologies.

In the last few weeks I’ve been designing and configuring an expansion of an existing datacentre.  This has given me a great opportunity to sit down and read through design guides and configuration docs on both the Cisco Nexus 5k range of switches and the Cisco ACE4170.  Before this I didn’t really know anything in detail on these devices other than general awareness and various bits and bobs I’d picked up from my compatriots on Twitter.

Both of these technologies gave me plenty to learn about – they both have their fair share of limitations and restrictions on how they can be deployed and both have subtle CLI differences that have entailed scrabbling through documents, scratching heads and asking questions of those better versed in these areas than me (thanks @EriksonIan!).  These gotchas ranged from the trivial (not knowing about the “trunk” parameter to “spanning-tree port type edge”) to the more fundamental (understanding how vPC works).

It was while I was finalising the configs that I realised I’d taught myself an awful lot during the last few weeks – technologies that I had never touched were almost becoming second nature and I was starting to feel vaguely competent (but hopefully not dangerously so).  This thought took me back to my University days – the program leader of the course I was studying had a phrase that he trotted our with regularity that was basically to the effect of:

It’s only now that I can see how true that statement was.  The best people I have ever worked with have all had an extremely good grasp of the fundamentals and the ability to take a new technology, new product, new service – whatever it may be – and make sense of the knowledge and put it to good use.

My personal #1 piece of advice to any aspiring techie would have to be: “Learn how to teach yourself”.  Find out what it takes for you to learn something in-depth and retain that knowledge.  It could be that reading documentation or 3rd party books is enough for you.  You might find that labbing something up and putting practical skills to work works better, or that audio/video-based training is what you need.

Whatever it may be – find a way that works for you and go put it to good use!

There are of course, two caveats – firstly that these books are NOT for the current version of the CCNP certification – they are a year or so out of date.  Secondly, I’m based in the UK, so bear in mind that shipping anywhere outside the UK is likely to be expensive!

If you’re interested, either comment on this post or contact me as @xanthein on Twitter.  It’d be a shame for me to have to just bin them.

By filipe93 on Flickr

Back in 2005, fueled by the growing trend of manufacturers to make their products cheaper, disposable and less home-repairable, Make Magazine published their “Owner’s Manifesto: A Maker’s Bill of Rights“. This document laid out the tenets of the maker/hardware hacking/upcycling movement – essentially the freedom to use your legally-owned goods in whatever way you damn well wanted!

It struck me today that we network engineers could use a similar document – something we can brandish in the faces of vendors when they start doing Stupid Things™ and acting against the interests of those who install, configure, operate, monitor and tweak their products day-in, day-out.  So, without further ado – a manifesto for those on the front-line of the networking industry!

1. Open standards please. We’re all tired of lock-in, and redistributing between EIGRP and OSPF gets old pretty quickly.
2. Likewise, producing your own standard when the open standard is still being drafted is only one step away from Microsoft’s “embrace and extend“.
3. Off the shelf parts: nobody wants to pay $900.00 for a 256MB CompactFlash card – or is the gold plating mandatory?
4. Is it too much to ask for a list of line cards on one page, with port types/density, QoS features and oversubscription details for each? Yeah, I thought as much.
5. Likewise, why do I have to dig, harangue my VAR and give my inside leg measurement just to get information that is essential to deploying your products?
6. Nobody likes spending all day on a problem only to find that the documentation they’ve been working off is wrong. Update it or bin it!
7. Training/certification: DO teach us how to configure your products.  DO NOT make us learn your latest ‘marketecture’ just so we can pass an exam (thanks to @ioshints for that term).
8. 9600, 8N1.  It works, bitches.
9. If your product needs rack rails, make them easy to fit and remove. Yeah, I’m looking at YOU, Cisco WAE-512 and F5 BIG-IP 1600.
10. Talking of rails: ship rails/ears with everything. Even the smallest offices have racks these days.
11. No default usernames, passwords, SSIDs, WPA keys.  A product that’s vulnerable out the box can really ruin someone’s day.
12. When your kit goes wrong, I don’t expect to spend 3 days going back and forth between vendor and VAR trying to prove that it’s definitely a hardware fault (I’m looking at you Check Point). New kit, now please.
13. Lastly, listen to your engineers. We might not always have decision-making abilities but there’s always the chance we could sway a purchasing decision one way or the other…

If you’ve got anything you want to add to that list, leave a comment please!