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.

Configuration example:

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

To display the current SNMP state:

vrouter 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
        ..
    traps
        destination 10.0.0.200 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:

vrouter 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>
      <traps>
        <destination>
          <host>10.0.0.200</host>
          <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¶

Configuration¶

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,
- a context for SNMP v3.

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

vrouter running config# vrf vrf1 snmp enabled false
vrouter running config# vrf main snmp
vrouter running snmp# static-info contact oam@my-company.com
vrouter running snmp# static-info location "Santa Barbara"
vrouter running snmp# community public authorization read-only source 10.0.0.0/24
vrouter running snmp# access-control user alice auth-password Password
vrouter running snmp# access-control group admin user alice authorization read-write security-level auth
vrouter running snmp# traps destination 10.0.0.200 notification-type TRAP2 community public
vrouter running snmp# traps process-check
vrouter running snmp# traps link-status-check
vrouter running snmp# traps load-check threshold 95
vrouter running snmp# monitored-vrf vrf1
vrouter running monitored-vrf vrf1# identifier vrf1 authorization read-only source 10.0.0.0/24
vrouter running monitored-vrf vrf1# traps destination 10.0.0.200 community vrf1
vrouter running monitored-vrf vrf1# commit
Configuration committed.

Note

When a VRF is linked to another one, its SNMP context must be disabled.
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).

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

vrouter 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>
vrouter 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,
the context name for SNMP v3.

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

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

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

SNMP requests on vrf1 VRF:

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

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

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

# snmpget -Ovq -v 3 -n vrf1 -l authNoPriv -u alice -a MD5 -A "Password" 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 vrf1 community for the vrf1 VRF.

/etc/snmp/snmptrapd.conf:

# Log trap from public and vrf1 communities
authCommunity log public
authCommunity log vrf1
# 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 vrf1 <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