SNMP overview

SNMP (Simple Network Management Protocol) is a mechanism for managing network and computer devices.

SNMP uses a manager/agent model for managing the devices. The agent resides in the device and provides the interface to the physical
device being managed. The manager resides on the management system and provides the interface between the user and the SNMP
agent. The interface between the SNMP manager and the SNMP agent uses a Management Information Base (MIB) and a small set of
commands to exchange information.

DANOS supports SNMP over both IPv4 and IPv6 networks.

The following list describes the SNMP components.

• MIB objects — A MIB contains the set of variables and objects that are managed (for example, MTU on a network interface). The objects are organized into a tree structure in which each object is a leaf node. Each object has its unique Object Identifier (OID). Objects are of two types: scalar and tabular. A scalar object defines a single object instance. A tabular object defines multiple related object instances that are grouped in MIB tables. For example, the uptime on a device is a scalar object, but the routing table in a system is a tabular object.

• Traps — In addition to MIB objects, the SNMP agent on a device can formulate alarms and notifications into SNMP traps. The device asynchronously sends the traps to the SNMP managers that are configured as trap destinations or targets. This sending of traps keeps the network manager informed of the status and health of the device. Traps are unacknowledged by the remote application that receives the message. DANOS uses User Datagram Protocol (UDP) for traps. For SNMP requests, UDP port 161 is used. For SNMP traps, UDP port 162 is used. SNMPv2 and SNMPv3 support traps. Traps can be configured for each routing protocol.
  
  NOTE - Protocols BFD, BGP, and OSPF are supported for SNMP traps and these traps are disabled by default.
  
  

• Informs — Informs are acknowledged traps. After receiving an inform notification, a remote application sends back an acknowledge message indicating that it received the message. By default, the DANOS uses UDP for inform notifications and sends inform notifications to trap targets.
  
  NOTE - SNMPv3 supports informs.

SNMP commands

SNMP commands can be used to read or change configuration or to perform actions on a device, such as resetting it. The set of commands used in SNMP are: GET, GET-NEXT, GET-RESPONSE, SET, and TRAP.

• GET and GET-NEXT are used by the SNMP manager to request information about an object. These commands are used to view configuration or status or to poll information, such as statistics.

• GET-RESPONSE is used by the SNMP agent on the device to return the requested information by GET or GET-NEXT or the status of the SET operation.

• SET is used by the SNMP manager to change the value of a specific object. Setting a configuration object changes the configuration of the device. Setting an executable object performs an action, such as a file operation or a reset.

• The TRAP command is used by the agent to asynchronously inform the manager about events important to the manager.

SNMP versions

Currently, SNMP has three versions:

• SNMPv1—This version is the first version of the protocol. It is described in RFC 1157.

• SNMPv2—This version is an evolution of the first version, and it adds a number of improvements to SNMPv1. It is described in RFCs 1902 through 1908.

• SNMPv3—This version improves the security model in SNMPv2 and adds support for proxies. It is described in RFCs 3413 through 3415.

DANOS supports SNMPv2 with community string (SNMPv2c) and SNMPv3 with SNMPv3 users.

SNMPv3

SNMPv3 adds security features to address the security shortcomings of SNMPv1 and SNMPv2.

The SNMPv3 architecture uses a modular approach to allow the protocol to be adapted in the future, if and when other types of features are added. The architecture supports the simultaneous use of different security, access control, and message processing models.

The SNMPv3 architecture provides the following security-related models:

• User-based Security Model (USM)—Used for message security. This model is defined in RFC 3414.

• Transport Security Model (TSM)—Used for message security. This model is defined in RFC 5591.

• View-based Access Control Model (VACM)—Used for access control. This model is defined in RFC 2275.

DANOS currently supports all three models.

The SNMPv3 architecture supports the following security features through USM and TSM:

• Data integrity—Ensures that packets have not been altered or destroyed in transit.

• Data-origin authentication—Verifies that the received packets come from a valid source.

• Data confidentiality— Encrypts packets to prevent data from being disclosed to unauthorized sources.

• Message timeliness and replay protection— Ensures a packet whose generation time is outside of a specified time window is not accepted.

USM

The User-based Security Model (USM) provides SNMP message-level security and is the default security model for SNMPv3. It also uses the traditional concept of a user (identified by a username) with which to associate security information. This model uses UDP to send the SNMP packets.

TSM

The Transport Security Model (TSM) within the SNMPv3 architecture is designed for use with secure transport protocols, such as SNMP over Secure Shell (SSH), Transport Layer Security (TLS), or Datagram Transport Layer Security (DTLS) to send SNMPv3 packets through secure tunnels. Brocade vRouter supports TLS and DTLS in its SNMPv3 implementation.

NOTE - The current implementation of TSM does not support SNMP over SSH.

TLS and DTLS use X.509 certificates to authenticate both the client and server of the secure tunnel connections. A public key infrastructure (PKI) is required to generate these certificates. To employ TLS and DTLS, you are required to generate X.509 security keys and certificates and install them on both the SNMP manager and the SNMP agent. The generation and distribution of certificates and keys using PKI involves numerous complex security issues, which are outside the scope of this document. Consult your particular PKI deployment documentation for the necessary procedures to generate and distribute these certificates and keys.

VACM

The View-based Access Control Model (VACM) is used for access control. In this model, access control is determined based on V3 groups and community. A group defines the access policy or the read-and-write access privileges for a set of SNMPv3 users. A group also defines the type of MIB view provided to a set of users. A group defines the following:

• Which users are allowed to access which view (a MIB or MIB object within a MIB)

• What type of access privileges are allowed into a view

NOTE - DANOS supports the access privilege types of read-only (ro) and read-write (rw) for groups.

Choosing USM or TSM

With two security models available, how do you determine which model to use in your network environment?

The main advantage of using TSM is the ability to integrate SNMP management into the existing X.509 public key security infrastructure of an organization.

Consider implementing TSM if you already have an X.509 public key infrastructure, need to deploy an X.509 public key infrastructure, or do not have a system for managing USM private keys in SNMPv3.

Consider implementing USM if you do not need to deploy an X.509 public key infrastructure or you already have a system for managing USM private keys for use in SNMPv3.

Default object IDs

Two default object IDs set by DANOS are as follows:

• sysObjectID = 1.3.6.1.4.1.30803

• sysDescr = Vyatta VSE6.6R0S6

The sysDescr object ID is updated automatically with each new release. It can also be changed by using the service snmp description desc command.

Supported MIBs

MIBs are typically located in the /usr/share/snmp/mibs directory.

SNMP configuration

Defining the SNMP community

SNMP community strings are used only by systems that support SNMPv1 and SNMPv2c protocols. SNMPv3 uses a username and password authentication, along with an encryption key.

The SNMP community of a system is the list of SNMP clients authorized to make requests of the system. Authorization for the community is in the form of a community string. The community string acts as a password, providing basic security and protecting the system against spurious SNMP requests.

• If no SNMP clients or networks are explicitly defined, then any client presenting the correct community string is granted the access privilege specified in the authorization option.

• If any client or network is defined, then only explicitly listed clients or networks are granted access to the system. Those clients have the access privilege specified by the authorization option. (The default is read-only.)

With reference to the figure Configuring SNMP communities and traps, the following configuration example shows how to set the SNMP community string for the system R1 to abc123 and specify three clients for the community with the following IP addresses: 176.16.0.15, 176.16.0.16, and 176.16.0.17. Read-only access is provided for this community.

Assigning views to an SNMP community

After you define an SNMP community and a view, you can associate each community with any number of views.

With reference to the figure Configuring SNMP communities and traps, the following example shows how to add views to a community.

Specifying protocol-specific traps

DANOS supports specifying SNMP traps for each routing protocol in your configuration. Currently, this feature is supported for BGP, BFD, and OSPF protocols.

NOTE - SNMP traps for all protocols are disabled by default on the DANOS. You must enable the SNMP traps by using the set service snmp notification command.

All notifications as defined in the supported MIBs for each routing protocol are enabled by using the keyword all in the command syntax. In the following figure, the community string for R1 is defined as abc123. The traps from R1 are configured to be sent to the three SNMP Managers that are defined by the IP addresses of 176.16.0.15, 176.16.0.16, and 176.16.0.17, respectively. R1 is connected to R2 and R3 by using a routing protocol, such as BFD. The following configuration example shows how to specify BFD-specific SNMP traps for R1. NOTE The command to enable protocol-specific SNMP traps is similar for all routing protocols.

SNMP over IPv6

This sequence is the same as the previous example but uses IPv6 addresses.

To define the SNMP configuration, perform the following steps in configuration mode.