OOB core router connectivity wish list

Sat Jan 12 18:54:48 UTC 2013

On 1/10/13, Nick Hilliard <nick at foobar.org> wrote:
> On 10/01/2013 13:51, Jared Mauch wrote:

>  	- rs232: please no.  it's 2013.  I don't want or need a protocol which
> was designed for access speeds appropriate to the 1980s.
[snip]
Maybe stop with rs232 versus Ethernet, and implement _both_  as
separate OOB, instead of "one or the other".

The year on the calendar has little to do with the usefulness of
rs232, there has been no thorough replacement for every situation.

Rs232 also a simpler technology;  as in,  no likely way to
accidentally flow production traffic over rs232,  in case of security
breach or anything breaking SSH/Telnet processes, crypto mechanisms,
or SSH/Telnet login access;  where IP/Ethernet management network is
normally served by the same software processes as the Inband
management; Rs232 is what you'll most likely need for recovery,  for
most network devices it works from device bootup and provides useful
info before the OS is booted.   No IP address had to be assigned that
each managed device has to remember;  no config information to be lost
or mucked up by the unit when it dumps core, with corrupt Nvram;
usually the IP and routing configuration information for management
interfaces resides in the same place on the device as IP configuration
information for inband interfaces  on network devices.

  More likely to not break at the same time. Where your network
device's config got blown up,  or it will no longer boot, because of a
corrupt image.

Whereas, with RS232 you can potentially reconfig from scratch; if
necessary,  combine with remote power cycle capability, and a console
server that can handle sending Breaks and Xmodem uploads,  and it
provides more robust control of the hardware.

You will need some RS232 somewhere in those worst-case situations;
even, as the case may be -- you resort to the OOB management method of
a human bringing a computer to the network device, and plugging in a
RS232 cable   (Which is still OOB management, it's just not networked
OOB management).

Many devices log debugging output to console, and a good console
switch can log this.

So there are some reasons to ensure access to /both/ access avenues
on the OOB management network;   RS232 and Ethernet/IP    not mutually
exclusive.

--
-JH