7.2.6 Creating node and interface groups
You must set up node and interface groups before configuring monitoring settings. Therefore, you must consider polling requirements while configuring node and interface groups. Ideally, node and interface groups are configured so that you can monitor important devices frequently, and you can check on non-critical devices less frequently (if at all).
- Tip
Configure one set of node and interface groups for network monitoring. Configure a different set of node groups for network visualization through maps.
These groups are defined through the Configuration workspace, Object Groups folder, and then Node Groups option, or through the Configuration workspace, Object Groups folder, and then Interface Groups option. By default, they are the same groups that are used to filter incident, node, interface, and address views. To create a separate set of node or interface filters for configuring monitoring settings, open a node or interface group and select the Add to View Filter List check box on the Node Group or Interface Group form. Click Save and Close to save the definition.
You can set polling types and polling intervals at a node group level or interface group level on the Node Settings and Interface Settings tabs of the Monitoring Configuration form.
Determine the criteria by which you want to group interfaces, devices, or both by similar polling needs. Here are some factors to consider in your planning:
Which area of your network contains these devices? Are there timing constraints?
Do you want to differentiate polling intervals or data gathered by device type? By interface type?
Does NNMi provide pre-configured groups you can use?
- Tip
You can create group definitions for objects that are likely to go OUT OF SERVICE at the same time, whether by location or some other criterion. For example, you could put all your Cisco routers into OUT OF SERVICE mode while you apply an IOS upgrade.
- Organization of this subsection
(1) Interface groups
Based on your criteria, determine the interface groups you wish to create. Remember that interface groups are evaluated first (see 7.1 Concepts for state polling). Interface groups can reference node group membership, so to implement your plan you might end up configuring node groups before interface groups.
- Preconfigured interface groups
NNMi has several useful interface groups already configured for you to use. These interface groups include the following:
All interfaces with an IFType related to ISDN connections
Interfaces for voice connections
Interfaces for point-to-point communication
Software loopback interfaces
VLAN interfaces
Interfaces participating in link aggregation protocols
You can use existing groups, modify them, or create your own.
Interface groups have two types of qualifiers: node group membership for the hosting node, and IFType or other attribute for the interface. You can choose to combine these as follows:
All interfaces on nodes in a node group are grouped regardless of IFType; do not select any IFTypes or attributes (such as name, alias, description, speed, index, address, or other IFType attributes).
All interfaces of certain IFTypes or set of attributes are grouped, regardless of the node on which they reside.
Only interfaces of a certain IFType or attributes that reside on a particular group of nodes are grouped.
(2) Node groups
After planning interface groups, plan node groups. Not all node groups created for monitoring make sense for filtering views, so you can configure them independently.
- Preconfigured node groups
A default collection of node groups is provided to simplify your configuration tasks. These node groups are based on device categories derived from the system object ID during the discovery process. The node groups provided by default include the following:
Routers
Networking infrastructure devices (such as switches or routers)
Windows systems
Devices for which you do not have the SNMP community string
Important nodes. This is used internally by the Causal Engine to provide special handling for devices in the shadow of a connector failure. For details, see Node Groups As Predefined View Filters in NNMi Help.
-
Virtual Machines
You can use existing groups, modify them, or create your own.
You can qualify the definition of related nodes using the following node attributes:
IP address(es) on the node
Host name wildcard convention
Device Profile derivatives, such as category, vendor, and family
MIB II sysName, sysContact, sysLocation
Find a balance by creating a rich set of groups for configuration and viewing without overloading the list with superfluous entries that will never be used.
- Tip
You can create simple, reusable, atomic groups and combine them into hierarchical clusters for monitoring or visualization. Group definitions can overlap, such as All routers and All systems with IP address ending in 100. Nodes will probably qualify for multiple groups as well.
- Interaction with device profiles
When each device is discovered, NNMi uses its system object ID to index it into the list of available device profiles. The device profile is used to derive additional attributes of the device, such as vendor, product family, and device category.
As you configure node groups, you can use these derived attributes to categorize devices to apply monitoring settings. For example, you might want to poll all switches regardless of vendor throughout your network on a certain polling interval. You can use the derived device category Switch as the defining characteristic of your node group. All discovered devices whose system object ID maps to the category Switch will receive the configured settings for the node group.
- Tip
-
If NNMi is managing a hypervisor network environment, you might want to create a Node Group that contains only Virtual Machines (VMs). These nodes are identified using the vmwareVM device profile. You can also use this Node Group to occasionally check for VMs that are no longer hosted on a hypervisor. After selecting this Node Group, filter by Hosted On = null to identify these VMs. You can also use this Node Group to enable fault polling for the IP addresses associated with your VMs, which is also a best practice to ensure your VMs continue to be monitored even when its associated hypervisor has been deleted.