Generazione degli errori ACI e prevenzione selettiva della generazione degli errori ACI

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.