<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Using the 'mask' Parameter in an SNMP View in FAQs</title>
    <link>https://community.extremenetworks.com/t5/faqs/using-the-mask-parameter-in-an-snmp-view/m-p/46846#M421</link>
    <description>Article ID: 5618 &lt;BR /&gt;
&lt;BR /&gt;
&lt;B&gt;Products&lt;/B&gt;&lt;BR /&gt;
DFE&lt;BR /&gt;
SecureStack C3&lt;BR /&gt;
SecureStack C2&lt;BR /&gt;
SecureStack B3&lt;BR /&gt;
SecureStack B2&lt;BR /&gt;
SecureStack A2 &lt;BR /&gt;
&lt;BR /&gt;
&lt;B&gt;Protocols/Features&lt;/B&gt;&lt;BR /&gt;
SNMP &lt;BR /&gt;
&lt;BR /&gt;
&lt;B&gt;Commands&lt;/B&gt;&lt;BR /&gt;
'set snmp view' &lt;BR /&gt;
&lt;BR /&gt;
&lt;B&gt;Goals&lt;/B&gt;&lt;BR /&gt;
Sample configuration &lt;BR /&gt;
&lt;BR /&gt;
&lt;B&gt;Solution&lt;/B&gt;&lt;BR /&gt;
The mask parameter ties to &lt;A href="http://www.ietf.org/rfc/rfc2575.txt" target="_blank" rel="nofollow noreferrer noopener"&gt;RFC2575&lt;/A&gt;, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)"; and is an optional paramenter of the 'set snmp view' command (&lt;A href="http://bit.ly/1c2ANeF" target="_blank" rel="nofollow noreferrer noopener"&gt;5610&lt;/A&gt;). &lt;BR /&gt;
&lt;BR /&gt;
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. &lt;BR /&gt;
&lt;BR /&gt;
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.&lt;BR /&gt;
                etherStatsEntry=1.3.6.1.2.1.16.1.1.1&lt;BR /&gt;
 &lt;BR /&gt;
                etherStatsIndex=1.3.6.1.2.1.16.1.1.1.1.&lt;BR /&gt;
           etherStatsDataSource=1.3.6.1.2.1.16.1.1.1.2.&lt;BR /&gt;
           etherStatsDropEvents=1.3.6.1.2.1.16.1.1.1.3.&lt;BR /&gt;
               etherStatsOctets=1.3.6.1.2.1.16.1.1.1.4.&lt;BR /&gt;
                 etherStatsPkts=1.3.6.1.2.1.16.1.1.1.5.&lt;BR /&gt;
        etherStatsBroadcastPkts=1.3.6.1.2.1.16.1.1.1.6.&lt;BR /&gt;
        etherStatsMulticastPkts=1.3.6.1.2.1.16.1.1.1.7.&lt;BR /&gt;
       etherStatsCRCAlignErrors=1.3.6.1.2.1.16.1.1.1.8.&lt;BR /&gt;
        etherStatsUndersizePkts=1.3.6.1.2.1.16.1.1.1.9.&lt;BR /&gt;
         etherStatsOversizePkts=1.3.6.1.2.1.16.1.1.1.10.&lt;BR /&gt;
            etherStatsFragments=1.3.6.1.2.1.16.1.1.1.11.&lt;BR /&gt;
              etherStatsJabbers=1.3.6.1.2.1.16.1.1.1.12.&lt;BR /&gt;
           etherStatsCollisions=1.3.6.1.2.1.16.1.1.1.13.&lt;BR /&gt;
         etherStatsPkts64Octets=1.3.6.1.2.1.16.1.1.1.14.&lt;BR /&gt;
    etherStatsPkts65to127Octets=1.3.6.1.2.1.16.1.1.1.15.&lt;BR /&gt;
   etherStatsPkts128to255Octets=1.3.6.1.2.1.16.1.1.1.16.&lt;BR /&gt;
   etherStatsPkts256to511Octets=1.3.6.1.2.1.16.1.1.1.17.&lt;BR /&gt;
  etherStatsPkts512to1023Octets=1.3.6.1.2.1.16.1.1.1.18.&lt;BR /&gt;
 etherStatsPkts1024to1518Octets=1.3.6.1.2.1.16.1.1.1.19.&lt;BR /&gt;
                etherStatsOwner=1.3.6.1.2.1.16.1.1.1.20.&lt;BR /&gt;
               etherStatsStatus=1.3.6.1.2.1.16.1.1.1.21.&lt;BR /&gt;
 &lt;BR /&gt;
 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. &lt;BR /&gt;
&lt;BR /&gt;
Here is an abbreviated example of one such SNMP query.&lt;BR /&gt;
 Object                          Instance  Type          Value&lt;BR /&gt;
 etherStatsIndex                 1001      INTEGER       1001&lt;BR /&gt;
  . . .&lt;BR /&gt;
 etherStatsIndex                 1518      INTEGER       1518&lt;BR /&gt;
 etherStatsDataSource            1001      OBJECT ID     1.3.6.1...11001&lt;BR /&gt;
  . . .&lt;BR /&gt;
 etherStatsDataSource            1518      OBJECT ID     1.3.6.1...12006&lt;BR /&gt;
  . . .&lt;BR /&gt;
 etherStatsStatus                1001      INTEGER       valid(1)&lt;BR /&gt;
  . . .&lt;BR /&gt;
 etherStatsStatus                1518      INTEGER       valid(1)&lt;BR /&gt;
 &lt;BR /&gt;
 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. &lt;BR /&gt;
&lt;BR /&gt;
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. &lt;BR /&gt;
&lt;BR /&gt;
The first ten octets of etherStatsEntry (that is, '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. &lt;BR /&gt;
&lt;BR /&gt;
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. &lt;BR /&gt;
&lt;BR /&gt;
Here is a such an SNMP View using these specifications, starting with a default configuration.&lt;BR /&gt;
 DFE(su)-&amp;gt;show snmp view&lt;BR /&gt;
 View Name       = All&lt;BR /&gt;
 Subtree OID     = 1&lt;BR /&gt;
 Subtree mask    =&lt;BR /&gt;
 View Type       = included&lt;BR /&gt;
 Storage type    = nonVolatile&lt;BR /&gt;
 Row status      = active&lt;BR /&gt;
 &lt;BR /&gt;
 View Name       = All&lt;BR /&gt;
 Subtree OID     = 0.0&lt;BR /&gt;
 Subtree mask    =&lt;BR /&gt;
 View Type       = included&lt;BR /&gt;
 Storage type    = nonVolatile&lt;BR /&gt;
 Row status      = active&lt;BR /&gt;
 &lt;BR /&gt;
 DFE(su)-&amp;gt;clear snmp view All 1&lt;BR /&gt;
 DFE(su)-&amp;gt;set snmp view viewname All subtree 1.3.6.1.2.1.16.1.1.1.0.1012 mask ff:df &lt;BR /&gt;
 DFE(su)-&amp;gt;show snmp view&lt;BR /&gt;
 View Name       = All&lt;BR /&gt;
 Subtree OID     = 0.0&lt;BR /&gt;
 Subtree mask    =&lt;BR /&gt;
 View Type       = included&lt;BR /&gt;
 Storage type    = nonVolatile&lt;BR /&gt;
 Row status      = active&lt;BR /&gt;
 &lt;BR /&gt;
 View Name       = All&lt;BR /&gt;
 Subtree OID     = 1.3.6.1.2.1.1.1.0.244&lt;BR /&gt;
 Subtree mask    = ff:df&lt;BR /&gt;
 View Type       = included&lt;BR /&gt;
 Storage type    = nonVolatile&lt;BR /&gt;
 Row status      = active&lt;BR /&gt;
 &lt;BR /&gt;
 DFE(su)-&amp;gt;&lt;BR /&gt;
 &lt;BR /&gt;
 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. &lt;BR /&gt;
&lt;BR /&gt;
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. &lt;BR /&gt;
&lt;BR /&gt;
A SNMP query of branch etherStatsEntry using the Community Name associated with this defined View, has a result similer to what is shown here.&lt;BR /&gt;
 Object                          Instance  Type          Value&lt;BR /&gt;
 etherStatsIndex                 1012      INTEGER       1012&lt;BR /&gt;
 etherStatsDataSource            1012      OBJECT ID     1.3.6.1...11012&lt;BR /&gt;
 etherStatsDropEvents            1012      Counter       54323&lt;BR /&gt;
 etherStatsOctets                1012      Counter       302877211&lt;BR /&gt;
 etherStatsPkts                  1012      Counter       1592774&lt;BR /&gt;
 etherStatsBroadcastPkts         1012      Counter       793487&lt;BR /&gt;
 etherStatsMulticastPkts         1012      Counter       729406&lt;BR /&gt;
 etherStatsCRCAlignErrors        1012      Counter       0 &lt;BR /&gt;
 etherStatsUndersizePkts         1012      Counter       0 &lt;BR /&gt;
 etherStatsOversizePkts          1012      Counter       0&lt;BR /&gt;
 etherStatsFragments             1012      Counter       0 &lt;BR /&gt;
 etherStatsJabbers               1012      Counter       0&lt;BR /&gt;
 etherStatsCollisions            1012      Counter       0 &lt;BR /&gt;
 etherStatsPkts64Octets          1012      Counter       0&lt;BR /&gt;
 etherStatsPkts65to127Octets     1012      Counter       458931&lt;BR /&gt;
 etherStatsPkts128to255Octets    1012      Counter       55190&lt;BR /&gt;
 etherStatsPkts256to511Octets    1012      Counter       656909&lt;BR /&gt;
 etherStatsPkts512to1023Octets   1012      Counter       57&lt;BR /&gt;
 etherStatsPkts1024to1518Octets  1012      Counter       1&lt;BR /&gt;
 etherStatsOwner                 1012      OCTET STRING  monitor&lt;BR /&gt;
 etherStatsStatus                1012      INTEGER       valid(1)&lt;BR /&gt;
 &lt;BR /&gt;
 To return to default settings:&lt;BR /&gt;
 DFE(su)-&amp;gt;clear snmp view All 1.3.6.1.2.1.16.1.1.1.0.244&lt;BR /&gt;
 DFE(su)-&amp;gt;set snmp view All subtree 1&lt;BR /&gt;
 &lt;BR /&gt;
 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. &lt;BR /&gt;
&lt;BR /&gt;
For more information regarding the SNMP View command set, see the relevant &lt;A href="https://extranet.enterasys.com/Downloads/" target="_blank" rel="nofollow noreferrer noopener"&gt;Configuration Guides&lt;/A&gt;.</description>
    <pubDate>Sun, 24 Nov 2013 22:31:00 GMT</pubDate>
    <dc:creator>FAQ_User</dc:creator>
    <dc:date>2013-11-24T22:31:00Z</dc:date>
    <item>
      <title>Using the 'mask' Parameter in an SNMP View</title>
      <link>https://community.extremenetworks.com/t5/faqs/using-the-mask-parameter-in-an-snmp-view/m-p/46846#M421</link>
      <description>Article ID: 5618 &lt;BR /&gt;
&lt;BR /&gt;
&lt;B&gt;Products&lt;/B&gt;&lt;BR /&gt;
DFE&lt;BR /&gt;
SecureStack C3&lt;BR /&gt;
SecureStack C2&lt;BR /&gt;
SecureStack B3&lt;BR /&gt;
SecureStack B2&lt;BR /&gt;
SecureStack A2 &lt;BR /&gt;
&lt;BR /&gt;
&lt;B&gt;Protocols/Features&lt;/B&gt;&lt;BR /&gt;
SNMP &lt;BR /&gt;
&lt;BR /&gt;
&lt;B&gt;Commands&lt;/B&gt;&lt;BR /&gt;
'set snmp view' &lt;BR /&gt;
&lt;BR /&gt;
&lt;B&gt;Goals&lt;/B&gt;&lt;BR /&gt;
Sample configuration &lt;BR /&gt;
&lt;BR /&gt;
&lt;B&gt;Solution&lt;/B&gt;&lt;BR /&gt;
The mask parameter ties to &lt;A href="http://www.ietf.org/rfc/rfc2575.txt" target="_blank" rel="nofollow noreferrer noopener"&gt;RFC2575&lt;/A&gt;, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)"; and is an optional paramenter of the 'set snmp view' command (&lt;A href="http://bit.ly/1c2ANeF" target="_blank" rel="nofollow noreferrer noopener"&gt;5610&lt;/A&gt;). &lt;BR /&gt;
&lt;BR /&gt;
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. &lt;BR /&gt;
&lt;BR /&gt;
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.&lt;BR /&gt;
                etherStatsEntry=1.3.6.1.2.1.16.1.1.1&lt;BR /&gt;
 &lt;BR /&gt;
                etherStatsIndex=1.3.6.1.2.1.16.1.1.1.1.&lt;BR /&gt;
           etherStatsDataSource=1.3.6.1.2.1.16.1.1.1.2.&lt;BR /&gt;
           etherStatsDropEvents=1.3.6.1.2.1.16.1.1.1.3.&lt;BR /&gt;
               etherStatsOctets=1.3.6.1.2.1.16.1.1.1.4.&lt;BR /&gt;
                 etherStatsPkts=1.3.6.1.2.1.16.1.1.1.5.&lt;BR /&gt;
        etherStatsBroadcastPkts=1.3.6.1.2.1.16.1.1.1.6.&lt;BR /&gt;
        etherStatsMulticastPkts=1.3.6.1.2.1.16.1.1.1.7.&lt;BR /&gt;
       etherStatsCRCAlignErrors=1.3.6.1.2.1.16.1.1.1.8.&lt;BR /&gt;
        etherStatsUndersizePkts=1.3.6.1.2.1.16.1.1.1.9.&lt;BR /&gt;
         etherStatsOversizePkts=1.3.6.1.2.1.16.1.1.1.10.&lt;BR /&gt;
            etherStatsFragments=1.3.6.1.2.1.16.1.1.1.11.&lt;BR /&gt;
              etherStatsJabbers=1.3.6.1.2.1.16.1.1.1.12.&lt;BR /&gt;
           etherStatsCollisions=1.3.6.1.2.1.16.1.1.1.13.&lt;BR /&gt;
         etherStatsPkts64Octets=1.3.6.1.2.1.16.1.1.1.14.&lt;BR /&gt;
    etherStatsPkts65to127Octets=1.3.6.1.2.1.16.1.1.1.15.&lt;BR /&gt;
   etherStatsPkts128to255Octets=1.3.6.1.2.1.16.1.1.1.16.&lt;BR /&gt;
   etherStatsPkts256to511Octets=1.3.6.1.2.1.16.1.1.1.17.&lt;BR /&gt;
  etherStatsPkts512to1023Octets=1.3.6.1.2.1.16.1.1.1.18.&lt;BR /&gt;
 etherStatsPkts1024to1518Octets=1.3.6.1.2.1.16.1.1.1.19.&lt;BR /&gt;
                etherStatsOwner=1.3.6.1.2.1.16.1.1.1.20.&lt;BR /&gt;
               etherStatsStatus=1.3.6.1.2.1.16.1.1.1.21.&lt;BR /&gt;
 &lt;BR /&gt;
 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. &lt;BR /&gt;
&lt;BR /&gt;
Here is an abbreviated example of one such SNMP query.&lt;BR /&gt;
 Object                          Instance  Type          Value&lt;BR /&gt;
 etherStatsIndex                 1001      INTEGER       1001&lt;BR /&gt;
  . . .&lt;BR /&gt;
 etherStatsIndex                 1518      INTEGER       1518&lt;BR /&gt;
 etherStatsDataSource            1001      OBJECT ID     1.3.6.1...11001&lt;BR /&gt;
  . . .&lt;BR /&gt;
 etherStatsDataSource            1518      OBJECT ID     1.3.6.1...12006&lt;BR /&gt;
  . . .&lt;BR /&gt;
 etherStatsStatus                1001      INTEGER       valid(1)&lt;BR /&gt;
  . . .&lt;BR /&gt;
 etherStatsStatus                1518      INTEGER       valid(1)&lt;BR /&gt;
 &lt;BR /&gt;
 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. &lt;BR /&gt;
&lt;BR /&gt;
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. &lt;BR /&gt;
&lt;BR /&gt;
The first ten octets of etherStatsEntry (that is, '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. &lt;BR /&gt;
&lt;BR /&gt;
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. &lt;BR /&gt;
&lt;BR /&gt;
Here is a such an SNMP View using these specifications, starting with a default configuration.&lt;BR /&gt;
 DFE(su)-&amp;gt;show snmp view&lt;BR /&gt;
 View Name       = All&lt;BR /&gt;
 Subtree OID     = 1&lt;BR /&gt;
 Subtree mask    =&lt;BR /&gt;
 View Type       = included&lt;BR /&gt;
 Storage type    = nonVolatile&lt;BR /&gt;
 Row status      = active&lt;BR /&gt;
 &lt;BR /&gt;
 View Name       = All&lt;BR /&gt;
 Subtree OID     = 0.0&lt;BR /&gt;
 Subtree mask    =&lt;BR /&gt;
 View Type       = included&lt;BR /&gt;
 Storage type    = nonVolatile&lt;BR /&gt;
 Row status      = active&lt;BR /&gt;
 &lt;BR /&gt;
 DFE(su)-&amp;gt;clear snmp view All 1&lt;BR /&gt;
 DFE(su)-&amp;gt;set snmp view viewname All subtree 1.3.6.1.2.1.16.1.1.1.0.1012 mask ff:df &lt;BR /&gt;
 DFE(su)-&amp;gt;show snmp view&lt;BR /&gt;
 View Name       = All&lt;BR /&gt;
 Subtree OID     = 0.0&lt;BR /&gt;
 Subtree mask    =&lt;BR /&gt;
 View Type       = included&lt;BR /&gt;
 Storage type    = nonVolatile&lt;BR /&gt;
 Row status      = active&lt;BR /&gt;
 &lt;BR /&gt;
 View Name       = All&lt;BR /&gt;
 Subtree OID     = 1.3.6.1.2.1.1.1.0.244&lt;BR /&gt;
 Subtree mask    = ff:df&lt;BR /&gt;
 View Type       = included&lt;BR /&gt;
 Storage type    = nonVolatile&lt;BR /&gt;
 Row status      = active&lt;BR /&gt;
 &lt;BR /&gt;
 DFE(su)-&amp;gt;&lt;BR /&gt;
 &lt;BR /&gt;
 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. &lt;BR /&gt;
&lt;BR /&gt;
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. &lt;BR /&gt;
&lt;BR /&gt;
A SNMP query of branch etherStatsEntry using the Community Name associated with this defined View, has a result similer to what is shown here.&lt;BR /&gt;
 Object                          Instance  Type          Value&lt;BR /&gt;
 etherStatsIndex                 1012      INTEGER       1012&lt;BR /&gt;
 etherStatsDataSource            1012      OBJECT ID     1.3.6.1...11012&lt;BR /&gt;
 etherStatsDropEvents            1012      Counter       54323&lt;BR /&gt;
 etherStatsOctets                1012      Counter       302877211&lt;BR /&gt;
 etherStatsPkts                  1012      Counter       1592774&lt;BR /&gt;
 etherStatsBroadcastPkts         1012      Counter       793487&lt;BR /&gt;
 etherStatsMulticastPkts         1012      Counter       729406&lt;BR /&gt;
 etherStatsCRCAlignErrors        1012      Counter       0 &lt;BR /&gt;
 etherStatsUndersizePkts         1012      Counter       0 &lt;BR /&gt;
 etherStatsOversizePkts          1012      Counter       0&lt;BR /&gt;
 etherStatsFragments             1012      Counter       0 &lt;BR /&gt;
 etherStatsJabbers               1012      Counter       0&lt;BR /&gt;
 etherStatsCollisions            1012      Counter       0 &lt;BR /&gt;
 etherStatsPkts64Octets          1012      Counter       0&lt;BR /&gt;
 etherStatsPkts65to127Octets     1012      Counter       458931&lt;BR /&gt;
 etherStatsPkts128to255Octets    1012      Counter       55190&lt;BR /&gt;
 etherStatsPkts256to511Octets    1012      Counter       656909&lt;BR /&gt;
 etherStatsPkts512to1023Octets   1012      Counter       57&lt;BR /&gt;
 etherStatsPkts1024to1518Octets  1012      Counter       1&lt;BR /&gt;
 etherStatsOwner                 1012      OCTET STRING  monitor&lt;BR /&gt;
 etherStatsStatus                1012      INTEGER       valid(1)&lt;BR /&gt;
 &lt;BR /&gt;
 To return to default settings:&lt;BR /&gt;
 DFE(su)-&amp;gt;clear snmp view All 1.3.6.1.2.1.16.1.1.1.0.244&lt;BR /&gt;
 DFE(su)-&amp;gt;set snmp view All subtree 1&lt;BR /&gt;
 &lt;BR /&gt;
 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. &lt;BR /&gt;
&lt;BR /&gt;
For more information regarding the SNMP View command set, see the relevant &lt;A href="https://extranet.enterasys.com/Downloads/" target="_blank" rel="nofollow noreferrer noopener"&gt;Configuration Guides&lt;/A&gt;.</description>
      <pubDate>Sun, 24 Nov 2013 22:31:00 GMT</pubDate>
      <guid>https://community.extremenetworks.com/t5/faqs/using-the-mask-parameter-in-an-snmp-view/m-p/46846#M421</guid>
      <dc:creator>FAQ_User</dc:creator>
      <dc:date>2013-11-24T22:31:00Z</dc:date>
    </item>
  </channel>
</rss>

