[149309] in North American Network Operators' Group
Re: Console Server Recommendation
daemon@ATHENA.MIT.EDU (Owen DeLong)
Wed Feb 1 12:10:13 2012
From: Owen DeLong <owen@delong.com>
In-Reply-To: <20120201073200.GA23107@pob.ytti.fi>
Date: Wed, 1 Feb 2012 09:07:42 -0800
To: Saku Ytti <saku@ytti.fi>
Cc: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On Jan 31, 2012, at 11:32 PM, Saku Ytti wrote:
> On (2012-01-31 11:09 -0800), Owen DeLong wrote:
>=20
>>> - 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
>>=20
>> How about normal is 'ssh device' and OOB is 'console device'?
>=20
> 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.
>=20
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.
>=20
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.
>=20
> 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)
>=20
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.
>=20
> 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
