Configuring your Opengear's net-snmp agent to respond to SNMP queries

 Opengear devices host net-snmpd which, when enabled, provides status and alert information on demand through SNMP to remote managers. net-snmpd  allows external SNMP management software to query the Opengear appliance. Upon receiving a request, it processes the request, collects the requested information and/or performs the requested operation(s) and returns the information to the sender. This information includes: 

- Serial port status
- Active users
- Remote Power Control (RPC) and Power Distribution Unit (PDU) status
- Environmental Monitoring Device (EMD) status
- Signal alert status
- Environmental alert status and
- UPS alert status 

To enable and configure the SNMP agent.  

• Select Alerts & Logging: SNMP (or click on the SNMP daemon on the Service Settings tab on System: Services)

 

• The SNMP Service Details tab is shown by default.   The SNMP Service Details tab controls aspects of the SNMP Service including Security Level.  It manages requests from external agents for Opengear status information.
• Check the Enable the SNMP Service box to start the SNMP Service.  The Service is disabled by default. 
• Select either UDP or TCP for the TCP/IP Protocol.   UDP is the recommended protocol and is selected by default.  TCP should only be used in special cases such as when Port Forwarding SNMP requests/responses to or from the Opengear device is required.
• Complete the Location and Contact fields.  The Location field should describe the physical location of the Opengear and will be used in response to requests for the SNMPv2-MIB::sysLocation.0 of the device.  The Contact field refers to the person responsible for the Opengear such as the System Administrator and will be used in response to requests as follows:SNMPv2-MIB::sysContact.0.
• Enter the Read-Only Community and Read-Write Community.  This is required for SNMP v1 & v2c only.  The Read-Only Community field is used to specify the SNMPv1 or SNMPv2c community that will be allowed read-only (GET and GETNEXT) access.  This must be specified in order for both versions to become enabled.  The Read-Write Community field is used to specify the SNMPv1 or SNMPv2c community that will be allowed read-write (GET, GETNEXT and SET) access.
• Configure SNMP v3, if required.  SNMP v3 provides secure SNMP operations through the use of USM (User-based Security Model). It offers various levels of security including user-based authentication and basic encryption. 
  • The Engine ID is used to localize the SNMPv3 user.  It will be automatically generated from a Network Interface (eth0) hardware address, if left blank, or must be entered as a hex value e.g. 0x01020304.
  • Specify the Security Level:

noauth	No authentication or encryption is required. This is the minimum level of security.
auth	Authentication will be required but encryption is not enforced. An authentication protocol (SHA or MD5) and password will be required.
priv	Enforces the use of encryption. This is the highest level of security and requires an encryption protocol (DES or AES) and password in addition to the authentication protocol and password.

• Complete the Read Only Username.  Enter the read only security name. This field is mandatory and must be completed when configuring the console server  for SNMPv3.
•  For a Security Level of auth, select the Auth. Protocol (SHA or MD5) and the Auth. Password.  A password of at least 8 characters is required.
• For a Security Level of priv, select the Privacy Protocol (DES or AES) and the Privacy Password.  AES is recommended as it provides stronger privacy but requires more intense calculations.  A password of at least 8 characters is required.
• Click Apply

Once the SNMP agent has been configured, make sure that SNMP is allowed by checking the SNMP box, for the respective interface, in System, Services, Service Access.

Note     The console server supports different versions of SNMP including SNMPv1, SNMPv2c and SNMPv3. SNMP, although an industry standard, brings with it a variety of security concerns.  For example, SNMPv1 and SNMPv2c offer no inherent privacy, while SNMPv3 is susceptible to man-in-the-middle attacks.  Recent IETF developments suggests tunnelling SNMP over widely accepted technologies such as SSH (Secure Shell) or TLS (Transport Layer Security) rather than relying on a less mature security systems such as SNMPv3's USM (User-based Security Model).  Additional information regarding SNMP security issues and SNMPv3 can be found at:

 http://net-snmp.sourceforge.net/wiki/index.php/TUT:Security

 http://www.ietf.org/html.charters/snmpv3-charter.html. 

Note:  Some new SNMP status and trap MIBs were created in firmware versions 3.10.2 and above, to provide more and better structured SNMP status and traps from the console servers. However there is an option to Use Legacy Notifications for the SNMP traps. Setting this option means the console server will send the older SNMP traps that are compatible with those sent in older firmware before the new MIBS were added - ensuring that the firmware upgrade won't upset existing SNMP management a user will already have in place.

  

Refer https://opengear.zendesk.com/entries/32422199-New-status-and-trap-MIBS for more details.