This section describes how NetIM infers links and connections between devices.

The Link and Connection Inference adapter uses data stored in the NetIM database to infer:

The data examined by Link and Connection Inference depends on the specific inference engines enabled when the adapter runs. The results are influenced by the configuration properties for the inference engine itself as well as advanced options.

This section includes the following topics

The Link and Connection Inference adapter is composed of inference engines, which is a program that performs a targeted type of connection inference. Most inference engines attempt to derive or infer connections based on specific network data stored in the NetIM database. For example, the IP Address Engine examines IP addresses to infer connections and the Neighbor Discovery Engine examines neighbor protocol information such as CDP neighbor tables to infer connections.

In most cases, the inference engines operate independently of each other. After the inference engines complete, the Link and Connection Inference adapter combines the output of the different engines to create a list of links for import into NetIM.

After all active inference engines have completed their inference actions, Link and Connection Inference merges the results together to create a consolidated list of links and connections and writes this list to an xml file. Only the links in the merged links list are created when VNE-XML Import runs immediately following Link and Connection Inference.

That a link is inferred by an engine does not necessarily mean that it will be retained when the inference results are merged. In other words, it is possible for a link to be inferred by an inference engine but not be imported into the NetIM database. Because inference engines examine different network data, it is possible for inference engines to derive different, and sometimes conflicting results. In cases of disagreement between inference engines, the Link Inference Merge rules determine which links the adapter will create. In addition, the Link and Connection Inference adapter has some advanced options that impact how inference results are merged together.

The Link and Connection Inference Engine Discrepancy report identifies situations where inference engines disagree on link endpoints and notifies you which link(s) exist in the NetIM database.

Address duplication in your network may cause Link and Connection Inference to infer incorrect links. The following topics are covered in the sections that follow:

Duplication of IP addresses in your network can cause incorrect results for inference engines that use IP address. You can use the Duplicate IP Address report to determine if you have duplicate addresses.

In the case of overlapping IP addresses, Link and Connection Inference may be configured to perform group-based link inference. For more information, see “Group-based Inference".

Duplication of MAC addresses in your network can cause incorrect results for the MAC Address Based Forwarding Table engine. You can use the Duplicate MAC Address report to determine if you have duplicate addresses.

The term module containment refers to the process of associating a separately managed routing module to the switch chassis in which that module is contained. Module containment must be inferred for a switch that has a removable module (for example, MSFC, RSFC, RSM, and FWSM) that is contained within the switch chassis but is managed separately.

When the module is managed separate from its switch chassis, the two have different CLI data files (.cfg,.cdp, and so on.), MIB data, and so on and are imported into the NetIM database as two separate devices. To accurately represent the two separately managed components as a single device rather than two separate devices, Layer 3 module containment must be inferred.

For the data from the switch and its module to be associated and merged into a single device upon import into analysis software, the two devices must be associated in NetIM. This module containment process is performed by the Link and Connection Inference adapter. After the Link and Connection Inference adapter runs, the Chassis Module Summary reports the module containment relationships inferred by the Module Containment engine.

The Module Containment Engine is enabled by default. If your network does not contain any switch chassis devices with separately managed modules, you can disable this engine without impacting the fidelity of the resulting network topology database. If you are not sure, you should leave this engine enabled.

The following sections cover

Module containment can be inferred by correlating the serial number for the routing module to one of the modules in the switch chassis. This is the primary method of inferring module containment.

The following data is required to infer module containment based on serial number:

Some Cisco RSM modules do not report serial number in device version output; therefore module containment based on serial number is unsuccessful for these devices. However both the switch and the RSM module may report a shared MAC address. The module containment engine attempts to identify a containment relationship based on the duplication of a MAC address on an RSM and a switch chassis. When the same MAC address is reflected for the vlan0 interface on a routing module and an interface in a switch chassis, the module containment engine infers that the routing module is contained in that switch chassis. This method is used to infer module containment only for Cisco RSM cards.

The NetIM database must contain needed data for both the switch chassis and the routing module card in order for a hybrid mode routing switch to be correctly represented. If either the switch chassis or the module card is missing from the NetIM database or if the data required to infer the relationship is missing, the resulting inferred topology will not be correctly represented. To determine if the a module card or switch chassis is missing from NetIM or if data needed to infer the relationship is missing, consult the following reports

When consulting these reports, keep in mind that they will only contain useful information after you run the Link and Connection Inference adapter.

By default, Link and Connection Inference considers all devices present in the NetIM database when it performs IP address-based inference. However, it can be configured to infer connections only between devices that are members of the same user-defined NetIM group. This is useful when you have overlapping IP address domains in your network.

When group-based inference is enabled, IP address-based inference engines perform separate link inference on each specified group. It can be configured to operate on all groups defined in NetIM, or just on specified groups.

When Group-based Inference is enabled, connections are inferred only between members of the specified group(s). No connections are inferred between groups. If you want to infer connections between devices in different groups, you must create a group that contains the connected devices and then configure Group-based Inference to include this group.

The MAC Address-based Forwarding Table Engine examines MAC address forwarding tables to determine Layer 2 connections. This link inference engine provides more accurate results when determining connections between Layer 2 devices and between Layer 2 and Layer 3 devices when MAC address forwarding tables are available for the devices.

In addition, the Link Layer Discovery Protocol (LLDP) Engine is helpful in determining Layer 2 and Layer 2/Layer 3 connections when LLDP is enabled on network devices. The Neighbor Discovery Protocol Engine is similarly helpful in determining Layer 2 and Layer 2/Layer 3 connections when a supported vendor-proprietary neighbor discovery protocol (such as Cisco Discovery Protocol) is enabled on network devices.

Link aggregation, also called trunking, is a way of combining multiple physical links into a single logical link.

Link and Connection Inference infers aggregate links in the following way. A logical link is inferred between the aggregate interfaces and physical links are created between physical interface pairs participating in the aggregate interface. When an aggregate link is inferred based on IP address, the logical (aggregate) interface is configured with an IP address and the physical interfaces are configured as members of the aggregate interface.

The Aggregate Link Rule (in Link Inference Merge Rules) must be enabled for aggregate links to be inferred and created by Link and Connection Inference.