close

keyboard_arrow_left

Table of Contents Expand all

play_arrow Overview
play_arrow Initial Configuration
- Initial Configuration on NFX150 Devices
- Zero Touch Provisioning on NFX Series Devices
play_arrow Generating YANG Files
- YANG files on NFX150 Devices
play_arrow Configuring Interfaces
play_arrow Configuring USB Pass-Through on NFX Series Devices
- Supporting File Transfer from USB on NFX Series Devices
- Installing Software on NFX Devices Using USB Autoinstallation
play_arrow Configuring Security
play_arrow Configuring VNFs
play_arrow Configuring Mapping of Address and Port with Encapsulation (MAP-E)
- Mapping of Address and Port with Encapsulation on NFX Series Devices
- Configuring MAP-E on NFX Series Devices
play_arrow Configuring High Availability
- Chassis Cluster on NFX150 Devices
- Upgrading or Disabling a Chassis Cluster on NFX150 Devices
play_arrow Configuring Service Chaining
play_arrow Monitoring and Troubleshooting
play_arrow Configuration Statements and Operational Commands
- Junos CLI Reference Overview

list Table of Contents

English

Configuring SNMP on NFX150, NFX250 NextGen, and NFX350 Devices

date_range 24-Nov-23

arrow_backward

arrow_forward

SNMP monitors network devices from a central location. NFX Series (NFX150, NFX250 NextGen, and NFX350) devices support querying of MIB data by using SNMPv2c and SNMPv3. Separate SNMP agents (known as the SNMP process or snmpd) reside on the vjunos0 and Host OS. The vjunos0 acts as the proxy for the Host OS. The system and chassis related MIB data is available in vjunos0.

Starting in Junos OS Release 21.4R1, NFX Series devices support LM-SENSORS-MIB, ENTITY-SENSORS-MIB, and libvirt MIB. The LM-SENSORS-MIB and ENTITY-SENSORS-MIB data is available on vjunos0 whereas the libvirt MIB data is available on the Host OS. You can use the libvirt MIB to monitor virtual machines. This topic discusses the SNMP implementation for the libvirt MIB.

How to Configure SNMPv2c to Access Libvirt MIB Data

SNMPv2c uses community strings, which act as passwords when determining the SNMP clients and how clients can access the data in the SNMP agent. The community string is not pre-configured on NFX Series devices. To access MIBs data using SNMPv2c, you must configure a community string and an SNMP proxy for the Host OS. The community string is added to the Host OS.

Figure 1 illustrates the communication flow for SNMPv2c on NFX Series devices.

Figure 1: Communication Flow for SNMPv2c on NFX Series Devices

When a user issues SNMP commands like snmpwalk, snmpget with the community string from the network management server:

The request goes to the SNMP daemon in vjunos0. The SNMPD reads the community string in the SNMP request and redirects the request to the Host OS using the internal routing instance nfx-host.
The SNMPD in the Host OS processes the request and sends the response to vjunos0, which then sends it to the network management server.

To configure SNMPv2c:

Configure the SNMPv2c community string in the Host OS:
```
root@host# set vmhost snmp v2c community community-name 
```
Note:
Ensure that a community with the same name does not already exist on the device.

Configure the proxy in vjunos0:

content_copy zoom_out_map
root@host# set snmp proxy snmp-proxy-name device-name 192.168.1.1 
root@host# set snmp proxy snmp-proxy-name version-v2c snmp-community community-name
root@host# set snmp proxy snmp-proxy-name nfx-host

To enable traps, see How to Enable libvirt SNMPv2c Trap Support.

How to Configure SNMPv3 to Access Libvirt MIB Data

SNMPv3 provides a secure way to access MIB data as it supports authentication and encryption. SNMPv3 uses the user-based security model (USM) for message security and the view-based access control model (VACM) for access control. USM specifies authentication and encryption, and VACM specifies access-control rules. Figure 2 illustrates the communication flow for SNMPv3 on NFX Series devices. For SNMPv3, you must create:

An SNMPv3 user under the vmhost hierarchy in Host OS with the authentication type and privacy
An SNMPv3 proxy with the user name and context

Figure 2: Communication Flow for SNMPv3 on NFX Series Devices

When a user issues SNMP commands like (snmpwalk, snmpget) with the user name and authentication credentials from the network management server:

The request goes to the SNMP daemon in vjunos0. The SNMPD reads the context for the Host OS in the SNMP request and redirects the request to the Host OS using the internal routing instance nfx-host.
The SNMPD in the Host OS processes the request and sends the response to vjunos0, which then sends it to the network management server.

To configure SNMPv3:

Configure the local engine information for USM:

content_copy zoom_out_map
root@host# set snmp v3 usm local-engine user snmpv3-user-name  authentication-type authentication-password Authentication_Password
root@host# set snmp v3 usm local-engine user snmpv3-user-name  privacy-type privacy-password Privacy_Password

Configure the remote engine and remote user. You must configure the remote-engine id as 80001f8804686f7374. The remote engine ID is used to compute the security digest for authenticating and encrypting packets sent to a user on the remote host. When sending an inform message, the agent uses the credentials of the user configured on the remote engine (inform target).
```
root@host# set snmp v3 usm remote-engine 80001f8804686f7374 user snmpv3-user-name authentication-type authentication-password Authentication_Password
root@host# set snmp v3 usm remote-engine 80001f8804686f7374 user snmpv3-user-name  privacy-type privacy-password Privacy_Password
```

Configure VACM:

content_copy zoom_out_map
root@host# set snmp v3 vacm security-to-group security-model usm security-name snmpv3-user-name  group Group-Name
root@host# set snmp v3 vacm access group Group-Name context-prefix snmpv3-context-name security-model usm security-level authentication read-view iso

Configure SNMPv3 on the Host OS:

content_copy zoom_out_map
root@host# set vmhost snmp v3 user snmpv3-user-name authentication-type authentication-password Authentication_Password 
root@host# set vmhost snmp v3 user snmpv3-user-name privacy-type privacy-password Privacy_Password

Configure SNMP v3 proxy:

content_copy zoom_out_map
root@host# set snmp proxy snmpv3-proxy-name device-name 192.168.1.1
root@host# set snmp proxy snmpv3-proxy-name version-v3 security-name snmpv3-user-name
root@host# set snmp proxy snmpv3-proxy-name version-v3 context snmpv3-context-name
root@host# set snmp proxy snmpv3-proxy-name nfx-host

To enable traps, see How to Enable libvirt SNMPv3 Trap Support.

How to Query Libvirt MIB Data

You can use the snmpget, snmpgetnext, and snmpwalk commands to read the MIB information. Note that you cannot use snmpset to configure the libvirt MIB.

The libvirt MIB provides the following information:

Name of active virtual guest (domain name)
Current state of the active guest (state of domain)
Number of virtual CPUs the virtual guest uses (cpu count defined for domain)
Current amount of memory (in MiB) used by the virtual guest (current allocated memory)
Memory limit for the domain (the maximum amount of memory (in MiB) that can be used by the virtual guest)
CPU time used by the virtual guest, in nanoseconds (CPU time)
Status of the virtual guest (row status)

The following are sample outputs of the snmpwalk command when you execute it on NMS:

SNMPv2c:

content_copy zoom_out_map
nms_server# snmpwalk -v2c -Obs -c community-name device_A LIBVIRT-MIB::libvirtMIB
libvirtGuestName.51.145.57.25.141.222.70.137.181.75.129.190.178.93.132.174 = STRING: "centos1"
libvirtGuestName.170.187.204.221.238.255.66.227.0.0.86.74.85.78.79.83 = STRING: "vjunos0"
libvirtGuestState.51.145.57.25.141.222.70.137.181.75.129.190.178.93.132.174 = INTEGER: running(1)
libvirtGuestState.170.187.204.221.238.255.66.227.0.0.86.74.85.78.79.83 = INTEGER: running(1)
libvirtGuestCpuCount.51.145.57.25.141.222.70.137.181.75.129.190.178.93.132.174 = Gauge32: 1
libvirtGuestCpuCount.170.187.204.221.238.255.66.227.0.0.86.74.85.78.79.83 = Gauge32: 1
libvirtGuestMemoryCurrent.51.145.57.25.141.222.70.137.181.75.129.190.178.93.132.174 = Gauge32: 512
libvirtGuestMemoryCurrent.170.187.204.221.238.255.66.227.0.0.86.74.85.78.79.83 = Gauge32: 1954
libvirtGuestMemoryLimit.51.145.57.25.141.222.70.137.181.75.129.190.178.93.132.174 = Gauge32: 512
libvirtGuestMemoryLimit.170.187.204.221.238.255.66.227.0.0.86.74.85.78.79.83 = Gauge32: 1954
libvirtGuestCpuTime.51.145.57.25.141.222.70.137.181.75.129.190.178.93.132.174 = Counter64: 12430000000
libvirtGuestCpuTime.170.187.204.221.238.255.66.227.0.0.86.74.85.78.79.83 = Counter64: 808830000000
libvirtGuestRowStatus.51.145.57.25.141.222.70.137.181.75.129.190.178.93.132.174 = INTEGER: active(1)
libvirtGuestRowStatus.170.187.204.221.238.255.66.227.0.0.86.74.85.78.79.83 = INTEGER: active(1)
libvirtGuestRowStatus.170.187.204.221.238.255.66.227.0.0.86.74.85.78.79.83 = No more variables left in this MIB View (It is past the end of the MIB tree)

SNMPv3:

content_copy zoom_out_map
nms-server# snmpwalk -Obs -v3 -a authentication-type -A Authentication_Password -x privacy-type -X Privacy-Password -l authPriv-level -u snmpv3-user-name -n snmpv3-context-name device_B LIBVIRT-MIB::libvirtMIB
libvirtGuestName.170.187.204.221.238.255.66.227.0.0.86.74.85.78.79.83 = STRING: "vjunos0"
libvirtGuestName.185.178.34.217.212.63.76.189.191.225.54.201.166.88.167.118 = STRING: "vnf0"
libvirtGuestState.170.187.204.221.238.255.66.227.0.0.86.74.85.78.79.83 = INTEGER: running(1)
libvirtGuestState.185.178.34.217.212.63.76.189.191.225.54.201.166.88.167.118 = INTEGER: running(1)
libvirtGuestCpuCount.170.187.204.221.238.255.66.227.0.0.86.74.85.78.79.83 = Gauge32: 1
libvirtGuestCpuCount.185.178.34.217.212.63.76.189.191.225.54.201.166.88.167.118 = Gauge32: 1
libvirtGuestMemoryCurrent.170.187.204.221.238.255.66.227.0.0.86.74.85.78.79.83 = Gauge32: 1954
libvirtGuestMemoryCurrent.185.178.34.217.212.63.76.189.191.225.54.201.166.88.167.118 = Gauge32: 512
libvirtGuestMemoryLimit.170.187.204.221.238.255.66.227.0.0.86.74.85.78.79.83 = Gauge32: 1954
libvirtGuestMemoryLimit.185.178.34.217.212.63.76.189.191.225.54.201.166.88.167.118 = Gauge32: 512
libvirtGuestCpuTime.170.187.204.221.238.255.66.227.0.0.86.74.85.78.79.83 = Counter64: 959760000000
libvirtGuestCpuTime.185.178.34.217.212.63.76.189.191.225.54.201.166.88.167.118 = Counter64: 19830000000
libvirtGuestRowStatus.170.187.204.221.238.255.66.227.0.0.86.74.85.78.79.83 = INTEGER: active(1)
libvirtGuestRowStatus.185.178.34.217.212.63.76.189.191.225.54.201.166.88.167.118 = INTEGER: active(1)

The following is a sample output of the snmpwalk command when you exexute it on the NFX Series device:

content_copy zoom_out_map
root@host> show vmhost snmp mib walk LIBVIRT-MIB::libvirtMIB
LIBVIRT-MIB::libvirtGuestName[STRING: 33913919-8dde-4689-b54b-81beb25d84ae] = STRING: "centos1"
LIBVIRT-MIB::libvirtGuestName[STRING: aabbccdd-eeff-42e3-0-564a554e4f53] = STRING: "vjunos0"
LIBVIRT-MIB::libvirtGuestState[STRING: 33913919-8dde-4689-b54b-81beb25d84ae] = INTEGER: running(1)
LIBVIRT-MIB::libvirtGuestState[STRING: aabbccdd-eeff-42e3-0-564a554e4f53] = INTEGER: running(1)
LIBVIRT-MIB::libvirtGuestCpuCount[STRING: 33913919-8dde-4689-b54b-81beb25d84ae] = Gauge32: 1
LIBVIRT-MIB::libvirtGuestCpuCount[STRING: aabbccdd-eeff-42e3-0-564a554e4f53] = Gauge32: 1
LIBVIRT-MIB::libvirtGuestMemoryCurrent[STRING: 33913919-8dde-4689-b54b-81beb25d84ae] = Gauge32: 512
LIBVIRT-MIB::libvirtGuestMemoryCurrent[STRING: aabbccdd-eeff-42e3-0-564a554e4f53] = Gauge32: 1954
LIBVIRT-MIB::libvirtGuestMemoryLimit[STRING: 33913919-8dde-4689-b54b-81beb25d84ae] = Gauge32: 512
LIBVIRT-MIB::libvirtGuestMemoryLimit[STRING: aabbccdd-eeff-42e3-0-564a554e4f53] = Gauge32: 1954
LIBVIRT-MIB::libvirtGuestCpuTime[STRING: 33913919-8dde-4689-b54b-81beb25d84ae] = Counter64: 12300000000
LIBVIRT-MIB::libvirtGuestCpuTime[STRING: aabbccdd-eeff-42e3-0-564a554e4f53] = Counter64: 734900000000
LIBVIRT-MIB::libvirtGuestRowStatus[STRING: 33913919-8dde-4689-b54b-81beb25d84ae] = INTEGER: active(1)
LIBVIRT-MIB::libvirtGuestRowStatus[STRING: aabbccdd-eeff-42e3-0-564a554e4f53] = INTEGER: active(1)

Supported Chassis MIBs and Traps

NFX Series devices support the following chassis MIBs:

jnxFruContentsIndex
jnxFruL1Index
jnxFruL2Index
jnxFruL3Index
jnxFruName
jnxFruType
jnxFruSlot
jnxFruTemp
jnxFruOfflineReason
jnxFruLastPowerOff
jnxFruLastPowerOn
jnxFruPowerUpTime
jnxFruChassisId
jnxFruChassisDescr
jnxFruPsdAssignment

NFX Series devices support the following traps:

jnxFanFailure
jnxFanOK
jnxPowerSupplyFailure
jnxPowerSupplyOK
jnxOverTemperature
jnxTemperatureOK
jnxPowerSupplyRemoved (only for NFX350)

Supported libvirt MIB Traps

The libvirt MIB monitors the virtual machines and sends asynchronous traps to the network management server. For example, if a domain (VNF) crashes unexpectedly, a notification is sent to the network management server. The traps are generated in the Host OS and sent to the snmptrapd daemon on vjunos0. The snmptrapd daemon forwards the traps to the network management server.

The libvirt trap has the following definition structure:

content_copy zoom_out_map
libvirtGuestNotif NOTIFICATION-TYPE
      OBJECTS { libvirtGuestName,
                  libvirtGuestUUID,
                  libvirtGuestState,
                   libvirtGuestRowStatus }
          STATUS current
          DESCRIPTION
             "Guest lifecycle notification."
          ::= { libvirtNotifications 1 }

Here is a sample output of an snmp libvirt trap:

content_copy zoom_out_map
SNMPv2-MIB::snmpTrapOID.0 = OID: LIBVIRT-MIB::libvirtGuestNotif,
 LIBVIRT-MIB::libvirtGuestName.0 = STRING: "test1",
 LIBVIRT-MIB::libvirtGuestUUID.1 = STRING: 7ad4bc2a-16db-d8c0-1f5a-6cb777e17cd8,
 LIBVIRT-MIB::libvirtGuestState.2 = INTEGER: running(1),
 LIBVIRT-MIB::libvirtGuestRowStatus.3 = INTEGER: active(1)

The current state of the active guest can be one of the following:

running(1)
blocked(2)
paused(3)
shutdown(4)
shutoff(5)
crashed(6)

How to Enable libvirt SNMPv2c Trap Support
How to Enable libvirt SNMPv3 Trap Support

How to Enable libvirt SNMPv2c Trap Support

To enable SNMPv2c trap support:

Configure the community name for the trap:

content_copy zoom_out_map
root@host# set vmhost snmp v2c-trap trap-community community-name

Configure the client-address, which is the source address from which the trap originates. If you do not configure the source address, the hypervisor address (192.168.1.1) is used as the client address.
```
root@host# set vmhost snmp client-address client-ip
```
Configure port-forwarding. You can configure multiple IP adresses.
```
root@host#  set forwarding-options helpers port 162 server IP-address-of-trap-target
```

How to Enable libvirt SNMPv3 Trap Support

To enable SNMPv3 trap support:

Configure the user name for the trap:
```
root@host# set vmhost snmp v3-trap trap-user user-name
```
Configure the client-address, which is the source address from which the trap originates. If you do not configure the source address, the hypervisor address (192.168.1.1) is used as the client address.
```
root@host# set vmhost snmp client-address client-ip
```

Configure the AES and SHA passwords for the user:

content_copy zoom_out_map
root@host# set vmhost snmp v3 user user-name authentication-sha authentication-password password
root@host# set vmhost snmp v3 user user-name privacy-aes128 privacy-password password

Configure port-forwarding for libVirtMIB trap support. You can configure multiple IP adresses.
```
root@host#  set forwarding-options helpers port 162 server IP-address-of-trap-target
```

arrow_backward PREVIOUS Example: Configuring Cross-Connect Using a Custom Bridge on NFX150 Devices

NEXT arrow_forward Monitor NFX150 Device Health

How to Configure the NFX150

ON THIS PAGE