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

Transcription

1 P a g e 1 Technical white paper SNMPv3 and NNMi A small introduction to SNMPv3 and how it works with Network Node Manager -i May 2015

2 P a g e 2 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 SNMPv3 Discovery One-stage discovery and two-stage discovery SNMPv3 Communication USM Report Codes that can be observed in a SNMPv3 packet List of Report PDUs SNMPv3 RFCs NNMi Node Discovery, Configuration and Status Poll Discovery and Configuration Poll... 23

3 P a g e 3 Status Poll Troubleshooting Loggers Communication Configuration Packet Capture Problem Examples NNMi and SNMPv3 configuration NNMi SNMP Security Levels NNMi SNMPv3 Settings SNMPv3 supported protocols Configuring NNMi to use SNMPv Example configuration SNMPv3 Traps SNMPv3 Informs For more information... 30

4 P a g e 4 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 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 nonauthoritative 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 nonauthoritative entity interchangeably. This also applies to agent and authoritative entity.

5 P a g e 5 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

6 P a g e 6 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: Description: Notes: Mandatory A SNMPv3 user that has access to certain MIBs in the device. SNMPv3 users need to be configured locally in the devices. Context Name Status: Description: Notes: Optional A context is a collection of MIBs that are accessible by a SNMPv3 user. 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.

7 P a g e 7 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

8 P a g e 8 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: Copyright (c) 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. Step 1. Create an SNMP group 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 Step 3. Test the configuration (CLI, from the NNMi Management Server) nnmsnmpwalk.ovpl -v 3 -v3u TestUserAuth -A authpass -a MD5 <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: Copyright (c) by cisco Systems, Inc. Compiled Thu 11-May-06 17: 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

9 P a g e 9 Step 1. Create an SNMP group 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 Step 3. Test the configuration (CLI, from the NNMi Management Server) nnmsnmpwalk.ovpl -v 3 -v3u TestUserPriv -A authpass -a MD5 -X privpass -x DES <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: Copyright (c) by cisco Systems, Inc. Compiled Thu 11-May-06 17: 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.

10 P a g e 10 Image 4. Steps to decrypt a SNMPv3 packet in Wireshark Result Image 5. SNMPv3 decrypted packet as seen in Wireshark

11 P a g e 11 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 nonauthoritative 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? From the RFC 3414 that describes the SNMPv3 protocol: 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.

12 P a g e 12 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. Image 6. SNMPv3 Packet as seen in Wireshark Response. A response is received that includes the Authoritative EngineID and the expected usmstatsunknownengineids report PDU.

13 P a g e 13 Image 7. SNMPv3 Packet as seen in Wireshark Communication. The communication is then established using the newly learned Authoritative EngineID. Image 8. SNMPv3 Packet as seen in Wireshark

14 P a g e 14 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 nonauthoritative 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.

15 P a g e 15 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. Image 10. SNMPv3 Packet as seen in Wireshark

16 P a g e 16 How does the non-authoritative SNMP engine learns the authoritative engineboots and enginetime required to establish Time Synchronization? From the RFC 3414 that describes the SNMPv3 protocol: 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

17 P a g e 17 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

18 P a g e 18 Response Image 14. SNMPv3 get-response packet as seen in Wireshark Request Image 15. SNMPv3 get-response packet as seen in Wireshark 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. From the RFC 3411 that describes the SNMPv3 protocol: 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).

19 P a g e 19 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 Image 16. SNMPv3 get-response packet as seen in Wireshark

20 P a g e 20 Authentication, No Privacy Image 17. SNMPv3 get-response packet as seen in Wireshark Authentication, Privacy Image 18. SNMPv3 get-response packet as seen in Wireshark 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.

21 P a g e 21 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 humanreadable 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 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.

22 P a g e 22 usmstatsnotintimewindows Summary: Outside of the authoritative SNMP engine's window Possible reason: The enginetime is not the expected value. usmstatsunknownusernames Summary: Packet referenced a user that was not known to the SNMP engine Possible reason: The user does not exist usmstatsunknownengineids 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 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 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: (SNMP Research International, Inc, 2015) RFC Introduction and Applicability Statements for Internet Standard Management Framework RFC An Architecture for Describing SNMP Management Frameworks RFC Message Processing and Dispatching RFC SNMP Applications RFC User-based Security Model RFC View-based Access Control Model RFC Version 2 of SNMP Protocol Operations RFC Transport Mappings

23 P a g e 23 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

24 P a g e 24 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 Example: nnmcommconf.ovpl -proto snmp -host <device> [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 = active readcommunity = null active SNMPv3 user = TestUserPriv active SNMPv3 context = null

25 P a g e 25 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 ( ) 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 ) 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 ) 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

26 P a g e 26 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 Deployment Reference, page 49, section SNMP Version Preferences. The following are the available security levels and a brief description: Community Only (SNMPv1 only) Community Only (SNMPv1 or v2c) Community No Authentication, No Privacy Authentication, No Privacy Authentication, Privacy NNMi will only use SNMPv1 to communicate with a device NNMi will try SNMPv2 first and if no response, NNMi will try SNMPv1 to communicate with a device NNMi attempts SNMPv2 communication first, if no response, it tries with SNMPv1 and if no response, it finally tries SNMPv3. NNMi attempts to use SNMPv3 only, with the noauthnopriv mode. NNMi attempts to use SNMPv3 only, with the AuthNoPriv mode. 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 User Name Context Name Authentication Protocol Passphrase Privacy Protocol Passphrase Internal record name to refer to the configuration. Not used by the SNMPv3 protocol during communication. SNMPv3 User Name SNMPv3 Context (if needed) SNMPv3 Authentication Protocol SNMPv3 Authentication Passphrase SNMPv3 Privacy Protocol SNMPv3 Privacy Passphrase Image 23. NNMi SNMPv3 Settings form Every SNMPv3 Settings entry can be used at any Communication Configuration level (Default, Region, and Specific Node Settings).

27 P a g e 27 SNMPv3 supported protocols The following are the SNMPv3 supported protocols in NNMi 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).

28 P a g e 28 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 Deployment Reference

29 P a g e 29 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 singlepacket 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 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 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 Deployment Reference, page 50, SNMPv3 Traps and Informs

30 P a g e 30 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.