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