Überprüfen von Verletzungen des Control Plane Policing auf Nexus-Plattformen

Einleitung

In diesem Dokument werden Details zum Control Plane Policing (CoPP) auf Cisco Nexus-Switches und seine relevanten Auswirkungen auf nicht standardmäßige Klassenverletzungen beschrieben.

Voraussetzungen

Cisco empfiehlt, dass Sie mit grundlegenden Informationen bezüglich Control Plane Policing (CoPP), den zugehörigen Richtlinien und Einschränkungen und der allgemeinen Konfiguration sowie der Quality of Service (QoS) Policing (CIR)-Funktionalität vertraut sind. Weitere Informationen zu dieser Funktion finden Sie in den entsprechenden Dokumenten:

• Cisco Nexus Serie 9000 NX-OS - Sicherheitskonfigurationsleitfaden, Version 10.2(x)
• CoPP bei Nexus Switches der Serie 7000
• Cisco Nexus Serie 9000 NX-OS - Quality of Service-Konfigurationsleitfaden, Version 10.2(x)

Anforderungen

Es gibt keine spezifischen Anforderungen für dieses Dokument.

Verwendete Komponenten

Dieses Dokument ist nicht auf bestimmte Software- und Hardwareanforderungen beschränkt.

Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die möglichen Auswirkungen aller Befehle kennen.

Hintergrundinformationen

Der Datenverkehr auf der Kontrollebene wird durch Umleitungszugriffskontrolllisten (ACLs) zum Supervisor-Modul umgeleitet. Diese sind so programmiert, dass der abgeglichene Datenverkehr, der zwei Schutzebenen - die Hardware-Ratenlimitierung und CoPP - durchläuft, analysiert wird. Störungen oder Angriffe auf das Supervisor-Modul können, sofern sie nicht geprüft werden, zu schwerwiegenden Netzwerkausfällen führen. Daher dient CoPP als Schutzmechanismus. Bei Instabilitäten auf Kontrollebene ist es wichtig, CoPP zu überprüfen, da anormale Datenverkehrsmuster, die durch Schleifen oder Überschwemmungen erzeugt werden, oder nicht autorisierte Geräte besteuert werden können und den Supervisor daran hindern, legitimen Datenverkehr zu verarbeiten. Solche Angriffe, die entweder versehentlich von nicht autorisierten Geräten oder böswillig von Angreifern verübt werden können, führen in der Regel zu hohen Datenverkehrsraten, die auf das Supervisor-Modul oder die CPU gerichtet sind.

Control Plan Policing (CoPP) ist eine Funktion zur Klassifizierung und Regelung aller über die In-Band-Ports (Vorderseite) empfangenen Pakete, die an die Routeradresse gerichtet sind oder die Beteiligung eines Supervisors erfordern. Mit dieser Funktion kann eine Richtlinienzuordnung auf die Steuerungsebene angewendet werden. Diese Richtlinienzuordnung ähnelt einer normalen QoS-Richtlinie (Quality of Service) und wird auf den gesamten Datenverkehr angewendet, der von einem Nicht-Management-Port auf den Switch gelangt. Durch den Schutz des Supervisor-Moduls durch Richtlinien kann der Switch Datenverkehrsfluten, die über die Committed Input Rate (CIR) für jede Klasse hinausgehen, durch das Verwerfen von Paketen verhindern, dass der Switch überlastet wird und sich somit auf die Leistung auswirkt.

CoPP-Zähler müssen kontinuierlich überwacht und begründet werden. Dies ist der Zweck dieses Dokuments. Wenn CoPP-Verletzungen deaktiviert sind, kann die Kontrollebene am Prozess des echten Datenverkehrs in der zugehörigen betroffenen Klasse gehindert werden. Die CoPP-Konfiguration ist ein flüssiger und kontinuierlicher Prozess, der auf die Netzwerk- und Infrastrukturanforderungen reagieren muss. Es gibt drei Standard-Systemrichtlinien für CoPP. Cisco empfiehlt standardmäßig die Verwendung der Standardrichtlinie strict als Ausgangspunkt und wird als Grundlage für dieses Dokument verwendet.

CoPP gilt nur für In-Band-Datenverkehr, der über die Ports an der Vorderseite empfangen wird. Der Out-of-Band-Management-Port (mgmt0) unterliegt nicht CoPP. Die Cisco NX-OS-Gerätehardware führt CoPP für jede Weiterleitungs-Engine aus. Wählen Sie deshalb die Übertragungsraten aus, damit der aggregierte Datenverkehr das Supervisor-Modul nicht überlastet. Dies ist besonders bei End-of-Row-/modularen Switches wichtig, da die CIR für den aggregierten Datenverkehr aller Module gilt, die an die CPU gebunden sind.

Relevante Hardware

Die in diesem Dokument beschriebene Komponente gilt für alle Cisco Nexus-Switches für Rechenzentren.

Interpretation des Control Plane Policing

Der Schwerpunkt dieses Dokuments liegt auf den häufigsten und wichtigsten nicht standardmäßigen Klassenverletzungen bei Nexus-Switches.

Standard-CoPP-Standardprofil

Um zu verstehen, wie CoPP interpretiert wird, muss bei der ersten Überprüfung sichergestellt werden, dass ein Profil angewendet wird, und festgestellt werden, ob ein Standardprofil oder ein benutzerdefiniertes Profil auf den Switch angewendet wird.

Hinweis: Als Best Practice muss CoPP auf allen Nexus-Switches aktiviert sein. Wenn diese Funktion nicht aktiviert ist, kann dies zu Instabilitäten für den gesamten Steuerungsebenen-Datenverkehr führen, da unterschiedliche Plattformen den an den Supervisor (SUP) gebundenen Datenverkehr einschränken können. Wenn z. B. CoPP auf einem Nexus 9000 nicht aktiviert ist, ist die Datenverkehrsrate für das SUP auf 50 pps begrenzt, sodass der Switch nahezu funktionsuntüchtig wird. CoPP wird für Nexus 3000- und Nexus 9000-Plattformen als Anforderung angesehen.


Wenn CoPP nicht aktiviert ist, kann es mithilfe des setup Befehls oder durch Anwendung einer der Standardrichtlinien unter der Konfigurationsoption reaktiviert oder auf dem Switch konfiguriert werden: copp profile [dense|lenient|moderate|strict].

Ein ungeschütztes Gerät klassifiziert und trennt den Datenverkehr nicht ordnungsgemäß in Klassen. Ein Denial-of-Service-Verhalten für eine bestimmte Funktion oder ein bestimmtes Protokoll ist daher nicht auf diesen Bereich beschränkt und kann sich auf die gesamte Kontrollebene auswirken.

Hinweis: CoPP-Richtlinien werden durch Ternary Content-Addressable Memory (TCAM)-Klassifizierungsumleitungen implementiert und sind direkt unter show system internal access-list input statistics module X | b CoPP oder show hardware access-list input entries detailzu sehen.

N9K1# show copp status Last Config Operation: None Last Config Operation Timestamp: None Last Config Operation Status: None Policy-map attached to the control-plane: copp-system-p-policy-strict copp-system-p-policy-strict is one of the system default profiles, in particular the strict profile. N9K1# show running-config copp !Command: show running-config copp !Running configuration last done at: Tue Apr 26 16:34:10 2022 !Time: Sun May 1 16:30:57 2022 version 10.2(1) Bios:version 05.45 copp profile strict


CoPP-Klassen

CoPP klassifiziert den Datenverkehr anhand der Übereinstimmungen, die den IP- oder MAC-ACLs entsprechen. Daher ist es wichtig zu wissen, welcher Datenverkehr unter welcher Klasse klassifiziert wird.

Die Klassen, die plattformabhängig sind, können variieren. Daher ist es wichtig zu verstehen, wie die Klassen zu überprüfen.

Beispiel für Nexus 9000 Top-of-Rack (TOR):

N9K1# show policy-map interface control-plane 
Control Plane

Service-policy input: copp-system-p-policy-strict
...
class-map copp-system-p-class-critical (match-any)
match access-group name copp-system-p-acl-bgp
match access-group name copp-system-p-acl-rip
match access-group name copp-system-p-acl-vpc
match access-group name copp-system-p-acl-bgp6
match access-group name copp-system-p-acl-ospf
match access-group name copp-system-p-acl-rip6
match access-group name copp-system-p-acl-eigrp
match access-group name copp-system-p-acl-ospf6
match access-group name copp-system-p-acl-eigrp6
match access-group name copp-system-p-acl-auto-rp
match access-group name copp-system-p-acl-mac-l3-isis
set cos 7
police cir 36000 kbps , bc 1280000 bytes 
module 1 : 
transmitted 177446058 bytes;
5-minute offered rate 3 bytes/sec
conformed 27 peak-rate bytes/sec
at Sat Apr 23 04:25:27 2022

dropped 0 bytes;
5-min violate rate 0 byte/sec
violated 0 peak-rate byte/sec
...


In diesem Beispiel copp-system-p-class-critical umfasst die Klassenzuordnung Datenverkehr, der sich auf Routing-Protokolle wie Border Gateway Protocol (BGP), Open Shortest Path First (OSPF) und Enhanced Interior Gateway Router Protocol (EIGRP) bezieht, sowie andere Protokolle wie vPC.

Die Namenskonvention der IP- oder MAC-ACLs ist für das Protokoll bzw. die Funktion mit dem Präfix meist selbsterklärend copp-system-p-acl-[protocol|feature].

Um eine bestimmte Klasse anzuzeigen, kann sie direkt angegeben werden, während der Befehl show ausgeführt wird. Beispiele:

N9K-4# show policy-map interface control-plane class copp-system-p-class-management
Control Plane

Service-policy input: copp-system-p-policy-strict

class-map copp-system-p-class-management (match-any)
match access-group name copp-system-p-acl-ftp
match access-group name copp-system-p-acl-ntp
match access-group name copp-system-p-acl-ssh
match access-group name copp-system-p-acl-http
match access-group name copp-system-p-acl-ntp6
match access-group name copp-system-p-acl-sftp
match access-group name copp-system-p-acl-snmp
match access-group name copp-system-p-acl-ssh6
match access-group name copp-system-p-acl-tftp
match access-group name copp-system-p-acl-https
match access-group name copp-system-p-acl-snmp6
match access-group name copp-system-p-acl-tftp6
match access-group name copp-system-p-acl-radius
match access-group name copp-system-p-acl-tacacs
match access-group name copp-system-p-acl-telnet
match access-group name copp-system-p-acl-radius6
match access-group name copp-system-p-acl-tacacs6
match access-group name copp-system-p-acl-telnet6
set cos 2
police cir 36000 kbps , bc 512000 bytes 
module 1 :
transmitted 0 bytes;
5-minute offered rate 0 bytes/sec
conformed 0 peak-rate bytes/sec

dropped 0 bytes;
5-min violate rate 0 byte/sec
violated 0 peak-rate byte/sec


Während die CoPP-Standardprofile normalerweise als Teil der Standardkonfiguration ausgeblendet werden, können Sie die Konfiguration wie folgt anzeigen show running-conf copp all:

N9K1# show running-config copp all

!Command: show running-config copp all
!Running configuration last done at: Tue Apr 26 16:34:10 2022
!Time: Sun May 1 16:41:55 2022

version 10.2(1) Bios:version 05.45 
control-plane
scale-factor 1.00 module 1
class-map type control-plane match-any copp-system-p-class-critical
match access-group name copp-system-p-acl-bgp
match access-group name copp-system-p-acl-rip
match access-group name copp-system-p-acl-vpc
match access-group name copp-system-p-acl-bgp6
match access-group name copp-system-p-acl-ospf
match access-group name copp-system-p-acl-rip6
match access-group name copp-system-p-acl-eigrp
match access-group name copp-system-p-acl-ospf6
match access-group name copp-system-p-acl-eigrp6
match access-group name copp-system-p-acl-auto-rp
match access-group name copp-system-p-acl-mac-l3-isis
(snip)
...

Die Klassenzuordnung copp-system-p-class-criticalverweist auf mehrere Zuordnungsanweisungen, die System-ACLs aufrufen, die standardmäßig ausgeblendet sind, und verweist auf die Klassifizierung, die zugeordnet wird. Beispiel für BGP:

N9K1# show running-config aclmgr all | b copp-system-p-acl-bgp
ip access-list copp-system-p-acl-bgp
10 permit tcp any gt 1023 any eq bgp 
20 permit tcp any eq bgp any gt 1023 
(snip)


Dies bedeutet, dass jeder BGP-Datenverkehr mit dieser Klasse übereinstimmt und unter sowie allen anderen Protokollen copp-system-p-class-criticaldieser Klasse klassifiziert wird.

Der Nexus 7000 verwendet eine CoPP-Funktionsstruktur, die der des Nexus 9000 sehr ähnlich ist:

N77-A-Admin# show policy-map interface control-plane 
Control Plane
service-policy input copp-system-p-policy-strict

class-map copp-system-p-class-critical (match-any)
match access-group name copp-system-p-acl-bgp
match access-group name copp-system-p-acl-rip
match access-group name copp-system-p-acl-vpc
match access-group name copp-system-p-acl-bgp6
match access-group name copp-system-p-acl-lisp
match access-group name copp-system-p-acl-ospf
match access-group name copp-system-p-acl-rip6
match access-group name copp-system-p-acl-rise
match access-group name copp-system-p-acl-eigrp
match access-group name copp-system-p-acl-lisp6
match access-group name copp-system-p-acl-ospf6
match access-group name copp-system-p-acl-rise6
match access-group name copp-system-p-acl-eigrp6
match access-group name copp-system-p-acl-otv-as
match access-group name copp-system-p-acl-mac-l2pt
match access-group name copp-system-p-acl-mpls-ldp
match access-group name copp-system-p-acl-mpls-rsvp
match access-group name copp-system-p-acl-mac-l3-isis
match access-group name copp-system-p-acl-mac-otv-isis
match access-group name copp-system-p-acl-mac-fabricpath-isis
match protocol mpls router-alert
set cos 7
police cir 36000 kbps bc 250 ms 
conform action: transmit 
violate action: drop 
module 1:
conformed 300763871 bytes,
5-min offered rate 132 bytes/sec
peak rate 125 bytes/sec at Sun May 01 09:50:51 2022
violated 0 bytes,
5-min violate rate 0 bytes/sec
peak rate 0 bytes/sec
module 2:
conformed 4516900216 bytes,
5-min offered rate 1981 bytes/sec
peak rate 1421 bytes/sec at Fri Apr 29 15:40:40 2022
violated 0 bytes,
5-min violate rate 0 bytes/sec
peak rate 0 bytes/sec
module 6:
conformed 0 bytes,
5-min offered rate 0 bytes/sec
peak rate 0 bytes/sec
violated 0 bytes,
5-min violate rate 0 bytes/sec
peak rate 0 bytes/sec


Beachten Sie, dass bei Nexus 7000, da es sich um modulare Switches handelt, die Klasse nach Modul aufgeteilt ist. Die CIR gilt jedoch für die Gesamtheit aller Module, und CoPP gilt für das gesamte Chassis. Die CoPP-Verifizierung und -Ausgaben sind nur im Standard- oder Admin-VDC (Virtual Device Context) sichtbar.


Es ist besonders wichtig, CoPP auf einem Nexus 7000 zu überprüfen, wenn Probleme auf der Kontrollebene auftreten, da Instabilitäten auf einem VDC mit übermäßigem CPU-gebundenem Datenverkehr, die zu CoPP-Verletzungen führen, die Stabilität anderer VDCs beeinträchtigen können.

Auf einem Nexus 5600 können die Klassen variieren. Für BGP ist es daher eine eigene Klasse:

N5K# show policy-map interface control-plane 
Control Plane
(snip)
class-map copp-system-class-bgp (match-any)
match protocol bgp
police cir 9600 kbps , bc 4800000 bytes 
conformed 1510660 bytes; action: transmit 
violated 0 bytes;
(snip)

Auf einem Nexus 3100 gibt es drei Routing-Protokollklassen. Um zu überprüfen, zu welcher Klasse BGP gehört, verweisen Sie auf die vier referenzierten CoPP-ACL:
EIGRP wird auf dem Nexus 3100 von einer eigenen Klasse behandelt.

N3K-C3172# show policy-map interface control-plane 
Control Plane

service-policy input: copp-system-policy

class-map copp-s-routingProto2 (match-any)
match access-group name copp-system-acl-routingproto2
police pps 1300 
OutPackets 0
DropPackets 0
class-map copp-s-v6routingProto2 (match-any)
match access-group name copp-system-acl-v6routingProto2
police pps 1300 
OutPackets 0
DropPackets 0
class-map copp-s-eigrp (match-any)
match access-group name copp-system-acl-eigrp
match access-group name copp-system-acl-eigrp6
police pps 200 
OutPackets 0
DropPackets 0
class-map copp-s-routingProto1 (match-any)
match access-group name copp-system-acl-routingproto1
match access-group name copp-system-acl-v6routingproto1
police pps 1000 
OutPackets 0
DropPackets 0

N3K-C3172# show running-config aclmgr

!Command: show running-config aclmgr
!No configuration change since last restart
!Time: Sun May 1 18:14:16 2022

version 9.3(9) Bios:version 5.3.1 
ip access-list copp-system-acl-eigrp
10 permit eigrp any 224.0.0.10/32 
ipv6 access-list copp-system-acl-eigrp6
10 permit eigrp any ff02::a/128 
ip access-list copp-system-acl-routingproto1
10 permit tcp any gt 1024 any eq bgp 
20 permit tcp any eq bgp any gt 1024 
30 permit udp any 224.0.0.0/24 eq rip 
40 permit tcp any gt 1024 any eq 639 
50 permit tcp any eq 639 any gt 1024 
70 permit ospf any any 
80 permit ospf any 224.0.0.5/32 
90 permit ospf any 224.0.0.6/32 
ip access-list copp-system-acl-routingproto2
10 permit udp any 224.0.0.0/24 eq 1985 
20 permit 112 any 224.0.0.0/24 
ipv6 access-list copp-system-acl-v6routingProto2
10 permit udp any ff02::66/128 eq 2029 
20 permit udp any ff02::fb/128 eq 5353 
30 permit 112 any ff02::12/128 
ipv6 access-list copp-system-acl-v6routingproto1
10 permit 89 any ff02::5/128 
20 permit 89 any ff02::6/128 
30 permit udp any ff02::9/128 eq 521 


In diesem Fall wird das BGP von der ACL abgeglichen, copp-system-acl-routingproto1und somit fällt auch die CoPP-Klasse BGP in copp-s-routingProto1.

Control Plane Policing-Statistiken und -Zähler

CoPP unterstützt QoS-Statistiken zur Verfolgung der aggregierten Zähler für Datenverkehr, der die Committed Input Rate (CIR) für eine bestimmte Klasse für jedes Modul bestätigt oder verletzt.


Jede Klassenzuordnung klassifiziert CPU-gebundenen Datenverkehr basierend auf der entsprechenden Klasse und fügt eine CIR für alle Pakete an, die unter diese Klassifizierung fallen. Als Referenz wird beispielsweise die Klasse verwendet, die sich auf den BGP-Datenverkehr bezieht:

Auf einem Nexus 9000 Top-of-Rack (TOR) für copp-system-p-class-critical:

class-map copp-system-p-class-critical (match-any)
match access-group name copp-system-p-acl-bgp
match access-group name copp-system-p-acl-rip
match access-group name copp-system-p-acl-vpc
match access-group name copp-system-p-acl-bgp6
match access-group name copp-system-p-acl-ospf
match access-group name copp-system-p-acl-rip6
match access-group name copp-system-p-acl-eigrp
match access-group name copp-system-p-acl-ospf6
match access-group name copp-system-p-acl-eigrp6
match access-group name copp-system-p-acl-auto-rp
match access-group name copp-system-p-acl-mac-l3-isis
set cos 7
police cir 36000 kbps , bc 1280000 bytes 
module 1 : 
transmitted 177446058 bytes;
5-minute offered rate 3 bytes/sec
conformed 27 peak-rate bytes/sec
at Sat Apr 23 04:25:27 2022

dropped 0 bytes;
5-min violate rate 0 byte/sec
violated 0 peak-rate byte/sec

Im Abschnitt class-map werden nach den Match-Anweisungen die Aktionen angezeigt, die sich auf den gesamten Datenverkehr innerhalb der Klasse beziehen. Der gesamte Datenverkehr innerhalb von copp-system-p-class-critical wird mit einer Class of Service (CoS) von 7 festgelegt, d. h. dem Datenverkehr mit der höchsten Priorität. Diese Klasse wird mit einer CIR von 36000 Kbit/s und einer Committed-Burst-Rate von 1280000 Byte geregelt.

Datenverkehr, der dieser Richtlinie entspricht, wird zur Verarbeitung an den SUP weitergeleitet, und alle Verletzungen werden verworfen.

set cos 7
police cir 36000 kbps , bc 1280000 bytes

Der nächste Abschnitt enthält die Statistiken für das Modul, für Top-of-Rack (TOR)-Switches, mit einem einzelnen Modul, Modul 1 bezieht sich auf den Switch.

module 1 : 
transmitted 177446058 bytes;
5-minute offered rate 3 bytes/sec
conformed 27 peak-rate bytes/sec
at Sat Apr 23 04:25:27 2022

dropped 0 bytes;
5-min violate rate 0 byte/sec
violated 0 peak-rate byte/sec

Die in der Ausgabe angezeigten Statistiken sind historisch, d. h., es wird ein Snapshot der aktuellen Statistiken zum Zeitpunkt der Ausführung des Befehls bereitgestellt.

Es gibt zwei Abschnitte, die hier interpretiert werden müssen: die übertragenen und die verworfenen Abschnitte:
Der übertragene Datenpunkt verfolgt alle übertragenen Pakete, die der Richtlinie entsprechen. Dieser Abschnitt ist wichtig, da er einen Einblick in die Art des Datenverkehrs bietet, den der Supervisor verarbeitet.

Der 5-Minuten-Tarif bietet einen Einblick in den aktuellen Tarif.
Die konforme Spitzenauslastung mit Datum gibt einen Überblick über die höchste Spitzenauslastung pro Sekunde, die noch mit der Richtlinie konform ist, und über den Zeitpunkt, zu dem sie aufgetreten ist.
Wenn ein neuer Höchstwert angezeigt wird, werden dieser Wert und dieses Datum ersetzt.

Der wichtigste Teil der Statistik ist der verworfene Datenpunkt. Genau wie die übertragenen Statistiken verfolgt der verworfene Abschnitt die kumulativen Bytes, die aufgrund von Verletzungen an die Polizeirate verworfen wurden. Außerdem werden die Verletzungsrate für die letzten 5 Minuten, der verletzte Peak und, falls ein Peak vorliegt, der Zeitstempel dieses Peak-Verstoßes angegeben. Und nochmal, wenn ein neuer Höchstwert gesehen wird, dann ersetzt er diesen Wert und dieses Datum. Auf anderen Plattformen variieren die Ausgänge, aber die Logik ist sehr ähnlich.

Der Nexus 7000 verwendet eine identische Struktur, und die Überprüfung ist dieselbe, obwohl einige Klassen in den referenzierten ACLs geringfügig variieren:

class-map copp-system-p-class-critical (match-any)
match access-group name copp-system-p-acl-bgp
match access-group name copp-system-p-acl-rip
match access-group name copp-system-p-acl-vpc
match access-group name copp-system-p-acl-bgp6
match access-group name copp-system-p-acl-lisp
match access-group name copp-system-p-acl-ospf
match access-group name copp-system-p-acl-rip6
match access-group name copp-system-p-acl-rise
match access-group name copp-system-p-acl-eigrp
match access-group name copp-system-p-acl-lisp6
match access-group name copp-system-p-acl-ospf6
match access-group name copp-system-p-acl-rise6
match access-group name copp-system-p-acl-eigrp6
match access-group name copp-system-p-acl-otv-as
match access-group name copp-system-p-acl-mac-l2pt
match access-group name copp-system-p-acl-mpls-ldp
match access-group name copp-system-p-acl-mpls-rsvp
match access-group name copp-system-p-acl-mac-l3-isis
match access-group name copp-system-p-acl-mac-otv-isis
match access-group name copp-system-p-acl-mac-fabricpath-isis
match protocol mpls router-alert
set cos 7
police cir 36000 kbps bc 250 ms 
conform action: transmit 
violate action: drop 
module 1:
conformed 300763871 bytes,
5-min offered rate 132 bytes/sec
peak rate 125 bytes/sec at Sun May 01 09:50:51 2022
violated 0 bytes,
5-min violate rate 0 bytes/sec
peak rate 0 bytes/sec
module 2:
conformed 4516900216 bytes,
5-min offered rate 1981 bytes/sec
peak rate 1421 bytes/sec at Fri Apr 29 15:40:40 2022
violated 0 bytes,
5-min violate rate 0 bytes/sec
peak rate 0 bytes/sec
module 6:
conformed 0 bytes,
5-min offered rate 0 bytes/sec
peak rate 0 bytes/sec
violated 0 bytes,
5-min violate rate 0 bytes/sec
peak rate 0 bytes/sec

Auf einem Nexus 5600:

class-map copp-system-class-bgp (match-any)
match protocol bgp
police cir 9600 kbps , bc 4800000 bytes 
conformed 1510660 bytes; action: transmit 
violated 0 bytes;

Obwohl es keine Informationen über die Rate oder Peaks, aber es stellt immer noch die aggregierten Bytes konform und verletzt.

Auf einem Nexus 3100 wird auf der Steuerungsebene "OutPackets" und "DropPackets" angezeigt.

class-map copp-s-routingProto1 (match-any)
match access-group name copp-system-acl-routingproto1
match access-group name copp-system-acl-v6routingproto1
police pps 1000 
OutPackets 8732060
DropPackets 0

"OutPackets" bezieht sich auf konforme Pakete, "DropPackets" auf Verletzungen des CIR. In diesem Szenario werden keine Auslassungen für die zugeordnete Klasse angezeigt.

Auf einem Nexus 3500 wird in der Ausgabe "HW and SW Matched Packets" (Mit Hardware und Software übereinstimmende Pakete) angezeigt:

class-map copp-s-routingProto1 (match-any)
match access-group name copp-system-acl-routingproto1
police pps 900 
HW Matched Packets 471425
SW Matched Packets 471425

Die HW Matched Packets beziehen sich auf die Pakete, die in der HW von der ACL abgeglichen werden. Die von der Software abgeglichenen Pakete sind diejenigen, die die Richtlinie erfüllen. Alle Unterschiede zwischen den von der HW und den von der SW abgeglichenen Paketen implizieren eine Verletzung.


In diesem Fall werden bei Routing-Protokollpaketen der Klasse 1 (einschließlich BGP) keine Verluste festgestellt, da die Werte übereinstimmen.

Auf aktive Löschverstöße prüfen

Angesichts der Tatsache, dass die Statistiken der Kontrollebenen-Richtlinien historisch sind, ist es wichtig, festzustellen, ob aktive Verletzungen zunehmen. Die Standardmethode, um diese Aufgabe auszuführen, besteht darin, zwei vollständige Ausgaben zu vergleichen und eventuelle Unterschiede zu überprüfen.


Diese Aufgabe kann manuell durchgeführt werden, oder die Nexus Switches bieten das Vergleichstool, mit dem die Ergebnisse verglichen werden können.


Obwohl die gesamte Ausgabe verglichen werden kann, ist dies nicht erforderlich, da der Fokus nur auf den verworfenen Statistiken liegt. So kann die CoPP-Ausgabe so gefiltert werden, dass sie sich nur auf die Verletzungen konzentriert.

Der Befehl lautet: show policy-map interface control-plane | egrep class|module|violated|dropped | diff -y

Hinweis: Der Befehl muss zweimal ausgeführt werden, damit diff die aktuelle Ausgabe mit der vorherigen vergleichen kann.

Mit dem vorherigen Befehl können Sie das Delta zwischen zwei Klassen anzeigen und feststellen, ob eine Verletzung zugenommen hat.

Hinweis: Da die CoPP-Statistiken historisch sind, wird empfohlen, die Statistiken nach Ausführung des Befehls zu löschen, um zu überprüfen, ob aktive Erhöhungen vorliegen. Führen Sie den folgenden Befehl aus, um die CoPP-Statistik zu löschen: clear copp statistics.

Arten von CoPP-Verlusten

CoPP ist eine einfache Richtlinienstruktur, da jeder CPU-gebundene Datenverkehr, der gegen die CIR verstößt, verworfen wird. Die Auswirkungen variieren jedoch erheblich je nach Art der Tropfen.

Die Logik ist zwar die gleiche, jedoch nicht die gleiche, wenn Datenverkehr, der an copp-system-p-class-critical.

class-map copp-system-p-class-critical (match-any)
match access-group name copp-system-p-acl-bgp
match access-group name copp-system-p-acl-rip
match access-group name copp-system-p-acl-vpc
match access-group name copp-system-p-acl-bgp6
match access-group name copp-system-p-acl-ospf
match access-group name copp-system-p-acl-rip6
match access-group name copp-system-p-acl-eigrp
match access-group name copp-system-p-acl-ospf6
match access-group name copp-system-p-acl-eigrp6
match access-group name copp-system-p-acl-auto-rp
match access-group name copp-system-p-acl-mac-l3-isis
set cos 7
police cir 36000 kbps , bc 1280000 bytes

Im Vergleich dazu wird Datenverkehr, der für die Klassenzuordnung bestimmt ist, verworfen copp-system-p-class-monitoring.

class-map copp-system-p-class-monitoring (match-any)
match access-group name copp-system-p-acl-icmp
match access-group name copp-system-p-acl-icmp6
match access-group name copp-system-p-acl-traceroute
set cos 1
police cir 360 kbps , bc 128000 bytes

Die erste betrifft hauptsächlich Routing-Protokolle, die zweite das Internet Control Message Protocol (ICMP), das eine der niedrigsten Prioritäten und CIR hat. Der CIR-Unterschied ist um das Hundertfache. Daher ist es wichtig, die Klassen, Auswirkungen, häufigen Überprüfungen/Überprüfungen und Empfehlungen zu verstehen.

CoPP-Klassen

Klassenüberwachung: copp-system-p-class-monitoring


Diese Klasse umfasst ICMP für IPv4 und IPv6 sowie die Traceroute für den an den betreffenden Switch gerichteten Datenverkehr.

class-map copp-system-p-class-monitoring (match-any)
match access-group name copp-system-p-acl-icmp
match access-group name copp-system-p-acl-icmp6
match access-group name copp-system-p-acl-traceroute
set cos 1
police cir 360 kbps , bc 128000 bytes 

Auswirkungen

Eine weit verbreitete Fehlvorstellung bei der Fehlerbehebung von Paketverlusten oder Latenz ist das Senden eines Ping an den Switch über dessen Inband-Ports, die durch CoPP in der Übertragungsrate begrenzt sind. Da CoPP ICMP streng regelt, kann selbst bei geringem Datenverkehr oder Engpässen ein Paketverlust durch einen Ping an In-Band-Schnittstellen direkt erkannt werden, wenn diese die CIR verletzen.

Wenn Sie z. B. an direkt verbundene Schnittstellen an gerouteten Ports mit einer Paketnutzlast von 500 Ping-Signalen senden, kann dies in regelmäßigen Abständen zu Verwerfungen führen.

N9K-3# ping 192.168.1.1 count 1000 packet-size 500
...
--- 192.168.1.1 ping statistics ---
1000 packets transmitted, 995 packets received, 0.50% packet loss
round-trip min/avg/max = 0.597/0.693/2.056 ms

Auf dem Nexus, an dem die ICMP-Pakete bestimmt waren, wurden sie vom CoPP verworfen, da die Verletzung erkannt wurde und die CPU geschützt war:

N9K-4# show policy-map interface control-plane class copp-system-p-class-monitoring
Control Plane

Service-policy input: copp-system-p-policy-strict

class-map copp-system-p-class-monitoring (match-any)
match access-group name copp-system-p-acl-icmp
match access-group name copp-system-p-acl-icmp6
match access-group name copp-system-p-acl-traceroute
set cos 1
police cir 360 kbps , bc 128000 bytes 
module 1 :
transmitted 750902 bytes;
5-minute offered rate 13606 bytes/sec
conformed 13606 peak-rate bytes/sec
at Sun May 01 22:49:24 2022

dropped 2950 bytes;
5-min violate rate 53 byte/sec
violated 53 peak-rate byte/sec at Sun May 01 22:49:24 2022

Um Latenz oder Paketverluste zu beheben, wird empfohlen, Hosts zu verwenden, die über den Switch auf Datenebene erreichbar sind, nicht auf den Switch selbst, der Datenverkehr auf Kontrollebene wäre. Datenverkehr auf Datenebene wird auf Hardwareebene ohne SUP-Intervention weitergeleitet bzw. geroutet und wird daher nicht durch CoPP geregelt. In der Regel treten keine Unterbrechungen auf.

Empfehlungen

• Senden Sie einen Ping über den Switch durch die Datenebene und nicht an den Switch, um falsch positive Ergebnisse für Paketverluste zu überprüfen.
• Begrenzen Sie das Network Monitoring System (NMS) oder Tools, die aggressiv ICMP am Switch verwenden, um einen Burst durch die Committed Input Rate für die Klasse zu vermeiden. Beachten Sie, dass CoPP für den gesamten aggregierten Datenverkehr gilt, der in die Klasse fällt.

Klassenverwaltung - copp-system-p-class-management

Wie hier gezeigt, umfasst diese Klasse verschiedene Verwaltungsprotokolle, die für Kommunikation (SSH, Telnet), Übertragungen (SCP, FTP, HTTP, SFTP, TFTP), Taktung (NTP), AAA (Radius/TACACS) und Überwachung (SNMP) für IPv4- und IPv6-Kommunikation verwendet werden können.

class-map copp-system-p-class-management (match-any)
match access-group name copp-system-p-acl-ftp
match access-group name copp-system-p-acl-ntp
match access-group name copp-system-p-acl-ssh
match access-group name copp-system-p-acl-http
match access-group name copp-system-p-acl-ntp6
match access-group name copp-system-p-acl-sftp
match access-group name copp-system-p-acl-snmp
match access-group name copp-system-p-acl-ssh6
match access-group name copp-system-p-acl-tftp
match access-group name copp-system-p-acl-https
match access-group name copp-system-p-acl-snmp6
match access-group name copp-system-p-acl-tftp6
match access-group name copp-system-p-acl-radius
match access-group name copp-system-p-acl-tacacs
match access-group name copp-system-p-acl-telnet
match access-group name copp-system-p-acl-radius6
match access-group name copp-system-p-acl-tacacs6
match access-group name copp-system-p-acl-telnet6
set cos 2
police cir 36000 kbps , bc 512000 bytes

Auswirkungen

Zu den gängigsten mit dieser Klasse verknüpften Verhaltensweisen oder Drops gehören:

• Langsame CLI-Anzeige bei Verbindung über SSH/Telnet Wenn die Klasse aktive Verwerfungen aufweist, können Kommunikationssitzungen langsam sein und Verwerfungen verursachen.
• Übertragen Sie Dateien mit den Protokollen FTP, SCP, SFTP und TFTP auf dem Switch. Das am häufigsten festgestellte Verhalten ist der Versuch, System-/Kickstart-Boot-Images über In-Band-Management-Ports zu übertragen. Dies kann zu höheren Übertragungszeiten und geschlossenen/beendeten Übertragungssitzungen führen, die durch die aggregierte Bandbreite für die Klasse bestimmt werden.
• NTP-Synchronisierungsprobleme. Diese Klasse ist ebenfalls wichtig, da sie nicht autorisierte NTP-Agenten oder -Angriffe abwehrt.
• AAA Radius- und TACACS-Services fallen ebenfalls in diese Klasse. Wenn diese Klasse betroffen ist, können Autorisierungs- und Authentifizierungsdienste am Switch für Benutzerkonten beeinträchtigt werden, was ebenfalls zu einer Verzögerung der CLI-Befehle beitragen kann.
• SNMP wird unter dieser Klasse ebenfalls geregelt. Das häufigste Verhalten, das aufgrund von Auslassungen aufgrund der SNMP-Klasse beobachtet wird, sind auf NMS-Servern, die Schritte, Sammelsammlungen oder Netzwerkscans durchführen. Wenn regelmäßig Instabilitäten auftreten, ist dies in der Regel mit dem NMS-Erfassungsplan verknüpft.

Empfehlungen

• Wenn eine langsame CLI festgestellt wird, können Sie zusammen mit einem Rückgang in dieser Klasse den Konsolenzugriff oder den Out-of-Band-Verwaltungszugriff (mgmt0) verwenden.
• Wenn System-Images auf den Switch hochgeladen werden müssen, verwenden Sie entweder den Out-of-Band-Management-Port (mgmt0) oder die USB-Ports für die schnellste Übertragung.
• Wenn NTP-Pakete verloren gehen, aktivieren Sie show ntp peer-status, und überprüfen Sie die Spalte für die Erreichbarkeit. Bei Verlust wird nicht automatisch "377" gelöscht.
• Wenn Probleme mit AAA-Services auftreten, verwenden Sie zur Fehlerbehebung nur lokale Benutzer, bis das Verhalten gemindert wird.
• Zur Minderung von SNMP-Problemen gehören weniger aggressives Verhalten, gezielte Erfassung oder Minimierung von Netzwerkscannern. Überprüfen Sie die periodischen Zeiten von Scannern bis zu Ereignissen auf CPU-Ebene.

Klasse L3 Unicast-Daten - copp-system-p-class-l3uc-data

Diese Klasse behandelt speziell "Glean Packets". Dieser Pakettyp wird auch vom Hardware Rate Limiter (HWRL) verarbeitet.


Wenn die ARP-Anforderung (Address Resolution Protocol) für den nächsten Hop nicht behoben wird, wenn eingehende IP-Pakete auf einer Linecard weitergeleitet werden, leitet die Linecard die Pakete an das Supervisor-Modul weiter.


Der Supervisor löst die MAC-Adresse für den nächsten Hop auf und programmiert die Hardware.

class-map copp-system-p-class-l3uc-data (match-any)
match exception glean
set cos 1

Dies tritt normalerweise auf, wenn statische Routen verwendet werden und der nächste Hop nicht erreichbar oder nicht aufgelöst ist.

Wenn eine ARP-Anfrage gesendet wird, fügt die Software eine /32-Drop-Adjacency in die Hardware ein, um zu verhindern, dass Pakete an dieselbe Next-Hop-IP-Adresse an den Supervisor weitergeleitet werden. Wenn der ARP behoben ist, wird der Hardwareeintrag mit der richtigen MAC-Adresse aktualisiert. Wenn der ARP-Eintrag nicht vor Ablauf einer Zeitüberschreitung behoben wird, wird der Eintrag von der Hardware entfernt.

Hinweis: CoPP und HWRL arbeiten zusammen, um sicherzustellen, dass die CPU geschützt ist. Obwohl sie ähnliche Funktionen auszuführen scheinen, tritt HWRL zuerst auf. Die Implementierung basiert darauf, wo die spezifische Funktion in den Forwarding-Engines des ASIC implementiert wird. Dieser serielle Ansatz ermöglicht eine detaillierte und mehrschichtige Absicherung, bei der alle CPU-gebundenen Pakete bewertet werden.

Der HWRL wird pro Instanz/Weiterleitungs-Engine auf dem Modul ausgeführt und kann mit dem Befehl angezeigt werden show hardware rate-limiter. HWRL wird in diesem technischen Dokument nicht behandelt.

show hardware rate-limiter

Units for Config: kilo bits per second
Allowed, Dropped & Total: aggregated bytes since last clear counters


Module: 1
R-L Class Config Allowed Dropped Total
+----------------+----------+--------------------+--------------------+--------------------+
L3 glean 100 0 0 0
L3 mcast loc-grp 3000 0 0 0
access-list-log 100 0 0 0
bfd 10000 0 0 0
fex 12000 0 0 0
span 50 0 0 0
sflow 40000 0 0 0
vxlan-oam 1000 0 0 0
100M-ethports 10000 0 0 0
span-egress disabled 0 0 0
dot1x 3000 0 0 0
mpls-oam 300 0 0 0
netflow 120000 0 0 0
ucs-mgmt 12000 0 0 0

Auswirkungen

• Der Datenverkehr auf Datenebene wird dem Supervisor als Verletzung gemeldet, da er nicht in der Hardware verarbeitet werden kann. Dadurch wird die CPU unter Druck gesetzt.

Empfehlungen

• Die gängige Lösung zur Minimierung der Glean-Drops besteht darin, sicherzustellen, dass der nächste Hop erreichbar ist, und die Glean-Throttling-Funktion durch den Konfigurationsbefehl zu aktivieren: hardware ip glean throttle.

Auf dem Nexus 7000 8.4(2) wurde auch die Unterstützung von Blütenfiltern für Glean-Adjacencies für M3- und F4-Module eingeführt. Weitere Informationen finden Sie im Konfigurationshandbuch für Unicast-Routing in der Cisco Nexus 7000-Serie

Überprüfen Sie alle statischen Routenkonfigurationen, die nicht erreichbare Next-Hop-Adressen verwenden, oder verwenden Sie dynamische Routing-Protokolle, die solche Routen dynamisch aus der RIB entfernen würden.

Klassenkritisch - class-map copp-system-p-class-critical

Diese Klasse bezieht sich aus L3-Sicht auf die wichtigsten Protokolle der Steuerungsebene. Dazu gehören Routing-Protokolle für IPv4 und IPv6, (RIP, OSPF, EIGRP, BGP), Auto-RP, Virtual Port-Channel (vPC) sowie l2pt und IS-IS.

class-map copp-system-p-class-critical (match-any)
match access-group name copp-system-p-acl-bgp
match access-group name copp-system-p-acl-rip
match access-group name copp-system-p-acl-vpc
match access-group name copp-system-p-acl-bgp6
match access-group name copp-system-p-acl-ospf
match access-group name copp-system-p-acl-rip6
match access-group name copp-system-p-acl-eigrp
match access-group name copp-system-p-acl-ospf6
match access-group name copp-system-p-acl-eigrp6
match access-group name copp-system-p-acl-auto-rp
match access-group name copp-system-p-acl-mac-l2pt
match access-group name copp-system-p-acl-mac-l3-isis
set cos 7
police cir 36000 kbps , bc 1280000 bytes 

Auswirkungen

Drops bei instabiler copp-system-p-class-critical Übertragung an Routing-Protokolle, z. B. abgebrochene Adjacencies, Konvergenzfehler oder Update-/NLRI-Propagierung.
Die gebräuchlichsten Richtlinien für diese Klasse können sich auf nicht autorisierte Geräte im Netzwerk beziehen, die ungewöhnlich (aufgrund von Fehlkonfigurationen oder Fehlern) oder skalierbar sind.

Empfehlungen

• Wenn keine Anomalien erkannt werden, z. B. ein nicht autorisiertes Gerät oder eine L2-Instabilität, die eine fortlaufende Rekonvergenz der Protokolle der oberen Schichten verursacht, kann eine benutzerdefinierte Konfiguration von CoPP oder eine flexiblere Klasse erforderlich sein, um die Skalierung zu ermöglichen.
• Informationen zum Konfigurieren eines benutzerdefinierten CoPP-Profils anhand eines bereits vorhandenen Standardprofils finden Sie im CoPP-Konfigurationsleitfaden.
  Kopieren der CoPP-Best Practice-Richtlinie

Klasse wichtig - copp-system-p-class-important


Diese Klasse bezieht sich auf die First-Hop Redundancy Protocols (FHRP), die HSRP, VRRP und auch LLDP umfassen

class-map copp-system-p-class-important (match-any)
match access-group name copp-system-p-acl-hsrp
match access-group name copp-system-p-acl-vrrp
match access-group name copp-system-p-acl-hsrp6
match access-group name copp-system-p-acl-vrrp6
match access-group name copp-system-p-acl-mac-lldp
set cos 6
police cir 2500 kbps , bc 1280000 bytes

Auswirkungen


Das häufigste Verhalten, das hier beobachtet wird und zu Drops führt, sind Probleme mit Layer-2-Instabilitäten, die zu Geräten führen, die in einen aktiven Zustand (Split-Brain) übergehen, aggressive Timer, Fehlkonfigurationen oder Skalierbarkeit.

Empfehlungen:

• Stellen Sie für FHRP sicher, dass die Gruppen ordnungsgemäß konfiguriert sind und die Rollen entweder aktiv/Standby oder primär/sekundär sind und ordnungsgemäß ausgehandelt werden und dass es keine Flaps auf den Status gibt.
• Überprüfen Sie, ob in L2 Konvergenzprobleme oder Multicast-Propagierung für die L2-Domäne vorliegen.

Class L2 Unpoliced - copp-system-p-class-l2-unpoliced

Die L2-Unpoliced-Klasse bezieht sich auf alle kritischen Layer-2-Protokolle, die die Grundlage für alle Protokolle der oberen Schicht bilden und daher als nahezu Unpoliced mit der höchsten CIR und Priorität angesehen werden.


Diese Klasse verarbeitet effektiv Spanning Tree Protocol (STP), Link Aggregation Control Protocol (LACP), Cisco Fabric Service over Ethernet (CFSoE).

class-map copp-system-p-class-l2-unpoliced (match-any)
match access-group name copp-system-p-acl-mac-stp
match access-group name copp-system-p-acl-mac-lacp
match access-group name copp-system-p-acl-mac-cfsoe
match access-group name copp-system-p-acl-mac-sdp-srp
match access-group name copp-system-p-acl-mac-l2-tunnel
match access-group name copp-system-p-acl-mac-cdp-udld-vtp
set cos 7
police cir 50 mbps , bc 8192000 bytes

Diese Klasse verfügt über eine CIR von 50 Mbit/s, die höchste aller Klassen, zusammen mit der höchsten Burst-Rate-Absorption.

Auswirkungen

Drops in dieser Klasse können zu globaler Instabilität führen, da alle Protokolle der oberen Schicht und die Kommunikation auf Daten-, Kontroll- und Verwaltungsebenen von der zugrunde liegenden Layer-2-Stabilität abhängen.

Probleme mit STP-Verletzungen können TCNs und STP-Konvergenzprobleme verursachen. Dazu gehören STP-Streitigkeiten, MAC-Löschungen, Verschiebungen und Lernbehinderungen, die Probleme mit der Erreichbarkeit verursachen und Datenverkehrsschleifen verursachen können, die das Netzwerk destabilisieren.

Diese Klasse verweist auch auf LACP und verarbeitet daher alle mit 0x8809 verknüpften EtherType-Pakete, die alle LACPDUs enthalten, die zum Beibehalten des Zustands der Port-Channel-Bindungen verwendet werden. Instabilität in dieser Klasse kann dazu führen, dass die Port-Channels ein Timeout erhalten, wenn die LACPDUs verworfen werden.

Cisco Fabric Service over Ethernet (CSFoE) gehört zu dieser Klasse und wird verwendet, um kritische Anwendungssteuerungszustände zwischen Nexus-Switches zu kommunizieren. Aus diesem Grund ist es wichtig, dass die Switches stabil bleiben.

Dasselbe gilt für andere Protokolle innerhalb dieser Klasse, darunter CDP, UDLD und VTP.

Empfehlungen

• Das häufigste Verhalten bezieht sich auf L2-Ethernet-Instabilität. Sicherstellung, dass STP planmäßig ausgelegt ist und die relevanten Funktionsverbesserungen im Spiel sind, um die Auswirkungen von Rekonvergenz oder nicht autorisierten Geräten im Netzwerk zu minimieren. Stellen Sie sicher, dass der richtige STP-Port-Typ für alle End-Host-Geräte konfiguriert ist, die nicht an der L2-Erweiterung teilnehmen und als Edge/Edge-Trunk-Ports konfiguriert sind, um die Anzahl der TCNs zu minimieren.
• Verwenden Sie ggf. STP-Erweiterungen wie BPDUguard, Loopguard, BPDUfilter und RootGuard, um den Umfang eines Fehlers oder Probleme mit falsch konfigurierten oder nicht autorisierten Geräten im Netzwerk einzuschränken.
• Siehe: Konfigurationsleitfaden für Layer-2-Switching in Cisco Nexus 9000 NX-OS, Version 10.2(x)
• Suchen Sie nach MAC-Verschiebungsverhalten, das zu einer Deaktivierung des MAC-Lernvorgangs und zu Leerungen führen kann. Siehe: Fehlerbehebung und Vorbeugung bei Verschiebungen von Nexus 9000-Macs

Class Multicast Router - class-map copp-system-p-class-multicast-router


Diese Klasse bezieht sich auf PIM-Pakete (Protocol Independent Multicast) der Kontrollebene, die für die Einrichtung und Steuerung von Multicast Shared Trees über alle PIM-fähigen Geräte im Datenebenenpfad verwendet werden. Sie umfasst First-Hop Router (FHR), Last-Hop Router (LHR), Intermediate-Hop Router (IHR) und Rendezvous Points (RP). Zu den innerhalb dieser Klasse klassifizierten Paketen gehören die PIM-Registrierung für Quellen, PIM-Joins für Empfänger sowohl für IPv4 als auch für IPv6, im Allgemeinen für den für PIM bestimmten Verkehr (224.0.0.13), und das Multicast Source Discovery Protocol (MSDP). Beachten Sie, dass es mehrere zusätzliche Klassen gibt, die sich mit sehr spezifischen Teilen der Multicast- oder RP-Funktionalität befassen, die von verschiedenen Klassen behandelt werden.

class-map copp-system-p-class-multicast-router (match-any)
match access-group name copp-system-p-acl-pim
match access-group name copp-system-p-acl-msdp
match access-group name copp-system-p-acl-pim6
match access-group name copp-system-p-acl-pim-reg
match access-group name copp-system-p-acl-pim6-reg
match access-group name copp-system-p-acl-pim-mdt-join
match exception mvpn
set cos 6
police cir 2600 kbps , bc 128000 bytes 

Auswirkungen

Die Hauptauswirkungen auf Drops, die sich auf diese Klasse beziehen, sind mit Problemen verbunden, die mit Multicast-Quellen durch PIM-Registrierung in Richtung der RPs kommunizieren oder PIM-Joins, die nicht ordnungsgemäß verarbeitet wurden, was die Shared oder Shortest Path Trees in Richtung der Quellen des Multicast-Streams oder zu den RPs destabilisieren würde. Das Verhalten kann ausgehende Schnittstellenlisten (OIL) umfassen, die aufgrund fehlender Joins nicht ordnungsgemäß ausgefüllt werden, oder (S, G) oder (*, G), die in der Umgebung nicht konsistent angezeigt werden. Probleme können auch zwischen Multicast-Routing-Domänen auftreten, die für die Verbindung auf MSDP angewiesen sind.

Empfehlungen

• Das häufigste Verhalten bei Problemen im Zusammenhang mit der PIM-Kontrolle bezieht sich auf Skalierungsprobleme oder nicht autorisierte Verhaltensweisen. Eines der häufigsten Verhaltensmuster ist die UPnP-Implementierung, die ebenfalls zu Problemen mit der Speicherauslastung führen kann. Dies kann durch Filter und einen reduzierten Umfang der nicht autorisierten Geräte behoben werden. Weitere Informationen zur Eindämmung und Filterung von Multicast-Kontrollpaketen, die von der Netzwerkrolle des Geräts abhängen, finden Sie unter: Konfigurieren der Multicast-Filterung auf Nexus 7000/N9K - Cisco

Class Multicast Host - copp-system-p-class-multicast-host

Diese Klasse verweist auf die Multicast Listener Discovery (MLD), insbesondere auf MLD-Abfrage, -Bericht, -Reduzierung und MLDv2-Pakettypen. MLD ist ein IPv6-Protokoll, das ein Host verwendet, um Multicast-Daten für eine bestimmte Gruppe anzufordern. Mithilfe der über MLD erfassten Informationen verwaltet die Software eine Liste der Multicast-Gruppen- oder Channel-Zugehörigkeiten auf Schnittstellenbasis. Die Geräte, die MLD-Pakete empfangen, senden die Multicast-Daten, die sie für angeforderte Gruppen oder Kanäle empfangen, aus dem Netzwerksegment der bekannten Empfänger. MLDv1 wird von IGMPv2 und MLDv2 von IGMPv3 abgeleitet. IGMP verwendet IP Protocol 2-Nachrichtentypen, während MLD IP Protocol 58-Nachrichtentypen verwendet, die eine Teilmenge der ICMPv6-Nachrichten darstellen.

class-map copp-system-p-class-multicast-host (match-any)
match access-group name copp-system-p-acl-mld
set cos 1
police cir 1000 kbps , bc 128000 bytes 

Auswirkungen

Drops in dieser Klasse führen zu Problemen bei der verbindungslokalen IPv6-Multicast-Kommunikation, die dazu führen können, dass Listener-Berichte von Empfängern oder Antworten auf allgemeine Abfragen verworfen werden, wodurch die Erkennung von Multicast-Gruppen, die die Hosts empfangen möchten, verhindert wird. Dies kann sich auf den Snooping-Mechanismus auswirken und dazu führen, dass der Datenverkehr nicht ordnungsgemäß über die erwarteten Schnittstellen weitergeleitet wird, die den Datenverkehr angefordert haben.

Empfehlungen

• Da MLD-Datenverkehr für IPv6 auf verbindungslokaler Ebene von Bedeutung ist, beziehen sich die häufigsten Ursachen für Verwerfungen in dieser Klasse auf Skalierung, L2-Instabilität oder nicht autorisierte Geräte.

Class Layer 3 Multicast Data - copp-system-p-class-l3mc-data  und Class Layer 3 Multicast IPv6 Data - copp-system-p-class-l3mcv6-data

Diese Klassen verweisen auf Datenverkehr, der einer Multicast-Ausnahmeredirection zur SUP entspricht. In diesem Fall gibt es zwei Bedingungen, die von diesen Klassen behandelt werden. Der erste Fehler ist Reverse-Path Forwarding (RPF), der zweite Fehler ist Destination Miss. "Destination Miss" bezieht sich auf Multicast-Pakete, bei denen die Hardwaresuche für die Layer-3-Multicast-Weiterleitungstabelle fehlschlägt und das Datenpaket an die CPU weitergeleitet wird. Diese Pakete werden manchmal verwendet, um die Multicast-Kontrollebene auszulösen/zu installieren und um Einträge zu den Hardware-Weiterleitungstabellen hinzuzufügen, die auf dem Datenverkehr der Datenebene basieren. Multicast-Pakete auf Datenebene, die die RPF verletzen, würden ebenfalls mit dieser Ausnahme übereinstimmen und als Verletzung klassifiziert werden.

class-map copp-system-p-class-l3mc-data (match-any)
match exception multicast rpf-failure
match exception multicast dest-miss
set cos 1
police cir 2400 kbps , bc 32000 bytes

class-map copp-system-p-class-l3mcv6-data (match-any)
match exception multicast ipv6-rpf-failure
match exception multicast ipv6-dest-miss
set cos 1
police cir 2400 kbps , bc 32000 bytes 

Auswirkungen

Bei RPF-Ausfällen und Ziel-Fehlern liegt ein Design- oder Konfigurationsproblem vor, das damit zusammenhängt, wie der Datenverkehr durch den Multicast-Router fließt. Ziel-Fehlschläge sind bei der Statuserstellung häufig, das Verwerfen kann zur Programmierung und zur Erstellung von (*, G), (S, G) Fehlern führen.

Empfehlungen

• Nehmen Sie Änderungen am grundlegenden Unicast-RIB-Design vor, oder fügen Sie eine statische Route hinzu, um den Datenverkehr bei RPF-Ausfällen über eine bestimmte Schnittstelle zu leiten.
• Siehe Router leitet Multicast-Pakete aufgrund eines RPF-Fehlers nicht an Host weiter

Klasse IGMP - copp-system-p-class-igmp


Diese Klasse bezieht sich auf alle IGMP-Nachrichten für alle Versionen, die zum Anfordern von Multicast-Daten für eine bestimmte Gruppe verwendet werden und von der IGMP-Snooping-Funktion zum Verwalten der Gruppen und der relevanten ausgehenden Schnittstellenliste (OIL) verwendet werden, die den Datenverkehr an die interessierten Empfänger auf Layer 2 weiterleitet. Die IGMP-Nachrichten sind lokal von Bedeutung, da sie eine Layer-3-Grenze nicht überschreiten, da ihre Time to Live (TTL) 1 sein muss, wie unter RFC 2236 (Internet Group Management Protocol, Version 2) dokumentiert. Die von dieser Klasse verarbeiteten IGMP-Pakete enthalten alle Mitgliedschaftsabfragen (allgemein oder quell-/gruppenspezifisch) sowie die Mitgliedschaft und hinterlassen Berichte von den Empfängern.

class-map copp-system-p-class-normal-igmp (match-any)
match access-group name copp-system-p-acl-igmp
set cos 3
police cir 3000 kbps , bc 64000 bytes 

Auswirkungen

Drops für diese Klasse würden sich auf allen Ebenen einer Multicast-Kommunikation zwischen Quelle und Empfänger als problematisch erweisen, je nachdem, welcher IGMP-Nachrichtentyp aufgrund der Verletzung verworfen wurde. Wenn Mitgliedsberichte von Empfängern verloren gehen, erkennt der Router keine Geräte, die am Datenverkehr interessiert sind, und nimmt daher die Schnittstelle/das VLAN nicht in die entsprechende Liste der ausgehenden Schnittstellen auf. Wenn dieses Gerät auch der abfragende oder designierte Router ist, löst es die relevanten PIM-Join-Nachrichten nicht in Richtung des RP aus, wenn sich die Quelle außerhalb der lokalen Layer-2-Domäne befindet. Daher wird die Datenebene über den Multicast-Tree nicht bis zum Empfänger oder RP eingerichtet. Wenn der Abwesenheitsbericht verloren geht, kann der Empfänger weiterhin unerwünschten Datenverkehr empfangen. Dies kann sich auch auf alle relevanten IGMP-Abfragen auswirken, die vom Abfrager ausgelöst werden, und auf die Kommunikation zwischen den Multicast-Routern in einer Domäne.

Empfehlungen

• Die häufigsten Verhaltensweisen im Zusammenhang mit IGMP-Drops betreffen L2-Instabilität, Timer-Probleme oder die Skalierung.

Klasse Normal - copp-system-p-class-normalcopp-system-p-class-normal

Diese Klasse bezieht sich auf Datenverkehr, der mit dem Standard-ARP-Datenverkehr übereinstimmt und auch den Datenverkehr umfasst, der mit 802.1X verknüpft ist und für die portbasierte Netzwerkzugriffskontrolle verwendet wird. Dies ist eine der häufigsten Klassen, bei der Verstöße festgestellt werden, da ARP-Anfragen, kostenlose ARP- und Reverse ARP-Pakete über die gesamte Layer-2-Domäne gesendet und propagiert werden. ARP-Pakete sind keine IP-Pakete. Sie enthalten keinen L3-Header. Daher wird die Entscheidung ausschließlich anhand des Umfangs der L2-Header getroffen. Wenn ein Router mit einer IP-Schnittstelle konfiguriert ist, die mit diesem Subnetz verknüpft ist, z. B. eine Switch Virtual Interface (SVI), sendet der Router die ARP-Pakete zur Verarbeitung an den SUP, da sie für die Hardware-Broadcast-Adresse bestimmt sind. Broadcast-Stürme, Layer-2-Loops (aufgrund von STP oder Flaps) oder ein unautorisiertes Gerät im Netzwerk können zu einem ARP-Stürm führen, der zu einer erheblichen Zunahme der Verletzungen führt.

class-map copp-system-p-class-normal (match-any)
match access-group name copp-system-p-acl-mac-dot1x
match protocol arp
set cos 1
police cir 1400 kbps , bc 32000 bytes 

Auswirkungen

Die Auswirkungen von Verletzungen in dieser Klasse hängen stark von der Dauer der Ereignisse und der Rolle des Switches in der Umgebung ab. Verluste in dieser Klasse implizieren, dass ARP-Pakete derzeit verworfen und daher nicht von der SUP-Engine verarbeitet werden. Dies kann zu zwei Hauptverhaltensweisen führen, die durch unvollständige ARP-Auflösungen verursacht werden.

Aus Sicht des End-Hosts können Geräte im Netzwerk die Adressenauflösung mit dem Switch nicht auflösen oder abschließen. Wenn dieses Gerät als Standard-Gateway für das Segment fungiert, kann dies dazu führen, dass Geräte ihr Gateway nicht auflösen können und daher kein Routing außerhalb ihres L2-Ethernet-Segments (VLAN) durchführen können. Geräte können weiterhin auf dem lokalen Segment kommunizieren, wenn sie die ARP-Auflösung für andere End-Hosts auf dem lokalen Segment vervollständigen können.

Aus Sicht des Switches kann es passieren, dass der Switch den Prozess für die von ihm generierte ARP-Anforderung nicht abschließen kann, wenn Sturm und Sicherheitsverletzungen weit verbreitet sind. Diese Anforderungen werden normalerweise für Next-Hop- oder direkt verbundene Subnetzauflösungen generiert. Obwohl es sich bei den ARP-Antworten um Unicast-Antworten handelt, da sie an die dem Switch angehörende MAC-Adresse gerichtet sind, werden sie unter derselben Klasse klassifiziert, da es sich nach wie vor um ARP-Pakete handelt. Dies führt zu Problemen mit der Erreichbarkeit, da der Switch den Datenverkehr nicht ordnungsgemäß verarbeiten kann, wenn der nächste Hop nicht aufgelöst wird, und kann zu Problemen mit dem Umschreiben des Layer-2-Headers führen, wenn der Adjacency Manager keinen Eintrag für den Host hat.

Die Auswirkungen hängen auch vom Umfang des grundlegenden Problems ab, das die ARP-Verletzung ausgelöst hat. Bei einem Broadcast-Sturm versuchen Hosts und der Switch beispielsweise weiterhin, ARP zu nutzen, um die Adjacency aufzulösen, was zu zusätzlichem Broadcast-Datenverkehr im Netzwerk führen kann. Da ARP-Pakete Layer 2 sind, gibt es keine Layer 3 Time To Live (TTL), um eine L2-Schleife zu unterbrechen, sodass sie weiterhin eine Schleife bilden und exponentiell durch das Netzwerk wachsen, bis die Schleife unterbrochen wird.

Empfehlungen

• Behebung grundlegender L2-Instabilitäten, die ARP-Stürme in der Umgebung verursachen können, z. B. STP, Flaps oder nicht autorisierte Geräte Unterbrechen Sie diese Schleifen nach Bedarf, indem Sie eine beliebige Methode verwenden, um den Verbindungspfad zu öffnen.
• Sturmkontrolle kann auch verwendet werden, um einen ARP-Sturm zu mildern. Wenn die Sturmkontrolle nicht aktiviert ist, überprüfen Sie die Zählerstatistiken auf den Schnittstellen, um den prozentualen Anteil des Broadcast-Datenverkehrs auf den Schnittstellen im Verhältnis zum gesamten Datenverkehr, der die Schnittstelle passiert, zu überprüfen.
• Wenn es keinen Sturm gibt, aber in der Umgebung immer noch ständige Datenverluste auftreten, überprüfen Sie den SUP-Datenverkehr, um nicht autorisierte Geräte zu identifizieren, die ständig ARP-Pakete an das Netzwerk senden und den legitimen Datenverkehr beeinträchtigen können.
• Die sichtbaren Erhöhungen hängen von der Anzahl der Hosts im Netzwerk und der Rolle des Switches in der Umgebung ab. ARP ist darauf ausgelegt, Einträge zu wiederholen, aufzulösen und zu aktualisieren. Daher wird erwartet, dass ARP-Datenverkehr jederzeit angezeigt wird. Werden nur sporadische Verluste festgestellt, können diese aufgrund der Netzwerkauslastung vorübergehend sein, und es werden keine Auswirkungen wahrgenommen. Es ist jedoch wichtig, das Netzwerk zu überwachen und zu kennen, um eine erwartete Situation richtig zu identifizieren und von einer anormalen Situation zu unterscheiden.

Class NDP - copp-system-p-acl-ndp

Diese Klasse bezieht sich auf Datenverkehr, der mit IPv6-Paketen zur Erkennung/Ankündigung von Nachbarn und Routeraufforderungs- und -ankündigungspaketen verknüpft ist, die ICMP-Nachrichten zur Bestimmung lokaler Link-Layer-Adressen von Nachbarn verwenden. Sie wird für die Erreichbarkeit und Nachverfolgung benachbarter Geräte verwendet.

class-map copp-system-p-class-ndp (match-any)
match access-group name copp-system-p-acl-ndp
set cos 6
police cir 1400 kbps , bc 32000 bytes

Auswirkungen

Verstöße in dieser Klasse können die IPv6-Kommunikation zwischen benachbarten Geräten beeinträchtigen, da diese Pakete zur dynamischen Erkennung oder für Informationen auf Verbindungsebene bzw. lokal zwischen Hosts und Routern auf der lokalen Verbindung verwendet werden. Eine Unterbrechung dieser Kommunikation kann auch zu Problemen mit der Erreichbarkeit über den zugehörigen lokalen Link hinaus oder über diesen hinaus führen. Wenn Kommunikationsprobleme zwischen IPv6-Nachbarn auftreten, stellen Sie sicher, dass diese Klasse nicht verloren geht.

Empfehlungen

• Untersuchen Sie abnorme ICMP-Verhaltensweisen von Nachbargeräten, insbesondere solche, die mit der Erkennung von Nachbarn und/oder Routern in Zusammenhang stehen.
• Stellen Sie sicher, dass alle erwarteten Timer- und Intervallwerte für die periodischen Meldungen in der gesamten Umgebung konsistent sind und eingehalten werden. Beispielsweise für Router Advertisement-Nachrichten (RA-Nachrichten).

Class Normal DHCP - copp-system-p-class-normal-dhcp


Diese Klasse bezieht sich auf Datenverkehr, der mit dem Bootstrap Protocol (BOOTP-Client/Server) verknüpft ist und allgemein als Dynamic Host Control Protocol (DHCP)-Pakete auf demselben lokalen Ethernet-Segment für IPv4 und IPv6 bezeichnet wird. Dies betrifft ausschließlich die Datenverkehrskommunikation, die von einem Bootp-Client ausgeht oder für einen beliebigen BOOTP-Server über den gesamten DORA-Paketaustausch (Discovery, Offer, Request, and Recognition) bestimmt ist, und umfasst auch DHCPv6-Client/Server-Transaktionen über die UDP-Ports 546/547. 

class-map copp-system-p-class-normal-dhcp (match-any)
match access-group name copp-system-p-acl-dhcp
match access-group name copp-system-p-acl-dhcp6
set cos 1
police cir 1300 kbps , bc 32000 bytes

Auswirkungen

Verletzungen dieser Klasse können dazu führen, dass End-Hosts keine IP-Adresse vom DHCP-Server korrekt abrufen können und somit auf ihren automatischen privaten IP-Adressbereich (APIPA) 169.254.0.0/16 zurückgreifen. Solche Verletzungen können in Umgebungen auftreten, in denen Geräte versuchen, gleichzeitig zu booten, und damit über die CIR der Klasse hinausgehen.

Empfehlungen

• Überprüfen Sie mit Captures, auf Hosts und DHCP-Server die gesamte DORA-Transaktion. Wenn der Switch Teil dieser Kommunikation ist, ist es auch wichtig, die verarbeiteten oder an die CPU gesendeten Pakete zu überprüfen und die Switch-Statistiken show ip dhcp global statistics und Umleitungen zu überprüfen: show system internal access-list sup-redirect-stats module 1 | grep -i dhcp.

Normale DHCP-Relay-Antwort der Klasse - copp-system-p-class-normal-dhcp-relay-response

Diese Klasse bezieht sich auf Datenverkehr, der mit der DHCP-Relay-Funktion für IPv4 und IPv6 verknüpft ist und an die konfigurierten DHCP-Server weitergeleitet wird, die unter dem Relay konfiguriert wurden. Dies betrifft speziell nur die Datenverkehrskommunikation, die von einem BOOTP-Server ausgeht oder über den gesamten DORA-Paketaustausch an beliebige BOOTP-Clients gerichtet ist, und umfasst auch DHCPv6-Client/Server-Transaktionen über die UDP-Ports 546/547.

class-map copp-system-p-class-normal-dhcp-relay-response (match-any)
match access-group name copp-system-p-acl-dhcp-relay-response
match access-group name copp-system-p-acl-dhcp6-relay-response
set cos 1
police cir 1500 kbps , bc 64000 bytes

Auswirkungen

Verstöße gegen diese Klasse haben die gleichen Auswirkungen wie Verstöße gegen die Klasse copp-system-p-class-normal-dhcp, da beide Teile derselben Transaktion sind. Diese Klasse konzentriert sich hauptsächlich auf die Antwortkommunikation von den Relay-Agent-Servern. Der Nexus fungiert nicht als DHCP-Server, sondern lediglich als Relay-Agent.

Empfehlungen

• Hier gelten die gleichen Empfehlungen wie für klassisches DHCP. Da der Nexus nur als Relay-Agent fungieren soll, erwarten Sie auf dem SUP, dass die gesamte Transaktion zwischen dem Host und dem Switch als Relay agiert und der Switch und die Server konfiguriert werden.
• Stellen Sie sicher, dass keine nicht autorisierten Geräte im Netzwerk vorhanden sind, z. B. unerwartete DHCP-Server, die auf den Bereich reagieren, oder Geräte, die in einer Schleife stecken und das Netzwerk mit DHCP Discover-Paketen überfluten. Zusätzliche Prüfungen können mit den Befehlen: show ip dhcp relay und show ip dhcp relay statisticsdurchgeführt werden.

Klasse NAT-Fluss - copp-system-p-class-nat-flow


Diese Klasse bezieht sich auf NAT-Datenverkehr von Software-Switches. Wenn eine neue dynamische Übersetzung erstellt wird, wird der Fluss per Software weitergeleitet, bis die Übersetzung in der Hardware programmiert ist. Anschließend wird sie von der CoPP kontrolliert, um den Datenverkehr zum Supervisor zu begrenzen, während der Eintrag in der Hardware installiert ist.

class-map copp-system-p-class-nat-flow (match-any)
match exception nat-flow
set cos 7
police cir 800 kbps , bc 64000 bytes 

Auswirkungen

Drops in dieser Klasse treten in der Regel dann auf, wenn eine hohe Rate neuer dynamischer Übersetzungen und Flows in der Hardware installiert wird. Die Auswirkungen betreffen softwaregesteuerte Pakete, die verworfen und nicht an den End-Host übermittelt werden, was zu Verlusten und erneuten Übertragungen führen kann. Sobald der Eintrag in der Hardware installiert ist, wird kein weiterer Datenverkehr an den Supervisor gesendet.

Empfehlungen

• Überprüfen Sie die Richtlinien und Einschränkungen der dynamischen NAT auf der entsprechenden Plattform. Es gibt bekannte Einschränkungen, die auf Plattformen dokumentiert sind, wie z. B. der 3548, bei dem die Übersetzung einige Sekunden dauern kann. Siehe: Einschränkungen für dynamische NAT

Klassenausnahme - copp-system-p-class-exception

Diese Klasse bezieht sich auf Ausnahmepakete, die mit der IP-Option und nicht erreichbaren IP ICMP-Paketen verknüpft sind. Wenn keine Zieladresse in der weiterleitenden Informationsbasis (FIB) vorhanden ist und ein Fehler auftritt, sendet die SUP ein nicht erreichbares ICMP-Paket zurück an den Absender. Pakete mit aktivierten IP-Optionen gehören ebenfalls zu dieser Klasse. Weitere Informationen zu IP-Optionen finden Sie im IANA-Dokument: IP-Optionsnummern

 class-map copp-system-p-class-exception (match-any)
match exception ip option
match exception ip icmp unreachable
match exception ipv6 option
match exception ipv6 icmp unreachable
set cos 1
police cir 150 kbps , bc 32000 bytes

Auswirkungen

Diese Klasse wird streng überwacht, und Verwerfungen in dieser Klasse weisen nicht auf einen Fehler hin, sondern auf einen Schutzmechanismus, um den Umfang von nicht erreichbaren ICMP-Paketen und IP-Optionspaketen zu begrenzen.

Empfehlungen

• Überprüfen Sie, ob Datenverkehrsflüsse an die CPU gesendet werden, wenn diese Ziele nicht auf der FIB findet.

Klassenumleitung - copp-system-p-class-redirect

Diese Klasse bezieht sich auf den Datenverkehr, der dem Precision Time Protocol (PTP) für die Zeitsynchronisierung zugeordnet ist. Dies umfasst Multicast-Datenverkehr für den reservierten Bereich 224.0.1.129/32, Unicast-Datenverkehr auf dem UDP-Port 319/320 und Ethernet-Typ 0X88F7.

class-map copp-system-p-class-redirect (match-any)
match access-group name copp-system-p-acl-ptp
match access-group name copp-system-p-acl-ptp-l2
match access-group name copp-system-p-acl-ptp-uc
set cos 1
police cir 280 kbps , bc 32000 bytes 

Auswirkungen

Drops in dieser Klasse können zu Problemen auf Geräten führen, die nicht richtig synchronisiert wurden oder die nicht die richtige Hierarchie festgelegt haben.

Empfehlungen

• Stellen Sie sicher, dass die Uhren stabil sind und korrekt konfiguriert sind. Stellen Sie sicher, dass das PTP-Gerät für den Multicast- oder Unicast-PTP-Modus konfiguriert ist, jedoch nicht für beide gleichzeitig. Dies wird ebenfalls in den Richtlinien und Einschränkungen dokumentiert und kann dazu führen, dass der Datenverkehr die vereinbarte Eingangsrate überschreitet.
• Überprüfen Sie Design und Konfiguration der Boundary Clock und aller PTP-Geräte in der Umgebung. Stellen Sie sicher, dass alle Richtlinien und Einschränkungen für jede Plattform befolgt werden, da diese unterschiedlich sind.

Klasse OpenFlow - copp-system-p-class-openflow

Diese Klasse bezieht sich auf Datenverkehr, der mit OpenFlow-Agentenvorgängen und der entsprechenden TCP-Verbindung zwischen dem Controller und dem Agenten verknüpft ist.

class-map copp-system-p-class-openflow (match-any)
match access-group name copp-system-p-acl-openflow
set cos 5
police cir 1000 kbps , bc 32000 bytes 

Auswirkungen

Stürze in dieser Klasse können zu Problemen in Agenten führen, die die Anweisungen vom Controller zum Verwalten der Weiterleitungsebene des Netzwerks nicht ordnungsgemäß empfangen und verarbeiten.

Empfehlungen

• Stellen Sie sicher, dass im Netzwerk oder auf einem Gerät, das die Kommunikation zwischen Controller und Agenten behindert, kein doppelter Datenverkehr vorhanden ist.
• Überprüfen Sie, ob das L2-Netzwerk nicht instabil ist (STP oder Schleifen).

Problembehandlung bei CoPP-Ausfällen

Die ersten Schritte zur Fehlerbehebung bei CoPP-Verletzungen bestehen in der Ermittlung von:

• Auswirkungen und Umfang des Problems.
• Verständnis des Datenverkehrsflusses durch die Umgebung und der Rolle des Switches in der betroffenen Kommunikation
• Stellen Sie fest, ob Verstöße gegen die zugeordnete Klasse vorliegen, und wiederholen Sie diese bei Bedarf.

Das aufgelistete Verhalten wurde z. B. erkannt:

• Die Geräte können nicht mit anderen Geräten außerhalb ihres Netzwerks kommunizieren, sondern lokal.
• Die Auswirkungen wurden auf die geroutete Kommunikation außerhalb des VLAN isoliert, und der Switch fungiert als Standard-Gateway.
• Eine Überprüfung der Hosts zeigt an, dass sie das Gateway nicht pingen können. Nach der Überprüfung der ARP-Tabelle lautet der Eintrag für das Gateway weiterhin Unvollständig.
• Alle anderen Hosts, die das Gateway beheben lassen, haben keine Kommunikationsprobleme. Eine Prüfung von CoPP auf dem Switch, der als Gateway fungiert, weist auf Verstöße gegen copp-system-p-class-normal hin.

class-map copp-system-p-class-normal (match-any)
match access-group name copp-system-p-acl-mac-dot1x
match protocol arp
set cos 1
police cir 1400 kbps , bc 32000 bytes 
module 1 :
transmitted 3292445628 bytes;
dropped 522023852 bytes;

• Außerdem zeigen mehrere Befehlsprüfungen, dass die Löschvorgänge aktiv zunehmen.
• Diese Verletzungen können dazu führen, dass legitimer ARP-Datenverkehr verworfen wird, was zu einer Diensteverweigerung führt.

Es muss hervorgehoben werden, dass CoPP die Auswirkungen auf den Datenverkehr isoliert, der mit der spezifischen Klasse verknüpft ist, bei der es sich in diesem Beispiel um ARP und copp-system-p-class-normal handelt. Datenverkehr, der mit anderen Klassen wie OSPF oder BGP in Verbindung steht, wird von CoPP nicht verworfen, da er vollständig einer anderen Klasse angehört. Wenn diese Option nicht aktiviert ist, können ARP-Probleme auf andere Probleme übertragen werden, was sich auf Protokolle auswirken kann, die von Anfang an darauf angewiesen sind. Wenn beispielsweise bei einem ARP-Cache eine Zeitüberschreitung auftritt und der Cache aufgrund übermäßiger Verletzungen nicht aktualisiert wird, kann eine TCP-Sitzung wie BGP beendet werden.

• Es wird empfohlen, Kontrollen auf Kontrollebene durchzuführen, z. B. Ethanalyzer, In-Band-Statistiken zu CPU-Mac und CPU-Prozess, um die Angelegenheit weiter zu isolieren.

Ethanalyzer

Da der durch CoPP geregelte Datenverkehr nur mit CPU-gebundenem Datenverkehr in Verbindung steht, ist das Ethanalyzer-Tool eines der wichtigsten Tools. Dieses Tool ist eine Nexus-Implementierung von TShark und ermöglicht die Erfassung und Dekodierung von Datenverkehr, der vom Supervisor gesendet und empfangen wird. Es können auch Filter verwendet werden, die auf unterschiedlichen Kriterien basieren, z. B. Protokolle oder Header-Informationen. Dies ist ein wertvolles Tool, um den von der CPU gesendeten und empfangenen Datenverkehr zu bestimmen.

Es wird empfohlen, zunächst den vom Supervisor erkannten ARP-Datenverkehr zu untersuchen, wenn das Ethanalyzer-Tool direkt in der Terminalsitzung ausgeführt oder zur Analyse an eine Datei gesendet wird. Es können Filter und Grenzwerte definiert werden, um die Erfassung auf ein bestimmtes Muster oder Verhalten zu fokussieren. Fügen Sie dazu flexible Anzeigefilter hinzu.

Ein weit verbreitetes Missverständnis ist, dass der Ethanalyzer den gesamten Datenverkehr erfasst, der über den Switch läuft. Datenverkehr auf Datenebene zwischen Hosts wird von den Hardware-ASICs zwischen Datenports geswitcht oder geroutet, erfordert keine CPU-Beteiligung und wird daher in der Regel nicht von der Erfassung durch Ethanalyzer erkannt. Zur Erfassung des Datenverkehrs auf Datenebene sollten andere Tools wie ELAM oder SPAN verwendet werden. Verwenden Sie zum Filtern von ARP beispielsweise den folgenden Befehl:

ethanalyzer local interface inband display-filter arp limit-captured-frames 0 autostop duration 60 > arpcpu

Wichtige konfigurierbare Felder:

• interface inband - bezieht sich auf den an das SUP gerichteten Datenverkehr.
• display-filter arp - bezieht sich auf den angewendeten tshark-Filter, die meisten Wireshark-Filter werden akzeptiert
• limit-captured-frames 0 - bezieht sich auf das Limit, 0 bedeutet "unbegrenzt", bis es durch einen anderen Parameter angehalten oder manuell durch Strg+C angehalten wird
• autostop duration 60 - bezieht sich auf den Ethanalyzer-Stopp nach 60 Sekunden, wodurch ein Snapshot von 60 Sekunden ARP-Datenverkehr auf der CPU erstellt wird

Die Ausgabe des Ethanalyzer wird mit > arpcpu auf eine Datei im Bootflash umgeleitet, die manuell verarbeitet werden muss. Nach 60 Sekunden ist die Erfassung abgeschlossen, und der Ethanalyzer wird dynamisch beendet, und die Datei arpcpu befindet sich auf dem Bootflash des Switches, der dann verarbeitet werden kann, um die Top Talkers zu extrahieren. Beispiele:

show file bootflash:arpcpu | sort -k 3,5 | uniq -f 2 -c | sort -r -n | head lines 50

669 2022-05-10 10:29:50.901295 28:ac:9e:ad:5e:47 -> ff:ff:ff:ff:ff:ff ARP Who has 10.1.1.1? Tell 10.1.1.2
668 2022-05-10 10:29:50.901295 28:ac:9e:ad:5e:43 -> ff:ff:ff:ff:ff:ff ARP Who has 10.2.1.1? Tell 10.2.1.2
668 2022-05-10 10:29:50.901295 28:ac:9e:ad:5e:41 -> ff:ff:ff:ff:ff:ff ARP Who has 10.3.1.1? Tell 10.3.1.2

Dieser Filter wird sortiert nach: der Quell- und Zielspalte, dann den gefundenen eindeutigen Übereinstimmungen (aber ignoriert die Datumsspalte), zählt die Instanzen und fügt die Anzahl der erkannten Instanzen hinzu, und schließlich sortiert er von oben nach unten, basierend auf der Anzahl, und zeigt die ersten 50 Ergebnisse an.

In diesem Beispiel wurden innerhalb von 60 Sekunden mehr als 600 ARP-Pakete von drei Geräten empfangen, die als verdächtige Geräte identifiziert wurden. In der ersten Spalte des Filters wird die Anzahl der Instanzen für dieses Ereignis angegeben, die in der Erfassungsdatei für die angegebene Dauer angezeigt wurden.

Es ist wichtig zu verstehen, dass das Ethanalyzer-Tool auf den In-Band-Treiber einwirkt, der im Wesentlichen die Kommunikation in den ASIC darstellt. Theoretisch muss das Paket den Kernel und den Paketmanager durchlaufen, um an den zugehörigen Prozess selbst übergeben zu werden. CoPP und HWRL handeln, bevor der Datenverkehr auf dem Ethanalyzer angezeigt wird. Selbst wenn die Anzahl der Verstöße aktiv zunimmt, fließt ein Teil des Datenverkehrs immer noch durch und wird innerhalb der Polizeirate abgeglichen. Dies hilft, Einblicke in die an die CPU gesendeten Datenverkehrsflüsse zu erhalten. Dies ist ein wichtiger Unterschied, da der auf dem Ethanalyzer gezeigte Datenverkehr NICHT der Datenverkehr ist, der gegen die CIR verstoßen hat und verworfen wurde.

Der Ethanalyzer kann auch offen eingesetzt werden, ohne dass ein Anzeigefilter oder Erfassungsfilter festgelegt wurde, der den gesamten relevanten SUP-Datenverkehr erfasst. Dies kann als Isolationsmaßnahme im Rahmen der Fehlerbehebung verwendet werden.

Weitere Informationen und die Verwendung des Ethanalyzer finden Sie in der TechNote:

Ethanalyzer auf Nexus 7000 - Leitfaden zur Fehlerbehebung

Verwendung von Ethanalyzer auf der Nexus-Plattform für die Analyse des Datenverkehrs auf Steuerungs- und Datenebene

Hinweis: Nexus 7000 kann vor der Version mit 8.x-Code nur Ethanalyzer-Erfassungen über den Admin-VDC durchführen, der SUP-gebundenen Datenverkehr von allen VDCs umfasst. VDC-spezifischer Ethanalyzer ist in 8.x-Codes vorhanden.

In-Band-Statistiken CPU-MAC

Die In-Band-Statistiken für CPU-gebundenen Datenverkehr enthalten relevante Statistiken des In-Band-TX-/RX-CPU-Datenverkehrs. Diese Statistiken können mit dem Befehl: überprüft werdenshow hardware internal cpu-mac inband stats, der einen Einblick in die Statistiken zu aktuellen Datenraten und Spitzenraten bietet.

show hardware internal cpu-mac inband stats`
================ Packet Statistics ======================
Packets received: 363598837
Bytes received: 74156192058
Packets sent: 389466025
Bytes sent: 42501379591
Rx packet rate (current/peak): 35095 / 47577 pps
Peak rx rate time: 2022-05-10 12:56:18
Tx packet rate (current/peak): 949 / 2106 pps
Peak tx rate time: 2022-05-10 12:57:00

Als Best Practice wird empfohlen, eine Baseline zu erstellen und zu verfolgen, da die Ausgabe des Switches aufgrund seiner Rolle und der Infrastruktur erheblich show hardware internal cpu-mac inband stats variiert. In dieser Laborumgebung sind die üblichen Werte und historischen Höchstwerte typischerweise nicht größer als einige hundert pps, und daher ist dies abnormal. Der Befehl show hardware internal cpu-mac inband events ist auch als Verlaufsreferenz nützlich, da er Daten zur Spitzenauslastung und zum Zeitpunkt der Erkennung enthält.

Prozess-CPU

Bei den Nexus-Switches handelt es sich um Linux-basierte Systeme. Das Nexus-Betriebssystem (NXOS) nutzt die Vorteile des CPU Preemptive Scheduler, des Multitasking und des Multithreadings seiner jeweiligen Kernarchitektur, um einen fairen Zugriff auf alle Prozesse zu ermöglichen. Daher sind Spitzen nicht immer ein Anzeichen für ein Problem. Wenn jedoch anhaltende Datenverkehrsverletzungen festgestellt werden, ist es wahrscheinlich, dass der zugehörige Prozess ebenfalls stark genutzt wird und unter den CPU-Ausgaben als wichtigste Ressource angezeigt wird. Erstellen Sie mehrere Snapshots der CPU-Prozesse, um die hohe Auslastung eines bestimmten Prozesses zu überprüfen. Verwenden Sie dazu: show processes cpu sort | exclude 0.0 or show processes cpu sort | grep <process>.

Die Verifizierungen für Prozess-CPU, In-Band-Statistiken und Ethanalyzer bieten Einblicke in die Prozesse und den Datenverkehr, die derzeit vom Supervisor verarbeitet werden, und helfen, die anhaltende Instabilität auf Kontrollebenen-Datenverkehr zu isolieren, die sich in Datenebenenprobleme kaskadieren kann. Es ist wichtig zu verstehen, dass CoPP ein Schutzmechanismus ist. Sie ist reaktionär, da sie nur auf Datenverkehr einwirkt, der an die SUP gesendet wird. Es wurde entwickelt, um die Integrität der Supervisor durch die Verwerfung von Datenverkehrsraten, die die erwarteten Bereiche überschreiten, zu schützen. Nicht alle Drops weisen auf ein Problem hin oder erfordern einen Eingriff, da ihre Bedeutung von der spezifischen CoPP-Klasse und den verifizierten Auswirkungen abhängt, die auf der Infrastruktur und dem Netzwerkdesign basieren. Drops aufgrund sporadischer Burst-Ereignisse haben keine Auswirkungen, da Protokolle integrierte Mechanismen wie Keepalive und Wiederholungsversuche aufweisen, die mit vorübergehenden Ereignissen umgehen können. Konzentrieren Sie sich über die etablierten Baselines hinaus auf lang anhaltende Ereignisse oder abnormale Ereignisse. Beachten Sie, dass CoPP die umgebungsspezifischen Protokolle und Funktionen einhalten und zur Feinabstimmung fortlaufend überwacht und iteriert werden muss, je nach den Skalierbarkeitsanforderungen, die sich bei der Entwicklung stellen. Wenn Datenverlust auftritt, prüfen Sie, ob CoPP den Datenverkehr unbeabsichtigt oder als Reaktion auf eine Fehlfunktion oder einen Angriff verworfen hat. In jedem Fall ist die Situation zu analysieren und zu bewerten, ob ein Eingreifen erforderlich ist, indem die Auswirkungen und Korrekturmaßnahmen auf die Umwelt analysiert werden, die möglicherweise nicht in den Anwendungsbereich des Switches selbst fallen.

Zusätzliche Informationen

Aktuelle Plattformen/Codes können die Fähigkeit haben, eine SPAN-zu-CPU durchzuführen, indem sie die Spiegelung eines Ports und einen Teil des Datenverkehrs der Datenebene zur CPU übernehmen. Dieser Wert ist normalerweise stark durch die Hardware-Ratenbeschränkung und CoPP begrenzt. Eine sorgfältige Verwendung des SPAN zur CPU wird empfohlen und ist nicht Gegenstand dieses Dokuments.

Weitere Informationen zu dieser Funktion finden Sie in den technischen Hinweisen:

Nexus 9000 Cloud Scale ASIC NX-OS SPAN-to-CPU-Verfahren