Why I made it
The course material covered the same network from different angles. A lecture explained a rule, a lab turned it into commands, and the useful evidence often appeared later in a show command.
I wanted a revision tool where those parts stayed connected. Instead of keeping separate notes, command lists and quiz answers, NETDES puts the path from concept → configuration → verification in one page.
The current console is a single HTML file. It works offline and stores study progress in the browser.
How the console is organized
The interface follows the way I actually revise the course rather than the order of files on disk.
Configuration is followed by a check
The lab workbench records the objective first, then the commands, then the verification commands. This keeps the configuration from becoming a list to memorize.
Example: VLAN access port
vlan 10 name STUDENTS ! interface Fa0/1 switchport mode access switchport access vlan 10
show vlan brief show interfaces status show interfaces fa0/1 switchport
Example taken from the VLAN/access-port lab workflow in NETDES.
That pattern repeats through the console: decide what should happen, configure it, then read the device output that confirms or contradicts the expectation.
Turning STP rules into deterministic logic
The STP section was the part that could not stay as notes. I added an educational 802.1D port-role solver so I could enter a topology and work through the same decisions used in the course labs.
The implementation compares path cost, Bridge IDs and port IDs. Root-path selection is repeated until no better candidate is found. The code itself describes this step as Bellman-Ford-style convergence.
What the project forced me to understand
Reading that the “lowest Bridge ID wins” is easy. Implementing the full decision path exposed the details that are easy to skip when studying: what happens when path costs tie, which port ID is compared, and why a link is designated on one side but blocked on the other.
The same thing happened with configuration. Writing a command is only half the task. The lab pages made me keep the expected verification output close to the configuration, which is closer to how troubleshooting actually works.
NETDES is still a study console, but the part I value is the reasoning behind it: translating written network rules into repeatable decisions and checking those decisions against device output.
What I would improve next
I keep the public claims on this page to what can be checked in the current repository. The solver is present in index.html, and the lab content is visible in the console.