Need a simple, easy way to check if a piece of Cisco hardware is covered under warranty or SMARTnet? Look no further than this useful site: https://cway.cisco.com/sncheck
You will need to login using your Cisco.com (CCO) username and password, but then you can check on coverage for ANY serial number. If the serial number is covered under a contract associated with your CCO account then you will see additional details including coverage end date and coverage level.
TranslatorX is an indispensable tool for parsing Cisco Unified Communications Manager (CallManager) as well as Cisco CUBE logs and trace files. Check it out here: http://translatorx.cisco.com/
Cisco IOS comes in several different flavors including Cisco IOS, Cisco IOS XE and Cisco IOS XR.
Cisco IOS (Classic IOS)
The classic Cisco IOS network operating system uses a monolithic kernel that runs all of the necessary modules in the same memory space. Any issues within IOS can cause the entire operating system to stop responding or crash.
Cisco IOS XE
IOS XE leverages an underlying Linux operating system and runs IOS as a daemon called ‘IOSd’ and as such the underlying Linux operating system is able to exert monitoring and control over IOSd. Some of the possibilities of this type of virtualization include software based high availability by having two copies of IOSd running at the same time without the need for a completely duplicated route process or hardware layer. Another exciting possibility is to leverage in service software upgrade or ISSU which allows for much easier software upgrades without the need to reload and stop packet processing to change software versions.
Cisco IOS XR
IOS XR is a completely new network operating system running directly within a Linux operating system. This type of rewrite led to a truly modular operating system where different IOS XR features run as isolated and distinct processes which can individually be stopped and restarted.
Cisco NX-OS started life as SAN-OS which was used on Cisco’s line of storage switches. The Nexus line of switches use a modified version of SAN-OS which was re-written to include more data networking focused while still including the SAN features needed in a converged data center networking product. Cisco NX-OS is modular and in many ways similar to IOS XR from a very high level.
Cisco.com IOS XE site – a generic overview of IOS XE
White Paper: Cisco IOS and NX-OS Software Reference Guide – an excellent overview of which flavor of IOS runs on what platform
Since 2005 Cisco IOS has offered several security enhancements to help mitigate the risks of dictionary attacks used against login sessions. Now you are probably wondering why I’m blogging about something more than 7 years after it was released. I rarely see people implement any of these features and I’m hoping to raise the visibility of these simple configurations.
If you’ve ever left SSH open to the internet I’m confident you’ve seen how quickly a dictionary attack will commence. There are two basic ways to combat this issue. The first, and highly recommended, way is to simply block SSH access from the internet. The second option involves slowing down dictionary attacks to the point where usernames and passwords can’t be tested quickly enough to guess a valid combination thereof.
The Cisco IOS login enhancements include two features:
- Introducing a delay between successive login attempts
- Blocking all login attempts once a failure threshold is reached
By introducing even a small delay the time taken for a remote attacker to apply a dictionary attack is greatly increased.
Cisco refers to the second feature as “quiet mode” and also includes an option to specify an access-list which is exempted during the block period.
A quick example should tie all these pieces together. First we will create an access-list that permits specific network(s) from which logins will never be denied.
ip access-list extended SSH_IN
remark Local Network
permit ip 10.1.0.0 0.0.0.255 any
Next we will configure the login blocking which requires three parameters. These three parameters are the length of time to block for, the number of failed attempts after which to take action and the period of time during which to monitor failed logins. Here’s the completed configuration to block logins for 60 seconds after 3 failed attempts within a 60 second period. The second line of configuration will reference the access-list created above to never block the specified networks.
login block-for 60 attempts 3 within 60
login quiet-mode access-class SSH_IN
Previously I mentioned that a simple delay between login attempts would greatly slow down dictionary attacks. This delay can be accomplished using the following configuration. The delay duration is specified in seconds.
login delay 2
Cisco Documentation Link
The Cisco CallManager TFTP server component provides various configuration files to endpoints (phones, video devices, etc.) as well as things like ring tones, IP phone background images, and phone loads (firmware). There are times when it is convenient to directly access the files that the TFTP server is hosting such as when determining why a phone can’t download a new background or ring tone.
One method of accessing these files from Windows is to use the built in TFTP command line application. Simply open a command prompt and type:
tftp <server IP or hostname> get SEP<MACADDRESS>.cnf.xml
Microsoft documentation on this command is available here. If you are running Windows 7 the TFTP application is not installed by default and you will need to install it using the “Turn Windows Features On or Off” section of the “Programs and Features” Control Panel item.
Most linux/unix (including OS X) distributions include tftp by default which can be invoked from the command line simply by typing:
tftp <server IP or hostname>
tftp>get get SEP<MACADDRESS>.cnf.xml
For more information reference the manual page (man tftp)
The other method of accessing these TFTP is to actually use HTTP which was made available in CallManager 8.x. The 89XX and 99XX series IP phones actually attempt to download files via HTTP and fall back to TFTP only when necessary. You can use this new functionality to your advantage and simply browse to http://<TFTP server IP or hostname>:6970/<File Name>
For example if you wish to download a phone configuration file just put this in the address bar of your browser:
http://<TFTP server IP or hostname>:6970/SEP<MACADDRESS>.cnf.xml
Once downloaded simply open this file with any text or XML capable editor.
Remember that just as in the past if you manually upload a new file to the CallManager TFTP server you need to stop and restart the TFTP service in order to have the new file appear no matter if you are accessing the file via TFTP or HTTP.
I was helping someone with a contact center express project recently and it became necessary to convert some G.711 audio prompts to G.729. Back in the good ol’ days of CallManager 3.x – 4.x this was a very simple task, but I had never attempted using a Linux based version of CUCM (CallManager) to do the same. You will need an SFTP server to act as the destination for the converted files. I highly recommend SilverSHielD if you are running Windows (there’s a free version available at the link).
Enough background. Here’s the process:
- Login to the CUCM admin web page and navigate to the Media Resources -> MOH Audio File Management
- Upload the audio file(s) that you want to convert to G.729
- Login to the CUCM command line interface via SSH
- Run the following command to see all current MOH files “file list activelog mohprep“
- Run the following command to transfer the file to an SFTP server: “file get activelog mohprep/<filename>.wav” (where filename is obtained in step 4)
- You will be prompted to enter the following details about the SFTP server:
SFTP server IP: <SERVER IP>
SFTP server port :
User ID: <SFTP username>
Password: <SFTP password>
Download directory: \
(NOTE: Use ‘\’ for Windows based SFTP servers or ‘/’ for Linux/Unix based SFTP servers)
This configuration will create a syslog message as well as an SNMP trap either of which your monitoring/alerting systems should be able to use as a trigger to take action.
1. Copy the linked TCL file to the root of the flash filesystem on the router that connects to the SIP trunk(s). Download TCL Script
2. Add the command to “voice-class sip options-keepalive” to one of the dial-peers pointing to the service provider and make a note of the dial-peer number you are adding the command to
dial-peer voice 100 voip
voice-class sip options-keepalive
3. Add the command
track 100 stub-object to the global config.
4. Add the command
snmp-server enable traps event-manager to the global config (this is needed for the SNMP trap functionality).
4. Finally the following configuration template can be applied to the router. Notice the number 100 below is a reference to the dial-peer and tracking number from above and must match for this to work.
event manager environment dial_peer_number 100
event manager environment check_interval 30
event manager directory user policy "flash:/"
event manager applet siptrunk_down
event track 100 state down
action 10 snmp-trap strdata "SIP Trunk Down"
action 20 syslog msg "Alert - SIP Trunk Down"
event manager policy check_dial_peer_status.tcl
This was documented at the following Cisco page as well: Link
Many engineers have been scared away from running debugs in production network due to bad experiences with high CPU utilization requiring drastic action like powering down the device and letting it reload. The CPU impact of debugging can be greatly decreased by changing the configuration of IOS. The snippet below shows a basic template that both reduces the performance impact of debugging and also helps improve the accuracy of logged debugging information.
Router(config)# service timestamps debug datetime localtime msec
Router(config)# service sequence-numbers
Router(config)# logging buffered 1000000 debug
Router(config)# no logging console
Router(config)# no logging monitor
I love config templates as much as the next guy, but a better understanding of what each of these commands does is important too!
Let’s break it down line by line:
service timestamps debug datetime localtime msec Ensures that debug logging entries include millisecond time stamps based on the router’s clock. Millisecond level precision is desired as debugging can generate a lot of messages very quickly and it’s important to know what order things happened in
service sequence-numbers Assigns numerically increasing values to the beginning of log entries to quickly identify the order in which messages occurred.
logging buffered 1000000 debug Increases the size of the onboard log buffer to 1 MB and enables logging of debug level messages. Be aware that issuing this command will erase the current log entries.
no logging console Disables logging output to the console port. By default all logging output is sent to the console port whether or not anything is even connected to it. Not configuring this is one of the biggest contributors to the high CPU utilization and sluggish response. Simply put Cisco IOS schedules the output of text to the console port ahead of many other tasks. The default baud rate on the console interface is 9600 bps, which further amplifies the problem. This means that when lots of things are being sent to the console other tasks must wait before they are allowed to execute.
no logging monitor Disables logging output to other terminal interfaces (telnet or SSH). This prevents us from being able to use the “terminal monitor” command which can be a useful way to see the output of a debug while connected to a router over telnet or SSH. The downside of examining debugs in this way is that depending upon how quickly the messages are being generated there is a good chance some won’t ever show up on your screen. It’s best to simply log them to the internal buffer and view them using “show log”.
Both of the previous commands could be altered to prevent just debug logs from being displayed. Simply add the word “debugging” after one or both and you’ll still be able to see everything that isn’t a debug message.
As wise network professionals always say be sure to test and validate these configurations in a lab environment before implementing anything in production. Even with the optimizations above be sure to check CPU and memory utilization before enabling any debugs.
When configuration archiving and logging is configured on an IOS router with a crypto capable image you may some rather odd commands every time the router starts up.
Here’s an example of what’s shown when you run the “show archive log config all”
1 1 console@console |access-list 199 permit icmp host 10.10.10.10 host 188.8.131.52
2 1 console@console |crypto map NiStTeSt1 10 ipsec-manual
3 1 console@console |match address 199
4 1 console@console |set peer 184.108.40.206
5 1 console@console |exit
6 1 console@console |no access-list 199
7 1 console@console |no crypto map NiStTeSt1
At first glance this appears to something nefarious, but it’s actually a test routine built in to IOS in order to meet FIPS requirements. It’s completely normal and does not impact normal operations.