Posts

Five Design Principles for the Network Architect - Availability

(#2 of 7) In the first post in this series , I shared a summary of my fundamental design principles which I try to apply to every network design I am involved in.  The follow-ups to that summary post will discuss these at greater length - this one addresses Network Availability. The network exists to provide the transport for endpoints to be able to consume services in a "remote" location.    Whether the endpoints are application servers in racks in a DC trying to consume database entries, wireless clients accessing an application in the data centre, sensors collecting data and dropping that data into storage, and regardless of location of the services themselves - public cloud, private cloud, co-lo DC - the fundamental measure of success of the network is availability of the service to the endpoint and thus the user. Clearly then availability can't be considered a simple measure of the network as a whole - it takes a number of capabilities and properties ...

Call to Arms!

Completed a great couple of days in labs and discussions with fellow travellers on the journey to the programmable network!  We were in London on a Cisco Cat 9K/DNA Center Programmability course, with the legend that is John Swartz (of Boson tests and Cisco books fame).  He really started opening our eyes to the possible, looking at how through the magic of Python it is possible to run event-driven processes on LAN switches, orchestrate the management capabilities of DNA Center, and build platform-agnostic configurations using YANG models, then deploy them over NETCONF. This stuff really brings it home what is there now and what will be possible in the networks of the 2020s.  It's time to start assembling the ideas to build out the real tangible network service that we can offer customers so that they can consume the networks the way they need to for their business.  Zero-touch provisioning for IoT.  Software overlays for abstracting the complexities of the n...

The Tyranny of the Immediate

I've been reading about and trying to make more sense of the "Tyranny of the Immediate", a situation to which I seem to fall   victim all the time.  The phrase can be applied to all manner of scenarios – indeed if you Google it you'll come up with references to everything from the housing market to prayer.  What do I mean by it and how does it affect me?  Basically it is the daily conflict between what is   deemed   to be urgent at that moment versus what is important in the longer term.   In my day-to-day, this takes one of three forms:   Things or people busting my plans for the day/week/month with something that is just so urgent that it can't wait;   Misunderstood priorities and/or dependencies in a project or infrastructure delivery leading to a short-sighted tactical solution;   Short-termism in career and personal development – looking at what skills are needed now and studying for those, without considering the...

Five Design Principles for the Network Architect - Intro

(#1 of 7) Whilst studying for the CCDE , you stumble across new design methodologies all the time, each of which set out some fundamental principles by which you should look to adhere when building your network solutions - the one that springs to mind is Chapter 1 of Russ White's book "Optimal Routing Design" .   The idea is that you bear those simple ideas in mind as you go through the design process, checking back in with them to make sure that the design you produce will lead to a network which is robust and manageable, but still meets customer requirements. Through an iterative process of my own, I have arrived at five principles I try and embody in my work, and over coming blog posts, I'll go into more detail on how I look to apply each of them.   They are: Availability … is the fundamental desirable property of a network, its raison d'ĂȘtre.   The network exists as the transport to deliver apps to users, make data available to apps, and coll...

Start of my journey

I have been wanting to start a blog, my blog, for a while now.  I've written a couple of things for company and Cisco blogs but by their nature they weren't *mine*.  And then an online challenge in the Cisco Champions Spark room prompted me into action.  And so here we are. I wanted to choose a name for it that meant something, that reflected me.  Most of my online presence revolves around the fact that I now work for a VAR, designing and building networks with Cisco products, and that I have certain prestigious Cisco qualifications.  When you are chasing those certs, it is easy to let them define you - especially when you are able to claim your CCIE number.  It's just ten years since my number was given to me - years of practice leading me to reach the top of my configuration game! - and every couple of years since, I have slogged away for a couple of months to recertify. Finding it tougher each time to pass due to the fact that my days at the CLI wer...