Use of Scripting to Identify Devices Affected by the Clock Signaling Field Notice

By now you have likely heard about the “Clock Signaling Component” issue affecting a broad range of Cisco products. If you haven’t a number of Cisco products are affected by an issue that will cause them to fail during normal operation, once they fail they will stop functioning completely and can not be powered back on. You can learn more about the affected devices on the notice page.

You are now faced with the challenge of identifying the affected systems in your environment, then deciding on an approach to replacement and coordinating RMA on the affected units before they fail. When we learned about this issue one of the first steps we took was to develop automated tooling to identify units impacted by the issue.

As part of our Stack8 Managed Services practice, we maintain up to date inventory information on customer environments. Our systems already track information on device models, firmware versions, serial numbers, and configurations. We have also extended them to include validation of the hardware versions so we could identify units impacted by the field notice. I’ve extracted some of our validation code (Thanks, Joris, for your work on getting this in place for our customers) and put it into a simple script for you to use or extend.

Here you can see the output of a run against three devices:

user@ubuntu:~$ ./simple-inventory-v2.py Device wanrouter1 model ISR4431/K9 vid V02 Device voicegateway1 model ISR4351/K9 vid V02 (affected by notice 64253) Device voicegateway2 model ISR4331/K9 vid V02 (affected by notice 64253) Affected device list: voicegateway1, voicegateway2

And here’s the script itself:

#!/usr/bin/python3 from easysnmp import snmp_get, exceptions community="public" affected_model = { 'ISR4321-AX/K9': ['V01','V02'], 'ISR4321-B/K9': ['V01'], 'ISR4321/K9': ['V01','V02'], 'ISR4321BR-V/K9': ['V01','V02'], 'ISR4331/K9': ['V01','V02'], 'ISR4331B/K9': ['V01'], 'ISR4331BR-V/K9': ['V01'], 'ISR4351-AX/K9': ['V01','V02'], 'ISR4351/K9': ['V01','V02'], 'UCS-EN120E-108/K9': ['V01','V02'], 'UCS-EN140N-M2/K9': ['V01'] } def s8_snmpget(host, oid, community): return snmp_get(oid, hostname=host, community=community, version=2).value def validate_notice_64253(device): model=s8_snmpget(device,"1.3.6.1.2.1.47.1.1.1.1.13.1",community) vid=s8_snmpget(device,"1.3.6.1.2.1.47.1.1.1.1.8.1",community) if model in affected_model and vid in affected_model[model]: print("Device {} model {} vid {} (affected by notice 64253)".format(device, model, vid)) return True print("Device {} model {} vid {}".format(device, model, vid)) return False if __name__ == "__main__": device_list=["wanrouter1","voicegateway1", "voicegateway2"] affected_devices=[] for device in device_list: if validate_notice_64253(device): affected_devices.append(device) if len(affected_devices) > 0: print ("nAffected device list:n{}".format(", ".join(affected_devices))) else: print ("nNo devices affected by notice 64253")

At a high level, the script functions as follows:

• We define a dictionary (affected_model) with a set of models and a list of affected hardware vids.
• We have a function (s8_snmpget) to retrieve an SNMP OID from a device.
• We have a function (validate_notice_64523) that retrieves the model and hardware revision for a device and compares is against the dictionary to determine if it’s affected by the notice.
• We iterate through a list of devices (device_list) and call the function that validates the device.
• We print a list of devices affected by the notice if any are found.

This script is a small extract from our managed service tooling, I’ve deliberately limited the functionality to keep the size of this blog post and script reasonable. This portion of our code only validates the commonly deployed ISR 4k Platform.

To make practical use of it in your environment, there are a number of changes you may want to make:

•  Improve the script, so it also returns the serial number (OID 1.3.6.1.4.1.9.3.6.3.0) for contract validation and RMA processing.
• Scan your entire IP address space rather than work from a list of devices.
• If you are using other impacted devices the table of affected models will need to integrate them.
• If you don’t have SNMP configured in your environment, you could leverage paramiko to ssh to devices and validate the output of show inventory.
• For larger numbers of devices, you could use a trigger to interact with thousands of devices in an efficient highly parallel fashion.

If the ideas behind the script are appealing to you but extending and adapting it to your needs are more than you and your team can take on, then our Managed Services offerings may be the ideal supplement to help you.

Regardless of how you proceed, with your inventory in hand, you can validate if your devices are under contract or warranty using the Cisco Coverage Checker. You can then coordinate the RMA of the impacted devices, provided they are covered by a warranty or active service contract, using the replacement ordering form and email address here.