When NetMRI performs Discovery on devices in the network for the first time, they are organized into Device Groups and Interface Groups, using common-sense networking terms.
Device Groups and Interface Groups are the primary organizational units in NetMRI. You can create device groups in a nested structure, with some device groups subordinate to other device groups. You can apply device group membership criteria in the same ways with nested device groups as for device groups from earlier releases of NetMRI, which used a flat data structure and enforced all device groups as existing on the same peer level. You can now create a hierarchical list of device groups, comprised of top-level groups, with child device groups subordinate to them, and with child device groups further subordinate to their parent groups. For more information, see Creating Device Groups.
NetMRI uses device groups to organize device discovery results, generate separate scorecards, filter issues and to manage polling and processing for each device in the network. Device groups also offer control of Switch Port Management processes, including the ability to immediately carry out Switch Port polling in a device group.
Device groups can also be used for suppression of Issue reporting across sets of devices, and to modify the thresholds used by NetMRI for raising chosen issues. The use of Device Group suppression removes the need for manually suppressing undesirable issue instances and allows for instances that have yet to be raised to be suppressed before they are raised.
You can create device groups to organize devices according to business needs. Devices can belong to more than one group, and different sets of groups can be used for different purposes.
For example, you might create a collection of groups named North, South, East, and West that organize devices geographically, while creating another set of groups named Accounting, Sales and Engineering that organize devices along departmental lines. This allows you to manage devices across different dimensions, using similar mechanisms. With the groups described above, for instance, you can generate separate scorecards for all devices in the West or all devices used by Engineering. You decide on the organization, and NetMRI properly sorts everything.
Anywhere an IP address appears as a hyperlink in the NetMRI appliance, you can right-click that hyperlink to open a useful shortcut menu.
The NetMRI appliance functions as a Telnet and SSH session proxy for users to communicate by command line with devices on the network, including devices that the system sees and can reach, but does not manage. This functionality extends to Telnet or SSH sessions with NetMRI devices themselves.
The Telnet/SSH proxy also provides full VT100 emulation for systems and devices that need it. NetMRI provides a hard limit of ten concurrent SSH or Telnet sessions from any NetMRI instance to other devices. For example, if one user has seven Telnet sessions open on a NetMRI instance, all other users are limited to a total of three additional terminal sessions.
Operations Center Only: The Telnet/SSH proxy works transparently in the OC as a two-tiered proxy to communicate to devices reachable by the individual collectors. The proxy is two-tiered because the OC cannot talk directly to devices–only Collectors can do so. Telnet/SSH operation is transparent and behaves normally when initiating sessions from the OC appliance. |
For any Telnet or SSH session, administrative users can define user CLI credentials for other NetMRI user accounts. The location for configuring is Settings icon –> User Admin –> edit User –> CLI Credentials tab. Accounts that can modify CLI credentials for themselves and other users include SysAdmin, UserAdmin and ChangeEngineer High. Without User CLI credentials, other users can still log in to devices using their own device-specific credentials. This is particularly handy for devices that are not directly managed by NetMRI, such as Linux systems, but for which a user has a specific account. Some devices that are detected and/or managed by NetMRI may not provide the same level of Telnet or SSH as NetMRI. This is an advantage of the Telnet/SSH proxy.
Some NetMRI user accounts, such as ChangeEngineer Low, will not be able to start terminal configuration sessions using the Telnet/SSH proxy. System credentials can also be used for Telnet/SSH sessions. For more information, see Creating Admin and User Accounts.
The default admin account cannot use the Telnet/SSH proxy feature through CLI. Create another account to use this feature. Alternatively, you can connect to the device through the web UI, for example, using Anyterm SSH console, to be able to use this feature. |
All session activity is logged. For more information, see User Audit Logs.
All Telnet/SSH proxy sessions have an inactivity timeout of five minutes. This value cannot be changed. NetMRI allows only one session to a device from the same NetMRI instance. |
To open a Telnet or SSH session with a device, perform the following:
Before typing, click in the browser-based Telnet or SSH session window after you open a session. |
In addition to using Telnet and SSH sessions as proxies, you can connect to network devices using the CLI proxy. This feature allows users with valid privileges to proxy a connection to network devices through NetMRI. Superusers can grant the following privileges to control user access to the CLI proxy feature:
For information about specifying privileges, see Defining and Editing Roles.
To connect to specific devices, users must also have permissions to the corresponding device groups to which the devices belong. Authorized users can use any SSH client to gain proxy connection using their NetMRI credentials, without the need to acquire the credentials for individual devices. With valid privileges, users can use the Connect command to connect to the devices from any SSH client. For information about the command, see Using the Connect Command. The CLI proxy feature connects only through the management interface on the NetMRI appliance. This helps eliminate the need to gain access to the user's computer through various networks, VRFs, and VLANs. Note that all connections and commands issued to any network devices through the CLI proxy are audited and logged. For information about audit logs, see User Audit Logs.
Use the Connect command to connect to network devices from any SSH client. Users only need a connection to the NetMRI Management interface to connect to any managed devices. Users can connect to devices in groups to which they have valid permissions. You can view the audit logs for all events when the users use the Connect command to access network devices.
Netmriuser > connect {device ip | device name} <Network View>
where <Network View> is the name of the network view.
To connect to a managed device via the CLI proxy, complete the following:
connect 10.0.1.24. If there are multi-network deployments, you must specify the name of the network view in the Connect command. Example: Connect 10.0.1.24 "Network 1".You can configure an SSH connection to automatically connect to a managed device using SSH environment variables. Using this feature, you can save shortcuts to the devices to which you frequently connect.
You can use the following environment variables to set up the automatic connection:
The following example illustrates how to use these environment variables through PuTTy:
Figure 14.1 Configuring Environment Variables in PuTTy Session
5. Click Open.
If the contents of an audit log are of interest and must be kept for a longer term, save the log contents into a separate text file, as the log will drop off of the system 30 days after it appears. Audit logs are unique to each device. |
Audit logs are an important tool for tracking the following event types:
When you display a single audit log entry, a complete screen dump of the entire session is shown in text format. Session audit logs are kept by the appliance for a rolling 30-day time window. Audit logs are available at two levels: system-wide (under Settings), and for individual devices (in the Device Viewer). Error events you see here are normally associated with credential guessing operations by NetMRI and user-initiated SSH/Telnet sessions to individual devices.
For CLI Credential guessing and Telnet/SSH session attempts, you will see messages for the following phenomena:
For configuration collection logging, you may see messages of the following types:
To view a device's user audit log, go to Device Viewer –> Settings & Status –> User Audit Log. The audit log appears as a cumulative list for all Telnet/SSH sessions for the individual network device or end host for the last 30 days.
The System Administrator and View Audit Log privileges are required in order to view the Device Audit Log. |
The Device Audit Log (Device Viewer –> Settings & Status –> Device Audit Log) provides a device-specific list of events related to the device's management by NetMRI. You can expect to see messages such as LicenseAdd, indicating when the device was added to NetMRI management into a Device Group for purposes of Switch Port Management or other licensing requirements. You may see DiscoveryDelete in a case where a device with a particular management port IP address was removed from NetMRI management due to another device being managed through the same IP.
A second Device Audit Log, in Settings icon –> Notifications –> Device Audit Log, provides a listing for all Discovery and Licensing messages for all devices managed by NetMRI.
When devices are removed from the license count for NetMRI or ACM, related event messages will appear.
Device groups are a fundamental organizing tool in NetMRI. You use device groups to gather devices with similar attributes and similar categories together, to perform device management tasks, or because you want to organize a set of devices into a group to perform specific processing tasks, or to prevent processing tasks from being performed.
NetMRI ships with pre-defined device groups. They group discovered devices based on their types and assurance levels. For more information, see Default Device Groups.
All device groups are divided into two types:
For more information, see Controlling NetMRI with Device Groups.
Default device groups serve as good examples of how selection criteria and process settings can be defined to organize your network devices, but you should learn how to create your own device groups to gain all of the benefits of the device groups feature.
The default set of device groups in NetMRI appears as a hierarchical list and includes the following:
Default device groups can be used as-is, edited to suit your needs, or removed completely if you have admin rights to do so.
Use caution when deleting default device groups. The Routing, Switching, NIOS, Optimizers, Security, and many other groups are groups built-in with NetMRI and should never be removed without first having developed new groups with the desired functionality to take their place. |
The main Dashboard, Network Analysis, and Network Explorer pages show the Device Group Selector control on the right. Simply click a device group name in the selector to filter the contents of the main display pane. To edit a device group, right-click any device group name and select Edit Device Group, or click the Edit Device Group icon.
All top-level device groups can act as top-level device groups for nested device groups. Nested device groups can only contain devices from the parent device group. You can nest child device groups up to five levels deep in the tree. By default, child device groups automatically appear in the tree but can be hidden by clicking the (-) symbol next to the parent group.
Basic device groups limit their processing options to a minimum. Basic device groups do not contribute to NetMRI Network Scorecard calculations and significantly reduce back-end processing. You can define group membership criteria. For more information, see Understanding Device Group Membership Criteria.
Extended device groups provide a substantial collection of settings to determine how an extended device group processes its information. Along with defining group membership criteria, a number of options help determine the level and types of processing performed by an extended device group:
All settings are further described in the topic Creating Device Groups.
You can convert basic device groups to extended device groups, and also the reverse, at any time.
Some types of network devices warrant more processing by NetMRI, such as the collection of performance and environmental data, open ports probing, NetBIOS name probing, collecting of configuration files, analyzing for issues, and other device processing features. Some device types can be quickly excluded from complex processing tasks by simply assigning them to a basic device group. Many end-host networks may fall into this category.
For efficient system operation, NetMRI provides a limit of 250 Extended device groups and 250 Basic device groups. Use Extended groups sparingly to avoid significant load on the system. |
Through device groups, switch port management enables you to monitor and analyze the complement of Ethernet trunks and switch ports in their network. Switch port information gathering, or polling, is the key tool for doing this. Device groups can specify unique switch port management polling settings. Polling settings that are located under Settings icon –> Setup –> Collection and Groups –> Groups tab take precedence over the global settings defined in Settings icon –> Setup –> Collection and Groups –> Global –> Switch Port Management.
To poll a device group or create custom settings for polling, perform the following:
3. Click Save & Close or Save & New.
The settings you define here apply only to the chosen device group.
For device groups, NetMRI uses the Rank setting to determine how and when each device is processed after it is discovered on the network. Also, device groups use Rank as a way of determining the actions to take on a device that is a member of more than one group. If a device is a member of two groups, one that is enabled for config collection, and in another that is not, the group with the highest rank determines if the configs should be collected for that device. Ranking for child device groups in the device group tree is hierarchical. Child groups ranking is always higher than the ranking of its parent. Group Ranking is also used as the default sort order for all group-related tables, with the highest rank shown first.
The default groups organize devices essentially into "network" and "non-network" devices, based on their type and assurance level. Network devices usually have SNMP and Config collection and analysis enabled, while non-network devices do not. This reduces unnecessary data collection and processing loads, allowing the appliance to work more efficiently for devices that matter most.
By selectively enabling and disabling data collection, you can fine-tune NetMRI performance, or ensure that NetMRI processes the most important devices when a Device Limit or Interface Limit, based on licensing, is exceeded. In such cases, the Rank associated with each group is used to determine which devices are within the limits (devices with the highest rank) and which are outside the limits (devices with a lower rank). In this way, the most important devices, as indicated by the group rank, are processed while others are not.
In the device groups tree, the Rank is displayed only for Extended groups. |
NetMRI controls processing within device groups by a hierarchical collection of settings in the following order:
If you disable a specific process (such as SNMP collection) at a higher level, then all lower level settings are ignored. This allows administrators to quickly disable all processing of a given type, such as SNMP, without being forced to change individual settings.
When the Select Device Group panel is available (in the right panel), you can filter the contents of the center panel by device group.
The Collection and Groups page opens, showing the Groups –> Device Groups tab (also reachable by Settings icon –> Setup –> Collection and Groups –> Groups tab).
The number in parentheses after a device group name is the number of devices in the group. |
You can create and manage device groups in Settings icon –> Setup –> Collection and Groups –> Groups –> Device Groups side tab.
Both Basic and Extended groups can be created as either top-level, sibling, or child groups. NetMRI automatically assigns a parent group ID to the group you create. You can drag and drop a group in the tree for the desired position. For more information, see the following sections:
The table in the Device Groups side tab lists all device groups, with default sorting by Rank. Each row shows group configuration settings. Parent groups appear as folder icons indicating that child device groups exist beneath them in the tree. The device groups table provides a series of columns showing the status of various discovery and monitoring features that are enabled or disabled for each group.
When you hover over an icon or column heading in the table, a tooltip appears. For example, when you hover over an information icon in the MC (Membership criteria) column, it displays the complete text of the membership criteria regular expression. Any feature column that is cleared, without a checkmark, indicates that the given feature is not enabled for the device group. Individual devices of certain types can override group-level settings. For information about device-level settings, see Interpreting Discovery Table Data.
The complete list of data points provided for every device group at all nested levels includes the following:
ARP (Refresh device caches) | Indicates whether member devices in the group will have their ARP caches refreshed before collecting discovery data. NetMRI uses ARP cache refresh to control LAN switches from which switch-forwarding data is collected. For more information, see Notes on ARP, Switch Data Collection, and End Hosts. |
SNMP | Indicates whether the device group is set to enable SNMP data collection for member devices. SNMP collection can also be enabled/disabled for groups and devices. |
PS (Port Scan) | Indicates whether members of the device group will be scanned for open protocol ports. If enabled, NetMRI probes the TCP and UDP ports listed at Settings icon –> Setup –> Port List, to determine whether they are open. For more information, see Defining Group Data Collection Settings. |
FP (Fingerprint) | Indicates the device group setting to use the Identify device using fingerprinting setting for member devices. (This setting is dependent on the Probe for Open ports feature.) A polling technique to identify each network device based on the response characteristics of its TCP stack. This information is used to determine the device type. In the absence of SNMP access, fingerprinting is usually the only way to identify non-network devices. For more information, see Defining Group Data Collection Settings. |
C (Collect configs) | Indicates the device group setting to allow config file collection for all members in the group (Collect config files). |
CCS (CCS scripting) | Indicates the device group setting to allow CCS script file execution for all members in the group (Allow Script Execution). |
| PP (Privileged Polling) | Indicates whether the option CLI polling in privileged mode (i.e. privileged exec (enable) mode) is enabled for the group the device belongs to. You can override this setting for an individual device in the Device Viewer. |
DC (Default Credentials) | Indicates the device group setting for Test for Default Credentials, used to scan for the presence of vendor default credentials for all members in the group. |
A (Issue Analysis) | Indicates the device group setting to allow Issue analysis for all members in the group (Analyze for Issues). For more information about Issue analysis, see Viewing Issues in the Network. |
CL (Config Lock) | Indicates the device group setting to collect config data but to consider all member device configs a locked and not to be changed through NetMRI (Regard configurations as 'locked'). For more information, see Defining Group Data Collection Settings. |
NB (NetBIOS Scan) | Device polling method to collect the NetBIOS name for endpoint devices in the network. Device groups also enable NetBIOS scanning. For more information, see Defining Group Data Collection Settings. |
DB (Discovery Blackout) | Indicates the device group setting to impose discovery blackouts. For more information, see Defining Blackout Periods. |
CB (Change Blackout) | Indicates the device group setting to impose configuration change blackouts. For more information, see Defining Blackout Periods. |
SPMC (SPM | Indicates the device group setting to allow switch port data collection (Switch port data Collection). For more information, see Device Groups and Switch Port Management. |
SPMS (Polling Schedule) | Indicates whether the device group provides a polling interval or scheduling for switch port data collection. This setting is dependent on an enabled Switch port data Collection setting for the device group. |
MC (Membership Criteria) | Hovering the mouse over the check box in this column shows the complete regular expression for the selected device group. For more information, see Understanding Device Group Membership Criteria. |
By default, a new top-level device group is inserted at the bottom of the list, denoting a lower ranking. Creating a sibling group allows you to insert a device group into a specific position in the list of device groups, defining different ranking for the new group. You can insert the new sibling group immediately above or below the selected upper-level group.
To create a top-level device group, complete the following:
Child device groups should only contain devices belonging to their parent group. Creating a child device group of the top-level group “Routing” and using a device group criteria regular expression to filter other devices (e.g., firewalls) will result in an empty device group.
The group membership criteria statements built into each device group, respectively:
$Assurance > 75 and $vendor eq "Cisco" and $type in ["Router","Switch-Router"]
$Assurance > 75 and $vendor eq "Juniper" and $type in ["Router","Switch-Router"]
When you create a child device group for an existing device group, the existing group changes its icon to a folder icon. That folder icon does not change the essential properties of the parent device group–the parent keeps all of its qualifying devices. |
To create a new child device group, complete the following:
Nested device groups also operate with Issue Analysis. For information, see Issue Analysis in NetMRI and its subsections. Nested device groups inherit their Issue settings from their parent device groups, and may need editing to suppress Issues that are not relevant to them. |
To create an Extended device group, complete the following:
Define a Membership Criteria regular expression. For more information, see Understanding Device Group Membership Criteria.
Infoblox recommends using regular expressions for refining the membership in device groups. The topic Understanding Device Group Membership Criteria provides the information you need to understand and define simple regular expressions for device groups. |
Polling Frequency: Allows you to slow down or speed up the device polling frequency. For more information, see the following section, Setting Polling Frequency for a Device Group.
For Switch Port data Collection, choose from the following:
Disable: Completely disables switch port polling for the device group.
The global or group-level polling frequency modifier does not affect settings for switch port data collection frequency. |
12. Select the Enable Discovery Blackout check box and click its Scheduling icon. The scheduling options appear.
c. If you choose Daily, click either Every Day or Every Weekday:
d. If you choose Weekly, complete the following:
e. If you choose Monthly, complete the following:
For more information about discovery blackouts and change blackouts, see Defining Blackout Periods. |
13. If necessary, select the Enable Change Blackout check box and click its Scheduling icon. The scheduling options appear. Follow steps 12a through 12e to define the change blackout schedule.
Some devices in your network may have a locked Config Change setting (Device Viewer –> Settings & Status –> General Settings), which means that NetMRI will be disallowed from changing configurations on the device. In these cases, a device-level Enable Change Blackout setting is unnecessary. Similarly, each NetMRI device group has a Regard configurations as 'locked' setting. If a device group uses this setting, the Enable Change Blackout setting is unnecessary. If a device group does not enforce a change blackout, but a device in that group enables the Regard configurations as 'locked' setting, the device setting takes precedence. |
13. Click Save & Close or Save & New.
You can set global or individual polling frequency for a device group. You do so by specifying a polling frequency modifier. This is a coefficient by which the default NetMRI setting is multiplied. The higher the coefficient, the more frequently devices in the current group are polled.
The default NetMRI polling frequency is located in Settings icon –> Setup –> Device Collection Status. The global polling frequency modifier is located in Settings icon –> General Settings –> Advanced Settings –> Data Collection –> Polling Frequency Modifier.
You can set values between 0.5 and 2 for the global or group-level polling frequency modifier. Interpret the values as follows:
As NetMRI recalculates polling frequency every 10 minutes, the new polling frequency is applied to the group not later than 10 minutes after you specified it.
The polling frequency modifier affects SNMP credentials guessing. For example, by default it happens once a day. With the polling frequency modifier, you can make it happen twice a day or once in two days. This setting does not affect the frequency of CLI credentials guessing or config collection.
To set polling frequency for a device group, complete the following:
Specify Polling Frequency: Allows you to set individual polling frequency for the current device group.
If you select Specify Polling Frequency, the Polling Frequency Modifier field appears.
The polling frequency modifier, both global and group-level, does not apply to SDN devices. |
To view a list of device group members (devices that are included in the device group), complete the following:
To copy a group (to use as the basis for a new group), complete the following:
To delete a group, complete the following:
The Device Groups page provides the complete list of top-level device groups, populated with a series of gear icons. Clicking each icon displays a shortcut Actions menu offering group editing features: for device groups, features include the following:
NetMRI ships with pre-defined device group definitions. These groups are based on device types and assurance levels (the probability that from the same has correctly identified a given device) and are primarily used to see what has been discovered on the network. Default device groups can be used as-is, edited to suit your needs, or removed completely (provided you have admin rights to do so.
Use caution when deleting device groups. The Routing, Switching, NIOS, Optimizers, Security, and many other groups are groups built-in with NetMRI and should never be removed without first having developed new groups with the desired functionality to take their place.
Default device groups serve as good examples of how selection criteria and process settings can be defined to organize your network devices, but you should learn how to create your own device groups to gain all of the benefits of the device groups feature.
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 will be interacted with by NetMRI. For example, if SNMP Collection or Config Collection are 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 (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 member ship. 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/
Device Groups offer the flexibility to specify custom fields data as matching information against custom fields identification values defined on individual devices. You specify custom fields information in device groups through the Device Group Criteria. Doing so, you can craft device groups that match specific types of information, such as Business Units, operational function, and so on. Based on the information in the section Defining and Using Custom Fields, you can create device custom fields (“device” is a specific type of custom field that you can create and use for data matching) that are referenced by specific device groups for collection of devices into logically-named groups in NetMRI for asset manageability.
Supporting custom fields in device groups requires some specific Device Group Criteria syntax. Because a custom field can use the same nomenclature as a standard device attribute (for example, the Custom Fields feature does not prevent you from creating a custom field named “Type,” “Vendor” or “Model”), the device group criteria uses a convention to prevent conflicts. To do so, you prefix every Device Group Criteria reference to a device custom field with a syntax constant:
$custom_
Consider the creation of a device custom field called “business_unit.” For information on how to create custom fields in NetMRI, see Defining and Using Custom Fields. Editing the Device Group Criteria field for a device group called “Consumer Banking Group” to support a device custom field, the typical syntax is as follows:
$Assurance > 65 and $Type in ["Router","Switch-Router",”Switch”,”Firewall”] and $custom_business_unit = "Consumer Banking"
You prepend the constant $custom_ to the value “business_unit” to create the expression $custom_business_unit = “Consumer Banking”. Doing so in the Device Group Criteria ensures that any device that possesses a matching field value will match the “Consumer Banking Group” device group.
Because devices are managed as part of one or more network views, you can define device groups or interface groups with criteria based on network membership.
$Network variable in both Device Groups and Interface Groups:Example: $Network = "blue"
Syntax example: hasnetwork[”blue”,”red”,”green”]
Change issue thresholds and suppress issues for device groups in the Settings icon –> Issue Analysis –> Issue Group Settings icon –> by Device Groups and by Interface Groups side tabs. After selecting a group in the left panel, the Issue Settings for Group table lists all issues for the group and shows the current thresholds (if any) in the Criteria column, and whether any listed issue is suppressed.
Consult the topics Issue Group Settings and Performing Issue Suppression for more information.
After Discovery, you can organize all interfaces discovered on the network into collections of named groups. Similar to device groups, interface groups can be used to organize interfaces for results analysis, troubleshooting or to manage interface data collection. Interface group membership is determined periodically and stored in the database. Interface Groups have considerably narrower use in NetMRI compared to Device Groups.
NetMRI ships with a set of common-sense default interface groups that automatically organize common interfaces, such as switched Ethernet ports, VLANs and Ethernet trunk interfaces. Interface groups can be modified or copied, pasted and edited to create new ones, or you can create entirely new groups (provided you have admin rights to do so).
The Interface Groups page provides an Actions column, populated with a series of gear icons. Clicking each icon displays a shortcut Actions menu offering group editing features: for interface groups, View Members lists the interfaces within the group. Copy, Edit, and Delete perform their respective functions on the selected group.
Use caution when deleting interface groups; the Admin Down, Trunk Ports, Active Router Interfaces, and Switch Ports groups are built-in groups with NetMRI and should not be removed without first having developed new groups with the desired functionality to take their place.
You create and configure interface groups in the Interface Groups page (settings icon –> Setup –> Collection and Groups –> Groups tab –> Interface Groups side tab). The benefits of using interface groups include the following:
The table in the Interface Groups side tab lists all interface groups, with default sorting by Rank. Each row shows group configuration settings, with a green check indicating that the option is enabled, and a red X indicating that the option is disabled.
Rank determines the process settings for individual interfaces that belong to multiple interface groups. An interface is assigned the process setting associated with the highest ranking group that includes the interface as a member.
Interfaces can be a member of one or more interface groups. |
To create an interface group, perform the following:
You can set the Frequency to be more frequent than the default Daily setting. |
7. Click the Save & Close button.
or
Click the Save & New button to save/close the current group definition and start a new group definition.
To view a list of interface group members, complete the following:
To copy a group (to use as the basis for a new group), complete the following:
To delete a group, complete the following:
Exercise caution when deleting groups, because any associated group settings such as filtering and other attributes will also be deleted. For related information, see Expressions in Group Definitions.
Performance data consists of utilization rates, error rates and broadcast levels for the interfaces that are gathered into an interface group. You can also view the same performance data for each interface in the interface viewer.
Performance data includes configured speed, throughput, percent utilization, percent errors, percent broadcasts, and percent discards. Additional information can be displayed through selections from the Columns drop-down list available via column header menus.
By default, performance data collection is disabled for most interface groups. NetMRI provides two ways to enable performance data collection:
By default, collection takes place daily. For some interfaces, you may need to collect performance data more frequently. To do so, select a different setting from the Frequency dropdown. Values include Daily (the default), and incremental values from 15 minutes to 2 minutes.
You can use more-frequent data collection only on a select number of interfaces. Up to 10% of the total interfaces up to the Interface Limit in the managed network, based on the NetMRI license. |
Performance data collection uses interface groups to determine the data types to be collected and stored for each monitored interface. Because collection runs continuously, it needs to be informed when interface group definitions have been changed. Notification is done automatically if one or more group definitions have been changed since the last group generation process was performed (either scheduled or manual). If a definition changes while collection is taking place, the changes will not take effect until the next collection run.
At that point, interface data collection resumes collecting limited data for all interfaces to determine which should be further processed, based on the new definitions.
Infoblox recommends that interface group definitions be changed only when necessary, or when data collection is disabled. This reduces the workload on the appliance. |
Use interface groups for suppression of certain interface related issues and to modify thresholds for their appearance. Interface group issue suppression removes the need to manually suppress undesirable issue instances and allows for instances that have yet to be raised — and to be suppressed — to be suppressed before they are even raised. You can review interface group issue suppression settings at the Settings icon –> Issue Analysis section –> Issue Group Settings page.
Group membership expressions consist of one or more logical sub-expressions (e.g., equals, like, in), acting on a set of variables (e.g., $Name, $Type) evaluated by boolean operators (e.g., and, or, =>, <=). You can specify any logical membership criteria using sub-expression combinations. Some variables are defined only for certain types of criteria expressions.
NetMRI defines the following device variables that are usable in Device Group, Interface Group, Device-Filter, and Section-Filter criteria expressions:
$ID unique NetMRI ID for device$IPAddress IP address of the device (e.g., 192.168.1.33)$Name name of the device (e.g., rtr1.netcodia.com)$Network name of the Network View for the device's management IP address$Type type of the device (e.g., Router, Switch, etc.)$Assurance assurance level for the device type$Vendor vendor of the device (e.g., Cisco)$Model model of the device$Version software version of the device$Community SNMP community of the device$sysName SNMP system name (CPD only)$sysDescr SNMP system description (CPD only)$sysLocation SNMP system location$sysName SNMP system name$sysDescr SNMP system description$sysContact SNMP system contact
All device variables and interface variables are case-insensitive. |
The following variables are defined for interfaces and supported in Interface Group criteria expressions:
$ifIndex unique SNMP numeric index for the interface$ifDescr interface description defined by user$ifName interface name$ifType interface type defined by SNMP$ifMtu interface MTU$ifPhysAddress interface MAC address (if any)$ifSpeed interface speed$ifAdminStatus interface administrative status ("up"/"down")$ifOperStatus interface operational status ("up"/"down")$ifTrunkStatus interface trunk status ("on"/"off")$Network returns the name of the network view to which the interface IP address belongs.
The following comparison operators are supported in all criteria expressions:
=, ==, !=, <, , <=, =
numeric comparison (The value on either side of the operator should be an integer, float or IP address.)
eq, ne, gt, lt, ge, le
string comparison (The value on either side of the operator should be a string.)
=~, !~, like, not like
regular expression (A non-string value on the left side of operator is converted to a string before comparison.)
in, not in
determines if a given value is contained in a list of values (The values inside of the list should be the same type as the value on the left side of the operator.)
memberOf, not memberOf
determines if the device or interface is a member of one or more other Device Groups and/or Interface Groups.
hasnetwork
determines if the device or interface is a member of a specific Network View.
Examples:
$ID = 30
$Vendor eq "Cisco"
$Version like /^12.1.*/
$Model in ["cat4506", "3725"]
$IPAddress in [10.1.3.56, 10.2.0.0/16]
memberOf ["Router Group", "Switch Group"]
$Vendor eq "Cisco" and ($Model eq "catalyst2912XL" or $Model eq "cat3548XL")
To perform a case-insensitive match, use the regular expression modifier /i.
Example:
$Name like /core/i
The $Model and $IPAddress values work for creating device groups but cannot be used for building Rules with device attributes under Configuration Management –> Policy Design Center –> Rule.
$Model in ["cat4506", "3725"]
$IPAddress in [10.1.3.56, 10.2.0.0/16]
For Rules in the Policy Design Center, simply use a comma-separated format.
The following logical operators can be used to combine sub-expressions:
and, &, && boolean AND or, |, || boolean OR (, ) grouping
Examples:
$Vendor eq "Cisco" and $Type eq "Router"
($Vendor eq "Juniper" and $Type eq "Router")
or ($Vendor eq "Cisco" and $Type in ["Router", "Switch"])
memberOf ["Routing Group”"] and $IPAddress in [10.1.0.0/16, 10.2.3.45]
NetMRI uses regular expressions similar to those supported by Cisco, JavaScript and Unix programming languages. Regular expressions supported for table filtering consist of a sequence of special symbols, modifiers and normal characters. NetMRI interprets the following single characters and expressions as follows:
^ Matches the beginning of the string
$ Matches the end of the string
. Matches any single character
[...] A set of matching characters such as [aeiouA-Z]
[^...] A set of non-matching characters
(...) A sub-pattern to be modified or remembered
(...|...) A set of alternate sub-patterns
\w Matches any word character; same as [a-zA-Z0-9]
\W Matches any non-word character; same as [^a-zA-Z0-9_]
\s Matches any whitespace character; same as [ \t\n\r\f\v]
\S Matches any non-whitespace character; same as [^ \t\n\r\f\v]
\d Matches any digit; same as [0-9]
\D Matches any non-digit; same as [^0-9]
To match any of the special characters above, enter the backslash (\) escape character immediately before them. Avoid spurious or excessive matches. To match all IP addresses starting with an initial octet of 10, use /10\./ as the pattern, not /10./ which matches 10., 100, 101, 102, etc. (remember, dot is a special symbol).
Examples:
$Vendor like /Cis.*/
$Type like /.*Switch.*/
$IPAddress like /10\.*[/]16/
A common mistake occurs by using the Unix wildcard syntax (*) instead of the regular expression syntax (.*) to match any sequence of characters. |
With the special symbols above, the following characters are treated as modifiers that can be used to match against a previous sub-pattern zero, one, or more times:
{N} Match the sub-pattern exactly N times
{N,} Match the sub-pattern N or more times
{N,M} Match at least N times and no more than M times
? Match the sub-pattern 0 or 1 times; same as {0,1}
* Match the sub-pattern 0 or more times; same as {0,}
+ Match the sub-pattern 1 or more times; same as {1,}
Modifiers can be used to reduce the size of the expression and to specify optional parts of the expression. They are useful when combined with parentheses to designate sub-patterns.
The pattern
/Se(rial)?\d+/\d+/
matches any serial interface designator, either in the short form (Se0/0) or the long form (Serial12/45).
Examples:
$Vendor like /Cis(co)?/ $
ifType like /Se(rial)?\d+[/]\d+/
You use regular expressions to match values selected from a larger database of values. For economy of effort, it is sometimes easier to specify “just enough” of a pattern to obtain the match. For example, though a valid IPv4 address is formatted as “A.B.C.D” where A, B, C, and D range from 0 to 255, an expression:
/^(\d{1-3}\.){3}254$/
ensures that the first three octets are in fact defined as numbers with dots in between, but is unnecessary to find all addresses ending with “.254” when a simpler expression
/\.254$/
which checks for the desired suffix will succeed.