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

  • 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.



https://www.cisco.com/c/en/us/support/docs/cloud-systems-management/application-policy-infrastructure-controller-apic/200136-How-ACI-Faults-Are-Generated-And-How-To.html

Bilel A

Bilel A

0 0 votes
Article Rating
Subscribe
Notify of
guest
0 Comments
Inline Feedbacks
View all comments
Learn Duty
0
Would love your thoughts, please comment.x
()
x