Contents

Introduction

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

Mecanismo de alto nível

Exemplo 1 - Falha em um espaço

Exemplo 2 - Falha física

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.