Cisco Crosswork Assurance Sensor Control 25.07.4 Release Notes

These release notes cover the requirements, new features, changes, and corrected issues for the Cisco® Crosswork Assurance Sensor Control version 25.07.4. Read all release notes before installing this firmware version.

Requirements

This firmware version applies to Sensor Control.

Software files are available from the Cisco Software Download page. You must sign in with valid customer credentials to access the page.

Note: This firmware release includes the images needed to deploy the Sensor Control using a KVM or VMware Hypervisor, as well as the .afl upgrade file that is typically part of a Sensor Control release.

Sensor Control 25.07.4 requires Crosswork Assurance 25.7.250 or later, and Sensor Management 25.07.1-LTS or later.

Important: In Sensor Control 25.07.4, remote device upgrades from firmware versions before the VCX 2.2 FWSuite (FWSUITE_VCX_2.2_10190) have been blocked to protect against a potential complete loss of connectivity/functionality that cannot be recovered. To upgrade a remote device from an older FWSuite version, an older version of Sensor Control must be used to first upgrade the remote device to FWSUITE_VCX_2.2_10190.

Upgrade Considerations

Upgrading the Sensor Control firmware version does not automatically upgrade the remote device firmware suite.

As of Sensor Control 22.12, you can use remote devices that have older firmware suite versions with the current release. For this release, the supported remote device firmware suite starts with version 22.06.

Caution: The upgrade process was hardened in VCX 2.7. Under specific circumstances, the remote device upgrade can still fail. This happens if the remote device management is lost, and the remote device performs an automatic rollback. The remote device can brick if the power is lost in a critical short period. This was seen in a lab environment only and never reported by a customer.

Before doing the upgrade, it is recommended to enable Extra Reconnection Delay with the previous release (refer to the Sensor Control user manual section "Adding Remote Devices" for more details on how to enable Extra Reconnection Delay).

The downgrade is still executed using the previous software that still has the update process deficiencies. The downgrade can still cause remote devices to fail and should be avoided at the exception of VCX 2.5.0.2 and VCX 2.6.0.1 for which the downgrade is supported without issue.

It is not recommended to change any other remote device configuration when operating with a different firmware version. Changing the configuration can result in unknown behavior. A factory reset using the Module Dock may be required in some cases. In a future release, Sensor Control software will prevent changing configuration for remote devices running a different firmware version.

For cases where all remote devices cannot be upgraded at the same time, it is recommended to run different Sensor Control instances with different software versions. Remote devices to be upgraded should be moved between Sensor Controls. When downgrading Sensor Control software, the remote devices firmware version shall also be downgraded. The downgrade process shall follow these steps to successfully downgrade Sensor Control software and remote devices firmware. Note that downgrades are not recommended (see Caution above).

Downgrade is not permitted for identical firmware suites. For example, the Sensor Control prevents downgrading the remote device firmware suite from version 24.11 to 24.09, as these versions are identical.

Operational Considerations

Be aware of these operational considerations:

• When deploying TWAMP services between Sensor Control and Cisco Router C8011, do not use the ipsla responder twamp configuration on the C8011, as it does not correctly set the Z bit to 1 to indicate RFC 8186 time‑reference compliance. Instead, use the performance-measurement–based TWAMP Light responder configuration, which is RFC 8186 compliant and leverages hardware‑based timestamps on the responder.

• IMPORTANT: If you are downgrading the firmware without performing a factory reset, you will not be able to connect to the board via CLI or WEB interfaces.

• The remote device firmware suite can be upgraded to a version that is greater than the Sensor Control version. For example, you can upgrade the remote device firmware suite from version 23.12.0 to 24.09.0 using Sensor Control version 23.12.0.

• When using hypervisor functions that involve dynamic load balancing of guest virtual appliances in a hypervisor cluster (i.e. VMWare DRS), the balancing policy should limit rebalancing operations to be done on virtual appliance startup and/or hypervisor host failures. The dynamic load balancing must follow the engineering guidelines for dedicated resources allocation. The user should also set MAC preservation. This is mandatory when using local licenses as the license is coupled with the MAC.

• If multiple discovery methods are being used, it is possible that they will discover the same remote device. This can cause some confusion regarding the IP address being used to manage the unit, especially if a specific IP address is expected to be used for a specific remote device. It is important to note that the first discovery method used to discover the remote device is the one that will be used for management. For example, if DHCP advertisement is used at the time of an IP Agnostic discovery, then the IP address of that first method discovering the device is the one that will be used. It is good practice to use only one discovery method for a specific remote device.

• When the user completes an upgrade to the latest build without configuration reset, they will get an error "CSRF Violation" when uploading the import files for the first time.

  • Press Ctrl + F5 to refresh the page.

• The Cisco Assurance SFP 10G link can take 30 seconds to come up.

• The Cisco Assurance SFP 10G reboot time can take up to 60 seconds.

• SyncE:

  • Shall be used with no force link up disable and ESMC enabled.
  • Long term holdover not supported.

• Internet Explorer 11 is no longer supported. The browser does not support newer technology and does not always work properly.

• Loopback usage in the second-generation remote devices is limited to one loopback on both ports or two loopbacks on a unique port. Using two loopbacks on both ports at the same time will be removed in a future release.

• The virtual machine MTU must be configured to a value greater than 1526 bytes to generate 1500-byte NFV probes over a Q-in-Q interface.

• The virtual machine disk must be deployed using thin mode with ESXi to limit the storage to the configured size. Otherwise, the maximum configuration size will be reserved on the host.

• The following table provides the traffic downtime associated with the upgrade of a Sensor Control 20.11 release firmware suite. All values are expressed in seconds.

  Note: The switching time (i.e., jump) between the PMON and TGEN firmware loads is equivalent to the FPGA downtime (third row below).

  Downtime	Cisco Assurance SFP 1G Copper	Cisco Assurance SFP 1G Optical	Cisco Assurance Module 1G Copper	Cisco Assurance Module 1G Combo	Cisco Assurance Module 10G	Cisco Assurance Module 1G	Cisco Assurance SFP 10G
  MCU	4.30	3.92	5.08	2.14	3.97	4.28	2.27
  Baseload	N/A	N/A	N/A	N/A	N/A	N/A	N/A
  FPGA	3.48	2.30	3.60	1.05	0.96	1.24	17.88
  Total	7.78	6.22	8.68	3.19	4.93	5.52	20.15

  Table: Firmware Suite Upgrade Downtime

  The traffic downtime values shown above were calculated following firmware upgrade tests performed with Assurance Sensors (formerly Accedian Skylight performance elements) acting as the host devices. Traffic downtime can vary from one host device type/model to another. For example, downtime measurements using a Cisco 901 as the host device gave the following results:

  • Cisco Assurance SFP 1G copper Cisco Assurance Module downtime: 13.0
  • Cisco Assurance SFP 1G optical Cisco Assurance Module downtime: 7.4

• SyncE clock transparency on Cisco Assurance SFP 1G copper Performance Modules may not work if the mastership is misconfigured.

• An XML file with the required Sensor Control virtual machine hardware information has been provided with this release to ease deployment of the Sensor Control on a KVM Hypervisor. Offered in libvirt-compatible format, this file can be used with any third-party tool that supports this format such as the virsh command line utility. For additional information, refer to libvirt.org.

• Prior to deploying the KVM image, you must configure your host networking settings to map to the Sensor Control network interfaces.

• Flow broker file transfer using FTPS:

  • Ensure the FTPS server allows session re-creation. Otherwise, the file transfer aborts, and the file is empty.

• SAT RFC-2544:

  • Due to the number of traffic filters available per remote device, SAT RFC-2544 Layer-3 (IP) tests using multiple (i.e., up to four) flows must use the same UDP source and destination ports on all flows, otherwise one of the flows will not function properly.
  • Attempts by the SAT RFC-2544 traffic generator to send two flows (Layer-3 packets with two distinct IP address targets) may occasionally fail. If this happens, simply restart the test.

• System Alarms:

  • The threshold period cannot be defined for raised or cleared alarms.
  • As the system reboots, some Loss of Connectivity alarms may be raised for remote devices that are configured in the system, but not yet linked to the Sensor Control instance. These alarms are cleared when the remote devices are linked again.
  • No alarm hierarchy mechanism has been implemented in the Sensor Control. As such, no alarms are filtered if a higher-priority alarm is raised.

• Remote Devices:

  • The remote device will be deleted if you change the port used for managing the remote device.
  • Due to the ageing mechanism used by the remote device inventory, a remote device may still appear in the inventory once it has been removed, depending on the discovery period.
  • A Domain ID cannot be specified when creating a remote device discovery instance using the ACP-Layer2 method. The Domain ID is automatically set to Default Domain.
  • When deleting a remote device, the link between the Sensor Control and the remote device must be properly closed before the same device can be added again. Remote devices added before the closure process has completed are not recognized by the Sensor Control. In such cases, simply allow a few seconds for the closure process to complete before trying again.
  • Since the Accedian ACP Layer-2 protocol is used to discover remote devices, its discovery messages may reconfigure the Auto interface of Accedian units (like Skylight element: TE, as well as NE and CE Skylight performance elements) running legacy firmware such as v4.9.x or older.
  • When discovering more than 500 remote devices, it is strongly recommended to perform the discovery process, at most, once every 60 seconds. The three-second discovery feature is CPU intensive.
  • The maximum permitted number of daisy-chained remote devices is 255.

• Time Synchronization:

  • Only NTP client instances are supported by this product: NTP server instances are not supported. The NTP client presents certain limitations compared to other Accedian products.
  • The date CLI command does not reject invalid dates.

• CFM second-generation Cisco Assurance Modules:

  • The Sensor Control manages CFM in either point-to-point or E LAN topologies. These CFM messages are handled through an NFV tunnel established between a Sensor Control.

• The dynamic firmware update feature may require up to five minutes per remote device to update the loads contained on the remote devices that are linked to an instance of the Sensor Control.

• If a Cisco Assurance Module 1G has a combo port with one active port and one inactive port, both links will be shown as "up" because a remote partner is linked to each of them. The inactive port maintains an "up" link status to achieve faster media selection.

• Cisco Assurance SFP 1G and Cisco Assurance Module 1G cannot loop back any TCP frames addressed to them (device primary IP).

• A Sensor Control's Node ID can be edited after the Probe agent has been disabled. For this reason, a nodeid edit command must be preceded by the agent server disable command and followed by the agent-server enable command.

• Each instance of the Sensor Control will extract the value of the following dynamic settings stored on the Cisco Assurance Module:

  • TWAMP stateless reflection state (enable/disable) and UDP port
  • Default TWAMP stateful reflection state (enable/disable) and UDP port
  • ETH-DMM reflection state (enable/disable)
  • SyncE state (enable/disable) and clock source selection and QL state (enable/disable)
  • LLDP enable state (enable/disable) and rate
  • Any port PHY related settings
  • Any port SFP related settings, such as:
    • Laser state (enable/disable)
    • Force Link Up (enable/disable) with timeout period

• Redundant Parameter Handling: If you enter redundant parameters in a command line, the system applies only the value of the last instance. For example, in the command mode edit syslog-ng enable syslog-ng disable, the system applies the final parameter value syslog-ng disable.

• When the system starts and PCA-AAA is not yet configured, the pca-aaa-client show connection status command intentionally displays the default value of OK for last token status and last auth request, and 0D:00H:00M:00S for next token update. In contrast, similar parameters for the pca-aaa-client show session status command, such as Last status and Uptime, are empty.

• By default, the tcpdump application converts the Source IP address and Destination IP address from the IP Header into hostname strings if the capture is directed to the console (stdout).

• Safari is not a supported browser. Accessing the application with Safari may result in limited functionality or unexpected behavior.

System Capabilities

The Sensor Control offers the following system capabilities:

New Features and Enhancements

This release introduces the following features and enhancements:

Rebranding to Cisco® Crosswork Assurance Sensor Control

Cisco® Crosswork Assurance Sensor Control is the new name of Cisco Provider Connectivity Assurance Sensor Control. The change is reflected in the Management Web Interface welcome screen and banner, and in report headers for RFC 2544 and Y.1564 test suites.

Corrected Issues

This release corrects the following issues:

TWAMP Delay and Jitter Results Are Inaccurate with Reflector Using PTP Time Format

On Sensor Control, TWAMP delay and jitter measurements can be inaccurate when a Cisco 8201 router acts as the reflector and the sync is below 30%. The reflector processing time using either PTP or NTP format is subtracted.

RADIUS Login Returns Viewer-Only Access Instead of Admin Rights

RADIUS authentication assigns viewer-only access instead of administrative rights, even when the server returns Service-Type = Administrative-User. The RADIUS reply includes a mandatory Message-Authenticator attribute (Type 80).

VCE Creation Fails on Newly Discovered Remote Device with Unsupported Feature Error

Users may be unable to create a VCE from a newly discovered and managed remote device, even though the device was connected. When applying the VCE configuration, the system displays the error: "ERROR: This platform doesn't support this feature."

Release Lifecycle

This section lists the planned lifecycle dates for this release.