OOB core router connectivity wish list
tglassey at earthlink.net
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.
> 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]http://18.104.22.168/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...
//Confidential Mailing - Please destroy this if you are not the intended recipient.
More information about the NANOG