Inhalt

Einführung

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

High-Level-Mechanismus

Beispiel 1: Fehler in einem Tenant

Beispiel 2: Physischer Fehler

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.