Document toolboxDocument toolbox

Understanding Device Group Membership Criteria

Note

One way to understand how you define membership criteria for device groups is to look at existing Extended device groups in the system, including Routing, Switching, and Security.

Group membership criteria expressions are simple logical expressions used to determine if a given device or interface should be included in a Device Group or Interface Group based on the properties associated with that device or interface. In other NetMRI contexts, such as Security Management, this process is also called filtering. A device group uses its filtering settings, called membership criteria, to determine which devices discovered by NetMRI will belong to that group.

If the device matches more than one group criteria, it is assigned the rank of the highest matching group and all of the settings for that group.

Device Groups also determine how its member devices interact with NetMRI. For example, if SNMP Collection or Config Collection is disabled for the highest-ranking group containing a given device, then no SNMP data collection or Configuration file collection is performed for that device (beyond the initial collection needed to detect its existence). You use the same processes and settings to define Interface Groups as described in Creating Interface Groups. The process for Device Groups is straightforward.

An example of a regular expression comprising the membership criteria for a Device Group:

$Assurance > 75 and $Type in ["Router","Switch-Router"]

This regular expression is used to define the Routing device group. Note the use of Boolean logic and the enclosure of two NetMRI device group types (Router and Switch-Router) in square brackets. Two unique NetMRI variables, $Assurance and $Type, are used as the filtering criteria to define what belongs in the group. Typically, at least two variables must be used to create accurate filtering for a Device Group definition. The $Assurance value is the value attached to every device by NetMRI after it is discovered, to certify the device type is determined correctly. Consider an expression for a custom Device Group definition:

$Assurance > 75 and $vendor eq "Juniper" and $type eq "Firewall" and $Access eq "on"

The more specific the expression, the more effective and specific that membership can be in the Device Group. The values to be matched against must, of course, be recognized by NetMRI.

Group membership criteria are also used to define the Device-Filter and Section-Filter directives in Configuration Policy Definition (CPD) files, and Script-Filter directives in Configuration Command Script (CCS) automation scripts. In these cases, if a device matches, then the CPD file or CCS script is used to analyze that device. You can create custom files or scripts to define new criteria. You do not need to use CPD files or CCS scripts to create new Device Groups or Interface Groups.

For Interface Groups, the processes are similar, with some useful differences in how the regular expressions are defined to filter out interfaces reported in the device configuration.

$Type in ["Switch","Switch-Router"] and $ifType like /ether/ and $ifAdminStatus eq "up"

The Switch Port interface group uses the same variables to filter membership. The $ifType like /ether/ variable expression indicates how an expression can be interpreted to add Ethernet ports of varying types to the Group. the argument like allows a loose match against any port with the partial phrase ether in its identification. Considering the possibility of separating only 10/100 interfaces into a distinct group, you would use a more-specific expression such as:

$ifType like /FastEthernet/