OOB core router connectivity wish list

Leo Bicknell bicknell at ufp.org
Wed Jan 9 17:12:25 UTC 2013

I think this list goes too far, and has a decent chance of introducing
other fun failure modes as a result.  The goal of OOB is generally
to gain control of a "misbehaving" device.  Now, misbehaving can
take many forms, from the device actually being ok and all of it's
circuits going down (fiber cut isolating it), to the device being
very much not ok with a bad linecard trying to lock up the bus,
core dumps, etc.

I'm going to pick on one specific example:

In a message written on Wed, Jan 09, 2013 at 03:37:16PM +0100, Mikael Abrahamsson wrote:
> [P1]: Powercycle the RP, switchfabrics and linecards (hard, as in they 
> might be totally dead and I want to cut power to it via the back plane. 
> Also useful for FPGA upgrades).

Most Cisco high end devices can do this today from the CLI (test
mbus power off on a GSR, for example).  Let's consider what it would
take to move that functionality from the live software to some sort
of "etherent oob" as proposed...

The first big step is that some sort of "computer" to operate the
ethernet oob is required.  I think where you're going with this is
some sort of small SoC type thing connected to the mangement buss
of the device, not unlike an IPMI device on a server.  Using IPMI
devices on servers as an example this is now another device that
must be secured, upgraded, and has the potential for bugs of its
own.  Since only a small fraction of high end users will use the
OOB at all (inband is fine for many, many networks), there will not
be a lot of testing of this code, or demand for features/fixes.

So while I agree with the list of features in large part, I'm not sure I
agree with the concept of having some sort of ethernet interface that
allows all of this out of band.  I think it will add cost, complexity,
and a lot of new failure modes.

The reality is the current situation on high end gear, a serial console
plus ethernet "management" port is pretty close to a good situation, and
could be a really good situation with a few minor modifications.  My
list would be much simpler as a result:

1) I would like to see serial consoles replaced with USB consoles.  They
   would still appear to be serial devices to most equipment, but would
   enable much faster speeds making working on the console a much more
   reasonable option.  For bonus points, an implementation that presents
   2-4 serial "terminals" over the same USB cable would allow multiple
   people to log into the device without the need for any network

   This would also allow USB hubs to be used to connect multiple devices
   in a colo, rather than the serial terminal servers needed today.

2) I would like to see "manangement" ethernets that live in their own
   walled off world out of the box.  Yes, I know with most boxes you can
   put them in a VRF or similar, but that should be the default.  I
   should be able to put an IP and default route on a management ethernet
   and still have a 100% empty (main) routing table.  This would allow
   the management port to be homed to a separate network simply and

3) I would like to see "legacy protocols" dumped.  TFTP, bye bye.  FTP,
   bye bye.  rcp, bye bye.  HTTP, HTTPS, and SCP should be supported
   for all operations at all levels of the OS.

In this ideal world, the deployment model is simple.  A small OOB
device would be deployed (think like a Cisco 1900, or Juniper SRX
220), connected to a separate network (DSL, cable modem, cell modem,
ethernet to some other provider, or gasp, even an old school analog
modem).  Each large router would get an ethernet port and usb console
to that device.  SSH to the right port would get the USB console,
ideally with the 2-4 consoles exposed where hitting the same port just
cycles through them.

At that point all of the functionality described in the original
post should be available in the normal CLI on the device.  File
transfer operations should be able to specify the management port
"copy [mangement] flash:" to use that
interface/routing table.

I also think on most boxes this would require no hardware changes.  The
high end boxes have Ethernet, they have USB...it's just updating the
software to make them act in a much more useful way, rather than the
half brain-dead ways they act now...

       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20130109/38eb2d34/attachment.sig>

More information about the NANOG mailing list