OOB core router connectivity wish list

[Mikael Abrahamsson <swmike () swm pp se>]

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.

http://swm.pp.se/oob.txt

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