Using the 'mask' Parameter in an SNMP View

  • 1.  Using the 'mask' Parameter in an SNMP View

    Posted 11-24-2013 14:31
    Article ID: 5618

    SecureStack C3
    SecureStack C2
    SecureStack B3
    SecureStack B2
    SecureStack A2


    'set snmp view'

    Sample configuration

    The mask parameter ties to RFC2575, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)"; and is an optional paramenter of the 'set snmp view' command (5610).

    A mask may be used to modify a View inclusion, designating certain octets of an OID string as wild-card "don't care" values. The desired result of defining a mask is to view within a MIB branch (using a MIB browser such as offered within the NetSight suite of products) only those leaves associated with designated port numbers, MAC addresses, IP addresses, etc.

    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.


    [/code]When displaying the etherStatsEntry branch, all ports are listed for each leaf before moving onto the ports of the next leaf - 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
    . . .
    etherStatsDataSource 1518 OBJECT ID
    . . .
    etherStatsStatus 1001 INTEGER valid(1)
    . . .
    etherStatsStatus 1518 INTEGER valid(1)

    [/code]When manually querying and viewing this information, it is generally most efficient to just point the SNMP browser to the etherStatsEntry branch and query it, then sift through the resulting glut of information as desired.

    However, it is possible to use the 'mask' parameter to significantly refine the output, so that only data for specified ports is returned. For this example, assume that DFE slot 1 port 12 is of interest.

    The first ten octets of etherStatsEntry (that is, '') 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.

    Here is a such an SNMP View using these specifications, starting with a default configuration.
    DFE(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

    DFE(su)->clear snmp view All 1
    DFE(su)->set snmp view viewname All subtree mask ff:df
    DFE(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 =
    Subtree mask = ff:df
    View Type = included
    Storage type = nonVolatile
    Row status = active


    [/code]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 thus 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.

    Also note that any use of the 'mask' parameter assumes "View Type = included". Parameters 'included' or 'excluded' cannot be specified along with the 'mask' parameter.

    A SNMP query of branch etherStatsEntry using the Community Name associated with this defined View, has a result similer to what is shown here.
    Object Instance Type Value
    etherStatsIndex 1012 INTEGER 1012
    etherStatsDataSource 1012 OBJECT ID
    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)

    [/code]To return to default settings:
    DFE(su)->clear snmp view All
    DFE(su)->set snmp view All subtree 1

    [/code]As already implied, the mechanics of determining exactly how to configure for this result, make for an inefficient use of time if the query will be a "one-shot". However, for data retrieved repeatedly, use of this method can prevent the unnecessary transfer of much SNMP data over the network.

    For more information regarding the SNMP View command set, see the relevant Configuration Guides.