This topic is a chance to discuss more about the installation, provisioning, operation and best troubleshooting practices on Cisco Dense Wave Division Multiplexing (DWDM) transport systems, with particular focus on NCS 2000 series. This session will provide you with a better understanding of the installation and troubleshooting practices of the initial setup of DWDM networks, RAMAN calibration and OTDR tracing that helps to enhance quality of RAMAN installation.
Enhance your installation practices and troubleshooting skills and reduce down time during maintenance windows with tips and recommendations from Cisco Technical Experts.
To participate in this event, please use the button below to ask your questions
Ask questions from Monday, April 2nd to Friday 13th 2018
Valery Kayukov is a System Architect Engineer with over 1 decade of experience in the It industry. Currently he works as a Lead System Engineer at the Step Logic Group LLC. Valery specializes in Optical Transmission Network, SAN Networking and Storage and Computing technologies (DWDM, SDH, OTN). In addition, he has experience in network programmability particularly on C++ and Python programming. Valery holds a Bachelor’s degree in Networks and Telecommunication Systems and several certifications such as, CCNP, CCDA, CCDP and Brocade - BCFP, BCFD among others.
Carlos Amador is a Technical Support Engineer with over 6 years of experience in the IT industry. He works as a HTE and Teach Lead for the Optical accounts of Telex, Mexico’s biggest communication company. Carlos specializes in Optical Transmission Network technology (DWDM, OTN, SDH and Sonet. Before Cisco, he has worked over a decade commissioning and integrating Optical and Microwave networks in Nortel and Axtel. He holds a Bachelor’s Degree in electronics and communications engineering.
Valery & Carlos might not be able to answer each question due to the volume expected during this event. Remember that you can continue the conversation at the Optical Networking Category.
Find other events or open new discussions https://supportforums.cisco.com/t5/community-ideas/bd-p/5911-discussions-community-ideas
**Ratings & Helpful Votes Encourage Participation! **
Please be sure to rate the Answers to Questions
CPU and RAM utilization is part of Controller card on DWDM chassis.
which can be a TCC2P, TCC3 or TNC card series.
you can get RAM and CPU utilization through VxWorks by doing telnet into the node.
SNMP will not be going to show that information, because Controller cards don't share that info.
Hi there! Do Cisco ONS15454/NCS2000 devices have the capability to report long-term fiber performance charts (at least per month and per year) based on optical line attenuation measurements?
Is it possible to see or measure Fiber cut, Fiber degradation?
Each ONS\NCS system\node can store optical performance for 32 number of intervals divided by 15 minutes. For long-term storage of statistics need to use Cisco Prime Optical server, witch could store optical performance statistics as long as you want.
Cisco NCS\ONS systems have many optical thresholds for many optical ports depending on card type. These optical thresholds calculated automatically by Cisco Transport Planner prior installation and could be modified during installation and maintenance windows.
Fiber cut could be detected by alarm Loss of Signal, also distance from fiber end to fiber cut could be detected by new TNC-O card with OTDR feature included in SFP for Optical Service Channel.
We have five NCS2000 devices on a roadm dwdm network and we're experiencing an anomaly on snmp data collection.
When the network was done, we started to monitor the network nodes with a test NMS based on PHP.
Everithing goes fine, collections worked properly and graphs appears complete.
At the end of the first test period, we moved the devices under production monitoring sysrtem OpenNMS.
Using that tool, which is working fine with all the other devices of our wan network (hundreds of routers, switch ecc...),
the data collection on the NCS2000 seems to have stale problems, with lack of snmp responses for minutes.
Consequently, the generated graphs have lots of missing segments.
Trying to add the test NMS in parallel, which was working fine at the starting time, it doesn't collect any data during the "issue time".
Is it possible to check the CPU of the controller card of NCS to understand if there are some performance problem during the lack of responses?
Do you have any other suggestion to investigate further ?
Thanks a lot, regards
CPU utilization. For a long time there were no cases of a high load of the system. If there are hight CPU it mean that system making DB backups or clearing memory. You can manually perform pulling through telnet CPU or memory performance by command in VxWorks "memShow" but any penetration in VxWorks without TAC recommendation is unsupported. Such penetration by negligence can lead to system failure.
NCS nodes accessibility. You have to describe how Data Network Communication Network (DCN) have been build. If you use Ethernet LAN port on each node connected to separate LAN network than you have to use GNE mode on each node. If you haven't got LAN connection on each site you have to use ENE mode excluding site witch connected to LAN and to NMS system. Please check reference guide and follow appropriate recommendation:
Any way you can draw your network with LAN connections, we will review and recommend best provisioning modes for your setup.
tnx for the reply.
Our network is a linear network, with 3 internal nodes and 2 edge.
Services are provided in 4 of 5 nodes, one is a simple ILA.
We use external LAN connection with OSPF to reach any node, with a different local subnet in each node.
We also enabled OSPF on the OSC channel, in order to be able to reach any node directly through the dwdm network in case of outages of the external LAN.
To achieve this result each node was configured on the provisioning network tab with "Enable Socks Proxy / Socks Proxy Only".
A part of that, I think the problem is not related on the connectivity model because of the correct behaviour with the first test NMS system, used at the beginning during the deployment of the network.
It seems to be more related on the dialog with the production NMS (OpenNMS) or in the way the TNC-E manage the kind of request it sends.
When the issue happens, the node doesn't reply to any simple single snmp-get for some minutes.
CPU load/stalled was one of my suppositions, but maybe could be other. Do you have any idea ?
To investigate issue need to perform some tests:
1. Check mem-low alarm in CTC
2. Reset control cards on any node and check snmp again
3. Check firewall between nodes and NMS system
4. Check GNE mode on nodes connected to LAN and ENE mode on nodes not connected to LAN. It could lead to short-term loss of communicatiion in CTC.
5. Check snmp walk tool from any other machine