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
mainVRF has 3 interfaces, the second one being calledmgmt,the
vrf1VRF has 2 interfaces, the second one being calledeth_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
See also
The SNMP command reference for details.
Supported mibs¶
Standard MIBs support¶
Turbo Router supports the following MIBs:
MIB name |
Reference |
Root OID |
|---|---|---|
DISMAN-EVENT-MIB |
|
|
EtherLike-MIB |
|
|
IF-MIB |
|
|
IF-MIB |
|
|
IP-MIB |
|
|
IP-MIB |
|
|
IP-FORWARD-MIB |
|
|
IPV6-MIB |
|
|
HOST-RESOURCES-MIB |
|
|
RFC1213-MIB |
|
|
SNMP-FRAMEWORK-MIB |
|
|
SNMP-MPD-MIB |
|
|
SNMP-NOTIFICATION-MIB |
|
|
SNMP-TARGET-MIB |
|
|
SNMP-USER-BASED-SM-MIB |
|
|
SNMP-VIEW-BASED-ACM-MIB |
|
|
SNMPv2-MIB |
|
|
SNMPv2-MIB |
|
|
SNMPv2-MIB |
|
|
TCP-MIB |
|
|
UCD-SNMP-MIB |
|
|
UDP-MIB |
|
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 |
|
|
GNOME-PRODUCT-ZEBRA-MIB |
|
|
OSPF-MIB |
|
|
OSPF-TRAP-MIB |
|
|
OSPFv3-MIB |
|
|
RIPv2-MIB |
|
HA VRRP¶
Supported MIBs:
MIB name |
Reference |
Root OID |
|---|---|---|
KEEPALIVED-MIB |
|
|
VRRP-MIB |
|
|
VRRPv3-MIB |
|
IPsec/IKE¶
IPsec monitoring
IKE monitoring
Supported MIB:
MIB name |
Reference |
Root OID |
|---|---|---|
SW-6WIND-IPSEC-MIB |
6WIND |
|