Dépannage de l'UC élevée causée par le scanner BGP ou le processus du routeur

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.

Amélioration des performances

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

Connexions de la file d'attente vers les homologues TCP

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.

Groupes d'homologues BGP

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.

Path MTU et la commande ip tcp path-mtu-discovery

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): 

Augmenter les files d'attente d'entrée d'interface

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.

Améliorations supplémentaires apportées à Cisco IOS

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

• Si BGP est parfaitement répliqué, les groupes d'homologues eBGP ont chacun un taux de réplication de 19 car il y a 20 homologues dans le groupe d'homologues. La mise à jour est formatée pour le responsable du groupe d'homologues, puis répliquée sur les 19 autres homologues. Cela fournit un taux de réplication optimal de 19. Le taux de réplication idéal pour le groupe d'homologues iBGP serait de 99 car il y a 100 homologues.
• Si les mises à jour BGP sont parfaitement compressées, il n'y a que 36 250 mises à jour formatées. Vous devez uniquement générer 36 250 mises à jour pour chaque groupe d'homologues, car il s'agit du nombre de combinaisons d'attributs dans la table BGP. Le groupe d'homologues iBGP à lui seul met en forme près de 2 500 000 mises à jour tandis que les groupes d'homologues eBGP génèrent chacun entre 500 000 et 1 000 000 mises à jour.

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.

Procédures de dépannage

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 l'évolutivité de la plate-forme car, dans la plupart des cas, elle est due à un périphérique surchargé qui mène à de telles situations. Vérifiez également que le routeur dispose d'un espace TCAM (ternary content Addressable Memory) approprié.

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

Informations connexes

• Page de support pour le routage IP
• Support technique - Cisco Systems