From Cisco Optical Network Controller 24.3.1 release onwards, fiber information and span loss details are added newly to the Topology live PM tool tip. When you click on the fiber sapn link in the map, you will see the following details appearing in the tool tip information:

• Fiber Type: The type of fiber link.

• Length: The length of the fiber link.

• Source Min Expected Spanloss: Source node's minimum expected span loss value.

• Source Max Expected Spanloss: Source node's maximum expected span loss value.

• Destination Min Expected Spanloss: Destination node's minimum expected span loss value.

• Destination Max Expected Spanloss: Destination node's maximum expected span loss value.

• Span Loss: Span loss table.

Note	On Topology tool tip information it is possible to add a description and save.

NCS1K4-OTN-XP Supported Component

The NCS1K4-OTN-XP line card supports three pluggables, each with two trunks. Each pluggable supports different card modes based on its type. See COSM Configuration Guide for more details.

The NCS1K4-OTN-XP pluggables are:

• CFP2

• QDD-400G-ZRP

• DP04CFP2-M25-K9

NCS1K4-OTN-XP FEC Modes

The Forwarding Error Correction (FEC) modes supported on the NCS1K4-OTN-XP line card are:

• CFEC

• OFEC

NCS1K4-2-QDD-C-K9 Supported Components

The NCS1K4-2-QDD-C-K9 line card supports fixed trunks and the components as given in the table.

OCH Circuit Trail Provisioning for NCS1K4-OTN-XP and NCS1K4-2-QDD-C-K9 Cards

CONC 24.3.1 supports and provides OCH circuit trail provision for the NCS1K4-OTN-XP and NCS1K4-2-QDD-C-K9 line cards.

Audit Logs

The Audit logs option helps in:

• Auditing all the Cisco Optical Network Controller operations which include provisioning, Cisco Optical Network Controller and COSM user login or logout procedures and traffic related operations that are done on COSM or node.

• The logs can be used to learn about all the changes that have occurred as a result of external notifications that come from connected nodes.

  Note	Audit logs are not added for configurations which are done on the devices before the device discovery.

Display Features

• Pagination and filter options are available for Audit logs.

• Filter option is set to All by default.

Categorization of Audit Logs

Audit logs are categorized into:

Note

Only admin or internal users can view logs, collect techdump, download or delete archive files and schedule archive. Only users with read-only permission and the supervisor users can view the archived files and collect techdump. The user names are based on the type of user. The User Name field is marked as [Unknown] for a few scenarios. For example: when the user login authentication fails, because of incorrect credentials you get this message: User failed while logging in due to invalid CSRF token.

Debug Logs

Under Debug logs, all the developer logs are displayed with filters and pagination. There is also an option to enable and disable debugging of all services. Also, similar to the Audit logs, the Debug logs have the logs active for up to seven days. After seven days these logs get archived, from where they can also be downloaded.

Note	Debug logs that are older than one month are cleared, as they are retained only for a month.

Retention and Archiving and Archive Logs

The Audit logs can be retained and saved as given.

• Audit logs are retained for up to seven days which can be viewed online using the Logs application.

• Logs beyond seven days are archived and kept in the Cisco Optical Network Controller storage. The Archive logs are maintained for three months and are deleted later.

• The archived logs can be downloaded any time by using the Archive tab in the Logs application.

• The Audit logs archiving can be scheduled weekly using the Audit log scheduler.

• The active Audit logs are visible in the Audit log table for up to seven days after which they are moved to the Archive logs.

• The archived logs can be retrieved anytime and are available in the archive tab. Archived logs which are more than three months old are deleted by Cisco Optical Network Controller by default.

• You can download or delete the archived logs anytime. You can also suspend or resume archiving of logs anytime.

Archive Logs

The Archive logs allow you to schedule the logs. It consists of two schedulers:

• Audit logs job scheduler: Refers to all the archived audit logs.

• Debug logs job scheduler: Refers to all the archived developer logs.

  Note	Techdump: Refers to the on-demand collection of logs from the services which are displayed in the table. It collects the data base (DB) snapshots for all the services. You can collect or download and also delete these logs from the table.

Note

The Archive logs are saved as tar zip files. The Suspend and Modify options can be used to suspend, resume or modify the archived logs. The Modify option works on a weekly basis and you can also set any day as the value as per your requirement. The archived audit logs are stored for up to three months where as the developer logs are stored for one month. When one archive collection is proceeding, it is recommended to not change the scheduler time as otherwise it can lead to generation of multiple In Progress tasks.

Sedo Commands

For any issues with the logs, you can collect the techdump data and use the sedo command logs and report them.

The sedo commands are as given:

1. Step 1:

   Use edo diagnostics archive-logs /tmp/logs to collect all service 7 days logs. It collects logs and stores them in the /tmp/logs directory with the file name nxfos-logs-xxxxxxx.tar.gz.

2. Step 2:

   Use the scp command to copy nxfos-logs-xxxxxxxx.tar.gz file to the local system.

Download of developer archive logs will time-out when logs are too huge, then it is recommended to use the sedo commands to download:

1. Step 1:

   Use the command sedo object-store list onc-torch-service-dev-log-data-archives which lists all archived files under the developer logs.

   For example:

   Ex : root@abrageor-nxf:~# sedo object-store list onc-torch-service-dev-log-data-archives
   ┌─────────────────────────────┬──────────────┬───────────────────────────────┐
   │ OBJECT                      │ SIZE (BYTES) │ LAST MODIFIED                 │
   ├─────────────────────────────┼──────────────┼───────────────────────────────┤
   │ devlogs_2024-09-20T12_40_00 │     13606281 │ Fri, 20 Sep 2024 12:47:01 UTC │
   │ devlogs_2024-09-22T07_31_00 │    175939085 │ Sun, 22 Sep 2024 08:58:12 UTC │
   └─────────────────────────────┴──────────────┴───────────────────────────────┘
   

2. Step 2:

   Use the command sedo object-store get onc-torch-service-dev-log-data-archives/devlogs_2024-09-20T12_40_00 to download from the current directory. devlogs_2024-09-20T12_40_00 is the file name list taken from the Step 1 output.

3. Step 3:

   You can download the file to the local system.

Benefits of Logs Enhancement

Log enhancements help in:

Purpose of Acknowledged Alarm Mute

By enabling the Mute Acknowledged Alarms toggle switch option to True, you can hide the acknowledged alarms and disable them from appearing in the Workspaces, Service Assurance and Topology summaries and alarms lists, even if they are available in the Alarms application.

Benefits of Using Acknowledged Alarm Mute Option

The acknowledged alarm mute option allows you to have only the selected alarms appearing in the screen, instead of the entire set of all the acknowledged alarms. This helps in reducing unwanted clutter on the screen. As all the unnecessary acknowledged alarms that you do not want to be displayed can be hidden using this option.

Muting the Acknowledged Alarms

To mute the alarms on the screen:

1. Acknowledge the alarm from the Alarm screen.

2. Toggle the Mute Acknowledged Alarms button to True.

Note

Once an alarm is acknowledged, and the toggle switch button is set to True, the alarm will no longer be visible in the Topology, Service Assurance, Network Monitoring, and Circuit Monitoring screens. Node and link colors take the color of the highest severity unacknowledged alarms on each node and link.

Notifications for Acknowledged Alarm Mute

Whenever the alarms are acknowledged and muted, related notifications are sent on the screen. The scenarios for the notifications are as given:

• Notifications are sent to inform all users of any toggle changes, prompting them to refresh their pages to see updates.

• When an alarm is acknowledged and the Mute Acknowledged Alarms button is set to True, notifications are sent updating device and link summaries. This occurs only if 10 or fewer alarms are acknowledged.

• Whenever a new alarm is raised, cleared or updated new notifications are sent. But when an alarm is cleared, its acknowledgement status is lost due to which you must reset it back again.

• Acknowledged alarms are excluded from the Topology, Service Assurance, Network Monitoring and Circuit Monitoring applications when the Mute Acknowledged Alarms toggle switch is set to True.

  Note

  A restriction is placed on the number of alarms that can be acknowledged at once. This is to ensure a single notification is sent, prompting users to refresh their pages. When you select the circuit, the respective alarms in the circuit that are not acknowledged are displayed when the Mute Acknowledged Alarms is set to ON. In the Topology screen you will be able to view the count of such alarms. In the Circuit Monitoring screen you will be able to see these alarm details. The Mute Acknowledged Alarms option can be used in the Network Monitoring application as well. Only the admin user or the supervisor with admin access can mute the acknowledged alarms using the Mute Acknowledged Alarms toggle switch.

Purpose of Implementing PM History Application

The PM History application allows you to view and generate PM history data reports for interfaces that are part of the nodes. For the sequential selection of each parameters in the order of nodes, interval, selected date time range, interface types, port name and locations.

Benefits of Using PM History

The benefits of using PM History are given in the table.

Time Range for Fetching Data

You can pick the start date or time and the end date or time based on the data stored in Cisco Optical Network Controller, for active and archive data by using the date-time input picker. The different time range options available for fetching the data are listed in the table.

Data Collection and Storage

PM data will be collected in 15 minutes and 24 hours time intervals from the onboarded COSM nodes and stored in a database. The data and activity logs are stored in the form of storage bins. The data is fetched based on what you choose as the start or end date and time values. Any data which is more than three months old is archived. Use the Get Archive option to get the archived PM History data.

Types of PM History Reports

You can download the archived data in the form of 15-minute or 24-hour granularity report type. The PM History reports are of two types based on the different granularity levels and time intervals.

Note

For both 15-Minute or 24-Hour granularity PM report, you can use the horizonal scroll bar to adjust the dates as per your need. For 15-Minute granularity archive data is available for download from 3 to 5 days and for 24 hours granularity from 31 to 93 days. If the date range falls on archive data then you will receive a message to indicate the user has chosen a time range which coincides with the archived data time range.

Data Representation

The PM history data is also represented in a graphical format.

PM Job Scheduler

The PM job scheduler manages the PM tasks as given:

• PM history.

• It generates one-time, daily, weekly, and monthly historical PM reports based on the job criteria and Cisco Optical Network Controller entities like circuits or services, links, and ports.

  Note	None: one time applicable for both 15 minutes and 24 hours. Daily: is applicable only for 15 minutes. Weekly and Monthly: are applicable only for 24 hours.

• Reports are sent through email which is configured through SMTP server and which are not password protected.

PM History in Network Monitoring

The Network Monitoring workspace now includes a new tab for PM History span loss reports, featuring both graphical and table representations. The dashboard display updates based on selections made in the Topology application and the user selected time range.

Note	You must select the OTS link in the Topology application to view the spanloss values in the table.

PM History in Topology

In the Topology application, the PM history tab:

• Interacts with the Topology application and its components.

• Helps in viewing the span loss changes and information.

PM History in Circuit Monitoring

The Circuit Monitoring workspace will now feature a new dashboard in the detailed service path component, displaying PM History data. This new add-on dashboard has the Detailed Service Path component which displays the PM values based on selected port.

The historical data for a particular port from the Detailed Service Path can be seen for 15 minutes and 24 hours interval. You can also select the start and end date. PM values for ports are displayed in the tabular and graphical formats.

Note	Right click on the port on Detailed Service Path and use the option to launch PM History for that port. Also you can choose up to two ports.

Service Endpoint PM History Report

The PM History application jobs dashboard report in service endpoint helps in:

• Calculating and presenting total availability or outage time and percentage.

• Exporting to Excel and scheduling job options if available.

Graphical Representation within PM History Application

The linear graph displays ALL/VALID/PARTIAL PM values. Also, the NA values do not have any representation in the graph.

Note	Partial is represented in yellow.

Configuration in PSM Circuits

PSM supports two-way configurations and can be manually configured. Out of the two paths one will be active and the other will be a standby path. Whenever the active path fails due to fiber cut then the standby path is used for receiving the signal. This is because both the active and standby paths are always used in the TX direction for transmitting the signal, but only one of them can be used to receive the signal at a time.

Note	PSM supports both automatic and manual path switching. Once you cross launch to COSM, there is also a manual switch option provided there for you to select any path and use it as the active path in the PSM circuit.

Benefits of PSM

The benefits of using PSM are:

• Enhanced network reliability and protection through PSM fiber protection.

• Improved network management and monitoring with clear visualization of active and standby paths in the circuits.

• Flexibility in network design with support for various connection scenarios for PSM.

• Comprehensive event logging and user-driven OAM for better operational control. See Configuration Guide for Cisco NCS 1001.

• Being multiplexer-agnostic ensures compatibility with various network components.

Note	ILA sites are not supported in 24.3.1 release, refer to the P2P scenario.

Additional PSM Functions

PSM generates alarms and performs automatic path switching with minimal data loss. PSM is integral to circuit creation and can be deployed in any network segment for protection. Additionally, it includes features for monitoring channel power and composite power.

PSM Circuit in Service Manager

In the Service Manager application, the PSM circuit is created like any other circuit using the Provision Circuit option. Once the PSM circuit is installed and it appears in the Services screen it can be visualized in the Service Assurance and the Workspace applications.

Purpose of Using SWIMU in Cisco Optical Network Controller

To enable support for the Cisco Optical Network Controller software image and node configuration database files storage and distribution. To help in the backup, restoration and upgrade of the software.

Note	For 24.3.1 release only the node configuration database backup and restore is supported.

Benefits of Using SWIMU

Using SWIMU you can backup the node configuration database and upload it to external or internal SFTP servers. Files can be distributed and saved to and from the COSM devices while providing granularity to the underlying devices. It helps in:

• Centralized Management: Provides a single interface for managing backups, restores, and upgrades.

• Granular Control: Allows detailed configuration of nodes used while scheduling a backup job on top of a node.

• Manage Tasks: It helps managing file storage, distribution, scheduling, and monitoring based tasks.

• Efficiency: The distribution and scheduling prevent network overload and ensure efficient operations.

• Flexibility: Supports ad-hoc backups with detailed scheduling options.

• Transparency: Allows to track the progress with notifications to keep users informed of task statuses.

• Long-term Storage: Ensures backup files are stored for an extended period, with configurable storage options.

Note	Granularity happens at the node level but not at the device which is under the node level. Restore can be done at the device level through COSM nodal UI using the cross-launch option in Cisco Optical Network Controller Nodes or SWIM applications.

Backup Capabilities

Backup capabilities include:

• Creating backup tasks by selecting groups, scheduling, and providing descriptions.

• Scheduling options for hourly, daily, weekly, and monthly configurations.

• Storage of backup files for at least 12 weeks, with user-configurable storage size for external SFTP server.

• Local SFTP server will retain up to five backup files per node.

  Note	User-configurable storage size is supported, and Cisco Optical Network Controller can initiate file overwriting to prevent disk memory from becoming full.

SFTP Servers

There are two types of SFTP servers allowed for backup and restore purpose.

• One internal SFTP server: It is the default SFTP server provided by Cisco Optical Network Controller itself which stores the backup DB in Cisco Optical Network Controller database.

• Two external SFTP servers: It is the external SFTP servers that you can configure for Cisco Optical Network Controller DB backup or restore as part of external server storage or upload.

Restore Capabilities

Download backup files to the node from SFTP servers and initiate the restoration process once the download is completed.

• You can initiate file upload from external or internal SFTP server to COSM node(s) through Cisco Optical Network Controller.

• You can cross launch to COSM nodal UI from Cisco Optical Network Controller by clicking on the IP address of the node. You can also use the SWIMU application Nodes table, with additional information present in a separate column called Upload to Node option for restoration.

Note	Cisco Optical Network Controller UI job summary table indicates the status of the on-going jobs for success or failure for backup and upload jobs. Restoration is applicable outside of Cisco Optical Network Controller, after cross launching to COSM nodal UI.

Types of Backup

There are two types of backup:

Formula for Calculating External Backup Storage Size

To calculate the storage size required for backup for external and internal SFTP servers use the given formula:

External SFTP Server Storage Formula

Backup Storage Size = (Network Total Devices x Size of Device x Requested Archive Period) / Backup Re-occurrence

Internal SFTP Server Storage Formula

Backup Storage Size = ( (Number of Small Nodes * 4.7 MB) + ( Number of Medium Nodes * 4.85 MB) + (Number of Large Nodes * 5.1 MB) + ( Number of XL Nodes * 5.4 MB) ) * 5

Cleanup of Storage

The cleanup of the storage in SFTP servers will be done based on the memory threshold value set by the user during the configuration of the SFTP server. The minimum threshold value is 50 and this is specific to external SFTP servers only.

Purpose of Using NLAC

When a fiber cut occurs, it triggers a Loss of Continuity (LOC) alarm, which is then correlated with other Loss of Signal-Payload (LOS-P) alarms in the circuit. The root cause alarm, typically the LOC, suppresses other alarms, ensuring that subsequent LOS-P alarms depend on the LOC rather than the Automatic Laser Shutdown (ALS) alarms.

Benefits of Using NLAC

The benefits of using NLAC are:

• Efficient Alarm Management: Ensures that only the root cause alarm is focused on, reducing the noise from multiple alarms.

• Quick Fault Isolation: Helps in quickly identifying and isolating the root cause of network issues.

• Improved Network Reliability: By correlating alarms effectively, it enhances the overall reliability and performance of the network.

• Simplified Troubleshooting: Makes it easier for network administrators to troubleshoot and resolve issues by providing clear alarm correlations.

Scenarios for Using NLAC

There are multiple scenarios which specify how NLAC is used, some of them are:

• Unidirectional Fiber Cut:

  • Correlation Mechanism: LOS to LOS-P: Forward direction

  • Correlation Mechanism: ALS to LOS-P: Reverse direction.

  • Multiple LOS in Forward Direction: For multiple LOS scenarios both in upstream and downstream circuits.

• Bidirectional Fiber Cut:

  • Correlation Mechanism: LOS to LOS-P: Forward and reverse direction.

  • Correlation Mechanism: ALS to LOS-P: Reverse direction.

  • Multiple LOS in Forward or Reverse Direction: For multiple LOS scenarios both in upstream and downstream circuits.

  • New LOS in Reverse direction: For new loss in the downstream circuits.

  Note	In the bidirectional scenario, we will have LOS and LOS-P correlations in both the directions. In addition, we will also have ALS to LOS-P correlation up to the port where we have the LOS. In this situation, LOS will correlate to all LOS-P downstream.

NLAC LOC and LOS-P Alarms

These alarms can be viewed in the Alarms and Workspaces applications for each node.

Note

Alarms that are suppressed display a suppressed tag in the alarms panel till you refresh. Alarms that are the root cause display the + icon next to them and when you click this icon it displays all the suppressed alarms. Links and nodes that have the suppressed alarms are not included in the summary and list of alarms in Workspaces, Service Assurance and Topology. A link with suppressed LOS-P does not consider LOs-P as its highest severity

Installing Syslog on Server

To install syslog feature on the server run the CLI commands given in the example:

Create the rsyslog server using steps provided in below website
		https://www.makeuseof.com/set-up-linux-remote-logging-using-rsyslog/

To create the folder structure 
		AUDIT logs here → /var/log/<host-ip>/audit.log
		ONC service logs here → /var/log/<host-ip>/service_logs/

Add the below lines in the rsyslog.conf file
		$ModLoad imudp
		$UDPServerRun 514

		Input (type="imudp" port="514" ruleset="rs1")

		template (name="ServLogLoc" type="string" string="/var/log/%FROMHOST-IP%/service_logs/%syslogtag%.log")
		template (name="AuditLogLoc" type="string" string="/var/log/%FROMHOST-IP%/audit.log")

		Ruleset (name="rs1") { 
		:msg, contains, "AUDIT" ?AuditLogLoc 
		*.* ?ServLogLoc
		}
		
Restart syslog server using command,
		systemctl restart rsyslog

Check if rsyslog service is active and running using command,
		systemctl status rsyslog

Installing Syslog on Client

To install syslog server forwarding in client run the CLI commands in the example:

sedo syslog server create <IP> <PROTOCOL> <IP> <PORT>
         IP is the address of the syslog server.
         Protocol to be used - udp or tcp.
         Port on which syslog server is listening to (default is 514)

To create a syslog query to forward the apllication logs of a particular ONC app:
	sedo syslog query create '{namespace="onc", app="<app_name>", container="app"}' LOG_INFO LOG_USER <app_name> <IP>

Note: The query inside single quotes is Grafana Loki's logQL, it can be tweaked according to user needs

To list all syslog queries:
	sedo syslog query list

To list all syslog servers:
	sedo syslog server list

To delete a syslog query:
	sedo syslog query delete <QUERY_ID>

To delete a syslog server:
	sedo syslog server delete <IP>