Sommario

Introduzione

Come viene generato un errore e come impedire in modo selettivo la generazione di errori

Meccanismo di alto livello

Esempio 1 - Errore in un tenant

Esempio 2 - Guasto fisico

Introduzione

In questo documento viene illustrato il processo di alto livello per la generazione di errori ACI (Application Centric Infrastructure) e viene spiegato come evitare la generazione di errori specifici. Il documento lo dimostra con due esempi.

Come viene generato un errore e come impedire in modo selettivo la generazione di errori

Meccanismo di alto livello

1. Ogni errore è un oggetto gestito (MO) della classe faultInst (o faultDelegate). Questo MO difettoso viene generato da un altro MO, in genere il relativo padre, perché alcune regole vengono violate.

2. Ogni MO nella struttura che può generare errori dispone di un attributo monPolDn che punta a un altro MO che è un oggetto criteri di monitoraggio. Questo oggetto consente la modifica della proprietà e la generazione di errori da parte del trigger. Sono disponibili più classi dell'oggetto criteri di monitoraggio, ad esempio:

- monInfraPol - tratta di regole a infrarossi (gestione VMM, policy delle porte di accesso, porte fisiche e così via) - Presente in Fabric > Policy di accesso > Policy di monitoraggio

- monFabricPol - tratta il monitoraggio dei fabric - disponibile in Fabric > Criteri fabric > Criteri di monitoraggio

- monEPGPol - tratta con tenant monitoraggio > situato in Tenant > Monitoring Policy menu

3. In genere si tratta dell'oggetto di monitoraggio predefinito. Tuttavia, andando all'area specifica del modello a oggetti è possibile creare un criterio di monitoraggio specifico definito dall'utente per una qualsiasi di tali classi di criteri di monitoraggio.

4. È possibile modificare molte proprietà di tali criteri di controllo. Nell'esempio viene illustrato come è possibile impedire la generazione di un determinato errore per tutti gli oggetti a cui viene applicato il criterio di monitoraggio. Tuttavia, è anche possibile modificare i timer del ciclo di vita di errore (tempo di conservazione, tempo di immersione e così via).

5. Per modificare la gravità dell'errore o impedire che venga generato un errore, è necessario selezionare l'oggetto di monitoraggio corrispondente alla classe dell'oggetto MO che ha generato l'oggetto (ad esempio, padre dell'errore).

6. In questa classe, scegliere il codice di errore che si desidera modificare e scegliere una gravità iniziale di valore "squelched".

In questo modo si evita che eventuali errori del codice vengano generati dall'MO assegnato a questo criterio di monitoraggio specifico.

Esempio 1 - Errore in un tenant

Ogni errore è associato a un oggetto.

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

L'errore precedente è un MO di classe fault.Inst con codice F0879.

L'errore è associato a un oggetto Endpoint Group (EPG) come illustrato di seguito.

Questo oggetto è il nome distinto (DN) del padre dell'errore. L'oggetto padre è di classe 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

L'oggetto EPG è associato a un oggetto monPolDn. La maggior parte degli oggetti nella struttura è monitorata da un oggetto di monitoraggio.

Di seguito è riportato un oggetto di monitoraggio definito dall'utente della classe monEPGPol con dn.

uni/tn-RD/monepg-RD_Monitoring

Di seguito è riportato l'oggetto completo utilizzato per il monitoraggio.

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

L'oggetto monEPGPol è configurato in Criteri di monitoraggio tenant, in cui è possibile creare un nuovo criterio o modificare quello predefinito. Di seguito è riportato un esempio del nome RD_Monitoring di monEPGPol.

È possibile scegliere i criteri di assegnazione Gravità errore e fare clic sulla matita accanto all'oggetto Monitoraggio.

Se quindi si sceglie nell'elenco degli oggetti di monitoraggio di tale criterio di monitoraggio, la classe per cui è stato creato l'errore (qui dbgac.RsToEpg).

È possibile visualizzare tutti gli errori associati alla classe specifica (l'unico visualizzato è F0789).

Il codice di errore F0789 è il codice di errore visualizzato all'inizio dell'esempio.

È possibile scegliere questo errore e, se si imposta una gravità iniziale su squelched (è possibile lasciare che la gravità della destinazione erediti), impedisce che tale errore venga generato in futuro con la presunzione che sia generato da un oggetto che ha un collegamento al criterio di monitoraggio appena modificato.

Tuttavia, non eliminerà i difetti esistenti, ma solo quelli nuovi.

Esempio 2 - Guasto fisico

Nell'esempio, il guasto è generato perché la porta 1/25 sulla foglia è admin up ma non contiene SFP.

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              :

È associato a una porta fisica. Ecco l'MO padre che ha generato l'errore.

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

Questo elemento è associato all'oggetto monInfraPol configurato come mostrato di seguito.

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

Nel criterio Assegnazione gravità errore fare clic sulla matita nel riquadro di lavoro, accanto all'elenco a discesa Oggetto di monitoraggio. Aggiungere una classe in cui modificare le proprietà di controllo. Scegliere quindi la classe dell'oggetto che ha generato l'errore, ovvero ethmPhysIf.

Scegliere questa classe e fare clic sull'icona + per visualizzare ogni errore generato per l'oggetto.

In questo esempio è possibile vedere l'errore F1678 e modificarne le proprietà. Se si sceglie Gravità iniziale Squelched e Gravità destinazione inherit, i nuovi errori di tale codice non verranno generati dall'oggetto a cui è applicato questo criterio di monitoraggio.

Dopo aver apportato la modifica, se si abilita la porta 1/25 senza SFP, non verranno generati errori.

Nota: nelle versioni precedenti alla 2.2: Gli errori esistenti (anche in modalità di conservazione Cancellazione) non verranno cancellati.

Nota: nel software versione 2.2 e successive: Anche i difetti esistenti saranno influenzati dalla nuova politica.