Problemen oplossen met hoge CPU’s op ASR 1000 Series router

Inleiding

Dit document beschrijft hoe u problemen met een hoge CPU-instelling kunt oplossen bij een ASR1000 Series router.

Voorwaarden

Vereisten

Cisco raadt u aan de ASR 1000-architectuur te begrijpen om dit document te interpreteren en te gebruiken. 

Beschrijving

Een hoge CPU op een Cisco-router kan worden gedefinieerd als de toestand waarin het CPU-gebruik op de router hoger is dan het normale gebruik. In sommige scenario's wordt het toegenomen CPU-gebruik verwacht terwijl het in andere scenario's op een probleem kan wijzen. Het tijdelijke gebruik van hoge CPU op de router door netwerkverandering of configuratieverandering kan worden genegeerd en wordt verwacht gedrag.

Een router die gedurende langere perioden een hoog CPU-gebruik ervaart zonder veranderingen in het netwerk of de configuratie, is echter ongebruikelijk en moet worden geanalyseerd. Daarom is de CPU bij overgebruik niet in staat om alle andere processen actief te ondersteunen, wat resulteert in een langzame opdrachtregel, een controlelampje, pakketdruppels en het falen van de services.

De oorzaken van een hoge CPU zijn:

1. Besturingsplatform CPU ontvangt te veel puntverkeer
2. Een proces dat zich onverwachts gedraagt en tot overbenutting in CPU’s leidt
3. De processor van het datacenter is te veel gebruikt/te veel geabonneerd
4. Teveel processoronderbrekingen

Hoge CPU is niet altijd een ASR 1000 Series-routerprobleem omdat het gebruik van router CPU’s rechtstreeks evenredig is met de lading op de router.  Als er bijvoorbeeld een netwerkwijziging is, veroorzaakt dit een grote hoeveelheid besturingsplane verkeer omdat het netwerk opnieuw samenkomt. Daarom moeten we de grondoorzaak van de CPU-overbenutting bepalen om te bepalen of er sprake is van een verwacht gedrag of een probleem.

Hieronder vindt u een diagram dat in detail aangeeft hoe u een probleem met een hoge CPU-instelling kunt oplossen:

Stappen voor probleemoplossing

Stap 1 - Identificeer de module met een hoge CPU

ASR1000 heeft verschillende CPU’s voor de verschillende modules. Daarom moeten we zien welke module groter is dan normaal. Dit kan worden gezien door de inactiviteitwaarde, terwijl hoe lager de inactiviteitwaarde, hoe hoger het CPU-gebruik van die module is. Deze verschillende CPU’s weerspiegelen allemaal het besturingsplane van de modules.

Bepaal welke module binnen het apparaat is waargenomen voor een hoge CPU. Is het de RP, ESP of SIP met onderstaande opdracht

   samenvatting van de platformsoftware status control-processor

Raadpleeg de onderstaande uitvoer om de gemarkeerde kolom te bekijken

Als de RP een lage inactiviteitwaarde heeft, gaat u vervolgens over naar Stap 2 Punt 1

Als het ESP een lage inactiviteitwaarde heeft, gaat u verder naar Stap 3 Punt 2 

Als de SIP een lage inactiviteitwaarde heeft, gaat u verder naar Stap 4 Punt 3

   Routerberichten#show platform software status control-processor kort

   Gemiddelde lading
   Status 1-Min. 5-Min. 15-Min
   RP0 Gezonde 0,00 0,02 0,00
   ESP0 Gezonde 0,01 0,02 0,00
   SIP0 Gezonde 0,00 0,01 0,00

   Geheugen (kB)
   Status TOTAAL GEBRUIKTE (PTC) Vrij (PFT) Committed (PCT)-status
   RP0 Gezonde 2009376 1879196 (94%) 130180 (6%) 1432748 (71%)
   ESP0 Gezonde 2009400 692100 (34%) 1317300 (66%) 472536 (24%)
   SIP0 Gezonde 471804 28424 (60%) 187380 (40%) 193148 (41%)

   CPU-gebruik
   Inactiviteitensysteem met CPU-systeem -vriendelijk inactiviteitstimer IRQ-SIRQ-wachttijd
   RP0 0 2,59 2,49 0,00 94,80 0,00 0,09 0,00
   ESP0 2,30 17,90 0,00 79,80 0,00 0,00 0,00 0,00
   SIP 0 1,29 4,19 0,00 94,41 0,09 0,00 0,00

Als de inactiviteitwaarden allemaal relatief hoog zijn, is dit mogelijk geen probleem met het bedieningspaneel. Voor het oplossen van problemen met het gegevensvliegtuig moet het QFP van het ESP worden gevolgd. Symptomen van "hoge CPU" kunnen nog steeds worden waargenomen door een te veel gebruikt QFP, dat geen hoge CPU op de besturingsplaneprocessors tot gevolg zal hebben. Ga verder naar STAP 6.

Stap 2 - Analyse van de module

• routeprocessor

Bevestig in de RP welke processor een hoog CPU-gebruik heeft met onderstaande opdracht. Is het het Linux-proces of de IOS?

   RP actieve monitor voor platform-softwareproces

Als IOS CPU-percentage hoog is (linux_iosd-afbeelding), is het dan de RP IOS. Ga verder naar STAP 3

Als het CPU-percentage van andere processen hoog is, is dit waarschijnlijk het Linux-proces. Ga verder naar STAP 4

• Geïntegreerde servicesprocessor

Bevestig binnen het ESP als geconstateerd wordt dat de besturingssysteemvliegtuigprocessor een hoog CPU-gebruik heeft. Is het de FECP?

   

   actieve monitor voor platform-softwareprocessleuf

Als de processen hoog zijn, is het de FECP, en gaat u vervolgens verder naar STAP 5

Indien dit niet het FECP is, is het geen met het ESP verband houdende kwesties in verband met de processen van het bedieningspaneel. Als symptomen zoals netwerklatentie of wachtrijdruppels nog steeds worden waargenomen, moet het gegevensvlak mogelijk worden herzien voor overgebruik. Ga verder naar STAP 6

• SPA-interfaceprocessor

Als wordt vastgesteld dat de SIP een hoog CPU-gebruik heeft, wordt er bij de IOCP een hoge CPU waargenomen. Bepaal welk proces of processen binnen de IOCP een hoog CPU-gebruik hebben.

Voer een pakketvastlegging uit en identificeer welk verkeer hoger is dan normaal en welke processen gekoppeld zijn aan dit type verkeer. Ga verder naar STAP 7

Stap 3 - IOS-processen

Raadpleeg de onderstaande uitvoer, het eerste percentage is het totale CPU-gebruik en het tweede percentage is het interrupte CPU-gebruik, dat de hoeveelheid CPU is die wordt gebruikt voor het verwerken van gepunte pakketten.

Als het percentage onderbroken is hoog, betekent dit dat een grote hoeveelheid verkeer wordt gestraft naar de RP (dit kan worden bevestigd met het punt van de opdrachtshow platform software infrastructuur)

Als het percentage onderbroken is, maar de totale CPU hoog is, bestaat er een proces of processen dat gedurende een langere periode zal worden waargenomen om de CPU te gebruiken.

Bevestig binnen IOS welke proces of processen worden waargenomen met een hoog CPU-gebruik met de onderstaande opdracht.

   toon processen gesorteerd cpu

Geef aan welk percentage hoog is (totale CPU of onderbreek CPU) en identificeer desgewenst het afzonderlijke proces/de afzonderlijke processen. Ga verder naar STAP 7

   Afgesorteerde processen van router#show

   CPU-gebruik gedurende vijf seconden: 0%/0%; één minuut: 1%; vijf minuten: 1%

   PID-uitvoertijd(en) Verworven secs 5 seconden: 1 min. 5 min.

   PID-uitvoertijd(en) Verworven secs 5 seconden: 1 min. 5 min.

   188 8143 434758 18 0,15% 0,18% 0,19% 19% Ethernet Msec Ti

   515 380 7050 53 0,07% 0,00% 0,00% 0,00% SBC hoofdproces

     3 2154 215 10018 0,07% 0,00% 0,19% 0,00%            

   380 1783 55002 32 0,07% 0,06% 0,06% 0,06% 0 MMA DB TIMER    

    63 3132 11143 281 0,07% 0,07% 0,07% 0,07% 0 IOSD ipc taak   

     5 1 2 500 0,00% 0,00% 0,00% 0,00% IPC ISSU Dispatc

     6 19 12 1583 0,00% 0,00% 0,00% 0,00% RF Slave Main Th

     8 0 1 0,00% 0,00% 0,00% 0,00% 0 RO Meldende timers

     7 0 1 0 0,00% 0,00% 0,00% 0,00% EDDRI_MAIN      

    10 6 75 80 0,00% 0,00% 0,00% 0,00% Pool Manager    

     9 5671 538 10540 0,00% 0,14% 0,12% 0 Controleer de kranen     

Stap 4 - Linux-processen

Als IOS wordt waargenomen dat de CPU is overschreden, moeten we het CPU-gebruik voor het individuele linux-proces observeren. Deze processen zijn de andere processen die in de lijst van de actieve monitor van het platform-softwareproces worden opgenomen. Identificeer welk proces of processen worden waargenomen om een hoge CPU te ervaren en ga vervolgens over naar STAP 7.

Stap 5 - FECP-processen

Als een proces of processen hoog zijn, is het waarschijnlijk dat het de processen binnen de FECP zijn die verantwoordelijk zijn voor het hoge CPU-gebruik, gaat u naar STAP 7

Stap 6 - Gebruik van QFP’s

De Quantum Flow Processor is de verzendende ASIC. Om de belasting op de verzendingsmotor te bepalen, kan het QFP worden gevolgd. De onderstaande opdracht toont de invoer- en uitvoerpakketten (prioriteit en niet-prioriteit) in pakketten per seconde, en bits per seconde. De laatste lijn geeft de totale hoeveelheid CPU-lading weer door pakkettransport in een percentage.

   tonen platform hardware qfp actief datapath-gebruik

Identificeer of de input of output hoog zijn, en bekijk de proceslading en ga vervolgens naar STAP 7

   Actieve datapath-gebruik van routerplatform qfp

     CPP 0: Subdev 0 5 seconden 1 min 5 min 60 min

    Invoer:  Prioriteit (pps) 0 0 0 0

                     (Gbps) 208 176 176 176

        Niet-prioritair (pps) 0 2 2 2

                     (Gbps) 64 784 784 784

               Totaal (p's) 0 2 2 2

                     (Gbps) 272 960 960 960

    Uitvoer: Prioriteit (pps) 0 0 0 0

                     (Gbps) 192 160 160 160

        Niet-prioriteit (pps) 0 1 1 1

                     (Gbps) 6488 6496 6488

              Totaal (p's) 0 1 1

                     (Gbps) 192 648 6656 6648

    Verwerking: Belading (pct) 0 0 0 0

Stap 7 - Bepaal de oorzaak van de wortel en identificeer de oplossing

Wanneer het proces of de processen waarvan wordt vastgesteld dat de CPU is overschreden, worden geïdentificeerd, is er een duidelijker beeld van de reden waarom een hoge CPU is ontstaan. Onderzoek de functies die door het geïdentificeerde proces worden uitgevoerd. Dit zal helpen bij het bepalen van een actieplan voor de aanpak van het probleem. Bijvoorbeeld - Als het proces verantwoordelijk is voor een bepaald protocol, kunt u de configuratie met betrekking tot dit protocol bekijken.

Als u nog steeds problemen hebt met CPU’s, wordt u aangeraden contact op te nemen met TAC om een ingenieur te helpen bij de verdere oplossing van uw probleem. De bovenstaande stappen om een probleem op te lossen zullen de engineer helpen het probleem efficiënter te isoleren.

Voorbeeld probleemoplossing

In dit voorbeeld zullen we door het proces om problemen op te lossen lopen en proberen om best een mogelijke diepere oorzaak voor de hoge CPU van de router te identificeren. Om te beginnen, bepalen welke module wordt waargenomen om de hoge CPU te ervaren:  

   Routerberichten#show platform software status control-processor kort
   Gemiddelde lading
   Status 1-Min. 5-Min. 15-Min
   RP0 Gezonde 0,66 0,15 0,05
   ESP0 Gezonde 0,00 0,00 0,00
   SIP0 Gezonde 0,00 0,00 0,00

   Geheugen (kB)
   Status TOTAAL GEBRUIKTE (PTC) Vrij (PFT) Committed (PCT)-status
   RP0 Gezonde 2009376 1879196 (94%) 130180 (6%) 1432756 (71%)
   ESP0 Gezonde 2009400 692472 (34%) 1316928 (66%) 472668 (24%)
   SIP0 Gezonde 471804 28456 (60%) 187248 (40%) 193148 (41%)

   CPU-gebruik
   IQ SIRQ-IOware sleuven voor CPU-gebruikerssysteem
   RP0 0 57.11 14.42 0.00 0.00 28.25 0.19 0.00
   ESP0 2.10 17.91 0.00 79.97 0.00 0.00 0.00
   SIP 0 1.20 6.00 0.00 92.80 0.00 0.00 0.00 0.00

Aangezien het inactiviteitbedrag binnen RP0 zeer laag is, stelt het een hoog CPU-probleem binnen de routeprocessor voor. Om de problemen op te lossen zullen we daarom identificeren welke processor binnen de RP wordt waargenomen om een hoge CPU te ervaren.

   Afgesorteerde processen van router#show
   CPU-gebruik gedurende vijf seconden: 84%/36%; één minuut: 34%; vijf minuten: 9%
   PID-uitvoertijd(en) Verworven secs 5 seconden: 1 min. 5 min.
   107 303230 50749 5975 46,69% 18,12% 4,45% 0 IOSXE-RP punt Se
    63 105617 540091 195 0,23% 0,10% 0,08% 0 IOSD ipc taak
   159 74792 2645991 28 0,15% 0,06% 0,06% 0,06% 0 VRR-hoofden
   116 53685 169683 316 0,15% 0,05% 0,01% 0 per seconde banen
     9 305547 26511 11525 0,15% 0,28% 0,16% 0 Controleer de kranen
   188 362507 20979154 17 0,15% 0,15% 0,19% Ethernet Msec Ti
     3 147 186 790 0,07% 0,08% 0,02% 0,02%
     2 32126 33935 946 0,07% 0,03% 0,00% 0-Laadmeter
   446 416 33932 12 0,07% 0,00% 0,00% VDC-proces
   164 5945 5261819 11 0,07% 0,04% 0,02% 0,02% RJsDRsDpArD000
    43 1703 16969 100 0,07% 0,00% 0,00% 0,00% 0,00% 0,00% 0,00% Levensonderhoud M  

Bij deze uitvoer kan worden opgemerkt dat het totale CPU-percentage en het percentage waarmee de taak wordt onderbroken hoger zijn dan verwacht. Het bovenste proces dat de CPU gebruikt, is het "IOSXE-RP Punt Se", het proces dat het verkeer voor de RP CPU’s verwerkt, zodat we verder in dit verkeer kunnen kijken dat naar de RP wordt gestraft.

  

   Routerberichten voor platform-softwareinfrastructuur
   LSMPI interface-interne status:
   enabled=0, disability=0, throttled=0, unthrottled=0, state is klaar
   Invoerbuffers = 90100722
   Uitvoerbuffers = 100439
   aantal overschrijvingen = 90100722
   aantal giften = 100436
   Rx geen deeltjesaantal = 0
   Tx geen deeltjesaantal = 0
   Txbuf van schaduwtelling = 0
   Geen begin van pakket = 0
   Geen uiteinde van pakket = 0
   Statistieken van de punten:
   Slechte versie 0
   Slecht type 0
   Functieheader 0
   had een platformkop 0
   Functieheader ontbreekt 0
   Gemeenschappelijke fout kop 0
   Slechte totale lengte 0
   Slechte pakketlengte 0
   Slechte netwerkoffset 0
   Niet punt header 0
   Onbekend link type 0
   Geen swidb 1
   Slechte ESS-functieknop 0
   Geen ESS-functie 0
   Geen SSLVPN-functie 0
   Punt voor VS type onbekend 0
   Punt buiten bereik 0
   IOSXE-RP pakketoorzaken:
       62210/226 Layer 26-controle en legacy-pakketten
            147 ARP-aanvraag- of antwoordpakketten
       2780/1234 Voor-us gegevenspakketten
          8426 RP<-S>QFP hoogwaardige pakketten
              6 Glein nabijheidspakketten
           1647 Voor-us bedieningspaneel

       FOR_US Control IPv4-protocol:
              1647 OSPF-pakketten
   Packet histogram (500 bytes/bin), gemiddelde grootte in 92, van de 56:
    Aantal in aantal getallen van het Pak-formaat
         0+:    90097805 98790
       meer dan 500:           0 7

Van deze uitvoer kunnen we zien dat er een grote hoeveelheid pakketten in de "Voor-us gegevenspakketten" zit die verkeer op de router aangeven. Er is bevestigd dat deze teller na observatie van de opdracht meerdere malen in enkele minuten is verhoogd. Dit bevestigt dat de CPU wordt overgebruikt door een grote hoeveelheid puntenverkeer, dat dikwijls het vliegtuigverkeer controleert. Het verkeer van het controlevliegtuig kan ARP, SSH, SNMP, de updates van de Route (BGP, DHCP, OSPF) enz. omvatten. Op basis van deze informatie zijn we in staat de mogelijke oorzaak van de hoge CPU’s te identificeren en deze assisteert bij het oplossen van problemen voor de basisoorzaak. Een pakketvastlegging of een monitor van verschillend verkeer zou bijvoorbeeld kunnen worden geïmplementeerd om het exacte verkeer te zien dat aan de RP wordt gestraft zodat de worteloorzaak kan worden geïdentificeerd en opgelost om een soortgelijk probleem in de toekomst te voorkomen.

Zodra een pakketvastlegging is voltooid, zijn er een aantal voorbeelden van mogelijk puntenverkeer:

• ARP: Dit zou het gevolg kunnen zijn van een excessief aantal ARP verzoeken, die zouden voorkomen als de meerdere IP adressen ARP verzoeken door de configuratie van een IP route naar een uitzending zouden moeten verzenden. Dit zou ook te wijten kunnen zijn aan gespoelde items van de ARP-tabel en zal moeten worden vrijgegeven op basis van de MAC-adreswaarden die zijn afgeleid, of interfaces op de omhoog/omlaag.

• SSH: Dit zou hoge CPU kunnen veroorzaken door een groot showopdracht (show tech-support) of wanneer veel debug-opdrachten zijn ingeschakeld, waardoor veel CLI-bestanden tijdens de SSH-sessie moeten worden verzonden.

• SNMP: Dit kan zijn veroorzaakt door de SNMP-agent die een lange tijd nodig heeft om een verzoek te verwerken en daardoor de hoge CPU’s veroorzaakt. Vaak zijn twee vermoedelijke oorzaken MIBs die worden gepolst, of route en/of ARP tabellen die door de NMS worden gepolst.

• Routeupdates: Vaak zal een toevloed van routeupdates te wijten zijn aan een herconvergentie van het netwerk of aan een verbindingsflaps. Dit zou routes kunnen aangeven die binnen het netwerk omlaag gaan, of hele apparaten die omlaag gaan die het netwerk dwingen om de beste routes te converteren en opnieuw te berekenen, wat afhangt van welke routingprotocol in gebruik is.

Dit benadrukt hoe de grondoorzaak kan worden geïsoleerd door identificatie van de oorzaak van de hoge CPU, wanneer deze op een individueel procesniveau komt. Vanaf hier kan het individuele proces of protocol afzonderlijk worden geanalyseerd om te bepalen of het een configuratieprobleem, softwarekwestie, netwerkontwerp of bedoelde praktijk is.

Aanvullende opdrachten

Hieronder staat een lijst met andere nuttige opdrachten die moeten worden gebruikt en die zijn gesorteerd op de processor waarop ze betrekking hebben:

routeprocessor

• <historie van snijpad tonen>
  • Hier vindt u een grafiek van de CPU-geschiedenis van de afgelopen 60 seconden, minuten en 72 uur
• <toon proces proces_ID>
  • Gedetailleerde informatie over individuele procesgeheugen- en CPU-toewijzingen
• <showplatform softwareinfrastructuur opgeven>
  • Bevat informatie over al het verkeer dat naar de RP wordt gestraft
• <show platform software status control-processorbrief>
  • Bijzonderheden over de lading en de "gezondheid" van de CPU, en bijzonderheden over de geheugen- en modulestatistieken
• <show platform softwareprocessleuf r0|r1-monitor>
  • Bijzonderheden over de verschillende processen en de toewijzingen van CPU’s en geheugen op de geselecteerde module
• <monitor-softwareproces></r1>
  • Verstrekt een levend voer dat updates van de processen terwijl zij de CPU gebruiken
  • Vereist dat de opdracht "terminal-type" eerst wordt ingevoerd in de mondiale configuratiemodus zodat deze correct werkt

Geïntegreerde servicesprocessor

• <show platform software proceslijst fp actieve samenvatting tonen>
  • Details de samenvatting van alle processen die op de CPU worden uitgevoerd, evenals de gemiddelde lading
• <show platform software processleuf voor 0|f1-monitor>
  • Bijzonderheden over de verschillende processen en de toewijzingen van CPU’s en geheugen op de geselecteerde module
• <monitor-softwareproces f0|f1>
  • Biedt een live feed die updates van de processen zoals zij de CPU gebruiken
  • Vereist dat de opdracht "terminal-type" eerst wordt ingevoerd in de mondiale configuratiemodus zodat deze correct werkt