Hello, I'm James.

How I started

I left school in 1995 and bounced around a few low-level technician jobs. That's where I picked up the easy parts of networking: IPX, NetBIOS, Ethernet and Token Ring. My first network was two office PCs joined with BNC coax.

After a few years I'd had enough of building and fixing Windows PCs. The company wouldn't pay for Cisco training, so I put myself on a one-week crash course and passed the CCNA. That was 2001, and I still look back and wonder how I managed it.

The same company that wouldn't pay for the course recognised the result and moved me into the network team. I started at the bottom, worked my way up to Senior Network Engineer, and ended up in charge of the department. After that I moved on to roles that gave me different technology and different problems. The full list is on LinkedIn.

Right place, right time

I can't point to one person and say they got me here. What I have had is a habit of being in the right place at the right time. Some of those jobs taught me amazing things, from the whole experience and from the people in it, and those lessons have served me well ever since.

Who I work with means more to me than the work I do. Over thirty years that has added up to some great friends and connections, and they're what I value most from it.

Thirty years of kit

I've worked on Cisco from CatOS on a Catalyst 6009 through to IOS XE and NX-OS, alongside Check Point, F5, Palo Alto, Fortinet and Juniper. These days most of my time goes on Cisco design and support and Check Point clusters.

I'm not interested in collecting model numbers. They date fast. What lasts is knowing why something works and what normal looks like, so you can spot what isn't.

A network Dr House

Medical students are taught: "When you hear hoofbeats, think horses, not zebras." Look for the common causes first. It's good advice, and most network faults really are horses: a cable, a VLAN missing from a trunk, a typo in an ACL.

Read enough of the field notes and you'll probably spot a bit of Dr Gregory House in how I go after a fault. House went looking for zebras because everyone else had already ruled out the horses. When a fault has beaten everyone else, it's usually a zebra, and the only way to find it is to follow the evidence one step at a time, even when it leads somewhere odd.

The other half of House is "Everybody lies." Not on purpose. The user says nothing changed. The provider says the circuit tests fine. The server team says it must be the network. Talking to people matters as much as the show commands, and the job is to check what they tell you against what the network shows you.

I'm made by dyslexia, and it has helped me think differently. That's probably why I enjoy the zebras.

The nights I remember

Every engineer has a handful of nights they don't forget. These are some of mine, written up in full in the field notes.

• The 2am call after lightning hit the buildingA Catalyst 6009 with half its slots dead. Every cable labelled, moved and re-patched before the business opened.
• Split brain after an upgradeA pair built for resilience, with both halves convinced they were in charge.
• The circuit that "tested fine"Until I read the manual for the provider's own box.
• When the back-out plan fails tooTwo firewall nights, and the step nobody wrote down.
• Proving it wasn't the networkJumbo frames, end to end.
• Senior managers on a major incident callWhat I've learned about talking to senior managers while the service is down.

Listen first

In Creed, Rocky tells Adonis: "As long as you're talking, you're not listening." On a bad night, the answer is often in something the user, the logs or someone on the call has already said, if you were listening.

Sir John Harvey-Jones said: "In order to solve problems, information has to be shared; and not only information, but doubts, fears and questions." That's the best description I know of a good major incident call. Say what you know, what you don't, and what's worrying you.

Four things I'd tell anyone running a change

1. Keep backups you can reach when everything is down. I've been caught out by cloud backups I couldn't get to when I needed them most.
2. Have an escape plan, and think through the what-ifs. I've had three independent failures at once. A copy on my own laptop saved the night.
3. Call the vendor early. Forget being the hero. If a change is guaranteed to cause an outage, line support up before you start.
4. Double your outage estimate. In Star Trek III, Kirk asks Scotty whether he always multiplies his repair estimates by four. Scotty's answer: "How else can I keep my reputation as a miracle worker?"

They're built into the free Change Window Starter Pack and every MOP the Change Window Kit writes.

Teaching

I've taught as well, through a free email course and one-to-one tutoring. My rule was always the same: teach people what they need to pass, then tell them straight what they'll never use in the real world.

Where I am now

I run Clifford Network Solutions Ltd, a small UK company, and work with ITogether on Cisco network design and support. The history of networking page was my wife's idea. She was right.

Why I built this site

In the age of AI, I wanted to get all my notes and thoughts together in one place.

Anyone can produce a tidy explanation of anything now. What you can't produce is having stood in a comms room at 2am. Everything here comes from work I've actually done, kit I've configured, and mistakes I've made or watched other people make. The commands are checked against Cisco's current documentation, but the judgement behind them is thirty years of doing the job.