I’ve recently spent more time testing video endpoints with Cisco Spark (SX10, SX20, Spark Board, Spark Room Kit, DX80, etc.) with my customers and have run in to several things that I think many others probably encounter as well.
- Check support Spark endpoints – https://help.webex.com/docs/DOC-4205
- Is your endpoint running the right software version to avoid certificate validation errors when attempting to register for the first time? (To activate your room device on Cisco Spark, the device must run software version CE8.2.0 or later.) https://help.webex.com/docs/DOC-7709
- To upgrade the codec it’s a simple process of downloaded CE software 8.2 or higher and then logging in to the web interface of the codec to complete the manual upgrade.
- If you plan to use a Touch 10 with any endpoint you must pair it to the codec BEFORE you register it to Spark – https://help.webex.com/docs/DOC-11657
Before I upgraded my SX20 to CE 8.2 I was seeing errors in the logs similar to
2017-12-09T09:51:08.966-06:00 a8 appl: 762.54 Wx2Http W: HTTP(2) Error: NetworkError (Peer certificate cannot be authenticated with given CA certificates)
The basic issue is that in releases of CE software prior to 8.2 the necessary CA certificates were not installed so the certificates presented by the Cisco Spark registration system weren’t able to be validated.
Cisco Cloud Web Security (CWS) and OpenDNS both provide cloud based security services. CWS offers an HTTP/HTTPS proxy and OpenDNS provides security and visibility at the DNS resolution layer. I’ve been asked many times where both CWS and OpenDNS host their services as this can make a big impact in end user experience if the hosting location is far away from the user and could lead to high latency and a lousy experience.
CWS Proxy Location and Status Page: http://servicestatus.sco.cisco.com/status
OpenDNS Location and Status Page: https://www.opendns.com/data-center-locations/
I regularly share useful links with customers and colleagues and often find that this page is a great starting point to explore some of the web tools Cisco has available http://www.cisco.com/c/en/us/support/web/tools-catalog.html
Some of these tools include the Cisco Power Calculator, Cisco Feature Navigator, Cisco IOS to NX-OS configuration converter, and many others. Give it a click and explore some tools you likely didn’t even know existed.
With the release of Cisco Unified Communications Manager (CallManager) version 11.5 support was removed for some of the oldest IP phone models. Support was removed for these phones as they do not support the latest security features that Cisco is working to standardize.
The following models are prevented from registering in version 11.5:
- Cisco IP Phone 12 S
- Cisco IP Phone 12 SP
- Cisco IP Phone 12 SP+
- Cisco IP Phone 30 SP+
- Cisco IP Phone 30 VIP
- Cisco Unified IP Phone 7902G
- Cisco Unified IP Phone 7905G
- Cisco Unified IP Phone 7910
- Cisco Unified IP Phone 7910G
- Cisco Unified IP Phone 7910+SW
- Cisco Unified IP Phone 7910G+SW
- Cisco Unified IP Phone 7912G
- Cisco Unified Wireless IP Phone 7920
- Cisco Unified IP Conference Station 7935
For more background on this check out the following Cisco Field Notice
A brief history lesson:
Prior to the announcement from Cisco of “Universal Access Points” you had to select an access point based on which regulatory domain it would operate within. Regulatory domains are simply places in the world with certain laws and regulations pertaining to radio frequency devices (mobile phones, radios, access points, etc.). In the world of Cisco this meant that an access point for use in Germany would have a different part number than one used in the United States. This led to much frustration and confusion.
The good stuff:
Cisco has announced Universal AP’s which are a single part number per access point model (2700, 3700, etc.) rather than the myriad of part numbers aligned to each and every regulatory domain. The details on how this works can be found in the following blog post.
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.