On Feb 1, 2012, at 9:24 AM, Saku Ytti wrote:
> On (2012-02-01 09:07 -0800), Owen DeLong wrote:
>>> I would hardly call conserver software a home-baked solution unless you'd
>> also call anything based on OSS a "home-baked solution".
>> Home-baked, i.e. it's not product you can get shipped and it'll work out of
> the box and you have organization supporting it.
> The shipping solutions are really nothing else than embedded linux running
> conserver or equivalent, opengear even gives many of their oftware for
> free.
> It's certainly not difficult to roll one yourself, but for many of us, TCO
> is lot more than just buying opengear.
>
It's a product you can download, compile, configure and it works out of the box.
It is pretty well supported by the authors and they have been very responsive to
each and every question/feature/other request I have made to them, no matter
how stupid. In fact, it has been better supported in my experience than most
boxed software.
conserver doesn't replace the opengear products, it's a software package that
sits next to them and provides increased functionality of the type you suggested
would be desirable.
It's no more difficult to configure conserver than to set up the DNS to do what
you were suggesting with SSH.
>> This takes away several of the other features from your list however, that are
>> implemented using the conserver software.
>> The required list is satisfied by multiple offerings, including giving IP
> address to console port. So there are products in the market doing exactly
> what I want at cost which I'd be hard to reproduce even if I calculate my
> time as free.
>
I think you are misunderstanding and thinking I propose conserver as a
replacement for MRV/Cyclades/etc. I do not. I propose it as a way to get
most of the features you wanted that aren't present in those boxes by
adding it to them.
It has the additional advantage that it can provide the same functionality
transparently across a wide variety of tserv hardware so that you can
use multiple manufacturers over time and keep that transparent for the
most part.
>> 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.
>> Lot of people don't have way to remotely power cycle devices, if OOB is
> separate management-plane, you can power cycle control-plane remotely. It's
> probably <50USD BOM addition to list price, which server guys have enjoyed
> for over decade and Cisco has been trying to introduce to networking guys.
>
Agreed. Nonetheless, power cycling the box vs. power cycling the control plane
isn't a huge difference from my perspective.
>> 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
>> If you can access BIOS from console, you can access it via vPRO/AMT. If you
> run into more exotic problem, it's cheaper just to swap that 50<100usd
> motherboard than to investigate what happened.
>
Tell me that again when your device looses it's mind and the vPRO/AMT doesn't
come up with a workable IP address. RS-232 does NOT have this problem.
Owen