3.13 Network Dependencies and Alerting AutoNOC supports the ability to detect and resolve device and protocol dependencies for the purpose of adapting probe behavior. For instance, consider the situation where a switch that is located between the AutoNOC portal and a large remote network becomes unavailable. In that situation, as an example, a probe that makes use of the ICMP/Ping protocol that was monitoring the remote network would trigger a large number of ping alerts. This is an undesireable behavior because it is really only the switch that has gone down. AutoNOC's dependency handling capability, when properly setup, helps to insure that in this case, and in other similar cases, 3.13.1 Requirements for Proper Behavior The following are the main requirements for making this behavior work properly: Portal Device Selected For dependency resolution to work, AutoNOC must know which device in the network model it is. The Portal Setup dialog under the Configure tab includes an option for selecting the portal device. Once this is selected, dependency resoution will be enabled.   Properly Defined Device Links AutoNOC must have a valid device link model in order to dependency resolutions. It is important that each interface have a proper link record to the interface it is connected to. Each interface in the Design tab under a device has a Link which specifies which remote interface the device is connected. Make sure these are setup properly.   Probe Template Service Levels Defined The dependency capability is implemented in a manner such that a probe can detect if it is currently blocked in terms of the service level. This gives a great deal of flexibility in terms of what a user might like to do without much complexity. n most cases, the default AutoNOC templates have properly defined probe template service levels, but users may wish to make use of this capability on their own. 3.13.2 Device Dependency Status The device dialog includes the Stacks tab which shows the current acquisition stacks as well as the status of the dependency path for the current device with respect to the portal. This is shown in the following diagram. In the above case, dragon is the AutoNOC portal and Laptop on WLAN is the current device. If the WAP device goes down or the Switch device goes down, then with a probe that makes use of dependency it will return a different service level in this case. 3.13.3 Using Dependency in Service Levels Dependency in AutoNOC is handled at the point of analyzing data for a service level. The dependency capability of AutoNOC includes two functions that can be used with service levels IsDeviceBlocked and IsDeviceDead. IsDeviceBlocked analyzes the path to the portal to determine if there are any devices between this device and the AutoNOC portal that are flagged dead. If there are, this function returns TRUE. IsDeviceDead is not normally used, but it returns the dead flag on the current device. The screenshot above shows that when analyzing the state of a ping probe, if the device is blocked the probe marks the probe as Unreachable. So how does a device know when it is effectively "dead"? Every probe template includes the ability to flag the current device as being dead. The following screenshot shows an example implementation of this for a ping probe. In this case, whenever the ping value is "X" which means a failed ping, the device is marked dead and will mark other related devices blocked. This may seem somewhat complex until it "clicks", however, do not worry too much about it. The default built-in probe templates implement this capability for you in a way that works well in the vast majority of cases. All you really need to be worried about is making sure your model accurately reflects your network.