SN10k SNMP theory of operations

Before proceeding with the following text please make sure that you are familiar with  SN10k SNMP - supported MIBs KB article. Please also ensure that the SnmpAgent application is running on your system - suitable reference can be found at the end of above article.

SN10k SNMP GET

In this example we will try to read ISDN and SIP NAP availability percentage from a SN10k gateway running 2.8.25 SmartMedia. We will perform the test from a Debian Linux operating system running 'snmp' deb package in version 5.4.3 and 'snmp-mibs-downloader' in version 1.1.
SN10k mgmt0 interface is addressed as '10.9.31.100' and the RO SNMP community is 'public'.

Firstly we need to download the 2.8 MIB file archive and decompress it contents:

root@sandbox:~/2015-04-28_SN10k_snmpTest# wget "http://www.patton.com/support/upgrades/agree.asp?rm=MIBS&path=SmartMedia-MIB.zip" -O SmartMedia-MIB.zip && unzip SmartMedia-MIB.zip && rm SmartMedia-MIB.zip

Then we need to check where the system stores MIB files

root@sandbox:~/2015-04-28_SN10k_snmpTest# net-snmp-config --default-mibdirs
/root/.snmp/mibs:/usr/share/mibs/site:/usr/share/snmp/mibs:/usr/share/mibs/iana:/usr/share/mibs/ietf:/usr/share/mibs/netsnmp

We will copy the downloaded mib to the directory located in current users home: '/root/.snmp/mibs' and create it if necessary

root@sandbox:~/2015-04-28_SN10k_snmpTest# if [ ! -e /root/.snmp ]; then mkdir /root/.snmp && mkdir /root/.snmp/mibs; fi; cp -vf SN10k-MIB.mib /root/.snmp/mibs

Now we will check if the MIB compiles properly and if we can reach the SN10k SnmpAgent process. Name of SNMP SN10k MIB module is 'SN-MIB' so we will use it as both input MIB and STDOUT filter. Following procedure will take some time since it queries all of available OIDs on the system

root@sandbox:~/2015-04-28_SN10k_snmpTest# snmpwalk -v2c -c public -m SN-MIB 10.9.31.100 | grep -iE SN-MIB

Result will contain many lines, most of them similar to following:

SNMPv2-SMI::mib-2.1.2.0 = OID: SN-MIB::snDirectory
SNMPv2-SMI::mib-2.88.1.2.2.1.6.10.115.110.109.112.100.46.99.111.110.102.71.101.110.101.114.97.116.101.32.65.112.112.72.97.83.116.97.116.101.49 = OID: SN-MIB::snHaAppHaCurrentState
SNMPv2-SMI::mib-2.88.1.2.2.1.6.10.115.110.109.112.100.46.99.111.110.102.71.101.110.101.114.97.116.101.32.65.112.112.72.97.83.116.97.116.101.50 = OID: SN-MIB::snHaAppHaCurrentState

In case you receive output similar to following, it means you are missing some standard SNMP MIB modules on your linux machine.

Unlinked OID in SN-MIB: 
Cannot adopt OID in SN-MIB: 

Next step will be to list all SNMP available NAP statistics. In 2.8 MIB file on line 2784 we can find a suitable object for this task:

snNapTable OBJECT-TYPE
    SYNTAX SEQUENCE OF SNNapEntry
    MAX-ACCESS not-accessible
    STATUS current
    DESCRIPTION
        "Lists NAPs statistics information."
    ::= { snNAP 2 }

We can issue a snmpwalk on this table to see what will be the returned values:

root@sandbox:~/2015-04-28_SN10k_snmpTest# snmpwalk -v2c -c public -m SN-MIB 10.9.31.100 SN-MIB::snNapTable

Result will be quite a long list of parameters with two looking mostly interesting:

• SN-MIB::snNapName
• SN-MIB::snNapAvailablePercent

If we will perform a snmpwalk on the first one, we will receive names of NAPs configured on the system with corresponding object identifier

root@sandbox:~/2015-04-28_SN10k_snmpTest# snmpwalk -v2c -c public -m SN-MIB 10.9.31.100 SN-MIB::snNapName
SN-MIB::snNapName.6 = STRING: NAP_SIP_FS5062
SN-MIB::snNapName.7 = STRING: NAP_ISDN_SN4950E1_0

Above results present only two NAPs I have configured on the testing system, which means the questy worked as expected. What's left is to issue a 'snmpget' command and retrieve the availability percentage of both NAPs:

root@sandbox:~/2015-04-28_SN10k_snmpTest# snmpget -v2c -c public -m SN-MIB 10.9.31.100 SN-MIB::snNapAvailablePercent.6
SN-MIB::snNapAvailablePercent.6 = INTEGER: 100
root@sandbox:~/2015-04-28_SN10k_snmpTest# snmpget -v2c -c public -m SN-MIB 10.9.31.100 SN-MIB::snNapAvailablePercent.7
SN-MIB::snNapAvailablePercent.7 = INTEGER: 50
root@sandbox:~/2015-04-28_SN10k_snmpTest#

Queries retured following data:

• NAP_SIP_FS5063 is available in 100% - which is true since the SIP server is UP and responds to SIP OPTIONS
• NAP_ISDN_SN4950E1_0 is available in 50% - which is true as well since this NAP is combined from two ISDN interfaces and one of them is disabled

The only remaining task is to gather numeric OIDs for your NMS system. In order to monitor fe. the availability percentage of NAP_SIP_FS5062 and present it's name

root@sandbox:~/2015-04-28_SN10k_snmpTest# snmptranslate -On SN-MIB::snNapName.6
.1.3.6.1.4.1.1768.400.5.2.1.1.6
root@sandbox:~/2015-04-28_SN10k_snmpTest# snmptranslate -On SN-MIB::snNapAvailablePercent.6
.1.3.6.1.4.1.1768.400.5.2.1.19.6

Of course be sure to implement the SN-MIB into your NMS system!

SN10k SNMP Trap

In order to receive SNMP Trap events I have launched a 'snmptrapd' daemon listening on port UDP/162 of our testing server IP:10.9.23.11.

root@sandbox:~/2015-04-28_SN10k_snmpTest# netstat -tulpaen | grep snmptrapd
udp 0 0 0.0.0.0:162 0.0.0.0:* 0 3912 1409/snmptrapd
root@sandbox:~/2015-04-28_SN10k_snmpTest#

SN10k configuration was done in the following way

After activating the SN10k configuration we enabled a tcpdump on the testing server and disconnected the E1 interface. Tcpdump trace returned the following values:

root@sandbox:~/2015-04-28_SN10k_snmpTest# tcpdump -i eth0 -s0 -n -v udp port 162
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
20:30:05.788731 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto UDP (17), length 248)
10.9.31.100.49135 > 10.9.23.11.162: { SNMPv2c C=SN10kSNMPTrapComTest { V2Trap(189) R=686734327 .1.3.6.1.2.1.1.3.0=354048 .1.3.6.1.6.3.1.1.4.1.0=.1.3.6.1.6.3.1.1.5.3 .1.3.6.1.2.1.2.2.1.1.452976.99=99 .1.3.6.1.2.1.2.2.1.7.452976.99=1 .1.3.6.1.2.1.2.2.1.8.452976.99=2 .1.3.6.1.2.1.2.2.1.2.452976.99="SN00A0BAxxxxxx ISDN Stack 1" .1.3.6.1.6.3.1.1.4.3.0=.1.3.6.1.4.1.8072.3.2.10 } }
20:30:05.791278 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto UDP (17), length 252)
10.9.31.100.49135 > 10.9.23.11.162: { SNMPv2c C=SN10kSNMPTrapComTest { V2Trap(193) R=686734329 .1.3.6.1.2.1.1.3.0=354049 .1.3.6.1.6.3.1.1.4.1.0=.1.3.6.1.6.3.1.1.5.3 .1.3.6.1.2.1.2.2.1.1.452976.100=100 .1.3.6.1.2.1.2.2.1.7.452976.100=1 .1.3.6.1.2.1.2.2.1.8.452976.100=2 .1.3.6.1.2.1.2.2.1.2.452976.100="SN00A0BAxxxxxx ISDN LAPD Link 1" .1.3.6.1.6.3.1.1.4.3.0=.1.3.6.1.4.1.8072.3.2.10 } }
20:30:05.817901 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto UDP (17), length 202)
10.9.31.100.49135 > 10.9.23.11.162: { SNMPv2c C=SN10kSNMPTrapComTest { V2Trap(143) R=686734337 .1.3.6.1.2.1.1.3.0=354051 .1.3.6.1.6.3.1.1.4.1.0=.1.3.6.1.4.1.1768.400.1.2.1.0.1 .1.3.6.1.4.1.1768.400.5.2.1.1.7="NAP_ISDN_SN4950E1_0" .1.3.6.1.4.1.1768.400.5.2.1.2.7=1 .1.3.6.1.4.1.1768.400.5.2.1.19.7=0 } }
20:30:06.061260 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto UDP (17), length 173)
10.9.31.100.49135 > 10.9.23.11.162: { SNMPv2c C=SN10kSNMPTrapComTest { V2Trap(115) R=686734395 .1.3.6.1.2.1.1.3.0=354076 .1.3.6.1.6.3.1.1.4.1.0=.1.3.6.1.4.1.1768.400.1.2.1.0.8 .1.3.6.1.4.1.1768.400.3.6.2.1.2.1="ISxxxxxx_00" .1.3.6.1.4.1.1768.400.3.6.2.1.3.1=0 } }

Remember that SNMPTrap daemon scans the SN10k Unit state accordingly to the interval configured in: 'Menu -> Applications -> SnmpAgent -> Application Parameters -> Advanced SNMP Parameters -> Polling delay to generate traps', so please provide a value suitable to your application needs, although having in mind that scans performed too oftenly can have a negative impact on your system performance.

Using a tool called 'snmptranslate' and Trap OID description from KB article SN10k SNMP - supported MIBs we can try putting more meaning for example to below line

10.9.31.100.49135 > 10.9.23.11.162: { SNMPv2c C=SN10kSNMPTrapComTest { V2Trap(143) R=686734337 .1.3.6.1.2.1.1.3.0=354051 .1.3.6.1.6.3.1.1.4.1.0=.1.3.6.1.4.1.1768.400.1.2.1.0.1 .1.3.6.1.4.1.1768.400.5.2.1.1.7="NAP_ISDN_SN4950E1_0" .1.3.6.1.4.1.1768.400.5.2.1.2.7=1 .1.3.6.1.4.1.1768.400.5.2.1.19.7=0 } }


Having in ming that SN10k proprietary SNMP module is called 'SN-MIB' and after making sure it's loaded to our system, we can proceed with following command for every OID value in the trace

root@sandbox:~/2015-04-28_SN10k_snmpTest# snmptranslate -m +SN-MIB .1.3.6.1.2.1.1.3.0 .1.3.6.1.6.3.1.1.4.1.0 .1.3.6.1.4.1.1768.400.1.2.1.0.1 .1.3.6.1.4.1.1768.400.5.2.1.1.7 .1.3.6.1.4.1.1768.400.5.2.1.2.7 .1.3.6.1.4.1.1768.400.5.2.1.19.7
DISMAN-EVENT-MIB::sysUpTimeInstance

SNMPv2-MIB::snmpTrapOID.0

SN-MIB::snNapAvailability

SN-MIB::snNapName.7

SN-MIB::snNapSignalingType.7

SN-MIB::snNapAvailablePercent.7

Which in a properly configure snmptrapd log would have the following format:

2015-04-28 20:30:06 host100.testhu [UDP: [10.9.31.100]:49135->[10.9.23.11]]:
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (354051) 0:59:00.51 SNMPv2-MIB::snmpTrapOID.0 = OID: SN-MIB::snNapAvailability SN-MIB::snNapName.7 = STRING: NAP_ISDN_SN4950E1_0 SN-MIB::snNapSignalingType.7 = INTEGER: isdn(1) SN-MIB::snNapAvailablePercent.7 = INTEGER: 0

Informing us that NAP_ISDN_SN4950E1_0 just became unavailable.