Submit a ticketCall us

Get a crash course on Network Monitoring delivered right to your inbox
This free 7-day email course provides a primer to the philosophy, theory, and fundamental concepts involved in IT monitoring. Lessons will explain not only how to perform various monitoring tasks, but why and when you should use them. Sign up now.

Home > Success Center > User Device Tracker (UDT) > UDT Administrator Guide > Manage groups and dependencies > Manage dependencies

Manage dependencies

Table of contents
No headers
Created by Steven Bansil_ret, last modified by Steven Bansil_ret on Jan 26, 2017

Views: 27 Votes: 0 Revisions: 2

Dependencies in Orion Platform allow you to account for topological constraints on your network. These constraints may be either the result of the design of a specific device, as in the case of interfaces on a switch or router, or the result of the physical architecture of your network itself. Orion Platform offers an Unreachable status to account for the case when a device may appear to be down when its status is actually indeterminate, due to another device being down or unresponsive.

For example, in the case of a typical switch monitored by SolarWinds NPM, when the switch itself goes down or becomes unresponsive, all interfaces on the switch will also be unresponsive, even though they may functioning perfectly well. By default, in SolarWinds NPM these child interfaces display as Unreachable because their parent node is reporting as down.

Likewise, Orion Platform also makes it possible to define dependencies among distinct devices, as in the case of a subnet of devices on your network that depends on a single WAN link to connect with the rest of your network. In this case, if you have defined a group consisting of the devices in this dependent subnet, you can then define a dependency where the dependent subnet is a child group to the parent router that is serving as the WAN link to the rest of your network.

The power of dependencies becomes evident when considering alerts. If you have an alert configured to trigger when a monitored object is down, you only want that alert to trigger if a monitored objects is positively down. In other words, you do not want an down object alert to trigger for an object that is not actually down. Without dependencies, all monitored objects on a monitored node that is unresponsive to ICMP queries will also report as down. With dependencies in use, these child objects will instead display as Unreachable, saving you the hassle of sorting through numerous false alerts resulting from the failure of a single node to respond promptly to a status query.

Interfaces may be defined as parent objects, but they cannot be defined as child objects. SolarWinds NPM determines interface status directly by polling parent nodes. If the node on which an interface exists goes down, SolarWinds NPM automatically reports any and all interfaces on that node as unreachable.

 
Last modified
19:38, 25 Jan 2017

Tags

Classifications

Public