5.4Accessing devices and collecting data

Diagnosis presupposes being able to access the target device and pull information. Do you operate it remotely from your PC, attach a cable right in front of it, or enter the office network safely from outside?—the right means changes with the situation. This section covers the representative access and data-collection means, from the viewpoint of when to use each: remote operation with RDP/SSH/Telnet (mind encryption), VPN for outside connection, direct console connection with a terminal emulator, NMS and cloud management (Meraki) that bundle many devices, and scripts for automation.

5.4.1Remote access, VPN, and console

• RDP remotely operates mainly a Windows desktop screen (the whole GUI). SSH is the standard way to connect to servers and network devices over an encrypted, secure CLI. Telnet is also a CLI connection but is unencrypted, sending even passwords in clear text, so it is discouraged—use SSH today.
• VPN builds an encrypted tunnel across the internet from an outside device to connect safely into the office network. It is often the prerequisite for diagnosing internal devices from home or while traveling.
• A console connection attaches a cable directly to the device's console port and operates it with a terminal emulator (PuTTY, Tera Term, etc.) on the PC. It is the last resort for reaching a device you cannot enter over the network or one in an initial state with no IP set.

5.4.2Managing many devices and automation

• An NMS (network management system) centrally monitors and manages the state of many devices (uptime, traffic, faults). Instead of visiting each device, you survey the whole from a dashboard and spot anomalies faster.
• Cloud management (Meraki)—like Cisco Meraki—configures and monitors devices together from a cloud dashboard. You can check status and change settings remotely without going on site, suited to multi-site management.
• A script is a small program that runs the same checks or settings automatically and repeatedly. It is used to gather information from many devices at once, or to run routine inspections the same way every time—making repetitive work efficient and error-free.

Suppose that while working from home you are asked to check the state of an internal switch. The first thought is "how do I even reach that device?" You cannot enter the internal switch directly from home, so you first connect safely into the office network with a VPN. Once inside, you connect to that switch's CLI with SSH to check its state. There is an option to use old-fashioned Telnet, but because Telnet sends passwords and operations in clear text, the right call is to avoid it even inside a VPN and choose the encrypted SSH. Yet when you try SSH, there is no response—perhaps it is unreachable by IP, or the IP settings themselves are wrong. For a device you cannot enter over the network like this, there is a last resort: ask an on-site person to attach a cable directly to the device's console port and make a console connection with a terminal emulator (such as PuTTY). Because the console touches the device independent of network state, it is indispensable for initial setup or recovery when the IP is unknown. Further, if the target is not one device but "collect the firmware versions of switches at all sites at once," then rather than SSHing to each by hand, checking in bulk on an NMS or Cisco Meraki dashboard, or auto-collecting with a script, is faster and surer. The key is the judgment of discerning the situation—"see one device now" vs. "watch many continuously," "can enter over the network" vs. "needs a direct connection"—and choosing the means. More means is not stronger; being able to pick the minimum appropriate means that fits the situation is what is asked of an introductory support technician.

5.4.3Section summary

• Remote operation: SSH (encrypted, recommended) / Telnet (clear text, discouraged) / RDP (Windows GUI); from outside, use VPN into the office network
• A device unreachable over the network can be reached directly via a console connection plus a terminal emulator—the last resort
• Monitor many devices centrally with an NMS or cloud management (Meraki), and automate repetitive work with scripts