Avez-vous un compte?
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 les questions élevées CPU sur un routeur de gamme ASR1000.
Cisco recommande que vous comprenniez l'architecture ASR1000 pour interpréter et utiliser ce document.
La CPU de haute sur un routeur de Cisco peut être définie comme condition où l'utilisation du processeur sur le routeur est au-dessus de l'utilisation normale. Dans quelques scénarios l'utilisation du CPU accrue est prévue tandis que dans d'autres scénarios elle pourrait indiquer un problème. L'utilisation du CPU élevé passagère sur le routeur dû à la modification de réseau ou à la modification de configuration peut être ignorée et est comportement prévu.
Cependant, un routeur qui n'éprouve l'utilisation du CPU élevé pendant des périodes étendues sans aucun changement du réseau ou de la configuration est peu commun et doit être analysé. Par conséquent une fois abusée, la CPU ne peut pas entretenir activement tous autres processus, qui a comme conséquence la ligne de commande lente, la latence plate de contrôle, les pertes de paquets, et la panne des services.
Les causes de la CPU de haute sont :
La CPU de haute n'est pas toujours un problème de routeur de gamme ASR1000 car l'utilisation de CPU de routeur est directement proportionnelle au chargement sur le routeur. Par exemple s'il y a une modification de réseau, ceci entraînera un grand nombre de trafic d'avion de contrôle car le réseau re-convergera. Par conséquent, nous devons déterminer la cause principale de la sur-utilisation CPU de déterminer si c'est comportement prévu ou une question.
Est ci-dessous un diagramme qui détaille un processus pas à pas sur la façon dont dépanner une question CPU de haute :
ASR1000 a plusieurs la CPU différente à travers les différents modules. Par conséquent, nous devons voir quel module affiche une utilisation plus grande que normalement. Ceci peut être vu par la valeur de veille, pendant que plus la valeur de veille est inférieure, plus l'utilisation du processeur de ce module est élevée. Ces CPU différente toute reflètent le plan de contrôle des modules.
Déterminez quel module dans le périphérique est observé pour éprouver la CPU de haute. Est il le RP, l'ESP, ou le SIP avec la commande ci-dessous
brief de show platform software status control-processor
Référez-vous à la sortie ci-dessous pour visualiser la colonne mise en valeur
Si le RP a une valeur de veille basse, alors passez à l'étape 2 points 1
Si l'ESP a une valeur de veille basse, alors passez à l'étape 3 points 2
Si le SIP a une valeur de veille basse, alors passez à l'étape 4 points 3
Brief de processeur de contrôle d'état du logiciel de plate-forme de Router#show
Moyenne de charge
État 1-Min 5-Min 15-Min d'emplacement
RP0 0.00 0.02 0.00 sain
ESP0 0.01 0.02 0.00 sain
SIP0 0.00 0.01 0.00 sain
Mémoire (kB)
Libre utilisé par total d'état d'emplacement (PCT) (PCT) commis (PCT)
RP0 2009376 1879196 (94%) 130180 (6%) 1432748 sains (71%)
ESP0 2009400 692100 (34%) 1317300 (66%) 472536 sains (24%)
SIP0 471804 284424 (60%) 187380 (40%) 193148 sains (41%)
Utilisation du processeur
Inactif IRQ SIRQ IOwait de système d'utilisateur CPU d'emplacement Nice
RP0 0 2.59 2.49 0.00 94.80 0.00 0.09 0.00
ESP0 0 2.30 17.90 0.00 79.80 0.00 0.00 0.00
SIP0 0 1.29 4.19 0.00 94.41 0.09 0.00 0.00
Si les valeurs de veille sont tout le relativement élevées, ce peut ne pas être une question d'avion de contrôle. Pour dépanner le plan de données que le QFP de l'ESP doit être observé. Les symptômes de la « CPU de haute » peuvent encore être dus observé à un QFP excessivement utilisé, qui n'aura pas comme conséquence la CPU de haute sur les processeurs d'avion de contrôle. Passez à l'étape 6.
Confirmez dans le RP qu'on observe le processeur pour avoir l'utilisation du CPU élevé avec la commande ci-dessous. Est-ce le processus de Linux ou l'IOS ?
moniteur d'active de l'emplacement RP de processus de logiciel de show platform
Si le pourcentage CPU IOS est élevé (linux_iosd-imag), alors est il est l'IOS RP. Passez à l'étape 3
Si le pourcentage CPU d'autres processus est élevé, alors il est susceptible d'être le processus de Linux. Passez à l'étape 4
Confirmez dans l'ESP si on observe le processeur d'avion de contrôle pour avoir l'utilisation du CPU élevé. Est-ce le FECP ?
moniteur d'active point de gel d'emplacement de processus de logiciel de show platform
Si les processus sont élevés puis c'est le FECP, alors passe à l'étape 5
Si ce n'est pas le FECP, ce n'est pas une question connexe de processus d'avion de contrôle dans l'ESP. Si on observe toujours des symptômes tels que des baisses de latence de réseau ou de file d'attente, le plan de données peut devoir être examiné pour la sur-utilisation. Passez à l'étape 6
Si on observe le SIP pour avoir l'utilisation du CPU élevé puis on observera l'IOCP pour avoir la CPU de haute. Déterminez quels processus ou processus dans l'IOCP sont observés pour avoir l'utilisation du CPU élevé.
Effectuez une capture de paquet et l'identifiez que le trafic est supérieur à habituel et que des processus sont associé avec ce type de trafic. Passez à l'étape 7
Référez-vous à la sortie ci-dessous, le premier pourcentage est toute l'utilisation du processeur, et le deuxième pourcentage est l'utilisation du processeur d'interruption, qui est la quantité de CPU utilisée pour traiter les paquets donnés un coup de volée.
Si le pourcentage d'interruption est élevé puis il signifie qu'un grand nombre de trafic est donné un coup de volée au RP, (ceci peut être confirmé avec le coup de volée d'infrastructure de logiciel de show platform de commande)
Si le pourcentage d'interruption est bas, mais toute la CPU est élevée, alors il y a un processus ou des processus qui seront observés pour utiliser la CPU pendant une période étendue.
Confirmez dans l'IOS qu'on observe le processus ou les processus pour avoir l'utilisation du CPU élevé avec la commande ci-dessous.
show processes cpu trié
Identifiez quel pourcentage est élevé (CPU totale ou CPU d'interruption), et puis identifiez s'il y a lieu le processus individuel/processus. Passez à l'étape 7
Router#show traite la CPU triée
Utilisation du processeur pendant cinq secondes : 0%/0% ; une minute : 1% ; cinq minutes : 1%
PID Runtime(ms) a appelé le processus TTY des uSecs 5Sec 1Min 5Min
PID Runtime(ms) a appelé le processus TTY des uSecs 5Sec 1Min 5Min
188 8143 434758 18 0.15% 0.18% 0.19% 0 Ti milliseconde d'Ethernets
515 380 7050 53 0.07% 0.00% 0.00% 0 processus SBC principaux
3 2154 215 10018 0.07% 0.00% 0.19% 0 exécutifs
380 1783 55002 32 0.07% 0.06% 0.06% 0 TEMPORISATEURS DE DB MUTTAHIDA MAJLIS-E-AMAL
63 3132 11143 281 0.07% 0.07% 0.07% 0 tâches IOSD IPC
5 1 2 500 0.00% 0.00% 0.00% 0 IPC ISSU Dispatc
6 19 12 1583 0.00% 0.00% 0.00% 0 Ths principaux slaves rf
8 0 1 0 0.00% 0.00% 0.00% 0 ROs informent des temporisateurs
7 0 1 0 0.00% 0.00% 0.00% 0 EDDRI_MAIN
10 6 75 80 0.00% 0.00% 0.00% 0 gestionnaires de groupe
9 5671 538 10540 0.00% 0.14% 0.12% segment de mémoire de 0 contrôles
Si on observe l'IOS pour avoir surchargé la CPU, alors nous devons observer l'utilisation du processeur pour le processus individuel de Linux. Ces processus sont les autres processus répertoriés du moniteur d'active de l'emplacement RP de processus de logiciel de show platform. Identifiez quels processus ou processus sont observés pour éprouver la CPU de haute puis passent à l'étape 7.
Si un processus ou des processus sont élevés alors il est probable ceux sont les processus dans les FECP qui sont responsables de l'utilisation du CPU élevé, passez à l'étape 7
Le processeur d'écoulement de Quantum est l'ASIC de transmission. Pour déterminer le chargement sur l'engine d'expédition, le QFP peut être surveillé. Les listes de commandes ci-dessous les paquets d'entrée et sortie (priorité et non-prioritaire) en paquets par seconde, et bits par seconde. La ligne affichages finale la quantité totale de chargement CPU due au transfert de paquet dans un pourcentage.
utilisation active de datapath de qfp de matériel de show platform
Identifiez si l'entrée ou la sortie sont élevée, et visualisez le chargement de processus et puis passez à l'étape 7
Utilisation active de datapath de qfp de matériel de la plate-forme de Router#show
CPP 0 : Subdev 0 5 sec 1 minute 5 minute de la minute 60
Entrée : Priorité (PPS) 0 0 0 0
(bps) 208 176 176 176
(PPS) 0 2 2 2 non-prioritaires
(bps) 64 784 784 784
Montez-vous (PPS) à 0 2 2 2
(bps) 272 960 960 960
Sortie : Priorité (PPS) 0 0 0 0
(bps) 192 160 160 160
(PPS) 0 1 1 1 non-prioritaire
(bps) 0 6488 6496 6488
Montez-vous (PPS) à 0 1 1 1
(bps) 192 6648 6656 6648
Traitement : Chargez (PCT) 0 0 0 0
Avec le processus ou les processus qui sont observés pour avoir surchargé la CPU identifiée, il y a une image plus claire de pourquoi la CPU de haute s'est produite. Pour poursuivre, recherchez les fonctions remplies par le processus identifié. Ceci aidera dedans pour déterminer un plan d'action sur la façon dont traiter le problème. Par exemple - Si le processus est responsable d'un protocole particulier puis vous pouvez vouloir regarder la configuration liée à ce protocole.
Si vous éprouvez toujours des questions connexes CPU, il est recommandé pour entrer en contact avec le TAC pour permettre à un ingénieur pour vous aider à dépanner plus loin. Les étapes ci-dessus à dépanner aideront l'ingénieur à isoler la question plus efficacement.
Dans cet exemple nous nous exécuterons par le processus pour dépanner et essayer au meilleur identifiez une cause principale possible pour la CPU de la haute du routeur. Pour commencer, déterminez quel module est observé pour éprouver la CPU de haute, nous ont la sortie ci-dessous :
Brief de processeur de contrôle d'état du logiciel de plate-forme de Router#show
Moyenne de charge
État 1-Min 5-Min 15-Min d'emplacement
RP0 0.66 0.15 0.05 sain
ESP0 0.00 0.00 0.00 sain
SIP0 0.00 0.00 0.00 sain
Mémoire (kB)
Libre utilisé par total d'état d'emplacement (PCT) (PCT) commis (PCT)
RP0 2009376 1879196 (94%) 130180 (6%) 1432756 sains (71%)
ESP0 2009400 692472 (34%) 1316928 (66%) 472668 sains (24%)
SIP0 471804 284556 (60%) 187248 (40%) 193148 sains (41%)
Utilisation du processeur
Inactif IRQ SIRQ IOwait de système d'utilisateur CPU d'emplacement Nice
RP0 0 57.11 14.42 0.00 0.00 28.25 0.19 0.00
ESP0 0 2.10 17.91 0.00 79.97 0.00 0.00 0.00
SIP0 0 1.20 6.00 0.00 92.80 0.00 0.00 0.00
Car la quantité oisive dans RP0 est très basse, elle suggère une question CPU de haute dans le processeur d'artère. Par conséquent pour nous dépanner plus loin identifierons quel processeur dans le RP est observé pour éprouver la CPU de haute.
Router#show traite la CPU triée
Utilisation du processeur pendant cinq secondes : 84%/36% ; une minute : 34% ; cinq minutes : 9%
PID Runtime(ms) a appelé le processus TTY des uSecs 5Sec 1Min 5Min
experts en logiciel de coup de volée 107 303230 50749 5975 46.69% 18.12% 4.45% 0 IOSXE-RP
63 105617 540091 195 0.23% 0.10% 0.08% 0 tâches IOSD IPC
159 74792 2645991 28 0.15% 0.06% 0.06% 0 thread principaux VRRS
Le 116 53685 169683 316 0.15% 0.05% 0.01% Par-deuxième travail 0
9 305547 26511 11525 0.15% 0.28% 0.16% segment de mémoire de 0 contrôles
188 362507 20979154 17 0.15% 0.15% 0.19% 0 Ti milliseconde d'Ethernets
3 147 186 790 0.07% 0.08% 0.02% 0 exécutifs
2 32126 33935 946 0.07% 0.03% 0.00% 0 Load Meter
446 416 33932 12 0.07% 0.00% 0.00% processus 0 volts continu
164 59945 5261819 11 0.07% 0.04% 0.02% 0 âges de relance d'ARP IP
43 1703 16969 100 0.07% 0.00% 0.00% 0 keepalives M IPC
De cette sortie, il peut observer que tout le pourcentage CPU et pourcentage d'interruption sont supérieur à prévu. Le processus supérieur qui utilise la CPU est « l'expert en logiciel de coup de volée IOSXE-RP » qui est le processus qui traite le trafic pour la CPU RP, donc que nous pouvons examiner plus loin ce trafic qui est donné un coup de volée au RP.
Coup de volée d'infrastructure de logiciel de plate-forme de Router#show
Stats internes d'interface LSMPI :
enabled=0, disabled=0, throttled=0, unthrottled=0, état est prêt
Tampons d'entrée = 90100722
Mémoires tampons de sortie = 100439
compte de rxdone = 90100722
compte de txdone = 100436
Rx aucun compte de particletype = 0
Tx aucun compte de particletype = 0
Txbuf de compte de shadow = 0
Aucun début de paquet = 0
Aucune extrémité de paquet = 0
Stats de baisse de coup de volée :
Mauvaise version 0
Mauvais type 0
A eu l'en-tête 0 de caractéristique
A eu l'en-tête 0 de plate-forme
En-tête de caractéristique manquant 0
Non-concordance commune 0 d'en-tête
Mauvaise longueur totale 0
Mauvaise longueur de paquet 0
Le mauvais réseau a compensé 0
Pas en-tête 0 de coup de volée
Type de lien inconnu 0
Aucun swidb 1
Mauvaise en-tête 0 de caractéristique d'éventail de services étendus
Aucune caractéristique 0 d'éventail de services étendus
Aucune caractéristique 0 SSLVPN
Coup de volée pour nous inconnu 0 de type
Cause de coup de volée hors de la plage 0
Causes de paquet de coup de volée IOSXE-RP :
contrôle 62210226Layer2etpaquets delegs
147 paquets de demande ou de réponse d'ARP
27801234 Pour-nous paquets de données
84426 paquets keepalive RP<->QFP
6 glanez les paquets de contiguïté
1647 Pour-nous paquets de contrôle
Stats de protcol d'ipv4 de contrôle FOR_US :
1647 paquets OSPF
Octets du paquet histogram(500/coffre), taille d'avg dans 92, 56 :
-compte de Dans-compte de PAK-taille
0+ : 90097805 98790
500+ : 0 7
De cette sortie, nous pouvons voir qu'il y a un grand nombre de paquets dans « Pour-nous des paquets de données » qui indique le trafic orienté sur le routeur, ce compteur a été confirmé pour être ont incrémenté de l'observation des plusieurs temps de commande au-dessus de plusieurs minutes. Ceci confirme que la CPU est surchargée par un grand nombre de trafic donné un coup de volée, qui est souvent le trafic d'avion de contrôle. Le trafic d'avion de contrôle peut inclure l'ARP, le SSH, le SNMP, les mises à jour de route (BGP, EIGRP, OSPF) etc. De ces informations, nous pouvons identifier la cause potentielle de la CPU de haute et ceci aide pour dépanner pour la cause principale. Par exemple, une capture de paquet ou un moniteur du trafic différent pourrait être mise en application pour voir le trafic précis donné un coup de volée au RP qui permettrait la cause principale d'être identifié et résolu pour empêcher une question semblable à l'avenir.
Une fois qu'une capture de paquet est terminée, quelques exemples du trafic donné un coup de volée par potentiel est :
Ceci met en valeur comment la cause principale peut être isolée par l'identification de la cause de la CPU de haute, quand elle descend à un niveau de processus individuel. D'ici, le processus individuel ou le protocole peut être analysé en isolation pour l'identifier si c'est une question de configuration, un problème logiciel, une conception de réseaux, ou une pratique destinée.
Le ci-dessous est une liste d'autres commandes utiles supplémentaires d'utiliser et est trié par aux lesquelles le processeur elles associent :