in the course of my ccie study -- i've grown tired of using a single console cable and moving it between the 10 devices in my rack every time i needed to make a change. i've seen a lot of ccie "kits" for sale that include a cisco console server ( 2511 or a nm16a or nm32a inside of a modular router). since i haven't purchased a kit but have put one together through spare pieces i could find, i need to either (a) fork over a lot of money to put together a cisco console server from parts on ebay or (b) roll my own for a lot less money. i'm cheap -- i chose the latter.
to do this -- i purchased (14) usb-to-serial adapters (at ~$5 each from monoprice), (4) 4-port usb hubs, and enough console cables to cable everything up.
to start, i spun up an ubuntu virtual machine on a spare laptop. i installed 'securecrt' (i have a multiplatform license) and a program called 'ser2net'. after that -- all i had to do was install the usb-to-serial adapters, configure 'ser2net', and lab everything up.
the one interesting piece is that linux (unlike windows) doesn't have persistent rules around port numbering. in one regard, its nice; i can plug my adapter into any serial port and it will be assigned '/dev/ttyUSB0'. on the other hand -- when i'm connecting 14 adapters to unique devices that need to always be mapped the same way, it creates an issue. enter udev rules.
without getting into a technical discussion, for the purpose of this, udev is just a way to map a discovered device to a certain device name or alias. for this purpose, we want to map the usb bus-id to a certain '/dev/ttyUSB' number.
we start by plugging the device into the computer and ensure that its connected to the virtual machine. dmesg is your friend here.
the above shows that a new usb-to-serial adapter was plugged in to usb bus-id 2-2.7.6. its important to either write down or edit the udev rules as you add each device. for this -- i created a udev rule called 99-usb-serial-rules and placed it into /etc/udev/rules.d/
in the udev ruleset -- you have to define criteria to match on. this can be serial number, manufacturer id, model number, or any other unique criteria. the issue is that the usb-to-serial adapters i've purchased are all the same and don't contain a serial number. because i've had to match on usb bus-id, my ruleset looks like the following
this ensures each time the adapters are removed, they will be given the same device numbering. even if a different adapter is placed into this location (i.e. say you swap the adapters around), it the adapter number is tied to the usb port that you plug it in to. in this regard, this emulates typical windows behaviour.
finally -- after the usb adapters are created to be persistent, you just need to edit the file /etc/ser2net.conf to make use of the adapters. ser2net is a program that allows direct telnet to a serial adapter over a network, much the same way that reverse telnet works on a cisco terminal server. i simply define a port and some configuration settings and the device is then available to be accessed over the network. the '600' number defines the number of inactive seconds before the connection times out -- its recommended to keep this at a non-zero number to prevent having to manually clear the sessions after you disconnect.
with the above configuration -- if i telnet to this virtual machine on port 2014, i will be given direct access to /dev/ttyUSB13 and whatever is attached to this serial port. because i have given the port the configuration of a cisco console port and will attach it to one, i will see no differences between this "console" connection and a direct attachment to my pc.
once the configuration is modified -- we just need to restart the ser2net service.
thats it. now we can just create sessions using secure-crt, putty, or whatever terminal program you use to access these devices.
additionally -- i can use x11 forwarding from the linux vm to another computer running x11 and bring secure-crt to my desktop. however -- this is much slower than direct telnet using ser2net.
[edited 7 april 2013]
while i should have known this -- i didn't realize it until it was too late.
because vmware workstation 'muffles' the actual usb bus-id from the o/s -- you can't keep the devices persistently named without some identifier (serial, etc). because of this, i converted the windows installation into an xbuntu install using wubi. the process above works correctly in this instance. i am going to see if there is a way to accomplish this in vmware, though it may take a back burner with my ccie studies.
q.
ReplyDeletenice posting and very affordable price every person to buy rdp if you want o know more about our services so visit our official site