This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for
- Extreme Networks
- Community List
- Training, Documentation, & General Discussions
- FAQs
- Using the 'mask' Parameter in an SNMP View
Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
Using the 'mask' Parameter in an SNMP View
Using the 'mask' Parameter in an SNMP View
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Get Direct Link
- Report Inappropriate Content
11-24-2013 02:31 PM
Article ID: 5618
Products
DFE
SecureStack C3
SecureStack C2
SecureStack B3
SecureStack B2
SecureStack A2
Protocols/Features
SNMP
Commands
'set snmp view'
Goals
Sample configuration
Solution
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.
etherStatsEntry=1.3.6.1.2.1.16.1.1.1
etherStatsIndex=1.3.6.1.2.1.16.1.1.1.1.
etherStatsDataSource=1.3.6.1.2.1.16.1.1.1.2.
etherStatsDropEvents=1.3.6.1.2.1.16.1.1.1.3.
etherStatsOctets=1.3.6.1.2.1.16.1.1.1.4.
etherStatsPkts=1.3.6.1.2.1.16.1.1.1.5.
etherStatsBroadcastPkts=1.3.6.1.2.1.16.1.1.1.6.
etherStatsMulticastPkts=1.3.6.1.2.1.16.1.1.1.7.
etherStatsCRCAlignErrors=1.3.6.1.2.1.16.1.1.1.8.
etherStatsUndersizePkts=1.3.6.1.2.1.16.1.1.1.9.
etherStatsOversizePkts=1.3.6.1.2.1.16.1.1.1.10.
etherStatsFragments=1.3.6.1.2.1.16.1.1.1.11.
etherStatsJabbers=1.3.6.1.2.1.16.1.1.1.12.
etherStatsCollisions=1.3.6.1.2.1.16.1.1.1.13.
etherStatsPkts64Octets=1.3.6.1.2.1.16.1.1.1.14.
etherStatsPkts65to127Octets=1.3.6.1.2.1.16.1.1.1.15.
etherStatsPkts128to255Octets=1.3.6.1.2.1.16.1.1.1.16.
etherStatsPkts256to511Octets=1.3.6.1.2.1.16.1.1.1.17.
etherStatsPkts512to1023Octets=1.3.6.1.2.1.16.1.1.1.18.
etherStatsPkts1024to1518Octets=1.3.6.1.2.1.16.1.1.1.19.
etherStatsOwner=1.3.6.1.2.1.16.1.1.1.20.
etherStatsStatus=1.3.6.1.2.1.16.1.1.1.21.
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 1.3.6.1...11001
. . .
etherStatsDataSource 1518 OBJECT ID 1.3.6.1...12006
. . .
etherStatsStatus 1001 INTEGER valid(1)
. . .
etherStatsStatus 1518 INTEGER valid(1)
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, '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.
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 1.3.6.1.2.1.16.1.1.1.0.1012 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 = 1.3.6.1.2.1.1.1.0.244
Subtree mask = ff:df
View Type = included
Storage type = nonVolatile
Row status = active
DFE(su)->
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 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)
To return to default settings:
DFE(su)->clear snmp view All 1.3.6.1.2.1.16.1.1.1.0.244
DFE(su)->set snmp view All subtree 1
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.
Products
DFE
SecureStack C3
SecureStack C2
SecureStack B3
SecureStack B2
SecureStack A2
Protocols/Features
SNMP
Commands
'set snmp view'
Goals
Sample configuration
Solution
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.
etherStatsEntry=1.3.6.1.2.1.16.1.1.1
etherStatsIndex=1.3.6.1.2.1.16.1.1.1.1.
etherStatsDataSource=1.3.6.1.2.1.16.1.1.1.2.
etherStatsDropEvents=1.3.6.1.2.1.16.1.1.1.3.
etherStatsOctets=1.3.6.1.2.1.16.1.1.1.4.
etherStatsPkts=1.3.6.1.2.1.16.1.1.1.5.
etherStatsBroadcastPkts=1.3.6.1.2.1.16.1.1.1.6.
etherStatsMulticastPkts=1.3.6.1.2.1.16.1.1.1.7.
etherStatsCRCAlignErrors=1.3.6.1.2.1.16.1.1.1.8.
etherStatsUndersizePkts=1.3.6.1.2.1.16.1.1.1.9.
etherStatsOversizePkts=1.3.6.1.2.1.16.1.1.1.10.
etherStatsFragments=1.3.6.1.2.1.16.1.1.1.11.
etherStatsJabbers=1.3.6.1.2.1.16.1.1.1.12.
etherStatsCollisions=1.3.6.1.2.1.16.1.1.1.13.
etherStatsPkts64Octets=1.3.6.1.2.1.16.1.1.1.14.
etherStatsPkts65to127Octets=1.3.6.1.2.1.16.1.1.1.15.
etherStatsPkts128to255Octets=1.3.6.1.2.1.16.1.1.1.16.
etherStatsPkts256to511Octets=1.3.6.1.2.1.16.1.1.1.17.
etherStatsPkts512to1023Octets=1.3.6.1.2.1.16.1.1.1.18.
etherStatsPkts1024to1518Octets=1.3.6.1.2.1.16.1.1.1.19.
etherStatsOwner=1.3.6.1.2.1.16.1.1.1.20.
etherStatsStatus=1.3.6.1.2.1.16.1.1.1.21.
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 1.3.6.1...11001
. . .
etherStatsDataSource 1518 OBJECT ID 1.3.6.1...12006
. . .
etherStatsStatus 1001 INTEGER valid(1)
. . .
etherStatsStatus 1518 INTEGER valid(1)
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, '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.
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 1.3.6.1.2.1.16.1.1.1.0.1012 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 = 1.3.6.1.2.1.1.1.0.244
Subtree mask = ff:df
View Type = included
Storage type = nonVolatile
Row status = active
DFE(su)->
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 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)
To return to default settings:
DFE(su)->clear snmp view All 1.3.6.1.2.1.16.1.1.1.0.244
DFE(su)->set snmp view All subtree 1
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.
0 REPLIES 0
