Fault Severity Assignement in Cisco ACI [Explained and Configuration]
How a Fault is Generated in ACI:
- Each fault is a Managed Object (MO) of class faultInst (or faultDelegate). This fault MO is generated by another MO, usually its parent, because some rules are violated.
- Each MO in the tree that can generate faults has an attribute monPolDn which points to another MO which is a monitoring policy object. This object allows the property to be modified and the trigger to generate faults.
There are multiple classes of the monitoring policy object, such as:
- monInfraPol: deals with infra policy (VMM manager, access port policy, physical ports, and so on) – Located in Fabric > Access Policies > Monitoring policies
- monFabricPol: deals with fabric monitoring – located in Fabric > Fabric Policies > Monitoring policies
- monEPGPol: deals with tenants monitoring > located in Tenant > Monitoring Policy menu
Let’s check a fault example from Cisco documentation in ACI to illustrate this:
- The fault is an MO of class fault.Inst and with code F0879.
- From the distinguished name (DN) of the parent of the fault. This parent object is of class dbgac.RsToEpg
dn : uni/tn-RD/ipToEpg-Ext_10.200.1.101/rstoEpg-[uni/tn-RD/ap-App_RD1/epg-EPG_RD11]/fault-F0879
admin@apic:~> moquery -d "uni/tn-RD/ipToEpg-Ext_10.200.1.101/rstoEpg-[uni/tn-RD/ap-App_RD1/epg-EPG_RD11]/fault-F0879" Total Objects shown: 1 # fault.Inst code : F0879 ack : no cause : resolution-failed changeSet : childAction : created : 2022-01-22T00:05:00.286+01:00 descr : Failed to form relation to MO uni/tn-RD/ap-App_RD1/epg-EPG_RD11 of class fvAEPg dn : uni/tn-RD/ipToEpg-Ext_10.200.1.101/rstoEpg-[uni/tn-RD/ap-App_RD1/epg-EPG_RD11]/fault-F0879 domain : infra highestSeverity : warning lastTransition : 2022-01-22T00:05:00.286+01:00 lc : raised modTs : never occur : 1 origSeverity : warning prevSeverity : warning rn : fault-F0879 rule : dbgac-rs-to-epg-resolve-fail
- You can see that this EPG object is associated with a monPolDn object. Most objects in the tree are monitored by a monitoring object.
monPolDn : uni/tn-RD/monepg-RD_Monitoring
admin@apic:~> moquery -d uni/tn-RD/ipToEpg-Ext_10.200.1.101/rstoEpg-[uni/tn-RD/ap-App_RD1/epg-EPG_RD11] Total Objects shown: 1 # dbgac.RsToEpg tDn : uni/tn-RD/ap-App_RD1/epg-EPG_RD11 childAction : dn : uni/tn-RD/ipToEpg-Ext_10.200.1.101/rstoEpg-[uni/tn-RD/ap-App_RD1/epg-EPG_RD11] forceResolve : no lcOwn : local modTs : 2014-12-05T12:56:29.340+01:00 monPolDn : uni/tn-RD/monepg-RD_Monitoring rType : mo rn : rstoEpg-[uni/tn-RD/ap-App_RD1/epg-EPG_RD11] state : missing-target stateQual : none status : tCl : fvAEPg tType : mo uid : 15374
Fault severity assignment ACI:
- You can modify many properties of those monitoring policies. The example will show how you can prevent a given fault from being generated for all objects for which the monitoring policy is applied to. However, you can also modify the fault lifecycle timers (retention time, soaking time, and so on).
- In order to modify fault severity or prevent a fault from being generated, you need to select the monitoring object that corresponds to the class of the MO that generated this object (for example, parent of the fault).
- Then under this class, choose the fault code that you want to modify and choose an initial severity of value “squelched”
* In the previous example, the fault is associated with the following monitoring Policy:
monPolDn : uni/tn-RD/monepg-RD_Monitoring
Fault severity assignment Configuration in ACI:
In order to modify the fault severity related to the Monitoring policy, follow these steps:
- Under Policies, chose “Fault Severity assignment policies”:
- In the action pane click “Modify Fault Severity assignment” :
- click the pencil (next to the Monitoring object)
- Chose the the parent class for which the fault was created (in our example dbgac.RsToEpg):
- Click Submit
- In The monitoring Object, select the Previously selected Object Class, you will see all faults generated by this Parent object with their codes (in my case, i don’t have fault related to this object, it’s just for illustration purposes):
Finally, You can choose this fault and if you set an initial Severity to squelched (you can leave Target Severity to inherit), it prevents such fault from being generated in the future with the presumption that they are generated by an object that has a link to the monitoring policy you just modified.