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 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... -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/