My main requirements would be: 1. Something that is *not* network (ethernet or otherwise) (isn't that the point of OOB?) 2. Something that is standard across everything, and can be aggregated easily onto a "console server" or the like I don't really see what is wrong with with keeping the serial port as the standard. Things like servers and RAID cards and such are coming with "BIOS"es that are graphical and even require a mouse to use. What use is that when I need to get into the BIOS from a remote site that is completely down? Likewise OS vendors are increasingly dropping support for installing OSes via serial port (RHEL, VMWare, etc.) At leaset with RHEL, you can make your own boot image that gets rid of the asinine splash screen (which is the only thing that causes the requirement for a full VGA console) It might be nice to have a "management-only" port of some sort to do more advanced things that serial cannot do, but the serial port is ubiquitous already, and I don't see any reason to remove it as the very low-level access method. thanks, -Randy ----- Original Message -----
I have together with some other people, collected a wish list for OOB support, mainly aimed for core routers. This is to replace the legacy serial port usually present on core routing equipment and to move/collapse all its functionality to an ethernet only port. Some equipment already have an mgmt ethernet port, but usually this can't do "everything", meaning today one has to have OOB ethernet *and* OOB serial which just brings more pain than before.
I would like to post it here to solicit feedback on it. Feel free to use it to tell your vendor account teams you want this if you feel it useful. I've already sent it to one vendor.
Priorities:
[P1] -> must have, otherwise not useful [P2] -> would be very useful, to most operators [P3] -> nice to have, useful to some
From the OOB ethernet port it should be possible to:
[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).
[P1]: Connect to manage the RP(s) and linecards (equivalent of todays "connect" on GSR and ASR9k or connecting to RP serial port).
[P2]: It should be possible to connect to the OOB from the RP as well (to diagnose OOB connectivity problems).
[P2]: Upload software to the RP or otherwise make information available to the RP (for later re-install/turboboot for example). RP should have access to local storage on the OOB device to transfer configuration or software from the OOB device to the RP).
[P2]: Read logs and other state of the components in the chassis (displays and LEDs) plus what kind of card is in each slot.
[P1]: The OOB port should support (configurable), telnet, ssh and optionally [P3] https login (with a java applet or equivalent to give CLI access in the browser) with ACLs to limit wherefrom things can be done. OOB should support ssh key based logins to admin account.
[P1]: The IP address of the OOB port should be set via DHCP/DHCPv6/SLAAC and should have both IPv4 and IPv6 support. If not both, then IPv6 only.
[P1]: It should be possible to transfer data using tftp, ftp and scp (ftp client on the OOB device, scp being used to transfer data *to* the device (OOB being scp server).
[P2]: OOB device should have tacacs and radius and [P1] local user/password database support for authentication. [P3] OOB should support ssh-key based authentication.
[P3] Chassis should have a character display or LEDs with configurable blink pattern from OOB, to aid remote hands identification.
[P3] OOB should have two USB ports, one to use to insert storage to transfer files to/from device. The other should be USB port that presents itself as ether USB serial port, or USB ethernet port, where the OOB device would have built in DHCP/DHCPv6 server to give IPv4v6 access to a laptop connected to the OOB so the onsite engineer can then use ssh/telnet to administrate the OOB. Optionally this port could be ethernet port (compare todays CON and AUX ports).
[P2] OOB should have procedure to factory default its configuration, perhaps physical button that can be pressed and held for duration of time. The fact that this is done should be logged to the RP.
[P3] OOB should have possibility to show power supply and environmental state.
[P3] The factory default configuration should not include an empty or obvious login password. The factory-default login password should be the MAC address (without punctuation) of the OOB ethernet interface, which should be printed on the chassis next to the OOBE port.
-- Mikael Abrahamsson email: swmike@swm.pp.se