CENTAURI | Monitoring with SNMP Proxy

TABLE OF CONTENTS

• Overview
• SNMP Proxy Architecture
• Installation Pre-Requisites
• Installation and Setup

Overview

The Transcelestial SNMP Proxy is a component that makes monitoring a fleet of CENTAURI devices easier by orchestrating SNMP requests from a Network Management System (NMS) through to the various devices being monitored. Use of SNMP proxy may be preferred in situations where many CENTAURI devices need to be monitored together, and it is not considered necessary to connect an NMS directly to every CENTAURI device.

In situations where direct connections to devices are desired, it is not necessary to use the SNMP Proxy. Refer to the CENTAURI Product Manual for instructions for setting up SNMP for an individual CENTAURI device.

Configuration Files

implementation of SNMP Proxy services requires coordination and assistance from Transcelestial. To learn more and to get the latest configuration files for use in setting up SNMP proxy for your CENTAURI deployment, please contact us. 

SNMP Proxy Architecture

The Centauri device uses net-snmp which is a standard implementation for Linux. Transcelestial has extended net-snmp to provide a MIB for CENTAURI which adds three new objects:

• TX Power
• RX Power
• Link Status

The Transcelestial SNMP Proxy will integrate to the snmpd daemon running on a CENTAURI device, and does not require any changes or additional configuration to the device setup. It will rely on SNMP V3 authentication to the device and standard SNMP get requests.

The Proxy architecture is illustrated as follows:

The SNMP Proxy is a Linux VM running in the customer's network with VPN connectivity to only the CENTAURI devices it should have access to. The Proxy will run on Linux with a suitably configured net-snmp.

As a design decision, only SNMP V3 GET will be supported from the Proxy to the CENTAURI devices. SNMP V1 or V2 requests will be not be enabled as these versions of SNMP do not support authentication and authorisation.

For the link between the customer NMS and the SNMP Proxy, SNMP V3 Get requests are strongly preferred, though the use of SNMP V1/V2c is possible. It is assumed that the client will set up a secure network between the NMS and the SNMP Proxy VM where V1/V2 is required.

Handling Overlapping OID’s

Usually, the net-snmp proxy will act as the proxy for a single device. This means that an SNMP Get for an OID is forwarded directly to the device. Where it is acting as a proxy for many devices that have the same OID tree (as is the case with CENTAURI devices) the proxy requires an additional field to know which device to forward the request to.

For SNMP V3 requests this is straightforward, as the protocol allows for a context field to be supplied. The context field will need to be set to the CENTAURI device serial number (for example, CENXXXXXXXX), and the proxy will use this information to route SNMP requests to the correct device.

For SNMP V1 and V2 Get requests a context field is not supported. For V1 and V2 the community string in the request will need to be set to the device serial number, and the proxy will use this to map the request to the correct device, instead. 

Monitoring the Proxy VM

It is also required to monitor the VM running the proxy and to integrate this to the customer NMS, along with the CENTAURI devices. The SNMP Proxy agent is able to monitor the VM it is running on as well as the proxied devices.

To obtain VM monitoring details, sending an SNMP V3 Get request with the default (empty) context will return the VM specific details. For SNMP V1/V2, if the default community string is used it will return details on the proxy VM. The default community string is set in the snmpd.conf file.

Installation Pre-Requisites

Knowledge

For installation and setup, we assume that you have a working understanding of SNMP, Linux (any of the main distributions) and an understanding of network concepts.

Implementation of the SNMP proxy will also require an understanding of how to configure the NMS intended for use with the SNMP proxy. Transcelestial uses net-snmp on the proxy server. Details regarding net-snmp are available at Net-SNMP.org.

Environment

For installation and setup, we assume that a Linux VM is up and running. Any of the common Linux distributions will work, including Redhat, CentOS, Debian, Ubuntu, and so on. Below, we have provided details for an instance sized to support monitoring up to 50 CENTAURI links (100 devices).

Storage disk requirements for the VM are mainly driven by requirements for log files and how much historical data must be stored. The proxy itself uses minimal disk space. 10GB of disk space is considered ample for storing and rotating of logs.

CPU and memory requirements are mainly driven by the frequency of updates required, or how often you need to poll the CENTAURI devices. In our example we assume the polling frequency to be 5 minutes. This translates to requirements of 1xVCPU and a memory requirement of 4GB RAM.

Network

The SNMP Proxy acts as a gateway device that bridges a connection for two separate networks.

It will be connected to a client-specific network to allow connectivity with the target NMS, and it will be connected to a second network that allows for connectivity to CENTAURI devices.

The configuration of this network is beyond the scope of this document. The creation of the appropriate networks and the setup and management of associated security measures requires a joint Client/Transcelestial network design and implementation.

The installation steps laid out below assume that this network configuration has been set up and that the SNMP Proxy VM will have connectivity to both networks.

SNMP Version, Context, and Credentials

Prior to deployment, a decision will be required as to which version of SNMP will be used between the Client NMS system and the SNMP Proxy.

We strongly recommend the use of SNMP V3, as this version differs from SNMP V1/V2c with security in the form of authentication and authorisation, as well as privacy (encryption) for data exchange.

For the proxy to know which device is to receive the request from the NMS it uses the V3 context string in the request. While many NMS systems support V3, they do not always support the setting of a V3 context. Where the client-side NMSSS does not support context, SNMP V1/V2c will need to be used. For SNMP V1/V2c the community string is used to identify the target device.

The configuration of the proxy also requires SNMP V3 credentials for each of the CENTAURI devices that the proxy will connect to. The detail needed is:

• Hostname or IP
• Auth User Name
• Auth Password
• Privacy Password

For V3, the Authorisation Algorithm is SHA and the Privacy Algorithm is AES. The detailed login credentials will be supplied by Transcelestial's CENTAURI Network Administrator, upon request.

Installation and Setup

The first step in the installation is to ensure that net-snmp is installed on the proxy server. The installation requires root privileges and the steps for this are:

1. Install SNMP
   • Debian/Ubuntu:

     • apt install snmpd snmp

   • Redhat/CentOS

     • yum install net-snmp net-snmp-libs net-snmp-utils

2. Copy template snmpd.conf file
   • If SNMP V1/V2c is to be used, with root priveleges copy the V1/V2c template file snmpd.conf.v1_v2 (attached) to /etc/snmp/snmpd.conf
   • If SNMP V3 is to be used, with root priveleges copy the V3 template file snmp.conf.v3 (attached) to /etc/snmp/snmpd.conf
3. Configure /etc/snmp/snmpd.conf
   • Instructions for adding the CENTAURI device details are provided in the snmpd.conf template files
   • When complete with the configuration changes:

     • chmod 0600 /etc/snmp/snmpd.conf

4. Restart the SNMP proxy service 
   • Restarting the SNMP proxy service will allow it to pick up the new configuration.
   • With root privileges:

     • /etc/init.d/snmpd restart