Erläutern von Paketverlusten in der ACI

Einleitung

In diesem Dokument werden die einzelnen Fehlertypen sowie das Verfahren beschrieben, mit dem Sie diesen Fehler erkennen. Während des normalen Betriebs einer Cisco Application Centric Infrastructure (ACI) Fabric kann der Administrator Fehler für bestimmte Typen von Paketverlusten sehen.   

Verwaltete Objekte

In der Cisco ACI werden alle Fehler unter "Managed Objects (MO)" (Verwaltete Objekte (MO)) ausgelöst. Beispiel: Der Fehler F11245 - ingress drop packages rate(l2IngrPktsAg15min:dropRate) bezieht sich auf den Parameter dropRate in MO l2IngrPktsAg15min.

In diesem Abschnitt werden einige Beispiele für verwaltete Objekte (MO) vorgestellt, die sich auf das Löschen von Paketfehlern beziehen.

*1: Diese Zähler in eqptIngrDropPkts können aufgrund einer ASIC-Einschränkung in mehreren Nexus 9000-Plattformen fälschlicherweise ausgelöst werden, da SUP_REDIRECT-Pakete als Weiterleitungspakete protokolliert werden. Siehe auch Cisco Bug-ID CSCvo68407 und Cisco Bug-ID CSCvn72699 für weitere Details und fixe Versionen.

Hardware-Verlustzählertypen

Auf Nexus 9000-Switches, die im ACI-Modus ausgeführt werden, gibt es im ASIC drei Haupthardwareindikatoren für den Grund, warum die Eingangsschnittstelle ausfällt.

Eine DropRate in l2IngrPkts, l2IngrPktsAg enthält diese Zähler. Drei Parameter (forwardingRate, errorRate, bufferRate) in der Tabelle für eqptIngrDropPkts stellen jeweils drei Schnittstellenindikatoren dar. 

Weiterleiten

Weiterleitungs-Drops sind Pakete, die im LookUp-Block (LU) des ASIC verworfen werden. Im LU-Block wird eine Entscheidung über die Paketweiterleitung basierend auf den Paketkopf-Informationen getroffen. Wenn das Paket verworfen werden soll, wird "Weiterleitung verwerfen" gezählt. Es gibt verschiedene Gründe dafür, aber lassen Sie uns über die wichtigsten sprechen:

SECURITY_GROUP_DENY

Ein Verlust aufgrund fehlender Verträge, um die Kommunikation zu ermöglichen. 

Wenn ein Paket in die Fabric eintritt, prüft der Switch die Quell- und Ziel-EPG, um festzustellen, ob diese Kommunikation durch einen Vertrag zugelassen ist. Wenn sich Quelle und Ziel in unterschiedlichen EPGs befinden und es keinen Vertrag gibt, der diesen Pakettyp zulässt, verwirft der Switch das Paket und kennzeichnet es als SECURITY_GROUP_DENY. Dadurch wird der Zähler für den Weiterleitungsverlust erhöht.

VLAN_XLATE_MISS

Ein Ausfall aufgrund eines ungeeigneten VLAN.

Wenn ein Paket in die Fabric eintritt, prüft der Switch das Paket, um zu bestimmen, ob die Konfiguration auf dem Port dieses Paket zulässt.  Beispiel: Ein Frame gelangt mit einem 802.1Q-Tag von 10 in die Fabric. Wenn der Switch über VLAN 10 auf dem Port verfügt, überprüft er den Inhalt und trifft eine Weiterleitungsentscheidung basierend auf der Ziel-MAC. Befindet sich VLAN 10 jedoch nicht auf dem Port, wird es verworfen und als VLAN_XLATE_MISS gekennzeichnet. Dadurch wird der Zähler für den Weiterleitungsverlust erhöht.  

Der Grund für XLATE oder Translate besteht darin, dass der Leaf-Switch in der ACI einen Frame mit einem 802.1Q-Encap annimmt und in ein neues VLAN übersetzt, das für VXLAN und andere Normalisierungen innerhalb der Fabric verwendet wird. Wenn der Frame mit einem nicht bereitgestellten VLAN eingeht, schlägt die Übersetzung fehl.

ACL_DROP

Ein Tropfen wegen sup-tcam.

sup-tcam in ACI-Switches enthält spezielle Regeln, die zusätzlich zur normalen L2/L3-Weiterleitungsentscheidung anzuwenden sind. Regeln in der sup-tcam sind integriert und können nicht vom Benutzer konfiguriert werden. Das Ziel der Sup-Tcam-Regeln besteht hauptsächlich darin, einige Ausnahmen oder einen Teil des Kontrollebenen-Datenverkehrs zu verarbeiten und nicht von Benutzern überprüft oder überwacht zu werden. Wenn ein Paket die Regeln der sup-tcam erfüllt und das Paket verworfen werden soll, wird das verworfene Paket als ACL_DROP gezählt, und der Zähler für verworfene Pakete wird inkrementiert. In diesem Fall bedeutet dies in der Regel, dass die Paketweiterleitung anhand der grundlegenden ACI-Weiterleitungsprinzipien stattfindet.

Obwohl der Name des Drops ACL_DROP lautet, entspricht diese ACL nicht der normalen Zugriffskontrollliste, die auf eigenständigen NX-OS-Geräten oder anderen Routing-/Switching-Geräten konfiguriert werden kann.

SUP_UMLEITUNG

Das ist kein Tropfen.

Ein per Sup umgeleitetes Paket (z. B. CDP/LLDP/UDLD/BFD usw.) kann als Weiterleitung gezählt werden, selbst wenn das Paket korrekt verarbeitet und an die CPU weitergeleitet wurde.

Dies ist auf die ASIC-Implementierungsbeschränkung bei ACI N9k-Switches zurückzuführen, die auf Cloud Scale ASIC (EX/FX/FX2/FX3/GX/GX2) basieren.

Fehler

Wenn der Switch einen ungültigen Frame an einer der Schnittstellen auf der Vorderseite empfängt, wird er als Fehler verworfen.  Beispiele hierfür sind Frames mit FCS- oder CRC-Fehlern. Wenn Sie Uplink-/Downlink-Leaf-Ports oder Spine-Ports betrachten, ist es am besten, FCS-/CRC-Fehler mithilfe der Show-Schnittstelle zu überprüfen. Im Normalbetrieb wird jedoch erwartet, dass Fehlerpakete auf Uplink-/Downlink-Ports von Leafs inkrementiert werden, oder Spine-Ports, da dieser Zähler auch Frames enthält, die vom System abgeschnitten werden und nicht von der Schnittstelle gesendet werden sollen.

Beispiel: TTL-Fehler für geroutete Pakete, Broadcast-/Flooded-Frames derselben Schnittstelle.

Puffer

Wenn der Switch einen Frame empfängt und es keine Buffer-Credits für Eingang oder Ausgang gibt, wird der Frame mit Buffer verworfen.  Dies weist in der Regel auf eine Überlastung irgendwo im Netzwerk hin. Die Verbindung, die den Fehler anzeigt, kann voll sein, oder die Verbindung mit dem Ziel kann überlastet sein.

Anzeigen von Drop-Statistiken in der CLI

Verwaltete Objekte

Sichern Sie Shell (SSH) mit einem APIC ab, und führen Sie diese Befehle aus.

apic1# moquery -c l2IngrPktsAg15min

Damit werden alle Objektinstanzen für diese Klasse l2IngrPktsAg15min bereitgestellt.

Hier ist ein Beispiel mit einem Filter, um ein bestimmtes Objekt abzufragen. In diesem Beispiel soll der Filter nur ein Objekt mit den Attributen dn anzeigen, das tn-TENANT1/ap-APP1/epg-EPG1 enthält.

Außerdem wird in diesem Beispiel egrep verwendet, um nur erforderliche Attribute anzuzeigen.

Beispielausgabe 1: EPG-Zählerobjekt (l2IngrPktsAg15min) von Tenant TENANT1, Anwendungsprofil 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

Oder wir könnten eine andere Option -d anstelle von -c verwenden, um ein bestimmtes Objekt zu erhalten, wenn Sie das Objekt dn kennen.

Beispielausgabe 2: EPG-Zählerobjekt (l2IngrPktsAg15min) von Tenant TENANT1, Anwendungsprofil 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

Hardware-Zähler

Wenn Sie Fehler feststellen oder Paketverluste auf Switch-Ports mithilfe der CLI überprüfen möchten, sehen Sie sich hierzu am besten die Plattformzähler in der Hardware an. Die meisten, aber nicht alle Zähler werden über show interface angezeigt.  Die drei Hauptgründe für das Verwerfen können nur mithilfe der Plattformzähler angezeigt werden.  So zeigen Sie diese an:

Blatt

SSH auf dem Leaf und führen Sie diese Befehle aus.

ACI-LEAF# vsh_lc
Modul-1# show platform internal counters port <X>
                                                    * wobei X für die Portnummer steht

Beispielausgabe für 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 -----

Wirbelsäule

Für einen Boxtyp Spine (N9K-C9336PQ) ist er genau gleich Leaf.

Bei modularen Spines (N9K-C9504 usw.) müssen Sie zunächst die jeweilige Linecard anbringen, bevor Sie die Plattformzähler anzeigen können.  SSH zum Spine und führen Sie die folgenden Befehle aus:

ACI-SPINE# vsh

ACI-SPINE# Attach-Modul <X>

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

                             * wobei X für die Modulnummer der Linecard steht, die Sie anzeigen möchten.

                                            Y steht für die Portnummer

Beispielausgabe für Ethernet 2/1:

ACI-SPINE# vsh
Cisco iNX-OS Debug Shell
This shell can only be used for internal commands and exists
for legacy reasons. User can 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 -----

Fehler

F112425 - Ingress Drop Packets Rate (l2IngrPktsAg15min:dropRate)

Beschreibung:

Einer der häufigsten Gründe für diesen Fehler ist, dass Layer-2-Pakete mit dem Grund "Forward Drop" verworfen werden. Es gibt verschiedene Gründe, aber der häufigste ist:

Auf einigen Plattformen (siehe Cisco Bug-ID CSCvo68407) gibt es eine Beschränkung, bei der L2-Pakete, die an die CPU umgeleitet werden müssen (z. B. CDP/LLDP/UDLD/BFD usw.), als Weiterleitungsverlust protokolliert und auf die CPU kopiert werden. Dies ist auf eine Beschränkung der in diesen Modellen verwendeten ASICs zurückzuführen.

Auflösung:

Die beschriebenen Drops sind rein kosmetischer Natur. Daher wird als Best Practice empfohlen, den Schwellenwert für den Fehler zu erhöhen, wie im Abschnitt "Schwellenwerte für Statistiken" gezeigt. Informationen hierzu finden Sie in den Anweisungen unter Stats Threshold (Statistikgrenzwert).

F100264 - Ingress Buffer Drop Packets Rate (eqptIngrDropPkts5min:bufferRate)

Beschreibung:

Dieser Fehler kann inkrementell auftreten, wenn Pakete an einem Port mit dem Grund "Buffer" verworfen werden.  Wie bereits erwähnt, geschieht dies in der Regel, wenn eine Überlastung an einer Schnittstelle in Eingangs- oder Ausgangsrichtung vorliegt.

Auflösung:

Dieser Fehler stellt die aufgrund von Überlastung tatsächlich verworfenen Pakete in der Umgebung dar.  Die verlorenen Pakete können Probleme mit Anwendungen verursachen, die in der ACI-Fabric ausgeführt werden. Netzwerkadministratoren können den Paketfluss isolieren und feststellen, ob die Überlastung auf unerwartete Datenverkehrsflüsse, ineffizienten Lastenausgleich usw. oder die erwartete Auslastung an diesen Ports zurückzuführen ist.

F100696 - Eingangs-Weiterleitungs-Drop-Pakete (eqptIngrDropPkts5min:forwardingRate)

Anmerkung: Eine ASIC-Einschränkung wie zuvor für F11245 kann dazu führen, dass diese Fehler ebenfalls ausgelöst werden. Siehe Cisco Bug-ID CSCvo68407 für weitere Informationen.

Dieser Fehler wird durch einige Szenarien verursacht. Die gängigste ist:

Beschreibung 1) Spine Drops

Wenn dieser Fehler an einer Spine-Schnittstelle auftritt, kann dies auf Datenverkehr zu einem unbekannten Endpunkt zurückzuführen sein. Wenn ein ARP- oder IP-Paket für eine Proxy-Suche an den Spine weitergeleitet wird und der Endpunkt in der Fabric unbekannt ist, wird ein spezielles Paket generiert und an alle Leafs der entsprechenden BD-(internen) Multicast-Gruppenadresse gesendet. Dadurch wird von jedem Leaf in der Bridge-Domäne (BD) eine ARP-Anfrage zur Erkennung des Endpunkts ausgelöst.  Aufgrund einer Einschränkung wird das vom Leaf empfangene Glean-Paket ebenfalls wieder in das Fabric reflektiert und löst einen Weiterleitungs-Drop für den mit dem Leaf verbundenen Spine-Link aus. In diesem Szenario wird der Weiterleitungsverlust nur auf Spine-Hardware der 1. Generation erhöht.

Entschließung 1)

Da bekannt ist, dass das Problem durch ein Gerät verursacht wird, das eine unnötige Menge an unbekanntem Unicast-Datenverkehr an die ACI-Fabric sendet, muss ermittelt werden, welches Gerät dies verursacht, und geprüft werden, ob dies verhindert werden kann. Dies wird in der Regel durch Geräte verursacht, die zu Überwachungszwecken IP-Adressen in Subnetzen suchen.  Um herauszufinden, welche IP diesen Datenverkehr sendet, muss SSH auf das Leaf angewendet werden, das mit der Spine-Schnittstelle verbunden ist. Dort wird der Fehler angezeigt.

Von dort können Sie diesen Befehl ausführen, um die Quell-IP-Adresse (SIP) anzuzeigen, die das Glean-Paket auslöst:

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

In dieser Beispielausgabe wird das Glean-Paket von 192.168.21.150 ausgelöst, und es wird empfohlen, zu prüfen, ob dies gemindert werden kann.

Beschreibung 2) Leaf Drops

Wenn dieser Fehler auf einer Leaf-Schnittstelle erkannt wird, liegt die wahrscheinlichste Ursache in den erwähnten SECURITY_GROUP_DENY-Löschungen.  

Entschließung 2)

ACI-Leaf speichert ein Protokoll der Pakete, die aufgrund von Verletzungen abgelehnt wurden. Dieses Protokoll erfasst nicht alle Protokolle, um CPU-Ressourcen zu schützen. Es stellt jedoch weiterhin eine große Anzahl von Protokollen bereit.

Wenn die Schnittstelle, an der der Fehler aufgetreten ist, Teil eines Port-Channels ist, müssen Sie diesen Befehl und grep für den Port-Channel verwenden, um die erforderlichen Protokolle abzurufen. Andernfalls kann die physische Schnittstelle erfasst werden.

Dieses Protokoll kann je nach Anzahl der verworfenen Verträge schnell übertragen werden.

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

In diesem Fall versucht 192.168.21.150, ICMP-Nachrichten (IP-Protokollnummer 1) an 192.168.20.3 zu senden. Es gibt jedoch keinen Vertrag zwischen den beiden EPGs, der ICMP zulässt, sodass das Paket verworfen wird. Wenn ICMP zulässig sein soll, kann zwischen den beiden EPGs ein Vertrag hinzugefügt werden.

Statistikgrenzwert

In diesem Abschnitt wird beschrieben, wie Sie einen Schwellenwert für Statistikobjekte ändern, die möglicherweise einen Fehler gegen einen Zähler zum Ablegen auslösen könnten.

Ein Schwellenwert für die Statistiken der einzelnen Objekte (z. B. l2IngrPkts, eqptIngrDropPkts) wird mithilfe der Überwachungsrichtlinie für verschiedene Objekte konfiguriert.

Wie in der Tabelle am Anfang erwähnt, wird eqptIngrDropPkts beispielsweise unter l1PhysIf-Objekten mithilfe der Überwachungsrichtlinie überwacht.

Weiterleiten - Paketrate in eqptIngrDropPkts

Hierfür gibt es zwei Bereiche.

+ Zugriffsrichtlinien (Ports zu externen Geräten). auch Frontblenden genannt)

+ Fabric-Richtlinien (Ports zwischen LEAF und SPINE, auch Fabric-Ports genannt)

Jedem Port-Objekt (l1PhysIf, pcAggrIf) kann über die Schnittstellen-Richtliniengruppe eine eigene Überwachungsrichtlinie zugewiesen werden, wie in der Abbildung oben gezeigt.

Standardmäßig gibt es in der APIC-GUI sowohl unter Fabric > Access Policies (Fabric > Zugriffsrichtlinien) als auch unter Fabric > Fabric Policies (Fabric > Fabric-Richtlinien) eine Standardüberwachungsrichtlinie. Diese Standardüberwachungsrichtlinien werden jeweils allen Ports zugewiesen. Die standardmäßige Überwachungsrichtlinie unter "Access Policies" (Zugriffsrichtlinien) gilt für die Frontplatten-Ports, die standardmäßige Überwachungsrichtlinie unter "Fabric Policies" (Fabric-Richtlinien) für Fabric-Ports.

Sofern es nicht erforderlich ist, die Schwellenwerte pro Port zu ändern, kann die Standard-Überwachungsrichtlinie in jedem Abschnitt direkt geändert werden, um die Änderung auf alle Ports an der Vorderseite und/oder Fabric-Ports anzuwenden.

In diesem Beispiel werden die Grenzwerte für Weiterleitungsverlust in eqptIngrDropPkts an Fabric-Ports (Fabric-Richtlinien) geändert. Führen Sie dasselbe unter Fabric > Zugriffsrichtlinien für Ports an der Vorderseite durch.

1. Navigieren Sie zu Fabric > Fabric Policies>Monitoring Policies.

2. Klicken Sie mit der rechten Maustaste, und wählen Sie Überwachungsrichtlinie erstellen aus.

     (Wenn die Schwellenwertänderung auf alle Fabric-Ports angewendet werden kann, navigieren Sie zur Standardeinstellung, anstatt eine neue zu erstellen.)

3. Erweitern Sie die neue Überwachungsrichtlinie oder die Standardeinstellung, und navigieren Sie zu Richtlinien für die Statistikerfassung.

4. Klicken Sie auf das Bleistiftsymbol für das Überwachungsobjekt im rechten Bereich, und wählen Sie Layer 1 Physical Interface Configuration (l1.PhysIf) aus.

     (Schritt 4 kann übersprungen werden, wenn die Standardrichtlinie verwendet wird.)

5. Wählen Sie aus dem Dropdown-Menü Überwachungsobjekt im rechten Bereich die Option Layer 1 Physical Interface Configuration (l1.PhysIf) aus, und wählen Sie Stats Type (Statistiktyp) aus, und wählen Sie Ingress Drop Packets (Eingehende Drop-Pakete).

    6. Klicken Sie auf + neben Konfigurationsschwellenwerte.

   7. Bearbeiten Sie den Schwellenwert für Weiterleitungs-Drop.

    8. Es wird empfohlen, die steigenden Schwellenwerte für die Konfiguration für kritische, ernste, kleine und Warnungen für die Weiterleitungs-Verlustrate zu deaktivieren.

9. Wenden Sie diese neue Überwachungsrichtlinie für die erforderlichen Ports auf die Schnittstellenrichtliniengruppe an. Vergessen Sie nicht, das Schnittstellenprofil, das Switch-Profil usw. in den Fabric-Richtlinien entsprechend zu konfigurieren.

     (Schritt 9 kann übersprungen werden, wenn die Standardrichtlinie verwendet wird.)

10. Wenn dies für die Ports an der Vorderseite (Zugriffsrichtlinien) gilt, führen Sie den gleichen Vorgang für die aggregierte Schnittstelle (pc.AggrIf) aus wie für die Konfiguration der physischen Layer-1-Schnittstelle (l1.PhysIf), sodass diese neue Überwachungsrichtlinie sowohl auf den Port-Channel als auch auf den physischen Port angewendet werden kann.

     (Schritt 10 kann übersprungen werden, wenn die Standardrichtlinie verwendet wird.)

Rate verlorener Eingangspakete in l2ingrPktsAg

Hierfür gibt es mehrere Bereiche.

Wie das obige Bild zeigt, wird l2IngrPktsAg unter vielen Objekten überwacht. Das obige Bild zeigt nur einige Beispiele, aber nicht alle Objekte für l2IngrPktsAg. Der Schwellenwert für Statistiken wird jedoch mithilfe der Überwachungsrichtlinie sowie mithilfe von eqptIngrDropPkts unter l1PhysIf oder pcAggrIf konfiguriert.

Jedem Objekt ( EPG(fvAEPg), Bridge Domain(fvBD) usw.) könnte eine eigene Überwachungsrichtlinie zugewiesen werden, wie in der Abbildung oben gezeigt.

Standardmäßig verwenden alle diese Objekte unter Tenant die Standard-Überwachungsrichtlinie unter Tenant > common > Monitoring Polices > default, sofern nicht anders konfiguriert.

Sofern es nicht erforderlich ist, die Schwellenwerte für jede Komponente zu ändern, kann die Standardüberwachungsrichtlinie unter Tenant Common direkt geändert werden, um die Änderung auf alle zugehörigen Komponenten anzuwenden.

In diesem Beispiel werden die Grenzwerte für die Drop-Paketrate bei eingehenden Paketen in l2IngrPktsAg15min auf der Bridge-Domäne geändert.

1. Navigieren Sie zu Tenant > (Tenant-Name) > Überwachungsrichtlinien.

     (Tenant muss gemeinsam sein, wenn die Standard-Überwachungsrichtlinie verwendet wird oder die neue Überwachungsrichtlinie auf Tenants angewendet werden muss)

2. Klicken Sie mit der rechten Maustaste, und wählen Sie Überwachungsrichtlinie erstellen aus.

     (Wenn die Schwellenwertänderung auf alle Komponenten angewendet werden kann, navigieren Sie zur Standardeinstellung, anstatt eine neue zu erstellen.)

3. Erweitern Sie die neue Überwachungsrichtlinie oder die Standardeinstellung, und navigieren Sie zu Richtlinien für die Statistikerfassung.

4. Klicken Sie auf das Bleistiftsymbol für das Überwachungsobjekt im rechten Bereich, und wählen Sie Bridge Domain (fv.BD) aus.

     (Schritt 4 kann übersprungen werden, wenn die Standardrichtlinie verwendet wird.)

5. Wählen Sie aus dem Dropdown-Menü Überwachungsobjekt im rechten Bereich die Option Bridge Domain (fv.BD) und Stats Type (Statistiktyp) aus, und wählen Sie Aggregierte Eingangspakete aus.

6. Klicken Sie auf + neben Konfigurationsschwellenwerte.

7. Bearbeiten Sie den Schwellenwert für Weiterleitungs-Drop.

8. Es wird empfohlen, die steigenden Schwellenwerte für die Konfiguration für kritische, ernste, kleine und Warnungen für die Weiterleitungs-Verlustrate zu deaktivieren.

9. Wenden Sie diese neue Überwachungsrichtlinie auf die Bridge-Domäne an, die eine Änderung des Grenzwerts erfordert.

     (Schritt 9 kann übersprungen werden, wenn die Standardrichtlinie verwendet wird.)

HINWEIS:
Eine nicht standardmäßige Überwachungsrichtlinie kann nicht über Konfigurationen verfügen, die in der standardmäßigen Überwachungsrichtlinie enthalten sind. Wenn diese Konfigurationen mit den standardmäßigen Überwachungsrichtlinien übereinstimmen müssen, müssen die Benutzer die standardmäßige Konfiguration der Überwachungsrichtlinie überprüfen und die gleichen Richtlinien manuell für die nicht standardmäßige Überwachungsrichtlinie konfigurieren.