Erläuterungen zu 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 es vorkommen, dass für bestimmte Typen von Paketverlusten Fehler auftreten.   

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 mit Paketfehlern verknüpft sind.

	Beispiel	Beschreibung	Beispielparameter	Beispiel-MO gegen welche Störungen ausgelöst werden
l2IngrPakete	l2IngrPkts5min l2IngrPakete15Min. l2IngrPkts1h usw.	Dies stellt die eingehende Paketstatistik pro VLAN während jedes Zeitraums dar.	DropRate Überschwemmungsrate MulticastRate UnicastRate	vlanCktEp (VLAN)
l2IngrPaketeAG	l2IngrPktsAg15min l2IngrPktsAG1h l2IngrPaketeAG1d  usw.	Dies stellt die eingehende Paketstatistik pro EPG, BD, VRF usw. dar. (ohne) EPG-Statistiken stellen die Aggregation von VLAN-Statistiken dar, die zur EPG gehören.	DropRate Überschwemmungsrate MulticastRate UnicastRate	fvAEPg (EPG) fvAP (Anwendungsprofil) fvBD (BD) l3extOut (L3OUT)
eqptIngrDropPkts	eqptIngrDropPkts15Min eqptIngrDropPkts1h eqptIngrDropPkts1d usw.	Dies stellt Statistiken über eingehende Paketverluste pro Schnittstelle in jedem Zeitraum dar.	*1 Weiterleitungsrate *1 Fehlerrate *1 Pufferrate	l1PhysIf (physischer Port) pcAggrIf (Port-Channel)

*1 : Diese Zähler in eqptIngrDropPaketen 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. Weitere Details und feste Versionen finden Sie unter CSCvo68407 und CSCvn72699.

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 obigen 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, warum dies passieren kann, aber lassen Sie uns über die Hauptgründe 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 zwischen den EPGs 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. Wenn VLAN 10 sich jedoch nicht auf dem Port befindet, wird er verworfen und als VLAN_XLATE_MISS gekennzeichnet. Dadurch wird der Weiterleitungsverlust erhöht Zähler.  

Der Grund für "XLATE" oder "Translate" liegt 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 SUP-TCAM-Regeln 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 der Regel bedeutet dies, dass das Paket im Begriff ist, anhand der grundlegenden ACI-Weiterleitungsprinzipien weitergeleitet zu werden.

Beachten Sie, dass die Zugriffskontrollliste (ACL), auch wenn der Name des Eintrags ACL_DROP lautet, nicht mit der normalen Zugriffskontrollliste übereinstimmt, 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 Weiterleitungsverlust gezählt werden, auch wenn das Paket richtig verarbeitet und an die CPU weitergeleitet wurde.

Dies geschieht in -EX-, -FX- und -FX2-Plattformen wie N9K-C93180YC-EX oder N9K-C93180YC-FX. Diese sollten nicht als "Drop" gewertet werden. Der Grund hierfür sind die ASIC-Einschränkungen in -EX/-FX/-FX2-Plattformen.

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 sich Uplink-/Downlink-Leaf-Ports oder Spine-Ports ansehen, ist es am besten, FCS-/CRC-Fehler mit "show interface" zu überprüfen.
Unter normalen Betriebsbedingungen wird jedoch erwartet, dass Fehlerpakete auf Uplink-/Downlink-Ports von Leafs oder Spine-Ports inkrementiert werden, da dieser Zähler auch Frames enthält, die vom System bereinigt 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 weder für den Eingang noch für den Ausgang Puffergutschriften verfügbar sind, wird der Frame mit "Puffer" verworfen.  Dies weist in der Regel auf eine Überlastung irgendwo im Netzwerk hin.  Die Verbindung, die den Fehler anzeigt, ist möglicherweise voll, oder die Verbindung mit dem Ziel ist überlastet.

Anzeigen von Drop-Statistiken in der CLI

Verwaltete Objekte

Sichern Sie Shell (SSH) mit einem der APIC, und führen Sie die folgenden Befehle aus.

apic1# moquery -c l2IngrPktsAg15min

Dadurch 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.

Auch in diesem Beispiel wird 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 die Anzeige 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
module-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 diese 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 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 -----

  

Fehler

F112425 - Ingress Drop Packet 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 CSCvo68407 ) gibt es eine Einschränkung, bei der L2-Pakete, die an die CPU umgeleitet werden müssen (z. B. CDP/LLDP/UDLD/BFD), 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 oben beschriebenen Drops sind rein kosmetischer Natur. Daher wird als Best Practice empfohlen, den Schwellenwert für den Fehler zu erhöhen, wie im Abschnitt über den Schwellenwert für Statistiken gezeigt. Informationen hierzu finden Sie in den Anweisungen unter Stats Threshold (Statistikgrenzwert).

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

Beschreibung:

Dieser Fehler kann inkrementell auftreten, wenn Pakete an einem Port mit dem Grund "Buffer" verworfen werden. Wie bereits erwähnt, tritt dies in der Regel dann auf, 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 sollten 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)

Hinweis: Eine ASIC-Einschränkung wie oben für F11245 kann dazu führen, dass diese Fehler ebenfalls ausgelöst werden. Weitere Informationen finden Sie unter CSCvo68407.

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 "Glean"-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-Anforderung 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 festgestellt 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, ist die wahrscheinlichste Ursache die erwähnten SECURITY_GROUP_DENY-Löschungen.  

Resolution 2 )

ACI-Leaf speichert ein Protokoll mit Paketen, die aufgrund von Vertragsverletzungen abgelehnt wurden.Dieses Protokoll erfasst nicht alle Pakete, um CPU-Ressourcen zu schützen. Dennoch stellt es eine große Anzahl an 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 (d. h. 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 für externe Geräte, auch Frontblenden-Ports genannt)

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

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

Standardmäßig ist in der APIC-GUI eine Standardüberwachungsrichtlinie unter Fabric > Access Policies (Fabric > Zugriffsrichtlinien) und Fabric > Fabric Policies (Fabric > Fabric-Richtlinien) festgelegt. 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.

Das folgende Beispiel dient zum Ändern der Grenzwerte für Weiterleitungsverlust in eqptIngrDropPkts an Fabric-Ports (Fabric-Richtlinien). Führen Sie das gleiche unter Fabric > Zugriffsrichtlinien für Frontpanel-Ports durch.

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

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

     (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.

     (Dieser Schritt 4 kann bei Verwendung der Standardrichtlinie übersprungen werden.)

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 Config Thresholds

   7. Ändern Sie den Schwellenwert für Weiterleitungsverlust.

    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. Bitte vergessen Sie nicht, das Schnittstellenprofil, das Switch-Profil usw. in den Fabric-Richtlinien entsprechend zu konfigurieren.

     (Dieser Schritt 9 kann bei Verwendung der Standardrichtlinie übersprungen werden.)

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

     (Dieser Schritt 10 kann bei Verwendung der Standardrichtlinie übersprungen werden.)

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), etc...) 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 > Überwachungsrichtlinien > 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.

Das folgende Beispiel dient zum Ändern der Grenzwerte für die Ingress Drop Packets Rate in l2IngrPktsAg15min auf der Bridge-Domäne.

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".

     (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.

     (Dieser Schritt 4 kann bei Verwendung der Standardrichtlinie übersprungen werden.)

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.

6. Klicken Sie auf + neben Config Thresholds

7. Ändern Sie den Schwellenwert für Weiterleitungsverlust.

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.

     (Dieser Schritt 9 kann bei Verwendung der Standardrichtlinie übersprungen werden.)

HINWEIS
Nicht standardmäßige Überwachungsrichtlinie darf keine Konfigurationen aufweisen, die in der Standardüberwachungsrichtlinie enthalten sind. Wenn diese Konfiguration mit der standardmäßigen Überwachungsrichtlinie übereinstimmen muss, müssen die Benutzer die standardmäßige Konfiguration der Überwachungsrichtlinie überprüfen und die gleichen Richtlinien manuell für eine nicht standardmäßige Überwachungsrichtlinie konfigurieren.