Console Server Recommendation

[owen at delong.com (Owen DeLong)]

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.

Owen