Console Server Recommendation
owen at delong.com
Tue Jan 31 13:09:39 CST 2012
On Jan 31, 2012, at 1:11 AM, Saku Ytti wrote:
> On (2012-01-30 11:08 -0500), Ray Soucy wrote:
>> What are people using for console servers these days? We've
>> historically used retired routers with ASYNC ports, but it's time for
>> an upgrade.
> This is very very common thread, replaying couple times a year in various
> lists, with to my cursory look no new information between iterations.
> I'd be more curious if people listed what do they think good console server
> should have, and if or not given model has them.
> For me, required features are
> - multiplexed connect to console port, console port should never, ever be busy,
> blocking. You don't want to find your most competent people blocked from
> accessing console, because 1st line is in lunch keeping the port busy.
+1 for conserver software as interface to existing terminal servers. It's a really
awesome package with very nice capabilities built by operations folks for
It provides this ability and much more.
> - console port output always buffered persistently (if devices crashes and
> burns, at least you have post-network-reachability logs puked in console
> stored, good for troubleshooting)
Conserver does this, too with the added advantage that the logs are stored
on an independent box not likely affected by whatever caused the crash.
> - IP address mappable to a console port. So that accessing device normally
> is 'ssh router' and via OOB 'ssh router.oob' no need to train people
How about normal is 'ssh device' and OOB is 'console device'?
Conserver does that.
> Nice to have
> - Configuration import/export as ascii, from single place, so configuration
> backups are easy
There are other tools that do this, such as rancid. I'm not sure I see significant advantage
to integrating it.
> - DC PSU support, redundantly
> - No moving parts
> - TACACS+ support
> - 3G support with IPSEC tunneling
> - Some clean and well designed webUI
These get more into the hardware actually connecting to the console port, so they
obviously aren't addressed by conserver. I believe that the MRV stuff has the first
three covered. The web UI, well, clean/well designed is in the eye of the beholder,
I suppose. I'm not overly impressed with any of the webUIs I've seen on any of these
The 3G with IPSEC is a nice thought. I haven't seen anyone do that yet.
> I also have to ask, why do we even need these? Why do we still get new gear
> with RS232 console only? Why only Cisco Nexus7k and SUP2T have seen the
> light? Dedicated management-plane separated from control-plane, so
> regardless of control-plane status, you can connect over ethernet to
> management-plane and copy images to control-plane, reset control-plane,
> check logs etc.
> Ethernet port is lot cheaper than RS232 port, so OOB gear would be cheaper.
I hink there are a few reasons.
First, for all its failings, RS-232 is dirt-simple and extremely reliable without any
configuration or external dependencies. Unless the box is a complete brick, the
RS-232 console port probably works, or, at least works once the box is power-
Ethernet, even ethernet on a dedicated management plane still depends on a
lot of things outside of the ethernet chip. It needs configuration (whether DHCP
or configuration file) and additional support hardware. Yes, much of this has
become cheaper than UART/driver chipsets, but, cheaper doesn't necessarily
mean more rock-solid reliable.
> RS232 console on control-plane is ridiculously useless, you cannot copy
> images over it (even if supported, images are several hundreds megabytes).
> It is completely dependant on control-plane working which is very poor
> requirement for OOB.
I agree that RS232 on a management plane would be a better choice. Personally,
I like the idea of having both RS232 and ethernet on dedicated management plane.
The RS232 allows you to deal with failures on the ethernet and the ethernet provides
support for image transfers, etc.
> When 50bucks intel desktop mobo has proper OOB, why does not every router
> and switch have?
I will point out that the intel mobo OOB has not completely eliminated the need for
IPKVM in the datacenter. YMMV.
More information about the NANOG