OOB core router connectivity wish list

Wed Jan 9 17:54:13 UTC 2013

On 1/9/2013 9:12 AM, Leo Bicknell wrote:
> 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...

Install an Embedded Peer (a Bus Level Peering Card like a SlotServer or 
the Fuji Module and provide console level access through the peer. Then 
the Peer itself becomes the controller interface.

Todd
>
> 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
>     connectivity.
>
>     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
>     easily.
>
> 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]http://1.2.3.4/newimage.code 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...
>

-- 
Regards TSG
"Ex-Cruce-Leo"

//Confidential Mailing - Please destroy this if you are not the intended recipient.