Generieren von ACI-Fehlern und selektives Verhindern der Generierung von Fehlern

Einführung

In diesem Dokument wird der allgemeine Prozess der Fehlergenerierung für die Application Centric Infrastructure (ACI) erläutert. Außerdem wird erläutert, wie verhindert werden kann, dass ein bestimmter Fehler generiert wird. Das Dokument veranschaulicht dies anhand von zwei Beispielen.

Generieren eines Fehlers und Gewusst wie die Generierung von Fehlern mithilfe von Auswahlen verhindert wird

High-Level-Mechanismus

1. Jeder Fehler ist ein Managed Object (MO) der Klasse errorInst (oder errorDelegate). Diese Fehler-MO wird von einer anderen MO, in der Regel deren Eltern, generiert, da einige Regeln verletzt werden.
2. Jeder MO in der Struktur, der Fehler generieren kann, verfügt über ein Attribut monPolDn, das auf einen anderen MO verweist, der ein Überwachungsrichtlinienobjekt ist. Dieses Objekt ermöglicht das Ändern der Eigenschaft und das Generieren von Fehlern durch den Trigger. Es gibt mehrere Klassen des Überwachungsrichtlinienobjekts, z. B.:
   • monInfraPol - behandelt Infra-Richtlinien (VMM-Manager, Zugriffsportrichtlinie, physische Ports usw.) - In Fabric > Zugriffsrichtlinien > Überwachungsrichtlinien
   • monFabricPol - befasst sich mit der Fabric-Überwachung - in Fabric > Fabric-Richtlinien > Überwachungsrichtlinien
   • monEPGPol - behandelt Tenants Monitoring > unter Tenant > Überwachungsrichtlinien
3. Normalerweise ist es das Standardüberwachungsobjekt. Wenn Sie jedoch zum spezifischen Bereich des Objektmodells wechseln, können Sie eine spezifische benutzerdefinierte Überwachungsrichtlinie für eine dieser Überwachungsrichtlinienklassen erstellen.
4. Sie können viele Eigenschaften dieser Überwachungsrichtlinien ändern. Im Beispiel wird gezeigt, wie Sie verhindern können, dass ein bestimmter Fehler für alle Objekte generiert wird, für die die Überwachungsrichtlinie angewendet wird. Sie können jedoch auch die Lebenszyklus-Timer für Fehler (Aufbewahrungszeit, Speicherzeit usw.) ändern.
5. Um den Schweregrad von Fehlern zu ändern oder die Generierung eines Fehlers zu verhindern, müssen Sie das Überwachungsobjekt auswählen, das der Klasse der MO entspricht, die dieses Objekt generiert hat (z. B. übergeordneter Fehler).
6. Wählen Sie dann unter dieser Klasse den Fehlercode aus, den Sie ändern möchten, und wählen Sie einen anfänglichen Schweregrad von Wert "gequelft" aus.

Dadurch wird verhindert, dass Fehler mit diesem Code von der MO generiert werden, die dieser spezifischen Überwachungsrichtlinie zugewiesen ist.

Beispiel 1: Fehler in einem Tenant

Jeder Fehler ist einem Objekt zugeordnet.

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          : 2015-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   : 2015-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

Der vorherige Fehler ist ein MO der Klassenfehler.Inst und mit Code F0879.

Der Fehler ist einem Endpoint Group (EPG)-Objekt (Endpoint Group) zugeordnet, wie nachfolgend gezeigt.

Dieses Objekt ist der DN (Distinguished Name) des übergeordneten Fehlers. Dieses übergeordnete Objekt ist der Klasse dbg.RsToEpg.

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

Sie können sehen, dass dieses EPG-Objekt einem monPolDn-Objekt zugeordnet ist. Die meisten Objekte in der Struktur werden von einem Überwachungsobjekt überwacht.

Es folgt ein benutzerdefiniertes Überwachungsobjekt der Klasse monEPGPol mit dn.

uni/tn-RD/monepg-RD_Monitoring

Hier ist das vollständige Objekt, das für die Überwachung verwendet wird.

admin@apic:~> moquery -d uni/tn-RD/monepg-RD_Monitoring
Total Objects shown: 1

# mon.EPGPol
name         : RD_Monitoring
childAction  :
descr        :
dn           : uni/tn-RD/monepg-RD_Monitoring
lcOwn        : local
modTs        : 2014-11-13T15:41:45.326+01:00
monPolDn     : uni/tn-RD/monepg-RD_Monitoring
ownerKey     :
ownerTag     :
rn           : monepg-RD_Monitoring
status       :
uid          : 10673

Das monEPGPol-Objekt wird unter der Tenant-Überwachungsrichtlinie konfiguriert, in der Sie entweder eine neue Richtlinie erstellen oder die Standardrichtlinie ändern können. Hier ein Beispiel für den monEPGPol-Namen RD_Monitoring.

Sie können die Richtlinien für die Zuweisung des Schweregrads auswählen und auf den Bleistift (neben dem Überwachungsobjekt) klicken.

Wenn Sie dann in der Überwachungsobjektliste dieser Überwachungsrichtlinie die Klasse auswählen, für die der Fehler erstellt wurde (hier dbgac.RsToEpg).

Sie können alle Fehler sehen, die dieser bestimmten Klasse zugeordnet sind (das einzige hier abgebildete Fehler ist F0789).

Der Fehler F0789 ist der am Anfang des Beispiels angezeigte Fehlercode.

Sie können diesen Fehler auswählen. Wenn Sie einen anfänglichen Schweregrad auf "gequelscht" (Sie können Target Severity erben lassen) festlegen, verhindert dies, dass dieser Fehler in Zukunft generiert wird, vorausgesetzt, dass er von einem Objekt generiert wird, das einen Link zu der Überwachungsrichtlinie hat, die Sie gerade geändert haben.

Allerdings werden bestehende Fehler nicht behoben, sondern nur neue Fehler.

Beispiel 2: Physischer Fehler

In diesem Beispiel wird der Fehler generiert, da der Port 1/25 auf dem Leaf zwar aktiv ist, aber kein SFP enthält.

admin@apic:~> moquery -c faultInst -f 'fault.Inst.code == "F1678"'
Total Objects shown: 2

# fault.Inst
code             : F1678
ack              : no
cause            : port-failure
changeSet        : usage (New: epg)
childAction      :
created          : 2015-01-19T14:26:13.862+01:00
descr            : TEST FAULT -- Port is down, reason:sfpAbsent(connected), used by:EPG,
 lastLinkStChg:1970-01-01T01:00:00.000+01:00, operSt:down
dn               : topology/pod-1/node-101/sys/phys-[eth1/25]/phys/fault-F1678
domain           : access
highestSeverity  : critical
lastTransition   : 2015-01-19T14:28:41.668+01:00
lc               : raised
modTs            : never
occur            : 1
origSeverity     : critical
prevSeverity     : critical
rn               : fault-F1678
rule             : ethpm-if-port-down-infra-epg-test
severity         : critical
status           : 
subject          : port-down
type             : communications
uid              : 

Dies ist einem physischen Port zugeordnet. Hier ist die übergeordnete MO, die diesen Fehler generiert hat.

admin@apic:~> moquery -d topology/pod-1/node-101/sys/phys-[eth1/25]/phys
Total Objects shown: 1

# ethpm.PhysIf
accessVlan         : vlan-1
allowedVlans       :
backplaneMac       : 50:87:89:A2:2A:C1
bundleBupId        : 1
bundleIndex        : unspecified
cfgAccessVlan      : vlan-1
cfgNativeVlan      : vlan-1
childAction        :
currErrIndex       : 4294967295
diags              : none
dn                 : topology/pod-1/node-101/sys/phys-[eth1/25]/phys
encap              : 3
errDisTimerRunning : no
errVlanStatusHt    : 0
errVlans           :
hwBdId             : 0
intfT              : phy
iod                : 29
lastErrors         : 0
lastLinkStChg      : 1970-01-01T01:00:00.000+01:00
media              : 2
modTs              : never
monPolDn           : uni/infra/moninfra-default
nativeVlan         : vlan-1

Dies ist mit dem monInfraPol-Objekt verknüpft, das wie hier gezeigt konfiguriert wurde.

admin@apic:~> moquery -c monInfraPol
Total Objects shown: 4

# mon.InfraPol
name         : default
childAction  :
descr        :
dn           : uni/infra/moninfra-default
lcOwn        : local
modTs        : 2014-08-06T07:58:19.494+01:00
monPolDn     : uni/infra/moninfra-default
ownerKey     :
ownerTag     :
rn           : moninfra-default
status       :
uid          : 0

Klicken Sie unter der Richtlinie für die Zuweisung eines Schweregrads auf den Bleistift im Arbeitsbereich neben der Dropdownliste Überwachungsobjekt. Fügen Sie eine Klasse hinzu, in der Sie die Überwachungseigenschaften ändern. Wählen Sie dann die Klasse des Objekts aus, das den Fehler generiert hat, d. h. ethmPhysIf.

Wählen Sie diese Klasse, und klicken Sie auf das Symbol +, um die einzelnen für das Objekt generierten Fehler anzuzeigen.

In diesem Beispiel wird der Fehler F1678 angezeigt, und seine Eigenschaften können geändert werden. Durch Auswahl von Initial Severity Squelyed (Initialer Schweregrad) und Target Severity (Zielschweregrad) wird verhindert, dass neue Fehler dieses Codes von dem Objekt generiert werden, für das diese Überwachungsrichtlinie angewendet wurde.

Wenn Sie nach der Änderung Port 1/25 ohne SFP aktivieren, werden keine Fehler generiert!

Hinweis: In Versionen vor der Softwareversion 2.2: Bestehende Fehler (auch im Clearing-Speichermodus) werden nicht gelöscht.

Hinweis: In Software-Version 2.2 und höher: Selbst bestehende Fehler werden von der neuen Richtlinie betroffen sein.