I'd strongly recommend to also have a serial console server around for oob.
Best pick in my opinion is the avocent/cyclades series.
They come in various variants with different amounts of serial ports.
connection is RJ45 (use the normal patch infrastructure (within lengths limits)
with a specific wired adapter for the device to manage.
IPMI, iLO and all these others help you well if it's a server - but with dead
switches, routers, appliances, ... it's wise to have serial console access over
ssh to the terminalserver.
and - just keep the "segregation of duty" in mind... in large installations,
server operators are mostly not happy providing accounts to use a serial port
on their server.
A dead switch is out of interest for a windoze admin - they just want you to
keep the SLAs.
Sad - but mostly true.
OOB depends... size of the team, devices to care of, ...
for smaller setups I fully agree to Jeroen's suggestions.
cheers, stay away from Delta and don't breed Epsilon ;-)
Ralph
- Am 29. Jul 2021 um 16:30 schrieb Jeroen Massar jer...@massar.ch:
> Of course OOB, depending on location and requirements various options:
>
> - IPMI built-in to many hosts (SuperMicro >X10 have Redfish and thus HTML5
> KVM)
> then you can always fix that host and continue from there if serial connected
> etc.
> - PCEngines APU ( [ https://pcengines.ch/apu2.htm |
> https://pcengines.ch/apu2.htm ] )
> connected over serial and/or ethernet for a nice management entry
> (APU6 with SPF [ https://ipng.ch/s/articles/2021/07/19/pcengines-apu6.html |
> https://ipng.ch/s/articles/2021/07/19/pcengines-apu6.html ] is coming!)
> - Michael Stapelberg's FreeTServ: [ https://freetserv.github.io/ |
> https://freetserv.github.io ]
> for serial lines
> - "the other host in the same rack" with ethernet + serial cross-connected
>
> Do note that OOB is only fully OOB if you can mess up prod completely and
> still
> reach your OOB devices, that means if a switch is involved in your IPMI setup,
> it should not be the main switch, but a separate one (so that one can kill the
> main one, and use the OOB to fix it again). That also means that you need
> separate connectivity (borrow an IP from a friendly ISP in the same rack) or
> use 4G/5G if available in the DC.
>
> If using 4G, remember that one can do a wireguard mesh OOB to a non-own VM
> somewhere for OOB too. Ensure that you have ACLs and static IPs to connect
> from
> them too. Tor is also a fine option for low-bandwidth access in more hostile
> networks, then people need to know the onion fingerprint to get to your SSH.
>
>
> In DCs you will also find opengear or airconsoles btw.
>
> As noted, depends on requirements, budget and many more things.
>
> Greets,
> Jeroen
>
>
>
>
> On 20210729, at 15:29, Félix Curinga < [ mailto:fe...@curinga.ch |
> fe...@curinga.ch ] > wrote:
>
> Hi all,
>
> I am starting a small project with a student of the Technical School in
> Lausanne
> ETML-ES (for his diplom work), it will end up as a mobile kit for remote
> staging.
> I would like to collect some experience from you folks, will be kept 100%
> anonymous.
> If you agree, can you drop me an email directly and answer these questions:
>
> - do you have Out-of-Band console management for your network equipment ?
> - if no : how do you manage your network equipment ?
> - if yes: which product (brand/model) ?
> - if yes: which interfaces on the equipment side ? (RJ45, USB, etc..)
>
> Thanks in advance.
> For the people providing answers: I will send you the survey result without
> company or people's names.
>
> Best regards
> --félix
>
> --
> Félix Curinga
> +41 79 446 38 11
>
>
>
> ___
> swinog mailing list
> [ mailto:swinog@lists.swinog.ch | swinog@lists.swinog.ch ]
> http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
>
>
>
> ___
> swinog mailing list
> swinog@lists.swinog.ch
> http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog