Avaya Aura® System Manager 7.1
SNMP Whitepaper
Issue 1.0
28th April 2017
“THE INFORMATION PROVIDED IN HEREIN IS PROVIDED “AS IS” WITHOUT ANY EXPRESS OR IMPLIED
WARRANTY. This document is intended to provide general information, and is not made part of any
agreement you may have with Avaya related to your purchasing and/or licensing of Avaya products or
services and related warranty, maintenance and support.”
© 2017 Avaya Inc. All rights reserved.
Table of Contents
1.
INTRODUCTION .............................................................................................................................. 3
2.
SYSTEM MANAGER SNMP AGENT ................................................................................................... 3
3. MANAGING SNMPV3 USER PROFILES AND SNMP TARGET PROFILES ................................................... 5
3.2
CUSTOMIZING SNMPV3 USERS ............................................................................................................... 6
3.3
CUSTOMIZING TARGET PROFILES .............................................................................................................. 8
3.4
SYSTEM MANAGER TARGET PROFILE .................................................................................................... 9
3.5
ASSIGNING/ATTACHING SNMPV3 USER PROFILES AND SNMP TARGET PROFILES TO SERVICEABILITY AGENTS ..... 10
4.
ALARM THROTTLING ..................................................................................................................... 13
5.
SUPPORTED MIB GROUPS ............................................................................................................. 19
6. ALARM FILTERING (NOTIFICATION FILTERING) .................................................................................. 20
7. SYSTEM MANAGER COMMON ALARM DEFINITION FINE AND EVENT CODES .................................... 24
8.
APPENDIX A ................................................................................................................................. 26
9.
APPENDIX B ................................................................................................................................. 30
© 2017 Avaya Inc. All rights reserved.
2
System Manager 7.1 SNMP White Paper
1.
INTRODUCTION
System Manager provides an Operating System (OS) level Simple Network Management Protocol (SNMP)
Master agent (Net-SNMP) for basic Internet Protocol (IP) discovery, OS platform monitoring, notification
sending and notification destination & SNMPv3 user management. SNMP notification is provided by
System Manager using standard SNMP notifications (v2c and v3) using unique notification OIDs.
System Manager provides the Serviceability Agent which monitors faults on the system and sends
SNMPv2c/SNMPv3 notifications (traps/informs) to configured destinations via the Net-SNMP master
agent. One of the configurable destinations is a SAL Gateway which forwards these traps as alarms to the
Avaya Data Center. For the System Manager alarming to work a SNMP target destination for System
Manager itself is created and pre-configured on its serviceability agent.
• For Release 6.1 elements with 6.1 SAL agent, and Release 6.2 elements with 6.2 serviceability agent,
System Manager cannot forward traps to NMS. You can configure 6.1 elements with 6.1 SAL agent and 6.2
elements with 6.2 serviceability agents to send SNMP traps directly to a customer Network Management
System (NMS). However, for Release 6.2 elements, you can configure from System Manager instead of
configuring in each element.
System Manager MIBs are listed in appendix.
2.
SYSTEM MANAGER SNMP AGENT
System Manager by default does not support SNMPv1 & SNMPv2 requests for GET/SET operations from
external NMS. However System Manager can receive and process SNMP v1, v2c and v3 notifications from
different elements. The SNMP master agent (Net-SNMP) comes pre-configured with seven snmpv3 users
(for each combination of authentication and privacy protocol). These SNMPv3 users however get
overwritten with new usernames and credentials, when the user-prefix and authentication & privacy
protocol passwords are defined by the admin during System Manager Deployment as shown in the
screenshot below:
© 2017 Avaya Inc. All rights reserved.
3
For example: If in the above screen we provide “snmpadmin” as User Name prefix, “admin123” as
Authentication Protocol Password and Privacy Protocol Password then the set of SNMPv3 users will be
created as per the following table and replace the old preconfigured set of SNMPv3 users. These SNMP
users are essential for further SNMP based operations and should not be deleted by any means:
Authentication
Protocol
Authentication
Password
Privacy
Protocol
Privacy
Password
SNMPv3
Username
Permissions
MD5
admin123
AES
admin123
snmpadmin
_md5_aes
read-write
SHA
admin123
AES
admin123
snmpadmin
_sha_aes
read-write
MD5
admin123
DES
admin123
snmpadmin
_md5_des
read-write
SHA
admin123
DES
admin123
snmpadmin
_sha_des
read-write
MD5
admin123
None
NA
snmpadmin
_md5_none
read-write
SHA
admin123
None
NA
snmpadmin
read-write
© 2017 Avaya Inc. All rights reserved.
4
_sha_none
The SNMP Agent will always be started by default.
The System Manager Console provides a user interface for “Activation” of Serviceability Agents,
establishment of SNMPv3 User Profiles and management and establishment of SNMP target profiles and
their management. The SNMPv3 user profiles ,target profiles and Filter Profiles are assigned to the SMGR
and managed element’s(for e.g. Session Manager) serviceability agents via usage of SNMPv3 “SET”
operations on the following standard MIBs supported by the Net-SNMP master agent:




USM MIB(RFC 3414)
VACM MIB(RFC 3415)
Target MIB(RFC 3413)
Notification MIB (RFC 3413).
3. Managing SNMPv3 User Profiles and SNMP Target Profiles
The System Manager console allows administrators to manage SNMPv3 users profiles and SNMP target
profiles at the serviceability agents.
3.1
Activate the Serviceability agents
The Serviceability Agents page lists all the serviceability agents (of the elements and System Manager
itself) which has R6.2 or above Serviceability Agents and registers with the System Manager.
Activation is a mandatory step required to manage SNMPv3 users and Notification destinations in the
serviceability agent(s). In this step the pre-configured SNMPv3 users are deleted and new SNMPv3 users
(newly entered during System Manager Deployment) are created in the serviceability agent.
Note: With SMGR 6.3 Release FP4 and onwards, the auto-activation feature is introduced where the
Serviceability Agents (which are also on 6.3 FP4 and above) are auto activated, as soon as they are added
in System Manager in Serviceability Agent Page.
Manual activation is applicable for older serviceability agents.
a) From the SMGR dashboard select HOME tab and select Inventory from Services.
© 2017 Avaya Inc. All rights reserved.
5
b) Choose Manage Serviceability Agents > Serviceability Agents.
c) The Serviceability Agents page shows the agent list and all of their “status” will be inactive at the
beginning.
Select any serviceability agent and the “Activate” button will be enabled. Click on that and that will
activate the agent and make it manageable.
3.2
CUSTOMIZING SNMPV3 USERS
Select the Manage Serviceability Agent > SNMPv3 User Profiles. The SNMPV3 User Profiles page is to list,
view create, edit and delete SNMPv3 users. Click on “New” button to create a new SNMPv3 user.
© 2017 Avaya Inc. All rights reserved.
6
Fill in the details from the “New User Profile” page and click on “Commit”, that user profile will be
created. If the SNMP user profile is to be used for SNMPv3 Target profiles only then the “Privilege (as
shown in the screenshot below)” should be “None”. If the SNMPv3 User profile is for the purpose of GET
or GET and SET operation from NMS then the privileges should be “Read” or “Read/Write” respectively.
To edit a SNMPv3 user select the user and click on “Edit” button. From the “Edit User Profile” page change
the SNMPv3 User profile and click on “Commit” button.
© 2017 Avaya Inc. All rights reserved.
7
Similarly one can list and delete SNMPv3 users from this “SNMPv3 User Profiles” page. One cannot “Edit”
and “Delete” the SNMPv3 user profile if it is already assigned to any target profile or serviceability agent.
Before editing or deleting SNMPv3 User Profile, the users must be detached from the agents and the
target profiles.
3.3
CUSTOMIZING TARGET PROFILES
Select the Manage Serviceability Agents > SNMP Target Profiles. The “SNMP Target Profiles” page lets us
create, view, edit and delete SNMP v2/v3 target profiles. Click on “New” button from the “SNMP Target
Profiles” page to create a new SNMP target profile.
Provide the target details, and assign a user profile from the “Attach/Detach User Profile” only if this is a
v3 target profile.
If the chosen protocol is “V3” then assign the SNMPV3 user to the v3 target profile and click on “Commit”
button. The SNMP v3 target profile will be created.
© 2017 Avaya Inc. All rights reserved.
8
Similarly a v2 target profile can be created, only the protocol should be “V2” in the “New Target Profile”
page and no SNMPv3 User has to be assigned from the “Attach/Detach User Profile” tab.
To edit a target profile, select the target profile from the “SNMP Target Profiles” page and click on the
“Edit” button. From the “Edit Target Profile” page make the changes to the target profile and click on
“Commit” button.
Similarly the target profile can be viewed and deleted by clicking on the “View” and the “Delete” button
from their respective pages. One cannot “Edit” and “Delete” the target profile if it is already assigned to
any serviceability agent, for editing or deleting the target profile it must be detached from the agents first.
3.4
SYSTEM MANAGER TARGET PROFILE
For System Manager there is a traplistener configuration which lists what the System Manager details are
for authentication protocol, privacy protocol, their passwords, SNMPV3 user, v2 community string and the
port. Internally the System Manager target profile is already created and assigned to its own serviceability
agent. If anything is changed in the traplistener configuration then a new SMGR target profile has to be
© 2017 Avaya Inc. All rights reserved.
9
created and assigned to the SMGR’s serviceability agent and other element’s serviceability agents which
want to send notifications to SMGR.
The traplistener profile can be viewed/changed from the Configuration > Settings > SMGR > Traplistener
link. One should “take caution in modifying this parameter”.
3.5
ASSIGNING/ATTACHING SNMPV3 USER PROFILES AND SNMP TARGET PROFILES TO SERVICEABILITY AGENTS
Customers can add their NMS as a trap destination by performing the following steps:
1.
2.
3.
Create SNMv3 User profile(s) following steps as in 3.2 Customizing SNMPv3 users. If the SNMPv3
User profile is for the purpose of GET or GET and SET operation from NMS then the privileges
should be “Read” or “Read/Write” respectively.
Create new SNMPv3 or SNMPv2 Target profile(s) following steps as in 3.3 Customizing Target
Profiles.
Assign the target profile(s) to the elements’ serviceability agent(s) as mentioned below:
Select “activated” agent(s), the “Manage Profiles” button will be enabled. Click on “Manage Profiles”
button.
The “Manage Profile” page has three tabs, “Selected Agents” shows the list of selected agents.
© 2017 Avaya Inc. All rights reserved.
10
In the “Snmp Target Profiles” we can select “Assignable Profiles” and “Assign” them to the selected
serviceability agent(s). We also can select “Removable profiles” and “Remove” them from the selected
serviceability agent(s).
From the “SNMPV3 User Profiles” tab we can assign SNMPv3 user profiles. If we click on “Commit” the
User Profiles and the Target Profiles will be assigned to that Serviceability Agent(s We also can select
“Removable profiles” and “Remove” them from the selected serviceability agent(s).
© 2017 Avaya Inc. All rights reserved.
11
3.6
GENERATING TEST ALARM FROM UI
There is feature available on Serviceability Agent UI that allows generating test alarm for the selected
Serviceability Agent. (Applicable for Serviceability Agents which have their tests alarm scripts
implemented)
The Serviceability Agent has to be added and activated as explained in 3.2/3.3/3.4 and 3.5 sections.
Once activated, we can generate the test alarm for it by Clicking on the “Generate Test Alarm” button on
the Serviceability Agent page., next to ‘Activate’ button.
After clicking the Generate Test Alarm Button, the notification would appear at the top.
The generated test alarm can be viewed on the Services/Events/Alarms page
© 2017 Avaya Inc. All rights reserved.
12
4.
Alarm Throttling
Alarm throttling (Manage interval of log/alarm generation) is nothing but a mechanism to reduce the
frequency of alarm being sent for the same events in specified interval of time. It is different from alarm
filtering in the sense where filtered alarms are not sent to the specified destination at all. Filtering can be
decided based on severity, priority and category.
Areas where throttling mechanism can be implemented:
1.
2.
At source
 Throttling of log generations at application level
o This mechanism can be leveraged to control flooding for only few specific
events/logs where we don’t need to check other dynamically populated stuff (via
varbinds values).
o For example if there is an event/log because a service is down, then every direct or
indirect invocation of that service will result into same alarm. Also, if we schedule a
job that runs every minutes and failing because of some common reason, then
there should be some interval in raising this event.
 Throttling of alarm generation at Serviceability Agent level
o Leverage Alarm MIB data in controlling the generation of alarms at serviceability
Agent.
At Destinations:
o At different destinations (e.g. ADC, SMGR) we can leverage (Source IP + Notification
OID + Log event time) varbinds for throttling alarms being received in very quick
succession.
Description:
Alarm flooding is an issue in all products where alarm is raised based on log events. To stop alarm flooding
the “alarm throttling” mechanism is introduced. The Current document explains the implementation of
Alarm throttling at Source Level (Serviceability Agent side).
Alarm MIB (implemented in SA) maintains the list of most recent raised alarms. The idea of Alarm
throttling is based on the time interval calculation between two alarms as fetched from the Alarm MIB
subagent. A throttle period (in minutes) can be configured either as a generic throttle period for all alarms
generated or specific to individual notifications at Serviceability Agent. This will cause redundant alarms
within the configured time period to be eliminated at the source itself via Serviceability Agent.
By default it is configured for 720 minutes (12 hrs).
Configuration:
© 2017 Avaya Inc. All rights reserved.
13
A user can configure the generic alarm throttle time interval in a properties file placed under:
“$SPIRIT_HOME/config/agent/AlarmThrottle.properties” and provide an entry like
"AlarmThrottlePeriod=2" inside the file, this is the throttle time period in minutes, and will be applied to
all outgoing alarms.
If user wants to configure for a specific event then, we need to add an <tns:ExtraAttribute> tag to
EP_Base_Rules.xml files which contain the events.
For Example:
Before:
<tns:Rule id="PANBR00">
<tns:RuleDescription>Generates test alarm TEST_ALARM_CLR_0000</tns:RuleDescription>
<tns:State>active</tns:State>
<tns:FilterSpec>event.SourceType == "LOG" and regex.matches(log.EventID,
"TEST_ALARM_GEN_0001")</tns:FilterSpec>
<tns:ActionList>
<tns:Action xsi:type="tns:ForwardType" id="PANBR00b">
<tns:State>active</tns:State>
<tns:Synchronicity>synchronous</tns:Synchronicity>
<tns:MessagingAddress>topic:EventProcessorNMS@localhost</tns:MessagingAddress>
<tns:IncludeNormalisedEvent>1</tns:IncludeNormalisedEvent>
<tns:ExtraInformation>
<tns:ExtraAttribute>
<tns:ExtraAttributeName>notificationOid</tns:ExtraAttributeName>
<tns:ExtraAttributeValue>.1.3.6.1.4.1.6889.2.35.0.1</tns:ExtraAttributeValue>
</tns:ExtraAttribute>
</tns:ExtraInformation>
</tns:Action>
</tns:ActionList>
</tns:Rule>
After :
<tns:Rule id="PANBR00">
<tns:RuleDescription>Generates test alarm TEST_ALARM_CLR_0000</tns:RuleDescription>
<tns:State>active</tns:State>
<tns:FilterSpec>event.SourceType == "LOG" and regex.matches(log.EventID,
"TEST_ALARM_GEN_0001")</tns:FilterSpec>
<tns:ActionList>
<tns:Action xsi:type="tns:ForwardType" id="PANBR00b">
<tns:State>active</tns:State>
<tns:Synchronicity>synchronous</tns:Synchronicity>
<tns:MessagingAddress>topic:EventProcessorNMS@localhost</tns:MessagingAddress>
<tns:IncludeNormalisedEvent>1</tns:IncludeNormalisedEvent>
<tns:ExtraInformation>
<tns:ExtraAttribute>
<tns:ExtraAttributeName>notificationOid</tns:ExtraAttributeName>
<tns:ExtraAttributeValue>.1.3.6.1.4.1.6889.2.35.0.1</tns:ExtraAttributeValue>
</tns:ExtraAttribute>
<tns:ExtraAttribute>
<tns:ExtraAttributeName>alarmThrottleInterval</tns:ExtraAttributeName>
© 2017 Avaya Inc. All rights reserved.
14
<tns:ExtraAttributeValue>2</tns:ExtraAttributeValue>
</tns:ExtraAttribute>
</tns:ExtraInformation>
</tns:Action>
</tns:ActionList>
</tns:Rule>
Here the above alarmThrottleInterval will be applied as the Alarm throttle time period for the specific
event (1.3.6.1.4.1.6889.2.35.0.1). This will override the generic alarm throttling period which is set in
AlarmThrottle.properties file as mentioned above.
Notes:







By default only generic alarm throttling is enabled, for 720 minutes (12 hrs). If a user
reconfigures the time period, it is required to restart Serviceability Agent.
As a thumb rule:
o Test Alarms shouldn’t be throttled. (This is true for SMGR Test alarms, for adopters we
need to configure in respective EP_BASERULES.XML for the product. See Details below)
o Similarly security related alarms shouldn’t be throttled. For example, sometimes we
generate alarms for unauthorized access.
If an alarm is raised again at SAL Agent it will get throttled at the Serviceability Agent itself until
either the throttle period has expired i.e. 12 hours or if there is a Clear alarm generated for the
previously raised alarm.
To disable the Alarm Throttling entirely in the Serviceability Agent, a user needs to set the
AlarmThrottlePeriod=-1, in the $SPIRIT_HOME/config/agent/AlarmThrottle.properties, and
restart spiritAgent.
Clear alarms will always have alarm throttling for consecutive clear alarms.
Alarm Throttling is a functionality which is based at SAL Agent and therefore will be applied to all
outgoing alarms irrespective whether forwarding to SMGR or any external NMS.
No one should confuse between alarm throttling and filtering.
How To:
1) To configure a specific alarm with a custom Alarm Throttle period. Or to disable alarm throttling
for a specific Notification. This can be used for security alarms which are never wanted to be
throttled.
Edit EP_Base_Rules.xml files which contain the events for the specific product. And provide the
alarm throttle period as shown below: For Example : If we want to set alarm throttle period for a
OP_MMTC20011
Postgres
Sanity
Alarm,
then
we
will
edit
file
:
$SPIRIT_HOME/config/agent/ SCRUSH_1.0_0_EPBaseRules_orig.xml
Before :
<tns:Rule id="AAAAA4">
<tns:RuleDescription>Forward LOG Events that matches OP_MMTC20011 Postgres
Sanity Alarm</tns:RuleDescription>
<tns:State>active</tns:State>
<tns:FilterSpec>event.SourceType
==
"LOG"
and
regex.matches(log.EventID,
"OP_MMTC20011")</tns:FilterSpec>
<tns:ActionList>
<tns:Action xsi:type="tns:ForwardType" id="AAAA4a">
<tns:State>inactive</tns:State>
<tns:Synchronicity>synchronous</tns:Synchronicity>
© 2017 Avaya Inc. All rights reserved.
15
<tns:MessagingAddress>topic:EventProcessorLogAlarm@localhost</tns:MessagingAddr
ess>
<tns:IncludeNormalisedEvent>1</tns:IncludeNormalisedEvent>
<tns:ExtraInformation>
<tns:ExtraAttribute>
<tns:ExtraAttributeName>DerivedPriority</tns:ExtraAttributeName>
<tns:ExtraAttributeValue>300</tns:ExtraAttributeValue>
</tns:ExtraAttribute>
</tns:ExtraInformation>
</tns:Action>
<tns:Action xsi:type="tns:ForwardType" id="AAAA4b">
<tns:State>active</tns:State>
<tns:Synchronicity>synchronous</tns:Synchronicity>
<tns:MessagingAddress>topic:EventProcessorNMS@localhost</tns:MessagingAddress>
<tns:IncludeNormalisedEvent>1</tns:IncludeNormalisedEvent>
<tns:ExtraInformation>
<tns:ExtraAttribute>
<tns:ExtraAttributeName>notificationOid</tns:ExtraAttributeName>
<tns:ExtraAttributeValue>.1.3.6.1.4.1.6889.2.36.0.221</tns:ExtraAttributeValue>
</tns:ExtraAttribute>
</tns:ExtraInformation>
</tns:Action>
<tns:Action xsi:type="tns:ContinueType" id="AAAA4c">
<tns:State>active</tns:State>
<tns:Synchronicity>synchronous</tns:Synchronicity>
</tns:Action>
</tns:ActionList>
</tns:Rule>
After :
<tns:Rule id="AAAAA4">
<tns:RuleDescription>Forward LOG Events that matches OP_MMTC20011 Postgres
Sanity Alarm</tns:RuleDescription>
<tns:State>active</tns:State>
<tns:FilterSpec>event.SourceType == "LOG" and regex.matches(log.EventID,
"OP_MMTC20011")</tns:FilterSpec>
<tns:ActionList>
<tns:Action xsi:type="tns:ForwardType" id="AAAA4a">
<tns:State>inactive</tns:State>
<tns:Synchronicity>synchronous</tns:Synchronicity>
<tns:MessagingAddress>topic:EventProcessorLogAlarm@localhost</tns:MessagingAddr
ess>
<tns:IncludeNormalisedEvent>1</tns:IncludeNormalisedEvent>
<tns:ExtraInformation>
<tns:ExtraAttribute>
<tns:ExtraAttributeName>DerivedPriority</tns:ExtraAttributeName>
<tns:ExtraAttributeValue>300</tns:ExtraAttributeValue>
</tns:ExtraAttribute>
</tns:ExtraInformation>
</tns:Action>
<tns:Action xsi:type="tns:ForwardType" id="AAAA4b">
<tns:State>active</tns:State>
<tns:Synchronicity>synchronous</tns:Synchronicity>
<tns:MessagingAddress>topic:EventProcessorNMS@localhost</tns:MessagingAddress>
<tns:IncludeNormalisedEvent>1</tns:IncludeNormalisedEvent>
<tns:ExtraInformation>
<tns:ExtraAttribute>
<tns:ExtraAttributeName>notificationOid</tns:ExtraAttributeName>
© 2017 Avaya Inc. All rights reserved.
16
<tns:ExtraAttributeValue>.1.3.6.1.4.1.6889.2.36.0.221</tns:ExtraAttributeValue>
</tns:ExtraAttribute>
<tns:ExtraAttribute>
<tns:ExtraAttributeName>alarmThrottleInterval</tns:ExtraAttributeName>
<tns:ExtraAttributeValue>XXX</tns:ExtraAttributeValue>
</tns:ExtraAttribute>
</tns:ExtraInformation>
</tns:Action>
<tns:Action xsi:type="tns:ContinueType" id="AAAA4c">
<tns:State>active</tns:State>
<tns:Synchronicity>synchronous</tns:Synchronicity>
</tns:Action>
</tns:ActionList>
</tns:Rule>
Now the above XXX value should be an integer, -1 is to completely disable alarm throttling on this event,
and we can provide a positive integer for a specific period in minutes.
In R6.3.2 and above, Serviceability Agent already has delivered the following enhancement:
Alarm throttling is enhanced to check the varbinds (instance level) .I.e same event may occur for different
nodes then SA will handle this scenario by considering the alarms on varbind values as well.
In R6.3.2 and above , Serviceability Agent has delivered the following feature:
There may be cases in which throttling should not consider varbinds values. We can configure whether
alarms will be throttled as per object (only OID) or instance level (check varbinds as well). This can be
controlled as shown below:
How To:
To configure a specific alarm, whether to throttle as per varbinds values or only OID value.
Edit $SPIRIT_HOME/config/agent/$PRODUCT$_1.0_0_EPBaseRules_orig.xml files which contain
the events for the specific product. And provide the tag ignoreVarbindForAlarmThrottling as
shown below: For Example: If we want to set that Alarm throttling should only consider
notification OID for OP_MMTC20011 Postgres Sanity Alarm, then we will edit file:
$SPIRIT_HOME/config/agent/ SCRUSH_1.0_0_EPBaseRules_orig.xml
Before :
<tns:Rule id="AAAAA4">
<tns:RuleDescription>Forward LOG Events that matches OP_MMTC20011 Postgres
Sanity Alarm</tns:RuleDescription>
<tns:State>active</tns:State>
<tns:FilterSpec>event.SourceType
==
"LOG"
and
regex.matches(log.EventID,
"OP_MMTC20011")</tns:FilterSpec>
<tns:ActionList>
<tns:Action xsi:type="tns:ForwardType" id="AAAA4a">
<tns:State>inactive</tns:State>
<tns:Synchronicity>synchronous</tns:Synchronicity>
<tns:MessagingAddress>topic:EventProcessorLogAlarm@localhost</tns:MessagingAddr
ess>
<tns:IncludeNormalisedEvent>1</tns:IncludeNormalisedEvent>
<tns:ExtraInformation>
<tns:ExtraAttribute>
<tns:ExtraAttributeName>DerivedPriority</tns:ExtraAttributeName>
<tns:ExtraAttributeValue>300</tns:ExtraAttributeValue>
© 2017 Avaya Inc. All rights reserved.
17
</tns:ExtraAttribute>
</tns:ExtraInformation>
</tns:Action>
<tns:Action xsi:type="tns:ForwardType" id="AAAA4b">
<tns:State>active</tns:State>
<tns:Synchronicity>synchronous</tns:Synchronicity>
<tns:MessagingAddress>topic:EventProcessorNMS@localhost</tns:MessagingAddress>
<tns:IncludeNormalisedEvent>1</tns:IncludeNormalisedEvent>
<tns:ExtraInformation>
<tns:ExtraAttribute>
<tns:ExtraAttributeName>notificationOid</tns:ExtraAttributeName>
<tns:ExtraAttributeValue>.1.3.6.1.4.1.6889.2.36.0.221</tns:ExtraAttributeValue>
</tns:ExtraAttribute>
</tns:ExtraInformation>
</tns:Action>
<tns:Action xsi:type="tns:ContinueType" id="AAAA4c">
<tns:State>active</tns:State>
<tns:Synchronicity>synchronous</tns:Synchronicity>
</tns:Action>
</tns:ActionList>
</tns:Rule>
After :
<tns:Rule id="AAAAA4">
<tns:RuleDescription>Forward LOG Events that matches OP_MMTC20011 Postgres
Sanity Alarm</tns:RuleDescription>
<tns:State>active</tns:State>
<tns:FilterSpec>event.SourceType == "LOG" and regex.matches(log.EventID,
"OP_MMTC20011")</tns:FilterSpec>
<tns:ActionList>
<tns:Action xsi:type="tns:ForwardType" id="AAAA4a">
<tns:State>inactive</tns:State>
<tns:Synchronicity>synchronous</tns:Synchronicity>
<tns:MessagingAddress>topic:EventProcessorLogAlarm@localhost</tns:MessagingAddr
ess>
<tns:IncludeNormalisedEvent>1</tns:IncludeNormalisedEvent>
<tns:ExtraInformation>
<tns:ExtraAttribute>
<tns:ExtraAttributeName>DerivedPriority</tns:ExtraAttributeName>
<tns:ExtraAttributeValue>300</tns:ExtraAttributeValue>
</tns:ExtraAttribute>
</tns:ExtraInformation>
</tns:Action>
<tns:Action xsi:type="tns:ForwardType" id="AAAA4b">
<tns:State>active</tns:State>
<tns:Synchronicity>synchronous</tns:Synchronicity>
<tns:MessagingAddress>topic:EventProcessorNMS@localhost</tns:MessagingAddress>
<tns:IncludeNormalisedEvent>1</tns:IncludeNormalisedEvent>
<tns:ExtraInformation>
<tns:ExtraAttribute>
<tns:ExtraAttributeName>notificationOid</tns:ExtraAttributeName>
<tns:ExtraAttributeValue>.1.3.6.1.4.1.6889.2.36.0.221</tns:ExtraAttributeValue>
</tns:ExtraAttribute>
<tns:ExtraAttribute>
<tns:ExtraAttributeName>alarmThrottleInterval</tns:ExtraAttributeName>
<tns:ExtraAttributeValue>2</tns:ExtraAttributeValue>
</tns:ExtraAttribute>
<tns:ExtraAttribute>
© 2017 Avaya Inc. All rights reserved.
18
<tns:ExtraAttributeName>ignoreVarbindForAlarmThrottling</tns:ExtraAttributeNa
me>
<tns:ExtraAttributeValue>XXX</tns: ExtraAttributeValue>
</tns:ExtraAttribute>
</tns:ExtraInformation>
</tns:Action>
<tns:Action xsi:type="tns:ContinueType" id="AAAA4c">
<tns:State>active</tns:State>
<tns:Synchronicity>synchronous</tns: Synchronicity>
</tns:Action>
</tns:ActionList>
</tns:Rule>
Now the above XXX value should be a Boolean value (true or false), value “true” denotes varbinds
should be ignored during throttling. Value “false” indicates varbinds if present should be considered.
By default the value is “false” i.e., if the tag is not provided for any notification, means varbinds shall
be considered during alarm throttling.
5.
Supported MIB Groups
The System Manager SNMP agent provides basic IP discovery and platform monitoring capabilities. It
supports the following industry standard MIBs:

SNMPv2-MIB

IFC-MIB

TCP-MIB

UDP-MIB

HOST-RESOURCES-MIB, with the exception of the HOST-RESOURCES-MIB::hrSWRun and HOSTRESOURCES-MIB::hrSWInstalled MIB groups

SNMP-MPD-MIB

SNMP-FRAMEWORK-MIB

SNMP-TARGET-MIB

SNMP-NOTIFICATION-MIB

SNMP-USER-BASED-SM-MIB

SNMP-VIEW-BASED-ACM-MIB

IP-MIB (By default ipAdressTable and ipNetToPhysicalTable are disabled in this MIB, However if
someone restarts snmpd with “ALL” option (service snmpd restart ALL) , that’ll initialize all the
MIB)

IPV6-MIB

IPV6-TCP-MIB

IPV6-UDP-MIB

RMON-MIB

EtherLike-MIB

IP-FORWARD-MIB

DISMAN-EVENT-MIB
© 2017 Avaya Inc. All rights reserved.
19

DISMAN-SCHEDULE-MIB

SNMP-USM-DH-OBJECTS-MIB

SCTP-MIB
6. Alarm Filtering (Notification Filtering)
It allows user to filter the notifications they want to receive on the Target NMS systems.
The new link is available on Inventory->Manage Serviceability Agents ->Notification Filter Profile
Create Filter Profile:- Click on “New “ button and give the filter profile name and type of filter profile we
want to create (include or exclude)
Now click on the Attach/Detach Notification OIds Tab,
© 2017 Avaya Inc. All rights reserved.
20
On selecting any product, the corresponding OIDS would be displayed in the table below:We can select the OIDS which we want to receive (filter out from all).
NOTE:- We can specify the entire subtree if we want to include all the OIDs belonging to it at once. The
section for providing OIDS subtree is shown in below image.
© 2017 Avaya Inc. All rights reserved.
21
Please note that the OID subtree should end with a .*
Now click on “Commit”
The filter profile is created.
Exclude Profile:The oids selected in this type of profile would be filtered and “not” sent to the NMS where the filter
profile is pushed.
Pushing Filter Profile to the Targets and Serviceability Agents:1) Go to serviceability Agent list
2) Select the Agent for which we want to filter the alarms and whose filter profile we have created
(select the product whose filter profile we have created e.g., SM).
© 2017 Avaya Inc. All rights reserved.
22
1) Go to “Manage Profile” button, select the second tab, Snmp Target Profile, select the target
(NMS) on which we want to receive the filtered alarms, push it to the agent.
2) Now check in the Removable Profiles section, select the target profile, and click on
“Assign/Remove Filter Profile button.
3) This will open the list of filter profile table to assign to the target profile for this agent.
Click the “+” button to assign the filter profile to target profile assigned to the agent.
Note: WE cannot assign more than 1 filter profile to the target profile per agent , i.e., per agent , per
target profile , only 1 filter profile can be pushed .
© 2017 Avaya Inc. All rights reserved.
23
1) Click on done button.
2) The filter profile pushed to the target agent is visible at the right side of the removable profiles
section.
Click on commit.
3) Now the filter profile is pushed on the agent target.
7. System Manager Common Alarm Definition Fine and Event Codes
System Manager’s common alarm definition file is attached below ( Latest for 7.1 Release)
SMGR-CommonAlarmDef-Data.xml
A list of System Manager Event Codes is presented in the attached sheet.
EventCodes71.xlsx
© 2017 Avaya Inc. All rights reserved.
24
System Manager provides a configuration file for easy integration with HPOV (tested on HP Open View
NNMGR Version 7.0.1) and IBM Tivoli. The Data from the attached configuration file can be merged into
“trapd.conf”.(Sample file )
© 2017 Avaya Inc. All rights reserved.
25
8.
Appendix A
Supported MIBS
The MIBs supported by the System Manager SNMP agents are shown in the table below. The MIB files
themselves are included here for convenience. The Avaya specific MIB are listed in the RFC column. The
MIB file can be viewed using WordPad.
MIB
RFC
MIB ASN1 File
Notes
(1) MIB-II
RFC3418
MIB-II
(2) SNMP-IF-MIB
RFC1229
SNMP Interface Support
(3) SNMP-TCPMIB
RFC4022
Module to support TCP
implementations
(4) SNMP-UDPMIB
RFC4113
Module to support UDP
implementations
(5) HOSTRESOURCES
RFC2790
IETF Host Resources MIB
(6) INADS-ALARM
N/A
INADS alarm trap definition
for SNMP traps forwarded
from System Manager server.
Avaya
Specific
(7) AVAYAGENERAL
(8) SYSTEMMANAGER
(9)
SERVICEABILITY
AGENT
N/A
Contains the Avaya root MIB
tree definition – required by
INADS-ALARM MIB.
Avaya
Specific
N/A
Avaya
Specific
N/A
Avaya
Specific
AV-AURA-SYSTEM-MANAGER-MIB_71.my
System Manager application
enterprise specific MIB
This MIB module is used by
Serviceability Agent for
AV-AURA-SERVICEABILITY-AGENT-MIB.my sending optional varbinds for
the completeness of trap
message.
© 2017 Avaya Inc. All rights reserved.
26
MIB
RFC
MIB ASN1 File
Notes
(10) SNMP-MPDMIB
RFC 3412
The MIB for Message
Processing and Dispatching
(11) SNMPFRAMEWORK-MIB
RFC 3411
The SNMP Management
Architecture MIB
(12) SNMPTARGET-MIB
RFC 3413
This MIB module defines MIB
objects which provide
mechanisms to remotely
configure the parameters
used by an SNMP entity for
the generation of SNMP
messages.
(13) SNMPNOTIFICATIONMIB
RFC 3413
This MIB module defines MIB
objects which provide
mechanisms to remotely
configure the parameters
used by an SNMP entity for
the generation of
notifications.
(14) SNMP-USERBASED-SM-MIB
RFC 3414
The management
information definitions for
the SNMP User-based
Security Model.
(15) SNMP-VIEWBASED-ACM-MIB
RFC 3415
The management
information definitions for
the View-based Access
Control Model for SNMP.
(16) IP-MIB
RFC 4293
The MIB module for
managing IP and ICMP
implementations, but
excluding their management
of IP routes.
(17) IPV6-MIB
RFC 2465
The MIB module for entities
implementing the IPv6
protocol.
(18) IPV6-TCP-MIB
RFC 2452
The MIB module for entities
implementing TCP over IPv6.
© 2017 Avaya Inc. All rights reserved.
27
MIB
RFC
MIB ASN1 File
Notes
(19) IPV6-UDPMIB
RFC 2454
The MIB module for entities
implementing UDP over IPv6.
(20) RMON-MIB
RFC 2819
Remote network monitoring
devices, often called
monitors or probes, are
instruments that exist for the
purpose of managing a
network. This MIB defines
objects for managing remote
network monitoring devices.
(21)
MIB
EtherLike-
RFC 3635
The MIB module to describe
generic objects for ethernetlike network interfaces.
(22) IP-FORWARDMIB
RFC 4292
The MIB module for the
management of CIDR
multipath IP Routes.
(23)DISMANEVENT-MIB
RFC 2981
The MIB module for defining
event triggers and actions for
network management
purposes.
(24)DISMANSCHEDULE-MIB
RFC 3231
This MIB module defines a
MIB which provides
mechanisms to schedule
SNMP set operations
periodically or at specific
points in time.
(25)SNMP-USMDH-OBJECTS-MIB
RFC 2786
The management
information definitions for
providing forward secrecy for
key changes for the
usmUserTable, and for
providing a method for
'kickstarting' access to the
agent via a Diffie-Helman key
agreement.
(26) SCTP-MIB
RFC 3873
The MIB module for
managing SCTP
implementations.
© 2017 Avaya Inc. All rights reserved.
28
MIB
RFC
(27)
AV-AURASYSTEMMANAGER-CMMEM-MIB
N/A
(28)
AV-AURASYSTEMMANAGER-SWMGMT-MIB
(29)
AV-AURASYSTEMMANAGERMGMTINVENTORY-MIB
(30)
AV-AURASYSTEMMANAGERMGMT-REPORTSMIB
(31)System_Mana
ger-IP-OfficeElementManager-MIB
MIB ASN1 File
This MIB to System Manager
CM Element Manager which
has information regarding
the notifications messages
that are used for generating
alarms.
Avaya
Specific
N/A
This MIB belongs to System
Manager Software
Management which has
information regarding the
notifications messages that
are used for generating
alarms.
Avaya
Specific
N/A
This MIB belongs to System
Manager Inventory
Management which has
information regarding the
notifications messages that
are used for generating
alarms.
Avaya
Specific
N/A
This MIB belongs to System
Manager Management
Reports which has
information regarding the
notifications messages that
are used for generating
alarms.
Avaya
Specific
N/A
Avaya
Specific
Notes
This Mib belongs to System
Manager IP office element
manager which has
information regarding the Ip
System_Manager_IP_Office_Element_Manager_MIB.mib
office specific objects and
messages that are used for
generating alarms.
© 2017 Avaya Inc. All rights reserved.
29
9.
Appendix B
Remote Access to System Manager CLI
System Platform
Avaya
NOC
Avaya
NOC
A
X
E
D
A
1
SAL GW
Network Tunnel
3
2
4
Avaya Issued
Certificate signed by
VeriSign
SMGR
Customer Network
1.
To access System Manager’s CLI, a network tunnel must be established with the SAL Gateway
(present on the System Platform U-dom) and session established with System Manager through
that tunnel. All subsequent requests to System Manager will be through the SAL Gateway.
To establish the tunnel, a technician must have access to the Axeda enterprise using a valid etoken. Also, the SAL Gateway needs to be configured to point to that Axeda enterprise. The
configuration in the SAL Gateway will involve:
1.
Setting a unique Solution Element ID (SEID) for the SAL Gateway. This ID will be used to
identify this SAL Gateway from the list of SAL Gateways available for access from the
Axeda enterprise.
2.
Setting the remote access configuration of the SAL Gateway to point to the required
Axeda enterprise.
3.
Adding System Manager as a managed element in the SAL Gateway. The System
Manager element will also require a unique SEID.
2.
Avaya Technician establishes a connection with the SMGR through a tunnel established between
Axeda Enterprise and the SAL Gateway.
3.
Avaya Technician sends a SSH connection request to the System Manager (e.g. via putty). The
request points to localhost instead of the System Manager’s IP address.
4.
System manager authenticates the technician based on the ASG Challenge/Response. This is an
optional step and may not be involved if local users are present for ssh access in the System
Manager.
© 2017 Avaya Inc. All rights reserved.
30