Comment générer les pannes ACI et comment empêcher la génération des pannes de manière sélective

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.