Dans le cadre de la documentation associée à ce produit, nous nous efforçons d’utiliser un langage exempt de préjugés. Dans cet ensemble de documents, le langage exempt de discrimination renvoie à une langue qui exclut la discrimination en fonction de l’âge, des handicaps, du genre, de l’appartenance raciale de l’identité ethnique, de l’orientation sexuelle, de la situation socio-économique et de l’intersectionnalité. Des exceptions peuvent s’appliquer dans les documents si le langage est codé en dur dans les interfaces utilisateurs du produit logiciel, si le langage utilisé est basé sur la documentation RFP ou si le langage utilisé provient d’un produit tiers référencé. Découvrez comment Cisco utilise le langage inclusif.
Cisco a traduit ce document en traduction automatisée vérifiée par une personne dans le cadre d’un service mondial permettant à nos utilisateurs d’obtenir le contenu d’assistance dans leur propre langue. Il convient cependant de noter que même la meilleure traduction automatisée ne sera pas aussi précise que celle fournie par un traducteur professionnel.
Ce document décrit en détail la réglementation du plan de contrôle (CoPP) sur les commutateurs Cisco Nexus et son impact pertinent sur les violations de classe non par défaut.
Cisco vous recommande de comprendre les informations de base relatives à la fonction de contrôle du plan de contrôle (CoPP), à ses directives et à ses limites, à sa configuration générale et à sa fonctionnalité de contrôle de la qualité de service (QoS). Pour plus d'informations sur cette fonctionnalité, reportez-vous aux documents applicables :
Aucune exigence spécifique n'est associée à ce document.
Ce document n'est pas limité à la configuration logicielle et matérielle requise.
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.
Le trafic du plan de contrôle est redirigé vers le module de supervision par des listes de contrôle d'accès (ACL) de redirection programmées pour diriger le trafic correspondant qui passe par deux couches de protection, les limiteurs de débit matériels et CoPP. Toute interruption ou attaque du module de supervision, si elle n'est pas contrôlée, peut entraîner de graves pannes de réseau ; La CoPP est donc là pour servir de mécanisme de protection. En cas d'instabilité au niveau du plan de contrôle, il est important de vérifier CoPP, car des modèles de trafic anormaux créés à partir de boucles ou d'inondations, ou des périphériques non autorisés peuvent taxer et empêcher le superviseur de traiter le trafic légitime. De telles attaques, qui peuvent être perpétrées par inadvertance par des périphériques non autorisés ou de manière malveillante par des pirates, impliquent généralement des taux élevés de trafic destiné au module de supervision ou au processeur.
La fonction Control Plan Policing (CoPP) classe et gère tous les paquets reçus sur les ports intrabande (façade) destinés à l’adresse du routeur ou nécessitant l’intervention d’un superviseur. Cette fonctionnalité permet d'appliquer une carte de stratégie au plan de contrôle. Cette carte de stratégie ressemble à une stratégie de qualité de service (QoS) normale et est appliquée à tout le trafic qui entre dans le commutateur à partir d'un port de non-gestion. La protection du module de supervision par la réglementation permet au commutateur d'atténuer les inondations de trafic qui vont au-delà du débit d'entrée garanti (CIR) pour chaque classe par l'abandon de paquets pour empêcher le commutateur d'être submergé et donc un impact sur les performances.
Il est important de surveiller les compteurs CoPP en permanence et de les justifier, ce qui est l'objectif de ce document. Les violations CoPP, si elles ne sont pas cochées, peuvent empêcher le plan de contrôle du processus de trafic réel sur la classe affectée associée. La configuration CoPP est un processus fluide et continu qui doit répondre aux exigences du réseau et de l'infrastructure. Il existe trois stratégies système par défaut pour CoPP. Par défaut, Cisco recommande l'utilisation de la stratégie par défaut en tant que point de départ initial, strict
qui sert de base à ce document.
La CoPP s'applique uniquement au trafic intrabande reçu via les ports du panneau avant. Le port de gestion hors bande (mgmt0) n'est pas soumis au protocole CoPP. Le matériel du périphérique Cisco NX-OS exécute la CoPP par moteur de transfert. Par conséquent, choisissez des débits afin que le trafic agrégé ne submerge pas le module de supervision. Ceci est particulièrement important pour les commutateurs modulaires/de fin de ligne, car le CIR s'applique au trafic agrégé de tous les modules et au trafic lié au CPU.
Le composant traité dans ce document s'applique à tous les commutateurs de data center Cisco Nexus.
L'objectif de ce document est de traiter les violations de classe non par défaut les plus courantes et critiques observées sur les commutateurs Nexus.
Pour comprendre comment interpréter le protocole CoPP, la première vérification doit consister à s'assurer qu'un profil est appliqué et à déterminer si un profil par défaut ou personnalisé est appliqué sur le commutateur.
Remarque : Comme pratique recommandée, tous les commutateurs Nexus doivent avoir CoPP activé. Si cette fonctionnalité n'est pas activée, elle peut provoquer une instabilité pour tout le trafic du plan de contrôle, car différentes plates-formes peuvent restreindre le trafic lié au superviseur (SUP). Par exemple, si CoPP n'est pas activé sur un Nexus 9000, le trafic destiné au SUP est limité à 50 pps, ce qui rend le commutateur pratiquement inutilisable. Le protocole CoPP est considéré comme obligatoire sur les plates-formes Nexus 3000 et Nexus 9000.
Si le protocole CoPP n'est pas activé, il peut être réactivé ou configuré sur le commutateur à l'aide de la setup
commande ou par l'application de l'une des stratégies par défaut standard sous l'option de configuration : copp profile [dense|lenient|moderate|strict]
.
Un périphérique non protégé ne classifie pas et ne sépare pas correctement le trafic en classes. Par conséquent, tout comportement de déni de service pour une fonctionnalité ou un protocole spécifique n'est pas limité à cette portée et peut affecter l'ensemble du plan de contrôle.
Remarque : Les politiques CoPP sont mises en oeuvre par des redirections de classification TCAM (Ternary Content-Addressable Memory) et peuvent être vues directement sous show system internal access-list input statistics module X | b CoPP
ou show hardware access-list input entries detail
.
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
Le protocole CoPP classe le trafic en fonction des correspondances qui correspondent aux listes de contrôle d’accès IP ou MAC. Par conséquent, il est important de comprendre quel trafic est classé dans quelle classe.
Les classes, qui dépendent de la plate-forme, peuvent varier. Il est donc important de comprendre comment vérifier les classes.
Par exemple, sur Nexus 9000 haut de 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
...
Dans cet exemple, la carte-classe copp-system-p-class-critical
englobe le trafic lié aux protocoles de routage, tels que le protocole BGP (Border Gateway Protocol), OSPF (Open Shortest Path First), EIGRP (Enhanced Interior Gateway Router Protocol), et inclut d'autres protocoles, tels que vPC.
La convention de nom des listes de contrôle d’accès IP ou MAC est généralement explicite pour le protocole ou la fonctionnalité concernés, avec le préfixe copp-system-p-acl-[protocol|feature]
.
Pour afficher une classe spécifique, vous pouvez la spécifier directement lors de l'exécution de la commande show. Exemple :
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
Alors que les profils CoPP par défaut sont normalement masqués dans le cadre de la configuration par défaut, vous pouvez voir la configuration avec 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)
...
La carte-classe copp-system-p-class-critical
ci-dessus fait référence à plusieurs instructions de correspondance qui appellent des listes de contrôle d'accès système, qui par défaut sont masquées, et fait référence à la classification sur laquelle la correspondance est établie. Par exemple, pour 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)
Cela signifie que tout trafic BGP correspond à cette classe et est classé sous copp-system-p-class-critical
, ainsi que tous les autres protocoles sur cette même classe.
Le Nexus 7000 utilise une structure de fonctionnalités CoPP très similaire au Nexus 9000 :
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
Il est important de noter que sur un Nexus 7000, comme il s'agit de commutateurs modulaires, vous voyez la classe divisée par module ; toutefois, le CIR s'applique à l'ensemble de tous les modules et la CoPP s'applique à l'ensemble du châssis. La vérification CoPP et les résultats ne peuvent être vus que depuis le contexte de périphérique virtuel (VDC) par défaut ou d'administration.
Il est particulièrement important de vérifier CoPP sur un Nexus 7000 si des problèmes de plan de contrôle sont observés, car l'instabilité sur un VDC avec un trafic excessif lié au CPU qui provoque des violations CoPP peut affecter la stabilité d'autres VDC.
Sur un Nexus 5600, les classes varient. Ainsi, pour BGP, il s'agit de sa propre classe séparée :
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)
Sur un Nexus 3100, il y a 3 classes de protocole de routage, donc pour vérifier à quelle classe BGP appartient, recoupez la liste de contrôle d'accès CoPP 4 qui est référencée :
EIGRP est géré par sa propre classe sur le Nexus 3100.
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
Dans ce cas, BGP est mis en correspondance par la liste de contrôle d'accès copp-system-acl-routingproto1
, et donc la classe CoPP BGP tombe dans sa copp-s-routingProto1
.
CoPP prend en charge les statistiques QoS pour suivre les compteurs agrégés de trafic qui confirment ou enfreignent le débit garanti (CIR) pour une classe particulière, pour chaque module.
Chaque class-map classe le trafic lié au CPU, en fonction de la classe à laquelle il correspond et joint un CIR pour tous les paquets qui relèvent de cette classification. Par exemple, la classe qui se rapporte au trafic BGP est utilisée comme référence :
Sur un commutateur Nexus 9000 haut de rack (TOR) pour 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
Dans la section de la carte-classe, après les instructions match, vous voyez les actions qui se rapportent à tout le trafic dans la classe. Tout le trafic classé dans copp-system-p-class-critical
est défini avec une classe de service (CoS) de 7, qui est le trafic de priorité la plus élevée, et cette classe est régulée avec un débit de données garanti de 36000 kbits/s et un débit garanti en rafale de 1280000 octets.
Le trafic conforme à cette stratégie est transféré au SUP pour être traité et toutes les violations sont abandonnées.
set cos 7
police cir 36000 kbps , bc 1280000 bytes
La section suivante contient les statistiques relatives au module, pour les commutateurs haut de rack (TOR), avec un seul module, le module 1 fait référence au commutateur.
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
Les statistiques affichées sur le résultat sont historiques, ce qui fournit un instantané des statistiques actuelles au moment de l'exécution de la commande.
Il y a deux sections à interpréter ici : les sections transmises et abandonnées :
Le point de données transmis assure le suivi de tous les paquets transmis qui sont conformes à la stratégie. Cette section est importante car elle fournit des informations sur le type de trafic traité par le superviseur.
La valeur du tarif offert de 5 minutes donne un aperçu du tarif actuel.
La fréquence et la date de pic conformes fournissent un instantané de la fréquence de pic la plus élevée par seconde qui est toujours conforme à la stratégie et de l'heure à laquelle elle s'est produite.
Si un nouveau pic est détecté, il remplace cette valeur et cette date.
La partie la plus importante des statistiques est le point de données abandonné. Tout comme les statistiques transmises, la section abandonnée suit le nombre cumulé d'octets abandonnés en raison de violations du taux de police. Elle indique également le taux de violations des 5 dernières minutes, le pic violé et, s'il y a un pic, l'horodatage de ce pic de violation. Et encore une fois, si un nouveau pic est vu, alors il remplace cette valeur et cette date. Sur d'autres plates-formes, les sorties varient, mais la logique est très similaire.
Nexus 7000 utilise une structure identique et la vérification est la même, bien que certaines classes varient légèrement sur les ACL référencées :
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
Sur un 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;
Bien qu'il ne fournisse pas d'informations sur le débit ou les pics, il fournit toujours les octets agrégés conformes et violés.
Sur un Nexus 3100, la sortie du plan de contrôle affiche OutPackets et DropPackets.
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 fait référence aux paquets conformes, tandis que DropPackets fait référence aux violations du CIR. Dans ce scénario, vous ne voyez aucune suppression sur la classe associée.
Sur un Nexus 3500, la sortie affiche les paquets matériels et logiciels correspondants :
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
Les paquets matériels mis en correspondance font référence aux paquets qui sont mis en correspondance dans le matériel par la liste de contrôle d’accès. Les paquets correspondant au logiciel sont ceux qui sont conformes à la politique. Toute différence entre les paquets correspondants matériels et logiciels implique une violation.
Dans ce cas, il n'y a pas d'abandon vu sur les paquets de classe du protocole de routage 1 (qui inclut le protocole BGP), car les valeurs correspondent.
Étant donné que les statistiques de réglementation du plan de contrôle sont historiques, il est important de déterminer si les violations actives sont en augmentation. La méthode standard pour effectuer cette tâche consiste à comparer deux sorties complètes et à vérifier les différences éventuelles.
Cette tâche peut être effectuée manuellement ou les commutateurs Nexus fournissent l'outil diff qui peut vous aider à comparer les résultats.
Bien que l'ensemble du résultat puisse être comparé, il n'est pas nécessaire car l'accent est uniquement mis sur les statistiques abandonnées. Ainsi, la sortie CoPP peut être filtrée pour se concentrer uniquement sur les violations.
La commande est la suivante : show policy-map interface control-plane | egrep class|module|violated|dropped | diff -y
Remarque : La commande doit être exécutée deux fois pour que le diff puisse comparer le résultat actuel au résultat précédent.
La commande précédente vous permet d'afficher le delta entre deux classes et de rechercher les augmentations de violation.
Remarque : Comme les statistiques CoPP sont historiques, une autre recommandation est d'effacer les statistiques après l'exécution de la commande, pour vérifier s'il y a des augmentations actives. Pour effacer les statistiques CoPP, exécutez la commande suivante : clear copp statistics
.
CoPP est une structure de réglementation simple, car tout trafic lié au CPU qui viole le CIR est abandonné. Les implications varient néanmoins considérablement en fonction du type de gouttes.
Bien que la logique soit la même, il n'est pas la même chose d'abandonner le trafic destiné à 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
Comparé à abandonner le trafic destiné à class-map 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
Le premier traite principalement des protocoles de routage, le second du protocole ICMP (Internet Control Message Protocol) qui a l'une des priorités les plus faibles et du CIR. La différence sur le débit de données garanti est de cent fois supérieure. Par conséquent, il est important de comprendre les classes, les impacts, les contrôles/vérifications communs et les recommandations.
Surveillance de classe - copp-system-p-class-monitoring
Cette classe englobe ICMP pour IPv4 et IPv6, et traceroute du trafic dirigé vers le commutateur en question.
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
Incidence
Une erreur courante lors du dépannage de la perte ou de la latence de paquets consiste à envoyer une requête ping au commutateur via ses ports intrabande, dont le débit est limité par le protocole CoPP. Étant donné que le protocole CoPP gère fortement le protocole ICMP, même en cas de trafic faible ou d’encombrement, la perte de paquets peut être observée par une requête ping envoyée directement aux interfaces intrabande si elles enfreignent le CIR.
Par exemple, en envoyant une requête ping aux interfaces directement connectées sur les ports routés, avec une charge utile de 500 paquets, des abandons peuvent être observés périodiquement.
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
Sur le Nexus, où les paquets ICMP étaient destinés, vous voyez que CoPP les a abandonnés car la violation a été détectée et le CPU a été protégé :
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
Pour résoudre les problèmes de latence ou de perte de paquets, il est recommandé d'utiliser les hôtes accessibles via le commutateur par le plan de données, qui n'est pas destiné au commutateur lui-même, qui serait le trafic du plan de contrôle. Le trafic du plan de données est transféré/routé au niveau matériel sans intervention du SUP et n'est donc pas réglementé par le CoPP, et ne subit généralement aucune perte.
Recommandations
Gestion des classes - copp-system-p-class-management
Comme on le voit ici, cette classe englobe différents protocoles de gestion qui peuvent être utilisés pour la communication (SSH, Telnet), les transferts (SCP, FTP, HTTP, SFTP, TFTP), l'horloge (NTP), AAA (Radius/TACACS) et la surveillance (SNMP), pour les communications IPv4 et IPv6.
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
Incidence
Les comportements ou abandons les plus courants associés à cette classe sont les suivants :
Recommandations
Données de monodiffusion de classe L3 - copp-system-p-class-l3uc-data
Cette classe traite spécifiquement des paquets glanés. Ce type de paquet est également géré par le HWRL (Hardware Rate Limiter).
Si la requête ARP (Address Resolution Protocol) pour le tronçon suivant n'est pas résolue lorsque les paquets IP entrants sont transférés dans une carte de ligne, la carte de ligne transfère les paquets au module de supervision.
Le superviseur résout l'adresse MAC pour le saut suivant et programme le matériel.
class-map copp-system-p-class-l3uc-data (match-any)
match exception glean
set cos 1
Cela se produit normalement lorsque des routes statiques sont utilisées et que le tronçon suivant est inaccessible ou non résolu.
Lorsqu'une requête ARP est envoyée, le logiciel ajoute une contiguïté d'abandon /32 dans le matériel pour empêcher les paquets à la même adresse IP de tronçon suivant d'être transférés au superviseur. Une fois le protocole ARP résolu, l'entrée matérielle est mise à jour avec l'adresse MAC correcte. Si l'entrée ARP n'est pas résolue avant un délai d'attente, elle est supprimée du matériel.
Remarque : CoPP et HWRL fonctionnent en tandem pour garantir la protection du processeur. Alors qu'ils semblent exécuter des fonctions similaires, HWRL se produit en premier. La mise en oeuvre est basée sur l'emplacement où la fonctionnalité spécifique est mise en oeuvre sur les moteurs de transfert sur l'ASIC. Cette approche série permet une granularité et des protections multicouches qui évaluent tous les paquets liés au processeur.
Le HWRL est effectué par instance/moteur de transfert sur le module et peut être visualisé avec la commande show hardware rate-limiter
. HWRL n'est pas couvert par ce document technique.
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
Incidence
Recommandations
hardware ip glean throttle.
Sur Nexus 7000 8.4(2), il a également introduit la prise en charge du filtre bloom pour les contiguïtés de glane pour les modules M3 et F4. Reportez-vous à : Guide de configuration du routage monodiffusion NX-OS de la gamme Cisco Nexus 7000
Passez en revue les configurations de routes statiques qui utilisent des adresses de tronçon suivant inaccessibles ou qui utilisent des protocoles de routage dynamique qui supprimeraient dynamiquement ces routes du RIB.
Classe critique - class-map copp-system-p-class-critical
Cette classe fait référence aux protocoles de plan de contrôle les plus critiques d'un point de vue L3, qui incluent les protocoles de routage pour IPv4 et IPv6 (RIP, OSPF, EIGRP, BGP), auto-RP, virtual port-channel (vPC) et l2pt et 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
Incidence
Abandon copp-system-p-class-critical
de l'instabilité de transfert vers les protocoles de routage, ce qui peut inclure des contiguïtés abandonnées ou des échecs de convergence, ou une propagation de mise à jour/NLRI.
Les abandons de stratégie les plus courants sur cette classe peuvent concerner des périphériques indésirables sur le réseau qui agissent anormalement (en raison d'une mauvaise configuration ou d'une défaillance) ou d'une évolutivité.
Recommandations
Classe importante - copp-system-p-class-important
Cette classe concerne les protocoles de redondance au premier saut (FHRP), qui incluent HSRP, VRRP et LLDP
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
Incidence
Les comportements les plus courants qui entraînent des pertes sont les problèmes d'instabilité de couche 2, qui entraînent la transition des périphériques vers des scénarios d'état actif (split brain), des minuteurs agressifs, des erreurs de configuration ou l'évolutivité.
Recommandations:
Class L2 Unpoliced - copp-system-p-class-l2-unpoliced
La classe non réglementée de couche 2 fait référence à tous les protocoles critiques de couche 2 qui constituent la base de tous les protocoles de couche supérieure et sont donc considérés comme presque non réglementés avec le CIR et la priorité les plus élevés.
Cette classe gère efficacement les protocoles STP (Spanning Tree Protocol), LACP (Link Aggregation Control Protocol) et CFSoE (Cisco Fabric Service over Ethernet)
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
Cette classe a un débit de données garanti de 50 Mbits/s, le plus élevé de toutes les classes, ainsi que le taux d'absorption de rafales le plus élevé.
Incidence
Les abandons de cette classe peuvent entraîner une instabilité globale, car tous les protocoles de couche supérieure et toutes les communications sur les plans de données, de contrôle et de gestion reposent sur une stabilité de couche 2 sous-jacente.
Les problèmes de violations STP peuvent entraîner des problèmes de TCN et de convergence STP, notamment des conflits STP, des vidages MAC, des déplacements et des comportements d'apprentissage désactivés, ce qui entraîne des problèmes d'accessibilité et peut provoquer des boucles de trafic qui déstabilisent le réseau.
Cette classe fait également référence à LACP, et gère donc tous les paquets EtherType associés à 0x8809, qui incluent tous les LACPDU utilisés pour maintenir l'état des liaisons port-channel. L'instabilité sur cette classe peut provoquer le dépassement du délai d'attente des ports-channels si les LACPDU sont abandonnées.
Cisco Fabric Service over Ethernet (CSFoE) appartient à cette classe et est utilisé pour communiquer les états de contrôle des applications critiques entre les commutateurs Nexus. Il est donc essentiel pour la stabilité.
Il en va de même pour les autres protocoles de cette classe, qui inclut CDP, UDLD et VTP.
Recommandations
Routeur multidiffusion de classe - class-map copp-system-p-class-multicast-router
Cette classe fait référence aux paquets PIM (Protocol Independent Multicast) du plan de contrôle utilisés pour l'établissement et le contrôle d'arborescences partagées de multidiffusion routées via tous les périphériques compatibles PIM dans le chemin du plan de données. Elle inclut les routeurs FHR (First-Hop Router), LHR (Last-Hop Router), IHR (Intermediate-Hop Routers) et RP (Rendezvous Points). Les paquets classés dans cette classe incluent l'enregistrement PIM pour les sources, les jonctions PIM pour les récepteurs pour IPv4 et IPv6, en général tout trafic destiné à PIM (224.0.0.13) et le protocole MSDP (Multicast Source Discovery Protocol). Sachez qu'il existe plusieurs classes supplémentaires, qui traitent de parties très spécifiques de la fonctionnalité multicast ou RP qui sont traitées par différentes classes.
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
Incidence
L'impact principal sur les abandons qui se rapportent à cette classe sont associés à des problèmes qui communiquent aux sources de multidiffusion par l'enregistrement PIM vers les RP ou les jonctions PIM non correctement traitées, ce qui déstabiliserait les arbres de chemin partagé ou le plus court vers les sources du flux de multidiffusion ou vers les RP. Le comportement peut inclure une liste d'interfaces sortantes (OIL) incorrectement renseignée en raison de jointures absentes, ou (S, G), ou (*, G) incohérente dans l'environnement. Des problèmes peuvent également survenir entre les domaines de routage de multidiffusion qui dépendent du protocole MSDP pour l'interconnexion.
Recommandations
Class Multicast Host - copp-system-p-class-multicast-host
Cette classe fait référence à la détection de l'écouteur de multidiffusion (MLD), en particulier aux types de paquets MLD requête, rapport, réduction et MLDv2. MLD est un protocole IPv6 qu'un hôte utilise pour demander des données de multidiffusion pour un groupe particulier. Avec les informations obtenues par le biais de MLD, le logiciel tient à jour une liste d'appartenances de groupes ou de canaux de multidiffusion par interface. Les périphériques qui reçoivent des paquets MLD envoient les données de multidiffusion qu'ils reçoivent pour les groupes ou les canaux demandés par le segment de réseau des récepteurs connus. MLDv1 est dérivé d'IGMPv2 et MLDv2 est dérivé d'IGMPv3. IGMP utilise les types de message IP Protocol 2, tandis que MLD utilise les types de message IP Protocol 58, qui est un sous-ensemble des messages ICMPv6.
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
Incidence
Les abandons de cette classe se traduisent par des problèmes sur les communications multidiffusion IPv6 link-local, ce qui peut entraîner la suppression des rapports d'écouteur des récepteurs ou des réponses aux requêtes générales, ce qui empêche la découverte des groupes multidiffusion que les hôtes souhaitent recevoir. Cela peut avoir un impact sur le mécanisme de surveillance et ne pas transférer correctement le trafic vers les interfaces attendues qui ont demandé le trafic.
Recommandations
Données multidiffusion de couche 3 de classe - copp-system-p-class-l3mc-data
et données IPv6 multidiffusion de couche 3 de classe - copp-system-p-class-l3mcv6-data
Ces classes font référence au trafic qui correspond à une redirection d'exception de multidiffusion vers le SUP. Dans ce cas, il y a deux conditions qui sont gérées par ces classes. La première est une défaillance du protocole RPF (Reverse-Path Forwarding) et la seconde est une absence de destination. L'absence de destination fait référence à des paquets de multidiffusion où la recherche dans le matériel pour la table de transfert de multidiffusion de couche 3 échoue, et donc le paquet de données est envoyé au CPU. Ces paquets sont parfois utilisés pour déclencher/installer le plan de contrôle de multidiffusion et ajouter les entrées des tables de transfert matérielles, en fonction du trafic du plan de données. Les paquets de multidiffusion de plan de données qui violent le RPF correspondraient également à cette exception et seraient classés comme une violation.
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
Incidence
Les échecs RPF et les échecs de destination impliquent un problème de conception ou de configuration lié à la façon dont le trafic circule dans le routeur de multidiffusion. Les échecs de destination sont fréquents lors de la création d'états, les abandons peuvent conduire à la programmation et à la création de défaillances (*, G), (S, G).
Recommandations
Classe IGMP - copp-system-p-class-igmp
Cette classe fait référence à tous les messages IGMP, pour toutes les versions qui sont utilisées pour demander des données de multidiffusion pour un groupe particulier, et utilisées par la fonctionnalité de surveillance IGMP pour maintenir les groupes et la liste d'interfaces sortantes (OIL) appropriée qui transfère le trafic vers les récepteurs intéressés au niveau de la couche 2. Les messages IGMP sont significatifs localement parce qu'ils ne traversent pas une limite de couche 3, car leur durée de vie (TTL) doit être de 1, comme documenté dans RFC2236 (Internet Group Management Protocol, Version 2). Les paquets IGMP traités par cette classe incluent toutes les requêtes d'adhésion (générales ou spécifiques à la source/au groupe), ainsi que les rapports d'adhésion et de sortie des récepteurs.
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
Incidence
Les abandons sur cette classe se traduiraient par des problèmes à tous les niveaux d'une communication multidiffusion entre la source et le récepteur, selon le type de message IGMP abandonné en raison de la violation. Si les rapports d'appartenance des récepteurs sont perdus, le routeur ne connaît pas les périphériques intéressés par le trafic et n'inclut donc pas l'interface/le VLAN dans sa liste d'interfaces sortantes. Si ce périphérique est également le demandeur ou le routeur désigné, il ne déclenche pas les messages de jointure PIM pertinents vers le RP si la source se trouve au-delà du domaine local de couche 2, de sorte qu'il n'établit jamais le plan de données à travers l'arbre de multidiffusion jusqu'au récepteur ou au RP. Si le rapport de congé est perdu, le destinataire peut continuer à recevoir du trafic indésirable. Cela peut également affecter toutes les requêtes IGMP pertinentes déclenchées par le demandeur et la communication entre les routeurs de multidiffusion dans un domaine.
Recommandations
Classe Normal - copp-system-p-class-normalcopp-system-p-class-normal
Cette classe fait référence au trafic qui correspond au trafic ARP standard, et inclut également le trafic associé à 802.1X, utilisé pour le contrôle d'accès réseau basé sur les ports. Il s'agit de l'une des classes les plus courantes qui rencontre des violations lorsque des requêtes ARP, des paquets ARP gratuits ou des paquets ARP inverses sont diffusés et se propagent dans l'ensemble du domaine de couche 2. Il est important de se rappeler que les paquets ARP ne sont pas des paquets IP, qu'ils ne contiennent pas d'en-tête L3 et que la décision est donc prise uniquement sur la portée des en-têtes L2. Si un routeur est configuré avec une interface IP associée à ce sous-réseau, telle qu'une interface virtuelle de commutateur (SVI), le routeur envoie les paquets ARP au SUP à traiter, car ils sont destinés à l'adresse de diffusion matérielle. Toute tempête de diffusion, boucle de couche 2 (en raison du protocole STP ou des volets) ou tout périphérique non autorisé sur le réseau peut entraîner une tempête ARP qui entraîne une augmentation significative des violations.
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
Incidence
L'impact des violations dans cette classe dépend fortement de la durée des événements et du rôle du commutateur sur l'environnement. Les abandons dans cette classe impliquent que les paquets ARP sont actuellement rejetés et donc non traités par le moteur SUP, ce qui peut conduire à deux comportements principaux provoqués par des résolutions ARP incomplètes.
Du point de vue de l’hôte final, les périphériques du réseau ne sont pas en mesure de résoudre ou de terminer la résolution d’adresse avec le commutateur. Si ce périphérique agit comme passerelle par défaut pour le segment, il peut empêcher les périphériques de résoudre leur passerelle et donc de router en dehors de leur segment Ethernet de couche 2 (VLAN). Les périphériques peuvent toujours communiquer sur le segment local s'ils peuvent effectuer la résolution ARP pour d'autres hôtes finaux sur le segment local.
Du point de vue du commutateur, si l'orage et les violations sont répandus, cela peut également empêcher le commutateur de terminer le processus de requête ARP qu'il a généré. Ces requêtes sont normalement générées pour les résolutions de sous-réseau de tronçon suivant ou connecté directement. Bien que les réponses ARP soient de type monodiffusion, puisqu'elles sont adressées à l'adresse MAC appartenant au commutateur, elles sont classées dans cette même classe, car elles sont toujours des paquets ARP. Cela se traduit par des problèmes d'accessibilité, car le commutateur ne peut pas traiter correctement le trafic si le saut suivant n'est pas résolu, et peut entraîner des problèmes de réécriture d'en-tête de couche 2, si le gestionnaire de contiguïté n'a pas d'entrée pour l'hôte.
L'impact dépend également de l'étendue du problème fondamental qui a déclenché la violation ARP. Par exemple, dans une tempête de diffusion, les hôtes et le commutateur continuent à utiliser le protocole ARP pour tenter de résoudre la contiguïté, ce qui peut entraîner un trafic de diffusion supplémentaire sur le réseau, et comme les paquets ARP sont de couche 2, il n'y a pas de durée de vie de couche 3 (TTL) pour rompre une boucle de couche 2 et donc ils continuent à boucler et à croître de façon exponentielle à travers le réseau jusqu'à ce que la boucle soit rompue.
Recommandations
Class NDP - copp-system-p-acl-ndp
Cette classe fait référence au trafic associé à la découverte/annonce de voisinage IPv6 et aux paquets de sollicitation et d'annonce de routeur qui utilisent des messages ICMP pour déterminer les adresses de couche liaison locales des voisins. Elle est également utilisée pour l'accessibilité et le suivi des périphériques voisins.
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
Incidence
Les violations sur cette classe peuvent entraver la communication IPv6 entre les périphériques voisins, car ces paquets sont utilisés pour faciliter la découverte dynamique ou les informations de couche liaison/locales entre les hôtes et les routeurs sur la liaison locale. Une interruption de cette communication peut également entraîner des problèmes d'accessibilité au-delà ou via la liaison locale associée. Si des problèmes de communication surviennent entre des voisins IPv6, assurez-vous qu'il n'y a pas d'abandon sur cette classe.
Recommandations
Classe DHCP normal - copp-system-p-class-normal-dhcp
Cette classe fait référence au trafic associé au protocole Bootstrap (client/serveur BOOTP), communément appelé paquets DHCP (Dynamic Host Control Protocol) sur le même segment Ethernet local pour IPv4 et IPv6. Cela concerne spécifiquement uniquement la communication de trafic qui provient de tout client Bootp ou destinée à tout serveur BOOTP, via l'échange de paquets DORA (détection, offre, requête et accusé de réception) entier, et inclut également la transaction client/serveur DHCPv6 via les ports UDP 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
Incidence
Les violations de cette classe peuvent empêcher les hôtes finaux d’acquérir correctement une adresse IP auprès du serveur DHCP et de revenir ainsi à leur plage d’adresses IP privées automatiques (APIPA), 169.254.0.0/16. De telles violations peuvent se produire dans des environnements où les périphériques essaient de démarrer simultanément et dépassent ainsi le CIR associé à la classe.
Recommandations
show ip dhcp global statistics
et redirections : show system internal access-list sup-redirect-stats module 1 | grep -i dhcp
.Réponse de relais DHCP normal de classe - copp-system-p-class-normal-dhcp-relay-response
Cette classe fait référence au trafic associé à la fonctionnalité de relais DHCP pour IPv4 et IPv6, dirigé vers les serveurs DHCP configurés sous le relais. Cela concerne spécifiquement uniquement la communication de trafic qui provient de n'importe quel serveur BOOTP ou destinée à n'importe quel client BOOTP via l'échange de paquets DORA entier, et inclut également la transaction client/serveur DHCPv6 via les ports UDP 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
Incidence
Les violations de cette classe ont le même impact que celles de la classe copp-system-p-class-normal-dhcp, car elles font toutes deux partie de la même transaction. Cette classe se concentre principalement sur les communications de réponse des serveurs d'agent de relais. Le Nexus n'agit pas en tant que serveur DHCP, il est conçu uniquement pour agir en tant qu'agent de relais.
Recommandations
show ip dhcp relay
et.show ip dhcp relay statistics
Flux NAT de classe - copp-system-p-class-nat-flow
Cette classe fait référence au trafic de flux NAT du commutateur logiciel. Lorsqu'une nouvelle traduction dynamique est créée, le flux est transféré par logiciel jusqu'à ce que la traduction soit programmée dans le matériel, puis il est réglementé par le CoPP pour limiter le trafic envoyé au superviseur pendant que l'entrée est installée dans le matériel.
class-map copp-system-p-class-nat-flow (match-any)
match exception nat-flow
set cos 7
police cir 800 kbps , bc 64000 bytes
Incidence
Les abandons de cette classe se produisent généralement lorsqu'un taux élevé de nouvelles traductions et de nouveaux flux dynamiques sont installés dans le matériel. L’impact concerne les paquets commutés par logiciel qui sont rejetés et non remis à l’hôte final, ce qui peut entraîner des pertes et des retransmissions. Une fois l'entrée installée dans le matériel, aucun autre trafic n'est envoyé au superviseur.
Recommandations
Exception de classe - copp-system-p-class-exception
Cette classe fait référence aux paquets d'exception associés à l'option IP et aux paquets IP ICMP inaccessibles. Si une adresse de destination n’est pas présente sur la base d’informations de transfert (FIB) et entraîne un échec, le SUP renvoie un paquet ICMP inaccessible à l’expéditeur. Les paquets dont les options IP sont activées font également partie de cette classe. Pour plus d'informations sur les options IP, reportez-vous au document IANA : Numéros d'option IP
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
Incidence
Cette classe est fortement réglementée, et les abandons sur cette classe ne sont pas indicatifs d'une défaillance, mais plutôt d'un mécanisme de protection pour limiter la portée des paquets d'options IP et d'ICMP inaccessibles.
Recommandations
Redirection de classe - copp-system-p-class-redirect
Cette classe fait référence au trafic associé au protocole PTP (Precision Time Protocol), utilisé pour la synchronisation temporelle. Cela inclut le trafic de multidiffusion pour la plage réservée 224.0.1.129/32, le trafic de monodiffusion sur le port UDP 319/320 et l'Ethetype 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
Incidence
Les abandons de cette classe peuvent entraîner des problèmes sur les périphériques qui ne sont pas correctement synchronisés ou qui n'ont pas établi la hiérarchie appropriée.
Recommandations
Classe OpenFlow - copp-system-p-class-openflow
Cette classe fait référence au trafic associé aux opérations de l'agent OpenFlow et à la connexion TCP correspondante entre le contrôleur et l'agent.
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
Incidence
Les abandons de cette classe peuvent entraîner des problèmes sur les agents qui ne reçoivent pas et ne traitent pas correctement les instructions du contrôleur pour gérer le plan de transfert du réseau
Recommandations
Les premières étapes du dépannage des violations CoPP consistent à déterminer :
Par exemple, le comportement répertorié a été détecté :
copp-system-p-class-normal
.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;
Il est important de souligner que CoPP isole l'impact sur le trafic associé à la classe spécifique, qui dans cet exemple sont ARP et copp-system-p-class-normal. Le trafic lié à d'autres classes, telles que OSPF, BGP n'est pas abandonné par CoPP, car ils appartiennent entièrement à une classe différente. Si cette case n’est pas cochée, les problèmes ARP peuvent se répercuter sur d’autres problèmes, ce qui peut affecter les protocoles qui s’y fient au départ. Par exemple, si un cache ARP expire et n'est pas actualisé en raison de violations excessives, une session TCP telle que BGP peut se terminer.
Comme le trafic contrôlé par CoPP n'est associé qu'au trafic lié au CPU, l'un des outils les plus importants est l'Ethanalyzer. Cet outil est une implémentation Nexus de TShark et permet au trafic envoyé et reçu par le superviseur d'être capturé et décodé. Il peut également utiliser des filtres basés sur différents critères, tels que des protocoles ou des informations d'en-tête, et devient ainsi un outil précieux pour déterminer le trafic envoyé et reçu par le processeur.
Il est recommandé d'examiner d'abord le trafic ARP vu par le superviseur lorsque l'outil Ethanalyzer est exécuté directement sur la session du terminal ou envoyé à un fichier pour analyse. Des filtres et des limites peuvent être définis pour focaliser la capture sur un modèle ou un comportement spécifique. Pour ce faire, ajoutez des filtres d'affichage flexibles.
Une idée fausse courante est que l'analyseur Ethanalyzer capture tout le trafic qui traverse le commutateur. Le trafic du plan de données, entre les hôtes, est commuté ou routé par les circuits ASIC matériels entre les ports de données, ne nécessite pas l'intervention du processeur et n'est donc normalement pas vu par la capture d'analyseur de données. Pour capturer le trafic du plan de données, il est conseillé d'utiliser d'autres outils, tels qu'ELAM ou SPAN. Par exemple, pour filtrer ARP, utilisez la commande suivante :
ethanalyzer local interface inband display-filter arp limit-captured-frames 0 autostop duration 60 > arpcpu
Champs configurables importants :
interface inband
- fait référence au trafic dirigé vers le SUPdisplay-filter arp
- fait référence au filtre tshark appliqué, la plupart des filtres Wireshark sont acceptéslimit-captured-frames 0
- fait référence à la limite, 0 équivaut à illimité, jusqu'à ce qu'il soit arrêté par un autre paramètre ou arrêté manuellement par Ctrl+Cautostop duration 60
- fait référence à l'arrêt de l'Ethanalyzer après 60 secondes, ce qui crée un instantané de 60 secondes de trafic ARP vu sur le CPULa sortie d'Ethanalyzer est redirigée vers un fichier sur le bootflash avec > arpcpu, pour être traitée manuellement. Au bout de 60 secondes, la capture est terminée et l'analyseur Ethanalyzer se termine dynamiquement, et le fichier arpcpu se trouve sur le bootflash du commutateur, qui peut ensuite être traité pour extraire les principaux émetteurs. Exemple :
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
Ce filtre est trié en fonction des éléments suivants : les colonnes source et de destination, puis les correspondances uniques trouvées (mais ignore la colonne date), compte les instances et ajoute le nombre vu, et enfin trie de haut en bas, en fonction du nombre, et affiche les 50 premiers résultats.
Dans cet exemple de travaux pratiques, en 60 secondes, plus de 600 paquets ARP ont été reçus de trois périphériques, identifiés comme des périphériques suspects. La première colonne du filtre détaille le nombre d'instances de cet événement qui ont été vues sur le fichier de capture pendant la durée spécifiée.
Il est important de comprendre que l'outil Ethanalyzer agit sur le pilote intrabande, qui est essentiellement la communication dans l'ASIC. En théorie, le paquet doit passer par le noyau et le gestionnaire de paquets pour être transféré au processus associé lui-même. CoPP et HWRL agissent avant que le trafic ne soit détecté sur l'analyseur Ethanalyzer. Même si les violations sont activement en augmentation, une partie du trafic passe toujours par et est conforme au taux de police, ce qui permet de fournir un aperçu des flux de trafic acheminés vers le processeur. Il s'agit d'une distinction importante, car le trafic vu sur l'analyseur Ethnologique n'est PAS le trafic qui a violé le CIR et a été abandonné.
L'analyseur Ethanalyzer peut également être utilisé de manière ouverte, sans aucun filtre d'affichage ou de capture spécifié pour intercepter tout le trafic SUP pertinent. Cela peut être utilisé comme mesure d'isolation dans le cadre de l'approche de dépannage.
Pour plus de détails et sur l'utilisation d'Ethanalyzer, reportez-vous à la TechNote :
Guide de dépannage d'Ethanalyzer sur Nexus 7000
Remarque : Nexus 7000, antérieur à la version du code 8.X, ne peut effectuer des captures Ethanalyzer que via le VDC d'administration, qui englobe le trafic lié au SUP de tous les VDC. Ethanalyzer spécifique à VDC est présent dans les codes 8.X.
Les statistiques intrabande associées au trafic lié au CPU conservent des statistiques pertinentes du trafic intrabande du CPU TX/RX. Ces statistiques peuvent être vérifiées à l'aide de la commande : show hardware internal cpu-mac inband stats
, qui donne un aperçu des statistiques actuelles sur les taux et les pics de taux.
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
Il est recommandé de créer et de suivre une ligne de base car, en raison du rôle du commutateur et de l'infrastructure, le résultat de l' show hardware internal cpu-mac inband stats
varie considérablement. Dans cet environnement de travaux pratiques, les valeurs habituelles et les pics historiques ne dépassent généralement pas quelques centaines de pps, ce qui est anormal. La commande show hardware internal cpu-mac inband events
est également utile en tant que référence historique, car elle contient des données relatives à l'utilisation maximale et à l'heure de détection.
Les commutateurs Nexus sont des systèmes basés sur Linux, et le système d'exploitation Nexus (NXOS) tire parti du planificateur préemptif de CPU, du multitâche et du multithreading de son architecture de coeur respective, pour fournir un accès équitable à tous les processus, et ainsi les pics ne sont pas toujours indicatifs d'un problème. Cependant, si des violations continues du trafic sont observées, il est probable que le processus associé est également fortement utilisé et apparaît comme une ressource principale sous les sorties du CPU. Prenez plusieurs instantanés des processus du processeur pour vérifier l'utilisation élevée d'un processus particulier en utilisant : show processes cpu sort | exclude 0.0 or show processes cpu sort | grep
.
Les vérifications de l'UC des processus, des états intrabande et de l'Ethanalyzer fournissent des informations sur les processus et le trafic actuellement traités par le superviseur et permettent d'isoler l'instabilité continue sur le trafic du plan de contrôle qui peut se répercuter sur les problèmes du plan de données. Il est important de comprendre que la CoPP est un mécanisme de protection. Il est réactionnaire car il n'agit que sur le trafic envoyé au SUP. Il est conçu pour préserver l'intégrité du superviseur en éliminant les débits de trafic qui dépassent les plages prévues. Les abandons ne signalent pas tous un problème ou nécessitent une intervention, car leur importance est liée à la classe CoPP spécifique et à l'impact vérifié, sur la base de la conception de l'infrastructure et du réseau. Les abandons dus à des rafales sporadiques ne se traduisent pas par un impact, car les protocoles disposent de mécanismes intégrés, tels que le keepalive et les nouvelles tentatives qui peuvent traiter des événements transitoires. Maintenir l'accent sur les événements durables ou anormaux au-delà des valeurs de référence établies. Rappelez-vous que le protocole CoPP doit respecter les protocoles et les fonctionnalités spécifiques à l'environnement et doit être surveillé et continuellement itéré pour l'ajuster avec précision, en fonction des besoins d'évolutivité à mesure qu'ils évoluent. Si des abandons se produisent, déterminez si CoPP a abandonné le trafic de manière non intentionnelle ou en réponse à un dysfonctionnement ou une attaque. Dans un cas comme dans l'autre, analysez la situation et évaluez la nécessité d'intervenir en analysant l'impact et la mesure corrective sur l'environnement, ce qui peut sortir du cadre du commutateur lui-même.
Les plates-formes/codes récents peuvent avoir la capacité d'effectuer une SPAN vers CPU, par le miroir d'un port et le point du trafic du plan de données vers le CPU. Ce débit est normalement fortement limité par la limite de débit du matériel et la CoPP. L'utilisation prudente de la fonctionnalité SPAN vers CPU est conseillée et n'entre pas dans le cadre de ce document.
Reportez-vous à la note technique répertoriée pour plus d'informations sur cette fonctionnalité :
Révision | Date de publication | Commentaires |
---|---|---|
2.0 |
26-Mar-2024 |
Texte de remplacement ajouté.
Mise à jour SEO, traduction automatique, exigences de style et formatage. |
1.0 |
01-Jul-2022 |
Première publication |