[159349] in North American Network Operators' Group
Re: OOB core router connectivity wish list
daemon@ATHENA.MIT.EDU (Leo Bicknell)
Wed Jan 9 13:18:45 2013
Date: Wed, 9 Jan 2013 10:18:22 -0800
From: Leo Bicknell <bicknell@ufp.org>
To: Mikael Abrahamsson <swmike@swm.pp.se>
Mail-Followup-To: Mikael Abrahamsson <swmike@swm.pp.se>, nanog@nanog.org
In-Reply-To: <alpine.DEB.2.00.1301091831360.26235@uplift.swm.pp.se>
Cc: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
--Kj7319i9nmIyA2yE
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
In a message written on Wed, Jan 09, 2013 at 06:39:28PM +0100, Mikael Abrah=
amsson wrote:
> IPMI is exactly what we're going for.
For Vendors that use a "PC" motherboard, IPMI would probably not be
difficult at all! :)
I think IPMI is a pretty terrible solution though, so if that's your
target I do think it's a step backwards. Most IPMI cards are prime
examples of my worries, Linux images years out of date, riddled with
security holes and universally not trusted. You're going to need a
"firewall" in front of any such solution to deploy it, so you can't
really eliminate the extra box I proposed just change its nature.
I also still think there's a lot of potential here to take gigantic
steps backwards. Replacing a serial console with a Java applet in
a browser (a la most IPMI devices) would be a huge step backwards.
Today it's trival to script console access, in a Java applet world,
not so much.
Having a IPMI like device with dedicated ethernet and connection to the
management bus would allow it to have a web interface to do things like
power cycle individual line cards and may be a win, but I would posit
these things are to work around horribly broken upgrade procedures that
vendors have not given enough thought. They could be solved with more
intelligent software in the ROM and on the main box without needing any
add on device.
> So I want to retire serial ports in the front to be needed for normal=20
> operation. Look at the XR devices from Cisco for instance. For "normal=20
> maintenance" you pretty much require both serial console (to do rommon=20
> stuff one would imagine shouldn't be needed) and also mgmt ethernet (to=
=20
> use tftp for downloading software when you need to turbo-boot because the=
=20
> system is now screwed up because the XR developer ("install") team messed=
=20
> up the SMUs *again*).
Your vendor is going to hire those same developers to write the code for
your OOB device. The solution here is not bad developers writing and
deploying even more code, it's to demand your vendors uplevel their
developers and software.
Ever have these problems on Vendor J? No, the upgrade process there is
smooth as silk. Not to say that vendor is perfect, they just have
different warts.
--=20
Leo Bicknell - bicknell@ufp.org - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/
--Kj7319i9nmIyA2yE
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (FreeBSD)
iQIVAwUBUO20brN3O8aJIdTMAQKDJw/+MXiDGOwc4kRP9JURV4qLPlP3YFe50tqs
8PxO1mC0uxrxdJ3eBGWuglhcyWCqdP6sND88Rtyj/pG4ozy/k32T5NlbAQ2J0Fr8
dg1gwIkEKt/FxFjhr6Dd9dtYTJZfcRkRQUgXzD5NIFkIfXs35bBNkSsOmjaaf5cJ
ZnJLuJfupmLlIuqOF2+Gx0fuVYg3baOp6tSBb3ntBZuw/jWCpKyHwRp870LMYHRd
s3faneRy1YlRSnzlwJa+gNWoFTQQ1p2BA9ozyPgtjioyuaLTFHR9qo169zywHus/
HIpU8BEgKI6ispyVzk8tvEm8Mn3Ch+zjp5l82/0h0F63XvwS7zBT/4ZVEAfrRKv4
mB0EFtdPJ/X8ydY8hDS7wLXQeDn7eKmgddgDg1iGRyB9dCC2L1sgBXGpbP0zb3PH
yjJZyL1Je/w3fW0+Tl0ErOjaUuHGHQuXNmMuJ33jlX/vlpfduMd3TVseZtEm8LB5
2D1RsI3Z8lMflZw8nNxOp10Wl6/Qy7XSKpJN3tajpRoKEX3JSD8r9d7DRnWq5vRR
BqKMJE0aqKutswkVQoHg77jWHnpL8X+DAQR/KVUpNoNFx0VTizvRw0cCMilyAXi3
SZX+YHwt7EC1AH4iaiFM8IlCO74+nhF3iRGtzAEHyaLKrlgdC/2zNUyh44Am7DST
QsckaeNKjaM=
=45R2
-----END PGP SIGNATURE-----
--Kj7319i9nmIyA2yE--
