The CCNA Workbench

The original idea was simple: create somewhere I could organise what I was learning for the CCNA.

Then I started asking questions.

Could it remember which parts of the CCNA blueprint I'd actually covered?

Could it identify areas I was weak in?

Could I practise subnetting instead of simply reading about it?

Could it generate troubleshooting scenarios?

Could it make me follow a packet through a network?

Could I interact with switches and routers rather than memorising what commands were supposed to do?

At some point, it stopped being a collection of revision notes.

It became the CCNA Workbench.

The Workbench is built around the six domains of the CCNA 200-301 blueprint.

Instead of treating the syllabus as one enormous checklist, I wanted the system to connect lessons, practical exercises, revision and assessment back to the actual topics Cisco expects a candidate to understand.

That meant building several different ways to learn.

There are structured lessons for learning the concepts, but there are also interactive trainers for things that only really stick through repetition.

Binary.

Subnetting.

Longest-prefix matching.

Routing decisions.

Packet journeys.

Troubleshooting.

I wanted to be able to get something wrong and understand why I got it wrong.

That distinction became important.

A score tells me that I answered a question incorrectly.

One of the most interesting parts of the project has been developing the networking simulation underneath it.

I wanted exercises where network behaviour wasn't simply predetermined text.

The system needed to understand enough networking logic for the outcome to emerge from the configuration.

Switches can learn MAC addresses.

Interfaces can belong to VLANs.

Links can operate as trunks.

Routers can make routing decisions.

Static and default routes can influence packet forwarding.

Administrative distance matters.

802.1Q subinterfaces can provide router-on-a-stick connectivity.

And deliberately broken configurations can create troubleshooting exercises.

That means a question can become something closer to a small engineering problem:

Here is the network. Here is what should happen. It isn't happening. Find out why.

That is much closer to how I want to learn.

I also built exam-style practice into the Workbench.

But I deliberately don't want it to become a machine for chasing an invented percentage.

Cisco doesn't publish a simple universal percentage that means somebody is "ready", so the Workbench shouldn't pretend one exists.

Instead, exam results feed back into the learning system.

Which blueprint topics am I consistently getting right?

Which ones am I getting wrong?

Was the problem knowledge, interpretation or application?

Have I demonstrated something once, or can I do it repeatedly?

The aim is not to make a dashboard turn green.

The aim is to know why the answer is right.

There is another reason this project became important to me.

I'm dyslexic.

Large blocks of technical information aren't always the best way for me to learn something, particularly when a subject introduces layers of terminology at the same time as new concepts.

Building my own learning environment meant I could experiment with presenting networking differently.

Shorter explanations.

Clear visual hierarchy.

Practical examples.

Repeated interaction.

Diagrams and packet journeys.

Small exercises before larger ones.

The ability to move backwards and forwards between theory and practice.

Rather than adapting myself to the learning material, I could start adapting the learning material to me.

There's a slightly strange loop at the centre of this project.

I started building the Workbench because I wanted to learn networking.

But building it forces me to understand networking more deeply.

If I'm going to write a simulator that decides which route a packet takes, I need to understand the decision well enough to encode it.

If I'm going to generate a troubleshooting problem, I need to understand both the correct configuration and the failure condition.

If I'm going to explain why an answer is wrong, I need to understand the misconception behind it.

So the project itself became another form of studying.

Writing the lesson makes me question the concept.

Building the simulator makes me test the rule.

Creating the fault makes me understand the failure.

The software and the learning have gradually become the same project.

The CCNA Workbench isn't finished.

That's partly because my CCNA journey isn't finished either.

As I learn something new, I find another thing the Workbench could do better.

A lesson becomes an exercise.

An exercise exposes a gap.

The gap becomes another tool.

And occasionally something that started as a tiny revision aid turns into several hundred tests and a networking engine.

Which probably tells you quite a lot about how my brain works.

Built from curiosity. Made with purpose.