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. It is specified in RFC 1157.

Configuring SNMPv2

This example creates an SNMP configuration:

  • with contact and location static information.

  • it adds a community called public, which is used for SNMP requests. This community has read-only access to the network information.

  • only SNMP requests from the 10.0.0.0/24 network are accepted.

  • traps are sent to address 10.0.0.200 when SNMP processes start, when network links change and when CPU load exceeds 95%. The trap source address is set to 10.10.0.1.

vsr running config# vrf main snmp
vsr running snmp# static-info contact oam@my-company.com
vsr running snmp# static-info location "Santa Barbara"
vsr running snmp# community public authorization read-only source 10.0.0.0/24
vsr running snmp# traps destination 10.0.0.200 source 10.10.0.1 notification-type TRAP2 community public
vsr running snmp# traps process-check
vsr running snmp# traps link-status-check
vsr running snmp# traps load-check threshold 95
vsr running snmp# interface-ignore dsvti
vsr running snmp# /
vsr running config# commit
Configuration committed.

To display the current SNMP state:

vsr running config# show state vrf main snmp
snmp
    enabled true
    static-info
        location "Copacabana, Rio de Janeiro"
        contact oam@my-company.com
        ..
    community public
        source 10.0.0.0/24
        authorization read-only
        ..
    interface-ignore dsvti
    traps
        destination 10.0.0.200 source 10.10.0.1 community public port 162 notification-type TRAP2
        link-status-check enabled true frequency 60s
        process-check enabled true frequency 2s
        load-check enabled true threshold 95
        ..
    ..

The same configuration can be made using this NETCONF XML request:

vsr running config# show config xml absolute vrf main snmp
<config xmlns="urn:6wind:vrouter">
  <vrf>
    <name>main</name>
    <snmp xmlns="urn:6wind:vrouter/snmp">
      <static-info>
        <contact>oam@my-company.com</contact>
        <location>Copacabana, Rio de Janeiro</location>
      </static-info>
      <ignore-interface>dsvti</ignore-interface>
      <traps>
        <destination>
          <host>10.0.0.200</host>
          <source>10.10.0.1</source>
          <notification-type>TRAP2</notification-type>
          <community>public</community>
          <port>162</port>
        </destination>
        <process-check>
          <frequency>2s</frequency>
          <enabled>true</enabled>
        </process-check>
        <link-status-check>
          <frequency>60s</frequency>
          <enabled>true</enabled>
        </link-status-check>
        <load-check>
          <threshold>95</threshold>
          <enabled>true</enabled>
        </load-check>
      </traps>
      <community>
        <name>public</name>
        <authorization>read-only</authorization>
        <source>10.0.0.0/24</source>
      </community>
    </snmp>
  </vrf>
</config>

Monitoring several VRFs

Monitoring different VRFs relies on a master VRF that provides access to the management network. Slave VRFs (that don’t have access to the management network) are linked to the master VRF.

To link a slave VRF:

  • add it to the list of monitored VRFs in the SNMP context of the master VRF,

  • configure an identifier for the slave VRF, which will act as a community for SNMP v1, v2c and traps.

Here is a configuration example to link VRF vrf1 with identifier id1 to VRF main:

vsr running config# vrf vrf1 snmp enabled false
vsr running config# vrf main snmp
vsr running snmp# community public authorization read-only source 10.0.0.0/24
vsr running snmp# traps destination 10.0.0.200 notification-type TRAP2 community public
vsr running snmp# traps process-check
vsr running snmp# traps link-status-check
vsr running snmp# traps load-check threshold 95
vsr running snmp# monitored-vrf vrf1
vsr running monitored-vrf vrf1# identifier id1 authorization read-only source 10.0.0.0/24
vsr running monitored-vrf vrf1# traps destination 10.0.0.200 community id1
vsr running monitored-vrf vrf1# commit
Configuration committed.

Note

  • When a VRF is linked to another one, its SNMP context must be disabled.

The same configuration can be made using this NETCONF XML request:

vsr running config# show config xml absolute vrf slave snmp
<config xmlns="urn:6wind:vrouter">
  <vrf>
    <name>slave</name>
    <snmp xmlns="urn:6wind:vrouter/snmp">
      <enabled>false</enabled>
      <static-info/>
      <access-control/>
      <traps/>
    </snmp>
  </vrf>
</config>
vsr running config# show config xml absolute vrf main snmp
<config xmlns="urn:6wind:vrouter">
  <vrf>
    <name>main</name>
    <snmp xmlns="urn:6wind:vrouter/snmp">
      <enabled>true</enabled>
      <static-info>
        <contact>oam@my-company.com</contact>
        <location>Santa Barbara</location>
      </static-info>
      <access-control>
        <user>
          <name>alice</name>
          <auth-password>Password</auth-password>
          <auth-method>sha</auth-method>
          <priv-protocol>aes</priv-protocol>
        </user>
        <group>
          <name>admin</name>
          <user>alice</user>
          <authorization>read-write</authorization>
          <security-level>auth</security-level>
        </group>
      </access-control>
      <traps>
        <destination>
          <host>10.0.0.200</host>
          <notification-type>TRAP2</notification-type>
          <community>public</community>
          <port>162</port>
          <protocol>udp</protocol>
        </destination>
        <process-check>
          <frequency>2s</frequency>
          <enabled>true</enabled>
        </process-check>
        <link-status-check>
          <frequency>60s</frequency>
          <enabled>true</enabled>
        </link-status-check>
        <load-check>
          <threshold>95</threshold>
          <enabled>true</enabled>
        </load-check>
      </traps>
      <community>
        <name>public</name>
        <authorization>read-only</authorization>
        <source>10.0.0.0/24</source>
      </community>
      <monitored-vrf>
        <name>slave</name>
        <traps>
          <destination>
            <host>10.0.0.200</host>
            <community>private</community>
          </destination>
        </traps>
        <identifier>
          <name>private</name>
          <authorization>read-only</authorization>
          <source>10.0.0.0/24</source>
        </identifier>
      </monitored-vrf>
    </snmp>
  </vrf>
</config>

snmp requests

Then SNMP information of the slave VRFs can be retrieved through the community parameter for SNMP v1 and v2.

Here are some SNMP request examples with the configuration example above, assuming that:

  • the SNMP server is listening on 10.0.0.2,

  • the main VRF has 3 interfaces, the second one being called mgmt,

  • the vrf1 VRF has 2 interfaces, the second one being called eth_out.

SNMP requests on main VRF:

# snmpwalk -Ovq -v 2c -c public 10.0.0.2 IF-MIB::ifIndex
1
2
3

# snmpget -Ovq -v 2c -c public 10.0.0.2 IF-MIB::ifName.2
mgmt

SNMP requests on vrf1 VRF:

# snmpwalk -Ovq -v 2c -c id1 10.0.0.2 IF-MIB::ifIndex
1
2

# snmpget -Ovq -v 2c -c id1 10.0.0.2 IF-MIB::ifName.2
eth_out

snmp traps

The SNMP traps from the different VRFs can be distinguished thanks to the community name.

Here is a snmptrapd configuration example, using the public community for trap events from the main VRF and the id1 community for the vrf1 VRF.

/etc/snmp/snmptrapd.conf:

# Log trap from public and vrf1 communities
authCommunity log public
authCommunity log id1
# override default format for TRAP2 to display the community information (%P option)
format print2 %.4y-%.2m-%.2l %.2h:%.2j:%.2k %P %B [%b]:\n%v\n

Start the snmptrapd daemon and log the trap events into /tmp/snmptrapd.log.

# snmptrapd -Lf /tmp/snmptrapd.log

Here are some log examples when interfaces get down in the vrf1 and main VRFs.

# cat /tmp/snmptrapd.log
2019-12-10 10:38:44 TRAP2, SNMP v2c, community id1 <UNKNOWN> [UDP: [10.0.0.2]:42616->[10.0.0.200]:162]:
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (8205) 0:01:22.05      SNMPv2-MIB::snmpTrapOID.0 = OID: IF-MIB::linkDown       IF-MIB::ifIndex.2 = INTEGER: 2      IF-MIB::ifAdminStatus.2 = INTEGER: down(2)      IF-MIB::ifOperStatus.2 = INTEGER: down(2)       SNMPv2-MIB::snmpTrapEnterprise.0 = OID: NET-SNMP-MIB::netSnmpAgentOIDs.10
2019-12-10 10:41:04 TRAP2, SNMP v2c, community public <UNKNOWN> [UDP: [10.0.0.2]:51157->[10.0.0.200]:162]:
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (22211) 0:03:42.11     SNMPv2-MIB::snmpTrapOID.0 = OID: IF-MIB::linkDown       IF-MIB::ifIndex.2 = INTEGER: 2      IF-MIB::ifAdminStatus.2 = INTEGER: down(2)      IF-MIB::ifOperStatus.2 = INTEGER: down(2)       SNMPv2-MIB::snmpTrapEnterprise.0 = OID: NET-SNMP-MIB::netSnmpAgentOIDs.10

See also

The SNMP command reference for details.

Configuring SNMPv3

This example creates an SNMP v3 configuration:

  • it configures an engine-id that will be built from the string “test”. Each SNMP entity has an engine-id. If it is not configured, by default, it will be determined by a (pseudo-)random number and the current time in seconds.

  • it inserts a user called alice with the engine-id for the given SNMP entity in the user database.

  • it inserts a second user called tusr1 with a specified engine-id 0x80001CA8003677696E64 in the user database. engine-id is used to manage an SNMP module, and uniquely identifies an SNMP entity in a management domain. The 2 users have read-write access to the network information. They both use the default auth-method SHA.

  • traps are sent to address 10.0.0.200 when SNMP processes are started, when network interfaces change and when CPU load exceeds 95%.

vsr running config# vrf main snmp
vsr running snmp# engine-id text test
vsr running snmp# access-control user alice auth-password Password
vsr running snmp# access-control user tusr1 auth-password Password engine-id 0x80001CA8003677696E64
vsr running snmp# access-control group admin user alice authorization read-write security-level auth
vsr running snmp# access-control group admin user tusr1 authorization read-write security-level auth
vsr running snmp# traps destination 10.0.0.200 notification-type TRAP3 user tusr1
vsr running snmp# traps process-check
vsr running snmp# traps link-status-check
vsr running snmp# traps load-check threshold 95
vsr running snmp# /
vsr running config# commit
Configuration committed.

Note

  • Users for SNMP v3 traps must have an engine-id.

  • Users for SNMP v3 informs must not have an engine-id.

Monitoring several VRFs

Here is a configuration example where the main VRF and vrf1 VRF need to send TRAP3 notifications. main and vrf1 use the same user to send SNMP v3 notifications to the same destination:

vsr running config# vrf vrf1 snmp enabled false
vsr running config# vrf main snmp
vsr running snmp# engine-id text test
vsr running snmp# access-control user alice auth-password Password
vsr running snmp# access-control user tusr1 auth-password Password engine-id 0x80001CA8003677696E64
vsr running snmp# access-control group admin user alice authorization read-write security-level auth
vsr running snmp# access-control group admin user tusr1 authorization read-write security-level auth
vsr running snmp# traps destination 10.0.0.201 notification-type TRAP3 user tusr1
vsr running snmp# traps process-check
vsr running snmp# traps link-status-check
vsr running snmp# traps load-check threshold 95
vsr running snmp# monitored-vrf vrf1
vsr running monitored-vrf vrf1# identifier id1 authorization read-only source 10.0.0.0/24
vsr running monitored-vrf vrf1# traps destination 10.0.0.201
vsr running monitored-vrf vrf1# commit
Configuration committed.

Note

  • For SNMP v3, both user and identifier authorizations are applied. Therefore, the most restrictive one is taken into account (in the example above: read-only).

snmp requests

SNMP information of the slave VRFs can be retrieved through the context name for SNMP v3. The network configuration is the same as before:

# snmpwalk -Ovq -v 3 -l authNoPriv -u alice -a SHA -A "Password" 10.0.0.2 IF-MIB::ifIndex
1
2
3

# snmpget -Ovq -v 3 -l authNoPriv -u tusr1 -a SHA -A "Password" 10.0.0.2 IF-MIB::ifName.2
mgmt

SNMP v3 requests on vrf1 VRF. Add the identifier name as context:

# snmpwalk -Ovq -v 3 -n id1 -l authNoPriv -u alice -a SHA -A "Password" 10.0.0.2 IF-MIB::ifIndex
1
2

# snmpget -Ovq -v 3 -n id1 -l authNoPriv -u tusr1 -a SHA -A "Password" 10.0.0.2 IF-MIB::ifName.2
eth_out

snmp traps

The SNMP v3 traps from the different VRFs can be distinguished thanks to the context name. In the SNMP v3 trap message, the VRF name will be set as context name.

Example of snmptrapd configuration file to log SNMP v3 traps from tusr1:

/etc/snmp/snmptrapd.conf:

createUser -e 0x80001CA8003677696E64 tusr1 SHA "Password" AES
group v3_admin usm tusr1
authgroup log v3_admin auth
format print2 %.4y-%.2m-%.2l %.2h:%.2j:%.2k %P %B [%b]:\n%v\n

Performance tuning

In some use cases, retrieving the mibs can become costly.

It is the case for the routing mibs when Virtual Service Router receives the full internet routing table.

The following command creates a view that blacklists the routing mibs to avoid a performance problem:

vsr running config# / vrf main snmp view VIEW subtree .1 included true
vsr running config# / vrf main snmp view VIEW subtree .1.3.6.1.2.1.4.21 included false
vsr running config# / vrf main snmp view VIEW subtree .1.3.6.1.2.1.4.24 included false

Supported mibs

Standard MIBs support

Virtual Service Router supports the following MIBs:

MIB name

Reference

Root OID

DISMAN-EVENT-MIB

RFC 2981

.iso.org.dod.internet.mgmt.mib-2.dismanEventMIB

.1.3.6.1.2.1.88

EtherLike-MIB

RFC 3635

.iso.org.dod.internet.mgmt.mib-2.etherMIB

.1.3.6.1.2.1.35

IF-MIB

RFC 2863

.iso.org.dod.internet.mgmt.mib-2.interfaces

.1.3.6.1.2.1.2

IF-MIB

RFC 2863

.iso.org.dod.internet.mgmt.mib-2.ifMIB

.1.3.6.1.2.1.31

IP-MIB

RFC 4293

.iso.org.dod.internet.mgmt.mib-2.ip

.1.3.6.1.2.1.4

IP-MIB

RFC 4293

.iso.org.dod.internet.mgmt.mib-2.icmp

.1.3.6.1.2.1.5

IP-FORWARD-MIB

RFC 4292

.iso.org.dod.internet.mgmt.mib-2.ip.ipForward

.1.3.6.1.2.1.4.24

IPV6-MIB

RFC 2465

.iso.org.dod.internet.mgmt.mib-2.ipv6MIB

.1.3.6.1.2.1.55

HOST-RESOURCES-MIB

RFC 2790

.iso.org.dod.internet.mgmt.mib-2.host

.1.3.6.1.2.1.25

RFC1213-MIB

RFC 1213

.iso.org.dod.internet.mgmt.mib-2

.1.3.6.1.2.1

SNMP-FRAMEWORK-MIB

RFC 3411

.iso.org.dod.internet.snmpV2.snmpModules.snmpFrameworkMIB

.1.3.6.1.6.3.10

SNMP-MPD-MIB

RFC 3412

.iso.org.dod.internet.snmpV2.snmpModules.snmpMPDMIB

.1.3.6.1.6.3.11.

SNMP-NOTIFICATION-MIB

RFC 3413

.iso.org.dod.internet.snmpV2.snmpModules.snmpNotificationMIB

.1.3.6.1.6.3.13

SNMP-TARGET-MIB

RFC 3413

.iso.org.dod.internet.snmpV2.snmpModules.snmpTargetMIB

.1.3.6.1.6.3.12

SNMP-USER-BASED-SM-MIB

RFC 3414

.iso.org.dod.internet.snmpV2.snmpModules.snmpUsmMIB

.1.3.6.1.6.3.15

SNMP-VIEW-BASED-ACM-MIB

RFC 3415

.iso.org.dod.internet.snmpV2.snmpModules.snmpVacmMIB

.1.3.6.1.6.3.16

SNMPv2-MIB

RFC 1213

.iso.org.dod.internet.mgmt.mib-2.system

.1.3.6.1.2.1.1

SNMPv2-MIB

RFC 1213

.iso.org.dod.internet.mgmt.mib-2.snmp

.1.3.6.1.2.1.11

SNMPv2-MIB

RFC 3418

.iso.org.dod.internet.snmpV2.snmpModules.snmpMIB

.1.3.6.1.6.3.1

TCP-MIB

RFC 4022

.iso.org.dod.internet.mgmt.mib-2.tcp

.1.3.6.1.2.1.6

UCD-SNMP-MIB

UCD-SNMP MIB

.iso.org.dod.internet.private.enterprises.ucdavis

.1.3.6.1.4.1.2021

UDP-MIB

RFC 4113

.iso.org.dod.internet.mgmt.mib-2.udp

.1.3.6.1.2.1.7

Interface Alias

IF-MIB::ifAlias parameter reflects the value of Linux network device aliases.

Interface aliases set through the CLI, iproute2 or sysfs can be read through SNMP in this parameter.

Control Plane Routing

Supported MIBs:

MIB name

Reference

Root OID

BGP4-MIB

.iso.org.dod.internet.mgmt.mib-2.bgp

.1.3.6.1.2.1.15

GNOME-PRODUCT-ZEBRA-MIB

.iso.org.dod.internet.private.enterprises.gnome.gnomeProducts.zebra

.1.3.6.1.4.1.3319.1.2

OSPF-MIB

.iso.org.dod.internet.mgmt.mib-2.ospf

.1.3.6.1.2.1.14

OSPF-TRAP-MIB

.iso.org.dod.internet.mgmt.mib-2.ospf.ospfTrap

.1.3.6.1.2.1.14.16

OSPFv3-MIB

RFC 5643

.iso.org.dod.internet.mgmt.mib-2.ospfv3MIB

.1.3.6.1.2.1.191

RIPv2-MIB

.iso.org.dod.internet.mgmt.mib-2.rip2

.1.3.6.1.2.1.23

HA VRRP

Supported MIBs:

MIB name

Reference

Root OID

KEEPALIVED-MIB

.iso.org.dod.internet.private.enterprises.debian.project.keepalived

.1.3.6.1.4.1.9586.100.5

VRRP-MIB

RFC 2787

.iso.org.dod.internet.mgmt.mib-2.vrrpMIB

.1.3.6.1.2.1.68

VRRPv3-MIB

RFC 6527

.iso.org.dod.internet.mgmt.mib-2.vrrpv3MIB

.1.3.6.1.2.1.207

IPsec/IKE

  • IPsec monitoring

  • IKE monitoring

Supported MIB:

MIB name

Reference

Root OID

SW-6WIND-IPSEC-MIB

6WIND

.iso.org.dod.internet.private.enterprises.sw6wind.swSecurity.swIpsecMib

.1.3.6.1.4.1.7336.2.1

Note

The IPsec MIB is available only if explicitly enabled for the relevant VRFs, see SNMP for IKE.

Licensing

Supported MIB:

MIB name

Reference

Root OID

SW-6WIND-LICENSE-MIB

6WIND

.iso.org.dod.internet.private.enterprises.sw6wind.swLicense.swLisenceMib

.1.3.6.1.4.1.7336.3.1

Note

The license MIB is available only if explicitly enabled, see Configuring SNMP sub-agent.