|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |
From: Owen DeLong <owen@delong.com> In-Reply-To: <20120131091136.GA22047@pob.ytti.fi> Date: Tue, 31 Jan 2012 11:09:39 -0800 To: Saku Ytti <saku@ytti.fi> Cc: nanog@nanog.org Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org On Jan 31, 2012, at 1:11 AM, Saku Ytti wrote: > On (2012-01-30 11:08 -0500), Ray Soucy wrote: >=20 >> 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. >=20 > This is very very common thread, replaying couple times a year in = various > lists, with to my cursory look no new information between iterations. >=20 > 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. >=20 > For me, required features are >=20 > - 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. >=20 +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) >=20 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 >=20 How about normal is 'ssh device' and OOB is 'console device'? Conserver does that. > Nice to have >=20 > - Configuration import/export as ascii, from single place, so = configuration > backups are easy >=20 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 >=20 > - No moving parts >=20 > - TACACS+ support=20 >=20 > - 3G support with IPSEC tunneling >=20 > - Some clean and well designed webUI=20 >=20 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. >=20 >=20 > 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. >=20 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
|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |