[159362] in North American Network Operators' Group
Re: OOB core router connectivity wish list
daemon@ATHENA.MIT.EDU (Warren Bailey)
Wed Jan 9 22:31:48 2013
From: Warren Bailey <wbailey@satelliteintelligencegroup.com>
To: "rcarpen@network1.net" <rcarpen@network1.net>, "swmike@swm.pp.se"
<swmike@swm.pp.se>
Date: Thu, 10 Jan 2013 03:16:36 +0000
In-Reply-To: <1400592755.31199.1357787111080.JavaMail.root@network1.net>
Cc: "nanog@nanog.org" <nanog@nanog.org>
Reply-To: Warren Bailey <wbailey@satelliteintelligencegroup.com>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
Uplogix has a pretty rad solution..
From my Galaxy Note II, please excuse any mistakes.
-------- Original message --------
From: Randy Carpenter <rcarpen@network1.net>
Date: 01/09/2013 7:07 PM (GMT-08:00)
To: Mikael Abrahamsson <swmike@swm.pp.se>
Cc: nanog@nanog.org
Subject: Re: OOB core router connectivity wish list
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 easi=
ly onto a "console server" or the like
I don't really see what is wrong with with keeping the serial port as the s=
tandard.
Things like servers and RAID cards and such are coming with "BIOS"es that a=
re 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 v=
ia 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 a=
dvanced things that serial cannot do, but the serial port is ubiquitous alr=
eady, 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
>
>
>
