Here are two clues that will help you plan for installing the new Dell server families.
They seem to be great servers... lots of capacity for RAM, lots of CPU strength, and I love the rack mounting rail system. I also like the iDRAC service processors.
What's not to like? The back of the chassis is too thick (or the DE9 console port is recessed too far). Either way, most of the serial console adapters (DE9 to RJ45) won't fit well, and provide reliable connections, unless you grind down the cases of the adapters. And, since the adapter vendors don't offer to sell you a "trimmed" version, that job is going to cost you extra, somehow. Hey, maybe we can get the intern to do it? ;-)
I'm *really* glad that the serial consoles are still on the back of the servers, but if you are going to put them there, it seems to me that making the serial adapters fit should be part of the plan to have them on the server.
The one adapter I've found that works on the R620 series servers is from Cyclades (ADB0036). Yes, you can still get them from CDW. Fortunately, our latest batch went into racks with Cyclades TS2000. But, I did need to modify SO MANY of the Lantronix adapters that I made a custom jig for a Dremel router, to get consistent results.
Clue number two: On the R620, ttyS0 goes tot he iDRAC, and ttyS1 goes to the DE9 on the rear of the server. You will need to start an agetty for BOTH of these, if you want to be able to use both of them.
My other big projects are nearly done, and I plan to post much more often this summer. Thanks for reading.
Showing posts with label Lantronix. Show all posts
Showing posts with label Lantronix. Show all posts
20101231
Ring out the old? Serial Consoles STILL going strong!
The last couple of weeks have been very busy, helping acquire a small company for a customer. The majority of my role included assessing, and then upgrading the network gear, as well as helping with the various server gear.
After the initial assessment, I installed Conserver on a local host, and I re-deployed a Cisco 3640 with a pair of NM-32A asynch modules. The serial consoles were VITAL to take over network gear for which the previous administrator could offer no admin credentials. Some of the network gear was also equipment with older operating software, which I had little experience with, so I needed to engage technical help from the equipment vendor. The first two questions were always "Can we do a remote desktop conference?" and "Do you have access to the serial console?" It's always nice to be able to answer "yes" to both questions. There is also some comfort in knowing that Conserver will be logging the session, so you can look back over the logs after the fact to review what happened.
During this session, I was also working with some Juniper gear, and I'm REALLY happy that Juniper also use the RJ45 wiring schema that Cisco uses. I'm a big fan of that symmetrical wiring format.
It's worth noting that SUN Microsystems newer machines (starting back with the Netra T-1) have also used this wiring schema for their TTYs0, and some Lantronix console servers have also used the wiring schema. Opengear has made this wiring schema an option for many of their products, and it is becoming the primary wiring format for some of their newest products. This makes hooking up the majority of the equipment that I work simple, AND it gives me some flexibility to choose different hardware vendors with confidence that they will drop into my existing infrastructure nicely.
Finally, I wanted to point out that serial port capability is also still being built into embedded processors! I've had some time to hack with the ATMEL processors used in the Arduino family of development boards. One port is normally integrated with a bootloader and connected to a USB interface (typically with an FTDI interface chip) to make it easy to talk to the processor. However, these 3.3-to-5 volt "TTL" interfaces can also be tied to an RS-232 interface chip when the ATMEL chip is plugged into an embedded system. (As an alternative, there is another pair of pins which can be a data-only 9600 bps (max) serial port to communicate between the ATMEL chip an another device. And the larger ATMEGA actually has 3 extra serial ports available!) My newest project is to make a small processor which can communicate via a serial interface to another system.
As we enter 2011, the venerable RS-232 serial interface lives on. I wish you all health and happiness, and hopefully a bit of prosperity as well.
-Z-
After the initial assessment, I installed Conserver on a local host, and I re-deployed a Cisco 3640 with a pair of NM-32A asynch modules. The serial consoles were VITAL to take over network gear for which the previous administrator could offer no admin credentials. Some of the network gear was also equipment with older operating software, which I had little experience with, so I needed to engage technical help from the equipment vendor. The first two questions were always "Can we do a remote desktop conference?" and "Do you have access to the serial console?" It's always nice to be able to answer "yes" to both questions. There is also some comfort in knowing that Conserver will be logging the session, so you can look back over the logs after the fact to review what happened.
During this session, I was also working with some Juniper gear, and I'm REALLY happy that Juniper also use the RJ45 wiring schema that Cisco uses. I'm a big fan of that symmetrical wiring format.
It's worth noting that SUN Microsystems newer machines (starting back with the Netra T-1) have also used this wiring schema for their TTYs0, and some Lantronix console servers have also used the wiring schema. Opengear has made this wiring schema an option for many of their products, and it is becoming the primary wiring format for some of their newest products. This makes hooking up the majority of the equipment that I work simple, AND it gives me some flexibility to choose different hardware vendors with confidence that they will drop into my existing infrastructure nicely.
Finally, I wanted to point out that serial port capability is also still being built into embedded processors! I've had some time to hack with the ATMEL processors used in the Arduino family of development boards. One port is normally integrated with a bootloader and connected to a USB interface (typically with an FTDI interface chip) to make it easy to talk to the processor. However, these 3.3-to-5 volt "TTL" interfaces can also be tied to an RS-232 interface chip when the ATMEL chip is plugged into an embedded system. (As an alternative, there is another pair of pins which can be a data-only 9600 bps (max) serial port to communicate between the ATMEL chip an another device. And the larger ATMEGA actually has 3 extra serial ports available!) My newest project is to make a small processor which can communicate via a serial interface to another system.
As we enter 2011, the venerable RS-232 serial interface lives on. I wish you all health and happiness, and hopefully a bit of prosperity as well.
-Z-
20071023
Whether we need DCD more than symetry
I'm very much in favor of a symmetrical RJ45 wiring schema for console servers, because it could minimize how many adapters I would need to stock. The advantages of a symmetrical pinout include using a simple 'rolled' cable to make a 'null-modem' connection between devices and adapters.
Now, I'm not picking any particular vendors wiring scheme as 'the best'. I'm espousing symmetry as the 'best way'. The problem is, this means having two Signal Ground pins, which usually means that DCD won't have a pin. (On an 8-wire RJ45 interface, you would have two ground leads, two data leads, two hardware flow control leads, and two hardware handshaking leads.)
Remember that today's Console Server has its roots in yesteryears Terminal Servers. The old TS used modems or terminals, to let remote users connect to hosts across the network. The hardware handshaking was used by the terminals to indicate if they were connected. With modems, they could be connected and powered, but it was DCD signals from the modem to the TS which told the TS whether an interface was 'on-line' with a remote user.
But, these days in console service, modems are a pretty rare thing. Still, I'll be the first to recognize that modems could be used to dial into a remote site and try to connect when the main WAN links are down. However, you can configure most modems to toggle the DSR lead to reflect the status of DCD, and you can configure most console servers to recognize the DSR lead as a signal that the device isn't ready. (So, I don't think we really need DCD in console service. I'll leave Dial-up Networking for later article.)
If you look at my Signals Page, in the RJ45 section, you'll notice that there are already a couple of symmetrical pinout schemes. But you can also see the wide variety of combinations that I've found so far. While pin 4 seems to be the most common pin for signal ground, its clear that not everyone uses pin for for the signal ground. That makes it harder to make an RJ45 signal tracer that works in all cases, so there is less incentive for a vendor to take on that project.
So, for the existing symmetrical RJ45 pinouts on my signals page, you'll notice that they use pins 4 and 5 as ground pins. Data pins are on pins 3 and 6. Handshaking is on pins 2 and 7, and flow control are on pins 1 and 8.
If you're asking "why can't we use pin 5 for DCD?", then you may not have thought about the issue deeply. The first problem comes when you use a rolled cable as a null modem, and you now connect two devices signal leads, but not their signal ground pins! You'll be replying on the chassis ground connections to provide the signal reference. Using these console servers in large data centers means that you may be connecting devices on different phases of the AC circuit, or even across two different Power Distrubtion Units (PDUs) or Uninterruptible Power Supplies (UPSs). The result could be burned out serial ports on your console server and the attached devices, or more sever damage to the units.
So, to summarize the vendors I know about today;
Symmetrical, with 2 grounds (9+ of 26):
Cisco, Logical Solutions SCS, Lantronics SCS-1600, Digi PortServer II, Xyplex 1600/1800, iTouch/MRV in-Reach lines, Juniper Networks (J-series devices, and many NetScreen devices), Server Technology CDU consoles, and Sun Microsystems console/TTY ports
Symmetrical, except for 1 ground and DCD (3 of 26):
Digi CM, Digi STS-1610, Opengear CM
Of the 27 console connections I've documented, 15 use pin 4 for ground, and 9 use pin 6 for ground. (Keep that in mind if you are making your own RJ45 signal tracers.) And of the 9 symmetrical pinouts, eight of them use pins 4 and 5 for ground, and one uses pin6 3 and 6.
It seems to me that other vendors (who are not making console servers) have been choosing the Cisco wiring scheme (Juniper, Sun, Server Technology). Lantronix picked the null-modem compliment to the Cisco pinout. Those choices have been good for me, since it simplifies some of the deployments that I work on. It's interesting to note that the Xyplex/iTouch/MRV pinouts are almost identical, except that pins 1 and 8 (the flow control leads) are inverted from the Cisco schema. (So, if you don't care about flow control, you can mix-and-match these devices with the Cisco-schema cousins.)
I'm under the impression that some vendors are considering adopting a different wiring scheme for their future product series. I'd strongly urge that they consider adopting a symmetrical schema, and I'd also strongly encourage them to consider using an existing schema, rather than trying to come up with a unique schema. And I'm always interested in discussing it in person, though an email on the topic is also welcome.
Now, I'm not picking any particular vendors wiring scheme as 'the best'. I'm espousing symmetry as the 'best way'. The problem is, this means having two Signal Ground pins, which usually means that DCD won't have a pin. (On an 8-wire RJ45 interface, you would have two ground leads, two data leads, two hardware flow control leads, and two hardware handshaking leads.)
Remember that today's Console Server has its roots in yesteryears Terminal Servers. The old TS used modems or terminals, to let remote users connect to hosts across the network. The hardware handshaking was used by the terminals to indicate if they were connected. With modems, they could be connected and powered, but it was DCD signals from the modem to the TS which told the TS whether an interface was 'on-line' with a remote user.
But, these days in console service, modems are a pretty rare thing. Still, I'll be the first to recognize that modems could be used to dial into a remote site and try to connect when the main WAN links are down. However, you can configure most modems to toggle the DSR lead to reflect the status of DCD, and you can configure most console servers to recognize the DSR lead as a signal that the device isn't ready. (So, I don't think we really need DCD in console service. I'll leave Dial-up Networking for later article.)
If you look at my Signals Page, in the RJ45 section, you'll notice that there are already a couple of symmetrical pinout schemes. But you can also see the wide variety of combinations that I've found so far. While pin 4 seems to be the most common pin for signal ground, its clear that not everyone uses pin for for the signal ground. That makes it harder to make an RJ45 signal tracer that works in all cases, so there is less incentive for a vendor to take on that project.
So, for the existing symmetrical RJ45 pinouts on my signals page, you'll notice that they use pins 4 and 5 as ground pins. Data pins are on pins 3 and 6. Handshaking is on pins 2 and 7, and flow control are on pins 1 and 8.
If you're asking "why can't we use pin 5 for DCD?", then you may not have thought about the issue deeply. The first problem comes when you use a rolled cable as a null modem, and you now connect two devices signal leads, but not their signal ground pins! You'll be replying on the chassis ground connections to provide the signal reference. Using these console servers in large data centers means that you may be connecting devices on different phases of the AC circuit, or even across two different Power Distrubtion Units (PDUs) or Uninterruptible Power Supplies (UPSs). The result could be burned out serial ports on your console server and the attached devices, or more sever damage to the units.
So, to summarize the vendors I know about today;
Symmetrical, with 2 grounds (9+ of 26):
Cisco, Logical Solutions SCS, Lantronics SCS-1600, Digi PortServer II, Xyplex 1600/1800, iTouch/MRV in-Reach lines, Juniper Networks (J-series devices, and many NetScreen devices), Server Technology CDU consoles, and Sun Microsystems console/TTY ports
Symmetrical, except for 1 ground and DCD (3 of 26):
Digi CM, Digi STS-1610, Opengear CM
Of the 27 console connections I've documented, 15 use pin 4 for ground, and 9 use pin 6 for ground. (Keep that in mind if you are making your own RJ45 signal tracers.) And of the 9 symmetrical pinouts, eight of them use pins 4 and 5 for ground, and one uses pin6 3 and 6.
It seems to me that other vendors (who are not making console servers) have been choosing the Cisco wiring scheme (Juniper, Sun, Server Technology). Lantronix picked the null-modem compliment to the Cisco pinout. Those choices have been good for me, since it simplifies some of the deployments that I work on. It's interesting to note that the Xyplex/iTouch/MRV pinouts are almost identical, except that pins 1 and 8 (the flow control leads) are inverted from the Cisco schema. (So, if you don't care about flow control, you can mix-and-match these devices with the Cisco-schema cousins.)
I'm under the impression that some vendors are considering adopting a different wiring scheme for their future product series. I'd strongly urge that they consider adopting a symmetrical schema, and I'd also strongly encourage them to consider using an existing schema, rather than trying to come up with a unique schema. And I'm always interested in discussing it in person, though an email on the topic is also welcome.
Subscribe to:
Posts (Atom)