Como as falhas da ACI são geradas e como evitar que falhas sejam geradas de forma seletiva

Introduction

Este documento explica o processo de alto nível de geração de falhas da Application Centric Infrastructure (ACI) e como evitar que uma falha específica seja gerada. O documento demonstra isso com dois exemplos.

Como uma falha é gerada e como evitar que falhas sejam geradas de forma seletiva

Mecanismo de alto nível

1. Cada falha é um objeto gerenciado (MO) de class failureInst (ou farelateDelegate). Essa falha de MO é gerada por outro MO, geralmente seu pai, porque algumas regras são violadas.
2. Cada MO na árvore que pode gerar falhas tem um atributo monPolDn que aponta para outro MO que é um objeto de política de monitoramento. Este objeto permite que a propriedade seja modificada e o acionador gere falhas. Há várias classes do objeto de política de monitoramento, como:
   • monInfraPol - trata da política de infra (gerenciador de VMM, política de porta de acesso, portas físicas, etc.) - Localizado em Estrutura > Políticas de acesso > Políticas de monitoramento
   • monFabricPol - trata do monitoramento de malha - localizado em Fabric > Fabric Policies > Monitoring policies
   • monEPGPol - trata de monitoramento de usuários > localizado em Espaço > menu Política de monitoramento
3. Geralmente, será o objeto de monitoramento padrão. No entanto, ao ir para a área específica do modelo de objeto, você pode criar uma política de monitoramento definida pelo usuário específica para qualquer uma dessas classes de política de monitoramento.
4. Você pode modificar muitas propriedades dessas políticas de monitoramento. O exemplo mostrará como você pode impedir que uma determinada falha seja gerada para todos os objetos aos quais a política de monitoramento é aplicada. No entanto, você também pode modificar os temporizadores do ciclo de vida das falhas (tempo de retenção, tempo de saturação e assim por diante).
5. Para modificar a gravidade da falha ou impedir que uma falha seja gerada, você precisa selecionar o objeto de monitoramento que corresponde à classe do MO que gerou esse objeto (por exemplo, pai da falha).
6. Em seguida, nessa classe, escolha o código de falha que deseja modificar e escolha uma gravidade inicial do valor "agrupado".

Isso evita que qualquer falha nesse código seja gerada pelo MO atribuído a essa política de monitoramento específica.

Exemplo 1 - Falha em um espaço

Cada falha está associada a um objeto.

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

A falha anterior é um MO de falha de classe.Inst e com código F0879.

A falha está associada a um objeto EPG (Endpoint Group, grupo de endpoints), como mostrado a seguir.

Este objeto é o nome distinto (DN) do pai da falha. Este objeto pai é da 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

Você pode ver que este objeto EPG está associado a um objeto monPolDn. A maioria dos objetos na árvore é monitorada por um objeto de monitoramento.

Aqui está um objeto de monitoramento definido pelo usuário da classe monEPGPol com dn.

uni/tn-RD/monepg-RD_Monitoring

Aqui está o objeto completo usado para monitoramento.

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

O objeto monEPGPol é configurado na Política de Monitoramento do espaço, onde você pode criar uma nova política ou modificar a padrão. Aqui está um exemplo do nome monEPGPol RD_Monitoring.

Você pode escolher as políticas de atribuição de Gravidade de Falha e clicar no lápis (ao lado do objeto Monitoramento).

Em seguida, se você escolher na lista de objetos de monitoramento dessa política de monitoramento, a classe para a qual a falha foi criada (aqui dbgac.RsToEpg).

Você pode ver todas as falhas associadas a essa classe específica (a única mostrada aqui é F0789).

A falha F0789 é o código do mostrador de falha no início do exemplo.

Você pode escolher essa falha e se definir uma Gravidade inicial como gerada (você pode deixar a Severidade do Alvo herdada), ela impedirá que tal falha seja gerada no futuro com a presunção de que ela é gerada por um objeto que tem um link com a política de monitoramento que você acabou de modificar.

No entanto, não irá eliminar as falhas existentes, mas apenas novas falhas.

Exemplo 2 - Falha física

Neste exemplo, a falha é gerada porque a porta 1/25 no leaf é admin up, mas sem 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              : 

Isso está associado a uma porta física. Aqui está o MO pai que gerou essa falha.

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

Isso é associado ao objeto monInfraPol configurado conforme mostrado aqui.

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

Na política Atribuição de severidade de falha, clique no lápis no painel de trabalho, ao lado da lista suspensa objeto de monitoramento. Adicione uma classe onde você modifique as propriedades de monitoramento. Em seguida, escolha a classe do objeto que gerou a falha, ou seja, ethmPhysIf.

Escolha essa classe e clique no ícone + para ver cada falha gerada para esse objeto.

Neste exemplo, você pode ver a falha F1678 e suas propriedades podem ser modificadas. A escolha da severidade inicial gerada e da severidade de destino inerente impede que novas falhas desse código sejam geradas do objeto que tem essa política de monitoramento aplicada.

Depois de fazer a alteração, se você habilitar a porta 1/25 sem SFP nela, ela não gerará nenhuma falha!

Nota: Em versões anteriores à versão de software 2.2: As falhas existentes (mesmo no modo Limpeza de retenção) não serão eliminadas.

Nota: No Software Versão 2.2 e posterior: Mesmo as falhas existentes serão afetadas pela nova política.