Assurance Sensor Control Release Notes 25.07

Operational Considerations

Be aware of these operational considerations:

• After deploying a new virtual machine from the OVA or QCOW2, the Assurance Sensor Control will not generate a default certificate. You will need to perform a factory reset after deploying the virtual machine in order to generate the certificate and access the web interface.
• 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 Sensor SFP 10G link can take 30 seconds to come up.
• The Sensor 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).
  
  

  Firmware Suite Upgrade Downtime

  Downtime	Sensor SFP 1G Copper	Sensor SFP 1G Optical	Sensor Module 1G Copper	Sensor Module 1G Combo	Sensor Module 10G	Sensor Module 1G	Sensor 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

  
  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:
  • Sensor SFP 1G copper Sensor Module downtime: 13.0
  • Sensor SFP 1G optical Sensor Module downtime: 7.4
• SyncE clock transparency on Sensor 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 Sensor 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 Sensor 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.
• Sensor SFP 1G and Sensor 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 Sensor 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.