Fehlerbehebung bei hoher CPU-Auslastung durch den HyBridge-Eingangsprozess auf Routern mit ATM-Schnittstellen

Einführung

In diesem Dokument wird erläutert, wie die hohe CPU-Auslastung eines Routers aufgrund des HyBridge-Eingangsprozesses behoben wird. ATM-Schnittstellen können eine große Anzahl von permanenten Virtual Circuits (PVCs) unterstützen, die für die Verwendung von RFC 1483 Bridge-Format Protocol Data Units (PDUs) mit Cisco IOS^® Bridging und Integrated Routing and Bridging (IRB) konfiguriert sind. Dieser Ansatz beruht in hohem Maße auf Broadcasts für die Anbindung von Remote-Benutzern. Mit steigender Anzahl von Remote-Benutzern und PVCs steigt auch die Anzahl der Übertragungen zwischen diesen Benutzern. Unter bestimmten Umständen erzeugen diese Broadcasts eine hohe CPU-Auslastung auf dem Router.

Voraussetzungen

Anforderungen

Für dieses Dokument bestehen keine speziellen Anforderungen.

Konventionen

Weitere Informationen zu Dokumentkonventionen finden Sie unter Cisco Technical Tips Conventions (Technische Tipps zu Konventionen von Cisco).

Standard Bridging-Architektur

Die TRFC 1483 legt fest, dass eine transparente Bridge (die einen für Bridging konfigurierten Cisco Router umfasst) Bridge-Frames überfluten, weiterleiten und filtern kann. Beim Flooding wird ein Frame an alle möglichen geeigneten Ziele kopiert. Eine ATM-Bridge überflutet einen Frame, wenn er den Frame explizit in jeden Virtual Circuit (VC) kopiert, oder wenn ein Point-to-Multipoint-VC verwendet wird.

Bei der Cisco IOS-Standardüberbrückung müssen Frames wie Address Resolution Protocols (ARPs), Broadcasts, Multicasts und Spanning-Tree-Pakete diesen Flooding-Prozess durchlaufen. Die Cisco IOS-Bridging-Logik verarbeitet jedes dieser Pakete:

1. Führt die Liste der in der Bridge-Gruppe konfigurierten Schnittstellen und Subschnittstellen durch.

2. Führt die Liste der VCs durch, die auf den Mitgliedsschnittstellen in der Bridge-Gruppe konfiguriert wurden.

3. Repliziert den Frame auf jeden VC.

Die Cisco IOS-Software-Routinen für die Replikation müssen in einer Schleife ausgeführt werden, um das Paket auf jeder PVC zu duplizieren. Wenn der Router eine große Anzahl an überbrückten PVCs unterstützt, werden die Replikationsroutinen über einen längeren Zeitraum ausgeführt, wodurch die CPU erhöht wird. Eine Erfassung des Befehls show process cpu zeigt einen großen "5sec"-Wert für die HyBridge-Eingabe, der für die Weiterleitung von Paketen verantwortlich ist, die die Switching-Methode der Paketweiterleitung verwenden. Cisco IOS muss Switches verarbeiten, z. B. Pakete wie Spanning Tree Bridge Protocol Data Units (BPDUs), Broadcasts und Multicasts, die nicht schnell geswitcht werden können. Beim Switching von Prozessen kann eine große CPU-Zeit verbraucht werden, da pro Aufruf nur eine begrenzte Anzahl von Paketen verarbeitet wird.

Wenn eine einzige Schnittstelle viele VCs unterstützt, kann die CPU durch eine Überbrückung der VC-Liste überfordert werden. Die Cisco Bug-ID CSCdr1146 löst dieses Problem. Wenn die Bridging-Logik in einer Schleife ausgeführt wird, um die Broadcasts zu replizieren, wird die CPU zeitweise aufgegeben. Die erneute Abfrage der CPU wird auch als Suspendierung der CPU bezeichnet.

Hinweis: Die Konfiguration vieler Subschnittstellen in derselben Bridge-Gruppe kann auch die CPU überlasten.

Typische Symptome

Wenn Ihre Bridge-PVCs zu einer hohen CPU-Auslastung auf dem Router führen, sollten Sie zuerst nach einer hohen Anzahl an Broadcasts auf Ihrer Schnittstelle suchen:

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  

Als Nebeneffekt können Sie eine hohe Anzahl von Ausfällen auf der Schnittstelle sehen. In dieser Situation kann das Problem von einer langsamen Reaktion auf den Router bis hin zur vollständigen Unzugänglichkeit des Routers reichen. Wenn Sie die Schnittstelle herunterfahren oder das Kabel von der ATM-Schnittstelle trennen, sollte der Router wieder angeschlossen werden.

Wenn der Broadcast-Datenverkehr sprunghaft ansteigt, was nur für kurze Zeiträume zu CPU-Spitzen führt, kann das Problem behoben werden, wenn Sie die Warteschlange für den Eingangs-Hold an der Schnittstelle ändern, um die Bursts zu bewältigen. Die Standardgröße für Warteschlangen beträgt 75 Pakete und kann mit dem Befehl hold-queue <queue length> in|out geändert werden. In der Regel darf die Größe der Warteschlange nicht über 150 erhöht werden, da dies zu einer höheren Belastung der CPU auf Prozessebene führt.

Fehlerbehebung

Wenn Probleme bei der hohen CPU-Auslastung durch HyBridge-Eingang auftreten, erfassen Sie diese Ausgabe, wenn Sie sich an das Cisco Technical Assistance Center (TAC) wenden. Verwenden Sie folgende Befehle, um diese Ausgabe zu erfassen:

• show process cpu - Wenn Sie eine hohe CPU-Auslastung feststellen, verwenden Sie den Befehl show process CPU, um den fehlerhaften Prozess zu isolieren. Siehe Fehlerbehebung bei hoher CPU-Auslastung auf Cisco Routern.

• show stapacks {process ID} - Sie können diesen Befehl auch verwenden, um festzustellen, welche Prozesse aktiv sind, und um nach potenziellen Problemen zu suchen. Fügen Sie die Ausgabe dieses Befehls im Output Interpreter Tool ein (nur registrierte Kunden). Nachdem die Prozesse entschlüsselt wurden, können Sie mit dem Software Bug Toolkit nach möglichen Fehlern suchen.

  Hinweis: Sie müssen sich für ein CCO-Konto registrieren und angemeldet sein, um beide Tools verwenden zu können.

• show bridge verbose - Mit diesem Befehl show können Sie bestimmen, wie viele Subschnittstellen in derselben Bridge-Gruppe eingefügt werden und ob die Schnittstelle überlastet ist.

   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

Fahren Sie darüber hinaus die Bridge Group Virtual Interface (BVI) herunter, und überwachen Sie die CPU-Auslastung mit mehreren Erfassen der Ausgabe über den Befehl show process cpu.

Workarounds

Cisco empfiehlt die Implementierung dieser Workarounds als Lösung für eine hohe CPU-Auslastung, die durch das Standard-Bridging verursacht wird:

• Implementieren Sie die Cisco IOS x Digital Subscriber Line Bridge-Funktion, mit der der Router für intelligente Bridge-Flooding über Subscriber-Richtlinien konfiguriert wird. Sperren Sie aktiv ARPs, Broadcasts, Multicasts und Spanning-Tree-BPDUs.

• Brechen Sie die VCs an mehreren Multipoint-Schnittstellen auf, von denen jede über ein anderes IP-Netzwerk verfügt.

• Konfigurieren Sie den Alterungs-Timer von IP ARP- und Bridging-Tabelleneinträgen auf denselben Wert. Andernfalls können Sie unnötige Überflutungen des Datenverkehrs in Ihren Links sehen. Das standardmäßige ARP-Timeout beträgt vier Stunden. Die voreingestellte Bridge-Alterungszeit beträgt 10 Minuten. Bei Remote-Benutzern, die 10 Minuten lang im Leerlauf waren, entfernt der Router nur den Eintrag der Bridge-Tabelle des Benutzers und behält den Eintrag der ARP-Tabelle bei. Wenn der Router Datenverkehr Downstream an den Remote-Benutzer senden muss, überprüft er die ARP-Tabelle und sucht einen gültigen Eintrag, um auf die MAC-Adresse zu verweisen. Wenn der Router die Bridge-Tabelle auf diese MAC-Adresse überprüft und diese nicht findet, überflutet der Router den Datenverkehr alle VCs in der Bridge-Gruppe. Verwenden Sie diese Befehle, um die Alterungszeiten für ARP und Bridge-Tabellen festzulegen.

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

• Ersetzen Sie Standard Bridging und IRB durch Routed Bridge Encapsulation (RBE) oder überbrückte PVCs an der Head-End-ATM-Schnittstelle. RBE erhöht die Weiterleitungsleistung, da es Cisco Express Forwarding (CEF) unterstützt und IP-Pakete nur über eine Routing-Entscheidung und nicht über eine Bridging-Entscheidung ausführt. In der Train 12.1(1)T können die Pakete per Software gewechselt werden. Wenn ja, wird die folgende Fehlermeldung angezeigt:

  %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  

  Das Problem ist im CSCdr37618 dokumentiert, und die Lösung ist ein Upgrade auf 12.2 Mainline. Weitere Informationen finden Sie unter Routed Bridge Encapsulation Baseline Architecture and Configuring Bridged-Style PVCs on ATM Interfaces in the GSR and 7500 Series (Grundarchitektur der Routed Bridge Encapsulation und Konfiguration von Bridge-Style-PVCs auf ATM-Schnittstellen.

Zugehörige Informationen

• Fehlerbehebung bei hoher CPU-Auslastung auf Cisco Routern
• Technischer Support und Dokumentation - Cisco Systems
• Tools und Dienstprogramme - Cisco Systems

Revisionsverlauf