2.6.2 Node group membership

(1) Hierarchies/containment

You can create simple, reusable, atomic groups and combine them hierarchically for monitoring or visualization. Using hierarchical containers for nodes greatly enhances map views by providing cues about the location or type of object at fault. NNMi gives you complete control of the definition of the groups and their drill-down order.

You can create simple, reusable atomic groups first, and then specify them as child groups as you build up. Alternatively, you can specify your largest parent group first and create child groups as you go.

For example, a network might contain Cisco switches, Cisco routers, Nortel switches, and Nortel routers. You can create parent groups for Cisco devices and for all switches. Because the hierarchy is specified when you create the parent and designate its children, each child group, such as Cisco switches, can have multiple parents.

Hierarchies work well for the following situations:

• Types of nodes with similar monitoring needs

• Geographical locations of nodes

• Types of nodes to be taken OUT OF SERVICE together

• Groups of nodes by operator job responsibility

When you use groups in map views and table views, you see a (configurable) propagated status for the group.

Reference note

Keep in mind that as you use group definitions to specify monitoring configuration, hierarchy does not imply ordering for settings. The settings with the lowest ordering number apply to a node. By carefully incrementing ordering numbers, you can emulate inheritance concepts for settings.

An attempt to save a child node group with a circular reference node group set will fail with a warning.

To Page Top

(2) Device filters

During discovery, NNMi collects direct information through SNMP queries and derives information other than that through device profiles. For details, see 4.1.1 Device profiles and device attributes. By gathering the system object ID, NNMi can index through the correct device profile to derive the following information:

• Vendor

• Device category

• Device family within the category

• Device profile

These derived values, in addition to the device profile itself, are available for use as filters.

For example, you can group all objects from a specific vendor, regardless of device type and family. You can also group all devices of a type, such as routers, across vendors.

To Page Top

(3) Additional filters

With the additional filters editor, you can create custom logic to match fields, including:

• hostname (host name)

• mgmtIPAddress (management address)

• hostedIPAddress (address)

• sysName (system name)

• sysLocation (system location)

• sysContact (system contact)

• capability (unique key of the capability)

• customAttrName (custom attribute name)

• customAttrValue (custom attribute value)

• isSnmpNode (agent enabled)

• isNnmSystemLocal (NNMi management server)

• sysOidNode (system object ID)

• devCategoryNode (device category)

• devVendorNode (device vendor)

• devFamilyNode (device family)

• nnmSystemName (host name, case sensitive)

• nodeName (node name)

• securityGroupName (security group name)

• securityGroupUuid (security group UUID)

• tenantName (tenant name)

• tenantUuid (tenant UUID)

Filters can include the AND, OR, NOT, EXISTS, NOT EXISTS, and grouping (parentheses) operations. For details, see Specify Node Group Additional Filters in NNMi Help.

You can check capabilities by examining the node details from a device that has already been discovered.

To Page Top

(4) Additional nodes

It is better to use Additional Filters to qualify nodes for node groups. If the network contains critical devices that are too difficult to qualify using filters, add them to a group by individual host name. Only add nodes to a node group by individual host names as a last resort.

Reference note

Avoid using the Additional Nodes tab to add nodes to a node group, because doing so consumes excessive resources on the NNMi management server.

To Page Top