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
