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 comment dépanner la cause des lectures CPU élevées lorsque le scanner BGP ou le routeur sont utilisés.
Ce document nécessite une connaissance de la façon d'interpréter la commande show process cpu.
Les informations de ce document sont basées sur la version 12.0 du logiciel Cisco IOS®.
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.
Pour plus d'informations sur les conventions utilisées dans ce document, reportez-vous à Conventions relatives aux conseils techniques Cisco.
Ce document décrit les situations dans lesquelles un routeur Cisco IOS peut bénéficier d'une utilisation élevée du CPU en raison du processus du routeur BGP (Border Gateway Protocol) ou du processus de scanner BGP, comme indiqué dans le résultat de la commande show process cpu. La durée de cet état d’utilisation élevée du CPU varie en fonction d’un certain nombre de conditions, en particulier la taille de la table de routage Internet et le nombre de routes qu’un routeur particulier gère dans ses tables de routage et BGP. La commande show process cpu montre l'utilisation moyenne du processeur au cours des cinq dernières secondes, une minute et cinq minutes. Les numéros d'utilisation du processeur ne fournissent pas une indication linéaire réelle de l'utilisation par rapport à la charge offerte.
Voici quelques-unes des principales raisons :
Dans un réseau réel, le processeur doit gérer diverses fonctions de maintenance du système, telles que la gestion du réseau.
Le processeur doit traiter des mises à jour de routage périodiques et déclenchées par des événements.
Il existe d'autres opérations de surcharge du système interne, telles que l'interrogation de la disponibilité des ressources, qui ne sont pas proportionnelles à la charge de trafic.
Vous pouvez également utiliser la commande show processes cpu afin d'obtenir une indication de l'activité du processeur.
Note: Pour plus d'informations sur les commandes show, reportez-vous à la référence des commandes de configuration de base de Cisco IOS
Un processus Cisco IOS, en général, se compose des threads individuels et des données associées qui effectuent des tâches, telles que la maintenance du système, les paquets de commutation et la mise en oeuvre des protocoles de routage. Plusieurs processus Cisco IOS exécutés sur le routeur permettent l'exécution de BGP. Utiliser la commande show process | include BGP pour voir la quantité d'utilisation du CPU due aux processus BGP.
Ce tableau répertorie la fonction des processus BGP et montre que chaque processus s'exécute à des moments différents, et que ces moments dépendent des tâches qui sont traitées. Étant donné que l'analyseur BGP et les processus du routeur BGP sont responsables d'une grande quantité de calculs, vous pouvez voir une CPU élevée due à l'un de ces processus. Les sections suivantes abordent ces processus plus en détail.
Nom du processus |
Description |
Intervalle |
Ouverture BGP |
Effectue l'établissement des homologues BGP. |
Lors de l'initialisation, lorsqu'une connexion TCP avec un homologue BGP est établie. |
BGP I/O |
Gère les paquets BGP qui sont dans la file d'attente et qui sont traités, tels que les mises à jour et les KEEPALIVES. |
À mesure que des paquets de contrôle BGP sont reçus. |
BGP Scanner |
Parcourt la table BGP et confirme l'accessibilité des sauts suivants. L'analyseur BGP vérifie également la publication conditionnelle pour déterminer si BGP annonce les préfixes de condition et effectue la réduction de route. Dans un environnement VPN MPLS, l'analyseur BGP importe et exporte des routes dans une instance de routage et de transfert VPN particulière (VRF). |
Une minute. |
Routeur BGP |
Calcule le meilleur chemin BGP et traite toute désactivation de route. Il envoie et reçoit également des routes, établit des homologues et interagit avec la base d’informations de routage (RIB). |
Une fois par seconde et lorsqu'un homologue BGP est ajouté, supprimé ou configuré de manière logicielle. |
Une CPU élevée due au processus du scanner BGP peut être attendue pendant de courtes durées sur un routeur qui transporte une grande table de routage Internet. Une fois par minute, le scanner BGP parcourt la table RIB BGP et effectue des tâches de maintenance importantes. Ces tâches incluent l'examen du saut suivant référencé dans la table BGP du routeur et vérifient que les périphériques du saut suivant peuvent être atteints. Ainsi, une grande table BGP prend un temps équivalent pour être marchée et validée.
Comme le processus du scanner BGP s'exécute sur l'ensemble de la table BGP, la durée de la condition CPU élevée varie en fonction du nombre de voisins et du nombre de routes apprises par voisin. Utilisez les commandes show ip bgp summary et show ip route summary pour capturer ces informations. Le processus du scanner BGP parcourt la table BGP pour mettre à jour toutes les structures de données et parcourt la table de routage à des fins de redistribution de route. (Dans ce contexte, la table de routage est également appelée base d’informations de routage (RIB), que le routeur génère lorsque vous exécutez la commande show ip route). Les deux tables sont stockées séparément dans la mémoire du routeur et peuvent être volumineuses et consommer des cycles CPU.
L'exemple suivant de la commande de debug ip bgp update capture une exécution de l'analyseur BGP :
router# 2d17h: BGP: scanning routing tables 2d17h: BGP: 10.0.0.0 computing updates, neighbor version 8, table version 9, starting at 0.0.0.0 2d17h: BGP: 10.0.0.0 update run completed, ran for 0ms, neighbor version 8, start version 9, throttled to 9, check point net 0.0.0.0 2d17h: BGP: 10.1.0.0 computing updates, neighbor version 8, table version 9, starting at 0.0.0.0 2d17h: BGP: 10.1.0.0 update run completed, ran for 4ms, neighbor version 8, start version 9, throttled to 9, check point net 0.0.0.0 router#
Pendant l'exécution du scanner BGP, les processus de faible priorité doivent attendre plus longtemps pour accéder au processeur. Un processus de faible priorité contrôle les paquets ICMP (Internet Control Message Protocol) tels que les requêtes ping. Les paquets destinés au routeur ou provenant de celui-ci peuvent connaître une latence supérieure à celle prévue, car le processus ICMP doit attendre derrière le scanner BGP. Le cycle est que l'analyseur BGP fonctionne pendant un certain temps et se suspend, puis ICMP s'exécute. En revanche, les requêtes ping envoyées via un routeur doivent être commutées via Cisco Express Forwarding (CEF) et ne doivent pas subir de latence supplémentaire. Lorsque vous dépannez des pics périodiques de latence, comparez les temps de transfert des paquets transmis via un routeur aux paquets traités directement par le processeur sur le routeur.
Note: Les commandes ping qui spécifient des options IP, telles que la route d'enregistrement, exigent également que le processeur les traite directement, ce qui peut entraîner des retards de transmission plus longs.
Utiliser le processus show | include bgp scanner pour afficher la priorité du processeur. La valeur de Lsi dans l'exemple de sortie suivant utilise L pour faire référence à un processus de faible priorité.
6513#show processes | include BGP Scanner 172 Lsi 407A1BFC 29144 29130 1000 8384/9000 0 BGP Scanner
Le processus du routeur BGP s'exécute environ une fois par seconde pour vérifier le fonctionnement. La convergence BGP définit la durée entre le moment où le premier homologue BGP est établi et le point auquel le BGP est convergent. Afin d'assurer les temps de convergence les plus courts possibles, le routeur BGP consomme tous les cycles de CPU libres. Cependant, après son démarrage, il abandonne (ou suspend) le processeur de manière intermittente.
Le temps de convergence est une mesure directe du temps passé par le routeur BGP sur le processeur, et non sur le temps total. Cette procédure montre une condition CPU élevée pendant la convergence BGP et échange les préfixes BGP avec deux homologues BGP externes (eBGP).
Capturez une ligne de base pour l'utilisation normale du processeur avant de commencer le test.
router#show process cpu CPU utilization for five seconds: 0%/0%; one minute: 4%; five minutes: 5%
Une fois le test lancé, le processeur atteint une utilisation de 100 %. La commande show process cpucommand montre que la condition CPU élevée est causée par le routeur BGP, indiqué par 139 (l'ID de processus Cisco IOS pour le routeur BGP) dans le résultat suivant.
router#show process cpu CPU utilization for five seconds: 100%/0%; one minute: 99%; five minutes: 81% !--- Output omitted. 139 6795740 1020252 6660 88.34% 91.63% 74.01% 0 BGP Router
Vous pouvez surveiller et capturer plusieurs sorties des commandes show ip bgp summary et show process cpu à ce stade. La commande show ip bgp summary capture l'état des voisins BGP.
router#show ip bgp summary Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 10.0.0.0 4 64512 309453 157389 19981 0 253 22:06:44 111633 10.1.0.0 4 65101 188934 1047 40081 41 0 00:07:51 58430
Lorsque le routeur termine l'échange de préfixe avec ses homologues BGP, les taux d'utilisation du CPU reviennent à des niveaux normaux. Les moyennes calculées d'une minute et de cinq minutes peuvent également se rétablir et afficher des niveaux supérieurs à la normale pendant une période plus longue que le taux de cinq secondes.
router#show process cpu CPU utilization for five seconds: 3%/0%; one minute: 82%; five minutes: 91%
Utilisez le résultat capturé des commandes show précédentes pour calculer le temps de convergence BGP. En particulier, utilisez la colonne Up/Down< /strong> de la commande show ip bgp summary et comparez les heures de début et d'arrêt de la condition CPU élevée. En règle générale, la convergence BGP peut prendre plusieurs minutes lorsqu'une grande table de routage Internet. est remplacé
Note: Le processeur élevé sur le périphérique peut également être dû à l'instabilité de la table BGP. Cela se produit si le routeur reçoit deux copies de la table de routage, l'une provenant de l'appairage EBGP avec le FAI et l'autre provenant de l'appairage IBGP dans le réseau. La cause première de cette situation est la quantité de mémoire sur le périphérique. Cisco recommande un minimum de 1 Gig de RAM pour une seule copie de la table de routage Internet. Pour éviter cette instabilité, augmentez la mémoire vive sur le périphérique ou filtrez les préfixes de sorte que la table BGP et la mémoire occupée par celui-ci soient libérées.
À mesure que le nombre de routes dans la table de routage Internet augmente, le temps nécessaire à BGP pour converger augmente également. En général, la convergence est définie comme le processus lorsque toutes les tables de routage sont mises à un état de cohérence. BGP est considéré comme convergent lorsque ces conditions sont vraies :
Toutes les routes ont été acceptées.
Toutes les routes ont été installées dans la table de routage.
La version de table pour tous les homologues est égale à la version de table de la table BGP.
L'InQ et l'OutQ pour tous les homologues sont nuls.
Cette section décrit certaines améliorations des performances de Cisco IOS pour réduire le temps de convergence BGP, qui se traduisent par une réduction d'une condition CPU élevée due à un processus BGP.
BGP met désormais les données en file d'attente de manière agressive depuis le BGP OutQ vers le socket TCP pour chaque homologue jusqu'à ce que les OutQs se soient complètement vidés. Puisque BGP envoie maintenant à un débit plus rapide, BGP converge plus rapidement.
Bien qu'ils contribuent à simplifier la configuration BGP, les groupes d'homologues BGP peuvent également améliorer l'évolutivité. Tous les membres du groupe d'homologues doivent partager une stratégie sortante commune. Ainsi, les mêmes paquets de mise à jour peuvent être envoyés à chaque membre du groupe, ce qui réduit le nombre de cycles CPU que BGP nécessite pour annoncer les routes aux homologues. En d'autres termes, avec les groupes d'homologues, BGP ne parcourt la table BGP que sur le responsable du groupe d'homologues, filtre les préfixes à travers les stratégies sortantes et génère des mises à jour, qu'il envoie au responsable du groupe d'homologues. En retour, le responsable répliquera les mises à jour aux membres du groupe avec lesquels il est synchronisé. Sans groupes d'homologues, le protocole BGP doit parcourir la table pour chaque homologue, filtrer les préfixes par le biais de stratégies sortantes et générer des mises à jour qui sont envoyées à un seul homologue.
Toutes les sessions TCP sont limitées par une limite du nombre d’octets pouvant être transportés dans un seul paquet. Cette limite, appelée Taille maximale du segment (MSS), est de 536 octets par défaut. En d’autres termes, le protocole TCP sépare les paquets d’une file d’attente de transmission en blocs de 536 octets avant de les transmettre à la couche IP. Utilisez la commande show ip bgp neighbors | include max data pour afficher le MSS des homologues BGP :
Router#show ip bgp neighbors | include max data Datagrams (max data segment is 536 bytes): Datagrams (max data segment is 536 bytes): Datagrams (max data segment is 536 bytes): Datagrams (max data segment is 536 bytes):
L’avantage d’un MSS de 536 octets est que les paquets ne sont pas susceptibles d’être fragmentés sur un périphérique IP le long du chemin vers la destination, car la plupart des liaisons utilisent un MTU d’au moins 1 500 octets. L'inconvénient est que les paquets plus petits augmentent la quantité de bande passante utilisée pour le transport de la surcharge. Puisque BGP crée une connexion TCP à tous les homologues, un MSS de 536 octets affecte les temps de convergence BGP.
La solution est d'activer la fonctionnalité MTU de chemin (PMTU) avec la commande ip tcp path-mtu-discovery. Vous pouvez utiliser cette fonctionnalité pour déterminer de manière dynamique la taille de la valeur MSS et, dans l'intervalle, ne pas créer de paquets qui doivent être fragmentés. Le protocole PMTU permet au protocole TCP de déterminer la taille de MTU la plus petite parmi toutes les liaisons d’une session TCP. TCP utilise ensuite cette valeur MTU, moins la place des en-têtes IP et TCP, comme MSS pour la session. Si une session TCP ne traverse que des segments Ethernet, le MSS est de 1 460 octets. S'il ne traverse que les segments POS (Packet over SONET), le MSS est de 4 430 octets. L'augmentation de MSS de 536 à 1 460 ou 4 430 octets réduit la surcharge TCP/IP, ce qui permet à BGP de converger plus rapidement.
Après avoir activé PMTU, réutilisez la commande show ip bgp neighbors | inclure la commande max data pour voir la valeur MSS par homologue :
Router#show ip bgp neighbors | include max data Datagrams (max data segment is 1460 bytes): Datagrams (max data segment is 1460 bytes): Datagrams (max data segment is 1460 bytes): Datagrams (max data segment is 1460 bytes):
Si BGP annonce des milliers de routes à de nombreux homologues, TCP doit transmettre des milliers de paquets en une courte durée. Les homologues BGP reçoivent ces paquets et envoient des accusés de réception TCP au haut-parleur BGP qui les annonce, ce qui fait que le haut-parleur BGP reçoit un flot d'ACK TCP en peu de temps. Si les accusés de réception arrivent à un débit trop élevé pour le processeur de routage, les paquets remontent dans les files d'attente d'interface entrantes. Par défaut, les interfaces de routeur utilisent une taille de file d’attente d’entrée de 75 paquets. En outre, les paquets de contrôle spéciaux tels que BGP UPDATES utilisent une file d'attente spéciale avec SPD (Selective Packet Discard). Cette file d'attente spéciale contient 100 paquets. Lorsque la convergence BGP se produit, les ACK TCP peuvent remplir rapidement les 175 points de mise en mémoire tampon d'entrée et les nouveaux paquets qui arrivent doivent être abandonnés. Sur les routeurs avec 15 homologues BGP ou plus et échange de la table de routage Internet complète, plus de 10 000 pertes par interface par minute peuvent être vues. Voici un exemple de sortie d'un routeur 15 minutes après le redémarrage :
Router#show interface pos 8/0 | include input queue Output queue 0/40, 0 drops; input queue 0/75, 278637 drops Router#
Si vous augmentez la profondeur de la file d'attente d'entrée de l'interface (avec la commande hold-queue en commande), cela contribue à réduire le nombre de listes de contrôle d'accès TCP abandonnées, ce qui réduit la quantité de travail que BGP doit faire pour converger. Normalement, une valeur de 1000 résout les problèmes causés par les pertes de file d'attente d'entrée.
Note: Utilisez cela consciemment car l'incrémentation de la file d'attente d'entrée peut ajouter un certain délai.
Cisco IOS inclut plusieurs optimisations du code de groupe d'homologues BGP afin d'améliorer le conditionnement et la réplication des mises à jour. Avant de passer en revue ces améliorations, examinez plus en détail le conditionnement et la réplication des mises à jour.
Une mise à jour BGP se compose d'une combinaison d'attributs (tels que MED = 50 et LOCAL_PREF = 120) et d'une liste de préfixes NLRI (Network Layer Reachability Information) qui partagent cette combinaison d'attributs. Plus le nombre de préfixes NLRI que BGP peut répertorier dans une seule mise à jour est élevé, plus le BGP peut converger plus vite puisque la surcharge (comme les en-têtes IP, TCP et BGP) est réduite. L'emballage des mises à jour fait référence à l'emballage de NLRI dans les mises à jour BGP. Par exemple, si une table BGP contient 100 000 routes avec 15 000 combinaisons d'attributs uniques, BGP doit envoyer seulement 15 000 mises à jour si NLRI est rempli avec une efficacité de 100 %.
Note: L'efficacité d'emballage de zéro signifie que BGP devrait envoyer 100 000 mises à jour dans cet environnement.
Utilisez la commande show ip bgp peer-group pour afficher l'efficacité des mises à jour BGP.
Si un membre du groupe d'homologues est synchronisé, un routeur BGP prend un message de mise à jour formaté pour le responsable du groupe d'homologues et le répliquera pour le membre. Il est beaucoup plus efficace de répliquer une mise à jour pour un membre de groupe d'homologues que de reformater la mise à jour. Par exemple, supposons qu'un groupe d'homologues a 20 membres et que tous les membres doivent recevoir 100 messages BGP. La réplication à 100 % signifie qu'un routeur BGP formate les 100 messages pour le responsable du groupe homologue et réplique ces messages aux 19 autres membres du groupe homologue. Pour confirmer les améliorations apportées à la réplication, comparez le nombre de messages répliqués au nombre de messages formatés, comme indiqué par la commande show ip bgp peer-group. Les améliorations font une différence considérable dans les temps de convergence et permettent à BGP de prendre en charge beaucoup plus d'homologues.
Par exemple, utilisez la commande show ip bgp peer-group pour vérifier l'efficacité de la mise à jour du conditionnement et de la réplication de mise à jour. La sortie suivante provient d'un test de convergence avec 6 groupes d'homologues, 20 homologues dans chacun des 5 premiers groupes d'homologues (homologues eBGP) et 100 homologues dans le sixième groupe d'homologues (homologues BGP internes (iBGP)). En outre, la table BGP utilisée comportait 36 250 combinaisons d'attributs.
L'exemple suivant du résultat de la commande show ip bgp peer-group | include, commande répliquée sur un routeur qui exécute Cisco IOS 12.0(18)S, affiche les informations suivantes :
Update messages formatted 836500, replicated 1668500 Update messages formatted 1050000, replicated 1455000 Update messages formatted 660500, replicated 1844500 Update messages formatted 656000, replicated 1849000 Update messages formatted 501250, replicated 2003750 !-- The first five lines are for eBGP peer groups. Update messages formatted 2476715, replicated 12114785 !-- The last line is for an iBGP peer group.
Afin de calculer le taux de réplication pour chaque groupe d'homologues, divisez le nombre de mises à jour répliquées par le nombre de mises à jour formatées :
1668500/836500 = 1,99 1455000/105000 = 1,38 1844500/660500 = 2,79 184 9000/656000 = 2,81 2003750/501250 = 3,99 12114785/2476715 = 4,89
Sur un routeur qui exécute Cisco IOS 12.0(19)S, show ip bgp peer-group La commande | include dupliquatedfournit ces informations :
Update messages formatted 36250, replicated 688750 Update messages formatted 36250, replicated 688750 Update messages formatted 36250, replicated 688750 Update messages formatted 36250, replicated 688750 Update messages formatted 36250, replicated 688750 Update messages formatted 36250, replicated 3588750
Note: Mettre à jour l'emballage est optimal. Exactement 36 250 mises à jour sont formatées pour chaque groupe d'homologues. 688750/36250 = 19 688750/36250 = 19 688750/36250 = 19 688750/36250 = 19 688750/36250 = 19 3588750/36250 = 99
Note: La réplication des mises à jour est également parfaite.
Utilisez ces procédures afin de dépanner le CPU élevé dû au scanner BGP ou au routeur BGP :
Collectez des informations sur votre topologie BGP. Déterminez le nombre d'homologues BGP et le nombre de routes annoncées par chaque homologue. La durée de la condition élevée du processeur est-elle raisonnable en fonction de votre environnement ?
Déterminez quand le processeur est élevé. Cela coïncide-t-il avec une marche régulière de la table BGP ?
Le processeur élevé a-t-il suivi un rabat d'interface ? Vous pouvez utiliser la commande show ip bgp dampening flap-statistics si l'amortissement est activé.
Envoyez une requête ping à travers le routeur, puis à partir du routeur. Les échos ICMP sont traités comme un processus de faible priorité. Le document Comprendre les commandes Ping et Traceroute explique cela plus en détail. Assurez-vous que le transfert régulier n'est pas affecté.
Vous devez vous assurer que les paquets peuvent suivre un chemin de transfert rapide lorsque vous vérifiez si la commutation rapide et/ou CEF sont activées sur les interfaces entrantes et sortantes. Assurez-vous que vous ne voyez pas la commande no ip route-cache cef sur l'interface ou la commande no ip cef sur la configuration globale. Afin d'activer CEF en mode de configuration globale, utilisez la commande ip cef.
Vérifiez la quantité de mémoire disponible sur le routeur. Conformément à la recommandation, utilisez au moins 1 Go de DRAM attribué à l'espace Cisco IOS par homologue BGP qui envoie la table de routage Internet complète. L'espace DRAM mentionné ici n'est que la mémoire requise pour BGP. D’autres fonctions exécutées sur le routeur peuvent nécessiter un espace supplémentaire.
Révision | Date de publication | Commentaires |
---|---|---|
2.0 |
18-Jul-2022 |
Recertification |
1.0 |
22-Jul-2008 |
Première publication |