Skip to content
Log in Sign up My account

Choosing a console server for the data center

This article explains why a data center needs out-of-band console access, how to size and cable a console server, and which features matter when you compare products. It covers RJ45 pinouts, USB console, cellular failover, dual power and dual network, SSH and AAA hardening, automation APIs, a vendor-neutral comparison of product categories, and a design for the out-of-band network that the console server sits on. It names no products and quotes no prices.

Why out-of-band console access

In-band management uses the same network you are trying to fix. When a bad ACL, a broken routing change, a full disk or a crashed management plane takes a device off the network, SSH goes with it. A console connection does not depend on the data plane, the management VRF or the device's IP configuration at all. It works at these moments:

  • Initial provisioning and ZTP failures, before the device has an address.
  • ROMMON or boot loader recovery, password recovery, and failed upgrades where the device never finishes booting.
  • Configuration mistakes that cut your own session, including a bad copy to running-config or a wrong management ACL.
  • Total loss of the production WAN, when the only way in is a separate path.

A console server (also called a serial console server or terminal server) gives you network access to many serial ports from one box. Your engineers SSH to the console server, pick a port, and get the device console. The console server in turn needs its own path that does not depend on production. That is the out-of-band (OOB) network.

Tip

Test the OOB path while production is healthy and again during change windows. An untested console server is a guess, not a recovery plan.

Port counts and sizing

Count what actually needs a console: core and border routers, every leaf and top-of-rack switch, firewalls and load balancers, and sometimes PDUs and UPS units. Server BMCs usually use the BMC network instead of serial.

Common sizes are 8, 16, 32 and 48 ports per unit. Leave spare ports, because racks fill up. Per-rack units keep serial runs short, which matters for RS-232 over RJ45 at any speed, and limit the blast radius of one failure. A central unit is easier to manage but needs long cable runs and patch panels.

Each rack unit then needs a link back to the OOB network, so a per-rack design trades serial cabling for more Ethernet and more devices to manage and patch.

Pinouts: rolled versus straight RJ45

This is where most first deployments go wrong. Serial ports on console servers use RJ45 connectors, but vendors wire the pins differently, and device consoles are not all wired the same way either.

  • Cisco's traditional console cable is a flat light-blue rolled cable. Pin 1 on one end connects to pin 8 on the other, pin 2 to pin 7, and so on. It was designed for a PC with a DB9 adapter on one end and the device's RJ45 console on the other.
  • Some console servers present a port that expects a straight-through (non-rolled) Ethernet-style cable to a device with a Cisco-style console port. Others use a port pinout that needs a rolled cable. Which one applies depends on the vendor and sometimes on the model.
  • Some vendors sell an adapter or let you choose a pinout in software or with a physical jumper, so the same unit can work with the Cisco console wiring or with another convention.

The practical rule is to read the vendor's pinout documentation for both the console server and the managed device before ordering cables. Do not assume either.

Warning

Do not use a rolled cable and a straight cable in series without knowing what each does. Two rolled cables joined by a coupler give you a straight-through path. Label every cable and adapter with its type so the next engineer does not have to guess.

Settings that work for most Cisco-style consoles are 9600 baud, 8N1, no flow control. Check the device, because some platforms default to a higher speed, and newer platforms can be set to 115200. Make the console server's per-port settings match, and keep them in your source of truth so a port reset does not leave you guessing.

USB console support

Many current switches, routers and firewalls have a USB console port (mini-USB, micro-USB or USB-C depending on the model) in addition to, or instead of, RJ45. Points to check:

  • Does the console server have USB-A ports that present a USB serial device, and does it support the chip or class that the managed device uses? Most modern devices use a standard USB CDC ACM device or a common USB-serial chip, but confirm.
  • Some devices disable the RJ45 console when a USB console cable is connected, or the reverse. Know which wins on your platforms.
  • USB ports can be fewer than serial ports on a console server. If most of your estate is USB-only, count USB ports as a separate requirement.

Cellular and LTE out-of-band

A console server that uses only your wired network shares fate with whatever you are protecting against. If the OOB network uplinks into the same ISP, the same building feed or the same router as production, a single failure can take out both. A cellular modem gives the console server an independent path.

What to look at:

  • Built-in modem versus a modem you attach. Built-in is neater. An attached external modem or router is easier to replace and to swap between carriers.
  • SIM and carrier support. Check which bands and which carriers the model supports in your region, and whether the SIM is a normal one or an embedded one.
  • Antenna placement. A console server in a metal rack in a basement may get no signal. External antennas on a cable are often required.
  • Failover behaviour. Can the unit bring the cellular link up automatically when the wired uplink fails, and can it do it without breaking its tunnels?
  • Remote access design. A cellular link usually sits behind carrier-grade NAT, so inbound connections are often not possible. Look for a unit that dials out to a central service or builds a VPN to your OOB hub, instead of expecting a public address.

Cellular is a backup path, not a design shortcut. It does not replace a proper wired OOB network, it covers the case where that network's own uplink has failed.

Power and network redundancy

A recovery device that goes down with the rack is no use. For data center use look for:

  • Dual power supplies or dual power inputs, fed from separate PDUs on separate circuits (A and B feeds).
  • Two network interfaces, so you can connect to two OOB switches. Check whether they can run active/backup, or can be used as separate management and data interfaces, and whether the unit supports LACP.
  • A reasonable boot time and configuration that survives power loss. After a site-wide power failure, the console server is the tool that shows you the rest of the site booting. It should come up first.

Where the console server cannot be dual-powered, consider two units in the same rack, each connected to different devices (for example, one for the A-side switches and one for the B-side).

Security: SSH only, AAA, logging, certificates

A console server gives direct access to the most privileged interface of every device it serves. Treat it as a high-value target.

Protocols. Disable Telnet, HTTP and any unencrypted service on the console server. Allow SSH to the unit and to the individual ports, and HTTPS for the web UI. Many units also support per-port access by TCP port number or by a user and port-name syntax over SSH. Whichever method you use, make sure it is authenticated and encrypted.

Authentication and AAA. Do not rely on local accounts for daily use. Use central authentication through TACACS+ or RADIUS, or LDAP or SAML where the unit supports it, and keep one local break-glass account with a long, stored password and key. Authorization matters as much as authentication. Limit which groups can reach which ports, and who can get a read-write session versus a read-only view. Use SSH keys for engineers and for automation accounts, and disable password login where you can.

Break-glass. Decide what happens when the AAA server is unreachable, since you use the console server when things are broken. Keep a logged local fallback.

Logging. Look for these capabilities:

  • Session logging that records who connected to which port and when.
  • Optional capture of the actual console data stream, which gives you a record of what was typed and what the device returned. This is useful for audit and for post-incident review. It can also capture passwords typed at a prompt, so protect the logs and limit access to them.
  • Forwarding of events to a remote syslog server over a protected path, not only local storage on a flash device.
  • A buffer of console output kept on the unit even when nobody is connected, so you can see what a device printed before it crashed.

Certificates and keys. Replace the factory self-signed certificate on the web UI and API with one from your internal CA, so that engineers do not learn to click through warnings. Check how certificates are installed and renewed, whether the unit supports automated enrolment, and whether it validates certificates when it talks to AAA, syslog and management services over TLS. Rotate and record SSH host keys, and put them in your known-hosts distribution so that a changed host key means something.

Hardening basics. Put the management interface in a dedicated OOB VLAN or VRF behind an ACL, change default credentials before cabling anything, keep firmware current, use SNMPv3 if you need SNMP at all, and back up the console server configuration with your other device configs.

Management and automation APIs

A console server with 48 ports and per-port settings is painful to manage by hand. Look for:

  • A REST API or other documented programmatic interface for configuration, port status and user management.
  • A CLI that can be scripted, and a way to apply a full configuration from a file or template.
  • Support for zero-touch provisioning, so a replacement unit pulls its configuration when it first connects.
  • Integration with your inventory or source of truth. If you already use NetBox or Nautobot (see IPAM and Source-of-Truth Tools), keep the port-to-device map there and generate the console server configuration from it.
  • Central management for fleets of units, either as a vendor service or as software you run yourself. Compare the features of the central tool honestly, because some depend on a cloud service and others run on your own server.
  • Scripted console access. The ability to open a port from an automation tool is valuable for jobs such as staging a new switch. Many units can expose a port as a plain TCP socket or through SSH, which tools such as Netmiko can use as a transport for devices that have no IP address yet.

Tip

If you cannot automate it, you will not keep it correct. A console server whose port labels do not match the rack is worse than none, because engineers trust it.

Product categories compared

The table compares categories, not products. Individual products vary, so check each datasheet.

Category Typical ports Strengths Weaknesses Fits
Dedicated data center console server 8 to 96 serial, some USB Purpose built, dual power, dual NIC, AAA, logging, APIs Cost, another device to manage Most data centers
Console server with built-in cellular 8 to 48 Independent failover path, one box Antenna and signal issues, carrier management Remote sites, edge and colo cages
Compact or branch console server 1 to 8 Small, widely deployable Few ports, often single power Branch, remote cabinets
Legacy terminal server (router with async lines) 8 to 32 via modules Possibly already owned, familiar CLI Weaker security, old hardware, no real APIs Labs and small shops
Software or DIY (Linux host with USB serial adapters, ser2net or conserver) Whatever you add Open source, flexible You own reliability, power, security and support Labs, small shops

For a lab or small shop, a Linux host with USB serial adapters running ser2net or conserver is a legitimate approach. For a production data center you want the redundancy, security features and support of a purpose-built unit.

The configuration format of ser2net changed between major versions, so use the documentation for the version you install.

Designing the OOB network

The console server is only as good as the network it hangs from. The OOB network should be a separate failure domain from production.

graph TB
    ENG["Engineers and automation"] --> JUMP["Bastion or jump host"]
    JUMP --> OOBCORE["OOB core switch pair"]
    OOBCORE --> FW["OOB firewall"]
    FW --> ISP1["Wired uplink: separate ISP or carrier"]
    FW --> LTE["Cellular uplink"]
    OOBCORE --> OOBSW1["OOB access switch, rack A"]
    OOBCORE --> OOBSW2["OOB access switch, rack B"]
    OOBSW1 --> CS1["Console server, rack A"]
    OOBSW2 --> CS2["Console server, rack B"]
    CS1 --> D1["Leaf switch consoles"]
    CS2 --> D2["Spine and firewall consoles"]
    OOBSW1 --> MGMT["Device mgmt ports, BMCs, PDUs"]

Design rules that hold up in practice:

  1. Separate physical infrastructure. Dedicated OOB switches, not VLANs on production switches. A VLAN on a production switch fails with that switch.
  2. Separate power where possible. OOB switches and console servers on UPS-backed circuits, with A and B feeds.
  3. Independent uplinks. A wired uplink on a different provider or path from production, plus cellular for the last resort. Do not let the OOB firewall depend on production DNS, NTP, AAA or routing.
  4. Dedicated addressing and VRF. Give the OOB network its own address block, kept in your IPAM. On devices, put the management port in a management VRF so that a production routing problem does not affect it.
  5. Local services. Put a small set of critical services inside the OOB network or reachable from it by a path that does not cross production: NTP, syslog, AAA (or a replica), and a place to hold config backups and images.
  6. Controlled access. Engineers reach the OOB network through a bastion with MFA, and not directly from the corporate LAN. Restrict which sources can reach the console server.
  7. Keep it simple. Static or simple routing with few moving parts.
  8. Document and test. Keep a port map in your source of truth, label both ends of every cable, and run a regular test where you connect to a lab device through the cellular path with production routing disabled.

On the managed device, connect the dedicated management Ethernet port to the OOB switch and the serial console to the console server. Use both. The management port gives you a fast SSH session for normal work, and the serial console covers failures that take that port down.

On the device, put the management Ethernet port in a management VRF, and configure line con 0 with an exec-timeout and a login authentication list.

Warning

Console authentication that depends on a remote AAA server can lock you out when the network is down. Configure a local fallback method on the line con 0 authentication list, so that the console is usable when TACACS+ or RADIUS is unreachable.

References