M2000 Northbound Alarm SNMP Interface Developer Guide

M2000
V200R012C00
Northbound Alarm SNMP Interface

Developer Guide
Issue
01
Date
2012-04-20
HUAWEI TECHNOLOGIES CO., LTD.
Copyright Huawei Technologies Co., Ltd. 2012. 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
Email:
support@huawei.com
Issue 01 (2012-04-20)
Huawei Proprietary and Confidential

Copyright Huawei Technologies Co., Ltd.
M2000
Northbound Alarm SNMP Interface Developer Guide
About This Document
About This Document
Purpose
This document provides information about the M2000 northbound alarm SNMP interface. The
document also provides operation guidelines for connecting the network management system
(NMS).
Related Versions
The following table lists product versions related to this document.
Product Name
Version
M2000
V200R012C00
Intended Audience
This document is intended for:
Network management engineers
Change History
01 (2012-04-20)
This issue is the first official release. Compared with issue Draft A (2012-02-10), this issue
incorporates the changes listed in the following table.
Issue 01 (2012-04-20)

ii
M2000
About This Document
Change
Description
l 1.5 Security Mechanism of

Northbound Alarm SNMP
Interface
Added.
l 6 Appendix: Scripts of the

Interface
1.6 Configuration File of the
Interface
Modified.
Draft A (2012-02-10)
This issue is a draft.
Organization
1 Introduction to Northbound Alarm SNMP Interface
This chapter describes the position of the northbound SNMP interface, the protocols that the
northbound interface supports, and the interconnection of the northbound alarm SNMP interface.
2 Trap Configuration Information of the Northbound Alarm SNMP Interface (M2000
MIB)
This chapter describes configuration information about the alarm traps for the northbound alarm
SNMP interface. It covers the following sections: overview, real-time alarm trap, active alarm
trap, start trap for querying active alarms, end trap for querying active alarms, and heartbeat
notification trap.
3 Trap Configuration Information of the Northbound Alarm SNMP Interface (HW MIB)
The HW-IMAPV1NORTHBOUND-TRAP-MIB (HW MIB for short) is used mainly in the
management of a multi-domain network or upgrades of network management systems (NMSs).
4 Interconnection Commissioning of the Northbound Alarm SNMP Interface
Before interconnecting the NMS with the M2000, you must conduct an interconnection
commissioning. Based on the commissioning result, determine whether the northbound SNMP
interface meets the conditions for interconnecting with the NMS.
5 Troubleshooting the Northbound Alarm SNMP Interface
If a fault occurs when the NMS interconnects to the M2000 through the northbound SNMP
interface, you need to adopt proper measures to rectify the fault. This chapter describes the
process and methods for handling faults related to the northbound SNMP interface.
6 Appendix: Scripts of the Northbound Alarm SNMP Interface
This section describes the scripts provided by the northbound alarm SNMP interface.
Issue 01 (2012-04-20)

iii
M2000
About This Document
Conventions
Symbol Conventions
The symbols that may be found in this document are defined as follows.
Symbol
Description
Indicates a hazard with a high level of risk, which if not
avoided, will result in death or serious injury.
Indicates a hazard with a medium or low level of risk, which
if not avoided, could result in minor or moderate injury.
Indicates a potentially hazardous situation, which if not
avoided, could result in equipment damage, data loss,
performance degradation, or unexpected results.
Indicates a tip that may help you solve a problem or save
time.
Provides additional information to emphasize or supplement
important points of the main text.
General Conventions
The general conventions that may be found in this document are defined as follows.
Convention
Description
Times New Roman
Normal paragraphs are in Times New Roman.
Boldface
Names of files, directories, folders, and users are in

boldface. For example, log in as user root.
Italic
Book titles are in italics.
Courier New
Examples of information displayed on the screen are in

Courier New.
Command Conventions
The command conventions that may be found in this document are defined as follows.
Issue 01 (2012-04-20)
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.

iv
M2000
About This Document
Convention
Description
{ 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 ">"

signs. For example, choose File > Create > Folder.
Keyboard Operations
The keyboard operations that may be found in this document are defined as follows.
Format
Description
Key
Press the key. For example, press Enter and press Tab.
Key 1+Key 2
Press the keys concurrently. For example, pressing Ctrl+Alt

+A means the three keys should be pressed concurrently.
Key 1, Key 2
Press the keys in turn. For example, pressing Alt, A means

the two keys should be pressed in turn.
Mouse Operations
The mouse operations that may be found in this document are defined as follows.
Issue 01 (2012-04-20)
Action
Description
Click
Select and release the primary mouse button without moving

the pointer.
M2000
Issue 01 (2012-04-20)
About This Document
Action
Description
Double-click
Press the primary mouse button twice continuously and

quickly without moving the pointer.
Drag
Press and hold the primary mouse button and move the
pointer to a certain position.

vi
M2000
Contents
Contents
About This Document.....................................................................................................................ii
1 Introduction to Northbound Alarm SNMP Interface.............................................................1
1.1 Definition of Northbound Interface....................................................................................................................3
1.2 Definition of Northbound Alarm SNMP Interface.............................................................................................3
1.3 MIB of the Northbound Alarm SNMP Interface................................................................................................4
1.4 Functions of the Northbound Alarm SNMP Interface........................................................................................5
1.4.1 Functions Supported by M2000 MIB........................................................................................................5
1.4.2 Functions Supported by HW MIB...........................................................................................................11
1.5 Security Mechanism of Northbound Alarm SNMP Interface..........................................................................12
1.6 Configuration File of the Northbound Alarm SNMP Interface........................................................................15
1.7 Mechanism for Forwarding Common Alarms..................................................................................................37
1.8 Technical Specifications of Northbound Alarm SNMP Interface....................................................................39
2 Trap Configuration Information of the Northbound Alarm SNMP Interface (M2000

MIB)...................................................................................................................................................40
2.1 Real-Time Alarm Trap.....................................................................................................................................41
2.1.1 Format of the Real-Time Alarm Trap......................................................................................................41
2.1.2 Fields in the Real-Time Alarm Trap........................................................................................................44
2.1.3 Definition of the Real-Time Alarm Trap.................................................................................................48
2.2 Active Alarm Trap............................................................................................................................................48
2.2.1 Format of the Active Alarm Trap............................................................................................................48
2.2.2 Fields of the Active Alarm Trap..............................................................................................................48
2.2.3 Definition of the Active Alarm Trap.......................................................................................................49
2.3 Start Trap for Querying Active Alarms............................................................................................................49
2.4 End Trap for Querying Active Alarms.............................................................................................................49
2.5 Heartbeat Notification Trap..............................................................................................................................50
3 Trap Configuration Information of the Northbound Alarm SNMP Interface (HW MIB)
............................................................................................................................................................51
3.1 Active Alarm Notification Trap.......................................................................................................................52
3.2 Active Alarm Synchronization Start Trap........................................................................................................55
3.3 Active Alarm Report Trap................................................................................................................................56
3.4 Active Alarm Synchronization End Trap.........................................................................................................60
3.5 KeepAlive Info (Heartbeat) Trap......................................................................................................................61
Issue 01 (2012-04-20)

vii
M2000
Contents
4 Interconnection Commissioning of the Northbound Alarm SNMP Interface................63

4.1 Negotiating the Interconnection Parameters of the Northbound Alarm SNMP Interface................................64
4.2 Commissioning the Interconnection of the Northbound Alarm SNMP Interface............................................65
4.2.1 Checking License (Alarm SNMP Interface)............................................................................................65
4.2.2 Commissioning the Interconnection of the Northbound Alarm SNMP Interface...................................65
5 Troubleshooting the Northbound Alarm SNMP Interface.................................................69

5.1 Common Troubleshooting and Information Collection (Alarm SNMP Interface)..........................................71
5.2 Troubleshooting Failure to Start the Northbound Alarm SNMP Interface Service After the M2000 Starts
................................................................................................................................................................................72
5.3 Troubleshooting Failure to Make New Settings Take Effect After Modifying the Configuration File...........73
5.4 Troubleshooting Inconsistency Between the Number of Fields Actually Reported and That of Fields in the
Configuration File...................................................................................................................................................73
5.5 Troubleshooting an Issue in Which No SNMP Log Is Recorded in the Specified File...................................74
5.6 Troubleshooting an Issue in Which Users Can Pass SNMPv3 Authentication with Only Part of the Cyclic
Password.................................................................................................................................................................74
5.7 How to Set Northbound Interface Compatibility.............................................................................................75
5.8 How to Set Parameters in a Northbound Configuration File............................................................................76
6 Appendix: Scripts of the Northbound Alarm SNMP Interface..........................................77
Issue 01 (2012-04-20)

viii
M2000
Introduction to Northbound Alarm SNMP

Interface
About This Chapter

This chapter describes the position of the northbound SNMP interface, the protocols that the
northbound interface supports, and the interconnection of the northbound alarm SNMP interface.
1.1 Definition of Northbound Interface
The northbound interface links the element management system (EMS) and the NMS.
1.2 Definition of Northbound Alarm SNMP Interface
The M2000 northbound alarm SNMP interface connects the NMS with the EMS. This interface
serves as an external interface in the entire M2000 system.
1.3 MIB of the Northbound Alarm SNMP Interface
The Management Information Base (MIB) is a key part of the SNMP network management
framework.
1.4 Functions of the Northbound Alarm SNMP Interface
The M2000 northbound alarm SNMP interface provides different management information
bases (MIBs) and supports different functions when different MIBs are loaded.
1.5 Security Mechanism of Northbound Alarm SNMP Interface
The security mechanism used by the northbound alarm SNMP interface is also the security
mechanism of the SNMP protocol. Any access to the northbound alarm SNMP interface must
be authenticated by the security mechanism of the specific SNMP version (SNMPv1, SNMPv2c,
and SNMPv3).
1.6 Configuration File of the Northbound Alarm SNMP Interface
This section describes the configuration file of the northbound alarm SNMP interface.
1.7 Mechanism for Forwarding Common Alarms
If the base stations of a multi-mode base station (MBTS) report common alarms simultaneously
to the M2000, the repeatedly reported alarms that are then forwarded from the M2000 to the
NMS may affect NMS services. The M2000 northbound interface provides policies for
M2000 users to determine whether to forward common alarms that are reported by different BSs
to the NMS.
1.8 Technical Specifications of Northbound Alarm SNMP Interface
Issue 01 (2012-04-20)

M2000
This section describes the technical specifications related to the northbound alarm SNMP
interface.
Issue 01 (2012-04-20)

M2000
1.1 Definition of Northbound Interface

The northbound interface links the element management system (EMS) and the NMS.
The NMS obtains information about the network elements (NEs) managed by the EMS and
delivers operation commands through the northbound interface. The NE information includes
the alarm, configuration, performance, and inventory data. Figure 1-1 shows the position of the
northbound interface in the network.
Figure 1-1 Position of the northbound interface
In the communication network, the M2000 provides the alarm, configuration, performance, and
inventory data of NEs to the NMS through the northbound interface.
1.2 Definition of Northbound Alarm SNMP Interface

The M2000 northbound alarm SNMP interface connects the NMS with the EMS. This interface
serves as an external interface in the entire M2000 system.
The M2000 supports SNMPv1, SNMPv2c, and SNMPv3. The NMS obtains information about
the supported protocol versions from the M2000 administrator.
Figure 1-2 shows the position of the northbound alarm SNMP interface in the network.
Issue 01 (2012-04-20)

M2000
Figure 1-2 Network position of the northbound alarm SNMP interface
The M2000 northbound alarm SNMP interface receives commands issued by the NMS according
to the SNMP protocol. Then, the interface responds to the commands and sends traps to inform
the NMS.
The SNMP is an industry standard protocol that is widely used for network management. It
ensures that:
l
You can transmit management information between any two nodes.
The administrator can search for and modify information, and locate faults at any node in
the network.
The administrator can diagnose the faults, plan the capacity, and generate reports.
The features of the SNMP are as follows:

l
Uses the polling mechanism to provide a basic function set. This ensures that the SNMP
fits small-sized, quick, and low-cost network scenarios.
Requires the User Datagram Protocol (UDP) only.
1.3 MIB of the Northbound Alarm SNMP Interface

The Management Information Base (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, apply to the managed objects in the MIB.
Issue 01 (2012-04-20)

M2000
The MIB defines the managed objects that are used by the function interfaces of the SNMP
northbound interface. The definitions determine the operations that the NMS can do and the
network management information that the NMS can obtain.
The International Organization for Standardization (ISO) assigns MIB node 2011 to Huawei
Technologies Co., Ltd.. Huawei Technologies Co., Ltd. assign MIB node 2011.2.15 to the NMS.
The NMS assigns MIB node 2 to the SNMP northbound interface. Therefore, the complete MIB
node information is:
iso(1).org(3).dod(6).internet(1).private(4).enterprises(1).iMAP(2011).products
(2).iMAPNetManagement(15).iMAPNorthbound(2)
IMAP-NORTHBOUND-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. The MIB node information is as follows:
--- iMAP(2011)
|--- products (2)
|--- iMAPNetManagement(15)
|--- iMAPNorthbound (2)
|---- iMAPNorthboundCommon(1)
|---- iMAPNorthboundFault(4)
iMAPNorthboundFault 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
RC: Read and Create
RW: Read and Write
RO: Read Only
1.4 Functions of the Northbound Alarm SNMP Interface

The M2000 northbound alarm SNMP interface provides different management information
bases (MIBs) and supports different functions when different MIBs are loaded.
Telecom operators can choose the MIB files to be loaded based on their requirements to facilitate
network maintenance and management.
l
M2000 MIB: loaded for managing radio access network (RAN) and core network (CN)
devices.
HW MIB: loaded for managing microwave and IP networking devices.
1.4.1 Functions Supported by M2000 MIB

This section describes the SNMP versions that the M2000 northbound alarm SNMP interface
complies with. It also describes the functions supported by this interface when M2000 MIB is
loaded.
Compliant SNMP Versions

Currently, the M2000 northbound alarm SNMP interface complies with SNMPv1, SNMPv2c,
and SNMPv3. For details, see Table 1-1.
Issue 01 (2012-04-20)

M2000
Table 1-1 Compliant SNMP versions

SNMP Version
Compliance
SNMPv1
l SNMPv1 operations
SNMP Get
SNMP Get Next
SNMP Set
l SNMPv1Trap
l SNMPv1 community-based security model
l SNMPv2c operations
SNMPv2c
SNMP Get
SNMP Get Next
SNMP Get Bulk
SNMP Set
l SNMPv2cTrap
l SNMPv2c community-based security model
l SNMPv3 operations
SNMPv3
SNMP Get
SNMP Get Next
SNMP Get Bulk
SNMP Set
l SNMPv3 Trap
l SNMPv3 user-based security model
CAUTION
SNMPv3 and the M2000 support three security levels: NoAuth and NoPriv, Auth and NoPriv,
Auth and Priv. Auth Protocol supports only MD5 and SHA.
Interface Functions
Table 1-2 lists the seven basic operations that the M2000 northbound alarm SNMP interface
provides to the NMS.
Table 1-2 Overview of the basic operations
Issue 01 (2012-04-20)
Basic Operation
Interface Function
Report alarms in real

time
The NMS receives real-time alarm traps through this interface.

M2000
Basic Operation
Interface Function
Query active alarms
The NMS queries active alarms through this interface.
Acknowledge active
alarms
The NMS acknowledges active alarms through this interface.
Unacknowledge
active alarms
The NMS unacknowledges active alarms through this interface.
Clear active alarms
The NMS clears active alarms through this interface.
Report heartbeat
traps
The NMS receives heartbeat traps through this interface.
Change the heartbeat

period
The M2000 northbound alarm SNMP interface allows the NMS to

change the heartbeat period in real time. The MIB provides a leaf
node about the heartbeat period to allow the NMS obtains and
changes the value of the heartbeat period in real time.
For details about the basic operations, see Table 1-3.

Table 1-3 Description of the basic operations
Basic Operation
Description
Report alarms in real

time
After the real-time alarm report function is enabled in the

configuration file, the M2000 sends real-time alarm traps to the NMS.
This function allows the NMS to learn about alarms generated on NEs
in real time.
The real-time alarms include: fault alarms, cleared alarms, event
alarms, acknowledged alarms, unacknowledged alarms, and changed
alarms.
Do as follows to enable the real-time alarm report function:
1. Modify the configuration file as M2000 administrator. For details,
see 1.6 Configuration File of the Northbound Alarm SNMP
Interface.
l Configure the IP address and port from which the NMS
receives traps.
l Set the criteria for filtering alarms by severity.
2. The NMS receives real-time alarms.
Issue 01 (2012-04-20)

M2000
Basic Operation
Description
Query active alarms
The active alarm query function allows the NMS to query active
alarms of NEs at any time.
Do as follows to enable the active alarm query function:
Interface.
receives traps.
l Set the criteria for filtering alarms by alarm severity.
2. Alarm query is triggered after the NMS sets the MIB node
iMAPNorthboundAlarmQuery to 1.
3. The NMS receives active alarms.
The NMS is not allowed to start a new query before the current
query is complete. The NMS can set iMAPNorthboundAlarmQuery to 0 to stop the current query while receiving active alarms.
Acknowledge active
alarms
The active alarm acknowledgment function allows the NMS to

acknowledge active alarms of NEs at any time.
Do as follows to enable the active alarm acknowledgment function:
Interface.
receives traps.
2. Alarm acknowledgment is triggered after the NMS sets the MIB
node iMAPNorthboundAlarmAcknowledge as the alarm serial
number. Multiple alarm serial numbers are separated by commas
(,).
3. The NMS receives and acknowledges alarms.
l If all alarms are acknowledged successfully, a null value is
returned.
l If there are any invalid alarm serial numbers or alarm serial
numbers that are not acknowledged, they are returned to the
NMS.
The NMS is not allowed to start a new acknowledgment before the
current acknowledgment is complete.
Issue 01 (2012-04-20)

M2000
Basic Operation
Description
Unacknowledge
active alarms
The active alarm unacknowledgment function allows the NMS to

unacknowledge active alarms of NEs at any time.
Do as follows to enable the active alarm unacknowledgment function:
Interface.
receives traps.
2. Alarm unacknowledgment is triggered after the NMS sets the MIB
node iMAPNorthboundAlarmUnAcknowledge as the alarm
serial number. Multiple alarm serial numbers are separated by
commas (,).
3. The NMS receives and unacknowledges alarms.
l If all alarms are unacknowledged successfully, a null value is
returned.
numbers that are not unacknowledged, they are returned to the
NMS.
The NMS is not allowed to start a new unacknowledgment before the
current unacknowledgment is complete.
Clear active alarms
The active alarm clearance function allows the NMS to clear active
alarms of NEs at any time.
Do as follows to enable the active alarm clearance function:
Interface.
receives traps.
2. Alarm clearance is triggered after the NMS sets the MIB node
iMAPNorthboundAlarmClear as the alarm serial number.
Multiple alarm serial numbers are separated by commas (,).
3. The NMS receives and clears alarms.
l If all alarms are cleared successfully, a null value is returned.
numbers that are not cleared, they are returned to the NMS.
The NMS is not allowed to start a new clearance before the current
clearance is complete.
Issue 01 (2012-04-20)

M2000
Basic Operation
Description
Report heartbeat
traps
After configuring the IP address and port for receiving traps, the NMS
periodically receives heartbeat traps from the M2000 within the preset
heartbeat period. The heartbeat traps help the NMS learn about its
connection status with the M2000. If the NMS does not receive
heartbeat traps from the M2000 within the preset heartbeat period, its
connection with the M2000 is abnormal. If the NMS receives
heartbeat traps from the M2000 within the preset heartbeat period, its
connection with the M2000 is normal.
Do as follows to enable the heartbeat trap report function:
Interface.
receives traps.
l Set the heartbeat period to a value that is greater than 0. In the
configuration file, the default heartbeat period is 60 seconds.
2. The NMS receives heartbeat traps.
Change the heartbeat

period
Do as follows to change the heartbeat period:

l Description
Gain access to and change the leaf node of the heartbeat period.
l OID
OID= 1.3.6.1.4.1.2011.2.15.2.1.3.1.1
l fullpath
fullpath= .iso(1).org(3).dod(6).internet(1).private(4).enterprises
(1).iMAP(2011).products(2).iMAPNetManagement
(15).iMAPNorthbound(2).iMAPNorthboundCommon
(1).iMAPNorthboundCommuLinkMonitor(3).iMAPNorthboundHeartbeatSvc(1).iMAPNorthboundHeartbeatSvcReportInterval(1)
l Field List
For details about the field list, see Table 1-4.
Issue 01 (2012-04-20)

10
M2000
Table 1-4 iMAPNorthboundHeartbeatSvcReportInterval field list

MIB
Variable
Descripti
on
Data
Type
Index Or
Not
Access
Method
Value
Range
Restricti
on
iMAPNort
hboundHe
artbeatSvc
ReportInte
rval
Gain
access to
and
change the
leaf node
of the
heartbeat
period.
INTEGER
No
RW
3 - 3600
current
1.4.2 Functions Supported by HW MIB

When loaded with the HW MIB, the SNMP NBI supports automatic alarm reporting,
synchronizing, clearing, acknowledging, and unacknowledging. Alarm synchronizing is to
query active alarms.
M2000
At the M2000 side, the primary functions are:
l
Reporting alarms
Reporting heartbeat
NOTE
To enable this function, set third-party NMS parameters only on the M2000 when deploying the SNMP
NBI instead of configuring the NMS. Alarm information will be received at the preset port of the NMS
server.
After receiving alarms from the equipment or the M2000, the SNMP NBI reports these alarms
to the NMS by means of standard SNMP trap messages.
The SNMP NBI periodically reports heartbeat to the NMS. Based on the heartbeat, the NMS
determines whether the connection with the SNMP NBI is proper.
Function
Description
Subscribi
ng alarms
Subscribes alarms by alarm severity and alarm category. You can set the severity
and category when deploying the SNMP NBI.
Sets the alarm field or variable binding (VB).
Issue 01 (2012-04-20)
Reporting
alarms
Reports alarms from NEs or the M2000.
Reporting
heartbeat
Reports heartbeat and sets the heartbeat period.

11
M2000
NMS
At the NMS side, the primary functions are:
l
Synchronizing alarms (querying current alarms)
Changing filter criteria in real time
Acknowledging/Unacknowledging alarms
Clearing alarms
NOTE
Ensure that the NMS is connected to the SNMP NBI properly before the query function is enabled.
Function
Description
Synchronizing
alarms (querying
current alarms)
Queries current alarms (uncleared alarms) on the M2000 in the Set

operation.
Querying alarms by
criteria
Reports alarms by alarm severity and category. The filter criteria are
specified during alarm subscription.
To query current alarms on the M2000, the NMS issues the query
begin command (value: 1) in the Set operation. After receiving the
command, the SNMP agent queries current alarms from the M2000
and reports the result to the NMS. If there are too many alarms and
the query needs to be stopped, the NMS issues the query end
command (value: 0) in the Set operation. After receiving the
command, the SNMP agent stops querying and does not report the
result to the NMS.
You can change filter criteria in real time when loading the HW MIB.
Changing filter
criteria in real time
Changes filter criteria using the Set operation when the SNMP NBI
is running.
The change will take effect without restarting the SNMP NBI.
Acknowledging/
Unacknowledging
alarms
Acknowledges or unacknowledges current alarms on the M2000

based on alarm serial numbers (SNs).
Clearing alarms
Clears alarms on the M2000 based on alarm SNs.
1.5 Security Mechanism of Northbound Alarm SNMP

Interface
The security mechanism used by the northbound alarm SNMP interface is also the security
mechanism of the SNMP protocol. Any access to the northbound alarm SNMP interface must
be authenticated by the security mechanism of the specific SNMP version (SNMPv1, SNMPv2c,
and SNMPv3).
Figure 1-3 shows that SNMPv1 and SNMPv2c use the community-based security mechanism,
while SNMPv3 uses the user-based security mechanism.
Issue 01 (2012-04-20)

12
M2000
Figure 1-3 Security mechanism of northbound alarm SNMP interface
SNMPv1 and SNMPv2

The security mechanism of SNMPv1 and SNMPv2c is community-based: The NMS
authenticates NEs based on the community name list and the agent does not check the validity
of the community name. SNMP packets are transferred without encryption. Therefore,
authentication security and confidentiality are not well guaranteed.
l
Before the Get, Get Next, or Set operation, the NMS must know the read and write
community names configured for the agent.
For trap and inform packets, the community name is the read community name configured
for the agent.
NOTE
SNMPv1 does not support the inform mode.
SNMPV3
The security mechanism of SNMPv3 is user-based. In terms of security, SNMPv3 emphasizes
data security and access control and therefore offers a higher level of security than SNMPv1 and
SNMPv2c.
In data security, SNMPv3 provides protection for SNMP packets in the following ways:
l
Data integrity check

The data cannot be modified in an unauthorized manner. Any changes in the data sequence
are limited to the allowed extent.
Data origin authentication

SNMPv3 authenticates users from whom received packets are sent rather than applications
that generate these packets.
Data confidentiality check

When the NMS or agent receives a packet, it checks when the packet was generated. If the
interval between the creation time and the system time exceeds the preset time range, this
Issue 01 (2012-04-20)

13
M2000
packet will be discarded. This check prevents packets from being maliciously modified and
malicious packets from being received.
In access control, the NMS performs security checks on managed objects (MOs) based on
SNMPv3.
Security Level
Table 1-5 shows security levels supported by the SNMP versions.
Table 1-5
Version
Security Level
v1
Without
authentication
and encryption
v2c
Without
authentication
and encryption
v3
Without
authentication
and encryption
v3
With
authentication
and without
encryption
With
authentication
and encryption
v3
Authenticatio
n
Community
Community
User name
MD5 or SHA
MD5 or SHA
Data
Encryption
Description
None
Uses only
community
names for
access
authentication.
None
Uses only
community
names for
access
authentication.
None
Uses only user

names for
access
authentication.
None
Uses MD5 or
SHA algorithms
for
authentication.
AES or DES
Uses MD5 or
SHA algorithms
for
authentication;
AES or DES
algorithms for
data encryption.
NOTE
The following rules are applicable to SNMPv3:
Issue 01 (2012-04-20)
You can set a different user name, authentication password, and encryption password from others.
You can select any of the listed security levels, authentication algorithms, and encryption algorithms.

14
M2000
1.6 Configuration File of the Northbound Alarm SNMP

Interface
This section describes the configuration file of the northbound alarm SNMP interface.
Overview
To configure the northbound alarm SNMP interface, modify the following items in the
configuration file:
l
SNMPv3 protocol
NMS information
Heartbeat period
Reported fields
Alarm transfer mode
Report type of the Csn field
FDN adapter
Maintenance-mode Alarm Report

NOTE
l The configuration file is stored in /opt/oss/server/nbi/snmp/conf/snmpagent.xml.

l After modifying the configuration file, run the following command to restart the northbound alarm
SNMP interface service for the configuration to take effect:
svc_adm -cmd restartsvc SnmpAgent
l You can modify the parameters of the northbound configuration file either by running commands or
by using the OSMU. For details about the operations performed on the OSMU, see 5.8 How to Set
Parameters in a Northbound Configuration File.
Table 1-6 describes the parameters in the snmpagent.xml file.

Table 1-6 Parameters in the snmpagent.xml file
Issue 01 (2012-04-20)
Paramete
r
Path of
Configuration
Item
Description
Default
Value
Delimiter
snmpagent->MIB1>Delimiter
Delimiter between character elements in

the ObjectInstance and ResourceIDs
fields.
Space

15
M2000
Paramete
r
Path of
Configuration
Item
Description
Default
Value
ResIDFor
mat
snmpagent->MIB1>ResIDFormat
Specifies whether to display the resource

information in FDN format.
NOTE
This parameter applies only to HW MIB and
can be set to:
l 0: octet format. The ResourceIDs and
ObjectInstance fields are displayed in
octet format. For example,
[3145731.-1.22.8.912.1.-1.-1].
l 1: FDN format. The ResourceIDs and
ObjectInstance fields are displayed in
FDN format. For example,
[NE=312323,FR=1,S=1,CP=1,PP=4|1|
2|].
If a northbound interface compatibility ID
has been set, the M2000 will adjust the EMS
ID and FDN format based on the setting. For
example, the EMS ID is changed from OSS
to OMC and the FDN is changed from dotted
format to name-value format. For details, see
5.7 How to Set Northbound Interface
Compatibility.
SupportX
733Alarm
snmpagent->MIB1>SupportX733Alarm
Specifies whether the X733 standard is

supported. This parameter can be set to:
l 0: The X733 standard is supported.

l 1: The X733 standard is not
supported.
KeepAliv
eVBOID
snmpagent->MIB1>KeepAliveVBOID
Specifies the type of heartbeat VB OIDs.

This parameter is set to
1.3.6.1.4.1.2011.2.15.1 by default. It can
also be set to
1.3.6.1.4.1.2011.2.15.1.7.2.1.
1.3.6.1.4.1.
2011.2.15.1
NotifyOI
D
snmpagent->MIB1>NotifyOID
Specifies the trap OIDs for alarms. This

parameter can be set to:
l 0: All alarms use the same trap OID.

l 1: Alarms of different severities use
different trap OIDs.
T2000Sup
port
snmpagent->MIB1>T2000Support
Specifies whether to enable T2000 fields

such as ObjectInstance,
ProbableCause, EventDetail,
ProbableRepair, and EventName.
CsnType
snmpagent->MIB2>CsnType
Specifies the format of the AlarmCSN

field. This parameter can be set to:
l 0: character string.
l 1: integer.
Issue 01 (2012-04-20)

16
M2000
Paramete
r
Path of
Configuration
Item
Description
Default
Value
SupportC
M
snmpagent->MIB2>SupportCM
Specifies whether to enable the

configuration of CMC ENUM. This
parameter can be set to:
l 0: disable the configuration of CMC

ENUM.
l 1: enable the configuration of CMC
ENUM.
SNMPv3 Protocol
M2000The M2000 supports SNMPv1, SNMPv2c, and SNMPv3. By default, it supports
SNMPv3.
Do as follows to configure the SNMP protocol:
Modify Level, AuthProtocol, and PrivProtocol in snmpagent->v3trap.
NOTE
Level and AuthProtocol apply only to SNMPv3.
Table 1-7 describes the parameters for configuring the SNMPv3 protocol.
Table 1-7 Configuring the SNMPv3 protocol
Parameter
Path of
Configuration
Item
Description
Default Value
Level
snmpagent>v3trap->Level
Sets the security

level:
l 1: unauthorized
and unencrypted
l 2: authorized but
unencrypted
l 3: authorized and
encrypted
AuthProtocol
snmpagent>v3trap>AuthProtocol
Sets the
authorization
protocol:
l 1: MD5 protocol
l 2: SHA protocol
Issue 01 (2012-04-20)

17
M2000
Parameter
Path of
Configuration
Item
Description
Default Value
PrivProtocol
snmpagent>v3trap>PrivProtocol
Sets the encryption

protocol of
SNMPv3:
l 1: DES
encryption
protocol
l 2: AES
encryption
protocol
NOTE
The M2000 uses 127.0.0.1 as the default IP address for running the SNMP service. If the NMS requires to
use a specific IP address, perform the following operations to configure the SNMP service information.
For example, to avoid possible impact of M2000 active/standby switchovers on northbound
interconnection, use the logical IP address of an M2000 HA system to configure the SNMP service when
interconnecting the NMS with the HA system.
(Optional) Do as follows to configure the SNMP service information:

Modify Agent_IP in snmpagent->common.
Table 1-8 describes the parameters for configuring the SNMP service information:
Table 1-8 Configuring the SNMP service information
Para
met
er
Path of Configuration Item
Description
Defa
ult
Valu
e
Agen
t_IP
snmpagent->common->Agent_IP
IP address for running the SNMP

service.
127.0
.0.1
l When the operating system has

only one IP address, the default
value is 127.0.0.1. The SNMP
service runs on the IP address of
the operating system.
l When the operating system has
two IP addresses, set this
parameter to either of the IP
addresses. Otherwise, the NMS
cannot determine the IP address
where the SNMP service runs.
Agen
t_Por
t
Issue 01 (2012-04-20)
snmpagent->common>Agent_Port
Port for running the SNMP service.

Generally, this parameter does not
need to be modified.

4700
18
M2000
NMS Information
The M2000 can concurrently interconnect with four NMSs.
Set the following configuration items related to each NMS:
l
Security user name in v3
Community name in v1 or v2
Authentication password in v3 (authenticated but unencrypted)
Encrypted password in v3
IP address for receiving traps
Port for receiving traps
Alarm severity
Alarm category
Table 1-9 describes the parameters for configuring the NMS information and the path of the
parameters in the configuration file.
NOTE
The configuration file displays community names and passwords in ciphertext. Therefore, before setting
a community name or password, run the following commands to enable the GenerateNBPass script to
encrypt the community name or password and then set the corresponding configuration item to the
encrypted community name or password. Send the plaintext community names and passwords to the NMS
OM personnel and explain them how to use the GenerateNBPass script.
The community names and passwords must meet the following requirements:
l
The character string contains a minimum of 8 characters and a maximum of 30 characters.
The character string contains at least three of the following four character types:
l Lowercase letters
l Uppercase letters
l Arabic numerals
l Underscores (_)
The default installation directory of the M2000 server is /opt/oss/server.

1. cd /opt/oss/server
2. . ./svc_profile.sh
3. cd /opt/oss/server/nbi/snmp/bin
4. GenerateNBPass -e community name or password to be encrypted
The system displays information similar to the following. In which, information after Encrypt
password result: is the encrypted community name or password:
Encrypt password result: VnYJqua5dagADOng43KJdgy
Table 1-9 Configuring the NMS information

Parameter
Description
IPAddress
snmpagent->nmsinfo->IPAddress
IP address or host name for the

NMS to receive traps. You can set
this parameter to an IP address or
a host name.
You can set nmsinfo to nmsinfo1,

nmsinfo2, nmsinfo3, or nmsinfo4.
Issue 01 (2012-04-20)

19
M2000
Parameter
Description
Port
snmpagent->nmsinfo->Port
Port for the NMS to receive traps.

The parameters IPAddress and
Port specify the NMS server that
receives real-time alarm traps,
active alarm query traps, and
heartbeat traps.

Version
snmpagent->nmsinfo->Version
SNMP version.

l 1: SNMPv1
l 2: SNMPv2
l 3: SNMPv3
Read
snmpagent ->nmsinfo>community1->Read
snmpagent ->nmsinfo>community1->Write
Write

snmpagent->nmsinfo->V3User
V3User

AuthPassword
snmpagent->nmsinfo>AuthPassword
Any read entity specified in the

SAC memory for connecting to
the SNMP agent.
Run the GenerateNBPass -e
command to encrypt the entity
before use.
Any write entity specified in the
SAC memory for setting the MIB
field.
Run the GenerateNBPass -e
command to encrypt the entity
before use.
If the parameter Version is set to
3, this parameter specifies the
security user name of SNMPv3.
Authentication password of an
NMS user. This parameter applies
when SNMPv3 authentication is
enabled.
You need to encrypt the password
and set this parameter to the
encrypted password according to
the note before Table 1-9.
PrivPassword
snmpagent->nmsinfo>PrivPassword
If the version value is set to 3 and

the security level is set to 3, you
must set the encryption policy for
the password.
You need to encrypt the password
and set this parameter to the
encrypted password according to
the note before Table 1-9.
Issue 01 (2012-04-20)

20
M2000
Parameter
Description
Critical
snmpagent->nmsinfo->alarmlevel>Critical
Whether to filter out critical

alarms reported to the NMS.

l 0: Critical alarms are filtered

out and not reported to the
NMS.
l 1: Critical alarms are not
filtered out and reported to the
NMS.
Major
snmpagent->nmsinfo->alarmlevel>Major
Whether to filter out major alarms

reported to the NMS.

l 0: Major alarms are filtered out

and not reported to the NMS.
l 1: Major alarms are not filtered
out and reported to the NMS.
Minor
snmpagent->nmsinfo->alarmlevel>Minor
Whether to filter out minor alarms


l 0: Minor alarms are filtered out

l 1: Minor alarms are not filtered
Warning
snmpagent->nmsinfo->alarmlevel>Warning
Whether to filter out warning


l 0: Warning alarms are filtered

NMS.
l 1: Warning alarms are not
NMS.
Event
snmpagent->nmsinfo->category>Event
Whether to filter out events


l 0: Events are filtered out and

not reported to the NMS.
l 1: Events are not filtered out
and reported to the NMS.
Fault
snmpagent->nmsinfo->category>Fault
Whether to filter out fault alarms


l 0: Fault alarms are filtered out

l 1: Fault alarms are not filtered
Issue 01 (2012-04-20)

21
M2000
Parameter
Description
Recover
snmpagent->nmsinfo->category>Recover
Whether to filter out cleared


l 0: Cleared alarms are filtered

NMS.
l 1: Cleared alarms are not
NMS.
Acknowledge
snmpagent->nmsinfo->category>Acknowledge
Whether to filter out

acknowledged alarms reported to
the NMS.
l 0: Acknowledged alarms are
filtered out and not reported to
the NMS.
l 1: Acknowledged alarms are
not filtered out and reported to
the NMS.
Unacknowled
ge
snmpagent->nmsinfo->category>Unacknowledge
Whether to filter out

unacknowledged alarms reported
to the NMS.
l 0: Unacknowledged alarms
alarms are filtered out and not
l 1: Unacknowledged alarms
are not filtered out and
Change
snmpagent->nmsinfo->category>Change
Whether to filter out changed


l 0: Changed alarms are filtered

NMS.
l 1: Changed alarms are not
NMS.
NeTypeFilter
snmpagent->nmsinfo>NeTypeFilter
Issue 01 (2012-04-20)

Parameter for filtering out alarms

by device type. By default, this
parameter is not set and therefore
alarms generated on all NEs are
reported. To filter out alarms of
multiple device types, separate the
device types with commas (,)
when setting this parameter.
22
M2000
Parameter
Description
MaintenanceA
larmFilter
snmpagent->nmsinfo>MaintenanceAlarmFilter
Whether to filter out maintenance


l 0: Maintenance alarms are

filtered out and not reported to
the NMS.
l 1: Maintenance alarms are not
NMS.
To configure the NMS, you need to open the configuration file, delete information similar to
 and , and manually configure the related
configuration items.

<nmsinfo name="nmsinfo1">
<param name="IPAddress"></param>
<param name="Port"></param>
<community name="community1">
<param name="Read"></param>
<param name="Write"></param>
</community>
<param name="Version">1</param>
<alarmlevel name="alarmlevel">
<param name="Critical"></param>
<param name="Major"></param>
<param name="Minor"></param>
<param name="Warning"></param>
</alarmlevel>
<category name="category">
<param name="Event"></param>
<param name="Fault"></param>
<param name="Recover"></param>
<param name="Acknowledge"></param>
<param name="Unacknowledge"></param>
<param name="Change"></param>
</category>
<param name="NETypeFilter"></param>
<param name="MaintenanceAlarmFilter"></param>
</nmsinfo>

Heartbeat Period
Table 1-10 describes the parameters for configuring the heartbeat period and the path of the
Issue 01 (2012-04-20)

23
M2000
Table 1-10 Configuring the heartbeat period

Parameter
Path of
Configuration
Item
Description
Default Value
Interval
snmpagent>heartbeat>Interval
Period for reporting

heartbeat traps. The
value range is 3 and
3600 seconds. If this
parameter is set to 0
or to a value that is
not within the
specified range, the
default value 60
seconds is used.
60
Enable
snmpagent>heartbeat>Enable
Whether to enable
heartbeat trap
reporting. When this
parameter is set to 0,
heartbeat trap
reporting is disabled.
When this parameter
is set to a non-0
value, heartbeat trap
reporting is enabled.
Lable
snmpagent>heartbeat->Lable
Identifier of
heartbeat trap
reporting.
SNMP Agent
Reported Fields
The M2000 provides the real-time alarm trap service to the NMS. If the NMS subscribes to this
service, the M2000 sends real-time alarms to the NMS in the form of traps. For details about
how to subscribe to this service, see 2.1 Real-Time Alarm Trap.
To configure real-time alarm traps, set parameters under snmpagent->MIB2->Mib in the
configuration file.
l
Set VB1 to Csn.
Set VB2 to Category.
Set VB3 to OccurTime.
Set VB4 to MOName.
Set VB5 to ProductID.
Set VB6 to NEType.
Set VB7 to NEDevId.
Set VB8 to DevCsn.
Set VB9 to ID.
Issue 01 (2012-04-20)

24
M2000
Set VB10 to Type.
Set VB11 to Level.
Set VB12 to Restore.
Set VB13 to Confirm.
Set VB14 to AckTime.
Set VB15 to RestoreTime.
Set VB16 to Operator.
Set VB17 to ExtendInfo.
Set VB18 to Probablecause.
Set VB19 to Proposedrepairactions.
Set VB20 to SpecificProblems.
Set VB21 to ClearOperator.
Set VB22 to ObjectInstanceType.
Set VB23 to ClearCategory.
Set VB24 to ClearType.
Set VB25 to ServiceAffectFlag.
Set VB26 to AdditionalInfo.
You can set ExtendProductItemX to an integer or a character string, where X can be set to 1,
2, 3, ..15. For details, see 2.3 Start Trap for Querying Active Alarms.
Table 1-11 lists all the reported alarm fields that can be configured and the path of the related
Table 1-11 Configurable reported alarm fields
Issue 01 (2012-04-20)
VB Name
Description
Csn
snmpagent->MIB2->Mib->Csn
Network serial number of an

alarm. This field is used as a
keyword to match the fault alarm,
cleared alarm, event alarm,
acknowledged alarm,
unacknowledged alarm, or
changed alarm.

25
M2000
VB Name
Description
Category
snmpagent->MIB2->Mib>Category
Category of an alarm. You to set

filter criteria based on the
following alarm categories:
1. Fault alarm
2. Cleared alarm
3. Event alarm
4. Acknowledged alarm
5. Unacknowledged alarm
6. Unknown alarm
7. Unknown alarm
8. Unknown alarm
9. Changed alarm
OccurTime
snmpagent->MIB2->Mib>OccurTime
Time when an alarm is generated

on a device.
MOName
snmpagent->MIB2->Mib>MOName
Name of a device.
snmpagent->MIB2->Mib>ProductID
ID of a product.
snmpagent->MIB2->Mib>NEType
Type of a device.
snmpagent->MIB2->Mib>NEDevID
ID of a device.
snmpagent->MIB2->Mib>DevCsn
Unique serial number of a faulty

device.
ProductID
NEType
NEDevID
DevCsn
This field identifies the name of

the device where an alarm is
generated.
This field identifies the product

series of the device where an
alarm is generated.
This field identifies the type of

the device where an alarm is
generated.
In the M2000 system, a device ID

is unique. This field identifies the
ID of the device where an alarm
is generated.
This field is used for counting

faulty devices.
Issue 01 (2012-04-20)

26
M2000
VB Name
Description
ID
snmpagent->MIB2->Mib->ID
ID of an alarm category.
You can define multiple alarm
categories for a device type.
After you define alarm categories
for a device type, a device of the
device type can only report
alarms of the predefined alarm
categories.
Type
snmpagent->MIB2->Mib>Type
Type of an alarm. The alarm types

are as follows:
1. Power system
2. Environmental system
3. Signaling system
4. Trunk system
5. Hardware system
6. Software system
7. Running system
8. Communication system
9. QoS
10.Processing error
11.Internal
12.Integrity violation
13.Operational violation
14.Physical violation
15.Security service or
mechanism violation
16.Time domain violation
Level
snmpagent->MIB2->Mib>Level
Severity of an alarm.
This field can be set to:
l 1: Critical
l 2: Major
l 3: Minor
l 4: Warning
l 5: Indeterminate
l 6: Cleared
Restore
snmpagent->MIB2->Mib>Restore
Clearance identifier.
l 1: Cleared
l 2: Uncleared
Issue 01 (2012-04-20)

27
M2000
VB Name
Description
Confirm
snmpagent->MIB2->Mib>Confirm
Acknowledgment identifier.
l 1: Acknowledged
l 2: Unacknowledged
AckTime
snmpagent->MIB2->Mib>AckTime
Acknowledgment time.
snmpagent->MIB2->Mib>RestoreTime
Clearance time.
snmpagent->MIB2->Mib>Operator
Acknowledgment operator.
snmpagent->MIB2->Mib>ExtendInfo
Extended information.
snmpagent->MIB2->Mib>Probablecause
Alarm cause.
Proposedrepairactions
snmpagent->MIB2->Mib>Proposedrepairactions
Alarm handling suggestion.
Specificproblems
snmpagent->MIB2->Mib>Specificproblems
Detailed alarm cause.
ClearOperator
snmpagent->MIB2->Mib>ClearOperator
Operator who clears an alarm.
ObjectInstanceType
snmpagent->MIB2->Mib>ObjectInstanceType
Type of an alarm object instance.
ClearCategory
snmpagent->MIB2->Mib>ClearCategory
Alarm clearance category.
RestoreTime
Operator
ExtendInfo
Probablecause
This field identifies the time

when an alarm is acknowledged.
This field identifies the time

when an alarm is cleared.
This field identifies the operator

who acknowledges an alarm.
This field contains the location

information about an alarm.
This field identifies the cause of

an alarm.
This field provides the suggestion

for handling an alarm.
l Automatically Detected
Automatically Cleared
(ADAC)
l Automatically Detected
Manually Cleared (ADMC)
Issue 01 (2012-04-20)

28
M2000
VB Name
Description
ClearType
snmpagent->MIB2->Mib>ClearType
Alarm clearance type.

l Normal Clear
l Restore Clear
l Manual Clear
l Configure Clear
l Co-relation Clear
Issue 01 (2012-04-20)
ServiceAffectFlag
snmpagent->MIB2->Mib>ServiceAffectFlag
Identifies whether a service is

affected.
AdditionalInfo
snmpagent->MIB2->Mib>AdditionalInfo
Additional information about an

alarm.
ExtendProductItem1
snmpagent->MIB2->Mib>ExtendProductItem1
Extended product information

based on Huawei alarm
specifications.
ExtendProductItem2

specifications.
ExtendProductItem3

specifications.
ExtendProductItem4

specifications.
ExtendProductItem5

specifications.
ExtendProductItem6

specifications.
ExtendProductItem7

specifications.
ExtendProductItem8

specifications.
ExtendProductItem9

specifications.
ExtendProductItem10

specifications.

29
M2000
VB Name
Description
ExtendProductItem11

specifications.
ExtendProductItem12

specifications.
ExtendProductItem13

specifications.
ExtendProductItem14

specifications.
ExtendProductItem15

specifications.
Alarm Transfer Mode

Table 1-12 describes the parameters for transferring alarms and the path of the parameters in
the configuration file.
Issue 01 (2012-04-20)

30
M2000
Table 1-12 Configuring the alarm transfer mode

Parameter
Description
Default
Value
Supported
MIB
snmpagent->common>SupportedMIB
Specifies the type of the

MIB to be loaded.
MIB2
l MIB1 indicates
message MIB. OIDs
corresponding to
HWIMAPV1NORTHB
OUND-TRAPMIB.mib are
supported.
l MIB2 indicates
distributed MIB.
OIDs corresponding
to
IMAP_NORTHBO
UND_MIB-V1.mib
and
IMAP_NORTHBO
UND_MIB-V2.mib
are supported.
Issue 01 (2012-04-20)
TrapSendI
P
snmpagent->common>TrapSendIP
Source IP address from

which traps and informs
are sent. If an invalid
value is set, the system
IP address is used.
127.0.0.1
TrapSendP
ort
snmpagent->common>TrapSendPort
Source port over which

traps and informs are
sent. If an invalid value
is set, the system obtains
a port randomly.
6666
TrapSendIn
terval
snmpagent->common>TrapSendInterval
Interval for sending traps

to the NMS. This
parameter is
inapplicable to informs.
The value range is 1 to
1000 microseconds.

31
M2000
Parameter
Description
Default
Value
TimeForma
t
snmpagent->common>TimeFormat
Time format of the VB

field that identifies alarm
time. The time format
can be set to:
l 0: UTC time
l 1: Local time without
time zone
l 2: Local time with
time zone
l 3: UTC time, which
has a different time
format compared
with the UTC time
when this parameter
is set to 0
l 4: Local time
TimeType
snmpagent->common>TimeType
Type of alarm reporting

time, which can be set to
1 or 2.
l 0: UTC time
l 1: EMS time
l 2: NE time
StringSize
snmpagent->common>StringSize
Maximum length of a
character string that can
be restored in the VB.
4096
ActiveAlar
m
snmpagent->common>ActiveAlarm
Specifies to query
current alarms or active
alarms. When it is set to
0, current alarms are
queried. When it is set to
a non-0 value, active
alarms are queried.
TrapCodin
g
snmpagent->common>TrapCoding
Character set encoding

of alarm traps.
ISO-8859-1
l UTF-8
l ISO-8859-1
l GBK
Issue 01 (2012-04-20)

32
M2000
Parameter
Description
Default
Value
SupportRo
otAlarm
snmpagent->common>SupportRootAlarm
Specifies whether to
support root alarms. This
root alarm analysis
function is valid only
after transport or access
E2E function
components are
installed.
l When it is set to 0,
root alarms are not
supported and all
alarms are reported
and queried.
root alarms are
supported and alarms
except correlative
alarms are reported
and queried.
PDUTrace
snmpagent->common->
PDUTrace
Specifies whether to
print PDU trace in logs.
PDU trace is not
printed in logs.
PDU trace is printed
in logs.
Table 1-13 describes the inform parameters.

Table 1-13 Configuring the inform parameters
Issue 01 (2012-04-20)
Parameter
Description
Enable
snmpagent->inform->Enable
Specifies whether to report 0

alarms in the form of
informs. When it is set to 1,
alarms are reported in the
form of informs. When it is
set to a non-1 value, alarms
are not reported in the form
of informs.

Default
Value
33
M2000
Parameter
Description
Default
Value
Timeout
snmpagent->inform>Timeout
Parameter specified by the

SNMP inform protocol,
which specifies the timeout
period for sending an
inform message. The
default value is five
seconds. The minimum
value is one second.
Retries
snmpagent->inform->Retries
Parameter specified by the

SNMP inform protocol,
which specifies the number
of attempts for resending an
inform message. The
minimum value is 0.
CacheSize
snmpagent->inform>CacheSize
Specifies the size of the

cache for real-time alarms.
The maximum value is
50000 and the minimum
value is 0. An independent
cache is assigned to each
NMS user.
10000
Report Type of the Csn Field

Table 1-14 describes the parameters for configuring the report type of the Csn field and the path
of the parameters in the configuration file.
Issue 01 (2012-04-20)

34
M2000
Table 1-14 Configuring the report type of the Csn field

Parame
ter
Description
Default Value
CsnTyp
e
snmpagent->MIB2->CsnType
Specifies the
report type of
the Csn field that
identifies alarm
serial numbers.
l When it is set
to 1, alarms
are reported
in the form of
integers.
l When it is set
to a non-1
value, alarms
are reported
in the form of
character
strings.
FDN Adapter
NOTE
You do not need to configure the FDN adapter for the RTN.
In V200R012 and later releases, objects are uniquely identified by distinguished names (DNs)
instead of by full distinguished names (FDNs). DNs are represented in the format of "xxx = yyy"
and FDNs are represented in the format of dot-decimal notation. In scenarios where the
M2000 is upgraded to V200R012 or a later release, you need to enable the FDN adapter to adapt
and switch DNs back to FDNs for reporting the NEDevID field.
Table 1-15 describes the path of the parameters for configuring the FDN adapter in the
configuration file.
Issue 01 (2012-04-20)

35
M2000
Table 1-15 Configuring the FDN adapter

Parame
ter
Description
Default Value
FDNAd
apter
snmpagent->MIB2->FDNAdapter
Specifies
whether to
enable the
adaption from
DNs to FDNs.
This
configuration
item is
inapplicable to
the RTN.
l When it is set
to 0, the FDN
adapter is
disabled.
l When it is set
to a non-0
value, the
FDN adapter
is enabled.
Maintenance-mode Alarm Report

To enable the maintenance-mode alarm report function, perform the following steps:
1.
Log in to the M2000 server as user ossuser.
2.
Run the following command to enable the maintenance-mode alarm report function:
If this function is disabled, the NMS cannot obtain maintenance-mode alarms from any of
the northbound alarm interfaces.
SettingTool -cmd setparam -path /imap/ifms/specialAlarmStatus/enable -value true
3.
Run the following commands to enable the maintenance-mode alarm report function over
the SNMP interface:
If this function is disabled, the NMS cannot obtain maintenance-mode alarms from the
alarm SNMP interface.
SettingTool -cmd setparam -path /imap/ifms/specialAlarmStatus/nbenable -value true
NOTE
If either /imap/ifms/specialAlarmStatus/enable or /imap/ifms/specialAlarmStatus/nbenable is

set to false, the NMS cannot obtain maintenance-mode alarms from the alarm SNMP interface.
4.
Run the following command to restart FaultService:

svc_adm -cmd restartsvc FaultService
5.
Run the following command to verify that FaultService has been started:
svc_adm -cmd status | grep FaultService
If the system displays the following information, FaultService has been started:
Issue 01 (2012-04-20)

36
M2000
FaultService

[running
1.7 Mechanism for Forwarding Common Alarms

If the base stations of a multi-mode base station (MBTS) report common alarms simultaneously
to the M2000, the repeatedly reported alarms that are then forwarded from the M2000 to the
NMS may affect NMS services. The M2000 northbound interface provides policies for
M2000 users to determine whether to forward common alarms that are reported by different BSs
to the NMS.
The base stations of an MBTS share some common resources such as power module and FAN
unit. When faults occur on common resources, the BSs report alarms to the M2000
simultaneously.
Common alarms are classified into the following types:
l
MBTS-GSM common alarms
MBTS-UMTS common alarms
MBTS-LTE common alarms
MBTS (GU)-GSM common alarms
MBTS (GU)-UMTS common alarms
MBTS (GL)-GSM common alarms
MBTS (GL)-LTE common alarms
MBTS (UL)-UMTS common alarms
MBTS (UL)-LTE common alarms
MBTS (GUL)-GSM common alarms
MBTS (GUL)-UMTS common alarms
MBTS (GUL)-LTE common alarms
MBTS (WL)-LTE common alarms
MBTS (WL)-WiMax common alarms
Users can modify the configuration items to determine whether to forward the corresponding
common alarms by running the SettingTool command. For details about how to set policies for
forwarding common alarms, see Table 1-16.
Following is an example of running the SettingTool command to forward MBTS (GU)-GSM
common alarms.
1.
Run the following command to forward MBTS (GU)-GSM common alarms:

-bash-3.00$ . /opt/oss/server/svc_profile.sh
-bash-3.00$ SettingTool -cmd modparam -path /imap/ifms/MBTS_Filter/
GU_GSM -value yes
NOTE
Users can run the following command for not forwarding MBTS (GU)-GSM common alarms:
-bash-3.00$ SettingTool -cmd modparam -path /imap/ifms/MBTS_Filter/GU_GSM -value
no
2.
Issue 01 (2012-04-20)
Run the following command to check whether the configuration items have been modified
successfully:
37
M2000
-bash-3.00$ SettingTool -cmd getparam -path /imap/ifms/MBTS_Filter/

GU_GSM
3.
Run the following command to restart the fault service for the modification to take effect:
-bash-3.00$ svc_adm -cmd restartsvc FaultService
Table 1-16 Setting policies for forwarding common alarms
Issue 01 (2012-04-20)
Common Alarm
Path in the SettingTool

Command
Default Value
MBTS-GSM common
alarms
/imap/ifms/MBTS_Filter/
OLD_GSM
yes
MBTS-UMTS common
alarms
OLD_UMTS
yes
MBTS-LTE common alarms
OLD_LTE
yes
MBTS (GU)-GSM common

alarms
GU_GSM
yes
MBTS (GU)-UMTS
common alarms
GU_UMTS
yes
MBTS (GL)-GSM common

alarms
GL_GSM
yes
MBTS (GL)-LTE common

alarms
GL_LTE
yes
MBTS (UL)-UMTS
common alarms
UL_UMTS
yes
MBTS (UL)-LTE common

alarms
UL_LTE
yes
MBTS (GUL)-GSM
common alarms
GUL_GSM
yes
MBTS (GUL)-UMTS
common alarms
GUL_UMTS
yes
MBTS (GUL)-LTE common

alarms
GUL_LTE
yes
MBTS (WL)-LTE common

alarms
WL_LTE
yes
MBTS (WL)-WiMax
common alarms
WL_WiMax
yes

38
M2000
1.8 Technical Specifications of Northbound Alarm SNMP

Interface
This section describes the technical specifications related to the northbound alarm SNMP
interface.
Issue 01 (2012-04-20)
Specification Item
Value
Maximum number of connections on the alarm SNMP interface
Maximum delay in reporting a northbound alarm (unit: second)
15

39
M2000
2 Trap Configuration Information of the Northbound Alarm

SNMP Interface (M2000 MIB)
Trap Configuration Information of the
Northbound Alarm SNMP Interface (M2000

MIB)
About This Chapter
This chapter describes configuration information about the alarm traps for the northbound alarm
SNMP interface. It covers the following sections: overview, real-time alarm trap, active alarm
trap, start trap for querying active alarms, end trap for querying active alarms, and heartbeat
notification trap.
2.1 Real-Time Alarm Trap
The M2000 sends information about real-time alarms to the NMS using real-time alarm traps.
The real-time alarm trap is implemented in this way. If an alarm on a device or the M2000 is
generated, the M2000 sends a real-time alarm trap to the NMS.
2.2 Active Alarm Trap
The M2000 sends information about active alarms to the NMS using active alarm traps. The
active alarm trap is implemented in this way. If an alarm on a device or the M2000 is generated,
the M2000 sends an active alarm trap to the NMS.
2.3 Start Trap for Querying Active Alarms
This section describes the start trap for querying active alarms, which includes description,
prerequisites, trap definition, and field list.
2.4 End Trap for Querying Active Alarms
This section describes the end trap for querying active alarms, which includes description,
2.5 Heartbeat Notification Trap
This section describes the function, triggering conditions, definition, and field lists of the
heartbeat notification trap.
Issue 01 (2012-04-20)

40
M2000

2.1 Real-Time Alarm Trap

The M2000 sends information about real-time alarms to the NMS using real-time alarm traps.
The real-time alarm trap is implemented in this way. If an alarm on a device or the M2000 is
generated, the M2000 sends a real-time alarm trap to the NMS.
2.1.1 Format of the Real-Time Alarm Trap

This section describes the format of the real-time alarm trap.
The real-time alarm trap contains the following fields, as shown in Figure 2-1.
Figure 2-1 Format of the real-time alarm trap
Device Information
The device information contains the following fields:
l
iMAPNorthboundAlarmProductID: ID of a product. This field identifies the product

series of the device where an alarm is generated.
iMAPNorthboundAlarmNEType: device type. The SNMP alarm interface supports all

types of NEs connected to the M2000. For details about the mapping between NE type IDs
and NE type names, see the Mapping Between M2000 NE Type IDs and NE Type
Names.xls delivered with the version.
iMAPNorthboundAlarmNEDevID: ID of a device. This field identifies the ID of the

device where an alarm is generated. In the M2000 system, a device ID is unique.
iMAPNorthboundAlarmMOName: name of a device. This field identifies the name of

the device where an alarm is generated.
Figure 2-2 shows the device types.
Figure 2-2 Device types
Issue 01 (2012-04-20)

41
M2000

In the following scenarios, device names are reported in DN format:

The alarm service starts. When the alarm service starts, the object information is not
loaded to memory. The names of objects where alarms (not new alarms) are queried are
displayed as dn and updated to the actual names after the alarm service is started.
NEs have been deleted. When objects are deleted, object names are displayed within a
certain duration and then NE names are displayed. If NEs are also deleted, the names
are displayed as dn.
Alarms are reported by the RTN.
Alarm Information
The alarm information contains the iMAPNorthboundAlarmID field, which is described as
follows:
iMAPNorthboundAlarmID: ID of an alarm category. You can define multiple alarm categories
for a device type. After you define alarm categories for a device type, a device of the device type
can only report alarms of the predefined alarm categories. Figure 2-3 shows the mapping
between device types and alarm categories. An alarm category is uniquely identified by the fields
product ID, device type, and alarm ID. Using the three fields, the NMS determines the alarm
category to which a received alarm belongs.
Figure 2-3 Mapping between device types and alarm categories
Basic Alarm Attributes

The basic alarm attributes contain the following fields:
l
iMAPNorthboundAlarmType: type of an alarm. This field can be set to:

1: Power system
2: Environmental system
3: Signaling system
4: Trunk system
5: Hardware system
Issue 01 (2012-04-20)

42
M2000

6: Software system
7: Running system
8: Communication system
9: QoS
10: Processing error
11: OMC
12: Integrity violation
13: Operational violation
14: Physical violation
15: Security service or mechanism violation
16: Time domain violation
l
iMAPNorthboundAlarmType: severity of an alarm. This field can be set to:

1: Critical
2: Major
3: Minor
4: Warning
5: Indeterminate
6: Cleared
iMAPNorthboundAlarmOccurTime: time when an alarm is generated on a device.
iMAPNorthboundAlarmDevCsn: alarm device serial number. This field identifies the

serial number of an alarm generated on a device. The device alarm serial number is unique
on the device.
iMAPNorthboundAlarmCSN: alarm network serial number. This field is used as a

keyword to match the following alarm categories:
Fault alarm
Cleared alarm
Event alarm
Acknowledged alarm
Unacknowledged alarm
Changed alarm
iMAPNorthboundAlarmCategory: category of an alarm. This field can be set to:
1: Fault
2: Cleared
3: Event
4: Acknowledged
5: Unacknowledged
9: Changed
iMAPNorthboundAlarmConfirm: acknowledgment identifier. This field can be set to:

1: Acknowledged
2: Unacknowledged
Issue 01 (2012-04-20)

43
M2000

iMAPNorthboundAlarmAckTime: acknowledgment time.
iMAPNorthboundAlarmRestore: clearance identifier.

1: Cleared
2: Uncleared
iMAPNorthboundAlarmRestoreTime: clearance time.
iMAPNorthboundAlarmOperator: operator who acknowledges an alarm.
iMAPNorthboundAlarmClearOperator: operator who clears an alarm.
Additional Information
The additional information contains the following fields:
l
iMAPNorthboundAlarmExtendInfo: extended information. This field contains the

location information about an alarm.
iMAPNorthboundAlarmProbablecause: alarm cause. This field identifies the cause of

an alarm.
iMAPNorthboundAlarmProposedrepairactions: alarm handling suggestion. This field

provides the suggestion for handling an alarm.
iMAPNorthboundAlarmSpecificProblems: detailed alarm cause.
iMAPNorthboundAlarmObjectInstanceType: type of an alarm object instance.
iMAPNorthboundAlarmClearCategory: alarm clearance category.
iMAPNorthboundAlarmClearType: alarm clearance type.
iMAPNorthboundAlarmServiceAffectFlag: identifies whether a service is affected.
iMAPNorthboundAlarmAddionalInfo: additional alarm information.
Reserved Fields
The reserved fields are as follows:
l
iMAPNorthboundAlarmParas1
2.1.2 Fields in the Real-Time Alarm Trap

This section describes the fields in the real-time alarm trap when the M2000 uses different
versions of protocols to interconnect with the NMS.
By default, the field types in Table 2-1 use the data types when the v1 protocol is used for
interconnection.
Issue 01 (2012-04-20)

44
M2000

NOTE
The same data types when the v2c or v3 protocol is used for interconnection are not described.
Types that are not the same are noted in brackets.
x refers to 1.3.6.1.4.1.2011.2.15.2.4.3.3. For example, x.1 refers to 1.3.6.1.4.1.2011.2.15.2.4.3.3.1.
Table 2-1 iMAPNorthboundFaultAlarmReportNotificationType field list

Name
OID
Type
Description
iMAPNorthbou
ndAlarmCSN
x.1
OCTET STRING
Network serial number of an alarm, which

uniquely identifies the alarm.
iMAPNorthbou
ndAlarmCatego
ry
x.2
OCTET STRING
Category of an alarm, which can be set to:

l 1: Fault
l 2: Cleared
l 3: Event
l 4: Acknowledged
l 5: Unacknowledged
l 9: Changed
Issue 01 (2012-04-20)
iMAPNorthbou
ndAlarmOccur
Time
x.3
OCTET STRING
Time when an alarm is generated.
iMAPNorthbou
ndAlarmMONa
me
x.4
OCTET STRING
Name of a device.
iMAPNorthbou
ndAlarmProduc
tID
x.5
INTEGER
ID of product series.
iMAPNorthbou
ndAlarmNETyp
e
x.6
OCTET STRING
Identity of a device type. The SNMP

alarm interface supports all types of NEs
connected to the M2000. For details about
the mapping between NE type IDs and NE
type names, see the Mapping Between
M2000 NE Type IDs and NE Type
Names.xls delivered with the version.
iMAPNorthbou
ndAlarmNEDev
ID
x.7
OCTET STRING
ID of a device, which uniquely identifies

a device.
iMAPNorthbou
ndAlarmDevCs
n
x.8
OCTET STRING
Alarm device serial number, which is

unique on a device.
iMAPNorthbou
ndAlarmID
x.9
INTEGER
(Integer32)
ID of an alarm, which is used to identify

alarm categories for the same type of
devices.

45
M2000

Name
OID
Type
Description
iMAPNorthbou
ndAlarmType
x.10
INTEGER
(Integer32)
Type of an alarm, which can be set to:

l 1: Power system
l 2: Environmental system
l 3: Signaling system
l 4: Trunk system
l 5: Hardware system
l 6: Software system
l 7: Running system
l 8: Communication system
l 9: QoS
l 10: Processing error
l 11: OMC
l 12: Integrity violation
l 13: Operational violation
l 14: Physical violation
l 15: Security service or mechanism
violation
l 16: Time domain violation
iMAPNorthbou
ndAlarmLevel
x.11
INTEGER
Severity of an alarm, which can be set to:

l 1: Critical
l 2: Major
l 3: Minor
l 4: Warning
l 5: Indeterminate
l 6: Cleared
iMAPNorthbou
ndAlarmRestor
e
x.12
iMAPNorthbou
ndAlarmConfir
m
x.13
INTEGER
Clearance identifier, which can be set to:

l 1: Cleared
l 2: Uncleared
INTEGER
Acknowledgment identifier, which can be

set to:
l 1: Acknowledged
l 2: Unacknowledged
Issue 01 (2012-04-20)
iMAPNorthbou
ndAlarmAckTi
me
x.14
OCTET STRING
Time when an alarm is acknowledged.
iMAPNorthbou
ndAlarmRestor
eTime
x.15
OCTET STRING
Time when an alarm is cleared.

46
M2000
Issue 01 (2012-04-20)

Name
OID
Type
Description
iMAPNorthbou
ndAlarmOperat
or
x.16
OCTET STRING
Operator who acknowledges an alarm.
iMAPNorthbou
ndAlarmParas1
x.17
INTEGER
(Integer32)
Reserved field 1.
iMAPNorthbou
ndAlarmParas2
x.18
INTEGER
(Integer32)
Reserved field 2.
iMAPNorthbou
ndAlarmParas3
x.19
INTEGER
(Integer32)
Reserved field 3.
iMAPNorthbou
ndAlarmParas4
x.20
INTEGER
(Integer32)
Reserved field 4.
iMAPNorthbou
ndAlarmParas5
x.21
INTEGER
(Integer32)
Reserved field 5.
iMAPNorthbou
ndAlarmParas6
x.22
INTEGER
(Integer32)
Reserved field 6.
iMAPNorthbou
ndAlarmParas7
x.23
INTEGER
(Integer32)
Reserved field 7.
iMAPNorthbou
ndAlarmParas8
x.24
INTEGER
(Integer32)
Reserved field 8.
iMAPNorthbou
ndAlarmParas9
x.25
INTEGER
(Integer32)
Reserved field 9.
iMAPNorthbou
ndAlarmParas1
0
x.26
INTEGER
(Integer32)
Reserved field 10.
iMAPNorthbou
ndAlarmExtend
Info
x.27
OCTET STRING
Extended information, which contains the

location information about an alarm.
iMAPNorthbou
ndAlarmProbab
lecause
x.28
OCTET STRING
Cause of an alarm.
iMAPNorthbou
ndAlarmPropos
edrepairactions
x.29
OCTET STRING
Suggestion for handling an alarm.
iMAPNorthbou
ndAlarmSpecifi
cproblems
x.30
OCTET STRING
Detailed cause of an alarm.
iMAPNorthbou
ndAlarmClearO
perator
x.46
OCTET STRING
Operator who clears an alarm.

47
M2000

Name
OID
Type
Description
iMAPNorthbou
ndAlarmClearC
ategory
x.48
OCTET STRING
Alarm clearance category, which can be

set to:
l 1: Alarms that can be cleared
automatically
l 2: Alarms that cannot be cleared
automatically
iMAPNorthbou
ndAlarmClearT
ype
x.49
OCTET STRING
Alarm clearance type, which can be set to:

l 1: Normal clear
l 2: Restore clear
l 3: Manual Clear
l 4: Configure Clear
l 5: Co-relation Clear
iMAPNorthbou
ndAlarmServiceAffectFlag
x.50
iMAPNorthbou
ndAlarmAddio
nalInfo
x.51
OCTET STRING
Identifies whether a service is affected.

l 0: No
l 1: Yes
OCTET STRING
Additional information.
2.1.3 Definition of the Real-Time Alarm Trap

This section describes how to define a real-time alarm trap.
A real-time alarm trap is defined as follows:
OID= 1.3.6.1.4.1.2011.2.15.2.4.3.3.0.1
2.2 Active Alarm Trap

The M2000 sends information about active alarms to the NMS using active alarm traps. The
active alarm trap is implemented in this way. If an alarm on a device or the M2000 is generated,
the M2000 sends an active alarm trap to the NMS.
2.2.1 Format of the Active Alarm Trap

This section describes the format of the active alarm trap.
The format of the active alarm trap is the same as that of the real-time alarm trap. For details,
see 2.1.1 Format of the Real-Time Alarm Trap.
2.2.2 Fields of the Active Alarm Trap

This section describes the fields of the active alarm trap, which include name, OID, type, and
description.
Issue 01 (2012-04-20)

48
M2000

The fields of the active alarm trap are the same as those of the real-time alarm trap. For details,
see 2.1.2 Fields in the Real-Time Alarm Trap.
2.2.3 Definition of the Active Alarm Trap

This section describes how to define the active alarm trap.
The active alarm trap is defined as follows:
OID= 1.3.6.1.4.1.2011.2.15.2.4.3.3.0.3
2.3 Start Trap for Querying Active Alarms

This section describes the start trap for querying active alarms, which includes description,
Description
The M2000 notifies the NMS that it starts sending the queried active alarms. After the NMS
receives the start trap, the query starts.
Prerequisites
The NMS triggers the query.
Trap Definition
OID= 1.3.6.1.4.1.2011.2.15.2.4.3.3.0.2
Field List
None.
2.4 End Trap for Querying Active Alarms

This section describes the end trap for querying active alarms, which includes description,
Description
The M2000 notifies the NMS that it stops sending the queried active alarms. After the NMS
receives the end trap, the query ends.
Prerequisites
The NMS triggers the stop of the query, or the query ends after the NMS receives active alarms.
Trap Definition
OID= 1.3.6.1.4.1.2011.2.15.2.4.3.3.0.4
Issue 01 (2012-04-20)

49
M2000

Field List
None.
2.5 Heartbeat Notification Trap

This section describes the function, triggering conditions, definition, and field lists of the
heartbeat notification trap.
Description
The M2000 regularly sends a heartbeat notification trap to the NMS. If the NMS receives a
heartbeat notification trap within a heartbeat period, the connection between the NMS and
M2000 is normal. If the trap is not received, the NMS and M2000 are disconnected.
Prerequisites
The M2000 regularly sends a heartbeat notification trap to the NMS in the preset period.
Trap Definition
OID= 1.3.6.1.4.1.2011.2.15.2.1.2.1.1.1.0.5
Field List
In Table 2-2, by default, the field types are those used for the connection with SNMPv1. For
SNMPv2c or SNMPv3, the same data types are not introduced again. Different data types are
noted in brackets.
Table 2-2 Fields of iMAPNorthboundHeartbeatNotificationType
Issue 01 (2012-04-20)
Name
OID
Type
Description
iMAPNorthbo
undHeartbeatS
ystemLabel
1.3.6.1.4.1.2011.2.15.2.1.2.1.1.1.1
OCTET
STRING
M2000 system
ID
iMAPNorthbo
undHeartbeatP
eriod
1.3.6.1.4.1.2011.2.15.2.1.2.1.1.1.2
INTEGER
(Integer32)
Heartbeat
period in
seconds (must
be greater than
0, and the
maximum is
3600).
iMAPNorthbo
undHeartbeatT
imeStamp
1.3.6.1.4.1.2011.2.15.2.1.2.1.1.1.3
OCTET
STRING
Timestamp, the
time when the
heartbeat
notification trap
is generated.

50
M2000

SNMP Interface (HW MIB)
Trap Configuration Information of the
Northbound Alarm SNMP Interface (HW MIB)

About This Chapter
The HW-IMAPV1NORTHBOUND-TRAP-MIB (HW MIB for short) is used mainly in the
management of a multi-domain network or upgrades of network management systems (NMSs).
3.1 Active Alarm Notification Trap
3.2 Active Alarm Synchronization Start Trap
3.3 Active Alarm Report Trap
3.4 Active Alarm Synchronization End Trap
3.5 KeepAlive Info (Heartbeat) Trap
Issue 01 (2012-04-20)

51
M2000

3.1 Active Alarm Notification Trap

Function
When alarms are generated on NEs or the M2000, the M2000 automatically sends this type of
traps to notify the OSS of real-time alarms through the SNMP NBI.
Trigger Condition
Alarms generated on NEs or the M2000 trigger the sending of active alarm notification traps
through the SNMP NBI.
Definition
Name
Enterprise
Type
Description
hwNmNorthboundE
ventNotify
hwNmNorthboundE
ventInfo
Trap/Inform
Indicates that realtime alarms are

reported.
VB List
In the following table, listed data types are for SNMPv1. Most of these data types are applicable
to SNMPv2c or SNMPv3. For any differences, details will be described in brackets.
NOTE
Bound variables (VBs) are the same for active alarm notification and report traps. Active alarm notification
traps are automatically sent by the M2000 while active alarm report traps are responses to the query of
active alarms from the OSS.
Additional VB are not reported by default. Additional VBs range from
hwNmNorthboundsAdditionalVB1 to hwNmNorthboundsAdditionalVB8.
VB
OID
Data
Type
Description
hwNmNorthboundNEName
1.3.6.1.4.1.2011.2.
15.1.7.1.1
Octet
string
Indicates the name of a network

element (NE).
hwNmNorthboundNEType
1.3.6.1.4.1.2011.2.
15.1.7.1.2
Octet
string
Indicates the device type of a NE.
hwNmNorthboundObjectInstance
1.3.6.1.4.1.2011.2.
15.1.7.1.3
Octet
string
Indicates the alarm location. The

options are as follows:
l Rack
l Frame
l Slot
l Subslot
l Port
Issue 01 (2012-04-20)

52
M2000

VB
OID
Data
Type
Description
hwNmNorthbound
EventType
1.3.6.1.4.1.2011.2.
15.1.7.1.4
Octet
string
Indicates the type of events.

l Communication
l Environment
l Equipment
l Service
l Processerror
l Integrity
l Operational
l Physical
l SecurityServiceOrMechanism
l TimeDomain
hwNmNorthbound
EventTime
1.3.6.1.4.1.2011.2.
15.1.7.1.5
Octet
string
Indicates time when the alarm was

generated. The options are as
follows:
l Local Time (YYYY/MM/DDhh:mm:ss)
l UTC Time (YYYY/MM/DDhh:mm:ssZ)
l Local with Time Zone
(YYYY/MM/
DD:hh:mm:ss:hh:mmTZ)
hwNmNorthboundProbableCause
1.3.6.1.4.1.2011.2.
15.1.7.1.6
Octet
string
Indicates the probable cause of the

alarm.
hwNmNorthboundSeverity
1.3.6.1.4.1.2011.2.
15.1.7.1.7
Octet
string
Indicates the alarm severity. The

l Critical
l Major
l Minor
l Warning
l Indeterminate
Issue 01 (2012-04-20)
hwNmNorthbound
EventDetail
1.3.6.1.4.1.2011.2.
15.1.7.1.8
Octet
string
Indicates the alarm ID and

detailed information.
hwNmNorthboundAdditionalInfo
1.3.6.1.4.1.2011.2.
15.1.7.1.9
Octet
string
Indicates the additional

information of an NE.

53
M2000

VB
OID
Data
Type
Description
hwNmNorthboundFaultFlag
1.3.6.1.4.1.2011.2.
15.1.7.1.10
Octet
string
Indicates the flag bit for an alarm.

The options are as follows:
l Event
l Fault
l Recovery
hwNmNorthboundFaultFunction
1.3.6.1.4.1.2011.2.
15.1.7.1.11
Octet
string
Indicates the function type of an

alarm. The options are as follows:
l Power
l Environment
l Signal
l Relay
l Hardware
l Software
l Run
l Communication
l Service
l Processerror
l UNKNOWN_FU NC_TYPE
Issue 01 (2012-04-20)
hwNmNorthboundDeviceIP
1.3.6.1.4.1.2011.2.
15.1.7.1.12
IP address
Indicates the IP address of a

device.
hwNmNorthboundSerialNo
1.3.6.1.4.1.2011.2.
15.1.7.1.13
Integer
Indicates the serial number of an

alarm.
hwNmNorthboundProbableRepair
1.3.6.1.4.1.2011.2.
15.1.7.1.14
Octet
string
Indicates the alarm

troubleshooting suggestions.
hwNmNorthboundResourceIDs
1.3.6.1.4.1.2011.2.
15.1.7.1.15
Octet
string
Indicates the ID of a resource.
hwNmNorthboundsAdditionalVB1
1.3.6.1.4.1.2011.2.
15.1.7.1.16
Octet
string

1.3.6.1.4.1.2011.2.
15.1.7.1.17
Octet
string

1.3.6.1.4.1.2011.2.
15.1.7.1.18
Octet
string

information about the alarm.
1.3.6.1.4.1.2011.2.
15.1.7.1.19
Octet
string

1.3.6.1.4.1.2011.2.
15.1.7.1.20
Octet
string


54
M2000

VB
OID
Data
Type
Description
1.3.6.1.4.1.2011.2.
15.1.7.1.21
Octet
string

1.3.6.1.4.1.2011.2.
15.1.7.1.22
Octet
string

1.3.6.1.4.1.2011.2.
15.1.7.1.23
Octet
string

hwNmNorthbound
EventName
1.3.6.1.4.1.2011.2.
15.1.7.1.24
Octet
string
Indicates the name of an event.
hwNmNorthboundReasonID
1.3.6.1.4.1.2011.2.
15.1.7.1.25
Integer
Indicates the ID of an alarm.
hwNmNorthboundFaultID
1.3.6.1.4.1.2011.2.
15.1.7.1.26
Integer
Indicates the fault ID of an alarm.
hwNmNorthboundDeviceType
1.3.6.1.4.1.2011.2.
15.1.7.1.27
Octet
string
Indicates the device type ID of an

alarm.
hwNmNorthboundTrailName
1.3.6.1.4.1.2011.2.
15.1.7.1.28
Octet
string
Indicates the name of the trail

affected by an alarm.
hwNmNorthboundRootAlarm
1.3.6.1.4.1.2011.2.
15.1.7.1.29
Integer
Specifies whether the alarm is root

alarm or not.
l 0: Non-root alarm
l 1: Root alarm
hwNmNorthboundGroupID
1.3.6.1.4.1.2011.2.
15.1.7.1.30
Integer
Indicates the group ID the alarm

belongs to.
hwNmNorthboundMaintainStatus
1.3.6.1.4.1.2011.2.
15.1.7.1.31
Integer
Indicates the engineering alarm

status.
3.2 Active Alarm Synchronization Start Trap

Function
After the OSS sends alarm query requests, the M2000 sends this type of traps to inform the OSS
that the synchronization starts.
Trigger Condition
The OSS triggers the alarm synchronization.
The OSS performs the operation hwNmNorthboundEventSynchronizationCommandStart
in the following format:
NMS IP:port:start time:end time
Issue 01 (2012-04-20)

55
M2000

NOTE
l NMS IP:Port indicates the IP address and port of the OSS.

l The format for start and end time is YYYYMMDDhhmmss.
Definition
Name
Enterprise
Type
Description
hwNmNorthboundE
ventSynchronizationStartNotify
hwNmNorthboundE
ventSynchronizationStart
Trap/Inform
Indicates that the

alarm
synchronization is
started.
VB List
N/A
3.3 Active Alarm Report Trap

Function
After the OSS initiates the alarm synchronization, the M2000 sends this type of traps to report
required alarms on the M2000 to the OSS.
Trigger Condition
The OSS triggers the synchronization.
The OSS performs the operation hwNmNorthboundEventSynchronizationCommandStart
in the following format:
NMS IP:port:start time:end time
NOTE
l NMS IP:Port indicates the IP address and port of the OSS.

l The format for start and end time is YYYYMMDDhhmmss.
Definition
Issue 01 (2012-04-20)
Name
Enterprise
Type
Description
hwNmNorthboundE
ventSynchronizationQueryResultNotify
hwNmNorthboundE
ventSynchronizationQueryResult
Trap/Inform
Indicates the
synchronization
result or required
alarms.

56
M2000

VB List
In the following table, listed data types are for SNMPv1. Most of these data types are applicable
to SNMPv2c or SNMPv3. For any differences, details will be described in brackets.
NOTE
Bound variables (VBs) are the same for active alarm notification and report traps. Active alarm notification
traps are automatically sent by the M2000 while active alarm report traps are responses to the query of
active alarms from the OSS.
Additional VB are not reported by default. Additional VBs range from
hwNmNorthboundsAdditionalVB1 to hwNmNorthboundsAdditionalVB8.
VB
OID
Data
Type
Description
hwNmNorthboundNEName
1.3.6.1.4.1.2011.2.
15.1.7.1.1
Octet
string
Indicates the name of a network

element (NE).
hwNmNorthboundNEType
1.3.6.1.4.1.2011.2.
15.1.7.1.2
Octet
string
Indicates the device type of a NE.
hwNmNorthboundObjectInstance
1.3.6.1.4.1.2011.2.
15.1.7.1.3
Octet
string
Indicates the alarm location. The

l Rack
l Frame
l Slot
l Subslot
l Port
hwNmNorthbound
EventType
1.3.6.1.4.1.2011.2.
15.1.7.1.4
Octet
string
Indicates the type of events.

l Communication
l Environment
l Equipment
l Service
l Processerror
l Integrity
l Operational
l Physical
l SecurityServiceOrMechanism
l TimeDomain
Issue 01 (2012-04-20)

57
M2000

VB
OID
Data
Type
Description
hwNmNorthbound
EventTime
1.3.6.1.4.1.2011.2.
15.1.7.1.5
Octet
string
Indicates time when the alarm was

generated. The options are as
follows:
l Local Time (YYYY/MM/DDhh:mm:ss)
l UTC Time (YYYY/MM/DDhh:mm:ssZ)
l Local with Time Zone
(YYYY/MM/
DD:hh:mm:ss:hh:mmTZ)
hwNmNorthboundProbableCause
1.3.6.1.4.1.2011.2.
15.1.7.1.6
Octet
string
Indicates the probable cause of the

alarm.
hwNmNorthboundSeverity
1.3.6.1.4.1.2011.2.
15.1.7.1.7
Octet
string
Indicates the alarm severity. The

l Critical
l Major
l Minor
l Warning
l Indeterminate
hwNmNorthbound
EventDetail
1.3.6.1.4.1.2011.2.
15.1.7.1.8
Octet
string
Indicates the alarm ID and

detailed information.
hwNmNorthboundAdditionalInfo
1.3.6.1.4.1.2011.2.
15.1.7.1.9
Octet
string

information of an NE.
hwNmNorthboundFaultFlag
1.3.6.1.4.1.2011.2.
15.1.7.1.10
Octet
string
Indicates the flag bit for an alarm.

The options are as follows:
l Event
l Fault
l Recovery
Issue 01 (2012-04-20)

58
M2000

VB
OID
Data
Type
Description
hwNmNorthboundFaultFunction
1.3.6.1.4.1.2011.2.
15.1.7.1.11
Octet
string
Indicates the function type of an

alarm. The options are as follows:
l Power
l Environment
l Signal
l Relay
l Hardware
l Software
l Run
l Communication
l Service
l Processerror
l UNKNOWN_FU NC_TYPE
Issue 01 (2012-04-20)
hwNmNorthboundDeviceIP
1.3.6.1.4.1.2011.2.
15.1.7.1.12
IP address
Indicates the IP address of a

device.
hwNmNorthboundSerialNo
1.3.6.1.4.1.2011.2.
15.1.7.1.13
Integer
Indicates the serial number of an

alarm.
hwNmNorthboundProbableRepair
1.3.6.1.4.1.2011.2.
15.1.7.1.14
Octet
string
Indicates the alarm

troubleshooting suggestions.
hwNmNorthboundResourceIDs
1.3.6.1.4.1.2011.2.
15.1.7.1.15
Octet
string
Indicates the ID of a resource.
1.3.6.1.4.1.2011.2.
15.1.7.1.16
Octet
string

1.3.6.1.4.1.2011.2.
15.1.7.1.17
Octet
string

1.3.6.1.4.1.2011.2.
15.1.7.1.18
Octet
string

1.3.6.1.4.1.2011.2.
15.1.7.1.19
Octet
string

1.3.6.1.4.1.2011.2.
15.1.7.1.20
Octet
string

1.3.6.1.4.1.2011.2.
15.1.7.1.21
Octet
string

1.3.6.1.4.1.2011.2.
15.1.7.1.22
Octet
string

1.3.6.1.4.1.2011.2.
15.1.7.1.23
Octet
string


59
M2000

VB
OID
Data
Type
Description
hwNmNorthbound
EventName
1.3.6.1.4.1.2011.2.
15.1.7.1.24
Octet
string
Indicates the name of an event.
hwNmNorthboundReasonID
1.3.6.1.4.1.2011.2.
15.1.7.1.25
Integer
Indicates the ID of an alarm.
hwNmNorthboundFaultID
1.3.6.1.4.1.2011.2.
15.1.7.1.26
Integer
Indicates the fault ID of an alarm.
hwNmNorthboundDeviceType
1.3.6.1.4.1.2011.2.
15.1.7.1.27
Octet
string
Indicates the device type ID of an

alarm.
hwNmNorthboundTrailName
1.3.6.1.4.1.2011.2.
15.1.7.1.28
Octet
string
Indicates the name of the trail

affected by an alarm.
hwNmNorthboundRootAlarm
1.3.6.1.4.1.2011.2.
15.1.7.1.29
Integer
Specifies whether the alarm is root

alarm or not.
l 0: Non-root alarm
l 1: Root alarm
hwNmNorthboundGroupID
1.3.6.1.4.1.2011.2.
15.1.7.1.30
Integer
Indicates the group ID the alarm

belongs to.
hwNmNorthboundMaintainStatus
1.3.6.1.4.1.2011.2.
15.1.7.1.31
Integer
Indicates the engineering alarm

status.
3.4 Active Alarm Synchronization End Trap

Function
The M2000 sends this type of traps to inform the OSS that the alarm synchronization completes.
Trigger Condition
Active alarm synchronization end traps are triggered when:
l
All required alarms have been reported to the OSS in trap packets.
The OSS stops the synchronization.
The OSS triggers the termination of synchronization.

The OSS performs the operation hwNmNorthboundEventSynchronizationCommandStop
on the designated M2000 in the following format:
NMS IP:port
NOTE
NMS IP:port refers to the IP address and port of the OSS server.
Issue 01 (2012-04-20)

60
M2000

Definition
Name
Enterprise
Type
Description
hwNmNorthboundE
ventSynchronizationEndNotify
hwNmNorthboundE
ventSynchronizationEnd
Trap/Inform
Indicates that the

alarm
synchronization
completes.
VB List
In the following table, listed data types for interconnection using the SNMPv1 protocol. Most
of these data types are applicable to the SNMPv2c and SNMPv3 protocols. For any differences,
details will be described in brackets.
VB
OID
Data
Type
Description
hwNmNorthbound
EventSynchronizationEndStatus
1.3.6.1.4.1.2011.2.
15.1.7.7.3.1
Integer
Indicates the synchronization

result. The options are as follows:
1: normalEnd(1): Indicates that
the synchronization was
complete.
2: stopped(2): Indicates that the
OSS stopped the synchronization.
3: error(3): Indicates that
exceptions occurred during the
synchronization.
hwNmNorthbound
EventSynchronizationEndStatusDetail
1.3.6.1.4.1.2011.2.
15.1.7.7.3.2
Octet
string
Indications the details about the

synchronization result.
3.5 KeepAlive Info (Heartbeat) Trap

Description
M2000 sends the KeepAlive info (heartbeat) to the NMS/OSS regularly each period. If the NMS
receives the trap, the connection between the NMS/OSS and the M2000 works. If the NMS/OSS
does not receive the trap in this period and the heartbeat is enabled, it indicates that the NMS/
OSS disconnects with the M2000.
NOTE
The range is from 3 to 300 seconds and the default value is 60.
Issue 01 (2012-04-20)

61
M2000

Condition
The M2000 sends the keepAlive info (heartbeat) trap to the NMS/OSS regularly in the preset
period.
Trap Definition
Name
ENTERPRISE
Type
Description
hwNmNorthboundE
ventKeepAlive
hwNmNorthboundE
ventKeepAliveInfo
Trap/Inform
Notification for the

Keep Alive traps.
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.
Issue 01 (2012-04-20)
Name
OID
Data Type
Descriptio
n
hwNmNorthboundKeepAlive
1.3.6.1.4.1.2011.2.15.1.7.2.1
OCTET STRING
Notification
for the Keep
Alive traps.

62
M2000
4 Interconnection Commissioning of the Northbound Alarm

SNMP Interface
Interconnection Commissioning of the

About This Chapter

Before interconnecting the NMS with the M2000, you must conduct an interconnection
commissioning. Based on the commissioning result, determine whether the northbound SNMP
interface meets the conditions for interconnecting with the NMS.
4.1 Negotiating the Interconnection Parameters of the Northbound Alarm SNMP Interface
This section describes how to negotiate the parameters for the interconnection with the
northbound alarm SNMP interface. After the relevant settings are complete, the alarm messages
that can be obtained by the NMS are generated according to the negotiated parameters.
4.2 Commissioning the Interconnection of the Northbound Alarm SNMP Interface
This section describes how to commission the interconnection of the northbound SNMP
interface. In the interconnection commissioning, you need to check the license of the NMS and
simulate the interconnection. If you can simulate the interconnection successfully, you can infer
that the northbound SNMP interface meets the conditions for interconnecting with the NMS.
Issue 01 (2012-04-20)

63
M2000

SNMP Interface
4.1 Negotiating the Interconnection Parameters of the

This section describes how to negotiate the parameters for the interconnection with the
northbound alarm SNMP interface. After the relevant settings are complete, the alarm messages
that can be obtained by the NMS are generated according to the negotiated parameters.
The negotiated parameters include the parameters that the NMS needs to provide to the
M2000 and the parameters that the NMS needs to negotiate with the M2000. For details, see
Table 4-1.
Table 4-1 Negotiated parameters
Parameter Type
Description
Parameters provided to the

M2000 by the NMS
The M2000 can be interconnected to four NMSs at the same

time.
The following information about each NMS needs to be
provided:
l V3 security user name
l V1 or V2 community name
l V3 authentication code (authenticate but not encrypt)
l V3 encrypted password
l Trap receiving address
l Trap receiving port
l Alarm severity
l Alarm filtering categories
Parameters negotiated by the

NMS and the M2000
The NMS needs to negotiate the following parameters with

the M2000:
l SNMP Protocol
l MIB Type
l Alarm Level
l Alarm Category
l Heartbeat Period
l Alarm Report Fields
l Report Time Type
l Binding Address and Port of Trap
l Time Display Mode
l SNMP Log Information
For details about how to configure these parameters, see
1.6 Configuration File of the Northbound Alarm SNMP
Interface.
Issue 01 (2012-04-20)

64
M2000

SNMP Interface
4.2 Commissioning the Interconnection of the Northbound

Alarm SNMP Interface
This section describes how to commission the interconnection of the northbound SNMP
interface. In the interconnection commissioning, you need to check the license of the NMS and
simulate the interconnection. If you can simulate the interconnection successfully, you can infer
that the northbound SNMP interface meets the conditions for interconnecting with the NMS.
4.2.1 Checking License (Alarm SNMP Interface)

Before interconnecting the M2000 to the NMS, make sure that the NMS is licensed to use the
northbound alarm SNMP interface.
Do as follows to check that the NMS has the required license:
1.
Log in to the M2000 client.
2.
Choose License > OSS License Management > License Information. The License
Information window is displayed.
3.
Click the Resource Control Item tab. If Resource contains Alarm SNMP Interface, the
NMS is authorized to use the SNMP interface.
4.2.2 Commissioning the Interconnection of the Northbound Alarm

SNMP Interface
This section describes the procedure for commissioning the interconnection of the northbound
alarm SNMP interface. The procedure include stopping the service, modifying the configuration
file, reloading the configuration file, and starting the service. This section uses M2000 MIB as
an example.
Prerequisites
You have logged in to the M2000 server as user root or ossuser.
Context
l
IMAP_NORTHBOUND_MIB-V1.mib (for SNMPv1)
IMAP_NORTHBOUND_MIB-V2.mib (for SNMPv2c or SNMPv3)
CAUTION
In an SLS system, you need to perform the following steps only on the master server and do not
need to perform them on the slave or standby server. In an HA or remote HA system, you need
to perform the following steps only on the active server and do not need to perform them on the
standby server.
Issue 01 (2012-04-20)

65
M2000

SNMP Interface
Procedure
Step 1 Go to the M2000 installation directory.
The default installation directory is /opt/oss/server.
By default, run the following command:
# cd /opt/oss/server
Step 2 Stop the northbound alarm SNMP interface service.
# . ./svc_profile.sh
# svc_adm -cmd stopsvc SnmpAgent
Step 3 Verify that the MIB type that interconnects with the NMS is MIB2.
1.
Run the following commands to check whether the MIB type that interconnects with the
NMS is MIB2:
# . /opt/oss/server/svc_profile.sh
# cd /opt/oss/server/nbi/snmp/conf
# cat snmpagent.xml
If the command output contains <param name="SupportedMIB">MIB2</param>, go to
Step 4. Otherwise, proceed to Step 3.2 and Step 3.3 to modify the MIB type.
2.
Run the following commands to set SupportedMIB to MIB2 in the configuration file:
# . /opt/oss/server/svc_profile.sh
# cd /opt/oss/server/nbi/snmp/conf
# vi snmpagent.xml
Change <param name="SupportedMIB">MIB1</param> to <param
name="SupportedMIB">MIB2</param>.
For details, see #sec.
3.
Press Esc. Then, run the :wq command to save the modification and exit the vi editor.
Step 4 Determine the SNMP version that interconnects with the NMS. Then set the SNMP version in
the configuration file to the interconnected version.
For details, see SNMP protocol configuration in 1.6 Configuration File of the Northbound
Alarm SNMP Interface.
Step 5 Configure the NMS parameters, including the IP address, port, security user name, and criteria
for filtering alarms by severity.
If you use SNMPv3 to interconnect with the NMS, you need to use the GenerateNBPass tool to
generate the authentication password first, and then add the password to the configuration file.
If your use SNMPv1 or SNMPv2c, you do not need to change the authentication password in
the configuration file.
The security user name of each NMS must be unique. For details, see NMS information
configuration in 1.6 Configuration File of the Northbound Alarm SNMP Interface.
Step 6 Configure the heartbeat period.
Issue 01 (2012-04-20)

66
M2000

SNMP Interface
For details, see heartbeat period configuration in 1.6 Configuration File of the Northbound
Step 7 Configure the reported field in traps.
For details, see the configuration of reported fields in 1.6 Configuration File of the Northbound
Step 8 Configure the report time type.
For details, see the configuration of report time types in 1.6 Configuration File of the
Northbound Alarm SNMP Interface.
Step 9 Start the northbound alarm SNMP interface service.
# svc_adm -cmd startsvc SnmpAgent
Step 10 The NMS receives traps and heartbeat notifications using the configured IP address and port.
Step 11 The NMS triggers the leaf node iMAPNorthboundAlarmQuery of the northbound alarm SNMP
interface when the NMS needs to query active alarms.
For details about how to set this leaf node, see 1.6 Configuration File of the Northbound
Step 12 The NMS triggers the leaf node iMAPNorthboundAlarmAcknowledge of the northbound alarm
SNMP interface when the NMS needs to acknowledge active alarms.
For details about how to set this leaf node, see 1.4.1 Functions Supported by M2000 MIB.
Step 13 The NMS triggers the leaf node iMAPNorthboundAlarmUnAcknowledge of the northbound
alarm SNMP interface when the NMS needs to unacknowledge active alarms.
Step 14 The NMS triggers the leaf node iMAPNorthboundAlarmClear of the northbound alarm SNMP
interface when the NMS needs to clear active alarms.
----End
Example
1.
Go to the M2000 installation directory.

The default installation directory is /opt/oss/server.
By default, run the following command:
2.
Stop the northbound alarm SNMP interface service.

# svc_adm -cmd stopsvc SnmpAgent
3.
Enter the IP address and port for interconnecting with the NMS. Configure the version of
the SNMP protocol to be used. Retain the default values for the other parameters.
For details, see NMS information configuration in 1.6 Configuration File of the
Northbound Alarm SNMP Interface.
4.
Configure parameters by modifying the configuration file.

For details, see 1.6 Configuration File of the Northbound Alarm SNMP Interface.
5.
Issue 01 (2012-04-20)
Start the northbound alarm SNMP interface service.

67
M2000

SNMP Interface
# svc_adm -cmd startsvc SnmpAgent
Issue 01 (2012-04-20)

68
M2000
Troubleshooting the Northbound Alarm

SNMP Interface
About This Chapter

If a fault occurs when the NMS interconnects to the M2000 through the northbound SNMP
interface, you need to adopt proper measures to rectify the fault. This chapter describes the
process and methods for handling faults related to the northbound SNMP interface.
5.1 Common Troubleshooting and Information Collection (Alarm SNMP Interface)
If a fault occurs when the NMS attempts to obtain data through the northbound SNMP interface,
rectify the fault according to common troubleshooting methods. If it is not possible to rectify
the fault, collect the fault information and contact Huawei engineers for assistance.
5.2 Troubleshooting Failure to Start the Northbound Alarm SNMP Interface Service After the
M2000 Starts
This section analyzes and resolves the problem that the northbound alarm SNMP interface
service does not start after the M2000 starts.
5.3 Troubleshooting Failure to Make New Settings Take Effect After Modifying the
Configuration File
This section analyzes and solves the problem that new settings do not take effect after you modify
the configuration items of the northbound alarm SNMP interface.
5.4 Troubleshooting Inconsistency Between the Number of Fields Actually Reported and That
of Fields in the Configuration File
This section analyzes and solves the problem that the reported number of the fields are
inconsistent with that of the fields in the configuration file.
5.5 Troubleshooting an Issue in Which No SNMP Log Is Recorded in the Specified File
This section analyzes and solves the problem that no SNMP log is recorded in the specified file.
5.6 Troubleshooting an Issue in Which Users Can Pass SNMPv3 Authentication with Only Part
of the Cyclic Password
This section analyzes and solves the problem that the northbound user can pass the verification
of SNMPv3 authentication with only part of the cyclic password.
5.7 How to Set Northbound Interface Compatibility
Issue 01 (2012-04-20)

69
M2000
This section describes how to set the FDN format and OMC ID of northbound interfaces so that
the northbound interfaces are compatible with earlier versions.
5.8 How to Set Parameters in a Northbound Configuration File
This section describes how to set parameters in the configuration file of a northbound interface.
Issue 01 (2012-04-20)

70
M2000
5.1 Common Troubleshooting and Information Collection

(Alarm SNMP Interface)
If a fault occurs when the NMS attempts to obtain data through the northbound SNMP interface,
rectify the fault according to common troubleshooting methods. If it is not possible to rectify
the fault, collect the fault information and contact Huawei engineers for assistance.
Troubleshooting
For the methods of handling common faults that may occur during the process of obtaining alarm
data for the NMS, see Table 5-1.
Table 5-1 Troubleshooting
Common Fault
Troubleshooting Method
Failure to start the northbound alarm SNMP

interface after starting the M2000.
See 5.2 Troubleshooting Failure to Start

the Northbound Alarm SNMP Interface
Service After the M2000 Starts.
Failure to make new settings effective after

modifying the configuration file.
See 5.3 Troubleshooting Failure to Make

New Settings Take Effect After Modifying
the Configuration File.
Inconsistency between the number of the

fields actually reported and that of the fields
in the configuration file.
See 5.4 Troubleshooting Inconsistency

Between the Number of Fields Actually
Reported and That of Fields in the
Configuration File.
No SNMP log recorded in the specified file.
See 5.5 Troubleshooting an Issue in Which

No SNMP Log Is Recorded in the Specified
File.
Able to pass SNMPv3 authentication using

only part of the cyclic password.
See 5.6 Troubleshooting an Issue in Which

Users Can Pass SNMPv3 Authentication
with Only Part of the Cyclic Password.
How to set northbound interface

compatibility
See 5.7 How to Set Northbound Interface

Compatibility.
How to set parameters in a northbound

configuration file
See 5.8 How to Set Parameters in a

Northbound Configuration File.
Information Collection
If the fault that occurs when the NMS attempts to obtain data through the northbound SNMP
interface is not listed in Table 5-1, you need to collect the fault information to locate the fault.
For details, see Table 5-2.
Issue 01 (2012-04-20)

71
M2000
Table 5-2 Information to be collected

Related Information
Description
Operation information
The operation information records the operations performed

before a fault occurs and the troubleshooting measures taken
later.
Version information
You need to obtain the information about the M2000 version,

NE mediation version, and NE version.
IP information
You need to obtain the IP information about the M2000

server.
Log information
NOTE
In an SLS system, you need to perform the following steps only on
the master server and do not need to perform them on the slave or
standby server. In an HA or remote HA system, you need to perform
the following steps only on the active server and do not need to
perform them on the standby server.
You can obtain logs from the /opt/oss/server/var/logs/nbi/

snmp directory. The .trace file include:
l osgi.log
l SnmpAgent_YYYYMMDDHHMMSS.log
l SnmpAgent_YYYYMMDDHHMMSS.zip
l PDUTrace_YYYYMMDDHHMMSS.log
l PDUTrace_YYYYMMDDHHMMSS.zip
NOTE
The log files PDUTrace_YYYYMMDDHHMMSS.log and
PDUTrace_YYYYMMDDHHMMSS.zip will be generated only
when PDUTrace is set to 1
5.2 Troubleshooting Failure to Start the Northbound Alarm

SNMP Interface Service After the M2000 Starts
This section analyzes and resolves the problem that the northbound alarm SNMP interface
service does not start after the M2000 starts.
Description
The northbound alarm SNMP interface service does not start after the M2000 starts.
Run the following commands:
# svc_adm -cmd status | grep SnmpAgent
If the following information is displayed, the SnmpAgent service does not start:
SnmpAgent
Issue 01 (2012-04-20)
[not running

72
M2000
Possible Cause
The M2000 fault service has not started.
Solution
The northbound alarm SNMP interface service depends on the M2000 fault service. Before
starting the northbound alarm SNMP interface service, ensure that the fault service has started.
Run the command # svc_adm -cmd startsvc SnmpAgent to start the fault service and then
the northbound alarm SNMP interface service.
5.3 Troubleshooting Failure to Make New Settings Take

Effect After Modifying the Configuration File
This section analyzes and solves the problem that new settings do not take effect after you modify
the configuration items of the northbound alarm SNMP interface.
Symptom
After some configuration items are modified, the SNMP northbound interface does not function
according to the new settings.
Possible Cause
After modifying or adding parameter values by running the SettingTool command, you did not
run the command for restarting the northbound alarm SNMP interface services.
Solution
After modifying the configuration items, run the following command to restart the northbound
alarm SNMP interface services:
# svc_adm -cmd restartsvc SnmpAgent
For details about the settings of the SNMP interface configuration items, see 1.6 Configuration
File of the Northbound Alarm SNMP Interface.
5.4 Troubleshooting Inconsistency Between the Number of

Fields Actually Reported and That of Fields in the
Configuration File
This section analyzes and solves the problem that the reported number of the fields are
inconsistent with that of the fields in the configuration file.
Description
The number of VB fields in the reported alarm trap is smaller than that configured in the
configuration file, or some configured reported fields do not appear in the trap report.
Issue 01 (2012-04-20)

73
M2000
Possible Cause
The field names are wrong.
Solution
Take care to choose alarm field names that can be configured. Follow the specified case
(uppercase or lowercase) to type the field names in the report field in the configuration file.
5.5 Troubleshooting an Issue in Which No SNMP Log Is

Recorded in the Specified File
This section analyzes and solves the problem that no SNMP log is recorded in the specified file.
Description
The SNMP log file is not found in the specified folder.
Possible Cause
l
The SNMP log switch is disabled.
The specified folder is inaccessible.
Follow the SNMP log configuration to enable the log switch.
Ensure that you can access the folder where you create the log file.
Solution
5.6 Troubleshooting an Issue in Which Users Can Pass

SNMPv3 Authentication with Only Part of the Cyclic
Password
This section analyzes and solves the problem that the northbound user can pass the verification
of SNMPv3 authentication with only part of the cyclic password.
Description
Part of the northbound user password is repeated, for example, 123123123. However, if 123 is
used to access the SNMP northbound interface, the partial password can pass the SNMP
authentication.
Possible Cause
The SNMP encryption algorithm stipulates that:
If the length of a password is shorter than that stipulated by the algorithm, the system
automatically adds the password repeatedly to form a new password to meet the requirement of
the algorithm.
Issue 01 (2012-04-20)

74
M2000
Solution
l
Do not use repeated character strings in the password.
The password should be not less than eight characters.
5.7 How to Set Northbound Interface Compatibility

This section describes how to set the FDN format and OMC ID of northbound interfaces so that
the northbound interfaces are compatible with earlier versions.
Prerequisites
You have logged in to the OSMU as user ossuser.
Context
For details about northbound interface changes, see the Huawei PCN M2000-20110001
(M2000 V200R012 Northbound Interface Changes).
Procedure
Step 1 Click NBI Management on the main page of the OSMU.
Step 2 In the navigation tree of the left pane, choose Service Configuration > Northbound Interface
Compatibility Settings. The Northbound Interface Compatibility Settings tab page is
displayed.
Step 3 View the current FDN format and OMC ID settings of each northbound interface.
Step 4 Set the FDN format and OMC ID for each northbound interface based on operator requirements.
NOTE
You can reset the FDN format and OMC ID only after you have discussed with operators and the operators
have agreed such settings.
Step 5 Select The northbound interface change has been discussed with the customer. The
customer demands the above settings.
Step 6 Click OK.
The system displays a message stating that some services will restart for the settings to take
effect.
Step 7 Click Yes to confirm the settings and restart the related services. Click No to cancel the settings.
----End
Follow-up Procedure
If the system displays a message stating that the related services fail to restart, these services do
not exist or there are other services being restarted. When this occurs, log in to the M2000 server
to install or manually restart the related services.
Issue 01 (2012-04-20)

75
M2000
5.8 How to Set Parameters in a Northbound Configuration

File
This section describes how to set parameters in the configuration file of a northbound interface.
Prerequisites
You have logged in to the OSMU as user ossuser.
Context
For details about the configuration file of each northbound interface, see the related developer
guide.
The OSMU does not support the SLS system. You can use commands to modify the
configuration parameters of the slave server in an SLS system.
Procedure
Step 1 Click NBI Management on the main page of the OSMU.
Step 2 Choose Service Configuration > Set Northbound Configuration Parameters. The Set
Northbound Configuration Parameters page is displayed.
Step 3 Select a northbound interface and its configuration file. Then set new values to parameters to be
modified in the configuration file.
NOTE
You can click Reset to restore the modified parameters to their previous values.
Step 4 Click Save&Restart for the modification to take effect.

----End
Issue 01 (2012-04-20)

76
M2000
6 Appendix: Scripts of the Northbound Alarm SNMP

Interface
Appendix: Scripts of the Northbound Alarm

SNMP Interface
This section describes the scripts provided by the northbound alarm SNMP interface.
Table 6-1 describes the scripts.
Table 6-1 Description of scripts provided by the northbound alarm SNMP interface
Issue 01 (2012-04-20)
Script
File path
Function
GenerateNBPass
/opt/oss/server/nbi/snmp/
bin
Uses the AES algorithm to

encrypt passwords.
NBIPostInstall.sh
bin
Installs SNMP components.
create_snmp_table.sh
init
Installs SNMP components.

77

M2000 Northbound Alarm SNMP Interface Developer Guide

Diunggah oleh

Informasi Dokumen

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

M2000 Northbound Alarm SNMP Interface Developer Guide

Diunggah oleh

Hak Cipta:

Format Tersedia

M2000

Northbound Alarm SNMP Interface

HUAWEI TECHNOLOGIES CO., LTD.

Copyright Huawei Technologies Co., Ltd. 2012. All rights reserved.

Trademarks and Permissions

Huawei Technologies Co., Ltd.

Huawei Industrial Base

Huawei Proprietary and Confidential

About This Document

About This Document

Huawei Proprietary and Confidential

About This Document

l 1.5 Security Mechanism of

l 6 Appendix: Scripts of the

Huawei Proprietary and Confidential

About This Document

Times New Roman

Normal paragraphs are in Times New Roman.

Names of files, directories, folders, and users are in

Book titles are in italics.

Examples of information displayed on the screen are in

The keywords of a command line are in boldface.

Command arguments are in italics.

Items (keywords or arguments) in brackets [ ] are optional.

About This Document

Optional items are grouped in braces and separated by

Optional items are grouped in brackets and separated by

Optional items are grouped in braces and separated by

Optional items are grouped in brackets and separated by

Buttons, menus, parameters, tabs, window, and dialog titles

Multi-level menus are in boldface and separated by the ">"

Press the keys concurrently. For example, pressing Ctrl+Alt

Press the keys in turn. For example, pressing Alt, A means

Select and release the primary mouse button without moving

About This Document

Press the primary mouse button twice continuously and

Huawei Proprietary and Confidential

2 Trap Configuration Information of the Northbound Alarm SNMP Interface (M2000

Huawei Proprietary and Confidential

4 Interconnection Commissioning of the Northbound Alarm SNMP Interface................63

5 Troubleshooting the Northbound Alarm SNMP Interface.................................................69

6 Appendix: Scripts of the Northbound Alarm SNMP Interface..........................................77

Huawei Proprietary and Confidential

1 Introduction to Northbound Alarm SNMP Interface

Introduction to Northbound Alarm SNMP

About This Chapter

Huawei Proprietary and Confidential

1 Introduction to Northbound Alarm SNMP Interface

Huawei Proprietary and Confidential

1 Introduction to Northbound Alarm SNMP Interface

1.1 Definition of Northbound Interface

1.2 Definition of Northbound Alarm SNMP Interface

Huawei Proprietary and Confidential

1 Introduction to Northbound Alarm SNMP Interface

Figure 1-2 Network position of the northbound alarm SNMP interface

You can transmit management information between any two nodes.

The features of the SNMP are as follows:

Requires the User Datagram Protocol (UDP) only.

1.3 MIB of the Northbound Alarm SNMP Interface

Huawei Proprietary and Confidential

1 Introduction to Northbound Alarm SNMP Interface

iMAPNorthboundFault defines the alarm subinterface of the SNMP northbound interface.

NA: Not Accessible

RC: Read and Create