Résolution du problème d'utilisation élevée du processeur causée par le processus d'entrée HyBridge sur les routeurs dotés d'interfaces ATM

Introduction

Ce document explique comment dépanner une utilisation élevée du CPU dans un routeur en raison du processus d'entrée HyBridge. Les interfaces ATM peuvent prendre en charge un grand nombre de circuits virtuels permanents (PVC) configurés pour utiliser des unités de données de protocole (PDU) de type requête de commentaires (RFC) 1483 avec pontage et pontage intégré (IRB) Cisco IOS^® standard. Cette approche repose largement sur les diffusions pour la connectivité aux utilisateurs distants. À mesure que le nombre d’utilisateurs distants et de circuits virtuels permanents augmente, le nombre de diffusions parmi ces utilisateurs augmente également. Dans certaines circonstances, ces diffusions produisent une utilisation élevée du CPU sur le routeur.

Conditions préalables

Conditions requises

Aucune spécification déterminée n'est requise pour ce document.

Conventions

Pour plus d'informations sur les conventions utilisées dans ce document, reportez-vous à Conventions relatives aux conseils techniques Cisco.

Architecture de pontage standard

Le TRFC 1483 spécifie qu'un pont transparent (qui inclut un routeur Cisco configuré pour le pontage) doit être capable d'inonder, de transmettre et de filtrer les trames pontées. L’inondation est le processus par lequel une trame est copiée vers toutes les destinations appropriées possibles. Un pont ATM inonde une trame lorsqu’il copie explicitement la trame sur chaque circuit virtuel (VC) ou lorsqu’il utilise un circuit virtuel point à multipoint.

Avec le pontage Cisco IOS standard, les trames telles que les protocoles ARP (Address Resolution Protocols), les diffusions, les multidiffusions et les paquets Spanning Tree doivent passer par ce processus d’inondation. La logique de pontage Cisco IOS gère tous ces paquets :

1. Parcourt la liste des interfaces et sous-interfaces configurées dans le groupe de ponts.

2. Parcourt la liste des circuits virtuels configurés sur les interfaces membres du groupe de ponts.

3. Réplique la trame sur chaque circuit virtuel.

Les routines du logiciel Cisco IOS qui gèrent la réplication doivent s'exécuter en boucle pour dupliquer le paquet sur chaque circuit virtuel permanent. Si le routeur prend en charge un grand nombre de circuits virtuels permanents au format ponté, les routines de réplication s'exécutent pendant une longue période, ce qui augmente le processeur. Une capture de la commande show process cpu affiche une grande valeur de 5 secondes pour l'entrée HyBridge, qui est responsable du transfert des paquets qui utilisent la méthode de commutation de processus de transfert de paquets. Cisco IOS doit traiter des paquets de commutation tels que les unités BPDU (Spanning Tree Bridge Protocol Data Units), les diffusions et les multidiffusions qui ne peuvent pas être commutées rapidement en multidiffusion. La commutation de processus peut nécessiter une grande quantité de temps processeur, car seul un nombre limité de paquets est traité par appel.

Lorsqu'une interface unique prend en charge de nombreux circuits virtuels, la traversée de la liste des circuits virtuels peut submerger le processeur. L'ID de bogue Cisco CSCdr11146 résout ce problème. Lorsque la logique de pontage s'exécute dans une boucle pour répliquer les diffusions, elle abandonne le processeur de manière intermittente. Le retrait du processeur est également appelé suspension du processeur.

Remarque : La configuration de nombreuses sous-interfaces dans le même groupe de ponts peut également submerger le processeur.

Symptômes typiques

Si vos circuits virtuels permanents pontés entraînent une utilisation élevée du CPU sur le routeur, la première chose à rechercher est un nombre élevé de diffusions sur votre interface :

ATM_Router# show interface atm1/0 
   ATM1/0 is up, line protocol is up 
      Hardware is ENHANCED ATM PA 
      MTU 4470 bytes, sub MTU 4470, BW 44209 Kbit,    DLY 190 usec, 
         reliability 0/255, txload    1/255, rxload 1/255 
      Encapsulation ATM, loopback not set    
      Keepalive not supported 
      Encapsulation(s): AAL5 
      4096 maximum active VCs, 0 current VCCs    
      VC idle disconnect time: 300 seconds    
      77103 carrier transitions 
      Last input 01:06:21, output 01:06:21, output    hang never 
      Last clearing of "show interface" counters    never 
      Input queue: 0/75/0/702097 (size/max/drops/flushes);    Total output drops: 12201965 
      Queueing strategy: Per VC Queueing    
      5 minute input rate 0 bits/sec, 0 packets/sec    
      5 minute output rate 0 bits/sec, 0 packets/sec    
         59193134 packets input,    3597838975 bytes, 1427069 no buffer 
         Received 463236 broadcasts,    0 runts, 0 giants, 0 throttles 
         46047 input errors, 46047    CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 
         91435145 packets output,    2693542747 bytes, 0 underruns 
         0 output errors, 0 collisions,    4 interface resets 
         0 output buffer failures,    0 output buffers swapped out  

En tant qu'effet secondaire, vous pouvez voir un nombre élevé de pertes sur l'interface. Dans cette situation, le problème peut être partout, de la lenteur de la réponse sur le routeur à l’inaccessibilité totale du routeur. Si vous mettez l’interface hors tension ou déconnectez le câble de l’interface ATM, le routeur doit être rétabli.

Si le trafic de diffusion est en rafale, ce qui n'entraîne que des pics de CPU pendant de courtes périodes, le problème peut être atténué si vous modifiez la file d'attente de mise en attente d'entrée sur l'interface pour prendre en charge les rafales. La taille par défaut de la file d'attente de mise en attente est de 75 paquets et peut être modifiée à l'aide de la commande hold-queue <queue length> in|out. En règle générale, la taille de la file d'attente ne doit pas être augmentée au-dessus de 150, car cela entraîne une charge plus importante au niveau du processus sur le processeur.

Dépannage

Si vous rencontrez des problèmes d'utilisation élevée du CPU causés par l'entrée HyBridge, capturez cette sortie lorsque vous contactez le centre d'assistance technique Cisco (TAC). Pour capturer ce résultat, utilisez les commandes suivantes :

• show process cpu - Si vous remarquez une utilisation élevée du CPU, utilisez la commande show process CPU pour identifier le processus défaillant. Voir Dépannage de l'utilisation élevée du CPU sur les routeurs Cisco.

• show stacks {process ID} - Vous pouvez également utiliser cette commande pour voir quels processus sont opérationnels et rechercher des problèmes potentiels. Collez la sortie de cette commande dans l'outil Interpréteur de sortie (clients enregistrés uniquement). Une fois les processus décodés, vous pouvez rechercher des bogues possibles avec le Software Bug Toolkit.

  Remarque : vous devez vous inscrire à un compte CCO et être connecté pour utiliser ces deux outils.

• show bridge verbose - Utilisez cette commande show pour déterminer le nombre de sous-interfaces placées dans le même groupe de ponts, ainsi que pour voir si l'interface est saturée.

   router#show process cpu

   CPU utilization for five seconds: 100%/26%; one minute: 94%; five minutes: 56% 
   PID   Runtime(ms)   Invoked   uSecs   5Sec   1Min   5Min   TTY   Process 
    1            44    38169     1       0.00%  0.00%  0.00%    0   Load Meter 
    2           288    733       392     0.00%  0.00%  0.00%    0   PPP auth 
    3         44948    19510     2303    0.00%  0.05%  0.03%    0   Check heaps    
    4             4    1         4000    0.00%  0.00%  0.00%    0   Chunk Manager 
    5          2500    6229      401     0.00%  0.00%  0.00%    0   Pool Manager 
   [output omitted] 
    86            4    1         4000    0.00%  0.00%  0.00%    0   CCSWVOFR    
    87      3390588    1347552   2516    72.72% 69.79% 41.31%   0   HyBridge Input 
    88          172    210559    0       0.00%  0.00%  0.00%    0   Tbridge Monitor    
    89      1139592    189881    6001    0.39%  0.42%  0.43%    0   SpanningTree 

  router#show stacks 87 
   Process 87: HyBridge Input Process 
    Stack segment 0x61D15C5C - 0x61D18B3C 
    FP: 0x61D18A18, RA: 0x60332608 
    FP: 0x61D18A58, RA: 0x608C5400 
    FP: 0x61D18B00, RA: 0x6031A6D4 
    FP: 0x61D18B18, RA: 0x6031A6C0

   router#show bridge verbose
   Total of 300 station blocks, 299 free 
   Codes: P - permanent, S - self

   BG  Hash   Address          Action   Interface       VC Age   RX count   TX count      
     1 8C/0   0000.0cd5.f07c   forward  ATM4/0/0.1      9   0    1857       0
   
Flood ports (BG 1)      RX count TX count 
     ATM4/0/0.1                   0        0

En outre, arrêtez l'interface BVI (Bridge Group Virtual Interface) et surveillez l'utilisation du CPU avec plusieurs captures de la sortie de la commande show process cpu.

Solutions

Cisco vous recommande de mettre en oeuvre ces solutions de contournement comme solution à l'utilisation élevée du CPU causée par le pontage standard :

• Implémentez la fonctionnalité de prise en charge du pont de la ligne d'abonné numérique Cisco IOS x, qui configure le routeur pour une diffusion intelligente du pont par le biais de stratégies d'abonné. Bloquez sélectivement les ARP, les diffusions, les multidiffusions et les BPDU Spanning Tree.

• Répartissez les circuits virtuels sur quelques interfaces multipoints, chacune ayant un réseau IP différent.

• Configurez le compteur d'obsolescence des entrées de table de pontage et ARP IP sur la même valeur. Sinon, vous pouvez voir une inondation inutile du trafic dans vos liaisons. Le délai ARP par défaut est de quatre heures. La durée de vieillissement du pont par défaut est de 10 minutes. Pour un utilisateur distant inactif depuis 10 minutes, le routeur purge uniquement l'entrée de la table de pont de l'utilisateur et conserve l'entrée de la table ARP. Lorsque le routeur doit envoyer du trafic en aval à l’utilisateur distant, il vérifie la table ARP et trouve une entrée valide pour pointer vers l’adresse MAC. Lorsque le routeur recherche cette adresse MAC dans la table de pontage et ne la trouve pas, il diffuse le trafic de chaque circuit virtuel du groupe de pontage. Utilisez ces commandes pour définir les durées de vieillissement de la table ARP et de la table de pontage.

   router(config)#bridge 1 aging-time ?
   <10-1000000> Seconds
  
   router(config)#interface bvi1    
  
   router(config-if)#arp timeout ? 
        <0-2147483> Seconds 
  

• Remplacer le pontage standard et l’IRB par des circuits virtuels permanents de type routé (RBE) ou ponté au niveau de l’interface ATM de tête de réseau. RBE améliore les performances de transfert car il prend en charge Cisco Express Forwarding (CEF) et exécute les paquets IP uniquement par une décision de routage et non par une décision de pontage. Sur le train 12.1(1)T, les paquets peuvent être commutés par logiciel. Si oui, vous pouvez voir ce message d'erreur :

  %FIB-4-PUNTINTF: CEF punting packets switched to        ATM1/0.100 to next slower path 
  %FIB-4-PUNTINTF: CEF punting packets switched to ATM1/0.101        to next slower path  

  Le problème est documenté dans CSCdr37618, et la solution est de mettre à niveau vers la ligne principale 12.2. Référez-vous à Architecture de référence d'encapsulation pontée routée et Configuration de circuits virtuels permanents de type ponté sur des interfaces ATM dans les gammes GSR et 7500 pour plus d'informations.

Informations connexes

• Dépannage de l'utilisation élevée du CPU sur les routeurs Cisco
• Support et documentation techniques - Cisco Systems
• Outils et utilitaires - Cisco Systems

Historique de révision