V100R002C01
Northbound SNMP Interface User Guide
Issue 01Date 2010-05-18
Copyright © Huawei Technologies Co., Ltd. 2010. All rights reserved.
No part of this document may be reproduced or transmitted in any form or by any means without prior written consent of Huawei Technologies Co., Ltd.
Trademarks and Permissions
and other Huawei trademarks are trademarks of Huawei Technologies Co., Ltd.
All other trademarks and trade names mentioned in this document are the property of their respective holders.
Notice
The purchased products, services and features are stipulated by the contract made between Huawei and the customer. All or part of the products, services and features described in this document may not be within the purchase scope or the usage scope. Unless otherwise specified in the contract, all statements, information, and recommendations in this document are provided "AS IS" without warranties, guarantees or representations of any kind, either express or implied.
The information in this document is subject to change without notice. Every effort has been made in the preparation of this document to ensure accuracy of the contents, but all statements, information, and recommendations in this document do not constitute the warranty of any kind, express or implied.
Huawei Technologies Co., Ltd.
Address: Huawei Industrial Base
Bantian, Longgang Shenzhen 518129
People's Republic of China
Website: http://www.huawei.com
About This Document
Related Versions
The following table lists the product versions related to this document.
Product Name Version
iManager U2000 V100R002C01
Intended Audience
The iManager U2000 Northbound SNMP Interface User Guide describes the basic concept and principles of U2000 northbound SNMP interface. And it is also describes how to deploying and maintaining the SNMP NBI. This document also provides the relationship between the SNMP NBI and license, description of alarms reported by the SNMP interface, the glossary, and the acronyms and abbreviations.
This document guides the user to understand basic operations of the U2000 SNMP NBI. This document is intended for:
l Installation and Commissioning Engineer l Data Configuration Engineer
l Application Developer
Symbol Conventions
The symbols that may be found in this document are defined as follows.
Symbol Description
DANGER
Indicates a hazard with a high level of risk, which if not avoided, will result in death or serious injury.
WARNING
Indicates a hazard with a medium or low level of risk, which if not avoided, could result in minor or moderate injury.
Symbol Description
CAUTION
Indicates a potentially hazardous situation, which if not avoided, could result in equipment damage, data loss, performance degradation, or unexpected results.
TIP Indicates a tip that may help you solve a problem or save
time.
NOTE Provides additional information to emphasize or supplement
important points of the main text.
Command Conventions
The command conventions that may be found in this document are defined as follows.
Convention Description
Boldface The keywords of a command line are in boldface.
Italic Command arguments are in italics.
[ ] Items (keywords or arguments) in brackets [ ] are optional.
{ x | y | ... } Optional items are grouped in braces and separated by
vertical bars. One item is selected.
[ x | y | ... ] Optional items are grouped in brackets and separated by
vertical bars. One item is selected or no item is selected.
{ x | y | ... }* Optional items are grouped in braces and separated by
vertical bars. A minimum of one item or a maximum of all items can be selected.
[ x | y | ... ]* Optional items are grouped in brackets and separated by
vertical bars. Several items or no item can be selected.
GUI Conventions
The GUI conventions that may be found in this document are defined as follows.
Convention Description
Boldface Buttons, menus, parameters, tabs, window, and dialog titles are in boldface. For example, click OK.
> Multi-level menus are in boldface and separated by the ">"
Change History
Updates between document issues are cumulative. Therefore, the latest document issue contains all updates made in previous issues.
Changes in Issue 01 (2010-05-18) Based on Product Version V100R002C01
Contents
About This Document...iii
1 Overview...1-1
1.1 Network Position...1-2 1.2 Introduction to SNMP...1-2 1.2.1 Overview...1-3 1.2.2 Structure...1-3 1.2.3 MIB Description...1-6 1.2.4 Technical Features...1-7 1.3 Security Mechanism...1-8 1.3.1 Overview...1-9 1.3.2 Security Mechanism of SNMP v1 and v2c...1-9 1.3.3 Security Mechanism of SNMP v3...1-9 1.4 Performance Indexes...1-102 Function Interfaces...2-1
2.1 Reporting Fault Alarms in Real-Time...2-2 2.2 Querying Current Alarms...2-3 2.2.1 Changing Filter Criteria...2-3 2.2.2 Synchronizing Alarms...2-5 2.2.3 Acknowledging Alarms...2-6 2.2.4 Unacknowledging Alarms...2-8 2.2.5 Clearing Alarms...2-9 2.3 Alarm handshaking and Caching...2-10 2.4 Traps...2-11 2.4.1 Overview...2-11 2.4.2 Active Alarm Trap...2-12 2.4.3 Alarm Query Start Trap...2-17 2.4.4 Alarm Query Stop Trap...2-17 2.4.5 KeepAlive Info...2-18
3 Deploying and Configuring SNMP...3-1
3.1 Overview...3-3 3.2 Configuration Requirements...3-4 3.3 Logging in to the Client of the NMS Maintenance Suite...3-4
3.4 Checking the SNMP NBI Status...3-6 3.5 Deploying the SNMP NBI for the First Time...3-7 3.5.1 Adding SNMP NBI Component...3-7 3.5.2 Adding the SNMP NBI Instance...3-8 3.6 Configuring the SNMP NBI...3-11 3.7 SNMP Configuration Parameters...3-15
4 Deleting and Disabling an SNMP Interface...4-1
4.1 Logging In to the System Monitor...4-2 4.2 Stopping the SNMP NBI...4-2 4.3 Disabling the SNMP NBI...4-4 4.4 Restarting the SNMP NBI...4-5 4.5 Deleting the SNMP NBI Instance...4-7 4.6 Deleting the SNMP NBI Component...4-8
5 Maintaining the SNMP NBI...5-1
5.1 Maintenance Description...5-2 5.2 Faults and Solutions...5-2 5.2.1 SNMP Agent Fails to Start...5-2 5.2.2 Fails to Receive Alarms...5-3 5.2.3 User Unable to Perform Certain Fault Operations...5-3 5.2.4 NMS User Could not Connect to the SNMP Agent...5-3 5.2.5 Real Time Alarms are Not Reported...5-4 5.2.6 Attempt to Acknowledge or Un-acknowledge or Clear Alarms Fails...5-4
6 Accessing U2000 from NMS...6-1
A Relations Between License and SNMP Interface...A-1
B Description of the Alarms Reported by the SNMP Interface...B-1
C Sample...C-1
D Acronyms and Abbreviations...D-1
Figures
Figure 1-1 Position of the SNMP alarm NBI in the network...1-2 Figure 1-2 SNMP structure... 1-4 Figure 1-3 SNMP protocol frame...1-5 Figure 1-4 Security mechanism...1-9 Figure 2-1 Configuring alarm reporting procedure...2-2 Figure 2-2 Caching Alarms...2-11 Figure A-1 Main dimensions...A-1Tables
Table 1-1 SNMP Components...1-3 Table 1-2 Component description... 1-4 Table 1-3 PDU type...1-6 Table 1-4 SNMP Version and Details...1-7 Table 1-5 Performance indexes of the SNMP alarm NBI...1-10 Table 2-1 MIB Node Content...2-3 Table 2-2 Alarm filter level...2-4 Table 2-3 Alarm category filter Condition...2-4 Table 2-4 MIB Node Details - Acknowledging Alarms...2-7 Table 2-5 Alarm states - Acknowledge Alarms... 2-7 Table 2-6 MIB Node Details - Unacknowledging Alarms...2-8 Table 2-7 Alarm states - Unacknowledge Alarms...2-8 Table 2-8 MIB Node Details - Clearing Alarms... 2-9 Table 2-9 Alarm states - Clear Alarms...2-10 Table 2-10 Fields of hwNmNorthboundEventNotify TRAP-TYPE table...2-12 Table 2-11 Trap Definition of Alarm Query Start Trap...2-17 Table 2-12 3 Trap Definition of Alarm Query Stop Trap...2-18 Table 2-13 Trap Definition of KeepAlive Info...2-18 Table 2-14 Filed List...2-19 Table 3-1 SNMP Agent parameters...3-15 Table 3-2 Third-party NMS parameters...3-17 Table 3-3 Heartbeat parameters...3-19 Table 3-4 Fields of reported alarms...3-19 Table 3-5 Parameters of reported notification...3-22 Table 3-6 Parameters of the format of reported time...3-23 Table 3-7 Other Settings...3-24 Table 3-8 Parameters of the MIB frame...3-24 Table A-1 Description for Dimension...A-2 Table A-2 Description for License Item...A-2 Table B-1 The Alarms Reported for U2000 MIB...B-1 Table B-2 The Alarms Reported for T2000 old MIB...B-41
Overview
About This Chapter
This chapter introduces the Simple Network Management Protocol (SNMP) alarm Northbound Interface (NBI) of the network management system.
1.1 Network Position
This part describes the position of the SNMP NBI in a network.
1.2 Introduction to SNMP
This part introduces the SNMP protocol and structure.
1.3 Security Mechanism
The security mechanism is provided by all the supported SNMP versions, SNMPv1, SNMPv2c and SNMPv3.
1.4 Performance Indexes
1.1 Network Position
This part describes the position of the SNMP NBI in a network.
The SNMP alarm NBI is an agent module between the following entities:
l Element Management System (EMS)
l Network Management System (NMS)
The SNMP alarm NBI provides the upper NMS with the following protocol versions:
l SNMP v1
l SNMP v2c
l SNMP v3
Figure 1-1 shows the position of the SNMP alarm NBI in the network.
Figure 1-1 Position of the SNMP alarm NBI in the network
NE1 NE2 NEn Device Network EMS NMS Get/Set SNMP Trap SNMP alarm northbound interface
NE: Network Element NMS: Network Management System
EMS: Element Management System SNMP: Simple Network Management Protocol
1.2 Introduction to SNMP
1.2.1 Overview
This part describes the function and structure of SNMP.
1.2.2 Structure
SNMP involves of a series of protocols and specifications. It provides the method of collecting NMS information from NEs and reporting problems and errors to the NMS.
1.2.3 MIB Description
This chapter provides the basic concepts of MIB.
1.2.4 Technical Features
The U2000 supports SNMPv1, SNMPv2c, and SNMPv3.
1.2.1 Overview
This part describes the function and structure of SNMP.
As a widely applied industry standard for the NMS protocols, the SNMP aims:
l To transmit the management information between two nodes.
l To help the manager to search and modify the information, and locate faults at any node
in the network.
l To help the manager to diagnose the faults, configure the capacity, and generate reports.
The features of the SNMP are as follows:
l Uses the polling mechanism and provides a basic function set. l Fits small, fast and cost effective network.
1.2.2 Structure
SNMP involves of a series of protocols and specifications. It provides the method of collecting NMS information from NEs and reporting problems and errors to the NMS.
SNMP consists of the following three components:
Table 1-1 SNMP Components
Component Describes
Structure of Management Information (SMI) How to describe the management information.
Management Information Base (MIB) How to store managed objects.
SNMP management protocol How to manage the objects and realize the
network management functions.
SNMP Structure
SNMP is a protocol used for communication between NMS processes and the SNMP agent. The NMS adopting SNMP consists of the following components:
l Network management station. It is also called Explorer. l SNMP agent. Figure 1-2 SNMP structure Agent MIB U2000 Notification Operation SNMP 1 1 1 2 2 1 2 5 6 NMS Managed System NE database
Table 1-2 Component description
Component Description
NMS It indicates network management software
running on a workstation. The administrator sends requests to managed NEs on the NMS for monitoring and configuring NEs.
Agent It indicates an agent process running on a
managed NE. After the managed NE receives a request sent by the NMS, the agent responds to the request. An agent is mainly used for collecting NE status information, performing operations on NEs remotely on the NMS, and sending an alarm to the NMS.
MIB It indicates a virtual database considered as
an NE status set maintained on NEs. The agent collects NE status information by searching MIB.
Component Description
SNMP It indicates a protocol used for
communication between NMS processes and the SNMP agent. The NMS adopting SNMP consists of the following components:
l Explorer
–Sends query messages to managed NEs
through SNMP.
–Receives responses and trap packets
from managed NEs.
l SNMP agent
–Runs on NEs.
–Receives and handles query messages
sent from agents.
–Obtains the values of management
variables from other modules of NEs and generates response messages.
–Sends messages to the NMS.
–After an emergency occurs, the SNMP
agent can actively send trap packets to the NMS.
SNMP Protocol Frame
SNMP is a protocol used at the application layer and acts as a part of TCP/IP protocol family. It is carried on UDP.
Figure 1-3 SNMP protocol frame
SNMP Manager SNMP application G e tNe xtRe q u e st G e tRe q u e st S e tRe q u e st G e tRe sp o n se T ra p UDP IP Physical Network SNMP Manager SNMP application G e tNe xtRe q u e st G e tRe q u e st S e tRe q u e st G e tRe sp o n se T ra p UDP IP Physical Network MIB Base
SNMP supports five types of protocol data units (PDUs), as follows:
Table 1-3 PDU type
PDU Function
GetRequest-PDU It is used for accessing an agent and obtaining variable values
from the table.
GetNextRequest-PDU It can obtain the next logical ID descriptor from MIB. Its functions are the same as those of GetRequest-PDU except this function.
GetResponse-PDU It is used for responding to GetResponse, GetNextResponse,
and SetRequest PDUs. It contains the ID descriptors relevant to the preceding PDUs and provides ID descriptors of response status information, such as error codes, error status, and supplementary information list.
SetRequest-PDU It describes the action acting on an element. Typically, it is
used for modifying the values in the variable list.
Trap-PDU It allows the network management module to report an event
occurred on an NE or status change of an NE.
1.2.3 MIB Description
This chapter provides the basic concepts of MIB.
The MIB is a key part of the SNMP network management framework. The MIB is the object set managed by SNMP, including all the variables to be managed. All the SNMP operations such as Get and Set, aim at the managed objects in the MIB.
The MIB defines the managed objects that are used by the function interfaces of the SNMP Northbound Interface. The definitions decide what operations the NMS can do and what network management information the NMS can obtain.
The international organization assigns MIB node 2011 to Huawei Technologies Co., Ltd (HUAWEI). HUAWEI assigns MIB node 2011.2.15 to the NMS. The NMS assigns MIB node 1 as hwNmAgent. Therefore, the complete MIB node information is:
iso(1).org(3).dod(6).internet(1).private(4).enterprises(1).huawei(2011).products (2).hwNetManagement(15).hwNmAgent(1)
IHW-IMAPV1NORTHBOUND-TRAP-MIB defines the root node information of the SNMP Northbound Interface.
The SNMP Northbound Interface further assigns the MIB node information based on the root node. See below:
--- huawei(2011)
|--- products (2)
|--- hwNetManagement(15) |--- hwNmAgent (1) |---- hwNmFault (5)
hwNmFault defines the alarm subinterface of the SNMP Northbound Interface. NOTE
In later sections, the following acronyms are used to describe the MIB nodes:
l NA: Not Accessible
l RC: Read and Create
l RW: Read and Write
l RO: Read Only
1.2.4 Technical Features
The U2000 supports SNMPv1, SNMPv2c, and SNMPv3.
Table 1-4 SNMP Version and Details
SNMP Version Supported Details
SNMPv1 l Mutual access to management information between the
SNMP management system and SNMP Agent.
l Operations –Get –Set –Trap
l Protocol Data Unit (PDU) –GetRequest
–GetNextRequest
–GetResponse –SetRequest –Trap
l SNMPv1 community-based security model
NOTE
The NMS needs to get the community information from the U2000 administrator.
SNMP Version Supported Details
SNMPv2c SNMPv2 supports all the SNMPv1 functions and the following
new features:
l Access to management information between SNMP
management systems.
l Operations
–GetBulk
–Inform –Report
l Updated format of the Trap PDU, which is the same as that of
the Get/Set PDU.
l Fractionalized error codes.
NOTE
The NMS needs to get the community information from the U2000 administrator.
SNMPv3 SNMPv3 supports all SNMPv2 functions and the following new
features:
l User-based security model
l The SNMPv3 supports all Security-Levels –No Authentication and No Privacy. –Authentication and No Privacy. –Authentication and Privacy.
In which, Auth-Protocol supports MD5 and SHA, Private-Protocol supports DES.
NOTE
The NMS cannot access the NBI unless it gets the SNMP v3 information from the U2000 administrator.
1.3 Security Mechanism
The security mechanism is provided by all the supported SNMP versions, SNMPv1, SNMPv2c and SNMPv3.
1.3.1 Overview
The security mechanism of the U2000 SNMP NBI is also the security mechanism of SNMP. Any access to the SNMP alarm NBI must be authenticated.
1.3.2 Security Mechanism of SNMP v1 and v2c
This section describes the security mechanism of SNMP versions v1 and v2c.
1.3.3 Security Mechanism of SNMP v3
1.3.1 Overview
The security mechanism of the U2000 SNMP NBI is also the security mechanism of SNMP. Any access to the SNMP alarm NBI must be authenticated.
Figure 1-4 shows that SNMP v1 and v2c use the community-based security mechanism, while SNMP v3 uses the user-based security mechanism.
Figure 1-4 Security mechanism
NMS
SNMP alarm northbound interface
v3 uses user based security mechanism v1/v2c use community name based security mechanism
1.3.2 Security Mechanism of SNMP v1 and v2c
This section describes the security mechanism of SNMP versions v1 and v2c.
The security mechanism of SNMP v1 and v2c is community-based. The packet is sent in plain text that is easy to be intercepted or modified. Compared with SNMP v3, the security is weaker. Before the Get, Get Next or Set operation, NMS must know the community strings configured in the agent.
For set operations, NMS must know the write community configured in the agent. For get operations, NMS must know the read community configured in the agent.
In the Trap and Inform packets, the community name is the first read community configured in the agent.
1.3.3 Security Mechanism of SNMP v3
This section describes the security mechanism of SNMPv3 version.
SNMPv3 adopts the user-based security mechanism. The authentication and encryption mechanisms are used during the interaction with SNMP. To do read and write operations to agent, user must know:
l SNMP v3 user name in the Agent.
l Security level.
l The authentication and/or privacy passwords information.
The trap packets can be correctly resolved and handled only when the receiving end knows authentication parameters configured at agent correctly.
SNMP v3 uses the elements such as EngineID and EngineBoots to avoid delay, frame change and other attacks. Therefore, the security is greatly optimized compared with SNMP v1 and v2c.
1.4 Performance Indexes
This part introduces the performance indexes of SNMP alarm NBI. Table 1-5 lists the performance indexes of the SNMP alarm NBI.
Table 1-5 Performance indexes of the SNMP alarm NBI
Item Index
Maximum concurrent NMS connections 10
Alarm Forwarding capacity Not less than 60 alarms per second (three
NMSs connected)
Alarm forwarding delay Less than 10 seconds (three NMSs
connected)
SNMP request response delay Less than 5 seconds (CPU usage is less than
2
Function Interfaces
About This Chapter
The SNMP Northbound Interface provides different function interfaces to the different NMSs.
2.1 Reporting Fault Alarms in Real-Time
The SNMP Northbound Interface reports the real-time fault alarms to the NMS, so that the NMS can get the exact information of NE real-time alarms.
2.2 Querying Current Alarms
Through the SNMP NBI of the U2000, the upper layer NMS can query the current alarms (unterminated alarms) of the U2000.
2.3 Alarm handshaking and Caching
Real time alarms are sent through Inform to the third party NMS. When the NMS is down due to some failure at its side, real-time alarms are cached. When the failure is rectified, all the cached alarms are sent to the NMS in the order in which they were received from the EMS.
2.4 Traps
2.1 Reporting Fault Alarms in Real-Time
The SNMP Northbound Interface reports the real-time fault alarms to the NMS, so that the NMS can get the exact information of NE real-time alarms.
Context
This function adopts SNMP Trap or Inform mode as per the configuration.
Figure 2-1 shows the process of configuring the report of fault alarms in real-time.
Figure 2-1 Configuring alarm reporting procedure
Start
Register the IP address and port of the NMS for
receiving alarms Set the alarm contents
and sending options Set the alarm filter
conditions Restart the SNMP Agent
End
Procedure
Step 1 Register the receiving IP address, port and the currently-used protocol version for receiving real-time alarms.
You can configure the NMS Receive Trap Address and NMS Receive Trap Port of the third-party NMS by using NMS Maintenance Suite, refer to 3.6 Configuring the SNMP NBI. For details on NMS receive trap address and port, refer Third-Party NMS.
You can configure the Alarm Field Settings of the SNMP by using NMS Maintenance Suite, so that you can set the variables that an alarm carries to change the alarm information. For details, see 3.6 Configuring the SNMP NBI.
For details on alarm field, refer Alarm Field Settings. Step 3 Set the alarm filter conditions.
You can configure the third-party NMS items of the SNMP by using NMS Maintenance Suite, so that you can set the alarm filter criteria. For details, see 3.6 Configuring the SNMP NBI. For details on alarm filter levels, refer Third-Party NMS.
Step 4 Restart SNMP Agent.
Restart the SNMP Agent for new settings to take effect.
The alarms are sent to the upper NMS by the SNMP Agent. The severity of the alarms is checked against the specified filter conditions. Accordingly, the alarms are either reported or filtered out. ----End
2.2 Querying Current Alarms
Through the SNMP NBI of the U2000, the upper layer NMS can query the current alarms (unterminated alarms) of the U2000.
2.2.1 Changing Filter Criteria
The alarm filter criteria can be changed dynamically when the SNMP NBI is running.
2.2.2 Synchronizing Alarms
Fault alarm synchronization is a process in which the alarms are queried by the third party NMS so that the alarms are consistent between upper NMS and EMS.
2.2.3 Acknowledging Alarms
NMS can acknowledge alarms based on the alarm serial numbers.
2.2.4 Unacknowledging Alarms
NMS can unacknowledge alarms based on the alarm serial numbers.
2.2.5 Clearing Alarms
NMS can clear alarms based on the alarm serial numbers.
2.2.1 Changing Filter Criteria
The alarm filter criteria can be changed dynamically when the SNMP NBI is running.
Context
The following MIB Node is exposed to the user.
Table 2-1 MIB Node Content
Node Name OID
Procedure
Step 1 Set the value of MIB node.
The format for setting the value of MIB node is as follows:
IP Address: Port: AlarmFilterLevel
The IP address and the port number are the same as specified in the snmp_agent_svc.xml file and the alarm filter level is the condition for filtering the alarms.
CAUTION
Enter the IP address and port number of the upper-layer OSS.
NOTE
l On the Windows OS, the configuration file snmp_agent_svc.xml in the %IMAPROOT%\server\etc \conf.
l On the Solaris or SUSE Linux OS, the configuration file snmp_agent_svc.xml in the $IMAPROOT/ server/etc/conf.
The alarm filter level is represented in four bits in binary notation. The alarm severity levels that can be filtered are critical, major, minor, and warning. Table 2-2 lists the meanings of each bit of the alarm filter level. If a bit is set to 0, it indicates that the alarms of the corresponding severity level are reported. If a bit is set to 1, it indicates that the alarms of the corresponding severity level are filtered out.
Table 2-2 Alarm filter level Most Significant
Bit (MSB) Least SignificantBit (LSB)
Critical Alarm Major Alarm Minor Alarm Warning Alarm
The alarm category filter condition is represented in three bits in binary notation. The alarm severity levels that can be filtered are event, fault, and recovery. Table 2-3 lists the meanings of each bit of the alarm category filter condition. If a bit is set to 0, it indicates that the alarms of the corresponding alarm category are reported. If a bit is set to 1, it indicates that the alarms of the corresponding alarm category are filtered out.
Table 2-3 Alarm category filter Condition
Most Significant Bit (MSB) Least Significant Bit (LSB)
Event Fault Recovery
Example
The IP address of the upper-layer OSS is set to 10.70.73.159 and the serial number of the port for receiving alarms is set to 161. To report only the critical and major alarms and filter out the minor and warning alarms, you need to set the MIB node to 10.70.73.159:161:0011.
2.2.2 Synchronizing Alarms
Fault alarm synchronization is a process in which the alarms are queried by the third party NMS so that the alarms are consistent between upper NMS and EMS.
Context
NMS can specify the time interval for alarm synchronization.
This function adopts SNMP Trap or Inform mode depending upon the configuration done in the snmp_agent_svc.xml file.
NOTE
l On the Windows OS, the configuration file snmp_agent_svc.xml in the %IMAPROOT%\server\etc \conf.
l On the Solaris or SUSE Linux OS, the configuration file snmp_agent_svc.xml in the $IMAPROOT/ server/etc/conf.
The following MIB nodes are exposed.
Node Name OID
hwNmNorthboundEventSynchronization-CommandStart 1.3.6.1.4.1.2011.2.15.1.7.7.4 hwNmNorthboundEventSynchronization-CommandStop 1.3.6.1.4.1.2011.2.15.1.7.7.5
Procedure
Step 1 Set the MIB node exposed.
Set the hwNmNorthboundEventSynchronizationCommandStart node in the format as specified.
IP address of the NMS: Port number of the NMS: Start Time: End Time
The IP address and Port are same as configured in the snmp_agent_svc.xml file. Start Time and End Time parameters are in UTC time format and are optional.
The syntax for start time and end time is: YYYYMMDDhhmmss. The variable description is as follows:
l YYYY: Four digit year. The range of values is 1970 onwards. l MM: Two digit month. The range of values is 01-12. l DD: Two digit date. The range of values is 01-31. l hh: Two digit hour. The range of value is 00-23.
l mm: Two digit minutes. The range of values is 00-59. l ss: two digit seconds. The range of values is 00-59.
For Example,
Valid query conditions:
10.18.38.63:20061006090520:20061006090520 - Start time and end time are specified. 10.18.38.63:161:20061006090520 - No end time is specified.
The SNMP Northbound Interface sends a start synchronization notification to the NMS with the following OID:
1.3.6.1.4.1.2011.2.15.1.7.7.4 Alarm synchronization starts.
Step 2 Receive active alarms present in the EMS Database.
The NMS receives the active alarms present in the EMS Database between time period specified (if any).
The OID of the synchronous data is: 1.3.6.1.4.1.2011.2.15
The OID carries the same VBs. The field formats are the same as those for a real-time alarm. The alarms can be synchronized for the NMSs configured in the snmp_agent_svc.xml file. Step 3 End alarm synchronization.
The alarm synchronization ends after all active alarms are sent to the NMS or the NMS user sends the stop alarm synchronization request to the SNMP Northbound Interface..
Set hwNmNorthboundEventSynchronizationCommandStop node in the format as specified:
IP Address: Port Number
The IP Address and the port number is the address of the NMS for which alarm synchronization is to be stopped
The SNMP alarm Northbound Interface sends a notification to the NMS which contains the result of synchronization.
1. Alarm synchronization has been successfully ended. 2. Alarm synchronization is stopped by the NMS command. 3. Error has occurred during the alarm synchronization.
NOTE
l If End Time is not present, the current system time of the EMS is treated as the End Time.
l If both are not present all the active alarms are queried.
l If End Time is present Start Time is mandatory.
----End
2.2.3 Acknowledging Alarms
Context
Table 2-4 shows the MIB node.
Table 2-4 MIB Node Details - Acknowledging Alarms
Node Name OID
hwNmAcknowledgeAlarms 1.3.6.1.4.1.2011.2.15.1.3.7
Procedure
l Set the MIB node with alarm serial number
NMS sets the above mentioned node with the serial number of the alarm to be acknowledged.
To acknowledge multiple alarms, NMS sets the node with all the serial numbers, separated by a comma.
Ack User field in U2000 client is set as SNMP Agent User when an alarm is acknowledged by the SNMP Agent.
Invalid or non existent alarm serial numbers list is returned as failed to acknowledge. For Example,
Consider the following string: ",1,,,2, 3 ,ab c,,4,3,d,4294967296 " Valid Alarm Serial Number. = 1,2,4,3
Invalid Alarm Serial. Number. = ab c,d,4294967296
Table 2-5 shows the change in state when alarms are acknowledged.
Table 2-5 Alarm states - Acknowledge Alarms
Sl.No Alarm State State Change SET
Response Failed List
1 Unacknowledg e and Unclear Acknowledge and Unclear Success Empty 2 Unacknowledg e and Clear Acknowledge and Clear Success Empty 3 Acknowledge and Unclear Acknowledge and Unclear Success Empty 4 Acknowledge and Clear
NA Success Alarm Serial
NOTE
The GET operation is not supported on this MIB node.
----End
2.2.4 Unacknowledging Alarms
NMS can unacknowledge alarms based on the alarm serial numbers.
Context
Table 2-6 describes the MIB node.
Table 2-6 MIB Node Details - Unacknowledging Alarms
Node Name OID
hwNmUnAcknowledgeAlarms 1.3.6.1.4.1.2011.2.15.1.3.8
Procedure
Step 1 Set the MIB node with alarm serial number.
NMS sets the above mentioned node with the serial number of the alarm to be unacknowledged. To unacknowledge multiple alarms, NMS sets the node with all the serial numbers, separated by a comma.
Invalid or non-existent alarm serial numbers list is returned as failed to unacknowledge. For Example,
Consider the following string: ",1,,,2, 3 ,ab c,,4,3,d,4294967296 " Valid Alarm Serial Number. = 1,2,4,3
Invalid Alarm Serial. Number. = ab c,d,4294967296
Table 2-7 shows the change in state when alarms are unacknowledged.
Table 2-7 Alarm states - Unacknowledge Alarms
Sl.No Alarm State State Change SET Response Failed List
1 Unacknowledge and Unclear Unacknowledge and Unclear Success Empty 2 Unacknowledge and Clear Unacknowledge and Clear Success Empty 3 Acknowledge and Unclear Unacknowledge and Unclear Success Empty
Sl.No Alarm State State Change SET Response Failed List
4 Acknowledge
and Clear
NA Success Alarm Serial
Numbers
NOTE
GET operation is not supported on this MIB node.
----End
2.2.5 Clearing Alarms
NMS can clear alarms based on the alarm serial numbers.
Context
Table 2-8 shows the MIB node.
Table 2-8 MIB Node Details - Clearing Alarms
Node Name OID
hwNmClearAlarms 1.3.6.1.4.1.2011.2.15.1.3.6
Procedure
Step 1 Set the MIB node with alarm serial number.
NMS sets the above mentioned node with the serial number of the alarm to be cleared. To clear multiple alarms, NMS sets the node with all the serial numbers, separated by a comma. Cleared User field in U2000 client is set as SNMP Agent User when an alarm is cleared by the SNMP Agent.
Invalid or non-existent alarm serial numbers list is returned as failed to clear. For Example,
Consider the following string: ",1,,,2, 3 ,ab c,,4,3,d,4294967296 " Valid Alarm Serial Number. = 1,2,4,3
Invalid Alarm Serial. Number. = ab c,d,4294967296
Table 2-9 Alarm states - Clear Alarms
Sl.No Alarm State State Change SET Response Failed List
1 Unacknowledge and Unclear Unacknowledge and Clear Success Empty 2 Unacknowledge and Clear Unacknowledge and Clear Success Empty 3 Acknowledge and Unclear Acknowledge and Clear Success Empty 4 Acknowledge and Clear
NA Success Alarm Serial
Numbers
NOTE
GET operation is not supported on this MIB node.
----End
2.3 Alarm handshaking and Caching
Real time alarms are sent through Inform to the third party NMS. When the NMS is down due to some failure at its side, real-time alarms are cached. When the failure is rectified, all the cached alarms are sent to the NMS in the order in which they were received from the EMS.
Context
Figure 2-2 Caching Alarms
NMS Up start
Set Cache Features, Timeout, Retries and Cache
Size
New Real Time Alarm
NMS Down Cache Alarms
End Report Alarms Yes No Yes
2.4 Traps
This chapter introduces the trap configuration information of the SNMP Northbound Interface.
2.4.1 Overview
This section describes the traps which the SNMP Northbound Interface provides for the NMS.
2.4.2 Active Alarm Trap
This section describes how the U2000 system sends real-time alarms to the NMS.
2.4.3 Alarm Query Start Trap
This section describes the alarm query start trap including the prerequisites and trap definition.
2.4.4 Alarm Query Stop Trap
This section describes about the alarm query stop trap including prerequisites and trap definition.
2.4.5 KeepAlive Info
This section describes about the Keep Alive info, prerequisites, trap definition and field list.
2.4.1 Overview
This section describes the traps which the SNMP Northbound Interface provides for the NMS. The trap names are given below:
l Active alarm trap: hwNmNorthboundEventSynchronization l Active alarm query start trap:
hwNmNorthboundEventSynchronizationCommandStart
l Active alarm query stop trap: hwNmNorthboundEventSynchronizationCommandStop
l KeepAlive Info trap: hwNmNorthboundEventKeepAliveInfo
2.4.2 Active Alarm Trap
This section describes how the U2000 system sends real-time alarms to the NMS.
Description
This section describes the purpose of the alarm trap.
Prerequisites
If an alarm occurs to an NE or the U2000, U2000 sends the alarm trap to the NMS.
Field List
In the following table , by default, the field types are those used for the connection with SNMPv1. For SNMPv2c or SNMPv3, the same data types will not be introduced again. Different data types are remarked in brackets.
Table 2-10 Fields of hwNmNorthboundEventNotify TRAP-TYPE table
Name OID Type Description Example
hwNmNorthbo undNEName
1.3.6.1.4.1.2011 .2.15.1.7.1.1
Octet string The name of
network element. otm460 hwNmNorthbo undNEType 1.3.6.1.4.1.2011 .2.15.1.7.1.2
Octet string The device type
of element. WDM_OTM hwNmNorthbo undObjectIn-stance 1.3.6.1.4.1.2011 .2.15.1.7.1.3
Octet string The instance of
element are as follows number of l Rack l Frame l Slot l Subslot l Port
Name OID Type Description Example hwNmNorthbo
undEventType
1.3.6.1.4.1.2011 .2.15.1.7.1.4
Octet string The type of
Event. l Communicati on l Environment l Equipment l Service l Processerror l Integrity l Operational l Physical l SecurityServi ceO rMechanism l TimeDomain Equipment hwNmNorthbo undEventTime 1.3.6.1.4.1.2011 .2.15.1.7.1.5
Octet string Time at which
the alarm was generated. The format is l Local Time (YYYY/ MM/DD-hh:mm:ss) l UTC Time (YYYY/ MM/DD-hh:mm:ssZ) l Local with Time Zone (YYYY/ MM/ DD:hh:mm:s s:hh:mm:TZ) 2009/09/05-03: 44:20 hwNmNorthbo undProbableCa use 1.3.6.1.4.1.2011 .2.15.1.7.1.6
Octet string The probable
cause of the alarm.
Name OID Type Description Example hwNmNorthbo
undSeverity
1.3.6.1.4.1.2011 .2.15.1.7.1.7
Octet string The level of
Alarm. The levels are as follows: l Critical l Major l Minor l Warning l Indeterminat e Critical hwNmNorthbo undEventDetail 1.3.6.1.4.1.2011 .2.15.1.7.1.8
Octet string The Alarm ID
and detail information. hwNmNorthbo undAdditionalI nfo 1.3.6.1.4.1.2011 .2.15.1.7.1.9
Octet string The additional
information of device, such as Country, City. (zero-length) hwNmNorthbo undFaultFlag 1.3.6.1.4.1.2011 .2.15.1.7.1.10
Octet string The flag which
specifies whether the alarm is an event, fault or recovery. l Event l Fault l Recovery Fault
Name OID Type Description Example hwNmNorthbo undFaultFuncti on 1.3.6.1.4.1.2011 .2.15.1.7.1.11
Octet string The function
type of the alarm. It can be any one of the following values: l Power l Environment l Signal l Relay l Hardware l Software l Run l Communicati on l Service l Processerror l UNKNOWN _FU NC_TYPE hwNmNorthbo undDeviceIP 1.3.6.1.4.1.2011 .2.15.1.7.1.12
IpAddress IP address of the
device. 10.167.12.84 hwNmNorthbo undSerialNo 1.3.6.1.4.1.2011 .2.15.1.7.1.13
INTEGER The serial
number of alarm. 54 hwNmNorthbo undProbableRe-pair 1.3.6.1.4.1.2011 .2.15.1.7.1.14
Octet string Alarm repair
recommendatio ns. ID: 187,DeviceTyp e:1891 hwNmNorthbo undResourceID s 1.3.6.1.4.1.2011 .2.15.1.7.1.15
Octet string The ID of
resource. 4063233.31457 28.1.196609.61. 1.1.-1 hwNmNorthbo undsAdditional VB1 1.3.6.1.4.1.2011 .2.15.1.7.1.16
Octet string The additional
information of the alarm. hwNmNorthbo undsAdditional VB2 1.3.6.1.4.1.2011 .2.15.1.7.1.17
Octet string The additional
information of the alarm. hwNmNorthbo undsAdditional VB3 1.3.6.1.4.1.2011 .2.15.1.7.1.18
Octet string The additional
information of the alarm.
Name OID Type Description Example hwNmNorthbo undsAdditional VB4 1.3.6.1.4.1.2011 .2.15.1.7.1.19
Octet string The additional
information of the alarm. hwNmNorthbo undsAdditional VB5 1.3.6.1.4.1.2011 .2.15.1.7.1.20
Octet string The additional
information of the alarm. hwNmNorthbo undsAdditional VB6 1.3.6.1.4.1.2011 .2.15.1.7.1.21
Octet string The additional
information of the alarm. hwNmNorthbo undsAdditional VB7 1.3.6.1.4.1.2011 .2.15.1.7.1.22
Octet string The additional
information of the alarm. hwNmNorthbo undsAdditional VB8 1.3.6.1.4.1.2011 .2.15.1.7.1.23
Octet string The additional
information of the alarm. hwNmNorthbo undEventName 1.3.6.1.4.1.2011 .2.15.1.7.1.24
Octet string The name of
event. ID: 187,DeviceTyp e: 1891,CHAN_L OS NOTE
The alarm trap notification is the same for real-time alarm reporting and as a response to querying active alarms.
How to configure AdditionalVB
Additional VBs are not defined in agent. New type of additional VB can be added without changing the agent. Only snmp_agent_svc.xml needs to be changed. They do not have its own OID and use fixed OID assigned to additional information. They will use OID according to their order in the additional vbs.
NOTE
l On the Windows OS, the configuration file snmp_agent_svc.xml in the %IMAPROOT%\server\etc \conf.
l On the Solaris or SUSE Linux OS, the configuration file snmp_agent_svc.xml in the $IMAPROOT/ server/etc/conf.
For example, the first VB in the additional VBs will use HwNmNorthboundAdditionalVB1 (1.3.6.1.4.1.2011.2.15.1.7.1.16.0)
The second VB in the additional VBs will use HwNmNorthboundAdditionalVB2 (1.3.6.1.4.1.2011.2.15.1.7.1.17.0)
The eighth VB in the additional VBs will use HwNmNorthboundAdditionalVB8 (1.3.6.1.4.1.2011.2.15.1.7.1.23.0).
The maximum number of count of additional VBs is eight. Only the first 8 additional VBs will be sent, and the other VBs are ignored.
The field for additional VBs can be configured by the user, the format is as follows:
AdditionalVBX=DEFINE_FIELD_NAME, Here X must begin from 1 and increase by 1 each time.
To configure the values for each additional VB which maps to the array index of the Paras parameter, is sent in FM alarm structure. The datatype of the additional VBs is Octect string. If the value configured in the snmp_agent_svc.xml file does not match with the array index of the Paras parameter, null will be reported to the NMS.
2.4.3 Alarm Query Start Trap
This section describes the alarm query start trap including the prerequisites and trap definition.
Description
The U2000 notifies the NMS of the start of the query. After the NMS receives the active alarm query start trap, the query starts.
The hwNmNorthboundEventSynchronizationCommandStart node is to be set to start the alarm synchronization. This node is set as NMS IP: port: start time: end time. The syntax for Start and End time is YYYYMMDDhhmmss.
Prerequisites
The NMS triggers the query.
Trap Definition
The following table describes the trap definition:
Table 2-11 Trap Definition of Alarm Query Start Trap
Name OID hwNmNorthboundEventSynchronizationCom-mandStart 1.3.6.1.4.1.2011.2.15.1.7.7.4
Field List
None2.4.4 Alarm Query Stop Trap
This section describes about the alarm query stop trap including prerequisites and trap definition.
Description
The U2000 notifies the NMS of the stop of the query. After the NMS receives the active alarm query stop trap, it indicates that the query ends.
"hwNmNorthboundEventSynchronizationCommandStop" node sets to stop the alarm
synchronization. This node sets as NMS's IP: port and the agent stops alarm synchronization for the specified IP and port.
Prerequisites
Query should be running.
Trap Definition
The following table describes the trap definition:
Table 2-12 3 Trap Definition of Alarm Query Stop Trap
Name OID hwNmNorthboundEventSynchronizationCom-mandStop 1.3.6.1.4.1.2011.2.15.1.7.7.5
Field List
None2.4.5 KeepAlive Info
This section describes about the Keep Alive info, prerequisites, trap definition and field list.
Description
U2000 sends the Keep Alive info to the NMS regularly each period. If the NMS receives the trap, the connection between the NMS and the U2000 works. If the NMS does not receive the trap in this period and the heartbeat is enabled, it indicates that the NMS disconnects with the U2000.The range is from 3 to 300 seconds and the default value is 60.
Prerequisites
The U2000 sends the keepAlive info trap to the NMS regularly in the preset period.
Trap Definition
The following table describes the trap definition:
Table 2-13 Trap Definition of KeepAlive Info
Name OID
Field List
In the following table, by default, the field types are those used for the connection with SNMPv1. For SNMPv2c or SNMPv3, the same data types will not be introduced again. Different data types are remarked in brackets.
Table 2-14 Filed List
Name OID Type Description
hwNmNorthboundEvent-KeepAliveInfo
1.3.6.1.4.1.2011.2.1 5.1.7.2
Trap Notification for the Keep
3
Deploying and Configuring SNMP
About This Chapter
This chapter describes how to deploy and configure the U2000 SNMP NBI. It includes the following information:
3.1 Overview
This topic describes the background information and the terms involved in the process of deploying and configuring the northbound interface.
3.2 Configuration Requirements
U2000 SNMP NBI and the U2000 server run on the same PC or Sun workstation, any additional configuration is not required. But to enable the SNMP NBI, you must purchase the license for the corresponding functions.
3.3 Logging in to the Client of the NMS Maintenance Suite
After you log in to the client of the NMS Maintenance Suite, you can maintain the U2000 by using the NMS Maintenance Suite, including deploying the U2000 and configuring the instance of the northbound interface.
3.4 Checking the SNMP NBI Status
After check the license and ensure it is support SNMP functions, you need to check the current status of SNMP NBI, and deploy the SNMP NBI according the status.
3.5 Deploying the SNMP NBI for the First Time
By default, the SNMP NBI is not installed during the installation of U2000 server. To enable the SNMP NBI, you need to add the SNMP NBI the SNMP NBI component first, then add the SNMP NBI instance.
3.6 Configuring the SNMP NBI
In order to enable the SNMP NBI, even though you have installed SNMP NBI component, you need configure the SNMP parameters accord to NMS planning. Also, you can modify the parameters by configuring SNMP NBI again. As usual, the general parameters is mandatory. The advanced items is optional while the default value is recommended. Every advanced item is independence and you need not set the parameters in sequence.
You can ensure that the connection between the U2000 and the upper layer NMS is normal by correctly configuring basic parameters in the deployment tool. You can also configure advanced parameters for customizing the messages queried or reported through the SNMP interface.
3.1 Overview
This topic describes the background information and the terms involved in the process of deploying and configuring the northbound interface.
Attention Item
l Northbound interface is an optional component of the U2000. A license is required for
using this function.
l If you do not install the northbound interface component during the installation of the
U2000, you need to add it manually.
l The northbound interface is a System single-instance deployment package. Therefore, only
one instance can be deployed.
CAUTION
l After the northbound interface component is installed or added, you need to add a
corresponding instance and configure parameters. Then, the U2000 can start the NBI-related process.
l After initializing the database of the U2000, you need to configure the northbound interface
instance again.
l After the northbound interface instance is configured, you need to restart all the NMS
services.
Terms
The following explains certain confusable terms:
l Component: It is the software function unit that can be selected for installation. A
component can consist of multiple deployment packages.
l Deployment package: It is the software unit that is deployed on a PC. In a distributed system,
the deployment packages of a component may be deployed on different PCs. Deployment packages are classified into the following types:
– System single-instance: Such deployment packages can be installed on only one server
and the server can be deployed with only one instance.
– Single-server single-instance: Such deployment packages can be installed on multiple
servers and each server can be deployed with only one instance.
– Single-server multi-instance: Such deployment packages can be installed on multiple
servers and each server can be deployed with multiple instances.
NOTE
The type of northbound interface deployment package is System single-instance.
NMS Maintenance Suite
Through the GUI of the NMS maintenance tool, you can conveniently deploy the northbound interface.
The NMS Maintenance Suite is a graphical system maintenance tool that is developed for the iManager U2000. The NMS Maintenance Suite is used to deploy the instances and distributed system of the U2000.
Refer to the NMS Maintenance Suite part of the iManager U2000 Administrator Guide for the details about the NMS Maintenance Suite.
3.2 Configuration Requirements
U2000 SNMP NBI and the U2000 server run on the same PC or Sun workstation, any additional configuration is not required. But to enable the SNMP NBI, you must purchase the license for the corresponding functions.
NOTE
For different operation system, the configuration requirements of U2000 is different, refer to the corresponding Software Installation Guide for more information.
Hardware Configuration
In practice, the U2000 SNMP interface and the U2000 server run on the same PC or SUN workstation. The hardware should be well configured enough to ensure the proper installation and running of the U2000 server. Any additional hardware configuration is not required the U2000 SNMP interface.
For details of hardware requirements of U2000 Server, refer to section Configuration
Requirements in the iManager U2000 Software Installation Guide.
Software Configuration
The function of U2000 SNMP interface is implemented based on the ORB technology of the SNMP. Since the the SNMP is integrated into the U2000 installation software, no additional software configuration is required for the installation of the U2000SNMP interface.
For details of software requirements U2000 Server, refer to section Configuration
Requirements in the iManager U2000 Software Installation Guide.
License
The U2000 controls the functions and available resources of the CORBA NBI through a license. If you want to enable the CORBA interface, you need to purchase the U2000 license. Ensure the license support CORBA interface function before deploying the CORBA NBI.
For details, see A Relations Between License and SNMP Interface. If the license does not support the functions or resources needed, contact Huawei engineers to apply for the license. For the license introduction and information on how to apply for a license, see section Applying
for and Updating the License in the iManager U2000 Administrator Guide.
3.3 Logging in to the Client of the NMS Maintenance Suite
After you log in to the client of the NMS Maintenance Suite, you can maintain the U2000 by using the NMS Maintenance Suite, including deploying the U2000 and configuring the instance of the northbound interface.
Prerequisite
l The server of the NMS Maintenance Suite must be started.
l The client and the server of the NMS Maintenance Suite must communicate with each other
normally.
Context
In normal cases, the NMS Maintenance Suite server starts along with the OS. You can do as follows to check whether the NMS Maintenance Suite server is started:
l In the Windows OS, check whether the msdaemon.exe and msserver.exe processes are
started in the Task Manager window. If you can find the two processes in the process list, it indicates that the NMS Maintenance Suite server is started. Otherwise, open the DOS window and run the following command to start the NMS Maintenance Suite server:
> net start nodemgr
l In the Solaris or SUSE Linux OS, run the following command as the root user to check
whether the NMS Maintenance Suite server is started:
# ps -ef | grep java
If ./engineering/jre/jre_unix/bin/java is displayed, it indicates that the NMS Maintenance Suite server is started. Otherwise, run the following commands to start the NMS
Maintenance Suite server:
# cd /opt/HWENGR/engineering # ./startserver.sh
Procedure
Step 1 On a computer installed with the NMS Maintenance Suite client, double-click the U2000 MSuite shortcut icon on the desktop and then wait about one minute. The Login dialog box is displayed.
NOTE
l In the Solaris OS, you must log in to the Java desktop system as the root user. Otherwise, the U2000 MSuite shortcut icon is not displayed on the desktop.
l In the SUSE Linux OS, you cannot log in to the NMS Maintenance Suite client through the shortcut icon. You need to run the following commands as the root user to start the NMS Maintenance Suite client:
# cd /opt/HWENGR/engineering # ./startclient.sh
Step 2 Set the related login parameters.
The login parameters are described as follows:
l IP Address: It refers to the system IP address of the computer where the NMS Maintenance
Suite server resides. In a distributed system, you need to enter the system IP address of the master server.
l Port No.: The default port number is 12212. You do not need to change the default value
during login.
l User Name: The default user name is admin. l Password: The initial password is admin.
NOTE
l When you log in to the client of the NMS Maintenance Suite, a progress bar showing the progress of querying components and instances is displayed. In this case, wait until the operation is complete.
l The NMS Maintenance Suite works in single-user mode. That is, only one NMS Maintenance Suite client can log in to the NMS Maintenance Suite server at one time. In a high availability system, only one site can be logged in at one time.
----End
Result
If a dialog box is displayed during the login, indicating that network configuration information is inconsistent and re-synchronization is required after login, read through the message to learn the server that needs to be synchronized. Then, do as follows:
1. On the NMS Maintenance Suite client, click the Server tab.
2. Right-click the server whose network configuration needs to be synchronized, and choose Synchronize the network configuration from the shortcut menu. A dialog box is displayed for you to confirm the operation.
3. Click OK.
3.4 Checking the SNMP NBI Status
After check the license and ensure it is support SNMP functions, you need to check the current status of SNMP NBI, and deploy the SNMP NBI according the status.
Context
The SNMP NBI is one of the components of U2000. The installation of the SNMP NBI is integrated in the process of installing the U2000 server. There are two cases of the installation.
l If the SNMP NBI is not installed during the installation of the U2000 server, to enable the
interface, you need to add the component first and then add the instance. For details, see 3.5 Deploying the SNMP NBI for the First Time.
l If the SNMP NBI is installed during the installation of the U2000 server, to enable the
interface, you need to configure the instance. For details, see 3.6 Configuring the SNMP NBI.
The details for how to install the U2000 Server, refer to iManager U2000 Software Installation
Guide. If you want to install SNMP NBI, ensure you have select Northbound SNMP Interface
component during the installation of the U2000 server.
Procedure
Step 1 Log in to the client of the NMS Maintenance Suite. For details, see 3.3 Logging in to the Client of the NMS Maintenance Suite.
Step 2 Click Instance tab, check whether the AgentSNMP exist in the instance list.
l If the AgentSNMP instance exist, refer the steps in 3.6 Configuring the SNMP NBI to enable the SNMP NBI.
l If the AgentSNMP instance not exist, you need to check whether the SNMP NBI deployment package exist according to the Step 3.
Step 3 Click Deployment Package tabs, check whether the SNMP NBI exist in the deployment package list.
l If the SNMP NBI deployment package exist, refer the steps in 3.5.2 Adding the SNMP NBI Instance to enable the SNMP NBI.
l If the SNMP NBI deployment package not exist, refer the steps in 3.5 Deploying the SNMP NBI for the First Time to enable the SNMP NBI.
----End
3.5 Deploying the SNMP NBI for the First Time
By default, the SNMP NBI is not installed during the installation of U2000 server. To enable the SNMP NBI, you need to add the SNMP NBI the SNMP NBI component first, then add the SNMP NBI instance.
3.5.1 Adding SNMP NBI Component
The SNMP NBI is one components of the U2000. If you have not installed the SNMP NBI by default, you need to add the SNMP NBI component.
3.5.2 Adding the SNMP NBI Instance
The type of SNMP NBI deployment package is system single-instance, you can deploy one instance only. After adding the SNMP NBI component, you need to adding SNMP NBI instance to enable the SNMP interface. You need set the general parameters, and it is recommended you set the advanced parameters to default value.
3.5.1 Adding SNMP NBI Component
The SNMP NBI is one components of the U2000. If you have not installed the SNMP NBI by default, you need to add the SNMP NBI component.
Prerequisite
l The NMS Maintenance Suite server installed on the master and slave servers must be
started.
l The System Monitor server of the U2000 must be started. l The Database server process must be in the Running state.
l The NMS Maintenance Suite client communicates with the NMS Maintenance Suite server
in the normal state.
Context
l In a distributed system, you only need to log in to the NMS maintenance tool server of the
master server to perform this operation.
l In a high availability system, you only need to log in to the NMS maintenance tool server
of the primary site to perform this operation.
Procedure
Step 1 Log in to the client of the NMS Maintenance Suite. For details, see 3.3 Logging in to the Client of the NMS Maintenance Suite.
Step 2 On the NMS Maintenance Suite client, choose Deploy > Add Component. The Add Component dialog box is displayed.
CAUTION
l In the distributed system, the SNMP NBI could be deployed in master server only.
l You can add one SNMP NBI component only.
Step 3 Choose the Northbound SNMP Interface component and click OK, the progress bar is displayed.
Step 4 Wait until the dialog box is displayed to prompt the message The component is successfully added.
Step 5 Click OK, completed the operation. ----End
Postrequisite
After the component is added, you need to add the SNMP NBI instance, then you can enable the SNMP interface.
3.5.2 Adding the SNMP NBI Instance
The type of SNMP NBI deployment package is system single-instance, you can deploy one instance only. After adding the SNMP NBI component, you need to adding SNMP NBI instance to enable the SNMP interface. You need set the general parameters, and it is recommended you set the advanced parameters to default value.
Prerequisite
l The NMS Maintenance Suite server installed on the master and slave servers must be
started.
l The System Monitor server of the U2000 must be started. l Database Server Process must be in the Enable state.
l The NMS Maintenance Suite client must communicate with the NMS Maintenance Suite
server in the normal state.
l The component to which the instance is added must be installed. If the component is not
installed, you must add SNMP NBI component first.
Context
l In a distributed system, you only need to log in to the NMS maintenance tool server of the
master server to perform this operation.
l In a high availability system, you only need to log in to the NMS maintenance tool server
Procedure
Step 1 Log in to the client of the NMS Maintenance Suite. For details, see 3.3 Logging in to the Client of the NMS Maintenance Suite.
Step 2 On the NMS Maintenance Suite client, click the Deployment Package tab. Right-click the northbound SNMP interface deployment package and choose Add Instance. The dialog box is displayed.
Step 3 In the General tab, choose the items in the left object tree, configure the basic project parameters of the SNMP NBI, refer to SNMP Agent and Third-Party NMS for more information.
Step 4 Click the Advanced tab. Choose the required items in the left object tree, refer 3.7 SNMP Configuration Parameters to set parameters.
l Heartbeat Settings l Alarm Field Settings l Set reporting notification l Report Date Format Settings l Other Settings
l MIB Frame Settings
Step 5 Click OK to complete the settings.
Step 6 Optional: In the case of a distribute HA system with multiple NICs, if you enter the IP address of the master server to deploy SNMP NBI, and this IP address is not in the relevant address drop-list, the Address for Standby Server dialog box is displayed.
1. Enter the IP address of the SNMP NBI on the standby server.
CAUTION
l The SNMP service can deploy in the primary server only.
l You can enter any IP address of the standby server (except 127.0.0.1). But you must
ensure that the input IP address is correct. That is, the standby server should be able to communicate with the upper-layer NMS successfully with the input IP address.
l The CORBA NBI searches for the IP configuration list (hosts file) of the computer
automatically. Additionally, the first IP address in the configuration list is bound to the Naming service host address and Notify service host address. In the case of a single IP address, you need not set the Naming service host address and Notify service host address. In the case of multiple IP addresses, you need to set these fields because the bound IP address is unknown. When setting theses fields, you need to set them to IP addresses that the upper-layer NMS can have access to.
l Receive Request from NMS address is mandatory, Send Trap address is optional,
2. Click OK, complete the settings.
Step 7 Wait until the dialog box is displayed to prompt the success message. Step 8 Click OK, complete add the CORBA instance.
Step 9 The dialog box is displayed, prompt that restart all of the NMS service. Step 10 Click OK, close the dialog box.
Step 11 Log in to the System Monitor. Restart all services of the U2000.
Step 12 In the System Monitor client, check the Status of SNMP Service. If the process is running, the SNMP NBI is enabled successfully.
----End
3.6 Configuring the SNMP NBI
In order to enable the SNMP NBI, even though you have installed SNMP NBI component, you need configure the SNMP parameters accord to NMS planning. Also, you can modify the parameters by configuring SNMP NBI again. As usual, the general parameters is mandatory. The advanced items is optional while the default value is recommended. Every advanced item is independence and you need not set the parameters in sequence.
Prerequisite
l Log in to the Solaris or SUSE Linux OS as the root user. l Log in to the Windows OS as the Administrator user.
l In a HA system, configure the SNMP interface on the active server.
l The NMS Maintenance Suite server installed on the master and slave servers must be
started.
l The Database server process must be in the Enabled state.
l The NMS Maintenance Suite client communicates with the NMS Maintenance Suite server
in the normal state.
l The SNMP NBI instance must be added. Otherwise, add the related SNMP NBI
instance first.
Context
l In a distributed system, you only need to log in to the NMS maintenance tool server of the
master server to perform this operation.
l In a high availability system, you only need to log in to the NMS maintenance tool server
of the primary site to perform this operation.
Procedure
Step 1 Log in to the client of the NMS Maintenance Suite. For details, see 3.3 Logging in to the Client of the NMS Maintenance Suite.
Step 2 On the NMS Maintenance Suite client, choose NBI > Configure the SNMP interface instance from the Main Menu. The dialog box is displayed.
Step 3 In the General tab, choose the items in the left object tree, configure the basic project parameters of the SNMP NBI, refer to SNMP Agent and Third-Party NMS for more information.
Step 4 Click the Advanced tab. Choose the required items in the left object tree, refer 3.7 SNMP Configuration Parameters to set parameters.
l Heartbeat Settings l Alarm Field Settings l Set reporting notification l Report Date Format Settings l Other Settings
l MIB Frame Settings
Step 5 Click OK to complete the settings.
Step 6 Optional: In the case of a distribute HA system with multiple NICs, if you enter the IP address of the master server to deploy SNMP NBI, and this IP address is not in the relevant address drop-list, the Address for Standby Server dialog box is displayed.
CAUTION
l The SNMP service can deploy in the primary server only.
l You can enter any IP address of the standby server (except 127.0.0.1). But you must
ensure that the input IP address is correct. That is, the standby server should be able to communicate with the upper-layer NMS successfully with the input IP address.
l The CORBA NBI searches for the IP configuration list (hosts file) of the computer
automatically. Additionally, the first IP address in the configuration list is bound to the Naming service host address and Notify service host address. In the case of a single IP address, you need not set the Naming service host address and Notify service host address. In the case of multiple IP addresses, you need to set these fields because the bound IP address is unknown. When setting theses fields, you need to set them to IP addresses that the upper-layer NMS can have access to.
l Receive Request from NMS address is mandatory, Send Trap address is optional,
the two parameters can be different.
2. Click OK, complete the settings.
Step 7 The dialog box is displayed, prompt that restart all of the NMS service. Step 8 Click OK, close the dialog box.
Step 9 Log in to the System Monitor. Restart all services of the U2000.
Step 10 In the System Monitor client, check the Status of SNMP Service. If the process is running, the SNMP NBI is enabled successfully.