Contenu

Introduction

Comment générer une erreur et comment empêcher la génération des erreurs de manière sélective

Mécanisme de haut niveau

Exemple 1 - Défaillance dans un locataire

Exemple 2 - Défaillance physique

Introduction

Ce document explique le processus de haut niveau de génération de pannes ACI (Application Centric Infrastructure) et comment empêcher la génération d'une pannes spécifique. Le document en donne deux exemples.

Comment générer une erreur et comment empêcher la génération des erreurs de manière sélective

Mécanisme de haut niveau

1. Chaque erreur est un objet managé (MO) de la classe failInst (ou failleDelegate). Ce MO de panne est généré par un autre MO, généralement son parent, car certaines règles sont violées.

2. Chaque MO de l'arborescence qui peut générer des erreurs a un attribut monPolDn qui pointe vers un autre MO qui est un objet de stratégie de surveillance. Cet objet permet de modifier la propriété et de générer des pannes. Il existe plusieurs classes de l'objet de stratégie de surveillance, telles que :

- monInfraPol - traite de la stratégie d'infrastructure (gestionnaire VMM, stratégie de port d'accès, ports physiques, etc.) - Situé dans Fabric > Politiques d'accès > Stratégies de surveillance

- monFabricPol - traite de la surveillance du fabric, situé dans Fabric > Fabric Policies > Monitoring policies

- monEPGPol - traite de la surveillance des locataires > située dans le menu Tenant > Stratégie de surveillance

3. Il s'agit généralement de l'objet de surveillance par défaut. Cependant, en accédant à la zone spécifique du modèle objet, vous pouvez créer une stratégie de surveillance définie par l'utilisateur spécifique pour l'une de ces classes de stratégie de surveillance.

4. Vous pouvez modifier de nombreuses propriétés de ces stratégies de surveillance. L'exemple montre comment vous pouvez empêcher la génération d'un défaut donné pour tous les objets auxquels la stratégie de surveillance est appliquée. Cependant, vous pouvez également modifier les temporisateurs de cycle de vie des pannes (temps de rétention, temps de stabilisation, etc.).

5. Afin de modifier la gravité d'une erreur ou d'empêcher la génération d'une erreur, vous devez sélectionner l'objet de surveillance qui correspond à la classe du MO qui a généré cet objet (par exemple, parent de l'erreur).

6. Ensuite, sous cette classe, choisissez le code d'erreur que vous voulez modifier et choisissez une gravité initiale de la valeur “ squelched ”.

Ceci empêche toute erreur avec ce code d'être générée par le MO affecté à cette stratégie de surveillance spécifique.

Exemple 1 - Défaillance dans un locataire

Chaque erreur est associée à un objet.

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

La défaillance précédente est un MO de classe de défaillance.Inst et avec le code F0879.

La défaillance est associée à un objet EPG (Endpoint Group), comme indiqué ci-après.

Cet objet est le nom unique (DN) du parent de la défaillance. Cet objet parent est de la 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

Vous pouvez voir que cet objet EPG est associé à un objet monPolDn. La plupart des objets de l'arborescence sont surveillés par un objet de surveillance.

Voici un objet de surveillance défini par l'utilisateur de class monEPGPol avec dn.

uni/tn-RD/monepg-RD_Monitoring

Voici l'objet complet utilisé pour la surveillance.

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'objet monEPGPol est configuré sous la stratégie de surveillance du locataire, où vous pouvez créer une nouvelle stratégie ou modifier la stratégie par défaut. Voici un exemple du nom monEPGPol RD_Monitoring.

Vous pouvez choisir les stratégies d'affectation de gravité des pannes et cliquer sur le crayon (en regard de l'objet Surveillance).

Ensuite, si vous choisissez dans la liste des objets de surveillance de cette stratégie de surveillance, la classe pour laquelle l'erreur a été créée (ici dbgac.RsToEpg).

Vous pouvez voir toutes les erreurs associées à cette classe spécifique (la seule représentée ici est F0789).

La faute F0789 est le code de la défaillance affichée au début de l'exemple.

Vous pouvez choisir cette erreur et si vous affectez à une gravité initiale la valeur squelched (vous pouvez laisser la gravité cible hériter), elle empêche qu'une telle erreur soit générée à l'avenir avec la présomption qu'elle est générée par un objet qui a un lien vers la stratégie de surveillance que vous venez de modifier.

Cependant, il ne supprimera pas les défauts existants, mais seulement les nouveaux défauts.

Exemple 2 - Défaillance physique

Dans cet exemple, la défaillance est générée car le port 1/25 sur leaf est admin up mais sans 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              :

Ceci est associé à un port physique. Voici le MO parent qui a généré cette erreur.

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

Ceci est associé à l'objet monInfraPol configuré comme indiqué ici.

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

Sous la stratégie Affectation de gravité des pannes, cliquez sur le crayon dans le volet de travail, en regard de la liste déroulante des objets de surveillance. Ajoutez une classe dans laquelle vous modifiez les propriétés de surveillance. Choisissez ensuite la classe de l'objet qui a généré la faute, c'est-à-dire ethmPhysIf.

Choisissez cette classe et cliquez sur l'icône + afin de voir chaque erreur générée pour cet objet.

Dans cet exemple, vous pouvez voir la défaillance F1678 et ses propriétés peuvent être modifiées. Choisir la gravité initiale L'héritage de gravité de la cible et de la gravité de la cible empêche la génération de nouveaux défauts de ce code à partir de l'objet auquel cette stratégie d'analyse est appliquée.

Après avoir effectué la modification, si vous activez le port 1/25 sans SFP dedans, il ne générera pas de pannes !

Remarque : dans les versions antérieures à la version 2.2 du logiciel : Les pannes existantes (même en mode Effacement) ne seront pas effacées.

Remarque : dans les versions 2.2 et ultérieures du logiciel : Même les défauts existants seront affectés par la nouvelle politique.