I've taken typing ASCII strings into serial ports as a normal interaction for decades now. Sometimes the strings seemed like arcane incantations that made little sense to me, but seemed to do the right things (in the end) on the device that I was talking to. I've written programs and scripts that took input from a user (via a keyboard, serial port, and other inputs), and I learned to "sanitize the input", and how to parse it, and how to cough up an error if the input was something unexpected, or not in the format that I wanted.
Over the years, I've had to sift through manuals, and command-completion information screens, in order to be reminded what my options are, on this device, running that version of firmware. Mainly because it seems so familiar, overall, but the occasional command options, or the order of arguments, may have been changed.
Today, I was sifting the web, looking for information to configure the serial port settings on an Avocent CCM4850. It turns out that line had roots from Equinox, with a different command syntax from the Cyclades line (which was also absorbed into Avocent, many years ago). But It also looks like the command syntax used for Lantronix and others. And this is when I decided to write this article.
Earlier in this month, Cisco Networks announced it was going to sue Arista Networks (Cisco's announcement) over what looked like copying of their Command Line Interface structures (and a few other items). Arista posted a couple early responses (from the Legal Counsel and the CTO), and I'm curious to see where it goes, and what effect it may have on the decade-old networking company. But, part of the argument begs the question about whether you can protect your Command Line Interface syntax. Are some command lines intuitive (after decades of predecessors...), and are some "common" enough that they become open to the public domain? Would the market benefit if a vendor could lock-in a particular set of commands, while competitors had to find unique ways to configure the same settings?
It harkens me back to the days of the big re-write of the Point-to-Point (PPP) protocols in the IETF Request For Comments... there were only three RFCs then, and there was confusion among the companies trying to write compatible versions. Many companies (Microsoft, Novell, Telebit, Morningstar) were trying to work on vendor-specific adaptations, and some were trying to find a way to aggregate multiple modem links into one larger pipe. The rewrite moved us into 13 different, new RFCs, but they helped lay the groundwork for interoperability. The PPP Consortium grew monthly, as more vendors jumped aboard to make things work together. And many command strings started to look alike. A LOT alike! And, at the time, that seemed like a very good thing, since I didn't have to reference many manuals to get a link running.
So, today, I'm wondering what the downside is, if different network vendors can parse the same command line string to provision VLAN or Spanning Tree settings for a switchport. And what may happen in the Console Server world if a ruling comes out that vendors must have unique command line syntaxes. How many syntaxes would you want to support, or remember?
Happy New Year! I can hardly wait to see what's ahead.
20140101
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.
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.
Subscribe to:
Posts (Atom)