View Tree Family Table

The vacmViewTreeFamilyTable table stores all collections of view subtree families. These collections are called MIB views. A MIB view is an OID subtree value, which is the family name, together with a bitstring value, which is the family mask. The family mask identifies which sub-identifiers of the family name are in the MIB view. A mask is a list of hex octets, which separated by either “.” or “:” The default is “ff”.

In a MIB view, each view subtree family has a type. The type determines if the view subtree family is included in the MIB view. A managed object instance is contained within a MIB view only if both of these statements are true:

• The managed object's OID contains the same number of sub-identifiers as the OID subtree, or more.

• If the corresponding bit of the mask is not zero, each of the managed object's OID sub-identifiers match corresponding sub-identifiers in the OID subtree.

If the configured value of the mask is too short to check these statements, the value is implicitly extended by a series of ones. A view family subtree with a mask of zero bits therefore corresponds to a mask of all ones, which in turn corresponds to one MIB subtree.

The vacmViewTreeFamilyTable table is indexed by:

viewName

Specified by the access right selected in the vacmAccessTable table. Used for access checking.

An OID of a MIB subtree

The OID of the PDU is compared to the MIB view.

Each of the rows in the vacmViewTreeFamilyTable table contains:

vacmViewTreeFamilyViewName

The name of the MIB view.

vacmViewTreeFamilySubtree

OID subtree. The OID subtree couples with a mask to make MIB view subtrees.

vacmViewTreeFamilyMask

Bitstring mask. The bitstring mask couples with an OID subtree to make MIB view subtrees.

vacmViewTreeFamilyType

The type determines whether the view subtree family is included in the MIB view.

If the MIB view does not contain the OID searched for, access is denied. In this case, a return value of notInView is returned. Otherwise, where the MIB view does contain the correct OID, access is granted. In this case a value of accessAllowed is returned.

The overall flow chart for this VACM algorithm is illustrated by Figure 4–2. In this diagram, the guideline terms suggested by the RFC are given for clarity:

securityName and securityModel

Indicate who requires access.

contextName

Determines where access is granted.

securityLevel and securityModel

Determines how access is granted.

viewType

Can be read, write or notify. Determines why a particular level of access is required by a group or user.

Object type, or OID of the managed object

Indicates what type of management data is checked.

Instance of the managed object

Combines with the object type to deliver which particular instance is checked to be in the MIB view. This decision is yes/no.

Figure 4–2 Overall Flow Chart for VACM

Example 4–3 shows typical entries in a vacmViewTreeFamilyTable.

Example 4–3 Creating Typical View Tree Family Table Entries

You can create a view in two ways:

• You can create a view by adding the view to the main /etc/sma/snmp/ configuration file.

  view all included .1 FF view none excluded .1 FF view vwnam1 included .1.3.6.1 FF

  The “FF” here is the mask.

  If the view is created by adding the group to the main /etc/sma/snmp/snmpd.conf configuration file, then the entries that are created in the vacmViewTreeFamilyTable table are as follows:

  SNMP-VIEW-BASED-ACM-MIB::vacmViewTreeFamilyMask."all".1.1 = STRING: "ÿ" SNMP-VIEW-BASED-ACM-MIB::vacmViewTreeFamilyMask."none".1.1 = STRING: "ÿ" SNMP-VIEW-BASED-ACM-MIB::vacmViewTreeFamilyMask."vwnam1".4.1.3.6.1 = STRING: "ÿ" SNMP-VIEW-BASED-ACM-MIB::vacmViewTreeFamilyType."all".1.1 = INTEGER: included(1) SNMP-VIEW-BASED-ACM-MIB::vacmViewTreeFamilyType."none".1.1 = INTEGER: excluded(2) SNMP-VIEW-BASED-ACM-MIB::vacmViewTreeFamilyType."vwnam1".4.1.3.6.1 = INTEGER: included(1) SNMP-VIEW-BASED-ACM-MIB::vacmViewTreeFamilyStorageType."all".1.1 = INTEGER: permanent(4) SNMP-VIEW-BASED-ACM-MIB::vacmViewTreeFamilyStorageType."none".1.1 = INTEGER: permanent(4) SNMP-VIEW-BASED-ACM-MIB::vacmViewTreeFamilyStorageType."vwnam1".4.1.3.6.1 = INTEGER: permanent(4) SNMP-VIEW-BASED-ACM-MIB::vacmViewTreeFamilyStatus."all".1.1 = INTEGER: active(1) SNMP-VIEW-BASED-ACM-MIB::vacmViewTreeFamilyStatus."none".1.1 = INTEGER: active(1) SNMP-VIEW-BASED-ACM-MIB::vacmViewTreeFamilyStatus."vwnam1".4.1.3.6.1 = INTEGER: active(1)

• You can create a view by using the snmpvacm command.

  # snmpvacm -v3 -u myuser -a MD5 -A my_password -l authNoPriv -Ce localhost createView all .1 FF

  # snmpvacm -v3 -u myuser -a MD5 -A my_password -l authNoPriv localhost createView none .1 FF

  # snmpvacm -v3 -u myuser -a MD5 -A my_password -l authNoPriv localhost createView vwnam1 .1.3.6.1 FF

  Here, the user myuser has rwuser level access. Therefore, view entries are created in this example for myuser, where appropriate for the context.

  If the view is created by using the snmpvacm command, the storage type would be nonVolatile.