Re: OOB core router connectivity wish list

[Randy Carpenter <rcarpen () network1 net>]

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.
>
> 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