More about Cisco's USB Console Port

This past fall, I was able to work with a Cisco 1941 router, allowing me to explore the USB console in a bit more depth. Because it was the first time I've had an opportunity to work with that interface on the Cisco gear, I came to the installation process as a new user, without any previously  loaded software for this Cisco interface. This was actually beneficial, because it exposed a few other issues that might affect you if you were to approach it today.

When I first plugged the blue USB cable into my computer, nothing happened. That is, no USB device was yet detected. It appears that the USB chip in the cable gets its power from the Cisco device. Once I had the USB cable connected to the router, that's when the USB device was detected.

On a Windows 8.1 system, the USB driver is not found, and a generic interface failed to load properly, resulting in new communications. Searching the Cisco site, you will want to search for “Cisco Windows USB console driver”. The most relevant links I found work installation guides for my hardware. However, the only software download links which were still valid were dated in 2010, and the installer file for windows only supported Windows Vista, XP, and older Windows Server 2000 software.

The good news here, is that the Vista drivers included 64-bit code, and this happily installed under Windows 8.1, properly identifying the Cisco adapter as a Cypress (chip manufacturer) device,  and loaded appropriate drivers… requiring a reboot of the system.


  Device: Cypress 
  Driver added:  CiscoSerial
  Device Installed: ciscoserial.inf
  Device installed: cypressserial.inf
  Driver Management has concluded the process to add Service CiscoSerial...


On Cisco equipment which includes a USB console, there is also an LED next to the USB console interface. NOTE: When the internal interface chip is activated, this LED will illuminate, and that is a visual indication that the local RJ-45 interface has been deactivated because the USB console is active.  If the USB chip in the cable isn't initialized, the LED won't light, and the console won't be swapped.

Caution: When swapping the console channel between the RJ-45 interface and the USB interface does not alter the console process state. That is to say, if you are logged in on the RJ-45 port and already using the enabled mode, and the USB interface is activated, the USB user is now logged in and in the enabled mode!  Conversely, if you leave a session login and enabled, and then remove the USB interface, that enabled session is still now active on the RJ-45 interface. This is a strong argument for having the exec–timeout command set on your serial console line 0.

The USB serial console has a few minor differences, depending on the Cisco hardware family and IOS version. For example, not all versions will support the usb-inactivity-timeout 30 command, but this is a useful method to try and revert to the RJ-45 console, if you have a deployed console server implementation.

Swapping between RJ-45 to USB, or USB to RJ-45, does not force a logout of the consul processed. There was no visual indication (no characters received) on the RJ-45 interface which indicated that the serial process has been diverted to the USB port, or been returned to RJ-45.

 While you can connect multiple Cisco USB interfaces via a USB Hub, each Cisco device does take up a COM port on your Windows machine, or a TTY port on your Linux or OS X machine. As a result, I cannot see this as a practical method to connect the serial console for many machines in data center service. (Using the RJ-45 serial console to a console server for remote access to dozens of machines is still a much more scalable solution.) However, I think that the USB console on a Cisco product is an elegant way to use a laptop or desktop device for setup of new equipment coming in prior to deployment. It offers a quick solution for devices which only have USB interfaces, such as tablets or netbooks, to use a single cable for the configuration and quick debugging, rather than needing to support a USB-to-DE9 interface.

I am grateful for access to the 1941 ISR to be able to do this testing, and for a few candid conversations with Cisco folks who are close to the USB serial console project.

All Together Now...

You use Console Servers to manage the serial ports of various devices, right? So, it only makes sense that a 'Best Practice' would be to connect the console ports of your Console Servers to a port on a console server, so you can monitor the Console Servers, too, right?

BUT, to do this 'right', you need to connect it to another, different console server. After all, when do you really need to use the console? When the machine is having a problem, and WHEN THE DEVICE REBOOTS! (All Caps used for emphasis...sorry if I offended anyone. ;-) When the device reboots, your serial console is how you see what the machine is doing until it gets going sufficiently for the network to be of use to you. So, if you connect your serial port to another port on the same Console server, you can monitor it when all is going well, but when things go badly, you've just lost your console access as well.

Tonight, I hit a bit of a snag...because I had connected some Console Server console ports to other "nearby" Console Servers. (Imagine 18" console jumper cables...why not, the 'different' units were close enough.) "What could be the problem with that", I had thought.

Tonight was the night to upgrade the software on this set of Console Servers...complete with systematic reboots between revision levels. Doing the three in parallel, to take advantage of 'cut-and-paste' to minimize the chances for typographical errors. Halfway through the reboots, I stop seeing progress...because the reboot of Console Server A had taken out the console access for Console Server B...

So, I type this note as I wait for the Console Servers to reboot and for my console access to stabilize again, and I consider whether my tie would have been worth the extra ~125 feet of cable to make the console runs to diversely-disparate Console Servers, to minimize the chance of a 'cluster service' outage taking out closely-grouped Console Servers. Food for thought.

-Z-