One solution that is now ready for prime time thanks to some great work from the Cisco Tail-f NED folks is NSO device connections over a terminal server. For those who don’t know, a terminal server (‘TS’) is a piece of networking equipment that provides a gateway between a network interface and a physical connection to a device console port. This enables one to connect to the serial port on a network device by SSH’ing to a specific TS IP address and port combination that maps to the device serial port connection. Terminal servers are often deployed in the rack with the networking gear but with a connection to a dedicated management network. This provides management connectivity regardless of the states of the in-band interfaces and routing.
Having an ‘always reachable’ network interface for device management is a dream for NSO devices, but there is a catch. This solution will only work for those devices that have CLI-based NEDs.
Why is that? Console connections, and therefore the TS connections to them, are for CLI commands. Therefore, the ‘format’ of the data over a serial port/TS connection is ‘CLI’ so it follows that only the devices that have a CLI-based NED are going to work. That leaves out Netconf NEDs (including Juniper), SNMP, and proprietary non-CLI NEDs too, but with Cisco and Arista supporting CLI NEDs, there are still plenty of potential opportunities to use this type of NSO device connection.
So how does it work? At a high level, because the TS is really just a CLI proxy, all you have to do is configure the IP address of the terminal server as the device address, the TS port for the device as the device port, and the rest of the parameters the same as for direct connections to the device. However, those who have used terminal servers before know that there are a few gotchas in there that need a little extra effort. At a high level these are:
- An additional level of login. The TS is really a proxy, and it usually has its own authentication. The Arista, IOS, and Nexus NEDs have a container for configuring these parameters (ned-settings/xxxx-proxy-settings) when the remote-connection type is ‘serial’.
- Extra carriage returns required. If you have ever logged in to a device over a terminal server, you’ll remember hitting carriage return a few times out of impatience or necessity to get to the next prompt. These extra carriage returns are now sent periodically until the prompt comes back from the device. The IOS NED has a ned-settings/cisco-ios/connection-settings/prompt-timeout that specifies this retry time.
- Console logging disabled. There are sometimes issues with the NED calculation of sync status if console logging is enabled. The NED is running over the console and these extra messages may affect the sync comparison.
- Console port speed. It is highly recommended to set the console port speed up from the default of 9600 baud to as high as it can go between the device and TS. Arista seems to be limited to 38400 baud, but the Ciscos can go higher.
Even after all of these years, the terminal server remains a key piece of network gear in many networks, and now NSO can talk to them over the console port just as it does over the management IP addresses. While it is still recommended to use the management IP for steady state device operations, it is good to know that the option exists for those times when the network may not be so steady.
