What are folks using for serial consoles these days?
Hey there folks. Dayjob has historically used USB TTY pods attached to real BSD machines to talk to our cisco consoles, with the amazing benefit that with a program like Vixie's rtty (or conserver) you can also capture the output of those consoles in real-time, and perhaps use that data to identify a connected device. As a bonus, because the rackmount devices have real DE-9's on them, it means they work with any kind of cable you get (not just your standard rj45 cisco rollover like you might get with a Cyclades thing -- and you don't have to come up with the weird-ass mappings for rj45-serial like you might need like our ME4012 NAS (the serial cable is a stereo plug), our smart power strips (it's either a stereo plug, or an rj12), or something like an older brocade switch (it's a DE9, but it's friggin ODD, and I think it may also be the wrong gender). It also means, since you're running a real OS, you have patches as long as the OS is supported (so you're not stuck with "gee it only speaks rsa1024"), versus some EOL appliance. But it's also 2u, and since we're recently buying a lot of Dell hardware, that's Super Overkill for a dell, so I'm evaluating maybe just going "Appliance". If we stick with an existing unix box for this, I'd want something with proper IPMI/OOB (so Rpi is out) but maybe the dumbest, shallowest-depth atom64 supermicro you can find, in the event you need to do a reinstall or catch a hung system. Are there things that other folks are using that are "easy" to work with that you've found to have Long firmware lives, decent warranties and low hassle? Does anything these days actually have DE9s on it? -Dan (You may have also seen my note earlier about the Cisco ASR920, which has RS232 pins in a USB-A header. No, not via a PL2032 chip inside the host that provides a virtual serial...direct txd/rxd/gnd/cts etc, on the USB pins. I've seen things you people would't believe)
On 12/17/25 19:51, Dan Mahoney via NANOG wrote:
Hey there folks.
Dayjob has historically used USB TTY pods attached to real BSD machines to talk to our cisco consoles, with the amazing benefit that with a program like Vixie's rtty (or conserver) you can also capture the output of those consoles in real-time, and perhaps use that data to identify a connected device.
As a bonus, because the rackmount devices have real DE-9's on them, it means they work with any kind of cable you get (not just your standard rj45 cisco rollover like you might get with a Cyclades thing -- and you don't have to come up with the weird-ass mappings for rj45-serial like you might need like our ME4012 NAS (the serial cable is a stereo plug), our smart power strips (it's either a stereo plug, or an rj12), or something like an older brocade switch (it's a DE9, but it's friggin ODD, and I think it may also be the wrong gender).
It's the wrong gender. It's a DCE pinout on a male connector that's usually used for the DTE. IDK why they did that, and of course they never fixed it because we can't change that sort of thing. That's the only thing "wrong" with it. I know it all too well. You need a null modem cable or adapter AND a gender changer to get to it.
It also means, since you're running a real OS, you have patches as long as the OS is supported (so you're not stuck with "gee it only speaks rsa1024"), versus some EOL appliance. But it's also 2u, and since we're recently buying a lot of Dell hardware, that's Super Overkill for a dell, so I'm evaluating maybe just going "Appliance".
If we stick with an existing unix box for this, I'd want something with proper IPMI/OOB (so Rpi is out) but maybe the dumbest, shallowest-depth atom64 supermicro you can find, in the event you need to do a reinstall or catch a hung system.
A small Supermicro with a Xeon-D or Epyc 2005 series (which are probably still in the works; I have an older Epyc 3151 board that works great, though) is probably a decent option. Should be reasonably cheap; power can be kept to about 50-60W max; they do have IPMI BMC, and get can get a real PCI slot or two for "real" multi-serial cards. They readily fit in 1U. Something like this can also easily handle VPN access to your OOB Ethernet, take a USB-connected cheap LTE/5G modem, etc.
Are there things that other folks are using that are "easy" to work with that you've found to have Long firmware lives, decent warranties and low hassle? Does anything these days actually have DE9s on it?
Depending on the environment, an old Cisco router like a 28xx/29xx with either an NM-16A/32A or HWIC-8A/16A or SM-32A is a very viable option. They're EOL, and I'd not put them on a raw, unfiltered Internet connection, but they offer a lot of options for VPN access to your OOB network (an old ESW module is useful for this) along with the serial ports in a single box, and you'll pay more for the serial breakout cables than you will for the rest of the hardware. You can SSH to them and use whatever line you want, or you can map SSH ports (or telnet ports if you're that kind of person) to individual serial lines (or both). The SSH server...kinda sucks, though. It'll do RSA2048 key exchange (slowly), but the hash algorithms and DH groups it supports are archaic. The pinout on the serial cables is, of course, Cisco which, while not the EIA standard, is as you alluded to the most popular one, so it'll plug directly into most things that have an 8P8C for serial, and adapters to DE-9 are readily available as well. I can't say I'm a Cisco fan, but these old boxes, despite being well past their prime in terms of intended usage, are still quite useful in corners like this, and they're very cheap on the secondary market. There's no modern cellular radio module for them, though I've heard it's possible to get USB-connected ones to work on the 29xx series.
Once upon a time, Brandon Martin <lists.nanog@monmotha.net> said:
It's the wrong gender. It's a DCE pinout on a male connector that's usually used for the DTE. IDK why they did that, and of course they never fixed it because we can't change that sort of thing.
I remember a few such devices from before most everybody switched over to Cisco-ish 8P8C connectors. I think Ascend TNTs were backwards? And then there were some 8P8C that were backwards (IIRC some Adtran gear?), needing a rollover adapter to work with the typical Cisco-compatible cables. It'd be nice if network vendors could spend an extra couple of bucks to put a basic IPMI BMC on the management network interface, with serial over LAN and remote power cycle support. -- Chris Adams <cma@cmadams.net>
On Dec 17, 2025, at 6:51 PM, Dan Mahoney via NANOG <nanog@lists.nanog.org> wrote:
Are there things that other folks are using that are "easy" to work with that you've found to have Long firmware lives, decent warranties and low hassle? Does anything these days actually have DE9s on it?
I’m not sure if it meets your requirements for being supported by a vendor and all that, but the things that actually see the most use at my end of the wire are genuine terminals. Most recently I added a LA120 that has been repaired a few times by both its past owners and myself. I found a supplier that will sell me newly manufactured ribbon in bulk, and I can 3D print the ribbon spools. It’s running such a ribbon right now. The paper can still be ordered from office supply houses, the firmware is never going to get updated, the warranty is “can I still get TTL parts?”, and while it does not have a DE9 it does have a DB25. As long as the paper doesn’t run out the log is immutable, and I can tear it off and write notes on it if I want. Then carry it around and/or copy it and give the copies out as needed. To accomplish remote access, I have a passive RS-232 sharing device from Black Box that has one “master” port and several “terminal” ports. The receive data line from the “master” port is duplicated on the “terminal” ports and the transmit line from the terminal ports is logically or'd onto the master port. Thus I can hang two or three whatever-the-heck-I-wants in line with the LA120. Dirt simple - it doesn’t even have a power supply, it’s powered by the serial devices themselves - and allows for redundancy if the modern stuff attached to it fails to be as reliable as the LA120. This is kinda sad if you think about it because in its day the LA120 was not noted for its great longevity, and mine is almost as old as I am... While all this stuff is highly obsolete, there’s no reason stuff today shouldn’t be this painless. The Black Box device is trivial in design, you’d just have to make it DE9 instead of DB25 for modern stuff. There are several efforts to make an open-source printer with modern parts and it would be relatively simple to add a keyboard to one and obtain a terminal. The firmware should not have to do anything fancy that would make frequent updates a necessity. Keep it simple and keep it focused. If your terminals are as hard to maintain as a host, and have the same attack surface as a host, all you have gained is another host you have to manage, and that’s probably not your goal.
Dan I have stacks and stacks of serial console servers. Today I mostly use an https://www.coolgear.com/product/32-port-rs-232-usb-to-serial-adapter with some pictures of the guts at https://lathama.net/Tech/Hardware/USB-32COM-RM if interested. It is my solution to a quick build of an https://freetserv.github.io/ (I have seen some things) On Wed, Dec 17, 2025 at 5:51 PM Dan Mahoney via NANOG <nanog@lists.nanog.org> wrote:
Hey there folks.
Dayjob has historically used USB TTY pods attached to real BSD machines to talk to our cisco consoles, with the amazing benefit that with a program like Vixie's rtty (or conserver) you can also capture the output of those consoles in real-time, and perhaps use that data to identify a connected device.
As a bonus, because the rackmount devices have real DE-9's on them, it means they work with any kind of cable you get (not just your standard rj45 cisco rollover like you might get with a Cyclades thing -- and you don't have to come up with the weird-ass mappings for rj45-serial like you might need like our ME4012 NAS (the serial cable is a stereo plug), our smart power strips (it's either a stereo plug, or an rj12), or something like an older brocade switch (it's a DE9, but it's friggin ODD, and I think it may also be the wrong gender).
It also means, since you're running a real OS, you have patches as long as the OS is supported (so you're not stuck with "gee it only speaks rsa1024"), versus some EOL appliance. But it's also 2u, and since we're recently buying a lot of Dell hardware, that's Super Overkill for a dell, so I'm evaluating maybe just going "Appliance".
If we stick with an existing unix box for this, I'd want something with proper IPMI/OOB (so Rpi is out) but maybe the dumbest, shallowest-depth atom64 supermicro you can find, in the event you need to do a reinstall or catch a hung system.
Are there things that other folks are using that are "easy" to work with that you've found to have Long firmware lives, decent warranties and low hassle? Does anything these days actually have DE9s on it?
-Dan
(You may have also seen my note earlier about the Cisco ASR920, which has RS232 pins in a USB-A header. No, not via a PL2032 chip inside the host that provides a virtual serial...direct txd/rxd/gnd/cts etc, on the USB pins. I've seen things you people would't believe) _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/5VV3B6CV...
-- - Andrew "lathama" Latham -
Up until recently I was using the Raritan Dominion SX II models. Dual PSU, dual NIC, and configurations ranging from 4 to 48 ports. However, Raritan has just discontinued that as of June. It is unclear how long they will continue to provide security patches. They are recommending customers switch to the ZPE Systems Nodegrid Serial Consoles. It looks to be much the same, but I haven't had a chance to test one yet. The only difference I've noticed is the ZPE device seems to have an embedded 5G cellular module. On Thu, 18 Dec 2025 at 09:34, Andrew Latham via NANOG <nanog@lists.nanog.org> wrote:
Dan
I have stacks and stacks of serial console servers. Today I mostly use an https://www.coolgear.com/product/32-port-rs-232-usb-to-serial-adapter with some pictures of the guts at https://lathama.net/Tech/Hardware/USB-32COM-RM if interested. It is my solution to a quick build of an https://freetserv.github.io/
(I have seen some things)
On Wed, Dec 17, 2025 at 5:51 PM Dan Mahoney via NANOG <nanog@lists.nanog.org> wrote:
Hey there folks.
Dayjob has historically used USB TTY pods attached to real BSD machines
to talk to our cisco consoles, with the amazing benefit that with a program like Vixie's rtty (or conserver) you can also capture the output of those consoles in real-time, and perhaps use that data to identify a connected device.
As a bonus, because the rackmount devices have real DE-9's on them, it
means they work with any kind of cable you get (not just your standard rj45 cisco rollover like you might get with a Cyclades thing -- and you don't have to come up with the weird-ass mappings for rj45-serial like you might need like our ME4012 NAS (the serial cable is a stereo plug), our smart power strips (it's either a stereo plug, or an rj12), or something like an older brocade switch (it's a DE9, but it's friggin ODD, and I think it may also be the wrong gender).
It also means, since you're running a real OS, you have patches as long
as the OS is supported (so you're not stuck with "gee it only speaks rsa1024"), versus some EOL appliance. But it's also 2u, and since we're recently buying a lot of Dell hardware, that's Super Overkill for a dell, so I'm evaluating maybe just going "Appliance".
If we stick with an existing unix box for this, I'd want something with
proper IPMI/OOB (so Rpi is out) but maybe the dumbest, shallowest-depth atom64 supermicro you can find, in the event you need to do a reinstall or catch a hung system.
Are there things that other folks are using that are "easy" to work with
that you've found to have Long firmware lives, decent warranties and low hassle? Does anything these days actually have DE9s on it?
-Dan
(You may have also seen my note earlier about the Cisco ASR920, which
has RS232 pins in a USB-A header. No, not via a PL2032 chip inside the host that provides a virtual serial...direct txd/rxd/gnd/cts etc, on the USB pins. I've seen things you people would't believe)
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/5VV3B6CV...
-- - Andrew "lathama" Latham - _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/CPBVORP6...
Matt Some open software would really keep a lot of this stuff out of the trash. I have Cyclades and Lantronix stuff on a shelf that works. I got tired of maintaining a box-in-the-middle to deal with ssh ciphers. On Thu, Dec 18, 2025 at 7:43 AM Matt Brennan <brennanma@gmail.com> wrote:
Up until recently I was using the Raritan Dominion SX II models. Dual PSU, dual NIC, and configurations ranging from 4 to 48 ports. However, Raritan has just discontinued that as of June. It is unclear how long they will continue to provide security patches.
They are recommending customers switch to the ZPE Systems Nodegrid Serial Consoles. It looks to be much the same, but I haven't had a chance to test one yet. The only difference I've noticed is the ZPE device seems to have an embedded 5G cellular module.
On Thu, 18 Dec 2025 at 09:34, Andrew Latham via NANOG <nanog@lists.nanog.org> wrote:
Dan
I have stacks and stacks of serial console servers. Today I mostly use an https://www.coolgear.com/product/32-port-rs-232-usb-to-serial-adapter with some pictures of the guts at https://lathama.net/Tech/Hardware/USB-32COM-RM if interested. It is my solution to a quick build of an https://freetserv.github.io/
(I have seen some things)
On Wed, Dec 17, 2025 at 5:51 PM Dan Mahoney via NANOG <nanog@lists.nanog.org> wrote:
Hey there folks.
Dayjob has historically used USB TTY pods attached to real BSD machines to talk to our cisco consoles, with the amazing benefit that with a program like Vixie's rtty (or conserver) you can also capture the output of those consoles in real-time, and perhaps use that data to identify a connected device.
As a bonus, because the rackmount devices have real DE-9's on them, it means they work with any kind of cable you get (not just your standard rj45 cisco rollover like you might get with a Cyclades thing -- and you don't have to come up with the weird-ass mappings for rj45-serial like you might need like our ME4012 NAS (the serial cable is a stereo plug), our smart power strips (it's either a stereo plug, or an rj12), or something like an older brocade switch (it's a DE9, but it's friggin ODD, and I think it may also be the wrong gender).
It also means, since you're running a real OS, you have patches as long as the OS is supported (so you're not stuck with "gee it only speaks rsa1024"), versus some EOL appliance. But it's also 2u, and since we're recently buying a lot of Dell hardware, that's Super Overkill for a dell, so I'm evaluating maybe just going "Appliance".
If we stick with an existing unix box for this, I'd want something with proper IPMI/OOB (so Rpi is out) but maybe the dumbest, shallowest-depth atom64 supermicro you can find, in the event you need to do a reinstall or catch a hung system.
Are there things that other folks are using that are "easy" to work with that you've found to have Long firmware lives, decent warranties and low hassle? Does anything these days actually have DE9s on it?
-Dan
(You may have also seen my note earlier about the Cisco ASR920, which has RS232 pins in a USB-A header. No, not via a PL2032 chip inside the host that provides a virtual serial...direct txd/rxd/gnd/cts etc, on the USB pins. I've seen things you people would't believe) _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/5VV3B6CV...
-- - Andrew "lathama" Latham - _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/CPBVORP6...
-- - Andrew "lathama" Latham -
On 12/18/25 7:24 AM, Andrew Latham via NANOG wrote:
Matt
Some open software would really keep a lot of this stuff out of the trash. I have Cyclades and Lantronix stuff on a shelf that works. I got tired of maintaining a box-in-the-middle to deal with ssh ciphers.
Have cipher suites really changed that much in the last 20 years or so? After the sha1 kerfuffle and needing to up RSA key sizes, has there been much change? Or are you talking about some seriously old kit that predates that? Mike, out of the loop
On Thu, Dec 18, 2025 at 7:43 AM Matt Brennan <brennanma@gmail.com> wrote:
Up until recently I was using the Raritan Dominion SX II models. Dual PSU, dual NIC, and configurations ranging from 4 to 48 ports. However, Raritan has just discontinued that as of June. It is unclear how long they will continue to provide security patches.
They are recommending customers switch to the ZPE Systems Nodegrid Serial Consoles. It looks to be much the same, but I haven't had a chance to test one yet. The only difference I've noticed is the ZPE device seems to have an embedded 5G cellular module.
On Thu, 18 Dec 2025 at 09:34, Andrew Latham via NANOG <nanog@lists.nanog.org> wrote:
Dan
I have stacks and stacks of serial console servers. Today I mostly use an https://www.coolgear.com/product/32-port-rs-232-usb-to-serial-adapter with some pictures of the guts at https://lathama.net/Tech/Hardware/USB-32COM-RM if interested. It is my solution to a quick build of an https://freetserv.github.io/
(I have seen some things)
On Wed, Dec 17, 2025 at 5:51 PM Dan Mahoney via NANOG <nanog@lists.nanog.org> wrote:
Hey there folks.
Dayjob has historically used USB TTY pods attached to real BSD machines to talk to our cisco consoles, with the amazing benefit that with a program like Vixie's rtty (or conserver) you can also capture the output of those consoles in real-time, and perhaps use that data to identify a connected device.
As a bonus, because the rackmount devices have real DE-9's on them, it means they work with any kind of cable you get (not just your standard rj45 cisco rollover like you might get with a Cyclades thing -- and you don't have to come up with the weird-ass mappings for rj45-serial like you might need like our ME4012 NAS (the serial cable is a stereo plug), our smart power strips (it's either a stereo plug, or an rj12), or something like an older brocade switch (it's a DE9, but it's friggin ODD, and I think it may also be the wrong gender).
It also means, since you're running a real OS, you have patches as long as the OS is supported (so you're not stuck with "gee it only speaks rsa1024"), versus some EOL appliance. But it's also 2u, and since we're recently buying a lot of Dell hardware, that's Super Overkill for a dell, so I'm evaluating maybe just going "Appliance".
If we stick with an existing unix box for this, I'd want something with proper IPMI/OOB (so Rpi is out) but maybe the dumbest, shallowest-depth atom64 supermicro you can find, in the event you need to do a reinstall or catch a hung system.
Are there things that other folks are using that are "easy" to work with that you've found to have Long firmware lives, decent warranties and low hassle? Does anything these days actually have DE9s on it?
-Dan
(You may have also seen my note earlier about the Cisco ASR920, which has RS232 pins in a USB-A header. No, not via a PL2032 chip inside the host that provides a virtual serial...direct txd/rxd/gnd/cts etc, on the USB pins. I've seen things you people would't believe) _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/5VV3B6CV...
-- - Andrew "lathama" Latham - _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/CPBVORP6...
Mike Yes and Yes. I have some seriously old stuff and often corporate standards move forward faster that vendor updates. HTTPS - lack of updated CA data can cause issue when the user can not update the data. SSH - Some offers of legacy ciphers/algorithms can be flagged by security sweeps. I am sure I could go down a rabbit hole. There are devices that work but get flagged for how they work within tight controls. On Thu, Dec 18, 2025 at 2:05 PM Michael Thomas via NANOG <nanog@lists.nanog.org> wrote:
On 12/18/25 7:24 AM, Andrew Latham via NANOG wrote:
Matt
Some open software would really keep a lot of this stuff out of the trash. I have Cyclades and Lantronix stuff on a shelf that works. I got tired of maintaining a box-in-the-middle to deal with ssh ciphers.
Have cipher suites really changed that much in the last 20 years or so? After the sha1 kerfuffle and needing to up RSA key sizes, has there been much change?
Or are you talking about some seriously old kit that predates that?
Mike, out of the loop
On Thu, Dec 18, 2025 at 7:43 AM Matt Brennan <brennanma@gmail.com> wrote:
Up until recently I was using the Raritan Dominion SX II models. Dual PSU, dual NIC, and configurations ranging from 4 to 48 ports. However, Raritan has just discontinued that as of June. It is unclear how long they will continue to provide security patches.
They are recommending customers switch to the ZPE Systems Nodegrid Serial Consoles. It looks to be much the same, but I haven't had a chance to test one yet. The only difference I've noticed is the ZPE device seems to have an embedded 5G cellular module.
On Thu, 18 Dec 2025 at 09:34, Andrew Latham via NANOG <nanog@lists.nanog.org> wrote:
Dan
I have stacks and stacks of serial console servers. Today I mostly use an https://www.coolgear.com/product/32-port-rs-232-usb-to-serial-adapter with some pictures of the guts at https://lathama.net/Tech/Hardware/USB-32COM-RM if interested. It is my solution to a quick build of an https://freetserv.github.io/
(I have seen some things)
On Wed, Dec 17, 2025 at 5:51 PM Dan Mahoney via NANOG <nanog@lists.nanog.org> wrote:
Hey there folks.
Dayjob has historically used USB TTY pods attached to real BSD machines to talk to our cisco consoles, with the amazing benefit that with a program like Vixie's rtty (or conserver) you can also capture the output of those consoles in real-time, and perhaps use that data to identify a connected device.
As a bonus, because the rackmount devices have real DE-9's on them, it means they work with any kind of cable you get (not just your standard rj45 cisco rollover like you might get with a Cyclades thing -- and you don't have to come up with the weird-ass mappings for rj45-serial like you might need like our ME4012 NAS (the serial cable is a stereo plug), our smart power strips (it's either a stereo plug, or an rj12), or something like an older brocade switch (it's a DE9, but it's friggin ODD, and I think it may also be the wrong gender).
It also means, since you're running a real OS, you have patches as long as the OS is supported (so you're not stuck with "gee it only speaks rsa1024"), versus some EOL appliance. But it's also 2u, and since we're recently buying a lot of Dell hardware, that's Super Overkill for a dell, so I'm evaluating maybe just going "Appliance".
If we stick with an existing unix box for this, I'd want something with proper IPMI/OOB (so Rpi is out) but maybe the dumbest, shallowest-depth atom64 supermicro you can find, in the event you need to do a reinstall or catch a hung system.
Are there things that other folks are using that are "easy" to work with that you've found to have Long firmware lives, decent warranties and low hassle? Does anything these days actually have DE9s on it?
-Dan
(You may have also seen my note earlier about the Cisco ASR920, which has RS232 pins in a USB-A header. No, not via a PL2032 chip inside the host that provides a virtual serial...direct txd/rxd/gnd/cts etc, on the USB pins. I've seen things you people would't believe) _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/5VV3B6CV...
-- - Andrew "lathama" Latham - _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/CPBVORP6...
_______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/Z4SBTD3J...
-- - Andrew "lathama" Latham -
Largest vendor kit that only went EOL 2 years ago needs special config to allow DH algorithm that has been deprecated on the version of openssh in a MacOS that is older++ than the OS image on the kit What has changed in the last 20 years is cryptanalysis leading to feasible attacks in minutes with a decent GPU -oh and the whole post-quantum encryption stuff and tonnes of cryptography hotness running through cfrg Wouldn’t be a problem if security added shareholder value but stuff like fortinet/baracuda/salt typhoon has ably demonstrated that the market careth not so why should the vendors? /rant
On 18 Dec 2025, at 21:05, Michael Thomas via NANOG <nanog@lists.nanog.org> wrote:
On 12/18/25 7:24 AM, Andrew Latham via NANOG wrote: Matt
Some open software would really keep a lot of this stuff out of the trash. I have Cyclades and Lantronix stuff on a shelf that works. I got tired of maintaining a box-in-the-middle to deal with ssh ciphers.
Have cipher suites really changed that much in the last 20 years or so? After the sha1 kerfuffle and needing to up RSA key sizes, has there been much change?
Or are you talking about some seriously old kit that predates that?
Mike, out of the loop
On Thu, Dec 18, 2025 at 7:43 AM Matt Brennan <brennanma@gmail.com> wrote: Up until recently I was using the Raritan Dominion SX II models. Dual PSU, dual NIC, and configurations ranging from 4 to 48 ports. However, Raritan has just discontinued that as of June. It is unclear how long they will continue to provide security patches.
They are recommending customers switch to the ZPE Systems Nodegrid Serial Consoles. It looks to be much the same, but I haven't had a chance to test one yet. The only difference I've noticed is the ZPE device seems to have an embedded 5G cellular module.
On Thu, 18 Dec 2025 at 09:34, Andrew Latham via NANOG <nanog@lists.nanog.org> wrote:
Dan
I have stacks and stacks of serial console servers. Today I mostly use an https://www.coolgear.com/product/32-port-rs-232-usb-to-serial-adapter with some pictures of the guts at https://lathama.net/Tech/Hardware/USB-32COM-RM if interested. It is my solution to a quick build of an https://freetserv.github.io/
(I have seen some things)
On Wed, Dec 17, 2025 at 5:51 PM Dan Mahoney via NANOG <nanog@lists.nanog.org> wrote:
Hey there folks.
Dayjob has historically used USB TTY pods attached to real BSD machines to talk to our cisco consoles, with the amazing benefit that with a program like Vixie's rtty (or conserver) you can also capture the output of those consoles in real-time, and perhaps use that data to identify a connected device.
As a bonus, because the rackmount devices have real DE-9's on them, it means they work with any kind of cable you get (not just your standard rj45 cisco rollover like you might get with a Cyclades thing -- and you don't have to come up with the weird-ass mappings for rj45-serial like you might need like our ME4012 NAS (the serial cable is a stereo plug), our smart power strips (it's either a stereo plug, or an rj12), or something like an older brocade switch (it's a DE9, but it's friggin ODD, and I think it may also be the wrong gender).
It also means, since you're running a real OS, you have patches as long as the OS is supported (so you're not stuck with "gee it only speaks rsa1024"), versus some EOL appliance. But it's also 2u, and since we're recently buying a lot of Dell hardware, that's Super Overkill for a dell, so I'm evaluating maybe just going "Appliance".
If we stick with an existing unix box for this, I'd want something with proper IPMI/OOB (so Rpi is out) but maybe the dumbest, shallowest-depth atom64 supermicro you can find, in the event you need to do a reinstall or catch a hung system.
Are there things that other folks are using that are "easy" to work with that you've found to have Long firmware lives, decent warranties and low hassle? Does anything these days actually have DE9s on it?
-Dan
(You may have also seen my note earlier about the Cisco ASR920, which has RS232 pins in a USB-A header. No, not via a PL2032 chip inside the host that provides a virtual serial...direct txd/rxd/gnd/cts etc, on the USB pins. I've seen things you people would't believe) _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/5VV3B6CV...
-- - Andrew "lathama" Latham - _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/CPBVORP6...
_______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/Z4SBTD3J...
Couldn't you install linux on the cisco 2500s Im pretty sure at some time I got that to work so I could get SSH on them. We don't really use serial for access any longer just about everything has an out of band ethernet and we use that. On 12/18/2025 3:32 PM, Mike Simpson via NANOG wrote:
Largest vendor kit that only went EOL 2 years ago needs special config to allow DH algorithm that has been deprecated on the version of openssh in a MacOS that is older++ than the OS image on the kit
What has changed in the last 20 years is cryptanalysis leading to feasible attacks in minutes with a decent GPU -oh and the whole post-quantum encryption stuff and tonnes of cryptography hotness running through cfrg
Wouldn’t be a problem if security added shareholder value but stuff like fortinet/baracuda/salt typhoon has ably demonstrated that the market careth not so why should the vendors?
/rant
On 18 Dec 2025, at 21:05, Michael Thomas via NANOG <nanog@lists.nanog.org> wrote:
On 12/18/25 7:24 AM, Andrew Latham via NANOG wrote: Matt
Some open software would really keep a lot of this stuff out of the trash. I have Cyclades and Lantronix stuff on a shelf that works. I got tired of maintaining a box-in-the-middle to deal with ssh ciphers. Have cipher suites really changed that much in the last 20 years or so? After the sha1 kerfuffle and needing to up RSA key sizes, has there been much change?
Or are you talking about some seriously old kit that predates that?
Mike, out of the loop
On Thu, Dec 18, 2025 at 7:43 AM Matt Brennan <brennanma@gmail.com> wrote: Up until recently I was using the Raritan Dominion SX II models. Dual PSU, dual NIC, and configurations ranging from 4 to 48 ports. However, Raritan has just discontinued that as of June. It is unclear how long they will continue to provide security patches.
They are recommending customers switch to the ZPE Systems Nodegrid Serial Consoles. It looks to be much the same, but I haven't had a chance to test one yet. The only difference I've noticed is the ZPE device seems to have an embedded 5G cellular module.
On Thu, 18 Dec 2025 at 09:34, Andrew Latham via NANOG <nanog@lists.nanog.org> wrote:
Dan
I have stacks and stacks of serial console servers. Today I mostly use an https://www.coolgear.com/product/32-port-rs-232-usb-to-serial-adapter with some pictures of the guts at https://lathama.net/Tech/Hardware/USB-32COM-RM if interested. It is my solution to a quick build of an https://freetserv.github.io/
(I have seen some things)
On Wed, Dec 17, 2025 at 5:51 PM Dan Mahoney via NANOG <nanog@lists.nanog.org> wrote:
Hey there folks.
Dayjob has historically used USB TTY pods attached to real BSD machines to talk to our cisco consoles, with the amazing benefit that with a program like Vixie's rtty (or conserver) you can also capture the output of those consoles in real-time, and perhaps use that data to identify a connected device.
As a bonus, because the rackmount devices have real DE-9's on them, it means they work with any kind of cable you get (not just your standard rj45 cisco rollover like you might get with a Cyclades thing -- and you don't have to come up with the weird-ass mappings for rj45-serial like you might need like our ME4012 NAS (the serial cable is a stereo plug), our smart power strips (it's either a stereo plug, or an rj12), or something like an older brocade switch (it's a DE9, but it's friggin ODD, and I think it may also be the wrong gender).
It also means, since you're running a real OS, you have patches as long as the OS is supported (so you're not stuck with "gee it only speaks rsa1024"), versus some EOL appliance. But it's also 2u, and since we're recently buying a lot of Dell hardware, that's Super Overkill for a dell, so I'm evaluating maybe just going "Appliance".
If we stick with an existing unix box for this, I'd want something with proper IPMI/OOB (so Rpi is out) but maybe the dumbest, shallowest-depth atom64 supermicro you can find, in the event you need to do a reinstall or catch a hung system.
Are there things that other folks are using that are "easy" to work with that you've found to have Long firmware lives, decent warranties and low hassle? Does anything these days actually have DE9s on it?
-Dan
(You may have also seen my note earlier about the Cisco ASR920, which has RS232 pins in a USB-A header. No, not via a PL2032 chip inside the host that provides a virtual serial...direct txd/rxd/gnd/cts etc, on the USB pins. I've seen things you people would't believe) _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/5VV3B6CV...
-- - Andrew "lathama" Latham - _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/CPBVORP6...
_______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/Z4SBTD3J...
NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/HEODRQTF...
Once upon a time, Trey Scarborough <trey@3dsc.co> said:
Couldn't you install linux on the cisco 2500s Im pretty sure at some time I got that to work so I could get SSH on them.
Cisco 2500 series used a 68EC030, which is a dumbed-down 68030 with no MMU. The Linux m68k project always required an MMU, so it would not run on that CPU. There was some attempt to do an MMU-less Linux kernel fork at one point, but I don't know if that included any m68k effort (or if it really went anywhere). -- Chris Adams <cma@cmadams.net>
We're still rocking a couple of those. On an isolated management network, they just keep working. -----Original Message----- From: "Chris Adams via NANOG" <nanog@lists.nanog.org> Sent: Friday, December 19, 2025 12:54pm To: nanog@lists.nanog.org Cc: "Chris Adams" <cma@cmadams.net> Subject: Re: What are folks using for serial consoles these days? Once upon a time, Trey Scarborough <trey@3dsc.co> said:
Couldn't you install linux on the cisco 2500s Im pretty sure at some time I got that to work so I could get SSH on them.
Cisco 2500 series used a 68EC030, which is a dumbed-down 68030 with no MMU. The Linux m68k project always required an MMU, so it would not run on that CPU. There was some attempt to do an MMU-less Linux kernel fork at one point, but I don't know if that included any m68k effort (or if it really went anywhere). -- Chris Adams <cma@cmadams.net> _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/RDIQXOK2...
A comment here, choosing hardware that is built better is getting really hard. I find myself staring at industrial systems that have wide temperature operating ranges. A brand name server may have to many moving parts and poor heat dissipation for an OOBM solution. I know that many don't have purchasing power for vendors outside corporate approved sources. On Fri, Dec 19, 2025 at 11:02 AM Shawn L via NANOG <nanog@lists.nanog.org> wrote:
We're still rocking a couple of those. On an isolated management network, they just keep working.
-----Original Message----- From: "Chris Adams via NANOG" <nanog@lists.nanog.org> Sent: Friday, December 19, 2025 12:54pm To: nanog@lists.nanog.org Cc: "Chris Adams" <cma@cmadams.net> Subject: Re: What are folks using for serial consoles these days?
Once upon a time, Trey Scarborough <trey@3dsc.co> said:
Couldn't you install linux on the cisco 2500s Im pretty sure at some time I got that to work so I could get SSH on them.
Cisco 2500 series used a 68EC030, which is a dumbed-down 68030 with no MMU. The Linux m68k project always required an MMU, so it would not run on that CPU.
There was some attempt to do an MMU-less Linux kernel fork at one point, but I don't know if that included any m68k effort (or if it really went anywhere). -- Chris Adams <cma@cmadams.net> _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/RDIQXOK2... _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/44ZCZJ7G...
-- - Andrew "lathama" Latham -
On 12/19/25 12:54, Chris Adams via NANOG wrote:
Cisco 2500 series used a 68EC030, which is a dumbed-down 68030 with no MMU. The Linux m68k project always required an MMU, so it would not run on that CPU.
FWIW, MMU-less Linux is a thing and is no longer a separate fork. It's supported by the mainline kernel sources. Just turn off CONFIG_MMU. M68k should be supported for this purpose along with most other popular architectures were MMUs are not an inherent part of the CPU architecture including ARM and PPC. You also still need enough RAM. The bare minimum is 4MB, and 8MB is far more realistic, and that's just for the kernel itself. The result, though, is a system with some serious limitations which was also true of the old uClinux fork. In particular, there's no way to run most standard ELF executables. You either need to use uclinux FLAT ABI images (which does not support dynamic linking at all) or the much newer (and with tenable toolchain support) FDPIC ELF ABI. Either ABI imposes limitations on what userspace can do. For example, fork(2) doesn't work, though vfork does. OpenSSH doesn't even compile against the relevant headers IIRC, but dropbear does though I had trouble getting it to work at last attempt. Support for various other features often considered sundry to Linux varies, too. For example, on ARMv7-M, causing a segmentation fault from userspace will crash the entire system with rather terse kernel panic instead of terminating the offending process. This is not a technical limitation but rather a lacking implementation. Debuggers also don't work properly and instead lock the system up (ditto regarding it not being a technical limitation AFAIK). I'm not sure that really solves the desire to meaningfully run Linux of this platform for the purpose intended. -- Brandon Martin
VyOS has a built-in conserver (https://docs.vyos.io/en/latest/configuration/service/console-server.html). All one needs is a box to put it on, and it allows for customization with serial ports, power, connectivity, and of course having a firewall for an out-of-band network. Considering the number of ways to deploy VPNs and setup conserver, this setup can allow for centralized "conserver" endpoints for quickly getting into devices. Job had a presentation (https://nlnog.net/static/nlnog_live_summer_2020/NLNOG_Live_Job_Snijders_NTT_...) similar to what I described, but with a Cisco ISR router, replacing those older 2500 series devices. Adair Thaxton did a presentation on Internet2's out-of-band setup (https://youtu.be/ZuAZCA5lzww). Dan Baxter did a presentation on cellular out-of-band (https://youtu.be/hBX81XrXw18), which could be useful here. Ryan Hamel ________________________________ From: Brandon Martin via NANOG <nanog@lists.nanog.org> Sent: Sunday, December 21, 2025 1:12 PM To: nanog@lists.nanog.org <nanog@lists.nanog.org> Cc: Brandon Martin <lists.nanog@monmotha.net> Subject: Re: What are folks using for serial consoles these days? Caution: This is an external email and may be malicious. Please take care when clicking links or opening attachments. On 12/19/25 12:54, Chris Adams via NANOG wrote:
Cisco 2500 series used a 68EC030, which is a dumbed-down 68030 with no MMU. The Linux m68k project always required an MMU, so it would not run on that CPU.
FWIW, MMU-less Linux is a thing and is no longer a separate fork. It's supported by the mainline kernel sources. Just turn off CONFIG_MMU. M68k should be supported for this purpose along with most other popular architectures were MMUs are not an inherent part of the CPU architecture including ARM and PPC. You also still need enough RAM. The bare minimum is 4MB, and 8MB is far more realistic, and that's just for the kernel itself. The result, though, is a system with some serious limitations which was also true of the old uClinux fork. In particular, there's no way to run most standard ELF executables. You either need to use uclinux FLAT ABI images (which does not support dynamic linking at all) or the much newer (and with tenable toolchain support) FDPIC ELF ABI. Either ABI imposes limitations on what userspace can do. For example, fork(2) doesn't work, though vfork does. OpenSSH doesn't even compile against the relevant headers IIRC, but dropbear does though I had trouble getting it to work at last attempt. Support for various other features often considered sundry to Linux varies, too. For example, on ARMv7-M, causing a segmentation fault from userspace will crash the entire system with rather terse kernel panic instead of terminating the offending process. This is not a technical limitation but rather a lacking implementation. Debuggers also don't work properly and instead lock the system up (ditto regarding it not being a technical limitation AFAIK). I'm not sure that really solves the desire to meaningfully run Linux of this platform for the purpose intended. -- Brandon Martin _______________________________________________ NANOG mailing list https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.nanog.org%2Farchives%2Flist%2Fnanog%40lists.nanog.org%2Fmessage%2FOIWTGINAXFVDSQ2WARMMGXVCPXYASJUC%2F&data=05%7C02%7Cryan%40rkhtech.org%7C1a9aa8838f484ed367a508de40d5c2c2%7C81c24bb4f9ec4739ba4d25c42594d996%7C0%7C0%7C639019483999720029%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Ge1v2Dg79zqsJWrc0jlWrD8ghPGKnjjGOuQIcdaYyq0%3D&reserved=0<https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/OIWTGINAXFVDSQ2WARMMGXVCPXYASJUC/>
On 12/21/25 17:41, Ryan Hamel wrote:
Job had a presentation (https://nlnog.net/static/nlnog_live_summer_2020/ NLNOG_Live_Job_Snijders_NTT_IP_OOB.pdf <https://nlnog.net/static/ nlnog_live_summer_2020/NLNOG_Live_Job_Snijders_NTT_IP_OOB.pdf>) similar to what I described, but with a Cisco ISR router, replacing those older 2500 series devices.
Yeah I personally have some 2811s with NM-32As or HWIC-16As in them for my serial console breakout needs. It works pretty well, but it's unfortunately EOS so, as tempting as it might be given the broad network capabilities, I'm loathe to put them on a raw, unfiltered Internet connection. It does work pretty well, at least.
I'll add that this is a great use case for VyOS. FWIW we've run VyOS in production (not just management roles) since 2014 on a deployment of nearly 80 units at 10G line rates, and aside from finding new bugs here and there when attempting to configure things, they've been rock solid through every upgrade cycle. It's a mature project, they take security updates and release management seriously, and it gives a great toolkit for building infrastructure out quickly... in a lot of different roles (routing, vpn, firewall, load-balancer, console server, etc). On Sun, Dec 21, 2025 at 5:42 PM Ryan Hamel via NANOG <nanog@lists.nanog.org> wrote:
VyOS has a built-in conserver ( https://docs.vyos.io/en/latest/configuration/service/console-server.html). All one needs is a box to put it on, and it allows for customization with serial ports, power, connectivity, and of course having a firewall for an out-of-band network. Considering the number of ways to deploy VPNs and setup conserver, this setup can allow for centralized "conserver" endpoints for quickly getting into devices.
Job had a presentation ( https://nlnog.net/static/nlnog_live_summer_2020/NLNOG_Live_Job_Snijders_NTT_...) similar to what I described, but with a Cisco ISR router, replacing those older 2500 series devices.
Adair Thaxton did a presentation on Internet2's out-of-band setup ( https://youtu.be/ZuAZCA5lzww).
Dan Baxter did a presentation on cellular out-of-band ( https://youtu.be/hBX81XrXw18), which could be useful here.
Ryan Hamel
________________________________ From: Brandon Martin via NANOG <nanog@lists.nanog.org> Sent: Sunday, December 21, 2025 1:12 PM To: nanog@lists.nanog.org <nanog@lists.nanog.org> Cc: Brandon Martin <lists.nanog@monmotha.net> Subject: Re: What are folks using for serial consoles these days?
Caution: This is an external email and may be malicious. Please take care when clicking links or opening attachments.
On 12/19/25 12:54, Chris Adams via NANOG wrote:
Cisco 2500 series used a 68EC030, which is a dumbed-down 68030 with no MMU. The Linux m68k project always required an MMU, so it would not run on that CPU.
FWIW, MMU-less Linux is a thing and is no longer a separate fork. It's supported by the mainline kernel sources. Just turn off CONFIG_MMU. M68k should be supported for this purpose along with most other popular architectures were MMUs are not an inherent part of the CPU architecture including ARM and PPC.
You also still need enough RAM. The bare minimum is 4MB, and 8MB is far more realistic, and that's just for the kernel itself.
The result, though, is a system with some serious limitations which was also true of the old uClinux fork. In particular, there's no way to run most standard ELF executables. You either need to use uclinux FLAT ABI images (which does not support dynamic linking at all) or the much newer (and with tenable toolchain support) FDPIC ELF ABI.
Either ABI imposes limitations on what userspace can do. For example, fork(2) doesn't work, though vfork does. OpenSSH doesn't even compile against the relevant headers IIRC, but dropbear does though I had trouble getting it to work at last attempt.
Support for various other features often considered sundry to Linux varies, too. For example, on ARMv7-M, causing a segmentation fault from userspace will crash the entire system with rather terse kernel panic instead of terminating the offending process. This is not a technical limitation but rather a lacking implementation. Debuggers also don't work properly and instead lock the system up (ditto regarding it not being a technical limitation AFAIK).
I'm not sure that really solves the desire to meaningfully run Linux of this platform for the purpose intended. -- Brandon Martin _______________________________________________ NANOG mailing list
https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.nanog.org%2Farchives%2Flist%2Fnanog%40lists.nanog.org%2Fmessage%2FOIWTGINAXFVDSQ2WARMMGXVCPXYASJUC%2F&data=05%7C02%7Cryan%40rkhtech.org%7C1a9aa8838f484ed367a508de40d5c2c2%7C81c24bb4f9ec4739ba4d25c42594d996%7C0%7C0%7C639019483999720029%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Ge1v2Dg79zqsJWrc0jlWrD8ghPGKnjjGOuQIcdaYyq0%3D&reserved=0 < https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/OIWTGINA...
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/ZBF22VNO...
-- Ray Patrick Soucy Principal Cybersecurity Engineer University of Maine System
aside from finding new bugs here and there when attempting to configure things
OOB/last resort access is not the place you want to be discovering random bugs. That infra should be as rock solid and stable as you can possibly get for obvious reasons. On Mon, Dec 22, 2025 at 9:41 AM Ray Soucy via NANOG <nanog@lists.nanog.org> wrote:
I'll add that this is a great use case for VyOS. FWIW we've run VyOS in production (not just management roles) since 2014 on a deployment of nearly 80 units at 10G line rates, and aside from finding new bugs here and there when attempting to configure things, they've been rock solid through every upgrade cycle. It's a mature project, they take security updates and release management seriously, and it gives a great toolkit for building infrastructure out quickly... in a lot of different roles (routing, vpn, firewall, load-balancer, console server, etc).
On Sun, Dec 21, 2025 at 5:42 PM Ryan Hamel via NANOG < nanog@lists.nanog.org> wrote:
VyOS has a built-in conserver ( https://docs.vyos.io/en/latest/configuration/service/console-server.html ). All one needs is a box to put it on, and it allows for customization with serial ports, power, connectivity, and of course having a firewall for an out-of-band network. Considering the number of ways to deploy VPNs and setup conserver, this setup can allow for centralized "conserver" endpoints for quickly getting into devices.
Job had a presentation (
https://nlnog.net/static/nlnog_live_summer_2020/NLNOG_Live_Job_Snijders_NTT_... )
similar to what I described, but with a Cisco ISR router, replacing those older 2500 series devices.
Adair Thaxton did a presentation on Internet2's out-of-band setup ( https://youtu.be/ZuAZCA5lzww).
Dan Baxter did a presentation on cellular out-of-band ( https://youtu.be/hBX81XrXw18), which could be useful here.
Ryan Hamel
________________________________ From: Brandon Martin via NANOG <nanog@lists.nanog.org> Sent: Sunday, December 21, 2025 1:12 PM To: nanog@lists.nanog.org <nanog@lists.nanog.org> Cc: Brandon Martin <lists.nanog@monmotha.net> Subject: Re: What are folks using for serial consoles these days?
Caution: This is an external email and may be malicious. Please take care when clicking links or opening attachments.
On 12/19/25 12:54, Chris Adams via NANOG wrote:
Cisco 2500 series used a 68EC030, which is a dumbed-down 68030 with no MMU. The Linux m68k project always required an MMU, so it would not run on that CPU.
FWIW, MMU-less Linux is a thing and is no longer a separate fork. It's supported by the mainline kernel sources. Just turn off CONFIG_MMU. M68k should be supported for this purpose along with most other popular architectures were MMUs are not an inherent part of the CPU architecture including ARM and PPC.
You also still need enough RAM. The bare minimum is 4MB, and 8MB is far more realistic, and that's just for the kernel itself.
The result, though, is a system with some serious limitations which was also true of the old uClinux fork. In particular, there's no way to run most standard ELF executables. You either need to use uclinux FLAT ABI images (which does not support dynamic linking at all) or the much newer (and with tenable toolchain support) FDPIC ELF ABI.
Either ABI imposes limitations on what userspace can do. For example, fork(2) doesn't work, though vfork does. OpenSSH doesn't even compile against the relevant headers IIRC, but dropbear does though I had trouble getting it to work at last attempt.
Support for various other features often considered sundry to Linux varies, too. For example, on ARMv7-M, causing a segmentation fault from userspace will crash the entire system with rather terse kernel panic instead of terminating the offending process. This is not a technical limitation but rather a lacking implementation. Debuggers also don't work properly and instead lock the system up (ditto regarding it not being a technical limitation AFAIK).
I'm not sure that really solves the desire to meaningfully run Linux of this platform for the purpose intended. -- Brandon Martin _______________________________________________ NANOG mailing list
<
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/OIWTGINA...
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/ZBF22VNO...
-- Ray Patrick Soucy Principal Cybersecurity Engineer University of Maine System _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/2RQA3NLB...
On Fri, Dec 19, 2025 at 9:54 AM Chris Adams via NANOG <nanog@lists.nanog.org> wrote:
Once upon a time, Trey Scarborough <trey@3dsc.co> said:
Couldn't you install linux on the cisco 2500s Im pretty sure at some time I got that to work so I could get SSH on them.
Cisco 2500 series used a 68EC030, which is a dumbed-down 68030 with no MMU. The Linux m68k project always required an MMU, so it would not run on that CPU.
I haven't tried it, but: http://www.kdvelectronics.eu/uClinux-cisco2500/uClinux-cisco2500.html Regards, Bill Herrin -- For hire. https://bill.herrin.us/resume/
On Dec 18, 2025, at 6:34 AM, Andrew Latham <lathama@gmail.com> wrote:
Dan
I have stacks and stacks of serial console servers. Today I mostly use an https://www.coolgear.com/product/32-port-rs-232-usb-to-serial-adapter with some pictures of the guts at https://lathama.net/Tech/Hardware/USB-32COM-RM if interested. It is my solution to a quick build of an https://freetserv.github.io/
This is exactly what we're currently doing, and at the moment I'd like to find something minimal to replace the Dell R430s (one in each cabinet) that's driving it, but something that still has an ilom in case it dies at the worst possible time. Which, murphy being murphy.... -Dan
Dan I have some PCEngines APU4s in use that are built to another level. Sadly they are end of life. I am sure there might be some current industrial solutions that last. On Thu, Dec 18, 2025 at 7:44 AM Dan Mahoney <danm@prime.gushi.org> wrote:
On Dec 18, 2025, at 6:34 AM, Andrew Latham <lathama@gmail.com> wrote:
Dan
I have stacks and stacks of serial console servers. Today I mostly use an https://www.coolgear.com/product/32-port-rs-232-usb-to-serial-adapter with some pictures of the guts at https://lathama.net/Tech/Hardware/USB-32COM-RM if interested. It is my solution to a quick build of an https://freetserv.github.io/
This is exactly what we're currently doing, and at the moment I'd like to find something minimal to replace the Dell R430s (one in each cabinet) that's driving it, but something that still has an ilom in case it dies at the worst possible time. Which, murphy being murphy....
-Dan
-- - Andrew "lathama" Latham -
On Wed, Dec 17, 2025, 19:51 Dan Mahoney via NANOG <nanog@lists.nanog.org> wrote:
Hey there folks.
Dayjob has historically used USB TTY pods attached to real BSD machines to talk to our cisco consoles, with the amazing benefit that with a program like Vixie's rtty (or conserver) you can also capture the output of those consoles in real-time, and perhaps use that data to identify a connected device.
As a bonus, because the rackmount devices have real DE-9's on them, it means they work with any kind of cable you get (not just your standard rj45 cisco rollover like you might get with a Cyclades thing -- and you don't have to come up with the weird-ass mappings for rj45-serial like you might need like our ME4012 NAS (the serial cable is a stereo plug), our smart power strips (it's either a stereo plug, or an rj12), or something like an older brocade switch (it's a DE9, but it's friggin ODD, and I think it may also be the wrong gender).
It also means, since you're running a real OS, you have patches as long as the OS is supported (so you're not stuck with "gee it only speaks rsa1024"), versus some EOL appliance. But it's also 2u, and since we're recently buying a lot of Dell hardware, that's Super Overkill for a dell, so I'm evaluating maybe just going "Appliance".
If we stick with an existing unix box for this, I'd want something with proper IPMI/OOB (so Rpi is out) but maybe the dumbest, shallowest-depth atom64 supermicro you can find, in the event you need to do a reinstall or catch a hung system.
Are there things that other folks are using that are "easy" to work with that you've found to have Long firmware lives, decent warranties and low hassle? Does anything these days actually have DE9s on it?
-Dan
(You may have also seen my note earlier about the Cisco ASR920, which has RS232 pins in a USB-A header. No, not via a PL2032 chip inside the host that provides a virtual serial...direct txd/rxd/gnd/cts etc, on the USB pins. I've seen things you people would't believe)
Dan (et. al.) - Hear me out. Unconventional and might raise some eyebrows, but way cheaper, modular (no more "I used to have"s, "can't find them anymore"s, etc.), and if it works for you it works. 1. Serial "concentrator"/"multiplexer": miniPC, something like https://www.amazon.com/dp/B0DGGFR68Y Chuck Linux/BSD on it, add something like one (or more) of the following: https://www.conserver.com/ https://github.com/xcat2/goconserver https://github.com/wd5gnr/SerialMux https://eluaproject.net/doc/master/en_sermux.html https://github.com/danielinux/ttybus Some (esp. the N95 chip ones, but the N100s tend to be a bit more power efficient) can run fine with completely passive cooling. 2. Add in a *dedicated power* (no power-from-host-device) large-number-of-ports USB hub. Something like: https://www.amazon.com/dp/B07JM9ZFFV plus whatever connector adapters you need. 3. For OOB mgmt on the miniPC, IP-KVM. These two are the current hotness and are dirt cheap. https://blog.hardill.me.uk/2025/03/30/nanokvm-and-jetkvm-ip-kvms/ No power control like you would with a BMC or DRAC, but you can just bounce from the PDU or whatever if it gets that drastic. YMMV and it's not for everyone, but again- if it works for you, it works.
Well, if you’re determined to have IPMI, you’re asking for a lot of extra expense with minimal benefit. OTOH, if you power it via PoE or a controllable outlet accessible via your OOB network, I find that a NanoPi R6S or R.Pi with a USB hub and a bunch of FTDI serial dongles works great. I highly recommend the following udev rule, however, to avoid unpleasant naming surprises on the USB ports: SUBSYSTEM=="tty", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001",SYMLINK+="tty.FTDI.%E{ID_SERIAL_SHORT}" This creates an additional /dev/ symlink named tty.FTDI.<Serial>, so for example: root@asilomar:/var/log# ls -al /dev/tty* | grep 188, crw-rw---- 1 root dialout 188, 0 Dec 22 04:06 /dev/ttyUSB0 crw-rw---- 1 root dialout 188, 1 Dec 22 04:06 /dev/ttyUSB1 crw-rw---- 1 root dialout 188, 2 Dec 22 04:06 /dev/ttyUSB2 crw-rw---- 1 root dialout 188, 3 Dec 22 04:06 /dev/ttyUSB3 crw-rw---- 1 root dialout 188, 4 Dec 22 04:06 /dev/ttyUSB4 crw-rw---- 1 root dialout 188, 5 Dec 22 04:06 /dev/ttyUSB5 root@asilomar:/var/log# ls -al /dev/tty.FTDI* lrwxrwxrwx 1 root root 7 Dec 22 04:06 /dev/tty.FTDI.A99AGU55 -> ttyUSB5 lrwxrwxrwx 1 root root 7 Dec 22 04:06 /dev/tty.FTDI.A9BPURYS -> ttyUSB3 lrwxrwxrwx 1 root root 7 Dec 22 04:06 /dev/tty.FTDI.A9MIOH4N -> ttyUSB4 lrwxrwxrwx 1 root root 7 Dec 22 04:06 /dev/tty.FTDI.A9ZFAU3B -> ttyUSB0 lrwxrwxrwx 1 root root 7 Dec 22 04:06 /dev/tty.FTDI.AQ00OLSN -> ttyUSB1 ttyUSB2 is a non-FTDI adapter that doesn’t report a serial number and will be replaced next time I’m in the cold. If you use the FTDI symlinks in your conserver configuration, they don’t change across reboots, whereas the TTYUSB5 may suddenly be a completely different device next time you console to it. If you want most of the advantages of IPMI for a fraction of the cost (rather than just remote power cycling), then a BLIKVM unit is an excellent alternative. (It can even provide power cycling for any standard-ish PC Mobo). Owen
On Dec 17, 2025, at 16:51, Dan Mahoney via NANOG <nanog@lists.nanog.org> wrote:
Hey there folks.
Dayjob has historically used USB TTY pods attached to real BSD machines to talk to our cisco consoles, with the amazing benefit that with a program like Vixie's rtty (or conserver) you can also capture the output of those consoles in real-time, and perhaps use that data to identify a connected device.
As a bonus, because the rackmount devices have real DE-9's on them, it means they work with any kind of cable you get (not just your standard rj45 cisco rollover like you might get with a Cyclades thing -- and you don't have to come up with the weird-ass mappings for rj45-serial like you might need like our ME4012 NAS (the serial cable is a stereo plug), our smart power strips (it's either a stereo plug, or an rj12), or something like an older brocade switch (it's a DE9, but it's friggin ODD, and I think it may also be the wrong gender).
It also means, since you're running a real OS, you have patches as long as the OS is supported (so you're not stuck with "gee it only speaks rsa1024"), versus some EOL appliance. But it's also 2u, and since we're recently buying a lot of Dell hardware, that's Super Overkill for a dell, so I'm evaluating maybe just going "Appliance".
If we stick with an existing unix box for this, I'd want something with proper IPMI/OOB (so Rpi is out) but maybe the dumbest, shallowest-depth atom64 supermicro you can find, in the event you need to do a reinstall or catch a hung system.
Are there things that other folks are using that are "easy" to work with that you've found to have Long firmware lives, decent warranties and low hassle? Does anything these days actually have DE9s on it?
-Dan
(You may have also seen my note earlier about the Cisco ASR920, which has RS232 pins in a USB-A header. No, not via a PL2032 chip inside the host that provides a virtual serial...direct txd/rxd/gnd/cts etc, on the USB pins. I've seen things you people would't believe) _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/5VV3B6CV...
On 12/22/25 06:00, Owen DeLong via NANOG wrote:
I highly recommend the following udev rule, however, to avoid unpleasant naming surprises on the USB ports: SUBSYSTEM=="tty", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001",SYMLINK+="tty.FTDI.%E{ID_SERIAL_SHORT}"
This creates an additional/dev/ symlink named tty.FTDI.<Serial>, so for example:
IDK how common this is on other distributions, but at least Debian has /dev/serial/by-id that's basically the same thing and is distribution-standard. It's very convenient. -- Brandon Martin
I may get laughed outta here, but I use Mikrotik routers that have a USB port. Then hang a USB HUB off that with as many USB to serial consoles as needed. Setup strong firewalling on the unit, and VPN to it. Then I have all the Serial consoles I need. And they are inexpensive Thank You, Levon Bragg Shift Computer Services Phone 714.369.8197 x1101 Email levon@shiftcs.com<mailto:levon@shiftcs.com> Web h<https://shiftcs.com/>ttps://s<https://shiftcs.com/>hiftcs.com<https://shiftcs.com/> 10349 Los Alamitos Bl. Los Alamitos, CA 90720<https://www.google.com/maps/place/10349+Los+Alamitos+Blvd,+Los+Alamitos,+CA+90720/@33.8122346,-118.0747438,17z/data=!3m1!4b1!4m5!3m4!1s0x80dd2e64afc42587:0xd021d280b7fa2983!8m2!3d33.8122346!4d-118.0725551> ________________________________ From: Dan Mahoney via NANOG <nanog@lists.nanog.org> Sent: Wednesday, December 17, 2025 4:51 PM To: nanog@lists.nanog.org <nanog@lists.nanog.org> Cc: Dan Mahoney <danm@prime.gushi.org> Subject: What are folks using for serial consoles these days? Hey there folks. Dayjob has historically used USB TTY pods attached to real BSD machines to talk to our cisco consoles, with the amazing benefit that with a program like Vixie's rtty (or conserver) you can also capture the output of those consoles in real-time, and perhaps use that data to identify a connected device. As a bonus, because the rackmount devices have real DE-9's on them, it means they work with any kind of cable you get (not just your standard rj45 cisco rollover like you might get with a Cyclades thing -- and you don't have to come up with the weird-ass mappings for rj45-serial like you might need like our ME4012 NAS (the serial cable is a stereo plug), our smart power strips (it's either a stereo plug, or an rj12), or something like an older brocade switch (it's a DE9, but it's friggin ODD, and I think it may also be the wrong gender). It also means, since you're running a real OS, you have patches as long as the OS is supported (so you're not stuck with "gee it only speaks rsa1024"), versus some EOL appliance. But it's also 2u, and since we're recently buying a lot of Dell hardware, that's Super Overkill for a dell, so I'm evaluating maybe just going "Appliance". If we stick with an existing unix box for this, I'd want something with proper IPMI/OOB (so Rpi is out) but maybe the dumbest, shallowest-depth atom64 supermicro you can find, in the event you need to do a reinstall or catch a hung system. Are there things that other folks are using that are "easy" to work with that you've found to have Long firmware lives, decent warranties and low hassle? Does anything these days actually have DE9s on it? -Dan (You may have also seen my note earlier about the Cisco ASR920, which has RS232 pins in a USB-A header. No, not via a PL2032 chip inside the host that provides a virtual serial...direct txd/rxd/gnd/cts etc, on the USB pins. I've seen things you people would't believe) _______________________________________________ NANOG mailing list https://linkprotect.cudasvc.com/url?a=https%3a%2f%2flists.nanog.org%2farchives%2flist%2fnanog%40lists.nanog.org%2fmessage%2f5VV3B6CVSW3KVIFFU4GOF5V5FAI625IG%2f&c=E,1,cHuXzymG0lzuzwkVOFlgLT6nbZ6E1fQ5lihh56DeVca6NH2zU-pQg9sXyWkrSSdy7HsLz1EAnhNojYwDIOMxXozW51vGclHRBr3Vf9jNpLZG5-r2FQEeske9&typo=1
I have been known to do this as well. Works quite good, and supports wireguard and zerotier out of the box. On Mon, Dec 22, 2025, 6:58 PM Levon Bragg via NANOG <nanog@lists.nanog.org> wrote:
I may get laughed outta here, but I use Mikrotik routers that have a USB port. Then hang a USB HUB off that with as many USB to serial consoles as needed. Setup strong firewalling on the unit, and VPN to it. Then I have all the Serial consoles I need.
And they are inexpensive
Thank You,
Levon Bragg
Shift Computer Services
Phone 714.369.8197 x1101
Email levon@shiftcs.com<mailto:levon@shiftcs.com>
Web h<https://shiftcs.com/>ttps://s<https://shiftcs.com/>hiftcs.com<; https://shiftcs.com/>
10349 Los Alamitos Bl. Los Alamitos, CA 90720 <https://www.google.com/maps/search/10349+Los+Alamitos+Bl.+Los+Alamitos,+CA+90720?entry=gmail&source=g> < https://www.google.com/maps/place/10349+Los+Alamitos+Blvd,+Los+Alamitos,+CA+...
________________________________ From: Dan Mahoney via NANOG <nanog@lists.nanog.org> Sent: Wednesday, December 17, 2025 4:51 PM To: nanog@lists.nanog.org <nanog@lists.nanog.org> Cc: Dan Mahoney <danm@prime.gushi.org> Subject: What are folks using for serial consoles these days?
Hey there folks.
Dayjob has historically used USB TTY pods attached to real BSD machines to talk to our cisco consoles, with the amazing benefit that with a program like Vixie's rtty (or conserver) you can also capture the output of those consoles in real-time, and perhaps use that data to identify a connected device.
As a bonus, because the rackmount devices have real DE-9's on them, it means they work with any kind of cable you get (not just your standard rj45 cisco rollover like you might get with a Cyclades thing -- and you don't have to come up with the weird-ass mappings for rj45-serial like you might need like our ME4012 NAS (the serial cable is a stereo plug), our smart power strips (it's either a stereo plug, or an rj12), or something like an older brocade switch (it's a DE9, but it's friggin ODD, and I think it may also be the wrong gender).
It also means, since you're running a real OS, you have patches as long as the OS is supported (so you're not stuck with "gee it only speaks rsa1024"), versus some EOL appliance. But it's also 2u, and since we're recently buying a lot of Dell hardware, that's Super Overkill for a dell, so I'm evaluating maybe just going "Appliance".
If we stick with an existing unix box for this, I'd want something with proper IPMI/OOB (so Rpi is out) but maybe the dumbest, shallowest-depth atom64 supermicro you can find, in the event you need to do a reinstall or catch a hung system.
Are there things that other folks are using that are "easy" to work with that you've found to have Long firmware lives, decent warranties and low hassle? Does anything these days actually have DE9s on it?
-Dan
(You may have also seen my note earlier about the Cisco ASR920, which has RS232 pins in a USB-A header. No, not via a PL2032 chip inside the host that provides a virtual serial...direct txd/rxd/gnd/cts etc, on the USB pins. I've seen things you people would't believe) _______________________________________________ NANOG mailing list
https://linkprotect.cudasvc.com/url?a=https%3a%2f%2flists.nanog.org%2farchives%2flist%2fnanog%40lists.nanog.org%2fmessage%2f5VV3B6CVSW3KVIFFU4GOF5V5FAI625IG%2f&c=E,1,cHuXzymG0lzuzwkVOFlgLT6nbZ6E1fQ5lihh56DeVca6NH2zU-pQg9sXyWkrSSdy7HsLz1EAnhNojYwDIOMxXozW51vGclHRBr3Vf9jNpLZG5-r2FQEeske9&typo=1 _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/E5XE6R7Y...
On Dec 22, 2025, at 5:09 PM, Josh Reynolds via NANOG <nanog@lists.nanog.org> wrote:
I have been known to do this as well. Works quite good, and supports wireguard and zerotier out of the box.
Yes, I tried to say in my own post that we do this with an Actual FreeBSD system (which we can provision with our usual provisioning stuff (an idrac and puppet) and something like this: https://www.newegg.com/serialgear-usbg-16com-rm-usb-to-db9/p/0Y3-00DC-00015. We don't attach serials to *every device* (i.e. servers) any more now that this is reasonable and doesn't require a f'kn Java Applet, but we do leave all our switches and routers full-time connected. Plus things like our NASes. (And we already *have* those, *and* the unix boxen to power those, the BSD machines are just due for replacement, so we're asking The Questions). I'm trying to evaluate the use-case of: Does buying a purpose-built serial device... ...which may have a closed-source SSH implementation (ala Cicso and APC devices I've been burned by in the past). ...which may at any point go EOL and stop getting firmware... ...which doesn't have its own way to heal *itself* (With a PC, I can at least ask the noc techs to just go into the bios and run a cross-connect to my own infra, and reinstall via iLOM) ...and which would force us to recable some weird-ass things like this: https://hardwaredirect.pl/console-cable-dell-powervault-me4012-me4024-sc4020... ...but which might be more power-efficient than the cheapest Dell server I can buy right now, and which would occupy only 1RU versus 2, and only 1/2 power plugs over 2/3 per cabinet. Nobody's jumped up and said "This ioGear/Cyclades/Avocent thing rocks, and it'll have firmware for the next 10 years, for sure". My network hardware reseller hasn't gotten back to me (but it is Christmas week), So I'm inclined to stick with our existing solution. I just need to find a basic $300 server that I can get an actual warranty on, that I can send a reboot command to via IPMI if need be. -Dan
On Mon, Dec 22, 2025 at 05:25:22PM -0800, Dan Mahoney via NANOG wrote:
Nobody's jumped up and said "This ioGear/Cyclades/Avocent thing rocks, and it'll have firmware for the next 10 years, for sure". My network hardware reseller hasn't gotten back to me (but it is Christmas week),
Because nothing rocks. They all have the problems you list. One-off embedded system the manufactorer developed once with zero product cycle in thought. Puts out for some number of years until they no longer feel like supporting it. And then goes end-of-life with no upgrade options. I feel like OpenGear (owned by Digi now) tends to be the most future proof at this point in time (which will probably change in the future) if you are looking for an embedded box, But I've done solutions like you list too, and been happy with conserver and a basic PC.
Could we just start asking vendors to implement actual out-of-band port. Like Cisco CMP. The rs232 port we use, is on-band, if the NOS panics or otherwise is broken or busy, the rs232 port won't work either. On some routers you used to be able to have hardware break stop executing NOS and execute shell on rs232, which would allow you to reset the device via rs-232, even if NOS is not running, but this is actually going away and was rarely used by operators. But actual ethernet port on different SOC decoupled from control-plane would remove need for these RS232 consoles and would get us peak 2005 technology for networking gear. I think we're ready for 2005. On Tue, 23 Dec 2025 at 20:43, Doug McIntyre via NANOG <nanog@lists.nanog.org> wrote:
On Mon, Dec 22, 2025 at 05:25:22PM -0800, Dan Mahoney via NANOG wrote:
Nobody's jumped up and said "This ioGear/Cyclades/Avocent thing rocks, and it'll have firmware for the next 10 years, for sure". My network hardware reseller hasn't gotten back to me (but it is Christmas week),
Because nothing rocks. They all have the problems you list.
One-off embedded system the manufactorer developed once with zero product cycle in thought. Puts out for some number of years until they no longer feel like supporting it. And then goes end-of-life with no upgrade options.
I feel like OpenGear (owned by Digi now) tends to be the most future proof at this point in time (which will probably change in the future) if you are looking for an embedded box, But I've done solutions like you list too, and been happy with conserver and a basic PC. _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/SR3PVDZN...
-- ++ytti
From a Cisco perspective when we built the first 8000 (Silicon One) routers, the original 8201/8202 had a separate Baseboard Management Controller (BMC) the same as a server because we thought people would truly enjoy having that. In turns out no one used it and more were confused by it. It added extra cost and took up real estate that could be used for other things, so it didn’t continue. Thanks, Phil From: Saku Ytti via NANOG <nanog@lists.nanog.org> Date: Tuesday, December 23, 2025 at 12:50 PM To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Saku Ytti <saku@ytti.fi> Subject: Re: What are folks using for serial consoles these days? Could we just start asking vendors to implement actual out-of-band port. Like Cisco CMP. The rs232 port we use, is on-band, if the NOS panics or otherwise is broken or busy, the rs232 port won't work either. On some routers you used to be able to have hardware break stop executing NOS and execute shell on rs232, which would allow you to reset the device via rs-232, even if NOS is not running, but this is actually going away and was rarely used by operators. But actual ethernet port on different SOC decoupled from control-plane would remove need for these RS232 consoles and would get us peak 2005 technology for networking gear. I think we're ready for 2005. On Tue, 23 Dec 2025 at 20:43, Doug McIntyre via NANOG <nanog@lists.nanog.org> wrote:
On Mon, Dec 22, 2025 at 05:25:22PM -0800, Dan Mahoney via NANOG wrote:
Nobody's jumped up and said "This ioGear/Cyclades/Avocent thing rocks, and it'll have firmware for the next 10 years, for sure". My network hardware reseller hasn't gotten back to me (but it is Christmas week),
Because nothing rocks. They all have the problems you list.
One-off embedded system the manufactorer developed once with zero product cycle in thought. Puts out for some number of years until they no longer feel like supporting it. And then goes end-of-life with no upgrade options.
I feel like OpenGear (owned by Digi now) tends to be the most future proof at this point in time (which will probably change in the future) if you are looking for an embedded box, But I've done solutions like you list too, and been happy with conserver and a basic PC. _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/SR3PVDZN...
-- ++ytti _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/MRY54DUN...
On Tue, 23 Dec 2025 at 21:01, Phil Bedard <bedard.phil@gmail.com> wrote:
From a Cisco perspective when we built the first 8000 (Silicon One) routers, the original 8201/8202 had a separate Baseboard Management Controller (BMC) the same as a server because we thought people would truly enjoy having that. In turns out no one used it and more were confused by it. It added extra cost and took up real estate that could be used for other things, so it didn’t continue.
And I will apologise for all of us customers, we are wrong, you were right with CMP, you were right with BMC. It is blind spot we have and we need education. -- ++ytti
Saku, NANOG-ers,
On 23 Dec 2025, at 20:04, Saku Ytti via NANOG <nanog@lists.nanog.org> wrote:
On Tue, 23 Dec 2025 at 21:01, Phil Bedard <bedard.phil@gmail.com> wrote:
From a Cisco perspective when we built the first 8000 (Silicon One) routers, the original 8201/8202 had a separate Baseboard Management Controller (BMC) the same as a server because we thought people would truly enjoy having that. In turns out no one used it and more were confused by it. It added extra cost and took up real estate that could be used for other things, so it didn’t continue.
And I will apologise for all of us customers, we are wrong, you were right with CMP, you were right with BMC. It is blind spot we have and we need education.
I'm pretty sure you're half-joking and half-not, but that's the reality. I lead platform (hardware) development for Cisco Firewalls. I can tell you, that during my discussions with all of our Customers, from biggest to smallest ones, security folks don't appreciate fully dedicated, separate out-of-band management ports, with their own OS that's available no-matter-what. I've been through hundreds of discussions, and everybody says "nah" (and I don't even go into cost or whatever - just "availability"). I very much like your comment, and I'll use it, but that's reality folks - you vote with your wallets, and it seems that's not really as critical for management as you'd (and I'd) think. And even *I* have LTE access to my own rack(s), including console ports. And I'm just toying with all the fancy and less fancy gear... 2005? Hell - more like 1995... -- Łukasz Bromirski
Tue, Dec 23, 2025 at 08:51:54PM +0100, Lukasz Bromirski via NANOG:
I'm pretty sure you're half-joking and half-not, but that's the reality. I lead platform (hardware) development for Cisco Firewalls. I can tell you, that during my discussions with all of our Customers, from biggest to smallest ones, security folks don't appreciate fully dedicated, separate out-of-band management ports, with their own OS that's available no-matter-what.
I'd expect that, from a security perspective, one problem is that BMCs are often neglected by both the customer and the mfg. eg, they often never receive a s/w update for the life of the product or the update procedure is arcane and unautomatable; both like smc and unacceptable. Regardless, maybe provide a jumper to disable the bmc, like smc does? Provide a sku that comes with it disabled, if you must. It might not fit all user scenarios, but a bmc port that is shared with the mgmt port, per-RP, would also save mgmt network ports. like some smc boards. And, just have a cli and a command that connects to a tty on the RP. No guis, no curses magic, no menus; KISS. Sun's LOM was a great impl.
- you vote with your wallets
how much is really saved? is it actually a noticable cost? make it a daughter card?
Hi,
On 23 Dec 2025, at 22:11, heasley <heas@shrubbery.net> wrote:
Tue, Dec 23, 2025 at 08:51:54PM +0100, Lukasz Bromirski via NANOG:
I'm pretty sure you're half-joking and half-not, but that's the reality. I lead platform (hardware) development for Cisco Firewalls. I can tell you, that during my discussions with all of our Customers, from biggest to smallest ones, security folks don't appreciate fully dedicated, separate out-of-band management ports, with their own OS that's available no-matter-what.
I'd expect that, from a security perspective, one problem is that BMCs are often neglected by both the customer and the mfg. eg, they often never receive a s/w update for the life of the product or the update procedure is arcane and unautomatable; both like smc and unacceptable.
Yes, and that's actually one of my talking points (to not use something off the shelf and instead deploy hardened Linux on some ARM/SoC). We never get to that point of discussion though. Currently our way of doing that was to dedicate cores from main CPU to run it's own VM as FXOS, or in some cases run these ports indeed as dedicated FXOS instance, physically distinct from the "main" CPU and OS. All we've heard was "oh, it adds complexity, we don't like it".
- you vote with your wallets how much is really saved? is it actually a noticable cost? make it a daughter card?
What I meant is by buying equipment that doesn't have it, or not driving this as a requirement in RFPs. The actual cost of the SoC, flash and circuitry is going to be like 5$. Let's be generous and assume I'm going to add 100$ to the price of the box to adjust for margins. There will be some cost of added development and testing. You think you're going to notice this in a 300k$ box? Or 1M$ box? Nah. But we need this clearly articulated by you - the people, otherwise it's "these PMs are making things up". -- ./
On Tue, 23 Dec 2025 at 23:08, heasley via NANOG <nanog@lists.nanog.org> wrote:
I'd expect that, from a security perspective, one problem is that BMCs are often neglected by both the customer and the mfg. eg, they often never receive a s/w update for the life of the product or the update procedure is arcane and unautomatable; both like smc and unacceptable.
Security is a very good argument to throw around whenever you're against something for whatever reason. Not only does no one ever ask if the defending is more expensive than the realised risk. Neither does anyone offer metrics to measure the performance of the security investment and roll it back, if it doesn't perform. You can always just add more security, the power of the bark. Only really effective security we have, online and offline, is building an environment and policies where motivation to be a bad actor is reduced. The safest societies in the world aren't those with the most LE investment (US pays much more per capita on LE, healthcare than west, and has absolutely abysmal murder close ratios. Going under 50% last year, while countries like Finland hover at 99% with much smaller LE investments) but those who invest on fundamentals on why those bad actors exist in the first place. Security is snakeoil men selling fear. Personally, I don't care about BMC security, it's not important. People are asking it to be CLI only, it was, so was CMP, BMC and CMP were what we wanted, we just didn't bother figuring it out. -- ++ytti
On Wed, Dec 24, 2025, 02:59 Saku Ytti via NANOG .
Personally, I don't care about BMC security, it's not important. People are asking it to be CLI only, it was, so was CMP, BMC and CMP were what we wanted, we just didn't bother figuring it out.
I mean it's not like a serious flaw was ever found[0] on the thing that grants access to "ring -4" and above. I'm sure those security guys are just giving you a hard time for funzies, those scoundrels! [0] a. http://fish2.com/ipmi/cipherzero.html https://nvd.nist.gov/vuln/detail/CVE-2013-4782 https://nvd.nist.gov/vuln/detail/CVE-2013-4783 https://nvd.nist.gov/vuln/detail/CVE-2013-4784 https://nvd.nist.gov/vuln/detail/CVE-2014-2955 b. https://eclypsium.com/blog/virtual-media-vulnerability-in-bmc-opens-servers-... c. https://nvd.nist.gov/vuln/detail/cve-2019-6260
Wed, Dec 24, 2025 at 09:58:34AM +0200, Saku Ytti:
Personally, I don't care about BMC security, it's not important. People are asking it to be CLI only, it was, so was CMP, BMC and CMP were what we wanted, we just didn't bother figuring it out.
bs, saku. complexity and cost of bmcs are not valid arguments imo, but security must be addressed, as must usability and compatability. It is not sufficient to isolate the bmc network; if it is accessible to you, then it is accessible to other internal threats, whatever their motivation. Ignoring FIPS bs, to which some are subjected; if the mfg never supplies updates or the owner never applies them, it could have security issues or issues that affect your use/mgmt of it. eg: only supports 3des-cbc. yet, if it can be disabled or simply not connected to the network, the security issue is mostly addressed, and voids the security argument. SMC literally creates a BMC & its s/w version, it is added to many models, and is unlikely to ever receive an update. Any bugs or holes are yours to cherish for the duration of the product's life. To name a few SMC gems: java, OoD java, backdoors, EoL ssh ciphers, ... I want the bmc, and a list of features. Minimally, it seems very reasonable to ask that bugs be fixed, bundled s/w be updated, and an automatable update procedure be supplied (that does not require rebooting the host). They're super useful for the lab & testing too. And, yes, some are cli, but far from all. The gui ones are really terrible. Not just network gear, all devices.
On Wed, 24 Dec 2025 at 19:09, heasley <heas@shrubbery.net> wrote:
SMC literally creates a BMC & its s/w version, it is added to many models, and is unlikely to ever receive an update. Any bugs or holes are yours to cherish for the duration of the product's life. To name a few SMC gems: java, OoD java, backdoors, EoL ssh ciphers, ...
I want the bmc, and a list of features. Minimally, it seems very reasonable to ask that bugs be fixed, bundled s/w be updated, and an automatable update procedure be supplied (that does not require rebooting the host).
They're super useful for the lab & testing too.
And, yes, some are cli, but far from all. The gui ones are really terrible. Not just network gear, all devices.
Fully agree on what it ideally should be and there are some downright broken things, some which require features that current web browsers do not support. But CMP/BMC are not like this, both are proper CLI. So both examples we've had for networking gear, have been good ones. And I don't think 3rd example exists. And yes, it should be just SOC with mostly standard Linux, with kernel modules to offer access to manage the NOS side control-plane and hardware (to power cycle it, to copy data off/on its storage, etc). But let's say we have this, reasonably well done. Now for whatever reason it stops receiving critical software upgrades, and it ends up running insecure OpenSSH or DHCPd and you can't get channel upgrades to it (maybe you can hack it yourself, if you can root to shell and throw around binary packages for sshd, dhcpd, maybe not). I'll still take it, I'll still take the port with old insecure OpenSSH and DHCPd, rather than also deploy RS232 port in the pop. I'll not be happy about it, but I won't lose any sleep, I know that if my security comes to the BMC port not having insecure OpenSSH. I am not assuming my RS232 port is any more secure than insecure OpenSSH port, I am assuming maybe if you inject some weird sequence, you can do HW interrupt to get the CPU to execute some other code. The BMC would connect to some switch and router down the line. These would have ACL that would allow out-of-band access from my managed infra, and potentially also one or two networks that I can access when nothing in my own infra works. Now the attacker has to have access to a specific network or hosts before they can attack that host, I'm just not worried about that. Things are too broken to entertain the luxury of caring about minor things like that, and it is not conceivable for them to become better in my horizon. I sometimes wonder if PSTN switches like DX200 and AXE are reliable because or despite of how they are written. Both basically have their own internal domain specific language which compiles into a more general purpose language. I think Arista is similarly using or at least used to use internal language that compiles to C++. I wonder if this should be encouraged or discouraged. Naively to me it seems like any project that you expect to be alive decades and need hundreds of high attrition developers should use their own programming language per software. I think this makes sense, because the surface area to write code is very limited, even on large projects, you can only throw a very limited number of developers at it, and the cost of those developers isn't actually a meaningful cost in your bottom line. So in addition to having your application developers, you could have a small team consisting both of language theory experts and senior people who came from the application side, who now develop the language itself. The rationale here is that if your language is targeting a single application, you can make tons of assumptions easily. You can make it increasingly easier for application developers to develop applications quickly and make it hard for them to introduce bugs, because you have visibility of where bugs happen, you can ensure there is an easier way to write those things, which will also guarantee correctness at compile time. -- ++ytti
On 23/12/2025 19:51:54, "Lukasz Bromirski via NANOG" <nanog@lists.nanog.org> wrote:
On 23 Dec 2025, at 20:04, Saku Ytti via NANOG <nanog@lists.nanog.org> wrote:
And I will apologise for all of us customers, we are wrong, you were right with CMP, you were right with BMC. It is blind spot we have and we need education.
Too soon, it will take a whole infra refresh cycle for such a change to be adopted. Something that is in one product generation is not going to get much use. New things get mingled with old things all connected to old OOB. All the old things need the new tech before we can get rid of the old OOB and in our case it does not change the OOB much, just another ethernet port instead of a serial port.
I lead platform (hardware) development for Cisco Firewalls. I can tell you, that during my discussions with all of our Customers, from biggest to smallest ones, security folks don't appreciate fully dedicated, separate out-of-band management ports, with their own OS that's available no-matter-what.
It will just sit alongside the control plane management ethernet port so probably no advantage to them for the few occasions that port locks up. When it does lock up they just send a tech or use the PDU relay to switch it off and on again. I'm even fine with it remaining serial. As an original Sun LOM adopter I value the LOM being really simple and not another OS with added attack surface to maintain. A built in BMC sharing ports with other stuff sounds less reliable to me.
And even *I* have LTE access to my own rack(s), including console ports.
We just use ISR 4451: serial, ethernet, 4G, sfp for OOB waves, dual psu, big spare SM slot to hide the rPI DMZ host, all in one box. Only external part is the managed PDU. brandon
Brandon,
On 24 Dec 2025, at 00:11, Brandon Butterworth <brandon@bogons.net> wrote:
It will just sit alongside the control plane management ethernet port so probably no advantage to them for the few occasions that port locks up. When it does lock up they just send a tech or use the PDU relay to switch it off and on again.
Just like Philip wrote, additional, dedicated ports seem to only confuse people these days. Maybe we traded too much of hardware for software.
I'm even fine with it remaining serial. As an original Sun LOM adopter I value the LOM being really simple and not another OS with added attack surface to maintain. A built in BMC sharing ports with other stuff sounds less reliable to me.
I never said "shared". Dedicated and connected to this CPU/SoC, with it's own flash. Doing anything shared outside of power/fans in this case just defeats the purpose.
And even *I* have LTE access to my own rack(s), including console ports. We just use ISR 4451: serial, ethernet, 4G, sfp for OOB waves, dual psu, big spare SM slot to hide the rPI DMZ host, all in one box. Only external part is the managed PDU.
Yup, 2901, same thing. Despite the comments, it can be very much hardened. If its current SSH implementation is not up to your liking, you can always simply terminate IPsec tunnel using certs and use that to access the device and devices behind it. Yeah, it's not wireguard. For 115200 you don't have need anything super powerful, and 2800/2900 class router can do a lot of IPsec to be enough for terminal access. I like the "SM slot to hide the RPi DMZ host" :) Never thought about it. -- ./
Heh, yeah right.. the very same security guys who CANNOT actually keep they stuff safe... or under controll.. Breaches and leaks left and right all the time.. But, back to the topic. Back in good old times I was admining SUN servers, and they had that super cool think called ALOM with was OOB CLI management stuff that worked all the time, even when device was powered on but plugged in. It was awesome.. Whatever happened to server, you could always telnet (or use SUN serial) to ALOM, and check things out or even reinstall box remotly if you had infra for it set up.. It was great thing. Ytti is absolutly right here. This stuff should be norm and from security point of view, I can always make entire OOB network dark, only accessible via VPN overlay network... ---------- Original message ---------- From: Lukasz Bromirski via NANOG <nanog@lists.nanog.org> To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Lukasz Bromirski <lukasz@bromirski.net> Subject: Re: What are folks using for serial consoles these days? Date: Tue, 23 Dec 2025 20:51:54 +0100 Saku, NANOG-ers,
On 23 Dec 2025, at 20:04, Saku Ytti via NANOG <nanog@lists.nanog.org> wrote:
On Tue, 23 Dec 2025 at 21:01, Phil Bedard <bedard.phil@gmail.com> wrote:
From a Cisco perspective when we built the first 8000 (Silicon One) routers, the original 8201/8202 had a separate Baseboard Management Controller (BMC) the same as a server because we thought people would truly enjoy having that. In turns out no one used it and more were confused by it. It added extra cost and took up real estate that could be used for other things, so it didn˙˙t continue.
And I will apologise for all of us customers, we are wrong, you were right with CMP, you were right with BMC. It is blind spot we have and we need education.
I'm pretty sure you're half-joking and half-not, but that's the reality. I lead platform (hardware) development for Cisco Firewalls. I can tell you, that during my discussions with all of our Customers, from biggest to smallest ones, security folks don't appreciate fully dedicated, separate out-of-band management ports, with their own OS that's available no-matter-what. I've been through hundreds of discussions, and everybody says "nah" (and I don't even go into cost or whatever - just "availability"). I very much like your comment, and I'll use it, but that's reality folks - you vote with your wallets, and it seems that's not really as critical for management as you'd (and I'd) think. And even *I* have LTE access to my own rack(s), including console ports. And I'm just toying with all the fancy and less fancy gear... 2005? Hell - more like 1995... -- Łukasz Bromirski _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/7E53W37W...
On Wed, Dec 24, 2025, 04:59 borg--- via NANOG <
Ytti is absolutly right here. This stuff should be norm and from security point of view, I can always make entire OOB network dark, only accessible via VPN overlay network...
Okay, but remember OOB/BMC/iDRAC management was brought up here in the explicit context of the *serial concentrator/multiplexer*. You know, the thing someone would be using to access/manage/recover the exact kit you'd be using to *do* all that.
I learned unix on those and worked almost exclusively with them for most of my early career. I kind of miss them. -----Original Message----- From: "borg--- via NANOG" <nanog@lists.nanog.org> Sent: Wednesday, December 24, 2025 4:58am To: nanog@lists.nanog.org Cc: borg@uu3.net Subject: Re: What are folks using for serial consoles these days? Heh, yeah right.. the very same security guys who CANNOT actually keep they stuff safe... or under controll.. Breaches and leaks left and right all the time.. But, back to the topic. Back in good old times I was admining SUN servers, and they had that super cool think called ALOM with was OOB CLI management stuff that worked all the time, even when device was powered on but plugged in. It was awesome.. Whatever happened to server, you could always telnet (or use SUN serial) to ALOM, and check things out or even reinstall box remotly if you had infra for it set up.. It was great thing. Ytti is absolutly right here. This stuff should be norm and from security point of view, I can always make entire OOB network dark, only accessible via VPN overlay network... ---------- Original message ---------- From: Lukasz Bromirski via NANOG <nanog@lists.nanog.org> To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Lukasz Bromirski <lukasz@bromirski.net> Subject: Re: What are folks using for serial consoles these days? Date: Tue, 23 Dec 2025 20:51:54 +0100 Saku, NANOG-ers,
On 23 Dec 2025, at 20:04, Saku Ytti via NANOG <nanog@lists.nanog.org> wrote:
On Tue, 23 Dec 2025 at 21:01, Phil Bedard <bedard.phil@gmail.com> wrote:
From a Cisco perspective when we built the first 8000 (Silicon One) routers, the original 8201/8202 had a separate Baseboard Management Controller (BMC) the same as a server because we thought people would truly enjoy having that. In turns out no one used it and more were confused by it. It added extra cost and took up real estate that could be used for other things, so it didn˙˙t continue.
And I will apologise for all of us customers, we are wrong, you were right with CMP, you were right with BMC. It is blind spot we have and we need education.
I'm pretty sure you're half-joking and half-not, but that's the reality. I lead platform (hardware) development for Cisco Firewalls. I can tell you, that during my discussions with all of our Customers, from biggest to smallest ones, security folks don't appreciate fully dedicated, separate out-of-band management ports, with their own OS that's available no-matter-what. I've been through hundreds of discussions, and everybody says "nah" (and I don't even go into cost or whatever - just "availability"). I very much like your comment, and I'll use it, but that's reality folks - you vote with your wallets, and it seems that's not really as critical for management as you'd (and I'd) think. And even *I* have LTE access to my own rack(s), including console ports. And I'm just toying with all the fancy and less fancy gear... 2005? Hell - more like 1995... -- Łukasz Bromirski _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/7E53W37W... _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/E7PZ4XCP...
Everything is incredibly broken and fragile. If you are not pwned, it is because no one wants to. DDoSing any backbone router is trivial from 10Mbps VPN, cause we cant protect the control plane. And it doesnt matter. No one wants to do that. ++ytti ________________________________ Lähettäjä: Shawn L via NANOG <nanog@lists.nanog.org> Lähetetty: Wednesday, December 24, 2025 3:01:36 PM Vastaanottaja: North American Network Operators Group <nanog@lists.nanog.org> Kopio: Shawn L <shawnl@up.net> Aihe: Re: What are folks using for serial consoles these days? I learned unix on those and worked almost exclusively with them for most of my early career. I kind of miss them. -----Original Message----- From: "borg--- via NANOG" <nanog@lists.nanog.org> Sent: Wednesday, December 24, 2025 4:58am To: nanog@lists.nanog.org Cc: borg@uu3.net Subject: Re: What are folks using for serial consoles these days? Heh, yeah right.. the very same security guys who CANNOT actually keep they stuff safe... or under controll.. Breaches and leaks left and right all the time.. But, back to the topic. Back in good old times I was admining SUN servers, and they had that super cool think called ALOM with was OOB CLI management stuff that worked all the time, even when device was powered on but plugged in. It was awesome.. Whatever happened to server, you could always telnet (or use SUN serial) to ALOM, and check things out or even reinstall box remotly if you had infra for it set up.. It was great thing. Ytti is absolutly right here. This stuff should be norm and from security point of view, I can always make entire OOB network dark, only accessible via VPN overlay network... ---------- Original message ---------- From: Lukasz Bromirski via NANOG <nanog@lists.nanog.org> To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Lukasz Bromirski <lukasz@bromirski.net> Subject: Re: What are folks using for serial consoles these days? Date: Tue, 23 Dec 2025 20:51:54 +0100 Saku, NANOG-ers,
On 23 Dec 2025, at 20:04, Saku Ytti via NANOG <nanog@lists.nanog.org> wrote:
On Tue, 23 Dec 2025 at 21:01, Phil Bedard <bedard.phil@gmail.com> wrote:
From a Cisco perspective when we built the first 8000 (Silicon One) routers, the original 8201/8202 had a separate Baseboard Management Controller (BMC) the same as a server because we thought people would truly enjoy having that. In turns out no one used it and more were confused by it. It added extra cost and took up real estate that could be used for other things, so it didn˙˙t continue.
And I will apologise for all of us customers, we are wrong, you were right with CMP, you were right with BMC. It is blind spot we have and we need education.
I'm pretty sure you're half-joking and half-not, but that's the reality. I lead platform (hardware) development for Cisco Firewalls. I can tell you, that during my discussions with all of our Customers, from biggest to smallest ones, security folks don't appreciate fully dedicated, separate out-of-band management ports, with their own OS that's available no-matter-what. I've been through hundreds of discussions, and everybody says "nah" (and I don't even go into cost or whatever - just "availability"). I very much like your comment, and I'll use it, but that's reality folks - you vote with your wallets, and it seems that's not really as critical for management as you'd (and I'd) think. And even *I* have LTE access to my own rack(s), including console ports. And I'm just toying with all the fancy and less fancy gear... 2005? Hell - more like 1995... -- Łukasz Bromirski _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/7E53W37W... _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/E7PZ4XCP... _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/KDJLQDJB...
Where was the confusion? Was it perhaps relatively difficult to configure, difficult to update, or difficult to manage? Were people maybe confused by the term "BMC"? The terms "iDRAC" and "iLO" tend to crop up more often in engineering shops. I see NIST recommended against using it in "FIPS mode", so I assume there was some security concern? The references I see still posted on Cisco.com talk about configuring the BMC in the "System Setup Guide for Cisco 8000 Series Routers." There's no match in that doc for anything related to BMC, so I assume the documentation has already been removed. I'd be very interested in a way to remotely and securely manage a router out-of-band that didn't involve EIA-232. CLI only would be preferred. Better still if the BMC firmware and config were unified with the device's firmware and config: one software package to update, one config to back up. -Brian On 2025-12-23 13:01, Phil Bedard via NANOG wrote:
From a Cisco perspective when we built the first 8000 (Silicon One) routers, the original 8201/8202 had a separate Baseboard Management Controller (BMC) the same as a server because we thought people would truly enjoy having that. In turns out no one used it and more were confused by it. It added extra cost and took up real estate that could be used for other things, so it didn’t continue.
Thanks, Phil
From: Saku Ytti via NANOG <nanog@lists.nanog.org> Date: Tuesday, December 23, 2025 at 12:50 PM To: North American Network Operators Group <nanog@lists.nanog.org> Cc: Saku Ytti <saku@ytti.fi> Subject: Re: What are folks using for serial consoles these days?
Could we just start asking vendors to implement actual out-of-band port.
Like Cisco CMP.
The rs232 port we use, is on-band, if the NOS panics or otherwise is broken or busy, the rs232 port won't work either. On some routers you used to be able to have hardware break stop executing NOS and execute shell on rs232, which would allow you to reset the device via rs-232, even if NOS is not running, but this is actually going away and was rarely used by operators.
But actual ethernet port on different SOC decoupled from control-plane would remove need for these RS232 consoles and would get us peak 2005 technology for networking gear. I think we're ready for 2005.
[snip]
Once upon a time, Levon Bragg <levon@shiftcs.com> said:
I may get laughed outta here, but I use Mikrotik routers that have a USB port. Then hang a USB HUB off that with as many USB to serial consoles as needed. Setup strong firewalling on the unit, and VPN to it. Then I have all the Serial consoles I need.
At $LASTJOB for the main site we got a 1U Supermicro barebones and a 16-port serial breakout card. Put CentOS Linux on it (the main server OS there) and off we went. Got one with 4x 1G NICs built in so we could connect to a couple of management ports and an OOB network provider. -- Chris Adams <cma@cmadams.net>
participants (26)
-
Andrew Latham -
borg＠uu3.net -
Brandon Butterworth -
Brandon Martin -
brent saner -
Brian Knight -
Chris Adams -
Dan Mahoney -
Daniel Seagraves -
Doug McIntyre -
heasley -
Josh Reynolds -
Levon Bragg -
Lukasz Bromirski -
Matt Brennan -
Michael Thomas -
Mike Simpson -
Owen DeLong -
Phil Bedard -
Ray Soucy -
Ryan Hamel -
Saku Ytti -
Shawn L -
Tom Beecher -
Trey Scarborough -
William Herrin