Skylight sensor control 20.05 Release Notes

These release notes cover the requirements, new features, changes, addressed issues and known limitations for this release of the SkylightTM sensor: control firmware version 20.05.

Please read all the notes prior to installing this firmware version.

Organization

This manual includes the following sections:

• Requirements

This section provides requirements for Firmware Version 20.05.

• Skylight sensor: control 20.05 Lifecycle

This section lists the planned lifecycle dates of this software release.

• Firmware Version 20.05_22954 (2020-06-25)

This section provides New Features and Enhancements, and MIB Changes, if any, for Firmware Version 20.05.

Requirements

This firmware version applies to the following products from Accedian:

Product ID

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

Skylight sensor: control was tested using the Skylight Appliance version 1.4.

Skylight sensor: control 20.05 requires Skylight orchestrator 20.05 as its minimum. Customers using SD Vision must first upgrade to Skylight orchestrator 20.05 before upgrading to Skylight sensor: control 20.05.

Important Note

In Skylight sensor: control 20.05, any module upgrades from firmware versions previous to VCX 2.2 FWSuite (FWSUITE_VCX_2.2_10190) have been blocked, in order to protect against a potential complete loss of connectivity/functionality that cannot be recovered. In order to upgrade a module from an older FWSuite version, an older version of Skylight sensor: control must be used to first upgrade the module to FWSUITE_VCX_2.2_10190:

 Skylight sensor: control upgrade consideration

When upgrading the Skylight sensor: control software, the modules firmware is not upgraded automatically. It is not recommended to operate Skylight sensor: control with a different module firmware version since the functionality is limited to management. The management includes:

• Module discovery
• Connect to module and have a management Link state
• Upgrade module firmware version using feature suite
• Update module interface (IP address, VLAN, and DHCP)

CAUTION: The upgrade process was hardened in VCX 2.7. Under specific circumstance the module upgrade can still fail. This happens if the module management is lost and the module performs an automatic rollback. The module can brick if the power is lost in a critical short time 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 Skylight sensor: control User Manual, section 4.3, “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 module configuration when operating with a different firmware version. Changing the configuration could result in unknown behavior. A factory reset using AMD could be required in some cases. In a future release, the Skylight sensor: control software will prevent changing configuration for modules running a different firmware version.

For cases where all modules cannot be upgraded at the same time, it is recommended to run different Skylight sensor: control instances with different software versions. Modules to be upgraded should be moved between Skylight sensor: controls.

When downgrading Skylight sensor: control software, the modules firmware version shall also be downgraded. The downgrade process shall follow these steps in order to successfully downgrade Skylight sensor: control software and modules firmware. Note that downgrades are not recommended (see CAUTION above).

CAUTION: Before doing the downgrade, it is recommended to enable Extra Reconnection Delay with the previous release (refer to the Skylight sensor: control User Manual, section 4.3, “Adding Remote Devices” for more details on how to enable Extra Reconnection Delay).

Scenario 1: downgrade using Skylight sensor: control rollback

• The modules firmware must be downgraded first using the newest Skylight sensor: control software.
• Perform Skylight sensor: control rollback.

Scenario 2: downgrade using a different Skylight sensor: control instance

• The modules firmware must be downgraded first using the newest Skylight sensor: control software.
• Delete modules from the newest Skylight sensor: control instance.
• Discover the modules using the older Skylight sensor: control instances.

Firmware Version 20.05_22954 (2020-06-25)

New Features and Enhancements

10G SFP compute

Introduce the new 10G SFP compute support in Skylight sensor: control. The 10G SFP compute supports the following features:

• FlowMeter (28 rules)
• NFV PM (TWAMP, ETH-DM, UDP echo, ICMP echo, ETH-LB, ETH-VS)
• SAT (RFC-2544 and Y.1564) IPv4 and IPv6
• TWAMP stateless refection
• TWAMP stateless reflection (16 rules)
• DMM reflection
• Loopback
• SyncE
• PTP-TC layer-2

LLDP neighbor discovery

Remote devices LLDP neighbors are now reported in Skylight sensor: control. Allows Skylight operators to retrieve LLDP neighbor information using Skylight sensor: control or Skylight orchestrator.

Fault propagation based on port status

Add support for one-way link in fault propagation. The one-way-link fault propagation can be done from NNI port propagating the fault to the UNI port. When the NNI port goes down, the UNI port is shut down until the NNI port goes back up. Once the NNI port is up, the UNI port will restart the link negotiation.

The opposite direction UNI to NNI is not possible since it would cause losing management with sensor control.

Skylight sensor control system monitor

System monitor provides monitoring, logging and alerting on the system resources. The main purpose is to provide additional information when troubleshooting issues. The following resources are monitored

• Disk usage
• Network usage
• CPU usage

WebUI help rebranding for new Skylight naming

Changes were made to the web help to address new nomenclature, such as:

• New name for FlowMETER is flowmeter
• New name for FlowBROKER is flow broker

Management IP and NFV IP added to remote device show command

Added the management IP and the NFV IP being used. This is useful for troubleshooting since the management IP and NFV IP can differ. Also, this helps the integration with Skylight orchestrator that uses the management IP.

System capabilities

The Skylight sensor: control offers the following system capabilities:

CFM Maximum number of Remote MEP

TWAMP reflection instances (module)

Actuator maximum number of probes

Number of trap alarm per second

Operational Considerations and Known Limitations

Important Notes

• The 10G SFP compute link can take 30 seconds to come up.
• The 10G SFP compute reboot time can take up to 60 seconds.
• SyncE:
  • Shall be use 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 modules 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 in order to generate 1500-byte NFV probes over a Q-in-Q interface.
• The virtual machine disk must be deployed using thin mode with ESXi in order 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 Skylight sensor: control 19.12 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).

The traffic downtime values shown above were calculated following firmware upgrade tests performed with 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:

• Skylight sensor: SFP compute 1G copper Skylight sensor: module downtime: 13.0
• Skylight sensor: SFP compute 1G optical Skylight sensor: module downtime: 7.4

• SyncE clock transparency on Skylight sensor: SFP compute 1G copper Performance Modules may not work if the mastership is misconfigured.
• An XML file with the required Skylight sensor: control virtual machine hardware information has been provided with this release to ease deployment of the Skylight 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 Skylight sensor: control network interfaces. 
• Flowbroker 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.
• 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 Skylight sensor: control instance. These alarms are cleared when the remote devices are linked again.
  • No alarm hierarchy mechanism has been implemented in the Skylight 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 Skylight 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 Skylight 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 Skylight sensor: module:
  • The Skylight 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 Skylight sensor: control.
• The DLA 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 Skylight sensor: control.
• If a Skylight 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 as a way to achieve faster media selection.
• Skylight sensor: SFP compute 1G and Skylight sensor: module 1G cannot loop back any TCP frames addressed to them (device primary IP).
• A Skylight 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 Skylight sensor: control will extract the value of the following dynamic settings stored on the Skylight 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
    • The ICMP responses on the module and SFP compute are throttled in order to reduce CPU usage.
    • ICMP-echo sessions targeted to the module IP address have a bigger delay due to the slow response.

MIB Changes

None.

 Skylight sensor: control 20.05 Lifecycle

This section lists the planned lifecycle dates of this software release. See the table below outlining the following milestones: