[c-nsp] Console connections

[Saku Ytti]

On Fri, 1 Feb 2019 at 01:55, Charles Sprickman via cisco-nsp
<cisco-nsp at puck.nether.net> wrote:

> Can’t say enough things about ConServer. The logging is awesome, multi-user is super-handy. It beats all of the software I’ve seen in proprietary terminal server hardware.

+1. Conserver is very very good, and your UX remains the same
regardless of your OOB hardware choice. And say automation tooling,
maybe zero-touch conf, can remain unchanged when you decide to change
OOB hardware.

For rest of the list, how conserver works is that you ask it to retain
persistent ssh to given ip+port and then offer multiplexed connection
to that by some word. We generate conserver configuration from
database, and use would be something like this

╰─ console r21.lab
console: ambiguous console abbreviation, `r21.lab'
choices are r21.labxtx01.us.bb_re1, r21.labxtx01.us.bb_re0, r21.labxtx02.us.bb


╰─ console r21.labxtx01.us.bb_re0
[Enter `^Ec?' for help]
[no, ytti at eng0.dllstx09.us.to.gin.ntt.net is attached]
[bumped ytti at eng0.dllstx09.us.to.gin.ntt.net]


r21.labxtx01.us.bb-re0 (ttyd0)

login:



(here ytti was already on console, so I bumped him off, so I can
continue working on the console).



Now you don't need anything from your console server, but ability to
offer console over IP+Port. It is very nice separation of concerns. We
also have script which logins every day to every console port, and
expects to see shell prompt, so that we actually know that the console
works, when we need it.



Now when it comes to OOB hardware CAPEX, in my world it doesn't matter
at all, when DC is asking 150USD/MRC for cross connnect, cost of OOB
hardware is just immaterial .So we opted to buy device which our
tooling supports, people are comfortable working with and can support
wide array of WAN options, doesn't have external PSU brick, can do
multipoint DMVPN/IPSEC call-home style, so we don't need to have
stable or known IP. To that effect, we chose Cisco4331.
We have four BGP sessions per Cisco4331, 2 per hub, and on-band +
out-of-band per hub. We prefer out-of-band connection, but will revert
back to on-band, which is useful if there are issues in 3rd party
non-fate-sharing 3rd party connection.


-- 
  ++ytti