Router Expert: Cisco asynchronous serial support

Asynchronous serial port types

Cisco IOS-based routers support three asynchronous serial interface types. Most administrators are already familiar with the first two. The "Console" port is a RS-232 variation, oriented toward direct DTE-to-DTE asynchronous communications. The Console port provides hardware level access to the configuration CLI and event reporting. The Console port is available on all router and switch models. The "Auxiliary" port, on the other hand, is available on router models 17x0 and higher. The Aux port provides a RS-232 compliant DTE presentation that can support a modem or equivalent terminal device.

In addition to fixed management and access serial ports, Cisco also supports fixed and modular asynchronous port solutions for providing DTE-to-DTE and DTE-to-DCE serial connections. The Cisco 2511 provides 16 fixed asynchronous ports. Asynchronous port network modules are also available for the Cisco 2600, 3600 and 3700 series platforms. There are two module flavors: the NM-16A, providing 16 async ports, and the NM-32A, which provides 32 async ports. Here is an illustration of the NM-16A card:

Both the fixed and modular asynchronous implementations utilize a 68-pin to RJ-45M breakout cable, Cisco product name CAB-OCTAL-ASYNC. This illustration represents the cable:

Two CAB-OCTAL cables are needed for the NM-16A; four are needed for the NM-32A. Each of the asynchronous ports on the NM-16A and NM-32A is wired as a DTE interface. The CAB-OCTAL is wired to provide DTE-to-DTE connections, with each breakout tail provisioned as a RJ-45M "rolled" or null-modem cable. In order for communications between two DTE devices to take place, the signal lines must be crossed, i.e. TX to RX, RTS to CTS, etc. In DB-9 and DB-25 scenarios, this is handled using an external null-modem adapter. The rolled cable in a RJ-45 implementation accomplishes the same thing without an added adapter, translating pin 1 on the router side of the cable to pin 8 on the terminal side of the cable. Here are the pin conversions for the rolled cable:

In most cases, when using a port on the NM-16A or NM-32A to communicate with a Cisco router's Console or Aux, the cable can be directly connected to the port. If necessary, it can also be extended with a standard RJ-45 straight-through cable. However, when connecting to a DCE device such as a modem or Cisco 7200 router, a DB-25M or DB-25F adapter is required. These adapters ship with every Cisco router and switch.

A DTE-to-DCE connection is a "bridge" connection -- the DTE and DCE work as a couple to exchange data with a remote DTE/DCE pair over the public network -- so the CAB-OCTAL's rolled cable needs to be reversed to a straight-through cable. This conversion is handled using the DB-25M adapter labeled "MODEM." The other DB-25F adapter, labeled "TERMINAL," turns a straight-through cable into a rolled cable. The "TERMINAL" adapter is also provided with DB-9F to provide the null-modem connection needed between a PC and the router when you want to talk to the router's Console port.

Now that we have looked at the different serial port flavors, let's review the operational differences between the three.

The Console port

The Cisco Console port comes in both an RJ-45F and DB-25F presentation. Operationally, the port is wired toward direct "live feed" DTE-to-DTE async communications. The console port's default configuration is:

• 9600 baud
• 8 data bits
• No parity
• 2 or 1 stop bits (depending on model)

The Console's default 9600-baud rate is, incidentally, also the port's maximum baud rate. The Console port does not have a corresponding TTY async interface, so the port cannot be configured as part of a DDR configuration. This makes the Console port's usefulness for any dial-in/dial-out function quite limited in terms of function and performance. However, it's not these limitations that make Console the port a pain to work with. It is the console port's hardware personality oriented toward live-feed operation that creates the headaches.

In a live-feed scenario, the data connection is always up and sending data. Typical examples of these kinds of serial connection are Teletype feeds and alarm system feeds. The idea is to transmit the data as close to real time as possible. In one-way feeds like teletypes, where there is no interaction, there is little need for buffering and line control. The Cisco console port has been wired toward this type of operation with DTE-to-DTE direct-connect implementation. As such, it has been implemented rather simplistically without the following RS-232 handshaking functionality:

• Data set ready (DSR): The DSR signal is always high, so the Console port behaves as if the connection is always up. The upstream DTE sees this DSR signal on its DTR pin and believes that a DCE (modem) connection is up. This condition results in the failure to terminate a modem connection when an EXEC session is terminated, leaving the modem connection up even after the session is over. This has advantages and disadvantages. The advantage is that as long as the device is powered, a modem connection will remain up, allowing you to be able to reload the router and not lose your connection. The disadvantage is that the modem connection needs to be manually disconnected, and in some cases the DCE port will become hung, requiring the modem to be reset. This problem also comes up when using async ports to access a router's Console port. Connections to the async port attached to the Console port will error out, requiring the async line to be reset (sometimes multiple times) before a connection will go through.
• Request to send (RTS): The Console port is always actively transmitting data. The data is transmitted live with no buffer. The port does not support hardware flow control. This can cause the async line or modem to hang. In the event the router starts to generate an excessive number of system or debug messages, the buffer on the DCE or DTE is overflowed, requiring a hard reset.
• Clear to send (CTS): The Console port will not receive any hardware flow control signals from the upstream DTE. This can result in the upstream device having its terminal buffer overrun with data sent from the router. Software flow-control can be implemented, but is not recommended.
• Data carrier detect (DCD): The Console port always assumes the presence of an active DCE connection. Since no DCD support exists, the Console port is unaware when a DTE session terminates. This can result in the console port remaining in its previous state when a modem connection or DTE terminal session is unexpectedly disconnected and then re-established. This can be a major security hole. To counter this, it is essential that session and absolute session timers are set and that the DCE or DTE connecting device supports its own security.
• Data terminal ready (DTR): The Console port receives a DTR signal from the upstream terminal device. It does not, however, respond if the signal is lost. It will continue to transmit data regardless of whether a device is terminated. This again creates the potential for a buffer overflows, requiring a port or device reset.

The following table maps the signal and pin breakdown provided by the rolled cable between the Console port and the upstream DTE device. Only DTR and DSR are provided -- just enough handshaking to establish a connection.

The lack of handshaking and resulting instability makes connecting a modem or a terminal server async port to the Console port less then ideal. However, as the only low-level access channel for monitoring IOS upgrades and password recovery, it is really the only useful option for OOB access.

Asynchronous lines

The Aux and NM-16/32a ports are true asynchronous serial lines. These ports come in two interface presentations: RJ-45F DTE (Aux and NM-16/32a) and DB-25M DTE (Aux only). The default line configuration is the same as the Console port, 9600-8-N-1 or 2. But, unlike the Console port, the Aux and NM-16/32a ports can support much higher baud rates. The Aux port is capable of supporting transmission rates up to 38400 baud. The NM-16/32a is capable of rates up to 115200 baud. Both ports also provide support for core RS-232 handshaking signaling (RTS, DSR, CTS and DTR). This table shows the signal and pin assignments for the Aux and NM-16/32a ports (based on a rolled cable).

The Aux and NM-16/32a ports' full support for RS-232 make them the preferable interface for providing modem access to the router. These ports, however, cannot provide the low-level hardware access to RMON and system boot messages that the Console port can. With these limitations in mind, this does not disqualify Aux ports from use in an OOB management capacity. But they are not suited for monitoring IOS upgrades, nor do they support password recovery.

That's Cisco asynchronous port support in a nutshell. This quick reference table lists port type and speed and availability by router model.

Next month we will finish our series on implementing an asynchronous serial line terminal server with terminal server configuration and support. So be sure to tune in.