In diesem Dokument wird erläutert, wie die Ausgabe der show controller fab queue- und show controller tofab queue-Befehle gelesen wird. Sie bietet außerdem einen detaillierten Überblick über die zugrunde liegende Architektur der Cisco Internet Router der Serie 12000, die sich auf diese speziellen Warteschlangen bezieht.
Weitere Informationen zu Dokumentkonventionen finden Sie in den Cisco Technical Tips Conventions.
Für dieses Dokument bestehen keine besonderen Voraussetzungen.
Die Informationen in diesem Dokument basieren auf:
Der Cisco Internet Router der Serie 1200
Alle Versionen der Cisco IOS© Software
Die in diesem Dokument enthaltenen Informationen wurden aus Geräten in einer bestimmten Laborumgebung erstellt. Alle in diesem Dokument verwendeten Geräte haben mit einer leeren (Standard-)Konfiguration begonnen. Wenn Sie in einem Live-Netzwerk arbeiten, stellen Sie sicher, dass Sie die potenziellen Auswirkungen eines Befehls verstehen, bevor Sie es verwenden.
Jede Linecard (LC) auf einem Cisco Internet Router der Serie 12000 verfügt über zwei Speichertypen:
Route- oder Prozessorspeicher (Dynamic RAM - DRAM): Dieser Speicher ermöglicht es hauptsächlich dem integrierten Prozessor, Cisco IOS-Software auszuführen und Netzwerkrouting-Tabellen (Forwarding Information Base - FIB, Adjacency) zu speichern.
Paketspeicher (Synchroner dynamischer RAM - SDRAM): Der Linecard-Paketspeicher speichert vorübergehend Datenpakete, die auf Switching-Entscheidungen des Line Card-Prozessors warten.
Dieses Dokument konzentriert sich ausschließlich auf den Paketspeicher, der in zwei Banken unterteilt ist: ToFab und FrFab (zum Fabric und vom Fabric). Der ToFab-Speicher wird für Pakete verwendet, die an einer der Schnittstellen des LCs zur Fabric kommen, während der FrFab-Speicher für Pakete verwendet wird, die eine Schnittstelle des LC aus der Fabric auslösen.
Die Warteschlangen Tofab und Fab sind die wichtigsten Konzepte, die Sie verstehen sollten, um die Fehler von ignorierten Paketen auf dem Cisco Internet Router der Serie 12000 effizient zu beheben. Weitere Informationen finden Sie unter Problembehandlung bei ignorierten Paketen und Speicherverlusten auf dem Cisco Internet Router der Serie 12000.
Hinweis: "ToFab" (Richtung Fabric) und "Rx" (vom Router empfangen) sind zwei verschiedene Namen für dieselbe Sache, ebenso "FrFab" (vom Fabric) und "Tx" (vom Router übertragen). So wird beispielsweise der ToFab Buffer Management ASIC (BMA) auch als RxBMA bezeichnet. In diesem Dokument wird die ToFab/FrFab-Konvention verwendet, aber möglicherweise wird die Rx/TX-Nomenklatur an anderer Stelle verwendet.
Der Zugriff auf den Paketspeicher erfolgt über den Buffer Management ASIC (BMA). Die BMA stellt der Linecard Funktionen für Paket-Puffer und Puffer-Warteschlangen-Management zur Verfügung. Alle Pakete durchlaufen die BMA zweimal - einmal ein- und ausgehend. Anders ausgedrückt: Pakete werden auf einem physischen Layer-Schnittstellenmodul (PLIM) eingehen, eine kurze Zeit in SDRAM-Puffern verbringen, dann aus den Puffern ausgelesen und an das Fabric Interface ASIC (FIA)-Modul geliefert. Hier werden sie in Cisco Zellen segmentiert und an die Switch-Fabric übertragen. Die Pakete werden dann von der Switch Fabric Interface ASIC auf der Ausgangs-Linecard empfangen. Sie werden wieder zusammengebaut, in SDRAM-Puffer, dann in PLIM, und schließlich in das Kabel gesendet.
Die Cisco IOS-Software implementiert einen Algorithmus zur Pufferung, der SDRAM in verschiedene Puffer unterteilt. Die GRP und andere Quellen stellen Anweisungen zur Carving-Funktion der Linecard bereit, die dann die Anweisungen ausführt. Es gibt verschiedene Arten von Carves. So erstellt beispielsweise eine einfache Carve einen Pool von Puffern gleicher Größe, während eine komplexe Carve mehrere Pools unterschiedlicher Größe erstellt, wobei jeder Pool Puffer derselben Größe enthält.
Alle Puffer gleicher Größe sind in einem Pool zusammengefasst. Ein Pool ist immer für die IPC-Nutzung (Inter-Process Communication) reserviert. Jeder zugewiesene statische Warteschlangen-RAM (QSRAM) wird mit dem Warteschlangenkopf, dem Schlange, der Länge, dem Längenschwelle, den zugeordneten Pufferadressen im SDRAM und dem nächsten Warteschlangenelement aktualisiert.
Die folgenden sequenziellen Bedingungen lösen eine Puffer-Carving auf einer Linecard aus:
Bootload über den Maintenance BUS (MBUS) - Einfaches Carve-Gespräch mit Carve-Puffern zum Herunterladen des Cisco IOS Software-Image.
Cisco IOS Software-Image vorhanden - LC Simple Carve Call, um IPC (Inter-Process Communication) zu aktivieren, sodass die GRP IPCs verwenden kann, um den LCs die anfängliche Carve-Spezifikation zu geben. Alle SDRAMs, die zum Carving zur Verfügung stehen, sind vorhanden.
Sobald IPC aktiviert ist - Über IPCs kann die GRP eine LC-komplexe Carve mehrmals aufrufen, um den gesamten SDRAM dynamisch zu empfangen.
Eine manuelle Konfiguration oder Änderung der MTU (Maximum Transmission Unit) auf einer Schnittstelle bewirkt, dass der Speicher zurückgespeichert wird. FrFab-Warteschlangen werden bis zur maximalen MTU des gesamten Systems gegliedert, während die ToFab-Warteschlangen bis zur maximalen MTU der jeweiligen Linecard unterteilt werden.
Hinweis: Es wird nur eine Änderung der maximalen MTU für die Linecard (ToFab-Warteschlangen) oder eine Änderung der maximalen MTU für das gesamte System (FrFab-Warteschlangen) vorgenommen. Wenn beispielsweise die MTU von 1500 auf 4470 geändert wird, ändert sich nichts, wenn auf dieser Linecard (ToFab-Warteschlangen) oder im gesamten System (FrFab-Warteschlangen) bereits eine Schnittstelle mit MTU 4470 vorhanden ist.
Sehen Sie sich das folgende Beispiel an:
Router#attach 1 Entering Console for 1 Port Packet Over SONET OC-48c/STM-16 in Slot: 1 Type "exit" to end this session Press RETURN to get started! LC-Slot1>enable LC-Slot1#show controllers tofab queues Carve information for ToFab buffers SDRAM size: 268435456 bytes, address: 30000000, carve base: 30019100 268332800 bytes carve size, 4 SDRAM bank(s), 16384 bytes SDRAM pagesize, 2 carve(s) max buffer data size 4544 bytes, min buffer data size 80 bytes 262140/262140 buffers specified/carved 240637152/240637152 bytes sum buffer sizes specified/carved Qnum Head Tail #Qelem LenThresh ---- ---- ---- ------ --------- 4 non-IPC free queues: 115254/115254 (buffers specified/carved), 43.96%, 80 byte data size 1 201 115454 115254 262143 81202/81202 (buffers specified/carved), 30.97%, 608 byte data size 2 115455 196656 81202 262143 41910/41910 (buffers specified/carved), 15.98%, 1568 byte data size 3 196657 238566 41910 262143 23574/23574 (buffers specified/carved), 8.99%, 4544 byte data size 4 238567 262140 23574 262143 IPC Queue: 200/200 (buffers specified/carved), 0.7%, 4112 byte data size 30 131 130 200 262143 Raw Queue: 31 0 0 0 65535 ToFab Queues: Dest Slot 0 0 0 0 262143 1 0 0 0 262143 2 0 0 0 262143 3 0 0 0 262143 4 0 0 0 262143 5 0 0 0 262143 6 0 0 0 262143 7 0 0 0 262143 8 0 0 0 262143 9 0 0 0 262143 10 0 0 0 262143 11 0 0 0 262143 12 0 0 0 262143 13 0 0 0 262143 14 0 0 0 262143 15 0 0 0 262143 Multicast 0 0 0 262143
Sie können sehen, dass seit der Installation dieser Linecard zwei Carves vorhanden sind und dass es vier Pools gibt: 80, 608, 1568 und 4544.
Ändern Sie jetzt die MTU auf einer Schnittstelle, die zu dieser Linecard gehört:
Router(config)#interface pos1/0 Router(config-if)#mtu ? <64-18020> MTU size in bytes Router(config-if)#mtu 2000
Stellen Sie jetzt eine Verbindung zum LC her, und überprüfen Sie, was sich geändert hat:
LC-Slot1#show control tofab queue Carve information for ToFab buffers SDRAM size: 268435456 bytes, address: 30000000, carve base: 30019100 268332800 bytes carve size, 4 SDRAM bank(s), 16384 bytes SDRAM pagesize, 3 carve(s) max buffer data size 4112 bytes, min buffer data size 80 bytes 262142/262142 buffers specified/carved 247054400/247054400 bytes sum buffer sizes specified/carved Qnum Head Tail #Qelem LenThresh ---- ---- ---- ------ --------- 4 non-IPC free queues: 91680/91680 (buffers specified/carved), 34.97%, 80 byte data size 1 202 201 91680 262143 65485/65485 (buffers specified/carved), 24.98%, 608 byte data size 2 91884 91883 65485 262143 49769/49769 (buffers specified/carved), 18.98%, 1568 byte data size 3 157366 207134 49769 262143 55008/55008 (buffers specified/carved), 20.98%, 2048 byte data size 4 207135 262142 55008 262143 IPC Queue: 200/200 (buffers specified/carved), 0.7%, 4112 byte data size 30 118 117 200 262143 Raw Queue: 31 206 205 0 65535 ToFab Queues: Dest Slot 0 0 0 0 262143 1 0 0 0 262143 2 0 0 0 262143 3 0 0 0 262143 4 0 0 0 262143 5 0 0 0 262143 6 0 0 0 262143 7 206 205 0 262143 8 0 0 0 262143 9 0 0 0 262143 10 0 0 0 262143 11 0 0 0 262143 12 0 0 0 262143 13 0 0 0 262143 14 0 0 0 262143 15 0 0 0 262143 Multicast 0 0 0 262143
Es gibt jetzt drei Carves, und die maximale Puffergröße für die Nicht-IPC-Warteschlange beträgt 2048 Byte statt 4544.
Die FrFab-Warteschlangen bleiben unverändert:
LC-Slot1#show controllers frfab queues Carve information for FrFab buffers SDRAM size: 268435456 bytes, address: 20000000, carve base: 2039D100 264646400 bytes carve size, 4 SDRAM bank(s), 16384 bytes SDRAM pagesize, 3 carve(s) max buffer data size 9248 bytes, min buffer data size 80 bytes 251927/251927 buffers specified/carved 209883344/209883344 bytes sum buffer sizes specified/carved Qnum Head Tail #Qelem LenThresh ---- ---- ---- ------ --------- 6 non-IPC free queues: 123349/123349 (buffers specified/carved), 48.96%, 80 byte data size 1 210 209 123349 262143 75519/75519 (buffers specified/carved), 29.97%, 608 byte data size 2 123552 123551 75519 262143 37759/37759 (buffers specified/carved), 14.98%, 1568 byte data size 3 199069 236827 37759 262143 2516/2516 (buffers specified/carved), 0.99%, 2048 byte data size 4 236828 239343 2516 262143 7551/7551 (buffers specified/carved), 2.99%, 4544 byte data size 5 239344 246894 7551 262143 5033/5033 (buffers specified/carved), 1.99%, 9248 byte data size 6 246895 251927 5033 262143 IPC Queue: 200/200 (buffers specified/carved), 0.7%, 4112 byte data size 30 52 51 200 262143 Multicast Raw Queue: 29 0 0 0 62981 Raw Queue: 31 52 51 0 251928 Interface Queues: 0 210 209 0 262143
Die maximale Puffergröße beträgt 9.248 Byte. Konfigurieren Sie jetzt eine MTU von 10.000 auf einer anderen Schnittstelle auf einer anderen Karte:
Router(config-if)#interface pos5/0 Router(config-if)#mtu ? <64-18020> MTU size in bytes Router(config-if)#mtu 10000 LC-Slot1#show contr frfab queues Carve information for FrFab buffers SDRAM size: 268435456 bytes, address: 20000000, carve base: 2039D100 264646400 bytes carve size, 4 SDRAM bank(s), 16384 bytes SDRAM pagesize, 4 carve(s) max buffer data size 10064 bytes, min buffer data size 80 bytes 257309/257309 buffers specified/carved 213496016/213496016 bytes sum buffer sizes specified/carved Qnum Head Tail #Qelem LenThresh ---- ---- ---- ------ --------- 5 non-IPC free queues: 128556/128556 (buffers specified/carved), 49.96%, 80 byte data size 1 204 203 128556 262143 77133/77133 (buffers specified/carved), 29.97%, 608 byte data size 2 128758 128757 77133 262143 38566/38566 (buffers specified/carved), 14.98%, 1568 byte data size 3 205890 244455 38566 262143 7713/7713 (buffers specified/carved), 2.99%, 4544 byte data size 4 244456 252168 7713 262143 5141/5141 (buffers specified/carved), 1.99%, 10064 byte data size 5 252169 257309 5141 262143 IPC Queue: 200/200 (buffers specified/carved), 0.7%, 4112 byte data size 30 24 23 200 262143 Multicast Raw Queue: 29 0 0 0 64327 Raw Queue: 31 24 23 0 257310 Interface Queues: 0 205 204 0 262143
Es gibt jetzt vier Carves für die FrFab-Warteschlangen, und die maximale Puffergröße wurde auf 10064 Byte geändert.
Hinweis: Bei Line Cards mit Point-to-Point Protocol (PPP)-Kapselung (Packet Over Sonet) (POS) wird eine MRU-Aushandlung (Maximum Receive Unit) durchgeführt, die MTU-Größe wird jedoch nicht angepasst. Darüber hinaus werden die PPP-Verbindungen nicht zurückgesetzt, wenn die MTU auf der Schnittstelle geändert wird.
Dieser Speicher ist in verschiedene Pools von Paketpuffern unterteilt. Um zu sehen, wie der Empfangsspeicher geschnitten wird, können Sie eine Linecard anschließen und den Befehl show controller tofab queue ausführen (siehe unten):
Router#attach ? <0-15> slot number of linecard to connect <cr> Router#attach 1 Entering Console for 1 Port SONET based SRP OC-12c/STM-4 in Slot: 1 Type "exit" to end this session Press RETURN to get started! LC-Slot1>enable LC-Slot1# LC-Slot1#show controllers tofab queues Carve information for ToFab buffers SDRAM size: 33554432 bytes, address: 30000000, carve base: 30029100 33386240 bytes carve size, 4 SDRAM bank(s), 8192 bytes SDRAM pagesize, 2 carve(s) max buffer data size 9248 bytes, min buffer data size 80 bytes 40606/40606 buffers specified/carved 33249088/33249088 bytes sum buffer sizes specified/carved Qnum Head Tail #Qelem LenThresh ---- ---- ---- ------ --------- 5 non-IPC free queues: 20254/20254 (buffers specified/carved), 49.87%, 80 byte data size 1 17297 17296 20254 65535 12152/12152 (buffers specified/carved), 29.92%, 608 byte data size 2 20548 20547 12152 65535 6076/6076 (buffers specified/carved), 14.96%, 1568 byte data size 3 32507 38582 6076 65535 1215/1215 (buffers specified/carved), 2.99%, 4544 byte data size 4 38583 39797 1215 65535 809/809 (buffers specified/carved), 1.99%, 9248 byte data size 5 39798 40606 809 65535 IPC Queue: 100/100 (buffers specified/carved), 0.24%, 4112 byte data size 30 72 71 100 65535 Raw Queue: 31 0 17302 0 65535 ToFab Queues: Dest Slot 0 0 0 0 65535 1 0 0 0 65535 2 0 0 0 65535 3 0 0 0 65535 4 0 0 0 65535 5 0 17282 0 65535 6 0 0 0 65535 7 0 75 0 65535 8 0 0 0 65535 9 0 0 0 65535 10 0 0 0 65535 11 0 0 0 65535 12 0 0 0 65535 13 0 0 0 65535 14 0 0 0 65535 15 0 0 0 65535 Multicast 0 0 0 65535 LC-Slot1#
In der folgenden Liste werden einige der Schlüsselfelder beschrieben, die im vorherigen Beispiel gefunden wurden:
SDRAM-Größe: 33554432 Byte, Adresse: 30000000, Carve Base: 30029100 - Die Größe des Empfangspaketspeichers und den Adressort, an dem er beginnt.
max. Pufferdatengröße 9248 Byte, min. Pufferdatengröße 80 Byte - Höchst- und Mindestpuffergröße.
40606/40606-Puffer spezifiziert/geschnitzt - Von der Cisco IOS-Software zu schneidende Puffer und die Anzahl der tatsächlich geschnitzten Puffer.
Nicht-IPC-freie Warteschlangen - Die Nicht-IPC-Pufferpools sind die Paket-Puffer-Pools. Paketen, die auf der Linecard eingehen, wird je nach Größe des Pakets ein Puffer aus einem dieser Pufferpools zugewiesen. Es können nur drei nicht IPC-freie Warteschlangen konfiguriert werden. Wenn es sich um ein Ethernet-Motherboard handelt, gibt es keinen 400-Pool, sondern nur einen Pool bis zu 1,500. Der Grund hierfür ist, dass die ToFab-Warteschlangen bis zur maximalen Übertragungseinheit (Maximum Transmission Unit, MTU) der jeweiligen Line Card gegliedert werden. Die Beispielausgabe zeigt fünf Paket-Puffer-Pools mit den Größen 80, 608, 1568, 4544 und 9248 Byte. Für jeden Pool sind weitere Details zu finden:
20254/20254 (spezifizierte/geschnitzte Puffer), 49,87 %, 80 Byte Datengröße - 49,87 % des Empfangspaketspeichers wurden in 80-Byte-Puffer 20254 eingeschnitten.
Menge: Die Warteschlangennummer.
#Qelem - Die Anzahl der Puffer, die dieser Warteschlange aktuell zugewiesen sind. Wenn es sich um eine freie Warteschlange handelt, sind diese Puffer für das System verfügbar. Wenn es sich um eine ToFab-Warteschlange oder eine Übertragungs-Warteschlange handelt, sind diese Puffer für das System nicht verfügbar. In dieser Spalte wird überprüft, welche Warteschlange gesichert wird.
Kopf und Schwanz - Ein Kopf- und Schwanzmechanismus stellt sicher, dass sich die Warteschlangen ordnungsgemäß bewegen.
IPC-Warteschlange - Reserviert für prozessübergreifende Kommunikationsnachrichten vom LC zum GRP.
Raw Queue: Wenn einem eingehenden Paket ein Puffer aus einer nicht IPC-freien Warteschlange zugewiesen wurde, wird es in die Rohwarteschlange aufgenommen. Bei der Rohwarteschlange handelt es sich um eine First In, First Out (FIFO)-Warteschlange, die von der LC-CPU bei Unterbrechungen verarbeitet wird. Wenn Sie eine sehr große Zahl in der Spalte #Qelem der Zeile "Raw Queue" sehen, warten zu viele Pakete auf der CPU und werden ignoriert, da die CPU nicht mit der Last Schritt halten kann. Dies ist jedoch sehr selten.
ToFab-Warteschlange - virtuelle Ausgabewarteschlangen einer pro Zielsteckplatz und einer für Multicast-Datenverkehr. Der letzte Teil des vorherigen Beispiels zeigt 15 virtuelle Ausgabewarteschlangen. Dies ist ein 12012-Router, der ursprünglich als Chassis mit 15 Steckplätzen konzipiert wurde. Die Warteschlangen 13 bis 15 werden nicht verwendet.
Nachdem die CPU der Eingangs-Linecard eine Paket-Switching-Entscheidung getroffen hat, wird das Paket in die virtuelle Ausgabewarteschlange gestellt, die dem Steckplatz entspricht, an dem das Paket bestimmt ist. Die Nummer in der vierten Spalte ist die Anzahl der Pakete, die derzeit in einer virtuellen Ausgabewarteschlange in die Warteschlange gestellt werden.
Schritt 1 - Ein Paket wird in das physische Layer Interface Module (PLIM) eingegeben. Während das Paket empfangen und verarbeitet wird, wird es als DMA'd (Direct Memory Access) in einen kleinen (etwa 2 x Maximum Transmission Unit (MTU)-Puffer) Speicher bezeichnet, der als "First In, First Out (FIFO) Burst Memory" bezeichnet wird. Die Größe dieses Speichers hängt vom Typ des LC ab (von 128 KB bis 1 MB).
Schritt 2 - Wenn sich das Paket vollständig im FIFO-Speicher befindet, kontaktiert ein ASIC (Application-Specific Integrated Circuit) auf dem PLIM den Buffer Management ASIC (BMA) und fordert einen Puffer zum Einlegen des Pakets an. Der BMA wird mitgeteilt, wie groß das Paket ist, und es wird ein Puffer entsprechend zugewiesen. Wenn die BMA keinen Puffer der richtigen Größe erhält, wird das Paket verworfen und der Zähler "ignoriert" auf der eingehenden Schnittstelle erhöht. Es gibt keinen Fallback-Mechanismus wie bei anderen Plattformen.
Schritt 3 - Während dieses Vorgangs empfängt das PLIM möglicherweise ein weiteres Paket im FIFO-Burst-Speicher, weshalb es eine 2xMTU-Größe hat. Wenn in der rechten Warteschlange ein freier Puffer verfügbar ist, wird das Paket von der BMA in der freien Warteschlangenliste der entsprechenden Größe gespeichert. Dieser Puffer wird in der Raw Queue platziert, die vom Salsa ASIC oder der R5K-CPU, abhängig vom Typ der Linecard-Switching-Engine, überprüft wird.
Schritt 4 - Auf der Engine 0 LC bestimmt die R5K CPU das Ziel des Pakets, indem sie die lokalen Tabellen für Distributed Cisco Express Forwarding (dCEF) im DRAM abruft. Anschließend wird der Puffer aus der Raw Queue in eine ToFabric-Warteschlange verschoben, die dem Zielsteckplatz entspricht. Wenn sich das Ziel nicht in den dCEF-Tabellen befindet, wird das Paket verworfen. Wenn es sich bei dem Paket um ein Steuerungspaket (z. B. Routing-Updates) handelt, wird es in die Warteschlange des GRP gestellt und vom GRP verarbeitet. Auf einem Router des Jahres 12016 gibt es 17 ToFab-Warteschlangen (16 Unicast und ein Multicast).
Schritt 5 - Der ToFab-BMA fügt den Puffer in die richtige ToFab-Warteschlange ein. An diesem Punkt kam der #Qelem-Zähler im Pool aus einer Verringerung um eins und der ToFab-Warteschlangenzähler um eins.
Hinweis: Pro Linecard gibt es eine ToFab-Warteschlange (dies beinhaltet auch die GRP). Diese Warteschlangen werden als virtuelle Ausgabewarteschlangen (VOQs) bezeichnet. Diese sind wichtig, um eine Head-of-Line-Blockierung zu vermeiden.
Schritt 6 - Der Fabric Interface ASIC (FIA) erkennt, dass eine Ausgabewarteschlange nicht leer ist. Die FIA ist so eingerichtet, dass das Paket in 48-Byte-Zellen segmentiert wird. Dem Paket wird ein 8-Byte-Header hinzugefügt, und die 56-Byte-Cisco-Zelle wird über die Switch-Fabric gesendet.
Pakete, die von der Switch-Fabric kommen und auf die Übertragung an die physische Schnittstelle warten, werden im Paket-Arbeitsspeicher gespeichert. Dieser Speicher ist auch in Pools verschiedener Größen unterteilt.
Über die GRP können Sie eine Linecard anschließen und den Befehl show controller fab queue ausführen, um den Übertragungspaketspeicher anzuzeigen. Zusätzlich zu den Feldern in der ToFab-Ausgabe zeigt die FrFab-Ausgabe den Abschnitt "Interface Queues" (Schnittstellenwarteschlangen) an. Die Ausgabe variiert je nach Typ und Anzahl der Schnittstellen auf dem ausgehenden LC.
Eine solche Warteschlange ist für jede Schnittstelle auf der Linecard vorhanden. Pakete, die für eine bestimmte Schnittstelle bestimmt sind, werden in die entsprechende Schnittstellenwarteschlange aufgenommen.
LC-Slot1#show controller frfab queue ========= Line Card (Slot 2) ======= Carve information for FrFab buffers SDRAM size: 16777216 bytes, address: 20000000, carve base: 2002D100 16592640 bytes carve size, 0 SDRAM bank(s), 0 bytes SDRAM pagesize, 2 carve(s) max buffer data size 9248 bytes, min buffer data size 80 bytes 20052/20052 buffers specified/carved 16581552/16581552 bytes sum buffer sizes specified/carved Qnum Head Tail #Qelem LenThresh ---- ---- ---- ------ --------- 5 non-IPC free queues: 9977/9977 (buffers specified/carved), 49.75%, 80 byte data size 1 101 10077 9977 65535 5986/5986 (buffers specified/carved), 29.85%, 608 byte data size 2 10078 16063 5986 65535 2993/2993 (buffers specified/carved), 14.92%, 1568 byte data size 3 16064 19056 2993 65535 598/598 (buffers specified/carved), 2.98%, 4544 byte data size 4 19057 19654 598 65535 398/398 (buffers specified/carved), 1.98%, 9248 byte data size 5 19655 20052 398 65535 IPC Queue: 100/100 (buffers specified/carved), 0.49%, 4112 byte data size 30 77 76 100 65535 Raw Queue: 31 0 82 0 65535 Interface Queues: 0 0 0 0 65535 1 0 0 0 65535 2 0 0 0 65535 3 0 0 0 65535
In der folgenden Liste werden einige der Schlüsselfelder beschrieben, die im vorherigen Beispiel gefunden wurden:
Nicht-IPC-freie Warteschlangen: Diese Warteschlangen sind Paketpufferpools unterschiedlicher Größe. Wenn ein Paket über die Fabric empfangen wird, wird aus einer dieser Warteschlangen ein Puffer mit entsprechender Größe entnommen, das Paket in dieses kopiert und der Puffer in die entsprechende Ausgabeschnittstellen-Warteschlange gestellt.
Hinweis: Für den gesamten Router sind so viele Pools erforderlich. Infolgedessen werden FrFab-Warteschlangen bis zur maximalen MTU des gesamten Systems unterteilt. Dies ist bei ToFab-Warteschlangen anders, die bis zur maximalen MTU der jeweiligen Linecard unterteilt sind.
IPC-Warteschlange: Reserviert für prozessübergreifende Kommunikationsmeldungen vom GRP zum LC.
Schnittstellenwarteschlangen: Diese Warteschlangen gelten für die Schnittstellen, nicht für die Steckplatznummern. Die letzte Zahl (65535) ist der Grenzwert für die TX-Warteschlange. Diese Nummer steuert die maximale Länge einer Warteschlange und kann mithilfe des Befehls TX-queue limit auf der Line Card Engine 0 eingestellt werden. Bei Überlastungen kann dieser Befehl verwendet werden, um zu verhindern, dass der Egress-LC mehr Pakete als die konfigurierte Anzahl von Paketen in der Schnittstellenwarteschlange für diesen bestimmten Port puffert. Stellen Sie sicher, dass Sie diese Zahl so niedrig konfigurieren, dass sie nicht alle FrFab-Warteschlangen für diese Schnittstelle enthält. Diese Einstellung bietet jedoch keine Kontrolle darüber, welche Pakete auf dem ausgehenden LC verworfen werden. Weitere Informationen finden Sie unter Problembehandlung bei ignorierten Paketen und Speicherverlusten auf dem Cisco Internet Router der Serie 12000.
Zu diesem Zeitpunkt wurden die Cisco Zellen von der FIA über die Switch-Fabric übertragen.
Schritt 1: Diese Cisco Zellen werden in FIFOs auf den FrFab-FIAs und dann in einen Puffer auf dem FrFab-BMAs eingefügt. Die FrFab-BMA ist die, die tatsächlich die Reassemblierung von Zellen in einem Paket durchführt.
Woher weiß die FrFab BMA, in welchem Puffer die Zellen platziert werden sollen, bevor sie wieder zusammengebaut werden? Dies ist eine weitere Entscheidung der Switching-Engine für eingehende Line Cards. Da alle Warteschlangen im gesamten Feld die gleiche Größe und die gleiche Reihenfolge haben, weist die Switching-Engine den übertragenden LC an, das Paket in die gleiche Nummernwarteschlange zu stellen, aus der es den Router eingegeben hat.
Die FrFab-BMA-SDRAM-Warteschlangen können mit dem Befehl show controller fab queue im LC angezeigt werden.
Schritt 2 - Dieser Schritt entspricht im Wesentlichen der ToFab-BMA-Ausgabe. Pakete werden in Paketen eingesendet, die aus den entsprechenden freien Warteschlangen entfernt werden. Diese Pakete werden in die FrFab-Warteschlange gestellt und in die Warteschlange für die Schnittstelle (es gibt eine Warteschlange pro physischem Port) oder in die Warteschlange für die Ausgangsverarbeitung gestellt. Im rawQ passiert nicht viel: Multicast-Replikation pro Port, Modified Deficit Round Robin (MDRR) - dieselbe Idee wie Distributed Weighted Fair Queuing (DWFQ) und Output Committed Access Rate (CAR). Wenn die Übermittlungswarteschlange voll ist, wird das Paket verworfen und der Zähler für die Ausgabe-Drop erhöht.
Schritt 3 - Die FrFab-BMA wartet, bis der TX-Teil des PLIM bereit ist, ein Paket zu senden. Die FrFab-BMA führt die eigentliche MAC-Umschreibung (basierend, erinnern Sie sich, auf den Informationen im Cisco Cell-Header) durch und DMAs übertragen das Paket auf einen kleinen (wiederum 2xMTU-) Puffer im PLIM-Schaltkreis. Das PLIM übernimmt ggf. die Segmentierung und Reassemblierung (SAR) des asynchronen Übertragungsmodus und SONET-Kapselung (Synchronous Optical Network) und überträgt das Paket.