Note
The mechanics of determining exactly how to configure the optional mask parameter make for an inefficient use of time if you will only be using the query once. However, for data retrieved repeatedly, using the method described in the following examples can prevent the unnecessary transfer of much SNMP data over your network.As defined in RFC2575, an SNMP mask is an optional parameter of the set snmp view command. You can use a mask to modify a view inclusion, designating certain octets of an OID string as wild-card “don't care” values. Once defined, you can view within a MIB branch (using a MIB browser such as that offered within the NetSight suite of products) only those leaves associated with specific items, such as designated port numbers, MAC addresses, and IP addresses.
For example, the RMON Statistics MIB branch is defined as follows, with the leaves defined within that branch each having multiple iterations, one for each port.
etherStatsEntry=1.3.6.1.2.1.16.1.1.1 etherStatsIndex=1.3.6.1.2.1.16.1.1.1.1.<port> etherStatsDataSource=1.3.6.1.2.1.16.1.1.1.2.<port> etherStatsDropEvents=1.3.6.1.2.1.16.1.1.1.3.<port> etherStatsOctets=1.3.6.1.2.1.16.1.1.1.4.<port> etherStatsPkts=1.3.6.1.2.1.16.1.1.1.5.<port> etherStatsBroadcastPkts=1.3.6.1.2.1.16.1.1.1.6.<port> etherStatsMulticastPkts=1.3.6.1.2.1.16.1.1.1.7.<port> etherStatsCRCAlignErrors=1.3.6.1.2.1.16.1.1.1.8.<port> etherStatsUndersizePkts=1.3.6.1.2.1.16.1.1.1.9.<port> etherStatsOversizePkts=1.3.6.1.2.1.16.1.1.1.10.<port> etherStatsFragments=1.3.6.1.2.1.16.1.1.1.11.<port> etherStatsJabbers=1.3.6.1.2.1.16.1.1.1.12.<port> etherStatsCollisions=1.3.6.1.2.1.16.1.1.1.13.<port> etherStatsPkts64Octets=1.3.6.1.2.1.16.1.1.1.14.<port> etherStatsPkts65to127Octets=1.3.6.1.2.1.16.1.1.1.15.<port> etherStatsPkts128to255Octets=1.3.6.1.2.1.16.1.1.1.16.<port> etherStatsPkts256to511Octets=1.3.6.1.2.1.16.1.1.1.17.<port> etherStatsPkts512to1023Octets=1.3.6.1.2.1.16.1.1.1.18.<port> etherStatsPkts1024to1518Octets=1.3.6.1.2.1.16.1.1.1.19.<port> etherStatsOwner=1.3.6.1.2.1.16.1.1.1.20.<port> etherStatsStatus=1.3.6.1.2.1.16.1.1.1.21.<port>
As shown in the example output above, when displaying the etherStatsEntry branch, all ports are listed for each leaf before moving on to the ports of the next leaf as the result of listing all of the data in numeric OID order.
Here is an abbreviated example of one such SNMP query.
Object Instance Type Value etherStatsIndex 1001 INTEGER 1001 etherStatsIndex 1518 INTEGER 1518 etherStatsDataSource 1001 OBJECT ID 1.3.6.1...11001 etherStatsDataSource 1518 OBJECT ID 1.3.6.1...12006 etherStatsStatus 1001 INTEGER valid(1) etherStatsStatus 1518 INTEGER valid(1)
This example shows you how to use the mask parameter to significantly refine your query output, so that only data for specified ports is returned. For this example, assume that S- K- or 7100-Series slot 1 port 12 is of interest.
The first ten octets of the etherStatsEntry (1.3.6.1.2.1.16.1.1.1) must match exactly as specified. The next octet, representing each of the 21 possible leaves within that branch, need not match exactly. The remainder, representing the port number, must match exactly as specified.
The bit representations for this would be 11111111-11011111, or 0xffdf. If the actual OID string being masked is longer than the specified bits, the missing bits to the right are assumed to be 1's. It is thus only necessary to make the mask long enough (in increments of 8-bit bytes) to designate, with a 0 bit, any desired “wild-card” OID string octets.
The following is an SNMP View using these specifications, starting with a default configuration.
System(su)->show snmp view View Name = All Subtree OID = 1 Subtree mask = View Type = included Storage type = nonVolatile Row status = active View Name = All Subtree OID = 0.0 Subtree mask = View Type = included Storage type = nonVolatile Row status = active System(su)->clear snmp view All 1 System(su)->set snmp view viewname All subtree 1.3.6.1.2.1.16.1.1.1.0.1012 mask ff:df System(su)->show snmp view View Name = All Subtree OID = 0.0 Subtree mask = View Type = included Storage type = nonVolatile Row status = active View Name = All Subtree OID = 1.3.6.1.2.1.1.1.0.244 Subtree mask = ff:df View Type = included Storage type = nonVolatile Row status = active
You can see by the unexpected Subtree OID value that this view actually accommodates only the right-most 8 bits of the entered decimal value 1012. The hexadecimal equivalent is 0x3f4, and the decimal equivalent of 0xf4 is 244. It is therefore true that this defined subtree will get a “hit” on multiple port values (244, 500, 756, 1012, etc), should they exist. This has nothing to do with the mask, and everything to do with the reasonable limitations of MIB design.
Note
Any use of the mask parameter assumes the View Type is configured as included. Parameters included or excluded cannot be specified along with the mask parameter.An SNMP query of the etherStatsEntry branch using the community name associated with this defined view would display a result similar to the following.
Object Instance Type Value etherStatsIndex 1012 INTEGER 1012 etherStatsDataSource 1012 OBJECT ID 1.3.6.1...11012 etherStatsDropEvents 1012 Counter 54323 etherStatsOctets 1012 Counter 302877211 etherStatsPkts 1012 Counter 1592774 etherStatsBroadcastPkts 1012 Counter 793487 etherStatsMulticastPkts 1012 Counter 729406 etherStatsCRCAlignErrors 1012 Counter 0 etherStatsUndersizePkts 1012 Counter 0 etherStatsOversizePkts 1012 Counter 0 etherStatsFragments 1012 Counter 0 etherStatsJabbers 1012 Counter 0 etherStatsCollisions 1012 Counter 0 etherStatsPkts64Octets 1012 Counter 0 etherStatsPkts65to127Octets 1012 Counter 458931 etherStatsPkts128to255Octets 1012 Counter 55190 etherStatsPkts256to511Octets 1012 Counter 656909 etherStatsPkts512to1023Octets 1012 Counter 57 etherStatsPkts1024to1518Octets 1012 Counter 1 etherStatsOwner 1012 OCTET STRING monitor etherStatsStatus 1012 INTEGER valid(1)
Print
this page
Email this topic
Feedback
View PDF
Download EPUB