Explication des pannes de suppression de paquets dans l'ACI

Introduction

Ce document décrit chaque type de panne et la procédure à suivre lorsque vous voyez cette défaillance. Lors du fonctionnement normal d'un fabric ACI (Application Centric Infrastructure) de Cisco, l'administrateur peut voir des erreurs pour certains types de pertes de paquets.   

Objets gérés

Dans l'ACI Cisco, toutes les défaillances sont soulevées sous Managed Objects (MO). Par exemple, une erreur "F11245 - taux d'abandon des paquets d'entrée(l2IngrPktsAg15min : dropRate) " concerne le paramètre dropRate dans MO l2IngrPktsAg15min.

Cette section présente quelques exemples d'objets gérés (MO) liés aux erreurs de paquets abandonnés.

	Exemple	Description	Exemples de paramètres	Exemple de MO contre Les défauts relevés
l2IngrPkts	l2IngrPkts5min l2IngrPkts15 min l2IngrPkts1h etc...	Cela représente les statistiques de paquets d'entrée par VLAN pendant chaque période	dropRate floodRate multicastRate unicastRate	vlanCktEp (VLAN)
l2IngrPktsAg	l2IngrPktsAg15min l2IngrPktsAg1h l2IngrPktsAg1d  etc...	Ceci représente les statistiques de paquets d'entrée par EPG, BD, VRF, etc. Par exemple) Les statistiques EPG représentent l'agrégation des statistiques VLAN qui appartiennent à l'EPG	dropRate floodRate multicastRate unicastRate	fvAEPg (EPG) fvAp (profil d'application) fvBD (BD) l3extOut (L3OUT)
eqptIngrDropPkts	eqptIngrDropPkts15min eqptIngrDropPkts1h eqptIngrDropPkts1d etc...	Ceci représente les statistiques de paquets d'entrée abandonnés par interface pendant chaque période	*1 forwardingRate *1 errorRate *1 bufferRate	l1PhysIf (port physique) pcAggrIf (port-channel)

*1 : Ces compteurs dans eqptIngrDropPkts peuvent être déclenchés à tort en raison d'une limitation ASIC dans plusieurs plates-formes Nexus 9000, car les paquets SUP_REDIRECT sont consignés en tant que pertes de transfert. Voir aussi CSCvo68407 et CSCvn72699 pour plus de détails et des versions fixes.

Types de compteur de pertes matérielles

Sur les commutateurs Nexus 9000 fonctionnant en mode ACI, il existe 3 compteurs matériels principaux pour la raison de perte d'interface d'entrée sur l'ASIC.

Un dropRate dans l2IngrPkts, l2IngrPktsAg inclut ces compteurs. Trois paramètres (forwardingRate, errorRate, bufferRate) dans la table ci-dessus pour eqptIngrDropPkts représentent chacun trois compteurs d'interface. 

Transférer

Les pertes de transfert sont des paquets qui sont abandonnés sur le bloc LookUp (LU) de l'ASIC. Dans le bloc LU, une décision de transfert de paquets est prise en fonction des informations d’en-tête de paquet. Si la décision est de supprimer le paquet, Forward Drop est compté. Il y a une variété de raisons à cela, mais parlons des principales :

SECURITY_GROUP_DENY

Une baisse en raison de contrats manquants pour permettre la communication.

Lorsqu'un paquet entre dans le fabric, le commutateur examine l'EPG source et de destination pour voir s'il existe un contrat autorisant cette communication.  Si la source et la destination se trouvent dans des groupes de terminaux différents et qu'il n'existe aucun contrat autorisant ce type de paquet entre eux, le commutateur abandonne le paquet et l'étiquette SECURITY_GROUP_DENY. Le compteur Forward Drop est incrémenté.

VLAN_XLATE_MISS

Une perte en raison d'un VLAN inapproprié.

Lorsqu’un paquet entre dans le fabric, le commutateur examine le paquet pour déterminer si la configuration sur le port autorise ce paquet.  Par exemple, une trame entre dans le fabric avec une balise 802.1Q de 10.  Si le commutateur a le VLAN 10 sur le port, il inspectera le contenu et prendra une décision de transfert en fonction de l'adresse MAC de destination.  Cependant, si le VLAN 10 n'est pas sur le port, il l'abandonnera et l'étiquetera comme VLAN_XLATE_MISS.  Le compteur Forward Drop sera incrémenté.  

La raison de XLATE ou Translate est que dans l'ACI, le commutateur leaf prendra une trame avec un encap 802.1Q et la traduira en un nouveau VLAN qui sera utilisé pour VXLAN et d'autres normalisations à l'intérieur du fabric.  Si la trame est fournie avec un VLAN non déployé, la « traduction » échouera.

ACL_DROP

Une goutte à cause de la sup-tcam.

sup-tcam dans les commutateurs ACI contient des règles spéciales à appliquer en plus de la décision normale de transfert L2/L3. Les règles de sup-tcam sont intégrées et ne peuvent pas être configurées par l'utilisateur. L'objectif des règles sup-tcam est principalement de gérer certaines exceptions ou une partie du trafic du plan de contrôle et ne doit pas être contrôlé ou contrôlé par les utilisateurs. Lorsque le paquet atteint les règles sup-tcam et que la règle est de supprimer le paquet, le paquet abandonné est compté comme ACL_DROP et incrémente le compteur Forward Drop. Lorsque cela se produit, cela signifie généralement que le paquet est sur le point d'être transféré par rapport aux principaux de transfert ACI de base.

Notez que, même si le nom d'abandon est ACL_DROP, cette « ACL » n'est pas identique à la liste de contrôle d'accès normale qui peut être configurée sur des périphériques NX-OS autonomes ou tout autre périphérique de routage/commutation.

SUP_REDIRECTION

Ce n'est pas une goutte d'eau.

Un paquet sup redirigé (c'est-à-dire CDP/LLDP/UDLD/BFD, etc...) peut être compté comme Forward Drop même si le paquet est correctement traité et transféré au CPU.

Cela peut se produire uniquement sur la plate-forme -EX telle que N9K-C93180YC-EX. Ces derniers ne doivent pas être considérés comme des pertes, mais c'est en raison de la limitation de l'ASIC dans la plate-forme -EX.

Erreur 

Lorsque le commutateur reçoit une trame non valide sur l’une des interfaces du panneau avant, elle est abandonnée en tant qu’erreur.  Les trames comportant des erreurs FCS ou CRC en sont des exemples. Lorsque vous examinez les ports Leaf de liaison ascendante/descendante, ou les ports Spine, il est préférable de vérifier les erreurs FCS/CRC à l'aide de la commande show interface.
Cependant, dans des opérations normales, il est prévu que les paquets d'erreur s'incrémentent sur les ports de leafs de liaison ascendante/descendante, ou sur les ports Spine, car ce compteur inclut également les trames qui sont élaguées par le système et ne devraient pas être envoyées hors de l'interface.
Exemple : Échecs de durée de vie pour les paquets routés, mêmes trames de diffusion/diffusion d'interface.

Tampon

Lorsque le commutateur reçoit une trame, et qu'aucun crédit de tampon n'est disponible pour l'entrée ou la sortie, la trame est abandonnée avec « Buffer ».  Cela indique généralement une congestion quelque part dans le réseau.  La liaison qui indique la défaillance peut être pleine ou la liaison contenant la destination peut être congestionnée.

Affichage des statistiques de perte dans CLI

Objets gérés

Secure Shell (SSH) vers l'un des APIC et exécutez les commandes suivantes.

apic1# moquery -c l2IngrPktsAg15min

Cela fournira toutes les instances d'objet pour cette classe l2IngrPktsAg15min.

Voici un exemple avec un filtre pour interroger un objet spécifique. Dans cet exemple, le filtre doit afficher uniquement un objet avec attributs dn qui inclut « tn-TENANT1/ap-APP1/epg-EPG1 » .

Cet exemple utilise également egrep pour afficher uniquement les attributs requis.

Exemple de résultat 1 : Objet de compteur EPG (l2IngrPktsAg15min) du locataire TENANT1, profil d'application APP1 , epg EPG1.

apic1# moquery -c l2IngrPktsAg15min -f 'l2.IngrPktsAg15min.dn*"tn-TENANT1/ap-APP1/epg-EPG1"' | egrep 'dn|drop[P,R]|rep'

dn               : uni/tn-TENANT1/ap-APP1/epg-EPG1/CDl2IngrPktsAg15min
dropPer          : 30                              <--- number of drop packet in the current periodic interval (600sec)
dropRate         : 0.050000                        <--- drop packet rate = dropPer(30) / periodic interval(600s)
repIntvEnd       : 2017-03-03T15:39:59.181-08:00   <--- periodic interval = repIntvEnd - repIntvStart
repIntvStart     : 2017-03-03T15:29:58.016-08:00                          = 15:39 - 15:29
                                                                          = 10 min = 600 sec

Ou nous pourrions utiliser une autre option -d au lieu de -c pour obtenir un objet spécifique si vous connaissez l'objet dn.

Exemple de résultat 2 : Objet de compteur EPG (l2IngrPktsAg15min) du locataire TENANT1, profil d'application APP1 , epg EPG2.

apic1# moquery -d uni/tn-TENANT1/ap-APP1/epg-EPG2/CDl2IngrPktsAg15min | egrep 'dn|drop[P,R]|rep'
dn               : uni/tn-jw1/BD-jw1/CDl2IngrPktsAg15min
dropPer          : 30
dropRate         : 0.050000
repIntvEnd       : 2017-03-03T15:54:58.021-08:00
repIntvStart     : 2017-03-03T15:44:58.020-08:00

Compteurs matériels

Si vous constatez des pannes ou si vous voulez vérifier les pertes de paquets sur les ports de commutation à l'aide de l'interface de ligne de commande, la meilleure façon de procéder est d'afficher les compteurs de plate-forme dans le matériel. La plupart des compteurs, mais pas tous, sont affichés avec show interface.  Les trois principales raisons de perte ne peuvent être affichées qu'à l'aide des compteurs de plate-forme.  Pour afficher ces informations, procédez comme suit :

Feuille

SSH à la feuille et exécutez ces commandes.

ACI-LEAF# vsh_lc
module-1# show platform internal counters port <X>
                                                    * où X représente le numéro de port

Exemple de sortie pour Ethernet 1/31 :

ACI-LEAF# vsh_lc
vsh_lc
module-1#
module-1# show platform internal counters port 31
Stats for port 31
(note: forward drops includes sup redirected packets too)
IF          LPort                    Input                       Output
                              Packets       Bytes          Packets    Bytes
eth-1/31    31  Total          400719   286628225      2302918    463380330 
                   Unicast     306610   269471065       453831     40294786 
                   Multicast        0           0      1849091    423087288 
                   Flood        56783     8427482            0            0 
                Total Drops     37327                        0 
                   Buffer           0                        0
                   Error            0                        0
                   Forward      37327
                   LB               0
                   AFD RED                                   0
                       ----- snip -----

Spine

Pour une colonne vertébrale de type boîte (N9K-C9336PQ), c'est exactement la même chose que Feuille.

Pour les modules Spines (N9K-C9504, etc...), vous devez d'abord fixer la carte de ligne particulière avant de pouvoir afficher les compteurs de la plate-forme.  SSH sur la colonne vertébrale et exécutez ces commandes

ACI-SPINE# vsh

Module d'attachement ACI-SPINE# <X>

module-2# show platform internal counters port <Y>.

                             * où X représente le numéro de module de la carte de ligne que vous souhaitez afficher

                                            Y représente le numéro de port

Exemple de sortie pour Ethernet 2/1 :

ACI-SPINE# vsh
Cisco iNX-OS Debug Shell
This shell should only be used for internal commands and exists
for legacy reasons. User should use ibash infrastructure as this
will be deprecated.
ACI-SPINE#
ACI-SPINE# attach module 2
Attaching to module 2 ...
To exit type 'exit', to abort type '$.' 
Last login: Mon Feb 27 18:47:13 UTC 2017 from sup01-ins on pts/1
No directory, logging in with HOME=/
Bad terminal type: "xterm-256color". Will assume vt100.
module-2#
module-2# show platform internal counters port 1
Stats for port 1
(note: forward drops includes sup redirected packets too)
IF          LPort                    Input                       Output
                              Packets       Bytes          Packets    Bytes
eth-2/1      1  Total        85632884  32811563575     126611414   25868913406 
                   Unicast   81449096  32273734109     104024872   23037696345 
                   Multicast  3759719   487617769     22586542   2831217061 
                   Flood            0           0            0            0 
                Total Drops         0                        0 
                   Buffer           0                        0
                   Error            0                        0
                   Forward          0
                   LB               0
                   AFD RED                                   0
                        ----- snip -----

  

Erreurs

F112425 : débit des paquets d'entrée en attente (l2IngrPktsAg15min : dropRate)

Description:

L'une des raisons les plus courantes de cette erreur est que les paquets de couche 2 sont abandonnés avec la raison Forward Drop. Il y a une variété de raisons, mais la plus courante est :

Sur certaines plates-formes (voir CSCvo68407 ), il y a une limite où les paquets de couche 2 qui doivent être redirigés vers le CPU (c'est-à-dire CDP/LLDP/UDLD/BFD, etc), seront enregistrés comme « Forward Drop » et seront copiés sur le CPU. Ceci est dû à une limitation de l'ASIC utilisé dans ces modèles.

Résolution :

Les gouttes décrites ci-dessus sont purement cosmétiques. la recommandation de la meilleure pratique consiste à augmenter le seuil de la défaillance comme indiqué dans la section Seuil de statistiques. Pour ce faire, reportez-vous aux instructions de la section Stats Threshold.

F100264 - Taux de pertes de tampon d'entrée (eqptIngrDropPkts5min : bufferRate)

Description:

Cette panne peut s'incrémenter lorsque des paquets sont abandonnés sur un port avec la raison « Buffer » Comme mentionné ci-dessus, cela se produit généralement lorsqu'il y a un encombrement sur une interface en entrée ou en sortie.

Résolution :

Cette erreur représente les paquets réellement abandonnés dans l'environnement en raison de la congestion.  Les paquets abandonnés peuvent causer des problèmes avec les applications exécutées dans le fabric ACI. Les administrateurs réseau doivent isoler le flux de paquets et déterminer si l'encombrement est dû à des flux de trafic inattendus, à un équilibrage de charge inefficace, etc.; ou l'utilisation prévue sur ces ports.

F100696 - paquets d'abandon de transfert d'entrée (eqptIngrDropPkts5min : forwardingRate)

Note: Une limitation ASIC telle que mentionnée ci-dessus pour F11245 peut également entraîner l'augmentation de ces défauts. Veuillez consulter CSCvo68407 pour plus de détails.

Cette erreur est causée par quelques scénarios. La plus courante est :

Description 1) Décharges de spine

Si cette défaillance est détectée sur une interface Spine, elle peut être due au trafic vers un point d'extrémité inconnu.

Lorsqu'un paquet ARP ou IP est transféré à la colonne vertébrale pour une recherche par proxy et que le point de terminaison est inconnu dans le fabric, un paquet de reconnaissance spécial est généré et envoyé à toutes les feuilles sur l'adresse de groupe de multidiffusion BD (interne) appropriée. Cela déclenchera une requête ARP de chaque feuille du domaine de pont (BD) pour détecter le point de terminaison.  En raison d'une limitation, le paquet glané reçu par la feuille est également réfléchi à nouveau dans le fabric et déclenche une perte de transfert sur la liaison dorsale connectée à la feuille. Le transfert dans ce scénario est incrémenté uniquement sur le matériel de colonne vertébrale de génération 1.

Résolution 1)

Comme il est connu que le problème est causé par l'envoi inutile d'une quantité de trafic de monodiffusion inconnue dans le fabric ACI, il est nécessaire de déterminer quel périphérique est à l'origine de ce problème et de voir s'il est possible de l'empêcher. Cela est généralement dû à des périphériques qui analysent ou analysent les adresses IP des sous-réseaux à des fins de surveillance.  Afin de trouver quelle adresse IP envoie ce trafic, SSH sur la feuille qui est connectée à l'interface de la colonne vertébrale montrant la panne.

À partir de là, vous pouvez exécuter cette commande pour voir l'adresse IP source (sip) qui déclenche le paquet glané :

ACI-LEAF# show ip arp internal event-history event | grep glean | grep sip | more
    [116] TID 11304:arp_handle_inband_glean:3035: log_collect_arp_glean;sip = 192.168.21.150;dip = 192.168.20.100;info = Received glean packet is an IP packet
    [116] TID 11304:arp_handle_inband_glean:3035: log_collect_arp_glean;sip = 192.168.21.150;dip = 192.168.20.100;info = Received glean packet is an IP packet

Dans cet exemple de sortie, le paquet glané est déclenché par 192.168.21.150 et il est recommandé de voir si cela peut être atténué.

Description 2 ) Baisse des feuilles

Si cette erreur est détectée sur une interface leaf, la cause la plus probable est due aux pertes SECURITY_GROUP_DENY mentionnées.  

Résolution 2 )

La feuille ACI conserve un journal des paquets refusés en raison de violations de contrat.Ce journal ne les capture pas tous pour protéger les ressources du processeur, mais il vous fournit toujours une grande quantité de journaux.

Pour obtenir les journaux requis, si l'interface sur laquelle la défaillance est déclenchée fait partie d'un port-channel, il est nécessaire d'utiliser cette commande et grep pour le port-channel. Sinon, l'interface physique peut être récupérée.

Ce journal peut être rapidement restauré en fonction du nombre de pertes de contrat.

ACI-LEAF# show logging ip access-list internal packet-log deny | grep port-channel2 | more
[ Sun Feb 19 14:16:12 2017 503637 usecs]: CName: jr:sb(VXLAN: 2129921), VlanType: FD_VLAN, Vlan-Id: 59, SMac: 0x8c604f0288fc, DMac:0x0022bdf819ff, SIP: 192.168.21.150, DIP: 192.168.20.3, SPort: 0, DPort: 0, Src Intf: port-channel2, Pr
oto: 1, PktLen: 98
[ Sun Feb 19 14:16:12 2017 502547 usecs]: CName: jr:sb(VXLAN: 2129921), VlanType: FD_VLAN, Vlan-Id: 59, SMac: 0x8c604f0288fc, DMac:0x0022bdf819ff, SIP: 192.168.21.150, DIP: 192.168.20.3, SPort: 0, DPort: 0, Src Intf: port-channel2, Pr
oto: 1, PktLen: 98

Dans ce cas, 192.168.21.150 tente d’envoyer des messages ICMP (numéro de protocole IP 1) à 192.168.20.3.  Cependant, il n'y a aucun contrat entre les 2 EPG qui autorise ICMP, de sorte que le paquet est abandonné.  Si le protocole ICMP est censé être autorisé, un contrat peut être ajouté entre les deux groupes de terminaux.

Seuil de statistiques

Cette section décrit comment modifier un seuil pour un objet de statistiques qui peut potentiellement provoquer un défaut par rapport au compteur de dépôt.

Un seuil pour les statistiques de chaque objet (c'est-à-dire l2IngrPkts, eqptIngrDropPkts) sont configurés par la stratégie de surveillance par rapport à divers objets.

Comme indiqué dans le tableau du début, eqptIngrDropPkts est surveillé sous, par exemple, les objets l1PhysIf via la stratégie de surveillance.

Taux de paquets abandonnés de transfert dans eqptIngrDropPkts

Il y a deux parties pour cela.

+ Stratégies d'accès (ports vers les périphériques externes). ports de la façade)

+ Stratégies de fabric (ports entre LEAF et SPINE). ports de fabric)

Chaque objet de port (l1PhysIf, pcAggrIf) peut se voir attribuer sa propre stratégie de surveillance via le groupe de stratégies d'interface comme illustré dans l'image ci-dessus.

Par défaut, il existe une stratégie de surveillance par défaut sous Fabric > Access Policies et Fabric > Fabric Policies dans l'interface utilisateur graphique APIC. Ces stratégies de surveillance par défaut sont affectées respectivement à tous les ports. La stratégie de surveillance par défaut sous Stratégies d'accès est pour les ports du panneau avant et la stratégie de surveillance par défaut sous Stratégies de fabric est pour les ports du fabric.

À moins qu'il ne soit nécessaire de modifier les seuils par port, la stratégie de surveillance par défaut de chaque section peut être modifiée directement pour appliquer la modification à tous les ports du panneau avant et/ou du fabric.

L'exemple suivant est de modifier les seuils pour Forward Drop dans eqptIngrDropPkts sur les ports de fabric (politiques de fabric). Effectuez la même chose sous Fabric > Access Policies pour les ports du panneau avant.

1. Accédez à Fabric >Fabric Policies>Monitoring Policies.

2. Cliquez avec le bouton droit de la souris et sélectionnez Créer une stratégie de surveillance.

     (Si le changement de seuil peut être appliqué à tous les ports de fabric, accédez à default au lieu de créer un nouveau port)

3. Développez la nouvelle stratégie de surveillance ou la stratégie par défaut et accédez à Stratégies de collecte de statistiques.

4. Cliquez sur l'icône représentant un crayon pour l'objet Monitoring dans le volet de droite, sélectionnez Configuration de l'interface physique de couche 1 (l1.PhysIf).

     (Cette étape 4 peut être ignorée lorsque la stratégie par défaut est utilisée)

5. Dans la liste déroulante Objet de surveillance du volet droit, sélectionnez Configuration de l'interface physique de couche 1 (l1.PhysIf) et Type de statistiques, choisissez Paquets de suppression en entrée

    6. Cliquez sur le + en regard de Seuils de configuration

   7. Modifier le seuil de transfert

    8. La recommandation est de désactiver les seuils de hausse à configurer pour les valeurs critiques, majeures, mineures et d'avertissement pour le taux de perte de transfert.

9. Appliquez cette nouvelle stratégie de surveillance au groupe de stratégies d'interface pour les ports requis. N'oubliez pas de configurer le profil d'interface, le profil de commutateur, etc. dans les politiques de fabric en conséquence.

     (Cette étape 9 peut être ignorée lorsque la stratégie par défaut est utilisée)

10. S'il s'agit des ports du panneau avant (stratégies d'accès), effectuez la même chose pour l'interface agrégée (pc.AggrIf) par opposition à la configuration de l'interface physique de couche 1 (l1.PhysIf) afin que cette nouvelle stratégie de surveillance puisse être appliquée au port-channel ainsi qu'au port physique.

     (Cette étape 10 peut être ignorée lorsque la stratégie par défaut est utilisée)

Taux de paquets abandonnés en entrée dans l2IngrPktsAg

Il y a plusieurs parties pour cela.

Comme le montre l'image ci-dessus, l2IngrPktsAg est surveillé sous beaucoup d'objets. L'image ci-dessus montre seulement quelques exemples mais pas tous les objets pour l2IngrPktsAg. Cependant, le seuil des statistiques est configuré via la stratégie de surveillance ainsi que eqptIngrDropPkts sous l1PhysIf ou pcAggrIf.

Chaque objet ( EPG(fvAEPg), Bridge Domain(fvBD), etc... ) pourrait se voir attribuer sa propre politique de surveillance comme indiqué dans l'image ci-dessus.

Par défaut, tous ces objets sous locataire utilisent la stratégie de surveillance par défaut sous Locataire > commun > Politiques de surveillance > par défaut sauf si configuré autrement.

À moins qu'il ne soit nécessaire de modifier les seuils par composant, la stratégie de surveillance par défaut sous la stratégie commune du locataire peut être directement modifiée pour appliquer la modification à tous les composants associés.

L'exemple suivant est de modifier les seuils pour le débit de paquets d'abandon en entrée dans l2IngrPktsAg15min sur le domaine de pont.

1. Accédez à Locataire > (nom du locataire) > Stratégies de surveillance.

     (le locataire doit être commun si la stratégie de surveillance par défaut est utilisée ou si la nouvelle stratégie de surveillance doit être appliquée à tous les locataires)

2. Cliquez avec le bouton droit de la souris et sélectionnez Créer une stratégie de surveillance.

     (Si le changement de seuil peut être appliqué à tous les composants, accédez à default au lieu de créer un nouveau.)

3. Développez la nouvelle stratégie de surveillance ou la stratégie par défaut et accédez à Stratégies de collecte de statistiques.

4. Cliquez sur l'icône représentant un crayon pour l'objet de surveillance dans le volet de droite, sélectionnez Domaine de pont (fv.BD).

     (Cette étape 4 peut être ignorée lorsque la stratégie par défaut est utilisée)

5. Dans la liste déroulante Objet de surveillance du volet droit, sélectionnez Domaine de pont (fv.BD) et Type de statistiques, choisissez Paquets d'entrée agrégés.

6. Cliquez sur le + en regard de Seuils de configuration

7. Modifier le seuil de transfert

8. La recommandation est de désactiver les seuils de hausse à configurer pour les valeurs critiques, majeures, mineures et d'avertissement pour le taux de perte de transfert.

9. Appliquez cette nouvelle stratégie de surveillance au domaine Bridge qui nécessite un changement de seuil.

     (Cette étape 9 peut être ignorée lorsque la stratégie par défaut est utilisée)

REMARQUE
La stratégie de surveillance non par défaut ne peut pas avoir de configurations qui sont présentes sur la stratégie de surveillance par défaut. S'il est nécessaire de conserver cette configuration de la même manière que la stratégie de surveillance par défaut, les utilisateurs doivent vérifier la configuration de la stratégie de surveillance par défaut et configurer manuellement les mêmes stratégies sur une stratégie de surveillance non par défaut.