ON THIS PAGE
Understand Root Cause Analysis
Paragon Automation monitors network resources — such as devices, interfaces, protocols, and label switched paths — through rules deployed in the network. Rules capture specific metrics called key performance indicators (KPI) for the network resources. Paragon Automation generates separate alarms when different KPIs experience an anomaly or an error. These alarms do not establish a causal relationship between two error events.
To find the root cause of multiple errors, Paragon Automation must first link rules to their corresponding resource. For example, the rules that monitor temperature must be linked to the chassis resource or rules that monitor interface admin status must be linked to the interface resource. Users can link a rule to a resource when a they configure a new resource or clone a system-generated resource. Secondly, Paragon Automation must perform root cause analysis by checking if an error in one resource leads to an error in another. To enable Paragon Automation to perform root cause analysis, you must configure dependency for the resources.
When Paragon Automation finds the root cause of several error events, it combines the alarms generated for these events into a top-down hierarchy based on the causal relationship between the events. Such a combined set of alarms is called a smart alarm.
Terms
The following list has frequently used terms and concepts connected with resources:
-
Resource—A resource is a specific component that constitute the network.
For example, chassis, line card, protocols, system memory, interfaces, and so on.
-
Resource Instance—Resources such as an interface, Flexible PIC Concentrators (FPC), router ids, or virtual private networks can have many instances. An instance is a specific realization of the resource. For example, an interface includes instances such as ge-0/0/1, et-1/0/0, xe-2/0/1, and so on.
-
Property—Properties define unique characteristics of a resource. A property is comparable to fields in rules.
For example, neighbor-id and maximum transmission unit (MTU) are characteristics of routing-options resource and interface resource, respectively.
Neighbor id is a unique characteristic of protocol OSPF as a resource.
-
Key property in resource— A key property uniquely identifies all instances of a resource.
For example, <variable>interface-name</variable> property uniquely identifies interface resource instance with name ge-0/0/0 from other instances. MTU cannot be a unique property.
-
Resource Dependency—Defines the relationship between two resources.
-
Dependent resource—In a resource dependency, a dependent resource is the one that depends on another resource. In a single-level resource dependency, a dependent resource is a child resource of another resource.
-
Dependency resource—In a resource dependency, a dependency resource is the one that impacts another resource. In a single-level resource dependency, a dependent resource is a parent resource of another resource.
Resources
A resource can be part of a device or the network. Device resources can be an interface, Flexible PIC Concentrator (FPC), chassis, OSPF, etc. Network resources are resources that span multiple devices in a network, such as IPSec tunnels, VPN, etc.
As with rules, you configure resources under the topic hierarchy in Paragon Automation. The resource properties are derived from rules. When you configure interface as a resource, you can choose the specific interface rules from which Paragon Automation detects a particular interface resource property. The exact rules you select to identify a resource depend on your use case.
When you configure a resource property (such as interface name or MTU), you can refer multiple rules where the values configured for the property are different. A resource property aggregates instances from referenced rules.
Resource Dependencies
Resource dependency defines the relationship between a dependent resource (child resource) and a dependency resource (parent resource). While configuring dependency, you begin with a dependent resource and refer dependency resources that the child resource depends on. A dependency configuration also has terms that contain the logic to map dependency between two resources.
There are three types of dependency based on the type of resources involved, as described in Table 1. You can define dependencies between resources in the same device (Local Device and Network), between resources in different devices (Other Device), between a network resource to another network resource (Other Network), and a network resource to a device resource (Other Device).
| Local Device and Network | Other Device | Other Network Group |
|---|---|---|
| Interface → line card | Interface 1 (device 1) → interface 2 (device 2) | VPN → interface 1 (device 1) |
| Line card → chassis | OSPF (device 1) → OSPF (device 2) | VPN → IPSec tunnel |
You can configure multiple single-level dependencies for a resource. Consider the following chains of dependencies:
- VPN → LSP → interface → Line card
- VPN → interface → Line card
When you configure VPN as a resource, you can define VPN’s dependency on Label Switched Paths (LSPs) as one dependency and VPN’s dependency on interface as a second dependency. For LSP as a resource, you can define its dependency on interface. For interface as a resource, you can define its dependency on line card.
A dependency term logic can involve checking parts of a dependent (child) resource property with parts of dependency (parent) resource's property, checking all instances of the dependency (parent) resource, checking all devices that have dependency (parent) resource instances, checking all or specific device groups, and checking all or specific network groups. Paragon Automation supports matches-with and user-defined functions for dependency logic.
As dependency configurations can involve complex operations, Paragon Automation also allows you to execute such operations in a function. The function returns a Boolean value that can be used to check if a dependency exists between resources.
Use Cases
Resource and dependency configurations serve the following use cases:
-
Root cause analysis — You can understand the root cause of a failure in your network. Refer the resource dependencies and use the relationship between resources to diagnose alerts generated by triggers in rules.
-
Smart alarms — Through smart alarms, Paragon Automation links several resources that have a failure to another resource that is the cause of the failure.