Inhalt

Einführung

Bevor Sie beginnen

Konventionen

Voraussetzungen

Verwendete Komponenten

Hintergrund

Puffer Carving-Algorithmen

Paketspeicher empfangen

Paketfluss im ToFab-BMA

Paketspeicher übertragen

Paketfluss in FrFab BMA

Zugehörige Informationen

Einführung

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.

Bevor Sie beginnen

Konventionen

Weitere Informationen zu Dokumentkonventionen finden Sie in den Cisco Technical Tips Conventions.

Voraussetzungen

Für dieses Dokument bestehen keine besonderen Voraussetzungen.

Verwendete Komponenten

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.

Hintergrund

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.

Puffer Carving-Algorithmen

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.

Paketspeicher empfangen

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.

Paketfluss im ToFab-BMA

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.

Paketspeicher übertragen

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.

Paketfluss in FrFab BMA

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.

Zugehörige Informationen

- Fehlerbehebung bei nicht erkannten Paketen und Speicherverlusten beim Cisco Internet Router der Serie 12000

- Fehlerbehebung bei Verlusten am Cisco Internet Router der Serie 12000

- Lesen der Ausgabe des Befehls Show Controller (Controller anzeigen)

- Technischer Support - Cisco Systems