ActiveXperts Network Monitor 2019##AdminFavorites

CISCO-COMMON-ROLES-MIB.mib object view, vendor Cisco

Introduction

Most network devices and programs ship with so-called MIB files to describe the parameters and meanings (i.e.: friendly names) which are available for monitoring via SNMP.
ActiveXperts Network Monitor 2019 can import vendor-specific MIB files, so it can be used to monitor specific OID's (Object Identifiers). This way, you can monitor your devices, computers, etc. by selecting your relevant OID's by name.

ActiveXperts Network Monitor 2019 can import MIB file CISCO-COMMON-ROLES-MIB and use it to monitor vendor specific OID's.

CISCO-COMMON-ROLES-MIB file content

Object view of CISCO-COMMON-ROLES-MIB:

Scalar Object
commonRoleFeatureEntry .1.3.6.1.4.1.9.9.361.1.1.1.1
An entry (conceptual row) in the commonRoleFeatureTable containing information about features and the operations supported by each of the features.
commonRoleSupportedOperEntry .1.3.6.1.4.1.9.9.361.1.1.2.1
An entry (conceptual row) in the commonRoleSupportedOperTable which lists the operations supported by the local device for a particular access method.
commonRoleMaxRoles .1.3.6.1.4.1.9.9.361.1.2.1
Maximum number of common roles that can be configured this device. i.e., the maximum number of entries in the commonRoleTable.
commonRoleEntry .1.3.6.1.4.1.9.9.361.1.2.2.1
An entry (conceptual row) in the commonRoleTable.
commonRoleMaxRulesPerRole .1.3.6.1.4.1.9.9.361.1.3.1
Maximum number of rules that can be configured for a role.
commonRoleRuleEntry .1.3.6.1.4.1.9.9.361.1.3.2.1
An entry (conceptual row) in the commonRoleRuleTable.
Tabular Object
commonRoleFeatureIndex .1.3.6.1.4.1.9.9.361.1.1.1.1.1
An arbitrary index for this entry.
commonRoleFeatureName .1.3.6.1.4.1.9.9.361.1.1.1.1.2
Name of the feature. For example, strings like 'ip', 'snmp-server' and 'vsan' are valid feature names.
commonRoleFeatureOperation .1.3.6.1.4.1.9.9.361.1.1.1.1.3
The operation associated with this feature.
commonRoleAccessMethod .1.3.6.1.4.1.9.9.361.1.1.2.1.1
Access method supported on this system.
commonRoleSupportedOperation .1.3.6.1.4.1.9.9.361.1.1.2.1.2
Operations supported by the access method. clear - Clear operation config - Config/Set operation debug - Debug operation show - Show/Get operation exec - Exec/Set Operation .
commonRoleName .1.3.6.1.4.1.9.9.361.1.2.2.1.1
Name of the common role.
commonRoleDescription .1.3.6.1.4.1.9.9.361.1.2.2.1.2
Description of the common role.
commonRoleScopeRestriction .1.3.6.1.4.1.9.9.361.1.2.2.1.3
This object indicates if there is a scope restriction for this role. If the value of this object is 'none', then there no scope restriction. If it is 'vsan', the two objects commonRoleScope1 and commonRoleScope2 provide the list of Virtual Storage Area Networks (VSANs) which this role can access. The object commonRoleScope1 provides list of VSANs from 0 through 2047 and commonRoleScope2 provides from 2048 through 4095. Each octet within the value of the the two objects specifies a set of eight VSANs. The first octet specifies VSANs 0 through 7 for commonRoleScope1 and VSANs 2048 through 2054 for commonRoleScope2. Similarly, the second octet specifies VSANs 8 through 15 and VSANs 2055 through 2062 for commonRoleScope2, etc. Within each octet, the most significant bit represents the lowest numbered VSAN, and the least significant bit represents the highest numbered VSAN. Thus, each VSAN, is represented by a single bit within the value of this object. A role can access a VSAN if and only if that bit has a value of '1'. If these objects have a value which are less than 256 bytes long, then the VSANs which are not represented are not considered to be in these list. If both the scope objects are zero-length strings, then this role can not access any VSANs if this object is `vsan'. The role can access all the VSANs if the this object is 'none'. Also, both commonRoleScope1 and commonRoleScope2 are invalid if this object is 'none'. Other means of restricting the scope of a role can be defined in the future by extending this object with additional enumerations. Each such addition will define the restriction and any parameters it might have, which might or might not be specified via the corresponding values of commonRoleScope1 and commonRoleScope2.
commonRoleScope1 .1.3.6.1.4.1.9.9.361.1.2.2.1.4
This object provides the scope for the role. The actual meaning of this object depends the value of commonRoleScopeRestriction and is defined in that object.
commonRoleScope2 .1.3.6.1.4.1.9.9.361.1.2.2.1.5
This object provides the scope for the role. The actual meaning of this object depends the value of commonRoleScopeRestriction and is defined in that object.
commonRoleRowStatus .1.3.6.1.4.1.9.9.361.1.2.2.1.6
Status of this role.
commonRoleRuleIndex .1.3.6.1.4.1.9.9.361.1.3.2.1.1
A sequential number starting from 1, and less than or equal to commonRoleMaxRulesPerRole, which identifies a rule.
commonRoleRuleFeatureName .1.3.6.1.4.1.9.9.361.1.3.2.1.2
Name of the feature. If this is a zero-length string, then this rule applies to all the features supported on the system as enumerated in commonRoleFeatureTable.
commonRoleRuleOperation .1.3.6.1.4.1.9.9.361.1.3.2.1.3
The operation permitted for this rule.
commonRoleRuleOperPermitted .1.3.6.1.4.1.9.9.361.1.3.2.1.4
This object tells if the operation `commonRoleRuleOperation' is permitted on the feature `commonRoleFeatureName'. The operation is permitted if the value of this object is `true'. If the value of the object is 'false', the operation is not permitted.
commonRoleRuleRowStatus .1.3.6.1.4.1.9.9.361.1.3.2.1.5
Status of this rule.
Table
commonRoleFeatureTable .1.3.6.1.4.1.9.9.361.1.1.1
This table lists all the features and the operations supported by the features on the system.
commonRoleSupportedOperTable .1.3.6.1.4.1.9.9.361.1.1.2
This table lists all the access methods supported on device and the operations supported by each of the access methods. The operations listed in CommonRoleOperation may not be supported by all the access methods. For example, suppose that in the future, a new operation 'create' is added to CommonRoleOperation. CLI may not support it; but may be supported by XML. So this operation would not apply to CLI. This table captures the supported operations for each of the access methods.
commonRoleTable .1.3.6.1.4.1.9.9.361.1.2.2
This table lists all the common roles configured on this device.Common roles are the user roles which are common across SNMP and CLI.
commonRoleRuleTable .1.3.6.1.4.1.9.9.361.1.3.2
This table lists all the rules configured for roles defined in the commonRoleTable. Each rule defines a feature and related access-level which provides either permit or deny access to the feature information. Entries in this table are also created/deleted using commonRoleRuleRowStatus. A row in this table cannot be made 'active' until a value is explicitly provided for that row's instances of following objects : - commonRoleRuleOperation Also, the following objects cannot be modified when 'commonRoleRuleRowStatus' is 'active' : - commonRoleRuleFeatureName - commonRoleRuleOperation - commonRoleRuleOperPermitted To modify the above objects, the entry must be deleted and re-created with new value of above objects.
Object Identifier
ciscoCommonRolesMIB .1.3.6.1.4.1.9.9.361
MIB module for managing the common roles between access methods like Command Line Interface (CLI), SNMP and XML interfaces. Every user on a device is associated with a role. A user role defines access rights afforded to the users that belog to this role. A role specifies which commands/operations a user is able to perform on what information. SNMP uses VACM (View-based Access Control Model) group to define access rights. Both SNMPv1/v2c community and SNMPv3 user have to belong to a group in order to access information. CLI uses proprietary mechanisms to define the access rights. Most of them depend on the underlying operating system. Groups created from SNMP are not same as the roles created from CLI unless they are synchronized. In addition to this, views make up the roles in VACM where was some kind of internal rules make the roles in the CLI. This MIB describes a framework in which a role defined independent of access methods. It is up to the the particular access method to convert this framework information into the native information. For example, SNMP needs to convert common role framework to VACM. Note that this framework could be also used for any other access methods other than SNMP and CLI. The framework needs a list of features and list of operations they can support. Features provide the data context and are system dependent. Operations are the actions that can be done on the data. The role are defined in terms of rules. Rules are essentially access rights which specify if a certain operation on a feature is permitted or not.
ciscoCommonRolesNotifications .1.3.6.1.4.1.9.9.361.0
ciscoCommonRolesMIBObjects .1.3.6.1.4.1.9.9.361.1
ciscoCommonRolesMIBConformance .1.3.6.1.4.1.9.9.361.2
ccrInfo .1.3.6.1.4.1.9.9.361.1.1
ccrRoleConfig .1.3.6.1.4.1.9.9.361.1.2
ccrRuleConfig .1.3.6.1.4.1.9.9.361.1.3
ciscoCommonRolesMIBCompliances .1.3.6.1.4.1.9.9.361.2.1
ciscoCommonRolesMIBGroups .1.3.6.1.4.1.9.9.361.2.2
Group
ccrmConfigurationGroup .1.3.6.1.4.1.9.9.361.2.2.1
A collection of objects for Common Roles configuration.