7

These best practices espouse having a dedicated physical console connection to network equipment for management. Assuming your device is within RS232 range of your management workstation, this would likely mean connecting to your devices' RS232 console ports over structured UTP already in place.

I have a collection of three current Cisco devices all within RS232 range of my management workstation. Their RS232 console ports are not all the same, however:

Device      Console Connector
======      =================
ASA5505     RJ45 Jack
SG500X      DE9 Male
SG300       DE9 Male

Of course, it is trivial to connect to the RJ45 console port using structured ethernet cabling. When you do that, you end up with the following RS232 signal map to your UTP:

enter image description here

As for the DE9 console ports, the only standard to connect RS232 over RJ45-terminated UTP seems to be TIA-561 (aka RS-232D). When you do that, you end up with the following RS232 signal map to your UTP:

enter image description here

As you can see this results in RS232 signals on the UTP that are different for the different console port types -- and this is with a collection of just three current devices from a single vendor.

While I'm sure I could document this and make sure all admins have just the right cables/adapters available to make a successful connection it seems unnecessarily error-prone. Particularly since the console connection is often used only as a backup during stressful periods when other methods of connecting to the device have already failed.

Ideally, all RS232 on the structured cabling would follow the same pinout. I can force everything to follow TIA-561 with custom adapters at each device and workstation, but I've never seen that done anywhere else. Is there a good way to standardize RS232 over RJ45 pinouts?

4
  • 3
    Both you and Fred imply that OOB doesn't need testing, it seems awfully common that OOB does not actually work when you need it. I believe that there is no point even installing OOB, unless you have automatic and periodic testing, we use script to login to the devices every 3h via OOB, if login fails alarm is raised. Personally, I'd normalize the port (DB or RJ45) pinout (we normalize to Cisco pinout, at both JNPR+CSCO support it, so it's least work for our environment), so straight CAT5 works always. And I'd use existing CAT5 infra.
    – ytti
    Commented Oct 20, 2013 at 13:58
  • Did any answer help you? if so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you could provide and accept your own answer.
    – Ron Maupin
    Commented Aug 8, 2017 at 14:44
  • @RonMaupin Not really. It's still unclear to me what a good way to do this is.
    – alx9r
    Commented Aug 8, 2017 at 14:48
  • OK. I'm just trying to see if we can clean up some old open questions. One thing to consider, based on experience and the Cisco documentation, is that the RS232 from the console ports is very limited in the distance over which it works. It usually tops out at about 25' (cable distance, not total distance). I set something up with standard UTP cables, and just plugged the Cisco cables (they come with every device, so there are usually dozens laying around) in one end.
    – Ron Maupin
    Commented Aug 8, 2017 at 14:53

1 Answer 1

2

I cannot speak for anyone else but I do a TOR 8 to 16 port 'terminal server' that is connected to a management Ethernet, we do not try to use the structured cable to bring them to a central set of terminal servers. We then test as part of the turn up. We also home run the cables, as it is less likely that someone will disconnect one in error and you don't know that the cabling is wrong till you really need it.

Unless you have on site people you really trust, I would not try to save $$s on this.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.