Skip to main content

Simple Network Management Protocol (SNMP) - Overview

Simple Network Management Protocol (SNMP) is an internet standard protocol for collecting and organizing information about managed devices on IP networks and for modifying that information to change device behavior. SNMP is widely used in network management for network monitoring. SNMP exposes management data in the form of variables on the managed systems organized in a management information base (MIB) which describe the system status and configuration.1

The SSR implementation of SNMP relies on the snmpd process running within the host operating system. All configuration for SNMP, however, is done within the SSR's data model via its administrative interfaces (e.g., PCLI, GUI, etc.).

MIB Definitions​

SSR provdes MIB files that describe the SSR SNMP objects and traps available on the SSR device and how they are encoded. For ease of use, these are installed on the device itself in this location:

/usr/share/snmp/128technology/

A Network Management System (NMS) can import these MIBs when managing the SSR appliance. The latest mibs can be optionally installed by downloading the latest "128T-mibs" package from the SSR yum repoisitory.

dnf install 128T-mibs
note

In order to install the SSR MIBS on another platform, a valid certificate and yum repo file must be present on the platform in order to obtain the file from the SSR repository.

The specific objects available in the MIB are described in more details in the the section MIB Layout.

SNMP v2c Basic Configuration​

Configuring SNMP on the SSR is done on a per-router basis, and is done within the router > system settings > snmp-server branch of the configuration hierarchy. There are three areas of configuration required: the protocol configuration, the access configuration, and the notification receiver configuration.

Sample Configuration (Basic)​

snmp-server
    enabled                true
    version                v2c
    port                   161

    access-control         my-nms-agent
        name       my-nms-agent
        community  public
        source     10.128.201.2
    exit

    notification-receiver  10.128.201.2 162 trap
        ip-address  10.128.201.2
        port        162
        type        trap
    exit
exit

Protocol Configuration​

The protocol configuration requires three settings: setting enabled to true enables the SNMP agent on your SSR. Set the protocol to v2c. Finally, configure the port on which the SNMP agent will listen for inbound requests; this is typically 161, the well-known port for SNMP agent requests.

Access Configuration​

The access configuration lets you create a set of "allowlist" addresses allowed to interact with the SSR SNMP agent (i.e., to send GET requests to the SSR). This represents your SNMP management platform.

The access configuration, configured within access-control in the snmp-server element, has three components:

  • name: a unique name given to the access configuration element (this is the "key" for the configuration, to uniquely identify an allowlisted SNMP source)

  • community: the community string to expect in requests from the requesting SNMP agent, as an authentication mechanism

  • source: the IP address of the allowlisted device

access-control         my-nms-platform
    name       my-nms-platform
    community  public
    source     10.128.201.2
exit
note

Iif you intend on polling the SSR device via one of the managed interfaces (i.e., one that is configured within SSR as a forwarding interface), this will require additional configuration steps. This in turn may affect the source address that the SNMP daemon sees as requests arrive. See the section below on Polling SNMP.

Notification Receiver Configuration​

The notification receiver configuration defines where the SSR will send SNMP information in the event of a system issue. This is configured within notification-receiver in the snmp-server element. Like the access configuration, it too has three components:

  • ip-address: the address of your trap receiver
  • port: the UDP listening port on the trap receiver (typically 162)
  • type: either trap or inform. This determines whether the SSR will send traps or informRequests to the receiver

Because the traps/informRequests are sent by the snmpd process running on the host Linux operating system, it is crucial that the host's routing table is capable of reaching the notification-receiver via the appropriate egress interface. Use the Linux command ip r to review the host's routing table to confirm that it meets your requirements.

SNMP v3 Basic Configuration​

Configuring SNMP on the SSR is done on a per-router basis, and is done within the router > system settings > snmp-server branch of the configuration hierarchy. For SNMPv3 there are now four areas of configuration required: the protocol configuration, the view configuration, the access configuration, and the notification receiver configuration.

Sample Configuration​

snmp-server
    enabled     true
    version     v3
    port        161
    engine-id   testEngineId

    vacm

        view    unrestricted
            name        unrestricted
            included    .1
        exit
    exit

    access-control  Public
        name        Public

        usm
            user-name           testUser
            authentication      sha
            authentication-key  (removed)
            privacy             aes
            privacy-key         (removed)
        exit
        view    unrestricted
    exit

    notification-receiver       172.18.0.230 162 trap
        ip-address              172.18.0.230
        port                    162
        type                    trap
        access-control          Public
    exit
exit

Protocol Configuration​

The protocol configuration requires three settings:

  • Set enabled to true. Enables the SNMP agent on your SSR.
  • Set the protocol to v3.
  • Configure the port on which the SNMP agent will listen for inbound requests; this is typically 161, the well-known port for SNMP agent requests. With SNMP v3, an optional engine-id parameter is available, to uniquely identify the SNMP engine.

View Configuration​

The view-based access control (VACM) configuration is used to define a list of views which serve as the mechanism to allow or restrict which OIDS a user may have access to. Each view has three components, and one hidden component:

  • Name: the view name
  • Included: a list of OIDS which are allowed
  • Excluded: a list of OIDS which are not allowed
  • (hidden) Strict: This is a hidden field. A boolean that defines the use of strict mode when parsing the include and exclude lists. It is set to true by default.

Strict Mode​

Strict mode is enabled by default. The SSR publishes a set of MIBS that define the OIDS available to query and evaluates the include and exclude lists to ensure each OID exists in the available SSR MIBS. If they are not, the configuration is rejected. This serves to restrict the NMS from querying OIDS that may be supported by the underlying operating system of the SSR.

note

Support of system MIBS may vary between SSR versions. Bypassing these checks by disabling strict mode may allow access to MIBs that are no longer supported. Disabling Strict mode is only recommended for advanced users.

Access Configuration​

With SNMPv3 enabled, access configuration allows you to define a User-Based Security Model (USM) as per RFC 3414. The access configuration is configured from within access-control in the snmp-server element, and has three components:

  • Name: Unique name given to the access configuration element (this is the key for the configuration, to uniquely identify an allowlisted SNMP source)
  • USM: The user based security model settings
    • User-name: Name given to the user
    • Authentication: Authentication protocol to use (MD5 or SHA)
    • Authentication-key: Authentication password
    • Privacy: Encryption algorithm (DES or AES)
    • Privacy-key: Encryption password
  • View: Restrict user access to the pre-configured view

Authentication and Encryption​

The SSR combinations of authentication and privacy as defined in the USM configuration are translated into an SNMPv3 security level:

  • noAuthNoPriv: When both authentication and privacy are set to None
  • authNoPriv: When authentication is set to either MD5 or SHA, but privacy is set to None
  • authPriv: When both authentication and privacy are set to anything other than None

These security levels are necessary when performing SNMPv3 operations, and the NMS is responsible for mapping the SSR USM configuration to these security levels.

Notification Receiver Configuration​

The notification receiver configuration defines where the SSR sends SNMP information in the event of a system issue. This is configured under notification-receiver in the snmp-server element. For SNMPv3, there are four configuration elements:

  • ip-address: Address of your trap receiver

  • port: UDP listening port on the trap receiver (typically 162)

  • type: Trap or Inform. Defines whether the SSR sends Traps or Inform Requests to the receiver

  • access-control: References the pre-configured access-control to use, identifies which configured user should handle the notifications, which ensures the appropriate authentication and encryption are used for the communication.

Because the traps/informRequests are sent by the snmpd process running on the host Linux operating system, it is crucial that the host's routing table is capable of reaching the notification-receiver via the appropriate egress interface. Use the Linux command ip r to review the host's routing table to confirm that it meets your requirements.

Traps vs Informs in SNMPv3​

The use of the engine-id parameter is specific to SNMPv3 and traps/informs. SNMP protocol dictates that for traps, the sender (in this case, the SSR) is authoritative, which is to say, the engine-id in use by the SSR will be placed in the messages, and that the companion NMS software will need to define the USM for the sending user with the engine-id of the SSR. In the case of net-snmp being the NMS, the following is an example of how to define SNMPv3 users. This would be placed in the snmptrapd.conf configuration file:

createUser -e <hex encoded engine ID in use by net-snmp on the SSR> testUser SHA password1 AES password2

In the case of Informs, the NMS is authoritative. In this case, the inform message passes along the engine-id of the NMS so that the SSR automatically uses it when sending responses. The SSR will not need to be configured with or have pre-shared knowledge of the engine-id of the NMS.

Polling SNMP​

Once the snmp-server is configured, the SSR device is eligible to be polled for SNMP requests from any source identified in an access-control configuration. Depending on your system architecture, this may require some additional configuration for polling to be successful.

Routing SNMP Responses​

Because the SNMP protocol is handled by a system process running on the host operating system, it is important that your host operating system's routing table has routes suitable for returning responses to inbound queries to the appropriate destination(s) via the appropriate interface. Use the Linux command ip r to review the host operating system's route table, to ensure that snmpd is capable of transmitting responses to inbound polling requests.

note

This also applies to traps sent by the SSR to the notification-receiver.

When sendiing responses via a forwarding interface (as described below), the SSR software manages the Linux routing table rules on your behalf.

Polling via Forwarding Interfaces​

A forwarding interface is one that is identified in your SSR configuration as being managed by the SSR software – generally, this is a device-interface of type ethernet, with a pci-address on your platform's PCI bus. In order to successfully poll an SSR via a forwarding interface, there are several other configuration components required:

  1. A host-service on the network-interface, with type set to custom and transport set to UDP/161 (or whichever port you've specified in your snmp-server configuration).
  2. The host-service should include one or more access-policy statements to allow access by the SNMP polling device(s).
  3. The access-control in the snmp-server should have its source set to 169.254.127.126 instead of the actual address of your SNMP polling server. This is due to the fact that the inbound SNMP requests will arrive at the Linux host operating system via a kernel network interface (KNI), which performs source NAT of the outbound packets sent to snmpd.

Sample Configuration (Via Forwarding Interface)​

snmp-server
    enabled                true
    version                v2c
    port                   162

    access-control         snmp-agent
        name       snmp-agent
        community  public
        source     169.254.127.126
    exit
exit

network-interface
    name                   lan
    description            "LAN"

    inter-router-security  internal

    address                192.168.1.1
        ip-address     192.168.1.1
        prefix-length  24

        host-service   custom
            service-type   custom

            transport      udp
                protocol    udp

                port-range  161
                    start-port  161
                exit
            exit

            access-policy  10.128.201.2/32
                source      10.128.201.2/32
                permission  allow
            exit

            access-policy  blocklist
                source      blocklist
                permission  deny
            exit
        exit
    exit
exit

MIB Layout​

The SSR MIB Database tree is structured as shown in the following diagram:

MIB layout

Note that the SNMP MIB objects only support read-only access (eg: GET, GETNEXT). To configure or alter the system it is necessary to use user-interfaces like PCLI or Web GUI or configuration APIs (eg: NETCONF).

note

The netconf configuration API is not applicable to version 5.3 and later. NETCONF controls have been replaced with REST API controls, with no loss of functionality.

The MIBs are described individually below.

T128-MIB.mib​

The parent T128-MIB defines the overall structure of the MIB and supported products. Only the t128NetworkingPlatform currently exists, however future MIBs may expand this to other SSR products.

T128-ALARM.mib​

The T128-ALARM-MIB defines objects that describes the state of SSR alarms. The MIB also contains definitions for the SNMP trap notifications sent out by the system on event of an alarm being added or cleared.

There are two tables for viewing the current alarm state, t128AlarmTable and t128ShelvedAlarmTable. Each row in this table represents a unique alarm that is active in the system. The t128ShelvedAlarmTable represents alarms that are shelved (for instance if the router is marked as being in maintenance-mode). The t128AlarmTable represents current alarms that are active and not shelved. The key for each row is an instance identifier string, either t128AlarmTableInstanceId or t128ShelvedAlarmTableInstanceId depending on which table the alarm resides. This string can be used to indicate a specific instance of an alarm, for example "Interface operationally down on eth0", which would be a different instance than a "Interface operationally down on dpdk1" alarm. This instance identifier should be considered an opaque string (i.e. the contents have no meaning other than that for each alarm this string is garaunteed to be unique).

note

The opaque instance identifiers are currently implemented as hex strings however the implementation may change from release to release so the exact content should not be relied on.

The t128AlarmNotification definition defines the alarm trap sent out by the system and contains the relevant objects to describe the alarm (e.g. source node and router, severity, alarm message, etc). The trap will also contain a unique t128AlarmInstanceId that can be used to correlate the alarm with the t128AlarmTable and t128ShelvedAlarmTable instance identifiers. If an alarm moves from a shelved to unshelved state or vice versa the instance ID will remain the same.

T128-METRICS.mib​

The T128-METRICS-MIB provides SNMP access to the expansive set of metrics provided by the SSR product which are exposed via the t128MetricsTable.

Each row of the metrics table is keyed by two objects, the t128MetricAlias and the t128MetricIndex. The t128MetricAlias is an arbitrary string up to 64 characters long that represents a description of the metric. When read from the table, this alias also includes a metric instance suffix which in the most common case will be _0. For example, if the default CPU utlization metric has an alias cpuUtilization, it will be returned as cpuUtilization_0. In addition to the alias, the t128MetricIndex key represents a unique series of a metric.

The values contained in each row are the t128MetricValue and t128MetricContributors objects. The t128MetricValue is simply the current value of the metric. The unique parameters that identify each data series are referred to as "contributors". For the CPU metric, the contributors are router, node, and core. The t128MetricContributors object will contain a string representation of these values so that each row can be correlated with the correct metric data series.

Below is an example of an SNMP query of the t128MetricsTable showing the 4 rows returned for each CPU utilization data series:

snmptable -Cl -Ci -mALL -v2c -c public 172.18.1.55 T128-METRICS-MIB::t128MetricsTable

SNMP table: T128-METRICS-MIB::t128MetricsTable

index                   t128MetricContributors    t128MetricValue
"cpuUtilization_0".0    Fabric128.test1.3         5
"cpuUtilization_0".1    Fabric128.test1.2         2
"cpuUtilization_0".2    Fabric128.test1.1         100
"cpuUtilization_0".3    Fabric128.test1.0         4

Note that in this example the router name is "Fabric128", the node is called "test1" and the CPU cores are 0, 1, 2 and 3. This can be clearly seen in the t128MetricContributors column, eg: "Fabric128.test1.0".

The metrics table can be configured to contain any of the SSR metrics that can be exposed via SNMP however this is an advanced feature and is outside the scope of this document. By default a small set of the most useful metrics are configured in the t128MetricsTable.

T128-SYSTEM.mib​

The T128-SYSTEM-MIB contains objects to describe the running state of the local SSR system.

The local node and router name, role and asset-id objects (t128RouterName, t128NodeName, t128NodeRole and t128AssetId) can be used to identify the system. The values of these parameters will match those in the SSR system configuration.

There are several processes running on the system that comprise the SSR product. The table t128ProcessTable provides details about these processes, for instance whether they are running or, if applicable, are assuming a leadership role. The key for the table rows is the process name, for example "nodeMonitor".

Footnotes​

  1. https://en.wikipedia.org/wiki/Simple_Network_Management_Protocol ↩