+1 for the Lantronix SLC. On 01/30/12 11:24 -0500, Paul Stewart wrote:

We really like Lantronix .. use them a lot.

Paul

-----Original Message----- From: Ray Soucy [mailto:rps@maine.edu] Sent: Monday, January 30, 2012 11:09 AM To: NANOG Subject: Console Server Recommendation

What are people using for console servers these days? We've historically used retired routers with ASYNC ports, but it's time for an upgrade.

OpenGear seems to have some nice stuff, anyone else?

-- Ray Soucy

Epic Communications Specialist

Phone: +1 (207) 561-3526

Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/

----- Original Message -----

From: "Michael Thomas" <mike@mtcc.com>

Lantronix still makes terminal servers? Huh. I designed their first ones over 20 years ago!

And Lantronix has the *delightful* policy that *they will still support those units (assuming they do at all) free*, even if I bought them used. +5 for Lantronix. Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274

+1 for Cyclades .. we've been using a few of these with a bunch 20-port PDU strips (2 x 15A circuits) and they've worked out pretty well for us. We did have some overheating issues with the PDU's though, but this was fixed with an adjustment to the HVAC (CYCLADES-ACS-PM-MIB is your friend ;-) -- Gino PGP Info: http://1337.io/pgp On 1/30/12 8:26 AM, -Hammer- wrote:

Avocent Cyclades ACS. Enterprise class.

http://www.avocent.com/Products/Category/Serial_Appliances.aspx

-Hammer-

"I was a normal American nerd" -Jack Herer

On 1/30/2012 10:08 AM, Ray Soucy wrote:

...

What are people using for console servers these days? We've historically used retired routers with ASYNC ports, but it's time for an upgrade.

OpenGear seems to have some nice stuff, anyone else?

Hi, leigh.porter@ukbroadband.com wrote on Mo, 2012-01-30 at 17:47+0100:

On 30 Jan 2012, at 16:10, "Ray Soucy" <rps@maine.edu> wrote:

...

What are people using for console servers these days? We've historically used retired routers with ASYNC ports, but it's time for an upgrade.

OpenGear seems to have some nice stuff, anyone else?

+1 for OpenGear. I asked this same question about a year ago..

+1 from me. Their boxes really rock. It just saved my life you can fully access the underlying linux as root (in my case to debug the mgetty on the box). Rgds, Malte -- Malte von dem Hagen Head of Network Engineering & Operations ----------------------------------------------------------------------- Host Europe GmbH - http://www.hosteurope.de Welserstraße 14 - 51149 Köln - Germany Telefon: 0800 467 8387 - Fax: +49 180 5 66 3233 (*) HRB 28495 Amtsgericht Köln - USt-IdNr.: DE187370678 Geschäftsführer: Patrick Pulvermüller, Thomas Vollrath (*) 0,14 EUR/Min. aus dem dt. Festnetz; maximal 0,42 EUR/Min. aus den dt. Mobilfunknetzen

Another +1 to Opengear Just buy the units that have the pinout for your devices, or you may need adapters. -- Brent Jones brent@brentrjones.com On Mon, Jan 30, 2012 at 9:40 AM, Asaf Rapoport <arapoport@telepacific.com>wrote:

I use Opengear more often now on smaller installs.. Works well and they have some neat add ons (Nagios, UPS monitoring etc)

Asaf Rapoport

On 1/30/12 9:31 AM, "Rafael Rodriguez" <packetjockey@gmail.com> wrote:

...

Opengear

On Mon, Jan 30, 2012 at 11:08 AM, Ray Soucy <rps@maine.edu> wrote:

...

What are people using for console servers these days? We've historically used retired routers with ASYNC ports, but it's time for an upgrade.

OpenGear seems to have some nice stuff, anyone else?

-- Ray Soucy

Epic Communications Specialist

Phone: +1 (207) 561-3526

Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/

On 31/01/2012 09:11, Saku Ytti wrote:

For me, required features are

This is part of the problem here. You want a terminal server which was designed for console access. Most of the terminal servers on the market are by-products of the modem dialin era and their development function was aimed at a different market. Consequently, they are better at stuff like modem dialin and stuff like that rather than console management. The problem is that there isn't a large market for console servers designed specifically for management console access, and there are a pile of incumbents in the existing market place. I like feature list you posted, btw. If there were any console servers out there with these features, I would buy a bunch of them.

RS232 console on control-plane is ridiculously useless, you cannot copy images over it (even if supported, images are several hundreds megabytes). It is completely dependant on control-plane working which is very poor requirement for OOB.

Yeah, indeed. And most of us have been stuck in the "omfg, the router is crashing and I'm in a hotel 2000km away, with crap OOB access, FML" situation more than once. Nick

I like feature list you posted, btw. If there were any console servers out there with these features, I would buy a bunch of them.

Wouldn't a program such as "conserver" running on a linux box someplace potentially provide these (maybe with a little extra hackery)? We use that quite a bit. One interesting option is that it allows another person to also watch the console session. So, for example, I can give someone a console session while watching the progress of it. http://conserver.com/ In other words, combining some software on a cheapo box someplace can give many of those features with just about any hardware console server.

On Jan 31, 2012, at 1:11 AM, Saku Ytti wrote:

On (2012-01-30 11:08 -0500), Ray Soucy wrote:

...

What are people using for console servers these days? We've historically used retired routers with ASYNC ports, but it's time for an upgrade.

This is very very common thread, replaying couple times a year in various lists, with to my cursory look no new information between iterations.

I'd be more curious if people listed what do they think good console server should have, and if or not given model has them.

For me, required features are

- multiplexed connect to console port, console port should never, ever be busy, blocking. You don't want to find your most competent people blocked from accessing console, because 1st line is in lunch keeping the port busy.

+1 for conserver software as interface to existing terminal servers. It's a really awesome package with very nice capabilities built by operations folks for operations folks. It provides this ability and much more.

- console port output always buffered persistently (if devices crashes and burns, at least you have post-network-reachability logs puked in console stored, good for troubleshooting)

Conserver does this, too with the added advantage that the logs are stored on an independent box not likely affected by whatever caused the crash.

- IP address mappable to a console port. So that accessing device normally is 'ssh router' and via OOB 'ssh router.oob' no need to train people

How about normal is 'ssh device' and OOB is 'console device'? Conserver does that.

Nice to have

- Configuration import/export as ascii, from single place, so configuration backups are easy

There are other tools that do this, such as rancid. I'm not sure I see significant advantage to integrating it.

- DC PSU support, redundantly

- No moving parts

- TACACS+ support

- 3G support with IPSEC tunneling

- Some clean and well designed webUI

These get more into the hardware actually connecting to the console port, so they obviously aren't addressed by conserver. I believe that the MRV stuff has the first three covered. The web UI, well, clean/well designed is in the eye of the beholder, I suppose. I'm not overly impressed with any of the webUIs I've seen on any of these products. The 3G with IPSEC is a nice thought. I haven't seen anyone do that yet.

I also have to ask, why do we even need these? Why do we still get new gear with RS232 console only? Why only Cisco Nexus7k and SUP2T have seen the light? Dedicated management-plane separated from control-plane, so regardless of control-plane status, you can connect over ethernet to management-plane and copy images to control-plane, reset control-plane, check logs etc. Ethernet port is lot cheaper than RS232 port, so OOB gear would be cheaper.

I hink there are a few reasons. First, for all its failings, RS-232 is dirt-simple and extremely reliable without any configuration or external dependencies. Unless the box is a complete brick, the RS-232 console port probably works, or, at least works once the box is power- cycled. Ethernet, even ethernet on a dedicated management plane still depends on a lot of things outside of the ethernet chip. It needs configuration (whether DHCP or configuration file) and additional support hardware. Yes, much of this has become cheaper than UART/driver chipsets, but, cheaper doesn't necessarily mean more rock-solid reliable.

RS232 console on control-plane is ridiculously useless, you cannot copy images over it (even if supported, images are several hundreds megabytes). It is completely dependant on control-plane working which is very poor requirement for OOB.

I agree that RS232 on a management plane would be a better choice. Personally, I like the idea of having both RS232 and ethernet on dedicated management plane. The RS232 allows you to deal with failures on the ethernet and the ethernet provides support for image transfers, etc.

When 50bucks intel desktop mobo has proper OOB, why does not every router and switch have?

I will point out that the intel mobo OOB has not completely eliminated the need for IPKVM in the datacenter. YMMV. Owen

On Jan 31, 2012, at 11:32 PM, Saku Ytti wrote:

On (2012-01-31 11:09 -0800), Owen DeLong wrote:

...

...

- IP address mappable to a console port. So that accessing device normally is 'ssh router' and via OOB 'ssh router.oob' no need to train people

How about normal is 'ssh device' and OOB is 'console device'?

Home-baked systems are certainly good option to many, but for some of us it means we need to either hire worker to design, acquire, build and support them or consultant. And as you can find devices which support above requirements (opengear) TCO for us is simply just lower to buy one ready.

I would hardly call conserver software a home-baked solution unless you'd also call anything based on OSS a "home-baked solution". You'd have to configure the tserv, ssh, and/or DNS in order to achieve ssh device.oob, and you have to configure the tserv and the conserver software in order to achieve what I suggested.

'console device' is what we do today, which is script someone needs to maintain (it picks up from DNS TXT records OOB and port where to connect).

If you use the conserver software, console isn't a script someone needs to maintain, it's the client portion of the conserver software package.

I prefer giving each port an IP and just use it via ssh (at least cyclades and opengear do this), if you are brave you could even setup same IP address for console and on-band loop, but I found that to be suboptimal, as you sometimes want to connect to OOB even when on-band is working.

This takes away several of the other features from your list however, that are implemented using the conserver software.

...

I agree that RS232 on a management plane would be a better choice. Personally, I like the idea of having both RS232 and ethernet on dedicated management plane. The RS232 allows you to deal with failures on the ethernet and the ethernet provides support for image transfers, etc.

You can get that from Nexus7k and Sup7. I wouldn't use the RS232 at all myself. Probably it's easier to sell this at day1 with RS232 port, as it is required in many RFPs and when everyone has migrated to ethernet OOB, phase-out RS232. So people please add to your 'nice to have' requirements in RFP, proper OOB :). (Can't tell how many times we've had to power-cycle CSCO or JNPR due to control-plane console not responding)

I've never seen a case where the control plane console failed to respond and I didn't need to reboot the router to bring the control-plane back to life anyway. It's not like a router can (usefully) continue for very long with a dead/locked-up control plane.

...

I will point out that the intel mobo OOB has not completely eliminated the need for IPKVM in the datacenter. YMMV.

This is bit drifting on the subject, but what are you missing specifically? You get VNC KVM, all the way from boot to bios, to GUI or CLI. You also get IDE redirection, to boot the remote box from your laptop CDROM. And you get API to automatically install factory fresh boxes without ever touching the boxes.

Only so long as the BIOS doesn't lose its mind which happens with some unfortunate regularity. With a good IPKVM such as the Raritans, I get everything you just described with the added advantage of still being able to connect to a server when it's BIOS has lost its mind. As nice as those devices sound, they still have some failure modes that stop short of being my ideal OOB solution. Owen

On Feb 1, 2012, at 9:24 AM, Saku Ytti wrote:

On (2012-02-01 09:07 -0800), Owen DeLong wrote:

...

I would hardly call conserver software a home-baked solution unless you'd also call anything based on OSS a "home-baked solution".

Home-baked, i.e. it's not product you can get shipped and it'll work out of the box and you have organization supporting it. The shipping solutions are really nothing else than embedded linux running conserver or equivalent, opengear even gives many of their oftware for free. It's certainly not difficult to roll one yourself, but for many of us, TCO is lot more than just buying opengear.

It's a product you can download, compile, configure and it works out of the box. It is pretty well supported by the authors and they have been very responsive to each and every question/feature/other request I have made to them, no matter how stupid. In fact, it has been better supported in my experience than most boxed software. conserver doesn't replace the opengear products, it's a software package that sits next to them and provides increased functionality of the type you suggested would be desirable. It's no more difficult to configure conserver than to set up the DNS to do what you were suggesting with SSH.

...

This takes away several of the other features from your list however, that are implemented using the conserver software.

The required list is satisfied by multiple offerings, including giving IP address to console port. So there are products in the market doing exactly what I want at cost which I'd be hard to reproduce even if I calculate my time as free.

I think you are misunderstanding and thinking I propose conserver as a replacement for MRV/Cyclades/etc. I do not. I propose it as a way to get most of the features you wanted that aren't present in those boxes by adding it to them. It has the additional advantage that it can provide the same functionality transparently across a wide variety of tserv hardware so that you can use multiple manufacturers over time and keep that transparent for the most part.

...

I've never seen a case where the control plane console failed to respond and I didn't need to reboot the router to bring the control-plane back to life anyway. It's not like a router can (usefully) continue for very long with a dead/locked-up control plane.

Lot of people don't have way to remotely power cycle devices, if OOB is separate management-plane, you can power cycle control-plane remotely. It's probably <50USD BOM addition to list price, which server guys have enjoyed for over decade and Cisco has been trying to introduce to networking guys.

Agreed. Nonetheless, power cycling the box vs. power cycling the control plane isn't a huge difference from my perspective.

...

Only so long as the BIOS doesn't lose its mind which happens with some unfortunate regularity. With a good IPKVM such as the Raritans, I get

If you can access BIOS from console, you can access it via vPRO/AMT. If you run into more exotic problem, it's cheaper just to swap that 50<100usd motherboard than to investigate what happened.

Tell me that again when your device looses it's mind and the vPRO/AMT doesn't come up with a workable IP address. RS-232 does NOT have this problem. Owen

Once upon a time, Owen DeLong <owen@delong.com> said:

I would hardly call conserver software a home-baked solution unless you'd also call anything based on OSS a "home-baked solution".

Console server hardware: buy appliance, plug it in, set password/IP Home-baked box: buy server (or buy parts and assemble), buy a serial card (make sure it is supported by Linux/BSD distribution of choice), install/configure OS, install/configure console server software Which one is worth my company's time for me to install? If you are going to install and maintain hundreds of them, the second might come out ahead eventually (assuming you script the install/configure steps), but the first is going to win almost all the time. I build stuff for personal use, but at work, we look for canned solutions to most needs. I have a couple of Linux firewalls where I wanted some extra flexibility, but we've got an Avocent console server (of course, Avocent is also a customer, and it is good to give a customer a little business). -- Chris Adams <cmadams@hiwaay.net> Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.

We use WTI, too, just don't like it that it reboots to apply a change. Frank -----Original Message----- From: Christopher O'Brien [mailto:obriapqz@bc.edu] Sent: Wednesday, February 01, 2012 9:59 AM To: nanog@nanog.org Subject: Re: Console Server Recommendation On 1/30/12 11:08 AM, Ray Soucy wrote:

What are people using for console servers these days? We've historically used retired routers with ASYNC ports, but it's time for an upgrade.

OpenGear seems to have some nice stuff, anyone else?

I've been using Western Telematic TSM-40 console servers and have been very happy with the price point and feature set. Also, I aggregate console connections from different parts of my campus over my existing fiber plant using TC Communications TC1880 Async Fiber MUXs. This combination has served me well.