Device Relationships

This section describes device relationships in SL1.

Use the following menu options to navigate the SL1 user interface:

• To view a pop-out list of menu options, click the menu icon ().
• To view a page containing all of the menu options, click the Advanced menu icon ().

What are Device Relationships?

SL1 automatically defines parent and child relationships for certain devices. Users can also manually define some types of relationships. Devices can have the following types of relationships:

• Layer-2 devices and their clients. Layer-2 relationships are automatically discovered by SL1 and can be created in the Subnet Map (L2) page (Maps > Classic Maps > Topology Maps > Layer-2).

• Layer-3 devices and layer-2 devices. Layer-3 relationships are automatically discovered by SL1 and can be created in the Layer 3 Map page (Maps > Classic Maps > Topology Maps > Layer-3).
• Network devices that use CDP (Cisco Discovery Protocol) and devices that are specified as neighbors in the CDP tables. CDP relationships are automatically discovered by SL1 and can be created in the Subnet Map (CDP) page (Maps > Classic Maps > Topology Maps > CDP).
• Network devices that use LLDP (Link Layer Discovery Protocol) and devices that are specified as neighbors in the LLDP tables. LLDP relationships are automatically discovered by SL1 and can be created in the Classic Maps > Topology Maps > LLDP page (Maps > Classic Maps > Topology Maps > LLDP).
• Component devices and their parent devices using Dynamic Application data. For example, virtual machines and their hypervisors.
• Device relationships between root devices, parent devices, and component devices (Component Mapping).
• Device relationships created using Dynamic Application data. For example, the Dynamic Applications in the VMware vSphere and NetApp PowerPacks are configured to create relationships between VMware Datastore component devices and their associated NetApp Volume component devices.
• Generic parent-child relationships, sometimes referred to as Event Correlation relationships or Ad-Hoc relationships, can be manually created. These relationships can be created in the Device Children page for the parent device.

NOTE: SL1 also automatically discovers relationships between VMWare hypervisors and VMWare virtual machines using SNMP data, but only for legacy versions VMWare ESX 3.5 and VMWare ESX 4.x.

All device relationships are displayed as child and parent relationships. For example:

• A layer-2 switch is a parent device and a firewall attached to the switch is a child device.
• A layer-3 router is a parent device and a layer-2 switch attached to the router is a child device.
• A VMware ESX server is a parent device and a Linux VM on that server is a child device.
  

Viewing the List of Device Relationships

The Device Relationships page displays information about every parent-child relationship that has been automatically created by SL1 or manually defined by a user.

For each child device, the Device Relationships page displays at least the MAC address of the child interface and, if possible, the device name of the child device, the IP address associated with the child interface, the name of the child interface, and the manufacturer of the child interface.

For each parent device, the Device Relationships page displays the device name, the name of the parent interface, the MAC address of the parent interface, and the manufacturer of the parent interface.

For example, suppose a switch has been discovered by SL1. Suppose that 12 interfaces on that switch are in use. Suppose that only three of those 12 interfaces are connected to child interfaces that have been discovered by SL1. The Device Relationships page will display whatever ARP information SL1 can retrieve about the remaining nine child interfaces. In most cases, SL1 can retrieve the MAC address and manufacturer associated with the child interface, even if the child interface has not been discovered by SL1.

The relationships in the Device Relationships page are dynamically updated. If SL1 discovers a new relationship, SL1 updates the Device Relationships page.

You can view information for each parent-child relationship between two devices managed by SL1 or for a single parent device managed by SL1 and an unknown child device.

To view information on Device Relationships:

1. Go to the Device Relationships page (Registry > Networks > Device Relationships).
2. The Device Relationships page displays the following information:

You can sort the list of user device relationships by column. To sort by ascending column value, click on a column heading. To sort by descending column value, click on the same column heading a second time.

The Device Relationships page respects multi-tenancy rules. This means that you can view relationships in this page only if both devices are aligned with an organization of which you are a member.

• Child. If the child device has been discovered by SL1, this column contains the name of the device and a link to the Device Relationships page for the child device.
• Child IP. If the child device has been discovered by SL1, this column contains the IP address through which the child communicates with the parent device.
• Child Interface. If the child device has been discovered by SL1, this column contains the name of the interface through which the child device communicates with the parent device and a link to the Interfaces Found page for the child interface.
• Child Phys Addr. The physical address (MAC address) for the interface through which the child device communicates with the parent device.
• Child IF Manufacturer. If included in the MAC address, the manufacturer of the child interface.
• Parent. The name of the parent device and a link to the Device Relationships page for the parent device.
• Parent Interface.The name of the interface through which the parent device communicates with the child device and a link to the Interfaces Found page for the parent interface.
• Parent IF Alias. Easy-to-remember, human-readable name for the interface on the parent device.
• Parent Phys Addr. The physical address (MAC address) for the interface through which the parent device communicates with the child device.
• Parent IF Manufacturer. If included in the MAC address, the manufacturer of the parent interface.
• Type. Describes the relationship between the parent device and child device. Possible values are:

• CDP
• LLDP
• Component Mapping
• Component Relationship
• Event Correlation
• Layer-2
• Layer-3
• VMware

Filtering the List of Device Relationships

You can filter the list on the Device Relationships page by one or more parameters. Only device relationships that meet all the filter criteria will be displayed in the Device Relationships page.

To filter by parameter, enter text into the desired filter-while-you-type field. The Device Relationships page searches for device relationships that match the text, including partial matches. By default, the cursor is placed in the left-most filter-while-you-type field. You can use the <Tab> key or your mouse to move your cursor through the fields. The list is dynamically updated as you type. Text matches are not case-sensitive.

You can also use special characters to filter each parameter.

Filter by one or more of the following parameters:

• Child. You can enter text to match, including special characters, and the Device Relationships page will display only device relationships that have a matching device name on the child device.
• Child IP. You can enter text to match, including special characters, and the Device Relationships page will display only device relationships that have a matching IP address on the child interface.
• Child Interface. You can enter text to match, including special characters, and the Device Relationships page will display only device relationships that have a matching name on the child interface.
• Child Phys Addr. You can enter text to match, including special characters, and the Device Relationships page will display only device relationships that have a matching MAC address on the child interface.
• Child IF Manufacturer. You can enter text to match, including special characters, and the Device Relationships page will display only device relationships that have a matching manufacturer for the child interface.
• Parent. You can enter text to match, including special characters, and the Device Relationships page will display only device relationships that have a device name on the parent device.
• Parent Interface. You can enter text to match, including special characters, and the Device Relationships page will display only device relationships that have a matching name on the parent interface.
• Parent IF Alias. You can enter text to match, including special characters, and the Device Relationships page will display only device relationships that have a matching IF alias on the parent interface.
• Parent Phys Addr. You can enter text to match, including special characters, and the Device Relationships page will display only device relationships that have a matching MAC address on the parent interface.
• Parent IF Manufacturer. You can enter text to match, including special characters, and the Device Relationships page will display only device relationships that have a matching manufacturer for the parent interface.
• Type. You can enter text to match, including special characters, and the Device Relationships page will display only device relationships that have a matching type.

Viewing Relationships for a Single Device

You can view all links for a single device on the Relationships tab of the Device Investigator (or on the Device Relationships page in the Device Properties panel in the classic SL1 user interface).

To view all links for a single device:

• Go to the Relationships tab of the Device Investigator. (Alternatively, in the classic SL1 user interface, go to the Device Manager page (Devices > Device Manager), click the wrench icon for a device () and click the Relationships tab in the Device Properties pane.) The Device Relationships page appears.

• The left pane of the Device Relationshipspage displays links to parent devices. The right pane of the Device Relationships page displays links to child devices. For each relationship, the Device Relationships page displays the following information:

• Type of relationship. Possible values are:

• Layer 2. Layer-2 devices and their clients.
• Layer 3. Layer-3 devices and layer-2 devices.
• VMware. Hypervisors and their virtual machines.
• CDP. Network devices that use CDP (Cisco Discovery Protocol) and devices that are specified as neighbors in CDP tables.
• LLDP. Network devices that use LLDP (Link Layer Discovery Protocol) and devices that are specified as neighbors in LLDP tables.
• Event Correlation. Relationships defined manually by users through the user interface.
• Component Mapping. Relationships defined using Dynamic Applications.

• Parent Device. The name of the parent device and a link to the Device Properties page for the parent device.
• Parent Interface. The name of the interface through which the parent device communicates with the child device and a link to the Interfaces Found page for the parent interface.
• Child Device. The name of the child device and a link to the Device Properties page for the child device.
• Child Interface. The name of the interface through which the child device communicates with the parent device and a link to the Interfaces Found page for the child interface.

NOTE: Clicking on a device reloads the Device Relationships page and makes the selected device the primary device.

Viewing Device Topology Maps

On the Map tab in the Device Investigator, you can view a map of the selected device and all of the devices with which the device has relationships.

These relationships include:

• Layer-2 devices and their clients

• Layer-3 devices and Layer-2 devices
• Component devices and their parent devices. For example, virtual machines and their hypervisors and their virtual machines.
• Network devices that use CDP (Cisco Delivery Protocol) and devices that are specified as neighbors in CDP tables
• Links between network devices that use CDP (Cisco Discovery Protocol) and devices that are specified as neighbors in CDP tables
• Network devices that use LLDP (Link Layer Delivery Protocol) and devices that are specified as neighbors in LLDP tables
• Links between network devices that use LLDP (Link Layer Discovery Protocol) and devices that are specified as neighbors in LLDP tables
• Device relationships between root devices, parent devices, and component devices (Component Mapping)
• Device relationships created with Dynamic Applications
• Manually created parent-child relationships that affect event correlation

A map includes the following graphical elements:

• Nodes. Shapes that represent Devices, Topology Elements, and Business Services defined in SL1. The shape of a node represents its type, and the color of its outline specifies the current state of the node.
• Edges. Lines with or without arrows that represent the relationships and hierarchies between nodes. All device relationships are displayed as child and parent relationships. If the nodes on a map contain arrows, then the arrows represent the direction of the relationship, pointing from the child node to its parent node. If a node does not contain an arrow, then the relationship is bi-directional, or undirected.

When you hover your mouse over a device icon on the map, a pop-up window appears that displays information about that device. Click the device name in the pop-up window to go to the Device Investigator for that device.

You can use the icons on the page to do the following:

• Increase the map size ()
• Decrease the map size ()
• Fit all of the map elements into the viewing pane ()
• Center the selected elements of a map in the viewing pane ()

Defining Device Relationships

The Device Children modal page allows users to select one or more devices to become children of the currently selected device.

To add children to a device:

1. Go to the Relationships tab of the Device Investigator. (Alternatively, in the classic SL1 user interface, go to the Device Manager page (Devices > Device Manager), click the wrench icon for a device () and click the Relationships tab in the Device Properties pane.) The Device Relationships page appears.

2. Click the Actions button and then select Device Children. The Device Children modal page appears.

3. In the Device Children page, select one or more devices to be children of the current device.
4. Click Save .

Event Correlation

In SL1, event correlation means the ability to build parent-child relationships between devices and their events. When events are correlated, only the parent event is displayed in the Events page.

• In the Events page, the child events are rolled up and nested under the parent event and are displayed only if you click on the magnifying-glass icon ().
• For the parent event, the Count column will be incremented to indicate the number of correlated child events.

For details on event correlation, see the Events section.

Events that Might Not Be Displayed in the Events Page

In SL1, there are four types of events that might not be displayed in the Events page:

• Rolled-up events. Multiple occurrences of the same event on the same device. When the same event occurs multiple times on a single device, SL1 does not display each occurrence in the Events page. Instead, SL1 displays a single entry and notes the number of occurrences in the Count column.
• Suppressed Events. Suppressed events do not appear in the Events page.
• Topology Events. In SL1, event correlation or topology suppression means the ability to build parent-child relationships between devices and between events. When events are correlated, only the parent event is displayed in the Events page. The magnifying-glass icon () appears to the left of the parent event. When you click on the magnifying-glass icon, the list of child events is displayed. The child events are rolled up under the parent event and are not displayed in the Events page. For the parent event, the count column will be incremented to indicate the number of correlated child events. Optionally, you can define event categories that allow SL1 to more efficiently align suppressing events with suppressible events. When you align an event category to a suppressing or suppressible event, that event will be correlated with only events that are aligned with the same event category.

• Event Masks. In the Device Properties page for each device, you can define an Event Mask. When a device uses the Event Mask setting, events that occur on a single device within a specified span of time are grouped together. In the Events page, masked events are displayed under a single event, the one with the highest severity. The magnifying-glass icon () appears to the left of the event. When you click on the magnifying-glass icon, the list of all events that are masked under event is displayed.

Defining Event Correlation

To manually configure event correlation in the classic SL1 user interface, you must define two types of events:

• Suppressing events. If this event occurs on a parent device, SL1 will search all related children devices for suppressible events. On the children devices, all suppressible events will be suppressed. Only the suppressing event will appear in the Events page (or the Event Console page in the classic SL1 user interface) . The suppressible events will not appear in the Events page (or the Event Console page in the classic SL1 user interface) .
• Suppressible events. This type of event is suppressed on a child device only when a suppressing event occurs on the parent device.

NOTE: If you configure event categories, the suppressing and suppressible events must be associated with the same category for correlation to occur. If you do not configure event categories, each and every suppressing event that occurs on a parent device will cause SL1 to suppress all suppressible events on the associated children devices.

To define an event as a suppressing event on the Event Policy Manager page in the classic SL1 user interface):

1. Go to the Event Policy Manager page (Registry > Events > Event Manager.
2. On the Event Policy Manager page, click the wrench icon () of the event that you want to define as the suppressing event. The Event Policy Editor page appears.
3. On the Event Policy Editor page, click the Advanced tab.

4. In the Topology Suppression field, select Suppressing.
5. Click Save. In the future, when this event occurs on a device, SL1 will check if the device is a parent device. If the device is a parent device, specified events (suppressible events) with the same category will be suppressed on the children devices.

To define an event as a suppressible event on the Event Policy Manager page in the classic SL1 user interface:

1. Go to the Event Policy Manager page (Registry > Events > Event Manager).
2. On the Event Policy Manager page , click the wrench icon () of the event that you want to define as the Suppressible event. The Event Policy Editor page appears.
3. On the Event Policy Editor page, click the Advanced tab.

4. In the Topology Suppression field, select Suppressible.
5. Click Save. In the future, when this event occurs on a device, SL1 will check if the device is a child device. If the device is a child device, SL1 will check to see if a suppressing event with the same category has occurred on the parent device. If a suppressing event has occurred on the parent device, the specified event will be suppressed on the child device.

Example: Child Event Suppression

For example, suppose you have the following devices and event policies defined:

• A parent device, a Cisco Catalyst switch named Boise-DMZ.
• A child device to Boise-DMZ, a server named HQ-W2K3-VC01.
• An event policy, "Poller: Interface operationally down", defined as a suppressing event.
• A second event policy, "Poller: Device not responding", defined as a suppressible event.
• Both events are associated with the same event category.

In this scenario, if an interface goes down on the switch Boise-DMZ, SL1 will not be able to communicate with the server, HQ-W2K3-VC01, attached to the switch.

With the above defined event topology suppression:

• The event "Poller: Interface operationally down" occurs on Boise-DMZ.
• The event "Poller: Device not responding" is suppressed on the server HQ-W2K3-VC01.
• On the Events page (or the Event Console page in the classic SL1 user interface), the only event that would appear in this scenario will be the event "Poller: Interface operationally down" on the device Boise-DMZ.

Layer-2 Topology Collection

A layer-2 topology record describes a direct network connection between a parent device (a Network Switch or Network Bridge) and a child device. The child device is either:

• Another bridge device discovered in SL1
• Another type of device that is discovered in SL1
• A device that is not discovered in SL1

Every hour, SL1 collects information from the Bridge-MIB from all discovered network switches and bridges. Network switches and bridges that support the Bridge-MIB report information about all MAC addresses for which that network switch or bridge has forwarding information.

During collection, SL1 performs the following steps:

• Compiles a list of all devices to poll. SL1 polls devices that have a Device Category of "Network.Switches" (ID 2) or "Network.Bridges" (ID 19). The Device Category is defined in the Device Class assigned to the device.
• If the Enable Community String Indexing (VLAN Topology) checkbox is selected in the Behavior Settings page (System > Settings > Behavior), SL1 compiles a list of vLANs for which data should be collected using the CISCO-VTP-MIB. A vLAN is added to the list of vLANs only if the vLAN state is 1 (operational) and the vLAN type is 1 (ethernet). If the Enable Community String Indexing (VLAN Topology) option is disabled, SL1 performs collection for vLAN 1 only.
• For each vLAN on each device, SL1 polls the Bridge-MIB to collect the list of all MAC addresses for which that network switch or bridge has forwarding information.
• SL1 stores a MAC address record if:
• The status of the record is "3" (learned).
• An ifIndex value was collected successfully for the associated port index.

The information collected from the Bridge-MIB does not explicitly indicate which devices are directly connected to a network switch or bridge; switches and bridges will report forwarding information for MAC addresses that are several network hops away from the switch or bridge. A second "crunch" process creates layer-2 topology relationships by evaluating all of the collected MAC address records holistically.

CDP Topology Collection

A CDP Topology record describes a direct network connection between a parent device (a Network Switch or Network Router) and a child device. CDP stands for "Cisco Discovery Protocol," a proprietary standard that is used by networking devices to communicate configuration information to the other devices in the network. Devices that support CDP store and report information received about their immediate neighbors.

CDP is a proprietary protocol developed by Cisco and is not supported by all network hardware. If your network includes both CDP-enabled and non-CDP network switches and routers, the topology data reported by the CDP-enabled devices might not be accurate.

Suppose a network includes three switches connected in the following way:

• Switch A and Switch C, which are both CDP-enabled, broadcast CDP messages.
• Because Switch B is not CDP-enabled, the broadcast messages from Switch A will reach Switch C. Therefore, Switch C will report that it is directly connected to Switch A.
• Conversely, the broadcast messages from Switch C will reach Switch A. Therefore, Switch A will report that it is directly connected to Switch C.

In addition to the CDP data collected from the switches in this example, SL1 might also collect layer-2 topology data that can be used to create correct topology links. However, each discovered interface can be associated with only one topology record of any type. If a conflict exists between the collected CDP topology data and the collected layer-2 topology data, the CDP topology data takes precedence. In the example above, the CDP topology data will be inaccurate, but the layer-2 data might be accurate. Therefore, if your network includes both CDP-enabled and non-CDP network switches and routers, you might want to disable CDP topology collection in the Behavior Settings page (System > Settings > Behavior).

If CDP collection is enabled, SL1 collects information from the Cisco-CDP-MIB from all discovered network switches and routers. SL1 polls devices that have a Device Category of "Network.Switches" (ID 2) or "Network.Routers" (ID 1). The Device Category is defined in the Device Class assigned to the device. Network switches and routers that support the Cisco-CDP-MIB report the IP address and interface information for all directly connected devices that are CDP-enabled.

Although SL1 polls all network switches and routers for CDP information, not all network switches and routers support CDP.

Each discovered interface can be associated with only one topology record of any type. Therefore, the same "crunch" process that creates layer-2 topology records is also responsible for creating the CDP records based on the collected data. However, unlike layer-2 topology records, the Cisco-CDP-MIB reports only directly connected devices. Therefore, if all associated interfaces are valid and available, there is a 1:1 mapping between collected CDP relationships and the CDP relationships created by the "crunch" process.

To view CDP maps, go to the Subnet Map (CDP) page (Views > Topology Maps >CDP). For details on viewing CDP maps, see the section on viewing CDP maps.

LLDP Topology Collection

An LLDP topology record describes a direct network connection between a parent device (a Network Switch or Network Router) and a child device. LLDP stands for "Link Layer Discovery Protocol," a standard used by networking devices to communicate configuration information to the other devices in the network. Devices that support LLDP store and report information received about their immediate neighbors.

If your network includes both LLDP-enabled and non-LLDP network switches and routers, the topology data reported by the LLDP enabled devices might not be accurate.

Suppose a network includes three switches connected in the following way:

• Switch A and Switch C, which are both LLDP-enabled, broadcast LLDP messages.
• Because Switch B is not LLDP-enabled, the broadcast messages from Switch A will reach Switch C. Therefore, Switch C will report that it is directly connected to Switch A.
• Conversely, the broadcast messages from Switch C will reach Switch A. Therefore, Switch A will report that it is directly connected to Switch C.

In addition to the LLDP data collected from the switches in this example, SL1 might also collect Layer-2 topology data that can be used to create correct topology links. However, each discovered interface can be associated with only one topology record of any type. If a conflict exists between the collected LLDP topology data and the collected Layer-2 topology data, the LLDP topology data takes precedence. In the example above, the LLDP topology data will be inaccurate, but the Layer-2 data might be accurate. Therefore, if your network includes both LLDP-enabled and non-LLDP network switches and routers, you might want to disable LLDP topology collection in the Behavior Settings page (System > Settings > Behavior).

If LLDP collection is enabled, SL1 collects information from the LLDP MIB from all discovered network switches and routers. SL1 polls devices that have a Device Category of "Network.Switches" (ID 2) or "Network.Routers" (ID 1). The Device Category is defined in the Device Class assigned to the device. Network switches and routers that support the Cisco-LLDP-MIB report the IP address and interface information for all directly connected devices that are LLDP-enabled.

Although SL1 polls all network switches and routers for LLDP information, not all network switches and routers support LLDP.

Each discovered interface can be associated with only one topology record of any type. Therefore, the same "crunch" process that creates Layer-2 topology records is also responsible for creating the LLDP records based on the collected data. However, unlike Layer-2 topology records, the -LLDP MIB reports only directly connected devices. Therefore, if all associated interfaces are valid and available, there is a 1:1 mapping between collected LLDP relationships and the LLDP relationships created by the "crunch" process.

Layer-3 Topology Collection

Layer-3 topology records are created by performing a traceroute command from a Data Collector or the All-In-One Appliance to the discovered network hardware every two hours:

• For each "hop" in a traceroute that specifies an IP address associated with a discovered device, SL1 creates a layer-3 topology record that connects the device from the previous hop to the device for the current hop.
• Layer-3 topology records are created only when both devices are discovered; layer-3 topology records are not created when one or both of the two devices is unknown.

• If the IP address associated with a hop is associated with an unknown device, SL1 does not store that hop or any subsequent hops for that traceroute.
• Layer-3 topology records describe only that two devices are connected; layer-3 topology records do not describe which interfaces on those devices are connected.

For SL1 to create layer-3 topology records, the following requirements must be met:

• All traceroute commands for layer-3 topology collection originate from Data Collectors or an All-In-One Appliance. Therefore, the parent node(s) in the layer-3 topology is always a Data Collector or the All-In-One Appliance. For SL1 to create layer-3 topology records, all Data Collectors and All-In-One Appliances must be discovered.

• SL1 performs traceroute commands to devices that have the L3 Topology option enabled. The L3 Topology option is defined in the device class assigned to a device. For SL1 to perform layer-3 topology collection, at least one device in your system must have the L3 Topology option enabled in the device class.
• Your network configuration must allow the traffic generated by the traceroute commands. To test whether your network allows this traffic, go to the Device Toolbox page (by clicking the Toolbox tab in the Device Administration panel) for a device with the L3 Topology option enabled, and then click the Traceroute icon.

A device that has the L3 Topology option disabled can still be associated with a layer-3 topology record. If an IP address associated with a device that has the L3 Topology option disabled appears as a "hop" in a traceroute command performed for a different device, the device with the L3 Topology option disabled will be associated with the layer-3 topology records that represent the hops to and from that device.