A user says "the network is down." You do not yet know if it is a dead cable, a flapping port, a device that fell off the network, or a config change nobody logged. So you open an SSH session. Then another to the upstream switch. Then you are reading show-interface output in three windows at once, trying to hold it all in your head.
The tools you actually need are not exotic: ping, traceroute, a cable test, interface counters, and a way to find where a device really connects. The problem is that they live behind a scattered set of CLI sessions. NetGUI's troubleshooting workbench puts them on one screen, in the order you would actually use them.
Start With Reachability
Before you touch anything physical, confirm what can and cannot be reached. Ping tells you whether the device answers; traceroute shows you where the path breaks. Running both from the same screen means you are narrowing down the problem, not guessing which hop to blame.
Check reachability and trace the path to any device without opening a jump box or hunting for the right session.
Test the Cable Without Walking to It
If a port looks dead, the next question is the physical layer. A TDR (Time Domain Reflectometer) cable test measures the pair and reports the distance to a fault, so you learn "open at 12 meters" instead of "maybe try a new cable." You pull that from your desk instead of sending someone with a hardware tester.
Pro tip: Distance-to-fault turns a vague "the cable might be bad" into a specific spot to inspect. That is the difference between a five-minute fix and a lost afternoon.
Run the cable test from the workbench and read where the fault is, so a bad run is a fact rather than a guess.
Read the Interface in Plain Language
Interface counters tell the truth, but only if you know which numbers matter. The interface checker pulls status, errors, and statistics and explains what they mean, so a rising CRC count or a duplex mismatch gets called out instead of buried in raw output.
Status and error counters come with plain-language explanations, so the signal is not lost in the noise.
Find Where a Device Actually Lives
Half of troubleshooting is finding the port a device is really on. NetGUI can search for a MAC address across every switch and run an ARP lookup, so you go straight to the access port instead of walking the topology by hand.
Locate a device across every switch and resolve it with ARP, so you chase the port, not the symptom.
Get the Full Picture on One Port
Once you have found the port, the Port X-Ray pulls everything about that interface into one view, so you are not stitching together five commands to understand a single port. It is the deep look you reach for after you know where to look.
Gather the full detail on one interface into a single view, instead of running command after command by hand.
The Bottom Line
Troubleshooting is slow when the tools are scattered, not when the problem is hard. Work top down: reachability, then the cable, then the interface, then where the device lives, then the port in detail, and keep it all on one screen.
You spend your time diagnosing instead of reconnecting SSH sessions, and every check is logged for the next person who asks what happened.