Fruit Company Console: My Review of the Cisco Console Companion for iPad/iPhone

One of the major advantages to owning an iPad, or in some cases an iPhone, is that you have a mobile computer at your fingertips that is quite easy to carry around the datacenter or networking closet.  I have an iPad myself, and I find it very useful for documentation purposes.  Whether it be taking notes about the configuration of a specific device or looking up the PDF of a particular feature from Cisco’s website, the iPad has many uses.  However, if I find myself in need of connecting to a device such as a switch or a router, my iPad/iPhone options are limited.  I can use a telnet or SSH client to remote into the system, but if I don’t know the management IP or the username/password combination I can be sunk.  Or worse yet, if the switch has never been properly configured for remote access it becomes a moot point.  If I want to be able to use my trusty Cisco rollover console cable to get into the switch the old fashioned way, I have to lug out my behemoth Lenovo W701 laptop and get it ready, which can be quite an endeavor depending on the amount of room I have to work with or the amount of time that I’m going to spend consoled in, since my laptop has about 1.5 hours of battery life under the best of circumstances.  Add in the difficulties that I’ve faced with USB-to-serial adapters under Windows 7 64-bit and you can see why I’m reluctant to use the console.  However, there is hope for the best of these two worlds.

A company called Redpark has started selling a rollover cable with a 30-pin iDevice connector.  Engadget had a story about it HERE.  Naturally, I decided that I just had to have one of these.  You know…for work and stuff.  Anyway, I jumped right over to the Redpark website.  Hello sticker shock.  This baby is going to set you back a cool $69.  Add in more if you want shipping and handling (whatever that is), so expect to shell out about $80 to get it to your neck of the woods, more if you need to have one tomorrow.  That’s not all, folks!  Even if you do manage to get your hands on one of these little jewels, you still need an app to access the console.  Now those of you that looked at this excellent blog post by Ruhann about console access on a jailbroken iPad are all set.  The rest of us poor saps that haven’t jailbroken our iPads yet are in a bit of a lurch.  Fear not, because the company also has an official app on the App Store called Get Console (or Cisco Console Companion) that will give you console access.  For a measly $9.99.  After all, you’ve already spent $80 already, what’s a few dollars more?

Once my console cable arrived in the mail, I was a little underwhelmed by the packaging:

Not much to look at.  The contents of the box were even worse.  The console cable lovingly encased in bubble wrap, and this instruction sheet:

Bravo for making it straightforward and easy to read.  Off to the App Store to download my new app.  Except…”Cisco Console Companion” isn’t the official title of the app.  It’s “Get Console”, along with a big disclaimer that it is in no way associated with Cisco.  I’m guessing they had to use an alternate title in the app store because of some wonky trademark issues that Uncle John wasn’t too pleased about.  At any rate, it was a fast download and then I was off and running.

For the purposes of this test, I’m consoling into a Cisco Catalyst 3560 8-port switch.  Once I fired up the program, it popped up with a one-time reminder that it was only for Cisco devices and that it would check each device to ensure that it was a genuine Cisco product.  My best guess is this is there to prevent people from trying to use it as an Ethernet cable or something, because most reports I’ve seen says that it works just fine with any kind of device that uses a rollover cable, like Juniper, or HP, or what have you.  I didn’t test this out during my first run, but I will be testing it down the road of some of those devices.  Note that since it is an RJ-45 rollover cable, it can’t be used on RS-232 or null modem devices.  Oh well, time to upgrade those old switches anyway.  The cable itself feels rather thin, almost like a fiber patch cable rather than a flat rollover cable or even a UTP cable.  It’s about 6 feet long, so you don’t have to be right next to the device you’re trying to console into, but don’t expect to be programming from across the room.  Here’s a picture of the cable on top of my test switch:

My first encounter with the Get Console program led me to this screen:

Fairly utilitarian, but that’s fine by me.  I’m not really a “bells and whistles” kind of guy.  The bottom section of the screen is dominated by the on-screen keyboard, but that’s to be expected.  Just above that is a collapsible keyboard bar that lists some very useful control keys.  First is the all-important TAB key, which I’ve found sorely lacking on some of the telnet clients I’ve used.  TAB saves me a ton of time.  Next is the CTRL key, which when tapped toggles on and allows you to use CTRL+ shortcuts for moving around the command line or sending a CTRL+C or CTRL+Z to end.  Next is the BRK key, which sends an immediate break signal to the console.  Useful for those times when you need to enter ROMMON on bootup.  Next is everyone’s favorite question mark key.  Having it here is really helpful so that I don’t have to waste a keystroke getting to the number/symbol keyboard on the iPad.  This is followed by the up and down error keys, which are used to cycle through your command history forward and backward.  Lastly is a Return key, which I didn’t really use, since the iPad keyboard has one built in.

The upper right corner of the app replicates many of the same keys as the collapsible keyboard, along with a paper clip icon.  When you tap this, it pulls out a drawer that contains the contents of the clipboard.  You can paste those contents directly onto the command line.  So if you find yourself typing the same commands in over and over, this is a handy shortcut (there are others we’ll get to in a second).  As a quick note, while you can type in this clipboard, if you don’t copy the contents before pasting it will simply paste what was in the box before.  So be sure to copy before you paste.

The upper left includes the Settings button, the session button, the keyboard show/hide button, a button to show/hide the collapsible keyboard with the TAB and CTRL keys, and a file drawer for storing config files.  The settings button is very feature rich. You can choose to have the program automatically connect when it launches or wait for you to connect manually.  There are also settings to change the baud rate and stop bits, which really helps when you are connecting to some non-standard gear.  You can have the system log all of your console sessions, which can be stored in the filing cabinet for later examination.  You can change the number of columns and rows, as well as the amount of scrollback in the window.  Be aware that adding too many columns will mean you need to scroll the screen left or right to see the output, as it looks like the main window is about 80 columns wide.  You can change the bell that dings when you do something you aren’t supposed to, as well as changing the color scheme to something other than white-on-black text.  The font size slider doesn’t correspond to actual point sizes, so you might need to play around with it to find a comfortable setting.

The session button allows you to disconnect a console session manually as well as offering one of the added benefits of this program.  By signing up at http://www.get-console.com, you can add an option under settings to connect to a remote console server at that website.  You can then tap the session button and obtain a 7-digit access code that allows someone to access your console session from the Get Console webpage.  This is fairly handy if you have a junior administrator on site and need to walk them through a configuration.  Or if that same junior admin is in a network that is down, you can use a 3G iPad to connect to their console session and do some troubleshooting.  I had to play around with the settings in order to test this feature.  It looks like the app connects to the remote console server when you choose to share the session, and the access code allows the user on the website to connect in like a type of reverse telnet connection.  I couldn’t get the app to connect using the North America servers, but the Europe and Asia servers worked just fine.  However, the latency on these connections was pitiful.  Redraw on my screen could be measured in seconds.  I tried entering some commands on the webpage, but careful typing was enough to overrun the keyboard buffer for the app.  And if you’re going to try and look at live debugs, you might as well forget about it.  By the time you could send a break or “un all”, you’d be swamped in messages.  Better to use the web app as a mirroring device for training or for simple troubleshooting.  You can also choose to encrypt the sessions if you want, which is a pretty good idea if you don’t want everyone on the Internet up in your business.

The filing cabinet is another interesting piece.  By uploading configs to the Get Console website, you can store them in your filing cabinet to copy onto the device locally.  That way, if you have a template for your switches, you don’t need to worry about copying and pasting it out of an e-mail, where it may get buggered up by some strange formatting issues.  You can also have those pesky junior admins share an account and copy the configs to the filing cabinet for them, so all they have to do is walk out and plug in to setup the switch with enough config for you to be able to telnet to it.  There is local shortcut storage as well, so you can keep some of your more clever commands on your own iPad safe from those that could use them to do harm.  You can also store console logs for later upload or email.

Out of the box, the font size was downright tiny.  I had to bump the slider up to about 3/4ths of the way just to read it comfortably, and I was holding the iPad less than a foot from my face.  The keyboard was quite responsive, and the scrolling of the information was smooth and easy to follow.  The app is setup to beep at you when you try to use a key that isn’t supported, such as a down arrow at the prompt when there are no more commands to replay.  This feature is nice because it gives some feedback so you know when you’re beating your head against a brick wall.

In case you’re curious, this app is universal for both iPad and iPhone/iPod Touch.  But other than just glancing at the console I’m not sure how useful it’s going to be.  There isn’t much screen real estate to start with, and all the extra pieces don’t give you much room to look at things.  Here’s a screen shot to give you and idea of what I’m talking about:

Tom’s Take

It all comes down to money.  Is there enough utility in this cable and app for you to justify spending $100 on it?  Do you often find yourself in a network room with only your iPad and a switch that won’t respond to any other method of input?  I wouldn’t dream of trying to do any kind of heavy duty debugging on this device.  I’d rather have my full laptop with multiple apps and notepad windows to drag around to interpret console spam.  As well, any kind of programming that would require lots of time at the keyboard would probably get uncomfortable after a while, unless you’re one of those people that happens to like typing on the iPad on-screen keyboard.  I suppose you could haul along a wireless keyboard, but at that point you’re dragging along an awful lot of devices for simple console access.

I could see this being a useful tool for training or for an emergency tool kit.  Throw an iPad and a cable in your kit and you have instant access to the console of a device from anywhere in the world.  You could send the less-skilled network admins out on site and a more senior person could stay in the office and do some simple troubleshooting or configuration in order to get to the equipment through SSH or telnet.  The web piece, in my mind, is just too unresponsive to spend a lot of time on.  Plus, if you are fast typist like I am, you’re going to get rather frustrated with the delay in command execution, if you don’t outright lock the system up with all the characters you’re throwing at it.

The app does what it says, there’s no denying that.  I find it very useful to have on my iPad and I’ll probably use it going forward for many of my walkthroughs and audits.  However, I think the $100 price tag is a little steep for something like this.  I hope that the price of the console cable will come down at some point, because $69 dollars for this is a bit of a stretch, even by Apple standards.  If there is enough demand, we may even see some other vendors get into the market and offer something like this.  If that happens, hopefully the Get Console people will support them as well.  I had hoped that maybe the software people could offer a gift card with the purchase of the cable, but I believe that they are two different companies so that’s probably out of the question.  Redpark could always throw in a $10 iTunes gift card if the want to soften the blow of needing the additional app to use the cable, but marketing isn’t my department.

All in all, I think I’m going to be able to find some use out of this app.  However, you really need to think twice about whether or not a C-note is worth giving up for this type of functionality.  If you want to learn more about these products, you can check out the console cable at http://redpark.myshopify.com/products/console-cable and you can check out the software program at http://www.get-console.com/

When Is A Trunk Not A Trunk?

When I was an impressionable youth back in my college years, I decided it might be a good idea to take Japanese as a foreign language.  I spent three semesters learning vocabulary and kanji and eventually managed to forget pretty much everything I learned.  One lesson that did stick with me, however, occurred in my first semester.  Our professor was explaining to us gaijins (Westerners) that we needed to be very careful about how we pronounced certain words.  Since words in Japanese are limited by a very small number of vowel sounds, there are many cases were words use the same sounds but have totally different meanings.  Such is the case with shujin. When pronounced as I have written it, it is the word for “husband”.  However, if you hold the “u” sound a little too long, as in shuujin, you instead have referred to that person as a “prisoner”.  As my professor explained, “Well, perhaps those two words really aren’t so different.”  In this case, a small difference in pronunciation can have a profound difference in meaning.

Another place where I see an issue similar to this is when someone starts asking questions about terminology differences between HP Networking (nee Procurve) and Cisco terminology on switches.  Often, these questions boil down to two major terminology differences based around one word: trunk.  It’s pronounced the same in both vendors world, but just like in Japanese, it can have a very different meaning depending on how it’s used.  Allow me to illustrate:

In Ciscoland, when I use the term trunk, I am referring to a port that carries multiple VLANs.  Trunk ports carry information about each of the VLANs on the switch in either Cisco’s ISL proprietary format or in the 802.1q vendor-neutral format.  Newer switches, like the 2960, have no support for ISL and will only form trunks using 802.1q, so I’ll use 802.1q for my examples.  Just keep in mind that if the switch doesn’t support ISL, you don’t need to configure the trunk encapsulation.  When these ports are designated as “trunks”, the frames are tagged with a special 802.1q header that indicates which VLAN they are a part of.  The only VLAN that is not tagged with an 802.1q header (by default) is the native VLAN.  On Cisco equipment, the default native VLAN for an 802.1q trunk is VLAN 1.  The behavior of Cisco IOS is to transmit information about all VLANs present on the switch over the trunk.  You can narrow this behavior through use of the switchport trunk allowed vlan command.  A sample Cisco trunk config might look like this:

Switch(config)#interface gig 0/1
Switch(config-int)#switchport trunk encapsulation dot1q
Switch(config-int)#switchport trunk allowed vlan 1,10,99
Switch(config-int)#switchport mode trunk

This configuration is sufficient to setup an 802.1q trunk and only allow VLANs 1, 10, and 99 to pass traffic on it.

In HPvania, the terminology used for a port that carries multiple VLANs is a tagged port.  On an HP switch, the individual ports are rarely configured directly.  Instead, the VLAN itself is configured and the ports are added to the VLAN configuration.  In order to setup an access port, it is configured as an untagged member of the VLAN it needs to belong to.  Since HP does not support ISL trunking, the terminology is straight from 802.1q.  The untagged ports do not carry 802.1q headers that specify they VLAN information.  This would be known as an “access port” on a Cisco switch.  In order to create a port that carries information for multiple VLANs, we must “tag” those VLANs on that port.   This modifies the packets sent on that port to carry VLAN tags for the VLANs indicated.  A sample configuration for an HP switch connected to the above Cisco switch might look like this:

Switch(config)#vlan 1
Switch(config-vlan)#untagged 1
Switch(config-vlan)#untagged 48
Switch(config-vlan)#vlan 10
Switch(config-vlan)#tagged 48
Switch(config-vlan)#vlan 99
Switch(config-vlan)#tagged 48

Notice that the configuration is done under the VLAN and references the port number on the switch.  Access ports are untagged members of a particular VLAN, and the native VLAN of an 802.1q trunk is also an untagged member.  Even though 802.1q has a native VLAN that doesn’t carry a tag, on an HP switch this VLAN needs to be explicitly set.  The other VLANs must be tagged to the uplink port in order for their information to be carried between switches.  This lends itself to being an additive solution, where VLANs are only present on a trunk if they have been specifically configured.  There is no need to prune VLANs or exclude them from the trunk if they aren’t needed.  They just aren’t configured in the first place.

Which method is better?  This tends to devolve into an OSPF vs. IS-IS type of argument.  If you are more comfortable with one you tend to prefer it.  I tend to use the Cisco terminology in my day-to-day operations, and I have a slight preference for not needing to remember to add each individual VLAN to an uplink port.  However, from a security perspective, I do like the HP idea of only adding VLANs that are needed.  In fact, this same concept of VLAN creation is present in the Force10 OS.  If you’d like to see more of it in action, you should check out Stretch’s excellent intro to Force10 over on Packetlife.net.

So, if HP refers to an uplink carrying multiple VLANs are a tagged port, then does HP have a “trunk”?  In fact they do.  In HPvania, a trunk is a logical construct that aggregates multiple ports into one logical link.  For those of you that might be out there scratching your heads about this one, this means that when you “trunk” a group of ports on an HP switch, you are creating one LACP link from up to four individual ports.  This kind of configuration should look like this:

Switch(config)#trunk 19-24
Switch(config)#trk1
Switch(config-trk)#lacp
Switch(config-trk)#vlan 1
Swtich(config-vlan)#untagged trk1
Swtich(config-vlan)#vlan 10
Swtich(config-vlan)#tagged trk1
Swtich(config-vlan)#vlan 99
Swtich(config-vlan)#tagged trk1

Those of you that are fans of irony will appreciate that the above config sets up this LACP port aggregation to pass multiple VLANs to another switch.  In other words, we are configuring a Cisco “trunk” on top of an HP “trunk”.

In Ciscoland, the idea of aggregating multiple ports into a grouping is referred to by many names, usually “port channeling” or “Etherchanneling”.  The latter is the term that usually describes the Cisco-proprietary Port Aggregation Protocol (PAgP) links that are created by default.  However, this term has more or less become genericized and is used to refer to any group of aggregated ports on a Cisco switch.  Cisco does support LACP on aggregated ports, so let’s see how we’d configure this switch to use LACP and send tagged VLAN traffic back to the HP switch:

Switch(config)#interface range gi 0/19-24
Switch(config-int-range)#switchport trunk encapsulation dot1q
Switch(config-int-range)#switchport trunk allowed vlan 1,10,99
Switch(config-int-range)#switchport mode trunk
Switch(config-int-range)#channel-group 1 mode active
Switch(config-int-range)#channel-protocol lacp

This will set the aggregated ports to use LACP and pass VLANs across the link with 802.1q tags.  Note that you must set the channel-group command to “active” in order to use LACP on the link.  If you set it to “auto” or “desirable”, it will use PagP by default.  If you set the mode to “on”, it will not use LACP or PAgP at all.

There you have it.  The terminology is different, but as long as you know what you are trying to accomplish, you can usually figure out what you need to configure in order to make it all work correctly.  Hopefully you’ll never find yourself married to any particular configuration, much less become a prisoner of it.  In the end, just remember that a trunk is still just a trunk.  The meaning is entirely up to you.

Party like it’s 1993!

I was once told by a consultant that he could figure out whether a client needed his services after about 30 seconds at a router console.  When I asked how he could be so sure after such a short amount of time, he consoled to a router in his lab and typed in “show clock”.  The lab router returned the now-familiar string of Mar 1, 1993 (he’d just booted it).  As soon as he showed me that one command, it all made sense.  Keeping accurate time in a computer environment is very important to systems.  Directory structures depend on an accurate clock to authorize logins and track audit events.  Novell and Windows both utilize systems to ensure that the clocks of all the servers in the network are synchronized.  And if those clocks drift out of sync, heaven help the server admins.

What about network equipment?  In days past, the routers and switches were typically neglected when it came to clock setting.  In fact, most older Cisco routers didn’t even include an on-board battery to keep the clock accurate.  And when the router would reboot, the software clock didn’t have an accurate hardware clock to refer to, so it used 00:00 1 Mar 1993 as the reference point.  But as systems have increased in complexity over the past several years, the need to have all the time on your equipment accurate has become paramount.  When debugging a call hand-off on a voice gateway, an accurate router clock ensures that you can match the time the call was placed with the debug message output.  If there is a security incursion into your network devices, you need to track the time the device was accessed in order to be able to accurately report the event to the proper authorities.

So how do we get our network clocks to report the right time?  Well, the process is fairly easy, provided you’ve done a little homework about a couple of things.  First, you need to know what timezone you are in and what your GMT offset is.  In today’s world, it is far easier to keep the clock of your device synced to GMT, then apply an offset to show you what the local time is.  That way, if you have devices spread all over the world, you never have to worry about a significant time difference because one clock was synced to local time and the other was synced to GMT with an offset applied.  For the purposes of the examples in this post, I’m going to assume the router is located in the central United States and is in the Central Time Zone.  The fact that I myself am in the Central Time Zone and therefore would not need to do any additional thinking to write my examples is purely coincidental.

In the case of my example, the central United States is in the Central Standard Time Zone (CST).  CST is six hours behind the GMT clock (GMT -6).

When you first connect to the router, you will either see the default time of 00:00 1 Mar 1993 (for older routers), or if you’re on an ISR or newer router, it may be synced fairly close to the actual time.  Starting with the ISR, Cisco started keeping the time synced more closely when the router was shipped from the factory, and the battery keeping the hardware clock time when powered off seemed to last a lot longer.

At this point, we need to set the router’s timezone with this command:

R1(config)# clock timezone <name> <GMT offset>
R1(config)# clock timezone CST -6

Once you’ve done that, the system should update with a message telling you that the current time zone has been updated.  Now, the router should know what time zone it’s in and adjust the clock offset appropriately.  You should also set the daylight savings time conditions as well.  For those not familiar, DST is a law that many countries have adopted that force sleepy engineers to reset the clock on the microwave at 2 a.m. on two days during the year.  Just when we had it down, they went and changed it a couple of years ago.  Hence the reason that Cisco doesn’t hard-code the DST settings on their routers.  They are more than happy to let you do it yourself.  In this example, we’re using the U.S. standard of the second Sunday in March and the first Sunday in November:

R1(config)# clock summer-time <name> recurring <week number start> 
        <day> <month> <time to start> <week number end> <day> <month> <time to end>
R1(config)# clock summer-time CDT recurring 2 Sun Mar 2:00 1 Sun Nov 2:00

And just like that, your router will perform just like every other smart device in your house and reset the clock for DST when necessary.  Now, if I could just get my microwave to do that.

Now that your router is in the right time zone, it’s probably a good idea to sync the clock to some kind of external time source.  That’s why Network Time Protocol (NTP) was created.  It allows distributed systems to sync their clocks with a time source directly connected to an atomic clock (the most precise kind).  NTP form as a hierarchy through use of strata. Stratum 0 NTP devices are directly connected to atomic clock sources, usually through RS-232 or other cabling.  The are not connected via a network.  Stratum 1 NTP devices are connected to Stratum 0 devices via a network connection.  These are the systems that are usually referred to as time servers.  These are usually the devices that you will sync one of your clocks to.  Why just one?  Well, while having all your devices synced to external time sources is a great idea, there are two issues that can arise.  First, having that much NTP traffic exiting your network isn’t exactly optimal.  There is no reason for 20 routers to each poll an external NTP server when one router could do the same thing, and the other 19 routers poll the synced router.  You can even designated your NTP-synced router as a Stratum 2 or 3 device if you’d like, then have it start serving time to your other devices.  The second issue with using all external NTP servers deals with security.  Some people are uncomfortable with the idea that all their devices are being told how to manage their clocks by an external device over which they have no control.  By configuring your devices to sync to one clock in your network that you control, there is more consistency and less reliance on systems outside your control that may be overloaded or unreliable.  For more info on what happens when someone starts abusing an NTP server, check out what NETGEAR did to the University of Wisconsin’s NTP server here.

For the sake of your sanity, it’s best to set the clock to something close to the actual time before you set the NTP server.  The reason for this is due to the propensity for NTP to look at your clock and declare it insane if you are too far drifted from the actual time.  I usually try to get my local clock somewhere in the neighborhood of one hour from the actual time, but the closer you are and the faster NTP will sync.  You do this with the following command (note the context)

R1#clock set <HH:MM:SS> <1-31> <Name of Month> <Year>
R1#clock set 01:00:00 10 Jan 2011

You must manually set the clock in enable mode, not global config mode.  Once you’ve gotten the clock close to your time, you can set the NTP server.  If you want to sync your router to an external time source, using the NIST Time Server list is always a good start.  If your router is capable of resolving DNS, a better idea is to use the NTP pool service.  This service is a cluster of NTP servers around the world that is served by round-robin DNS query, so no one server can get overloaded.  If you don’t feel comfortable syncing your clock to a server in France or Japan, you can always narrow down the focus of your query by using narrower DNS entries.  Check out their site for ways to do this.  Once you’ve figured out  how you are going to connect to NTP, and whether you are going to use external or internal servers, the command is pretty easy:

R1(config)# ntp server <name or ip>
R1(config)# ntp server 10.1.1.1
or
R1(config)# ntp server 0.pool.ntp.org

Yep, that’s it.  Simple once you’ve gotten all the planning down.  You can check your NTP sync status with the command show ntp status.  You can see which time servers your are polling with the command show ntp associations.  The commands have a lot of good info, but can be a little cryptic your first couple of trys.

Once you’ve gotten your clock in sync, there’s just two more commands you need to use to ensure that all your logs and debug outputs are using the right clock.  By default, logs and debugs use the system uptime for their output, so you could get a log message that says “1w3d” instead of the real time.  And if you have to start doing math on your debugs to figure out when a call was dropped, you’re going to be a cranky rock star.  From global config mode, go ahead and type in these two commands:

R1(config)# service timestamps log datetime msec
R1(config)# service timestamps debug datetime msec

The “MSEC” keyword on the end tracks the message down to the millisecond level, which I’ve always found very handy when trying to figure out sub-second error messages.  It also helps better match error logs which are all part of the same event, but spread out over multiple messages.

Now, your routers are all in sync and your logs and debugs are all outputting the correct time.  If a consultant tries to access your devices, you will appear to be one cool customer that doesn’t need any help on your networking devices.  You’ll also be able to troubleshoot faster and get all the fame and wealth appropriate to your station as the Network Miracle Worker.

For what it’s worth, I did a lot of searching about why the default time on a Cisco router without a battery backup is March 1, 1993.  No one seemed to have a definitive answer.  According to the Internet, the only really exciting thing that happened that day was George Steinbrenner being reinstated as Yankees owner.  I doubt anyone in San Jose is a Yankees fan, so I didn’t think that was it.  It also didn’t correspond to any neat numbers in the Unix Time Epoch.  1993 was the first year that Cisco acquired a company, but that happened in September of that year.  The only thing that happened early was the release of IOS 10.0.  I guess that Cisco decided that “10” was an important enough number that they wanted to start basing recent history sourced from this date.  The other possibility is that it was just an arbitrary date chosen by IOS engineers so that the router clock didn’t cycle all the way back to 1900.  MS-DOS had a similar functionality, wherein it would see the system BIOS clock set to 1900 and assume that the BIOS had to be wrong.  It would then set the clock to the earliest date it could (January 1, 1980).  Maybe Cisco just decided that 1993 was so early that if they noticed a router clock stuck on that date, it would just be assumed the the clock was not set.  Either than, or they were really big fans of this song…

CUVA Windows 7 64-bit Support

If you are one of those people who jumped on board the video train with Cisco back in the day, you’ve probably got a Cisco Unified Video Advantage (CUVA) camera on your desk.  This device, which suspiciously resembles a Logitech 4000/5000 QuickCam (more on that later), was used back in the day in conjunction with 7900 series IP phones to provide the first video-enabled endpoint.  It was a little better than using the 7985 monstrosity, but was a little iffy sometimes to get it working properly.  I, for one, stashed my CUVA camera in a drawer and promptly forgot about it until I won a video-enabled 9971 at Cisco Live Las Vegas this year (Thanks again, Cisco Collaboration!).  I wanted to test how the video calls worked between endpoints in the office.  So I dug my CUVA camera out of the desk, video enabled a couple of phones, and set about installing the software so we could do cool Blade Runner-style video phone calls.  Except, most of the machines in the office are now running Windows 7 64-bit and the CUVA camera doesn’t work with that OS at all.  Cisco has never updated the drivers to support 64-bit, and based on the documentation has no plans to do it in the near future.  Woe is me…

So, after a few months of casual searching, I finally stumbled across a post on Cisco’s Community Support Forums that fixed me right up.  All credit goes to these guys for figuring out the solution, I’m just reposting it here in case anyone wants to try it for themselves.

1.  Download the latest version of the Logitech QuickCam software from here: http://www.logitech.com/en-us/435/243?WT.z_sp=Image.  I chose the Logitech QuickCam 5000, as that is all a CUVA camera is (just different branding).  Be sure in the drop-down box to select your operating system as Windows Vista 64-bit, as that is the highest 64-bit OS supported.

2.  After downloading the drivers, copy them to a non-Windows 7 device.  This could be a Windows XP system, Windows XP mode, Windows XP in a VM, or Windows XP running on a toaster in your kitchen that you have KVM and Remote Desktop access to.  The important thing is that you DON’T want to install it on Windows 7 or Vista.  We aren’t actually installing it, just getting the drivers.

3.  Start the installation program.  It should extract the drivers then fail due to incorrect OS type.  We don’t care.  Navigate to your temporary folder (Start -> Run -> %temp% -> Click OK) and find the folder that the installation program copied the files to.  It should be something like “QuickCam_<Version Number>”.  Copy this whole folder back to the Windows 7 machine from your XP system/VM/toaster.

4.  Navigate through the folder structure in the “\Drivers\x64\PRO464” folder.  Inside you’ll find a whole bunch of driver files.  Specifically, we want to edit the lPRO464v.inf file.  Open it in Notepad or the replacement text editor of your choice.

5.  Now, for the fun part.  We need to do a find-and-replace for the hardware ID in this text file.  I had the most luck searching for the string “08C5” and replacing it with “08C7”.  Depending on the age of your CUVA camera, you could also try searching for “08B2” and replacing it with “08B6”.  After the replacement option, save the file and exit.  What you are doing in this step is forcing the driver installation routine to identify your CUVA camera as a Logitech QuickCam 5000.  Because, that’s basically what it is.

6.  Plug in your CUVA camera.  It will successfully install all but one driver, leaving you with an unknown device in the Device Manager.  Go into the Device Manager, and update the driver.  When prompted to search for drivers or specify a location, choose to specify.  Point the installer at the location you just edited, which should be in <Location of QuickCam Folder>\\Drivers\x64\PRO464.  After you point the driver updater there, it should take right off and start working.  You’ll probably get a popup about the system not being able to verify the driver source.  This is because we changed the values in the INF file.  It’s a harmless warning in this case, so allow the driver installation to proceed.  After a few more seconds, you should have a brand spanking new Logitech QuickCam 5000 installed on your system.

There you go.  Hacking a CUVA camera back into the QuickCam 5000 it originally was in order to make it work with 64-bit drivers for a different OS that you are installing it on.  No one ever said voice would be easy.  But hey, you can get a little more mileage out of that camera.  At least while you work on your boss and convince him you need a 9971.  Or a personal Telepresence unit.  And if you figure out how to convince your boss on that last item, give me a call.  I’ve got someone you can go to work on for me.