Ce document décrit comment effectuer le dépannage de l'utilisation élevée du processeur provoquée par différents processus.
Nous vous recommandons de lire Dépannage de l'utilisation élevée du CPU sur les routeurs Cisco avant de poursuivre avec ce document.
Ce document n'est pas limité à des versions de matériel et de logiciel spécifiques.
Les informations présentées dans ce document ont été créées à partir de périphériques dans un environnement de laboratoire spécifique. All of the devices used in this document started with a cleared (default) configuration. Si vous travaillez dans un réseau opérationnel, assurez-vous de bien comprendre l'impact potentiel de toute commande avant de l'utiliser.
Pour plus d'informations sur les conventions utilisées dans ce document, consultez Conventions relatives aux conseils techniques Cisco.
Une utilisation CPU élevée dans le processus d'entrée ARP (Address Resolution Protocol) se produit si le routeur doit émettre un nombre excessif de requêtes ARP. Le routeur utilise le protocole ARP pour tous les hôtes, et pas seulement ceux du sous-réseau local, et les requêtes ARP sont envoyées en tant que diffusions, ce qui entraîne une plus grande utilisation du processeur sur chaque hôte du réseau. Les requêtes ARP pour la même adresse IP sont limitées en débit à une requête toutes les deux secondes, de sorte qu'un nombre excessif de requêtes ARP devrait provenir de différentes adresses IP. Cela peut se produire si une route IP a été configurée pointant vers une interface de diffusion. Un exemple le plus évident est une route par défaut telle que :
ip route 0.0.0.0 0.0.0.0 Fastethernet0/0
Dans ce cas, le routeur génère une requête ARP pour chaque adresse IP qui n'est pas accessible via des routes plus spécifiques, ce qui signifie pratiquement que le routeur génère une requête ARP pour presque chaque adresse sur Internet. Pour plus d'informations sur la configuration de l'adresse de tronçon suivant pour le routage statique, consultez Spécification d'une adresse IP de tronçon suivant pour les routes statiques.
Une quantité excessive de requêtes ARP peut également être causée par un flux de trafic malveillant qui analyse les sous-réseaux connectés localement. La présence d’un nombre très élevé d’entrées ARP incomplètes dans la table ARP est une indication d’un tel flux. Puisque les paquets IP entrants qui déclencheraient des requêtes ARP devraient être traités, le dépannage de ce problème serait essentiellement le même que le dépannage d'une utilisation CPU élevée dans le processus d'entrée IP.
Le processus d'entrée IPX est similaire au processus d'entrée IP dans le sens où il prend en charge la commutation de processus, sauf que le processus d'entrée IPX commute des paquets IPX. Presque tous les paquets IPX sont examinés au niveau du processus par IPX Input avant d'être mis en file d'attente vers d'autres processus IPX tels que IPX SAP In, IPX RIP In, etc. Contrairement à IP, IPX ne prend en charge qu'un seul mode de commutation d'interruption, à savoir la commutation rapide IPX, activée par défaut. La commutation rapide IPX est activée à l'aide de la commande d'interface ipx route-cache .
Si vous constatez une utilisation élevée du CPU pendant le processus d'entrée IPX, vérifiez les points suivants :
La commutation rapide IPX est désactivée. Utilisez la commande show ipx interface si la commutation rapide IPX est désactivée.
Certains trafics IPX ne peuvent pas être commutés rapidement par IPX :
Diffusions IPX : vérifiez si le routeur est saturé de diffusions IPX à l'aide de la commande show ipx traffic.
Mises à jour de routage IPX : si le réseau présente de nombreuses instabilités, le traitement des mises à jour de routage augmente.
Remarque : au lieu du protocole RIP IPX, utilisez le protocole EIGRP IPX (incrémentiel) pour réduire le nombre de mises à jour, en particulier sur les liaisons série lentes (reportez-vous à la section Routage de Novell IPX sur des lignes série lentes et à la section Gestion SAP pour plus de détails).
Remarque : vous trouverez d'autres documents relatifs à IPX sur la page Novell IPX Technology Support.
Lorsque le processus du minuteur TCP (Transmission Control Protocol) utilise beaucoup de ressources CPU, cela indique qu'il y a trop de points d'extrémité de connexion TCP. Cela peut se produire dans les environnements de commutation de liaisons de données (DLSw) avec de nombreux homologues, ou dans d'autres environnements où de nombreuses sessions TCP sont ouvertes simultanément sur le routeur.
Le temporisateur de contrôle FIB initialise et démarre le temporisateur de collecte de statistiques FIB pour les statistiques par VLAN et les statistiques globales ; initialise et démarre le temporisateur de requête/exception FIB/ADJ ; maintient les fonctions de registre associées à FIB ; et initialise le temporisateur de comptabilité BGP. Ces processus démarrent lors de l'initialisation d'EARL.
Le processus TTY Background est un processus générique utilisé par toutes les lignes de terminal (console, aux, async, etc.). Normalement, il ne devrait pas y avoir d'impact sur les performances du routeur puisque ce processus a une priorité plus faible que les autres processus qui doivent être planifiés par le logiciel Cisco IOS.
Si ce processus requiert une utilisation CPU élevée, vérifiez si la « journalisation synchrone » est configurée sous « line con 0 ». La cause possible pourrait être l'ID de bogue Cisco CSCed16920 (clients enregistrés uniquement), l'ID de bogue Cisco ou CSCdy01705 (clients enregistrés uniquement) .
L'utilisation du CPU vue pour le processus « TAG Stats Background » est attendue, et elle n'affecte pas le transfert de trafic.
Le processus TAG Stats Background est un processus de faible priorité. Ce processus collecte des statistiques pour les balises et les transmet au RP. Ce n'est pas une fonction de la quantité de trafic, mais de la quantité de travail que le plan de contrôle MPLS/LDP effectue. Il s'agit d'un comportement attendu, qui n'a pas d'impact sur le transfert du trafic. Ce problème est documenté dans le bogue CSCdz32988 (clients enregistrés seulement) .
Un modèle virtuel (vtemplate) doit être cloné pour chaque nouvelle interface d'accès virtuelle chaque fois qu'un nouvel utilisateur se connecte au routeur ou au serveur d'accès. L'utilisation du CPU dans le processus Vtemplate Backgr peut devenir extrêmement élevée si le nombre d'utilisateurs est important. Cela peut être évité en configurant le pré-clonage du modèle virtuel. Pour plus d'informations, consultez Améliorations de l'évolutivité de session.
Le processus Arrière-plan réseau s'exécute chaque fois qu'une mémoire tampon est requise mais n'est pas disponible pour le processus ou l'interface. Il crée les mémoires tampon souhaitées à partir du pool principal en fonction de la requête. L'arrière-plan net gère également la mémoire utilisée par chaque processus et nettoie la mémoire libérée. Ce processus est principalement associé aux interfaces et peut consommer des ressources CPU importantes. Les symptômes d'une CPU élevée sont l'augmentation des étranglements, l'ignorance, les dépassements et les réinitialisations sur une interface.
Le processus IP Background implique les procédures suivantes : le vieillissement périodique du cache de redirection ICMP chaque minute ; un changement de type d'encapsulation d'une interface ; le passage d'une interface à un nouvel état, UP et/ou DOWN ; un changement d'adresse IP de l'interface ; l'expiration d'une nouvelle carte dxi ; et l'expiration des minuteurs de numérotation.
Le processus IP Background modifie la table de routage en fonction de l'état des interfaces, tandis que le processus IP Background suppose qu'il y a un changement d'état de liens lorsqu'il reçoit des messages de changement d'état de liens. Il indique ensuite à tous les protocoles de routage de vérifier l’interface concernée. Si davantage d’interfaces exécutent des protocoles de routage, une utilisation plus élevée du CPU est provoquée par le processus IP Background.
Les processus ARP en arrière-plan gèrent plusieurs tâches et peuvent consommer une utilisation CPU élevée.
Cette liste fournit quelques exemples de travaux :
Vidage ARP dû à des événements d'interface up/down
Effacement de la table ARP via la commande clear arp
Paquets d'entrée ARP
appareil de radionavigation ARP
Si un autre processus consomme beaucoup de ressources CPU et qu'il n'y a aucune indication de problème dans les messages enregistrés, alors le problème peut être causé par un bogue dans le logiciel Cisco IOS®. En utilisant le Bug Toolkit (clients enregistrés seulement) , lancez une recherche pour le processus spécifié pour voir si des bogues ont été rapportés.
Si vous avez toujours besoin d'aide après avoir suivi les étapes de dépannage ci-dessus et que vous souhaitez créer une demande de service avec le TAC Cisco, veillez à inclure les informations suivantes : |
---|
|
Révision | Date de publication | Commentaires |
---|---|---|
1.0 |
29-Sep-2008 |
Première publication |