Blog: Cisco

My IP Communicator continually hung at "registering."  I found a post where someone was experiencing the same issue, and could resolve it by deleting the HKCU\programs\cisco inc\ip communicator registry settings each time before running the software.  So far, I've only had to delete the registry key once.

Recently we had a team change the inside interface of one of our ASA’s to be a trunked port so we could support multiple VLANs.  To do that, we needed to move the “nameif Inside” command and IP address from the physical interface (Eth0/1) to a new subinterface (Eth0/1.4094).  In doing so I came across a few gotchas: [more]

Problem 1:

When you remove the nameif command from an interface, all associated configuration is removed from the running-config. 

Solution:

There isn’t an easy way to migrate the nameif command from one physical interface to a new one.  Once you make the change you have to reenter any configuration that included the interfaces nameif name.  The alternative is to create a new startup-configuration with the changes and reboot to that startup file.

Problem 2:

After moving the nameif command to a new sub-interface I couldn’t SSH to the device via that interface.

Solution:

Basically, the SSH daemon needs to be restarted.  I was remotely making these changes via SSH so my only option was to reboot the ASA. 

I was recently trying to factory reset a Cisco Express 500 switch for use at a customer site.  I researched Cisco’s website and other websites, but nothing I tried would work.  The basic steps are these:

1. Hold down the mode button while applying power to the switch.
2. After the mode lights turn amber, let go and the switch will reset to defaults.
3. After a short time a port (usually port 1) light will start blinking.  Plug your workstation/laptop into that port.  Your workstation/laptop should then acquire a DHCP address from the switch.
4. You should then be able to access the web GUI using the default IP address.

Unfortunately, none of the online documentation I read mentioned the fact that this only worked when Windows XP was the operating system.  Windows Vista or Windows 7 will not work.  I did not find this out until after the fact when another engineer, who had also struggled with this issue, informed me that this was the case. 

Cisco SGE2000 switches (and other Cisco switches) with a web interface still require that the running configuration get saved to the startup configuration.  Oddly, the option is buried under the “File Copy” menu option.  The “Save Configuration” menu option is for saving a backup (text) copy of the configuration.

I had bought a new Wireless HP Laserjet printer and connected it to my wireless router.  Print jobs tested from wireless devices on the same subnet worked flawlessly.

Next, I needed to be able to print from my PCs directly outside of the wireless router.  A brief overview of my network at home is:

Cable Modem -> Cisco 851 Router (hardwired PCs, IP Phone, VPN) -> Linksys E4200 Wireless Router (Laptops, Printer).

I configured port forwarding on the wireless router to forward port 9100 to the printer’s IP address.  I setup a new network printer and told it to use the IP address of the outside interface on the wireless router.  The printer started printing, but then it would not stop.  The PC kept sending the job over and over, and it would never clear out of the print queue. [more]

Within the ports tab of the printer properties on my PC, I had to uncheck “Enable Bi-Directional Support”.  Bi-Directional printing can allow the printer to communicate back to the PC to tell it that the print job has completed.  Turning this off tells the PC to send the job to the printer and then remove it from queue

We recently deployed VRF groups on our core switches and there are a few key changes to troubleshooting/configuration.
Ping:
Standard way: ping 192.168.1.1
w/ VRFs: ping vrf NAME 192.168.1.1 (where NAME is the name of the vrf group)

Traceroute
Standard way: traceroute 192.168.1.1
w/ VRFs: traceroute 192.168.1.1 /vrf NAME

If you are trying to make a connection to a destination that resides in a VRF from the core switches you will most likely have to include some sort of VRF tagging.  This even applies to services like RADIUS, NTP, DHCP Relay, and TACACS.

Recently, I was working on our Cisco 3560E switch. I needed to create a route-map and apply it to an interface for some changes we were planning to make. I was able to create the route-map, but it wouldn’t allow me to apply it to the interface with the “ip policy route-map” command. After doing some research I realized to apply a route-map to an interface for policy-based routing our switch had to be licensed for “IP Services.” The command wasn’t even available, which makes sense being that it wasn’t supported. While upgrading the license; I tried to apply the “ip policy route-map” command again. I did a “sh run int vlan 1” to see if the command was showing up in the config and to my surprise it wasn’t listed!  I went back to the documentation and found the route-map command “set ip default next-hop” was not supported at all on the 3560/3750 switch platforms. I removed this command from my route-map and applied the route-map to the interface and everything seemed to apply correctly. Unfortunately, our whole plan revolved around the ability to use the “set ip default next-hop” command.

So when you are working with Cisco equipment there are at least 3 ways they let you know a command isn’t supported in the IOS:[more]

1. The logical way:  The command isn’t present in IOS and it can’t be used.
2. The illogical way: Allow you to apply a command, but doesn’t prompt you with an error if another “child” command is not supported.  This can only be discovered if you review the configuration and see that the command you entered is nowhere to be found.
3. And what I like to call “The Cisco Way”:  Include the command in the IOS to lead users to believe that the command is supported and works with that IOS/platform all the while not supporting the command in any variation of the IOS/Platform.

After further review, the documentation did have a note that stated the command we needed wasn’t supported on these platforms.  In summary, it is a good idea to fully read any and all documentation on supported/unsupported commands for a platform.  

Cisco's IOS documentation says that pre-shared keys used for VPNs can be 128 characters long.  If you try to specify a 128 character key this message appears "Pre-shared key length exceeds 127 characters.   Key not added."  So, I have been using 127 character pre-shared keys for a long time.  Then IOS 15 came out and we are still doing VPNs just fine with that version, but not using 127 character pre-shared keys.  It still allows them but the VPN will not come up and "%CRYPTO-4-IKMP_BAD_MESSAGE" is logged, which means the keys do not match.  It now looks like the pre-shared keys cannot be longer than 125 characters.

It is possible to boot a Cisco router off of a USB flash drive.  This can come in real handy if you are on-site and the compact flash of the router is bad.  Here are the steps to do it: [more]

1. Format your USB flash drive with a FAT file system.  This needs to be FAT and not FAT32.
2. Copy the system IOS image to the USB flash drive.
3. While the router is powered off, plug in the USB flash drive to the USB port on the router.
4. Power on the router and when it starts to boot up press the Break key to enter ROMMON mode.
5. Once in ROMMON mode enter the following command to boot to USB:
   • boot usbflash0:<system image file name>    (e.g. boot usbflash0:1841-advsecurityk9-mz.124-23.bin)

The following link has some more information about what is supported: http://www.cisco.com/en/US/prod/collateral/modules/ps6247/prod_qas0900aecd80232483.html