Note |
Explore the Content Hub, the all new portal that offers an enhanced product documentation experience.
Get started with the Content Hub at content.cisco.com to craft a personalized documentation experience. Do provide feedback about your experience with the Content Hub. |
Cisco Optical Network Controller Overview
Cisco Optical Network Controller (ONC) is an SDN Domain Controller for Cisco Optical Networks. ONC collects optical data which is used to provide network information in an abstracted format to higher layer controllers. This abstraction enables a centralized control of a Cisco Optical Network.
Some of the features of Cisco ONC are:
-
Serves as a domain controller for optical products and provides data to Hierarchical Controllers. ONC supports a standardized TAPI model which enables it to abstract the device level details from hierarchical controller.
-
As a Provisioning Network Controller (PNC), monitors the topology (physical or virtual) of the network, and collects information about the topology, and setup/teardown of optical circuits.
-
PCE service provides optical path computation to other Cisco ONC services.
What's New in Cisco Optical Network Controller, Release 2.0
Cisco is continuously enhancing the product with every release and this section covers a brief description of key features and enhancements. It also includes links to detailed documentation, where available.
Feature | Description |
---|---|
NCS1010 support |
Cisco ONC 2.0 onboarding of NCS 1010 devices and discovery of NCS 1010 inventory, links (OLT and ILA), and OCHNC services. Cisco ONC provides alarms information for the NCS1010 platform. The information is live data from NCS1010 platform, collected on demand from the platform when you open the alarms page in the UI. Cisco ONC supports a logical node model or site to aggregate multiple physical devices to create an aggregated optical domain node. This feature enables simpler management of NCS 1010 ROADM sites. |
Multicarrier support |
Cisco ONC 2.0 supports the following multicarrier configurations:
Cisco ONC 2.0 supports OCH-NC and OCH-Trail service types with multicarrier configurations. |
Planning Data Import |
Cisco ONC 2.0 can import planning data generated as a json file by Cisco ONP 5.0. You can push the imported configuration to the planned devices in the network. |
Alien support |
Cisco ONC 2.0 topologies support non-Cisco optical products and Cisco nonoptical platforms as alien devices. Cisco ONC 2.0 supports alien wavelengths provisioning to include performance verification. You can add alien transceivers specs and the PCE calculates a circuit that meets the required alien transceiver specs. For NCS 1004 nodes, you can manage all possible NCS 1004 configuration modes. ONC 2.0 will manage following nonoptical platform trunks as alien interfaces:
|
Connection Verification |
Cisco ONC 2.0 provides connection verification for NCS 1010 platform. Connection verification checks cable connections against the expected connections. During connection verification, Cisco ONC generates the tone from OLTs and detects the tone on passive modules to verify the connection against the expected connections. Connection Verification service generates the tone and measures the patch loss by reading the power values. |
Improved Integration with Crosswork HCO |
Cisco ONC 2.0 supports improved integration with Cisco Crosswork HCO. Cisco ONC allows monitoring of all network elements and services in a managed network. |
Software and Hardware Requirements
Before installing Cisco ONC, you must install Cisco Crosswork Infrastructure 4.4.
The infrastucture requirements for installing Cisco Crosswork are listed below. For complete installation requirements, see the Cisco Crosswork Infrastructure 4.4 and Applications Installation Guide.
Data Center Requirements
Cisco Crosswork can be deployed in either a vCenter managed data center. To aid in the deployment, Cisco has developed a cluster installation tool. This tool works in both environments. However, there are limitations to the tool which are detailed later in this section.
Note |
|
VMware Data Center Requirements
This section explains the data center requirements to install Cisco Crosswork on VMware vCenter.
Note |
The following requirements are mandatory if you are planning to install Cisco Crosswork using the cluster installer. If your vCenter data center does not meet these requirements, then the VMs have to be deployed individually, and connectivity has to be established manually between the VMs. |
-
Hypervisor and vCenter supported:
-
VMware vSphere 6.7 or above
-
VMware vCenter Server 7.0 and ESXi 7.0.
-
VMware vCenter Server 6.7 (Update 3g or later) and ESXi 6.7 (Update 1)
-
-
All the physical host machines must be organized within the same VMware Data Center, and while it is possible to deploy all the cluster nodes on a single physical host (provided it meets the requirements), it is recommended that the nodes be distributed across multiple physical hosts.
-
The networks required for the Crosswork Management and Data networks need to be built and configured in the data centers, and must allow low latency L2 communication.
-
To allow use of VRRP, DVS Port group needs to be set as follows:
Property Value Promiscuous mode
Reject
MAC address changes
Reject
Forged transmits
Accept
To edit the settings in vCenter, navigate to the Host > Configure > Networking > Virtual Switches, and select the virtual switch. In the virtual switch, select Edit > Security and confirm the settings as suggested. Repeat the process for each virtual switch used in the cluster.
-
Ensure the user account you use for accessing vCenter has the following privileges:
-
VM (Provisioning): Clone VM on the VM you are cloning.
-
VM (Provisioning): Customize on the VM or VM folder if you are customizing the guest operating system.
-
VM (Inventory): Create from the existing VM on the data center or VM folder.
-
VM (Configuration): Add new disk on the data center or VM folder.
-
Resource: Assign VM to resource pool on the destination host, cluster, or resource pool.
-
Datastore: Allocate space on the destination datastore or datastore folder.
-
Network: Assign network to which the VM will be assigned.
-
Profile-driven storage (Query): This permission setting needs to be allowed at the root of the DC tree level.
-
-
We also recommend you to enable vCenter storage control.
VM Host Requirements
This section explains the VM host requirements.
Requirement |
Description |
||
---|---|---|---|
CPU/Memory/Storage Profiles (per VM) |
The data center host platform has to accommodate three VMs of the following minimum configuration: VMware vCenter:
Cisco CSP:
Few things to note:
|
||
Additional Storage |
10 GB (approximately) of storage is required for the Crosswork OVA (in vCenter), OR the Crosswork QCOW2 image on each CSP node (in CSP). |
||
Network Connections |
For production deployments, we recommend that you use dual interfaces, one for the Management network and one for the Data network. For optimal performance, the Management and Data networks should use links configured at a minimum of 10 Gbps. |
||
IP Addresses |
Two IP subnets, one for the Management network and one for Data network, with each allowing a minimum of four assignable IP addresses (IPv4 or IPv6). A Virtual IP (VIP) address is used to access the cluster, and then three IP addresses for each VM in the cluster. If your deployment requires worker nodes, you will need a Management and Data IP address for each worker node.
|
||
NTP Servers |
The IPv4 or IPv6 addresses or host names of the NTP servers you plan to use. If you want to enter multiple NTP servers, separate them with spaces. These should be the same NTP servers you use to synchronize the Crosswork application VM clock, devices, clients, and servers across your network.
|
||
DNS Servers |
The IPv4 or IPv6 addresses of the DNS servers you plan to use. These should be the same DNS servers you use to resolve host names across your network.
|
||
DNS Search Domain |
The search domain you want to use with the DNS servers, for example, cisco.com. You can have only one search domain. |
Important Notes
-
Cisco Crosswork Infrastructure and applications are built to run as a distributed collection of containers managed by Kubernetes. The number of containers varies as applications are added or deleted.
-
Dual stack configuration is not supported in Crosswork Platform Infrastructure. Therefore, all addresses for the environment must be either IPv4 or IPv6.
Caveats
Open Caveats
The following table lists the open caveats for Cisco ONC 2.0
Identifier |
Headline |
---|---|
R2.0 - deleted connectivity-service is still present in TAPI and OSM response |
|
Post reload or fiber cut: OMS fiber link is not present in TAPI model intermittently |
|
after disabling a line port of an OLT, fiberspan and oms link disappeared |
|
Chaos - Resync for 183 SVO + 10 NCS1010 devices taking more than 30 mins |
|
Connection service and cross-connections inconsistency between OSA and NBI after repeat re-creation |
|
NCS1010 ILA device cannot be delete if added under the same site of another ILA device |
|
NBI notification generated twice while adding ncs1010 devices via bulk import |
|
after passive connect/disconnect many unexpected NEPs of OTS layer found in TAPI |
|
a passive pre-provision request may be rejected bcs slot not empty but the slot was in fact empty |
|
creating a brownfield circuit (BRK8), the circuit was not shown in the OSA model |
|
Auto Resync fails in CONC after NCS1010 is reloaded using reload location all cli |
|
Passive addition - Fixed - Validation in the MM response failed for addition for fixed passive |
|
After a passive was connected in a pre-provisioned slot, resync failed |
|
wrong data at TAPI and OSA (DBs misaligned) while performing card plug-in / plug-out |
|
JT: NCS1010 inventory changes are not detected dynamically and requires resync |
|
PCE channel failed for some application code as 00B08E#NCS1K4-1.2T-K9#3#1576#R200G |
Exceptions
Connection Verification can be performed only when there is no service present on the patch-cord . Full management of OOB verification when services are present and patch loss measurement is planned in future releases.
CONP planning data input must be in lower case.
In case of fiber cuts, the link gets removed from TAPI topology and gets re-added with restore.
Bug Search Tool
Cisco Bug Search Tool (BST) is a web-based tool that acts as a gateway to the Cisco bug tracking system that maintains a comprehensive list of defects and vulnerabilities in Cisco products and software. BST provides you with detailed defect information about your products and software.
Using the Cisco Bug Search Tool
You can use the Cisco Bug Search Tool to search for a specific bug or to search for all bugs in a release.
Procedure
Step 1 |
Go to the http://tools.cisco.com/bugsearch. |
Step 2 |
Log in using your registered Cisco.com username and password. The Bug Search page opens. |
Step 3 |
Use any of these options to search for bugs, and then press Enter (Return) to initiate the search:
|
Step 4 |
When the search results are displayed, use the filter tools to narrow the results. You can filter the bugs by status, severity, and so on. To export the results to a spreadsheet, click Export Results to Excel. |
Other Important Information and References
Scale Support
-
Device Onboarding
-
Cisco ONC 2.0 supports up to 750 devices.
-
You can onboard up to 200 devices at a time, for a bulk import. Wait for the previous batch to complete before importing the next batch.
-
When the bulk import operation ends, Crosswork HCO shows all the relevant information.
-
When onboarding devices that have configuration already present on them, onboarding can take longer depending on the number circuits present on the device.
-
-
Circuit Provisioning
-
Cisco ONC 2.0 allows you to create 4 circuits in a minute. We recommend you wait for the previous provisioning operation to complete before initiating a new one.
-
On SVO setup
-
Time taken for OCHNC circuits to go to Installed state depends on the number of fiber spans involved.
-
We recommend 75-seconds delay between each circuit provisioning.
-
-
On an NCS 1010 5-node point-to-point setup
-
OCHNC circuits typically go to Installed state in 20–60 seconds.
-
We recommend 45-seconds delay between each circuit provisioning.
-
-
-
Device deletion
-
We recommend you delete not more than 10 devices together and wait until the device deletion is complete. You can either monitor the NBI Notifications or wait for 5 minutes between each operation to ensure complete deletions.
-
Cisco Optical Network Controller Documentation
This section lists the guides that are provided with Cisco Optical Network Controller, Release 2.0.
Title |
What is included |
---|---|
|
|
|
|
|