Tnms SNMP Nbi - Operation Guide
Tnms SNMP Nbi - Operation Guide
V15.10
Coriant TNMS
SNMP NBI Operation Guide (SNOG)
The information in this document is subject to change without notice and describes only the product
defined in the introduction of this documentation. This documentation is intended for the use of
Coriant customers only for the purposes of the agreement under which the document is submitted,
and no part of it may be used, reproduced, modified or transmitted in any form or means without the
prior written permission of Coriant. The documentation has been prepared to be used by professional
and properly trained personnel, and the customer assumes full responsibility when using it. Coriant
welcomes customer comments as part of the process of continuous development and improvement of
the documentation.
The information or statements given in this documentation concerning the suitability, capacity, or
performance of the mentioned hardware or software products are given "as is" and all liability arising
in connection with such hardware or software products shall be defined conclusively and finally in a
separate agreement between Coriant and the customer. However, Coriant has made all reasonable
efforts to ensure that the instructions contained in the document are adequate and free of material
errors and omissions. Coriant will, if deemed necessary by Coriant, explain issues which may not be
covered by the document. Coriant will correct errors in this documentation as soon as possible.
IN NO EVENT WILL CORIANT BE LIABLE FOR ERRORS IN THIS DOCUMENTATION OR FOR
ANY DAMAGES, INCLUDING BUT NOT LIMITED TO SPECIAL, DIRECT, INDIRECT, INCIDENTAL
OR CONSEQUENTIAL OR ANY LOSSES, SUCH AS BUT NOT LIMITED TO LOSS OF PROFIT,
REVENUE, BUSINESS INTERRUPTION, BUSINESS OPPORTUNITY OR DATA,THAT MAY ARISE
FROM THE USE OF THIS DOCUMENT OR THE INFORMATION IN IT.
This documentation and the product it describes are considered protected by copyrights and other
intellectual property rights according to the applicable laws. Other product names mentioned in this
document may be trademarks of their respective owners, and they are mentioned for identification
purposes only.
Copyright © Coriant 2015. All rights reserved.
Table of Contents
This document has 98 pages.
1 Preface ........................................................................................................... 8
1.1 Intended audience........................................................................................... 8
1.2 Structure of this document .............................................................................. 8
2 Introduction ................................................................................................... 9
2.1 General description ......................................................................................... 9
2.2 SNMP protocol support ................................................................................. 10
2.3 Terminology .................................................................................................. 10
2.4 Differences to TNMS Core SNMP Proxy ....................................................... 11
2.4.1 General changes ........................................................................................... 11
2.4.2 Tables and fields ........................................................................................... 11
2.4.3 Notification behaviors .................................................................................... 12
2.4.4 Protocol support changes.............................................................................. 13
2.5 Installation and licensing ............................................................................... 13
2.6 MIB file location............................................................................................. 13
10 Troubleshooting .......................................................................................... 86
Abbreviations .............................................................................................. 89
Summary of changes
1 Preface
2 Introduction
The SNMP NBI provides the following functionality to the SNMP managers:
Network discovery and synchronization
- Lists of NEs, Modules, Ports, Termination Points (TPs) and Port
Connections (PCs)
- Notifications for network object creation (OC) and deletion
(OD), attribute value changes (AVC) and state changes (SC).
Fault management
The SNMP NBI MIB is based on the TNMS Core SNMP Proxy MIB, meaning
that their exported data models, as well as notification behaviors, are mostly
similar. However, some tables and fields are not yet supported. See section
2.4 for the main differences.
SNMP NBI also provides preliminary MEF MIB support for the retrieval of
Ethernet Paths (MEF 40).
2.3 Terminology
The term “SNMP manager” is used to refer any external system or application
that accesses TNMS via the SNMP protocol.
The term “SNMP agent” refers to the SNMP NBI component itself.
The term “EMS” refers to the TNMS system itself.
The term “trap” is commonly used to refer an SNMP notification, regardless of
it being sent as an SNMP TRAP or an SNMP INFORM.
Some objects are named differently in SNMP NBI MIB and TNMS. The table
below shows the equivalences.
Module Equipment
The MIB tables, table fields and table traps below are present in the SNMP
NBI MIB file, but will only be supported in the future.
Notification behaviors for Object Deletion events (OD) have been made
consistent among all network object types. Avoiding redundant OD traps helps
minimizing network and processing spikes in case of network changes.
As for the SNMP protocol support, the differences to TNMS Core’s SNMP
Proxy are:
The listening port is now configurable, to allow SNMP NBI to coexist
with other SNMP services on the server.
SNMP v1 is no longer supported, only v2c and v3.
Timeout and maximum tries of INFORM notifications are configurable.
<TNMS Home>\Docs\SNMP-NBI\TNMS-NBI-MIB.my
4. In Proxy name and Network name, enter informative names for this
SNMP NBI instance and for the network.
5. In Trap history length, specify the number of records to be kept in the
trap history table. The default is 256. Allowed values are between 2 and
10000. (See also 4.4 - Resynchronization after network or manager
errors.)
6. The MIB version is read-only and shows the version of the SNMP NBI
MIB. It matches the LAST-UPDATE clause in the MIB definition file, and
therefore can be used to check if an SNMP manager is using the correct
file.
7. Check Enable heartbeat traps if heartbeat traps are to be sent to the
listening SNMP managers.
In Interval, specify the number of seconds between heartbeats.
Default is 60 seconds. Allowed values are between 5 and 86400
seconds (equivalent to 24 hours).
8. In the Inform group, configure how SNMP INFORM notifications are
managed:
In Timeout, specify the maximum number of seconds that SNMP
NBI will wait for a response before resending an Inform. Default is
3 seconds. Allowed values are between 1 and 60 seconds.
In Maximum tries, specify the maximum number of times that
SNMP NBI will try to send an Inform notification to each
destination. Default is 3 tries. Allowed values are between 1 and 5
tries.
The Proxy name, Network name, Trap history length and MIB version
values above are readable via SNMP under the enmsControl MIB branch (see
section 8.1).
The Heartbeat and Inform configuration parameters are also modifiable via
SNMP under the enmsControl MIB branch (see section 8.1).
In the SNMP NBI User Management window (Figure 4) you may add, edit or
remove SNMP users. Next sections explain how to configure a user.
In the Identification tab (Figure 5) you specify the basic user details.
In the Accesses tab (Figure 6) you configure the user permissions for
incoming SNMP requests.
1. Select the level of permission granted to the user for accessing the SNMP
NBI MIB:
No permission – The user has no access permission.
Read – The user has read-only access.
Read/Write – The user has read and write access.
2. Specify the IP addresses from which requests from this user are accepted.
Both IPv4 and IPv6 addresses are allowed. Examples:
10.55.140.25
4f::58a3:45fe:38
Address format restrictions:
- Host names are not supported, only IP addresses.
In the Traps tab (Figure 7) you configure the SNMP TRAP destinations for the
SNMP user.
In the Informs tab (Figure 8) you configure the SNMP INFORM destinations
for the SNMP user.
In relation to fault management, all active alarms in the system are exported
via the table enmsAlarmTable. Other tables act as views of that master table,
showing only the alarms affecting a specific type of object (Figure 11).
coriant.svsProductMibs.svsProxEmns
enmsNetworkSetup
enmsNETable (5.1.1)
enmsModuleTable (5.1.2)
enmsPortTable (5.1.3)
enmsTPTable (5.1.4)
enmsPortConnTable (5.1.5)
enmsSNCTable (6.1.1)
enmsCCTable (6.1.4)
enmsEthernetPathTable (6.1.2)
enmsService
enmsServiceTable (6.1.3)
enmsAlarmTables
enmsAlarmTable (7.1.1)
enmsAlarmsForNETable (7.1.2)
enmsAlarmsForPortTable (7.1.3)
enmsAlarmsForTPTable (7.1.4)
enmsAlarmsForPortConnTable (7.1.5)
enmsAlarmsForSNCTable (7.1.7)
enmsAlarmsForModuleTable (7.1.6)
enmsProxy
enmsControl (8.1)
enmsTrapGroup
enmsTrapHistory
enmsTrapHistoryTable (8.4)
enmsTrapVariable
enmsTraps (5.2, 6.2, 7.2, 8.2)
enmsTrapFilter (8.3)
The following table shows what notifications are supported for each type of
modelled object:
CC None
In addition to the notifications for the modelled objects, there are also
notifications associated to the SNMP agent and the EMS themselves:
An out-of-sync situation may also occur if the SNMP manager does receive
the traps, but for some reason is unable to process them.
To help the SNMP manager to detect out-of-sync situations, all traps sent by
the SNMP NBI include a trap counter, which is incremented by one for each
trap. By checking this trap counter, it is possible detect if one or more traps
are missing.
In case an out-of-sync is detected, instead of resynchronizing all tables –
which can be a heavy and lengthy process – the SNMP manager may try first
to identify the objects associated to the missed traps by looking up the trap
history table (enmsTrapHistoryTable, section 8.4). This table contains
information about the last traps sent by the SNMP NBI, and its maximum
length is configurable either via the GUI (see 3.1) or via SNMP by setting the
enmsTrapHistoryTableLength MIB variable (see 8.1).
The trap history table does not carry the full trap details; its purpose is to allow
the SNMP manager to resynchronize only the specific objects associated to
the missed notifications.
The suggested approach to retrieve all rows in the table consists of performing
successive GETNEXT operations, and in each operation request all fields of
the same row. In this case the SNMP manager starts by requesting the first
row of values:
The GETNEXT operations above are requesting the index field (enmsNeId)
just for the sake of clarity. In a real implementation, the SNMP manager may
infer the index values from the OIDs of other fields in the same row.
To retrieve a row by index, use the GET operation and request several column
values at once:
GET(enmsNeType.9, …, enmsNeIdName.9)
GETRESPONSE(enmsNeType.9 = “ABC”, …, enmsNeIdName.9 = “NE9”)
Suppose the SNMP manager needs to retrieve all modules of a given NE, let’s
say the NE 9.
2 1 CARDX … 1234
2 2 CARDY 321
5 1 CARDZ 545
9 4 CARDX … 1234
9 5 CARDY … 321
9 6 CARDZ 545
15 3 CARDX … 1234
Table 8 Example data for enmsModuleTable
Each SNMP response must fit in a single UDP packet, whose maximum size
may be insufficient to carry all requested values (the response will have an
error status set to “Too big.”). To avoid such situations you may need to split
the GETNEXT / GETBULK / GET requests into two or more operations.
NEClass (Future)
Class of an NE.
- singleNode(1)
- repeaterNode(2)
- managementNode(3)
- masterRingNode(4)
- slaveRingNode(5)
This table contains all NEs in the network. It supports OC, OD, AVC and SC
notifications.
This table contains all modules in the network. It supports OC, OD and SC
notifications.
This table contains all ports in the network. It supports OC, OD, AVC and SC
notifications.
This table contains all termination points in the network. It supports OC, OD,
AVC and SC notifications.
This table contains all managed ports connections. It supports OC, OD and
AVC notifications.
This table contains all paths of the Optical Manager. It supports OC, OD, AVC
and SC notifications.
enmsScSrcTPIdH TPId
enmsScSrcTPIdL TPId
enmsScDestTPIdH TPId
enmsScDestTPIdL TPId
enmsScSrc2TPIdH TPId
enmsScSrc2TPIdL TPId
enmsScDest2TPIdH TPId
enmsScDest2TPIdL TPId
This table contains all the services of the Ethernet Manager. It supports OC,
OD, and SC notifications.
This table contains all services defined in TNMS (containers of type ‘Service’).
This table contains all cross connections in the network. It does not support
any type of notifications.
enmsCcSrcPortId PortId
enmsCcSrcTPIdH TPId
enmsCcSrcTPIdL TPId
enmsCcDestPortId PortId
enmsCcDestTPIdH TPId
enmsCcDestTPIdL TPId
enmsCcSrc2TPIdH TPId
enmsCcSrc2TPIdL TPId
enmsCcDest2TPIdH TPId
enmsCcDest2TPIdL TPId
This table contains all active alarms in TNMS. Its single index value
(enmsAlAlarmNumber) is not an identifier of the alarm: it corresponds to the
position of the alarm in the list and therefore may change between table
retrievals. Because of that, this table is not meant to be accessed randomly,
via GET operations. Instead, it should be retrieved row by row from top to
bottom, using GETNEXT / GETBULK operations.
The following combination of fields may be used to identify an alarm and relate
it to other tables and traps:
enmsAlProbableCause +
enmsAlTimeStamp +
enmsAlEntityString +
enmsAlNEId +
enmsAlPortId +
enmsAlTPIdH +
enmsAlTPIdL
System alarms (i.e. raised by the EMS itself) can be distinguished by having
the NE Id (enmsAlNEId) set to zero.
This table contains all alarms originating in a port or a TP contained in it. Its
indexes allow retrieving the alarms for a selected port.
This table contains all alarms originating in a TP. Its indexes allow retrieving
the alarms for a selected TP.
This table contains all alarms affecting a port connection, which include all
alarms originating in the endpoint ports or in the associated modules. Its
indexes allow retrieving the alarms for a selected port connection.
This table contains all alarms originating in a module. Its indexes allow
retrieving the alarms for a selected module.
This table contains all alarms affecting SNCs. Its indexes allow retrieving the
alarms for a selected SNC.
9.1 MEF-UNI-EVC-MIB
TNMS SNMP NBI provides preliminary support for the MEF MIB for the
management of User Network Interfaces (UNIs) and Ethernet Virtual
Connections (EVCs). Currently only basic Ethernet Path retrieval is supported.
Specification of notifications in MEF 40 is not final and as such not
implemented by SNMP NBI. To monitor changes to Ethernet Paths, use the
SNMP NBI MIB notifications instead (see section 6.2).
For more information on the MEF MIB, please refer to the MEF 40 Technical
Specification available on the MEF web site (www.mef.net).
9.1.1 mefServiceEvcCfgTable
The ‘mefServiceEvcCfgTable’ table lists all the Ethernet Paths. This table
implementation is read-only, therefore adding rows is not supported.
mefServiceEvcCfgIdentifier DisplayString
mefServiceEvcCfgServiceType INTEGER
mefServiceEvcCfgMtuSize Unsigned32
mefServiceEvcCfgCevlanIdPreservation MefServicePreservationType
mefServiceEvcCfgCevlanCosPreservation MefServicePreservationType
mefServiceEvcCfgAdminState EntityAdminState
9.1.2 mefServiceEvcStatusTable
mefServiceEvcCfgIndex Unsigned32
mefServiceEvcStatusMaxMtuSize Unsigned32
mefServiceEvcStatusOperationalState INTEGER
10 Troubleshooting
The table below proposes solutions for the most common issues when operating with SNMP
NBI. Also check TNMS System Event Log for messages related to SNMP NBI events.
The SNMP NBI menu entries in SNMP NBI not installed in the server Reinstall TNMS and select the
TNMS Client are missing or SNMP northbound interface (see
greyed out. 2.5).
SNMP NBI license not installed Install SNMP NBI license (see 2.5).
The “Enable SNMP northbound An SNMP NBI license has been Restart TNMS server (see 2.5).
interface” checkbox (SNMP NBI installed, but the server has not
system settings) is greyed out. been restarted yet.
No response from SNMP NBI or SNMP NBI not installed or not Install SNMP NBI or its license (see
timeout error. licensed. 2.5).
Incorrect SNMP agent address Make sure that the SNMP agent
configured on the SNMP manager. address configured on the SNMP
manager corresponds to the TNMS
server machine.
Incorrect SNMP agent port Make sure that the SNMP agent port
configured on the SNMP manager. configured on the SNMP manager
matches the SNMP NBI listening
port (see 3.1).
SNMP NBI could not bind to the Make sure that the configured
listening port. listening port is not being used by
any other service or application on
the TNMS server machine (see 3.1).
You may use a utility such as
‘netstat’ to list the ports on which the
server computer is listening.
SNMP error “No such name” The requested object doesn’t exist in Check if the requested OID is valid
received. the MIB. Usually occurs with GET and belongs to the SNMP NBI MIB.
requests.
Verify if the SNMP manager is trying
to get a nonexistent table value (i.e.
the table is valid, but doesn’t contain
any value for the index specified in
the OID).
SNMP error “Authentication Incorrect user data or SNMP Make sure the SNMP manager is
error” received. protocol version configured on the using the correct user authentication
SNMP manager. details, as configured in the SNMP
NBI user configuration (see 3.3.1).
This frequently occurs with SNMPv3,
so confirm the user name, the
authentication and privacy protocols,
and the corresponding passwords.
SNMP error “Too big” received. The response to the request does Split the failing GET / GETNEXT /
not fit in a single SNMP packet (see GETNEXT operations into two or
4.5.4). Typically occurs when the more requests.
SNMP manager requests too many
OIDs in the same operation, or the Use a lower max-repetitions value
max-repetitions value for a for GETBULK requests.
GETBULK operation is too high.
No traps/informs received from SNMP manager address not added Add the SNMP manager address to
SNMP NBI. to the trap destination list. the trap/inform destination list of the
appropriate SNMP NBI user (see
3.3.3).
Incorrect trap destination port. Make sure the destination port of the
traps/informs matches the port on
which the SNMP manager is waiting
for traps (see 3.3.3).
The SNMP manager is not listening Make sure the SNMP manager is
to the trap receiving port. really listening for traps/informs on
the configured port.
SET operation returns an error. SNMP user doesn’t have write Change permission of the SNMP to
permission. ‘Read/Write’ (see 3.3.2).
The target MIB object is not writable. Check the object the SNMP
manager is trying to set.
The type of the value in the SET Use the correct data type.
request is not compatible with the
MIB object.
Abbreviations
AC Attribute Change
ACS Actual Creation State
AES Advanced Encryption Standard
AVC Attribute Value Change
DB Database
DES Data Encryption Standard
3DES Triple DES
EMS Element Management System
EVC Ethernet Virtual Connection
GUI Graphical User Interface
HW Hardware
IANA Internet Assigned Numbers Authority
ITU International Telecommunication Union
MD5 Message Digest 5
NBI Northbound Interface
NE Network Element
NMS Network Management System
OC Object Creation
OD Object Deletion
PEN Private Enterprise Number
PDU Protocol Data Unit
RCS Required Creation State
SC State Change
SHA Secure Hash Algorithm
SEL System Event Log
SNMP Simple Network Management Protocol
SW Software
TCP Transmission Control Protocol
TNMS Telecommunication Network Management System
UDP User Datagram Protocol
UNO Universal Network Object
UI User Interface
UNI User Network Interface