Technical white paper SNMPv3 and NNMi - Micro Focus …SNMPv3 Introduction SNMP (Simple Network...

P a g e | 1

Sign up for updates

hp.com/go/getupdated

© Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice. The only warranties for HP

products and services are set forth in the express warranty statements accompanying such products and services. Nothing herein should be construed as constituting

an additional warranty. HP shall not be liable for technical or editorial errors or omissions contained herein.

Technical white paper

SNMPv3 and NNMi A small introduction to SNMPv3 and how it works with Network Node Manager -i

May 2015

P a g e | 2

Sign up for updates





Contents Contents .................................................................................................................................................................. 2

SNMPv3 Introduction ............................................................................................................................................. 4

SNMPv3 Enhancements .................................................................................................................................... 4

SNMPv3 Goals .................................................................................................................................................... 4

Authoritative and Non-authoritative SNMP entities ...................................................................................... 4

SNMPv3 Configuration Modes .............................................................................................................................. 5

No Authentication and No Privacy ................................................................................................................... 5

Authentication with No Privacy ........................................................................................................................ 5

Authentication with Privacy .............................................................................................................................. 6

Authentication and Privacy Protocols ............................................................................................................. 6

Communication Configuration ............................................................................................................................. 6

User Name .......................................................................................................................................................... 6

Context Name .................................................................................................................................................... 6

Authentication passphrase and protocol ....................................................................................................... 6

Privacy passphrase /protocol .......................................................................................................................... 7

Configuring a Cisco Router .................................................................................................................................... 7

No Authentication with No Privacy configuration mode ............................................................................... 7

Authentication with No Privacy configuration mode ..................................................................................... 8

Authentication with Privacy configuration mode .......................................................................................... 8

How to decrypt a SNMPv3 packet in Wireshark ................................................................................................. 9

SNMPv3 Objects ................................................................................................................................................... 11

SNMPv3 Discovery ............................................................................................................................................... 11

One-stage discovery and two-stage discovery ........................................................................................... 14

SNMPv3 Communication ..................................................................................................................................... 18

USM Report Codes that can be observed in a SNMPv3 packet ...................................................................... 21

List of Report PDUs ......................................................................................................................................... 21

SNMPv3 RFCs ....................................................................................................................................................... 22

NNMi Node Discovery, Configuration and Status Poll ..................................................................................... 23

Discovery and Configuration Poll................................................................................................................... 23

P a g e | 3

Sign up for updates





Status Poll ........................................................................................................................................................ 23

Troubleshooting ................................................................................................................................................... 24

Loggers ............................................................................................................................................................. 24

Communication Configuration ....................................................................................................................... 24

Packet Capture ................................................................................................................................................. 25

Problem Examples............................................................................................................................................... 25

NNMi and SNMPv3 configuration ....................................................................................................................... 26

NNMi SNMP Security Levels ............................................................................................................................ 26

NNMi SNMPv3 Settings ................................................................................................................................... 26

SNMPv3 supported protocols ........................................................................................................................ 27

Configuring NNMi to use SNMPv3 .................................................................................................................. 27

Example configuration .................................................................................................................................... 28

SNMPv3 Traps .................................................................................................................................................. 28

SNMPv3 Informs .............................................................................................................................................. 29

For more information ...................................................................................................................................... 30

P a g e | 4

Sign up for updates





SNMPv3 Introduction SNMP (Simple Network Management) is an internet standard protocol for managing devices on IP

networks. It supports both IPv4 and IPv6, and it is mostly used in network management systems (NMS) to

monitor network devices.

SNMPv3 Enhancements SNMPv3 (SNMP version 3) provides security enhancements (over SNMP v1 and v2c) to the SNMP protocol

by adding the following to the SNMP packets that travel through the network

Authentication (The use of a passphrase to authenticate with the agent/manager.)

Encryption (The use of an encryption protocol to encrypt the payload.)

SNMPv3 Goals From the RFC 3414 that describes the SNMPv3 protocol:

Provide for verification that each received SNMP message has not

been modified during its transmission through the network.

Provide for verification of the identity of the user on whose

behalf a received SNMP message claims to have been generated.

Provide for detection of received SNMP messages, which request or

contain management information, whose time of generation was not

recent.

Provide, when necessary, that the contents of each received SNMP

message are protected from disclosure.

USM for SNMPv3, RFC 3414 - http://www.ietf.org/rfc/rfc3414.txt

This enhances SNMPv1|2c where control was performed by community strings, sent in clear text through

the network.

The inconvenient is a more complex configuration needed on both sides, the agent and the manager.

Authoritative and Non-authoritative SNMP entities The SNMPv3 protocol definition no longer refers to the concepts of “agent” and “manager”, instead it

refers to “SNMP Entities” that can be authoritative and non- authoritative.

The authoritative entities receive the SNMP requests (get, set, getnext and getbulk…) and the non-

authoritative entity request them.

In the NMS context, most of the time the manager is the non-authoritative entity and the agent the authoritative one. For the purposes of this document, we will use the terms manager and non-authoritative entity interchangeably. This also applies to agent and authoritative entity.

http://www.ietf.org/rfc/rfc3414.txt

P a g e | 5

Sign up for updates





SNMPv3 Configuration Modes The SNMPv3 protocol definition allows for several modes of operation.

The following are the different modes that are defined:

No Authentication and No Privacy This is the simplest configuration mode and does not have a significant improved security over SNMPv1|2c

as there is no authentication and the payload is transferred in plain text over the network.

Example.

Image 1. SNMPv3 Packet with No Authentication and No Privacy as seen in Wireshark

Authentication with No Privacy This mode allows for user authentication between the manager and the agent. The authentication

passphrase is passed using a message digest but the packet’s payload (data to be transferred) is not

encrypted, therefore it can be intercepted easily.

Example.

Image 2. SNMPv3 Packet with Authentication and No Privacy as seen in Wireshark

P a g e | 6

Sign up for updates





Authentication with Privacy This is the most secure mode as it allows for user authentication and an encrypted payload.

Example.

Image 3. SNMPv3 Packet as seen in Wireshark

Authentication and Privacy Protocols The following are the encryption protocols supported. Some SNMPv3 devices may not support all of the

protocols

Authentication encryption protocols: MD5 and SHA (message digest)

Privacy encryption protocols: DES and AES (symmetric key data encryption)

Communication Configuration In order to establish a communication with an authoritative SNMP entity, the following parameters need to be known by the non-authoritative SNMP entity.

User Name Status: Mandatory

Description: A SNMPv3 user that has access to certain MIBs in the device.

Notes: SNMPv3 users need to be configured locally in the devices.

Context Name Status: Optional Description: A context is a collection of MIBs that are accessible by a SNMPv3 user. Notes: It is optional as it may or may not be configured on the agent side.

Authentication passphrase and protocol Status: Optional

Description: Passphrase: The passphrase to authenticate against the SNMP agent.

Protocol: The protocol used to encrypt the passphrase.

Notes: If configured on the agent, then it needs to be specified on the manager.

P a g e | 7

Sign up for updates





Privacy passphrase /protocol Status: Optional

Description: Passphrase: The passphrase used to encrypt the packet’s payload

Protocol: The protocol used to encrypt the payload.

Notes: If configured on the agent, then it needs to be specified on the manager.

Configuring a Cisco Router The following are the configuration examples of SNMPv3 on a Cisco 3640 router.

Notes:

All commands below will be executed in the Cisco Configure Terminal Mode (configure terminal)

Text in blue is the command syntax and/or output

Text in orange are the configuration parameters

The Cisco 3640 router support the three SNMPv3 modes mentioned earlier

# snmp-server group test v3 ?

auth group using the authNoPriv Security Level

noauth group using the noAuthNoPriv Security Level

priv group using SNMPv3 authPriv security level

No Authentication with No Privacy configuration mode Note: This is the simplest configuration mode and does not have a significant improved security over SNMPv1|2c

Step 1. Create an SNMP group

The SNMP group is used to specify the configuration mode, in this case, NoAuth

# snmp-server group TestGroupNoAuth v3 noauth

Step 2. Create an SNMP user

Create and attach the user to the recently created group (TestGroupNoAuth).

# snmp-server user TestUserNoAuth TestGroupNoAuth v3

P a g e | 8

Sign up for updates





Step 3. Test the configuration (CLI, from the NNMi Management Server)

nnmsnmpwalk.ovpl -v 3 -v3u TestUserNoAuth <device> sysDescr

sysDescr.0 : OCTET STRING- (ascii): Cisco Internetwork Operating System Software

IOS (tm) 3600 Software (C3640-IK9S-M), Version 12.3(19), RELEASE SOFTWARE (fc2)

Technical Support: http://www.cisco.com/techsupport

Copyright (c) 1986-2006 by cisco Systems, Inc.

Compiled Thu 11-May-06 17:

Authentication with No Privacy configuration mode Note: Because the SNMPv3 with authentication and/or privacy configuration uses encrypted data, it is not stored in the normal

“running config” file in the device (because that file is stored as plain text) and therefore the configuration will not be in the output of

“show running config”.


The SNMP group is used to specify the configuration mode, in this case, AuthNoPriv

# snmp-server group TestGroupAuth v3 auth

Step 2. Create an SNMP user using MD5 as the authentication protocol

Create and attach the user to the recently created group (TestGroupAuth).

# snmp-server user TestUserAuth TestGroupAuth v3 auth md5 authPass


nnmsnmpwalk.ovpl -v 3 -v3u TestUserAuth -A authPass -a MD5 <device> sysDescr






Authentication with Privacy configuration mode Note. Because the SNMPv3 with authentication and/or privacy configuration uses encrypted data, it is not stored in the normal

“running config” file in the device (because that file is stored as plain text) and therefore the configuration will not be in the output of

“show running config”

P a g e | 9

Sign up for updates






The SNMP group is used to specify the configuration mode, in this case, AuthPriv

# snmp-server group TestGroupPriv v3 priv

Step 2. Create an SNMP user using MD5 as the authentication protocol and DES for the privacy protocol

The user is attached to the recently created group (TestGroupPriv).

# snmp-server user TestUserPriv TestGroupPriv v3 auth md5 authPass priv des privPass


nnmsnmpwalk.ovpl -v 3 -v3u TestUserPriv -A authPass -a MD5 -X privPass -x DES <device>

sysDescr






How to decrypt a SNMPv3 packet in Wireshark When the Privacy configuration mode is in use, Wireshark is unable to decrypt the packets unless it is

configured it with the agent’s pass-phrases and protocols. To configure Wireshark to decrypt an encrypted

v3 packet the following can be done:

Steps

1) Edit > Preferences >> 2) Protocols > SNMP

3) Users Table > Edit >> 4) Add New

4.a Engine ID

4.b Username

5) Authentication Model and Password, Privacy Protocol and Password Note: The authentication and privacy protocols can be either obtained from the NNMi configuration or be provided by the

network team, but the password must be provided by the network admins as it is encrypted in the database.

P a g e | 10

Sign up for updates





Image 4. Steps to decrypt a SNMPv3 packet in Wireshark

Result

Image 5. SNMPv3 decrypted packet as seen in Wireshark

P a g e | 11

Sign up for updates





SNMPv3 Objects The non-authoritative engine needs to learn some values from the authoritative engine so that the

communication is allowed. Once that those values are learnt by the manager, then communication

(encrypted or plain text) can be initiated.

From the RFC 3414 that describes the SNMPv3 protocol:

Each SNMP engine maintains three objects:

- snmpEngineID …

- snmpEngineBoots …

- snmpEngineTime …

Each SNMP engine is always authoritative with respect to these objects

in its own SNMP entity. It is the responsibility of a non-

authoritative SNMP engine to synchronize with the authoritative SNMP

engine, as appropriate.

As mentioned in the RFC, it is the responsibility of the non-authoritative SNMP engine to synchronize with

the authoritative SNMP engine. This synchronization process is known as SNMPv3 discovery, described

next.

SNMPv3 Discovery From the RFC 3414 that describes the SNMPv3 protocol:

The User-based Security Model requires that a discovery process

obtains sufficient information about other SNMP engines in order to

communicate with them. Discovery requires a non-authoritative SNMP engine to learn the authoritative SNMP engine's snmpEngineID value

before communication may proceed.

So, to initiate communication, the non-authoritative entity needs first to learn the authoritative

snmpEngineID.

How does the non-authoritative SNMP engine learns the authoritative snmpEngineID required for SNMPv3

communication?


This may be accomplished by generating a Request message with a

securityLevel of noAuthNoPriv, a msgUserName of zero-length, a

msgAuthoritativeEngineID value of zero length, and the varBindList left

empty. The response to this message will be a Report message

containing the snmpEngineID of the authoritative SNMP engine as the

value of the msgAuthoritativeEngineID field within the

msgSecurityParameters field. It contains a Report PDU with the

usmStatsUnknownEngineIDs counter in the varBindList.

P a g e | 12

Sign up for updates





The following images are packet captures that demonstrates the steps.

Request. A request is sent with no engineID, username, authentication or privacy information and the

varbind list left empty.


Response. A response is received that includes the Authoritative EngineID and the expected

“usmStatsUnknownEngineIDs” report PDU.

P a g e | 13

Sign up for updates






Communication. The communication is then established using the newly learned Authoritative EngineID.


P a g e | 14

Sign up for updates





It can be observed in the process above that no user authentication was performed (observe the msgAuthenticationParameters field). This is because Authentication Protocol and Passphrase was not configured in the Authoritative entity. Note: *** This is not a recommended configuration as it does not introduce any significant improvement over the SNMPv1 or SNMPv2c. For all production systems Authentication Security Level should be used. In the case that the Authentication Security Level is configured in the Authoritative Entity, the RFC 3414 states the following

If authenticated communication is required, then the discovery

process should also establish time synchronization with the

authoritative SNMP engine.

To establish Time Synchronization two more values are needed to be learnt from the Authoritative entity: snmpEngineBoots snmpEngineTime The need to learn these values introduce the one-stage or two-stage discovery process.

One-stage discovery and two-stage discovery The following is a first response obtained from an Authoritative Entity as part of the discovery process. It can be observed that the Authoritative Entity has provided the engineBoots and engineTime values on its first response to the non-authoritative entity as part of the discovery process. At this time the non-authoritative entity will be able to establish time synchronization and communication will be possible. This process is known as one-stage discovery, as only one packet exchange between the manager and the agent were required for the discovery process.

P a g e | 15

Sign up for updates





Response. It includes the engineID and the required values of engineBoots and engineTime

Image 9. SNMPv3 Packet as seen in Wireshark However, there are occasions where the Authoritative Entity will not provide the engineBoots and

engineTime values on its first response. The following is an example.

Response. Notice that the engineID and the expected usmStatsUnknownEngineIDs report PDU are

received, but not the engineBoots and engineTime.


P a g e | 16

Sign up for updates





How does the non-authoritative SNMP engine learns the authoritative engineBoots and engineTime

required to establish Time Synchronization?


This may be accomplished by sending an authenticated Request message

with the value of msgAuthoritativeEngineID set to the newly learned

snmpEngineID and with the values of msgAuthoritativeEngineBoots and

msgAuthoritativeEngineTime set to zero. For an authenticated Request

message, a valid userName must be used in the msgUserName field. The

response to this authenticated message will be a Report message

containing the up to date values of the authoritative SNMP engine's

snmpEngineBoots and snmpEngineTime as the value of the

msgAuthoritativeEngineBoots and msgAuthoritativeEngineTime fields

respectively. It also contains the usmStatsNotInTimeWindows counter

in the varBindList of the Report PDU.

It is required to send a second packet to the Authoritative Entity to obtain the information, hence the name

two-stage discovery.

The second packet will contain the newly learned engineID, a valid username, and the engineBoots and

engineTime values set to Zero. And in response, the Authoritative entity will respond with the engineTime,

engineBoots and the “usmStatsNotInTimeWindows” report PDU

Example of One-stage Discovery

Request

Image 11. SNMPv3 get-request packet as seen in Wireshark

P a g e | 17

Sign up for updates





Response

Image 12. SNMPv3 get-response packet as seen in Wireshark

Example of Two-stage discovery

Request

Image 13. SNMPv3 get-request packet as seen in Wireshark

P a g e | 18

Sign up for updates





Response


Request


SNMPv3 Communication Once that the non-authoritative entity has learnt the required values to communicate, the communication

can start.

Depending on the SNMPv3 Configuration Mode (NoAuthNoPriv, AuthNoPriv, AuthPriv), the subsequent

packets after the discovery need to be properly encoded for that configuration mode.


The msgUserName specifies the user (principal) on whose behalf the

message is being exchanged. Note that a zero-length userName will

not match any user, but it can be used for snmpEngineID discovery.

The msgAuthenticationParameters are defined by the authentication

protocol in use for the message, as defined by the usmUserAuthProtocol

column in the user's entry in the usmUserTable.

The msgPrivacyParameters are defined by the privacy protocol in use for

the message, as defined by the usmUserPrivProtocol column in the user's

entry in the usmUserTable).

P a g e | 19

Sign up for updates





All Configuration Modes

The msgUserName must be included in packets for all Configuration Modes, except during the Discovery

Process. If a Valid user name is not included in the requests then the agent will respond with an

“usmStatsUnknownUserNames” response PDU and terminate the communication.

Including a username does not provide Authentication, as the pass-phrase is the method use to

authenticate the user. Providing a username is a protocol requirement that is used to specify the user on

whose behalf the message is being exchanged, therefore, the user is required even when no

Authentication is configured.

Authentication Mode

If the User in question has been configured to use Authentication, then the msgAuthenticationParameters

must include the user’s authentication information. If the Authentication parameters are not included then

the agent will respond with an “usmStatsUnsupportedSecLevels” response PDU. Similarly, if the

information is incorrect then the agent will respond with an “usmStatsWrongDigests” response PDU. In

both scenarios, the agent terminates the communication.

Authentication and Privacy

If the User in question has also been configured for Privacy, then the msgPrivacyParameters must include

the user’s Privacy configuration and the packet’s Payload must be encrypted. If the privacy Parameters are

not included then the agent will respond with an “usmStatsUnsupportedSecLevels” response PDU.

Similarly, if the information is incorrect then the agent will respond with an “usmStatsDecryptionErrors”

response PDU. In both scenarios, the agent terminates the communication.

Communication Examples

No Authentication No Privacy Mode


P a g e | 20

Sign up for updates





Authentication, No Privacy


Authentication, Privacy


Important to note about engineTime and engineBoots

Time synchronization is performed as a mechanism to protect from message replay. During

communication, the snmpEngineTime value has to be within 150 seconds (when compared with the local

notion of snmpEngineTime) and if the remote device is rebooted, then the device’s snmpEngineBoots

value must be incremented by one, so that the remote entity can interpret that a reboot occurred and

therefore the engineTime needs to be updated.

P a g e | 21

Sign up for updates





This allows for proper communication between the manager and the agent. This is described in the RFC

3414, Sub-section 3.2 “Processing an Incoming SNMP Message”. Increasing the snmpEngineBoots value

allows the manager to detect the reboot, and keeping the snmpEngineTime value within 150 seconds has

been defined in the same RFC as “the window of time in which a message generated on behalf of any user

is valid” Please refer to the RFC 3414 for more details.

USM Report Codes that can be observed in a SNMPv3 packet When the authoritative entity detects a problem with a SNMPv3 request, it responds with a Report PDU

that contains one of the defined USM report codes defined below. The USM report codes are found within

the varbind list of the response packet.

If trying to run an nnmsnmpwalk.ovpl against a v3 device then the tool will output the error in human-

readable form.

CLI example for an un-existing user:

Image 19. CLI Example for a SNMPv3 Response

Packet example:

Image 23. SNMPv3 packet with a response code as seen in Wireshark

List of Report PDUs usmStatsUnsupportedSecLevels | .1.3.6.1.6.3.15.1.1.1

Summary: The SecurityLevel was unknown to the SNMP engine

Possible reason: The security level, or configuration mode (noAuth, AuthNoPriv, Priv) in use is not

configured in the entity.

P a g e | 22

Sign up for updates





usmStatsNotInTimeWindows | .1.3.6.1.6.3.15.1.1.2

Summary: Outside of the authoritative SNMP engine's window

Possible reason: The engineTime is not the expected value.

usmStatsUnknownUserNames | .1.3.6.1.6.3.15.1.1.3

Summary: Packet referenced a user that was not known to the SNMP engine

Possible reason: The user does not exist

usmStatsUnknownEngineIDs | .1.3.6.1.6.3.15.1.1.4

Summary: Packet referenced a snmpEngineID that was not known to the SNMP engine

Possible reason: The engineID is that the expected one. This is normal during v3 discovery.

usmStatsWrongDigests | .1.3.6.1.6.3.15.1.1.5

Summary: Packet didn't contain the expected digest value

Possible reason: Digest values are used in the Authentication Protocol. Possibly the

Authentication Passphrase is incorrect.

usmStatsDecryptionErrors | .1.3.6.1.6.3.15.1.1.6

Summary: Packet could not be decrypted

Possible reason: Possibly the Privacy Passphrase is incorrect

SNMPv3 RFCs The following is a list of SNMPv3 RFC documents that can become useful in the case that interoperability

issues occur or that it is desired to expand the knowledge of the protocol.

The list of RFCs has been taken from the following source:

http://www.snmp.com/protocol/snmp_rfcs.shtml (SNMP Research International, Inc, 2015)

RFC 3410. Introduction and Applicability Statements for Internet Standard Management Framework

RFC 3411. An Architecture for Describing SNMP Management Frameworks

RFC 3412. Message Processing and Dispatching

RFC 3413. SNMP Applications

RFC 3414. User-based Security Model

RFC 3415. View-based Access Control Model

RFC 3416. Version 2 of SNMP Protocol Operations

RFC 3417. Transport Mappings

http://www.snmp.com/protocol/snmp_rfcs.shtml

P a g e | 23

Sign up for updates





NNMi Node Discovery, Configuration and Status Poll

Discovery and Configuration Poll During initial discovery, re-discovery and configuration poll, NNMi goes through the SNMPv3 discovery

process.

The information collected during the SNMPv3 discovery process is cached within NNMi memory and used

for subsequent status polling.

Example of a Configuration Poll for a v3 node that has been already discovered by NNMi:

Image 20. SNMPv3 packets as seen in Wireshark during an NNMi Configuration Poll

Status Poll During on demand or scheduled status poll, NNMi uses the cached SNMPv3 parameters for

communication.

Example of a Status Poll for a v3 node that has been already discovered by NNMi:

Image 21. SNMPv3 packets as seen in Wireshark during an NNMi Status Poll

P a g e | 24

Sign up for updates





Troubleshooting

Loggers Use the loggers with caution since they may create a massive amount of data in an environment with

thousands of nodes being monitored

nnmsetlogginglevel.ovpl com.hp.ov.snmp

nnmsetlogginglevel.ovpl com.hp.ov.nms.comm

nnmsetlogginglevel.ovpl com.hp.ov.nms.snmp

Communication Configuration Use the Actions > Configuration Details > Communication Configuration UI menu or the following command

to retrieve the communication settings for the node in question

nnmcommconf.ovpl -proto snmp -host <device>

Example:

[root@server ~]# nnmcommconf.ovpl -proto snmp -host <device>

SNMP Configuration Entry:

name = <device>

management address = <IP>

addressForced = true

preferredVersion = null

minimum security level = Authentication, Privacy

readCommunity = null

writeCommunity = null

timeout = 5000

retries = 2

port = 161

proxyPort = null

proxyAddress = null

SNMPv3 user names = TestUserPriv

SNMPv3 context names =

enabled = true

address disco enabled = false

get bulk enabled = true

region name = null

node setting description = null

active address = 172.16.10.73

active readCommunity = null

active SNMPv3 user = TestUserPriv

active SNMPv3 context = null

P a g e | 25

Sign up for updates





Packet Capture Use Wireshark on Windows, snoop on Solaris, nettl on HPUX or tcpdump on Linux to capture the

communication.

Then use Wireshark to decode the packets (if encrypted) as shown earlier on this document.

Problem Examples usmStatsUnsupportedSecLevels - Configuration Poll

1) NNMi does send the discovery packet

2) The device does respond with the usual “usmStatsUnknownEngineIDs” report

(1.3.6.1.6.3.15.1.1.4)

3) NNMi then sends a get request with the username, engine ID but it sends it in plain text, it

does not use the authentication/privacy configuration

4) The agent responds with “usmStatsUnsupportedSecLevels” “1.3.6.1.6.3.15.1.1.1”

5) The node discovery ends here and it is discovered as non-SNMP.

Possible Reason: NNMi is not configured with the correct privacy/authentication mode.

Solution: Configure NNMi properly

usmStatsNotInTimeWindows - Status Poll

1) The device is already discovered therefore NNMi sends a request packet with the known v3

parameters.

2) The agent responds with “usmStatsNotInTimeWindows” “1.3.6.1.6.3.15.1.1.2”

3) The status poll fails

Possible Reason: The agent restarted, it did not update the engineBootCount and the engineTime

known by NNMi is incorrect.

Solution: Run a configuration poll against the device

P a g e | 26

Sign up for updates





NNMi and SNMPv3 configuration

NNMi SNMP Security Levels NNMi supports several security levels for SNMP communication. A security level is a combination of

allowed SNMP versions that can be tried to communicate with an agent.

The detailed description of the available security levels are documented in the NNMi 10.00 Deployment

Reference, page 49, section “SNMP Version Preferences”.

The following are the available security levels and a brief description:

Community Only (SNMPv1 only) NNMi will only use SNMPv1 to communicate with a device Community Only (SNMPv1 or v2c) NNMi will try SNMPv2 first and if no response, NNMi will try

SNMPv1 to communicate with a device

Community NNMi attempts SNMPv2 communication first, if no response, it tries with SNMPv1 and if no response, it finally tries SNMPv3.

No Authentication, No Privacy NNMi attempts to use SNMPv3 only, with the noAuthNoPriv mode. Authentication, No Privacy NNMi attempts to use SNMPv3 only, with the AuthNoPriv mode. Authentication, Privacy NNMi attempts to use SNMPv3 only, with the AuthPriv mode.

Security levels can be configured at the Communication Settings > Default and Regional levels only. For

the Communication > Specific Node Settings, the user must choose one explicit protocol to communicate.

NNMi SNMPv3 Settings An NNMi SNMPv3 Settings is a table entry that contains the following information.

Unique Name Internal record name to refer to the configuration. Not used by the SNMPv3 protocol during communication.

Image 23. NNMi SNMPv3 Settings form

User Name SNMPv3 User Name Context Name SNMPv3 Context (if needed) Authentication Protocol SNMPv3 Authentication

Protocol Passphrase SNMPv3 Authentication

Passphrase Privacy Protocol SNMPv3 Privacy Protocol Passphrase SNMPv3 Privacy Passphrase

Every SNMPv3 Settings entry can be used at any Communication Configuration level (Default, Region, and

Specific Node Settings).

P a g e | 27

Sign up for updates





SNMPv3 supported protocols The following are the SNMPv3 supported protocols in NNMi 10.00

For SNMPv3 authentication:

HMAC-MD5-96

HMAC-SHA-1

For SNMPv3 privacy:

DES-CBC

TripleDES

AES-128

AES-192

AES-256

Configuring NNMi to use SNMPv3 The configuration can be done at the Default, Regional or Specific Node Settings level in the NNMi

Communication Configuration works-space.

Image 24. NNMi Communication Configuration works-space

If using the Default or Region configuration levels, then the SNMP Minimum Security Level needs to be set

to “”Community” or one of the SNMPv3 Specific Security Levels (Authentication, Privacy and their

combinations).

P a g e | 28

Sign up for updates





If “Community” is chosen, and a valid SNMP Community String is also configured at the level, then NNMi

will succeed to communicate using SNMPv2c or SNMPv1 before it attempts to use SNMPv3, therefore

SNMPv3 will not be used.

In that case, if you need NNMi to use SNMPv3 you can try one of the following possible solutions:

Configure the agent to only support SNMPv3 (do not respond to the community string)

Configure NNMi to use a SNMPv3 Specific Security Level (at a Regional or Specific Level)

Example configuration The image below shows an example configuration in the Regional Communication Configuration. The

SNMP Minimum Security Level has been set to the SNMPv3 Specific Level “Authentication, Privacy” and a

new SNMPv3 Settings entry has been added “testSNMPv3Setting”.

Under this configuration, for every node contained in this region, NNMi will try to communicate specifically

with SNMPv3 using the parameters in the “testSNMPv3Setting”configuration.

Image 25. NNMi Communication Configuration for Region

SNMPv3 Traps The following has been taken from the NNMi 10.00 Deployment Reference

P a g e | 29

Sign up for updates





When NNMi uses SNMPv3 to communicate with a device, it uses a discovery process to identify the

Engine ID, boot count, and engine time of the device. NNMi then uses this information, along with

the configured user and protocol details, to start sending messages to the device. When the device

sends a trap to NNMi, the device may not have the NNMi information, and because a trap is a single-

packet transaction, it has no way to get the necessary information. Therefore, it uses its own Engine

ID, boot count and engine time in the trap, along with the user name and protocol details. These

device details must be the same as those configured for the device in NNMi. You cannot configure

multiple SNMPv3 users per device in NNMi.

NNMi 10.00 Deployment Reference, page 50, “SNMPv3 Traps and Informs”

A SNMP trap is an unsolicited message sent from the managed node to the management server, it is a

single transaction and because of that it does not try to perform a SNMPv3 information discovery to

obtain the management server’s Engine ID, Boot Count or engine time. As a result, when sending a

SNMPv3 trap, the device uses its own values. For NNMi to be able to process a SNMPv3 trap, the node

sending the trap needs to have been discovered by NNMi as a SNMPv3 device, this way, NNMi will have

cached the device’s Engine Time, Engine ID and Boot Count and NNMi will also know the managed node’s

user and protocol configuration. NNMi will use this information to process the incoming trap. Without the

information NNMi will be unable to process the trap.

The User and Protocol configuration information in the trap must match what has been configured in NNMi

for the device, otherwise NNMi will be unable to process the trap (i.e won’t be able to decrypt the

information).

SNMPv3 Informs

The following has been taken from the NNMi 10.00 Deployment Reference

An inform is an acknowledged packet, so this is more like an SNMP request that NNMi would make

to the device except, this time, it is the device initiating the first packet and NNMi responding with the

acknowledgment. The device, therefore, performs the discovery to NNMi to learn NNMi’s Engine ID,

boot count and engine time. The user name and protocol configuration that the device uses must

match what is configured in the NNMi trap forwarding configuration—this is, in effect, NNMi’s

SNMPv3 agent configuration

NNMi 10.00 Deployment Reference, page 50, “SNMPv3 Traps and Informs”

P a g e | 30

Sign up for updates





The SNMPv3 Inform, as opposed to a trap, does perform a SNMP discovery. The process will be similar to

the one described on this document under the “SNMPv3 Discovery” section. On this scenario, the device is

initiating the connection and it will be responsible to perform the SNMPv3 information discovery (Engine

Time, Engine ID, Boot Count). To be able to communicate with NNMi, the managed device will have to

know the NNMi User and Configuration Protocols. Just like NNMi needs to know the same information

when initiating communication with a managed v3 device.

The device needs to be configured to use the NNMi’s user and protocol information. The NNMi user and

protocol information can be found by accessing the following configuration page in the NNMI Web

Console:

Configuration > Incidents > Trap Server > Trap Forwarding Configuration

By default, the username is “NNMi” and the protocol information is not configured as seen below

Image 26. NNMi Trao Forwarding Configuration page

After defining the Authentication and Privacy settings in NNMI, configure the remote device sending the

SNMPv3 informs to use these settings as well.

For more information For more information about configuring NNMi to work with SNMPv3, please refer to the NNMi Deployment

Reference for your NNMi version.

Technical white paper SNMPv3 and NNMi - Micro Focus …SNMPv3 Introduction SNMP (Simple Network...

Documents

Transcript of Technical white paper SNMPv3 and NNMi - Micro Focus …SNMPv3 Introduction SNMP (Simple Network...