Console Server Recommendation

Owen DeLong owen at
Wed Feb 1 17:07:42 UTC 2012

On Jan 31, 2012, at 11:32 PM, Saku Ytti wrote:

> On (2012-01-31 11:09 -0800), Owen DeLong wrote:
>>> - 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'?
> Home-baked systems are certainly good option to many, but for some of us it
> means we need to either hire worker to design, acquire, build and support
> them or consultant. And as you can find devices which support above
> requirements (opengear) TCO for us is simply just lower to buy one ready.

I would hardly call conserver software a home-baked solution unless you'd
also call anything based on OSS a "home-baked solution".

You'd have to configure the tserv, ssh, and/or DNS in order to achieve
ssh device.oob, and you have to configure the tserv and the conserver
software in order to achieve what I suggested.

> 'console device' is what we do today, which is script someone needs to
> maintain (it picks up from DNS TXT records OOB and port where to connect).

If you use the conserver software, console isn't a script someone needs to
maintain, it's the client portion of the conserver software package.

> I prefer giving each port an IP and just use it via ssh (at least cyclades
> and opengear do this), if you are brave you could even setup same IP
> address for console and on-band loop, but I found that to be suboptimal, as
> you sometimes want to connect to OOB even when on-band is working.

This takes away several of the other features from your list however, that are
implemented using the conserver software.

>> 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.
> You can get that from Nexus7k and Sup7. I wouldn't use the RS232 at all
> myself. Probably it's easier to sell this at day1 with RS232 port, as it is
> required in many RFPs and when everyone has migrated to ethernet OOB,
> phase-out RS232.
> So people please add to your 'nice to have' requirements in RFP, proper OOB
> :). (Can't tell how many times we've had to power-cycle CSCO or JNPR due to
> control-plane console not responding)

I've never seen a case where the control plane console failed to respond and I didn't
need to reboot the router to bring the control-plane back to life anyway. It's not like a
router can (usefully) continue for very long with a dead/locked-up control plane.

>> I will point out that the intel mobo OOB has not completely eliminated the need for
>> IPKVM in the datacenter. YMMV.
> This is bit drifting on the subject, but what are you missing specifically?
> You get VNC KVM, all the way from boot to bios, to GUI or CLI. You also get
> IDE redirection, to boot the remote box from your laptop CDROM. And you get
> API to automatically install factory fresh boxes without ever touching the
> boxes.

Only so long as the BIOS doesn't lose its mind which happens with some
unfortunate regularity. With a good IPKVM such as the Raritans, I get
everything you just described with the added advantage of still being able
to connect to a server when it's BIOS has lost its mind. As nice as those
devices sound, they still have some failure modes that stop short of being
my ideal OOB solution.


More information about the NANOG mailing list