Working Towards My CCNA 200-301

Understanding the network behind the technology.

I've always been someone who wants to know what is happening behind the screen.

It's not enough for me to know that something works. I want to understand why it works, how the different pieces communicate, and what happens when it stops working.

That curiosity has led me towards my next challenge: working towards the Cisco Certified Network Associate (CCNA) 200-301 certification.

Why CCNA?

Networking increasingly overlaps with almost everything I find interesting professionally.

Modern field service is no longer purely mechanical or electrical. Equipment is becoming connected. Consoles communicate with networks. Devices need IP addresses. Software talks to hardware. Services depend on internet connectivity, switches, routers, wireless networks, DNS, DHCP and increasingly cloud infrastructure.

When something doesn't communicate properly, simply knowing how to replace a component isn't always enough.

I want to understand the infrastructure underneath it.

That is what attracted me to the CCNA.

It isn't simply another qualification to add to a CV. For me, it is about developing a proper foundation in networking rather than collecting bits of knowledge whenever I encounter a problem.

Turning "I Think" Into "I Know"

I've picked up a lot of networking knowledge through experience, experimentation and building things myself.

I've configured home networks, experimented with managed switches, VLANs, wireless networks, DNS, firewalls, Raspberry Pis and different pieces of network hardware.

And naturally, I've broken things.

Then fixed them.

Then wondered why they broke.

Then changed something else.

Then broken them again.

That cycle is genuinely one of my favourite ways to learn.

But there is a difference between knowing enough to make something work and properly understanding the principles behind it.

Working towards CCNA is my way of filling those gaps.

Instead of saying:

I know this configuration works.

I want to be able to explain:

I know why this works.

That distinction matters to me.

What I'm Learning

The CCNA 200-301 covers a broad foundation of networking knowledge, including network fundamentals, network access, IP connectivity, IP services, security fundamentals, and automation and programmability.

That means getting comfortable with concepts such as IPv4 and IPv6 addressing, subnetting, routing, switching, VLANs, trunking, wireless networking, DHCP, DNS, NAT, access control, network security and troubleshooting.

Some topics are familiar.

Others make my brain briefly resemble a router with every status light flashing at once.

Subnetting, I'm looking at you.

But that's exactly the point.

The areas I find difficult are usually the areas where there is the most to learn.

Learning by Building

I learn best when I can actually interact with something.

Reading documentation is useful, but give me a network diagram, a console window and something that isn't working and I'll happily disappear down the rabbit hole.

So my approach to CCNA isn't simply memorising enough information to pass an exam.

I want to build networks.

Configure them.

Break them.

Troubleshoot them.

Rebuild them.

Then understand exactly what happened.

Tools such as Cisco Packet Tracer make it possible to experiment with network designs without needing a cupboard containing thousands of pounds worth of enterprise networking equipment, although I'm certainly not ruling out gradually turning part of my house into a miniature data centre.

Why Networking Matters to a Field Service Engineer

At first glance, networking and repairing commercial fitness equipment might seem like completely different worlds.

Increasingly, they aren't.

The modern field engineer sits somewhere between mechanical engineering, electronics, IT support, networking and customer service.

A fault might originate from a mechanical component.

Or a console.

Or cabling.

Or network configuration.

Or customer infrastructure.

Being able to methodically identify which layer is actually causing the problem makes an engineer significantly more capable.

Rather than treating "the network" as a mysterious box that belongs to somebody else, I want enough knowledge to have meaningful conversations with IT teams and accurately diagnose where responsibility for a problem sits.

That doesn't mean pretending to be the customer's network administrator.

Beyond the Exam

Passing the CCNA 200-301 is the target, but I don't want the certificate to be the finish line.

Networking connects naturally with several other areas I'm interested in, particularly cybersecurity, infrastructure, automation, connected devices and software development.

The deeper I've gone into building applications and experimenting with technology, the more I've realised how valuable networking fundamentals are.

APIs, servers, databases, cloud services, IoT devices and applications might appear completely different on the surface.

Underneath, they all need to communicate.

Understanding that communication gives me another layer of understanding when I'm designing, diagnosing or questioning a system.

Still Learning

I'm not presenting myself as a network engineer.

I'm learning.

There will be commands I forget, subnetting questions that require considerably more coffee than they should, and configurations that work perfectly until I touch one completely innocent-looking setting.

That's part of it.

My career has never really followed a single straight line. I've worked across customer service, account management, photography and field engineering, while continuing to explore technology and build things alongside my day job.

CCNA is another piece of that puzzle.

It's about becoming a better troubleshooter.

A better engineer.

And someone who understands a little more of what is happening behind all those blinking lights.

Current status: CCNA 200-301 in progress.
The network is up.
The engineer is learning.
And somewhere, inevitably, there's a cable plugged into the wrong port.