Learn to Teach Yourself

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!

Secure your OOB!

As anyone who has had to work with remote datacenters or remote offices will tell you, you can never have too much OOB (Out-Of-Band) access.  Whether it be because you’ve fudged an ACL on a firewall or fat-fingered your route filtering, some form of remote access to your network devices comes under the heading of “bacon saver”.

A terminal server doesn’t necessarily have to be a dedicated device: as many network engineers know, a Cisco router equipped with some manner of async card makes a fairly basic but serviceable terminal server.  I’ve used both 2800 and 2900 series routers equipped with HWIC-8A and HWIC-16A modules at work, while my home lab uses a 2600XM (which does double duty as one of the “BB” routers in the IPexpert topology) with an NM-16A.  I’ve then equipped these devices with some kind of alternative network access – sometimes an old-school analog dialup or ISDN connection, other times a cheap ADSL connection – so that you can still get access to the site to troubleshoot when all other routes to the site are down.

Read the rest of this entry »

Short-Term Memory Loss

When I started preparing for the CCIE lab, I made a decision to build my own physical hardware lab at home.  Partly because I’m a geek and that’s the sort of thing we do, and partly because it made my life easier.  The ability to decide on the spur of the moment to fire up the rack and do an hour or two of labbing was very attractive to me, especially as most of the lab rental providers are US-based and work on 8 hour slots – this doesn’t always translate to friendly labbing hours here in the UK.

My lab is based loosely on the IPexpert topology – but built mostly using 1841s.  After a successful evening of labbing I’d shut down the rack and gone to bed.  The next day I’d fired it up again only to be caught by several of the 1841s getting stuck in a loop of stack traces and reboots.  The main error of any use was:

SYSTEM INIT: INSUFFICIENT MEMORY TO BOOT THE IMAGE!

Houston, we have a problem…

Read the rest of this entry »