Gewichtete Fair-Warteschlangen auf ATM

Einführung

Dieses Dokument bietet eine Einführung in Datenverkehrswarteschlangen, bei denen die WFQ-Technologie (Weighted Fair Queuing) zum Einsatz kommt.

WFQ wurde eingeführt, um langsame Verbindungen, z. B. serielle Verbindungen, zu ermöglichen, um eine faire Behandlung aller Arten von Datenverkehr zu gewährleisten. Zu diesem Zweck klassifiziert WFQ den Datenverkehr in verschiedene Datenflüsse (auch als Kommunikation bezeichnet), die auf Informationen auf Layer 3 und Layer 4 basieren, z. B. IP-Adressen und TCP-Ports. Dies geschieht, ohne dass Sie Zugriffslisten definieren müssen. Dies bedeutet, dass Datenverkehr mit niedriger Bandbreite gegenüber Datenverkehr mit hoher Bandbreite Priorität hat, da Datenverkehr mit hoher Bandbreite die Übertragungsmedien im Verhältnis zum zugewiesenen Gewicht teilt.

WFQ weist jedoch gewisse Einschränkungen auf:

• Es ist nicht skalierbar, wenn der Flow-Betrag erheblich zunimmt.

• Natives WFQ ist für Hochgeschwindigkeitsschnittstellen wie ATM-Schnittstellen nicht verfügbar.

Class-Based Weighted Fair Queuing (CBWFQ) bietet eine Lösung für diese Einschränkungen.

Im Gegensatz zu Standard-WFQ können Sie mit CBWFQ Datenverkehrsklassen definieren. Sie können auch Parameter wie Bandbreite und Warteschlangenbeschränkungen anwenden. Die Bandbreite, die Sie einer Klasse zuweisen, wird verwendet, um das Gewicht dieser Klasse zu berechnen. Daraus wird auch das Gewicht jedes Pakets errechnet, das den Klassenkriterien entspricht. WFQ wird dann auf die Klassen angewendet, die statt der Flüsse selbst mehrere Flüsse enthalten können.

Weitere Informationen zur Konfiguration von CBWFQ finden Sie in den folgenden Dokumenten:

• Class-Based, Weighted Fair Queuing (Per-VC CBWFQ) auf Cisco Routern der Serien 7200, 3600 und 2600

• Class-Based, Weighted Fair Queuing auf RSP-basierten Plattformen

ATM-Schnittstellen unterstützen kein natives, Flow-basiertes WFQ, das direkt auf einer Schnittstelle mit dem Befehl fair-queue konfiguriert wird. Mit der Software, die CBWFQ unterstützt, können Sie Flow-Based WFQ jedoch innerhalb der Standardklasse konfigurieren, wie im folgenden Beispiel gezeigt:

policy-map test
 class class-default
  fair-queue
!         
interface ATMx/y.z point-to-point
 ip address a.b.c.d M.M.M.M
 pvc A/B 
  service-policy output test

Voraussetzungen

Anforderungen

Für dieses Dokument bestehen keine speziellen Anforderungen.

Verwendete Komponenten

Dieses Dokument ist nicht auf bestimmte Software- und Hardwareversionen beschränkt.

Konventionen

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

Netzwerkdiagramm

Verwenden Sie diese Konfiguration, um die Funktionsweise von WFQ zu veranschaulichen:

In dieser Konfiguration können Pakete in einer der folgenden beiden Warteschlangen gespeichert werden:

• Die Hardware First In First Out (FIFO)-Warteschlange am Port-Adapter und Netzwerkmodul

• Die Warteschlange in der Cisco IOS^®-Software im E/A-Speicher des Routers, in der Quality of Service (QoS)-Funktionen wie CBWFQ angewendet werden können

Die FIFO-Warteschlange am Port-Adapter speichert die Pakete, bevor sie zur Übertragung in Zellen segmentiert werden. Wenn diese Warteschlange voll ist, signalisiert der Port-Adapter oder das Netzwerkmodul der IOS-Software, dass die Warteschlange überlastet ist. Dieser Mechanismus wird als Rückdruck bezeichnet. Nach Erhalt dieses Signals beendet der Router das Senden von Paketen an die FIFO-Warteschlange für die Schnittstelle und speichert die Pakete in der IOS-Software, bis die Warteschlange wieder nicht überlastet wird. Wenn die Pakete in IOS gespeichert werden, kann das System QoS anwenden.

Festlegen des Übermittlungsklingellimits

Ein Problem bei diesem Warteschlangenmechanismus ist, dass die Verzögerung, bevor Pakete am Ende dieser Warteschlange übertragen werden können, umso größer ist, je größer die FIFO-Warteschlange an der Schnittstelle ist. Dies kann bei verzögerungsempfindlichem Datenverkehr, z. B. beim Sprachverkehr, zu schwerwiegenden Leistungsproblemen führen.

Mit dem Befehl Permanent Virtual Circuit (PVC) tx-ring-limit können Sie die Größe der FIFO-Warteschlange reduzieren.

interface ATMx/y.z point-to-point
 ip address a.b.c.d M.M.M.M
 PVC A/B 
  tx-ring-limit  
       

  service-policy output test

<Größe> Hier können Sie eine Anzahl von Paketen für Cisco Router der Serien 2600 und 3600 oder eine Partikelzahl für Cisco Router der Serien 7200 und 7500 angeben.

Die Verringerung der Größe des Übertragungsringes hat zwei Vorteile:

• Dadurch wird die Wartezeit von Paketen in der FIFO-Warteschlange reduziert, bevor sie segmentiert werden.

• Sie beschleunigt die Nutzung der QoS in der IOS-Software.

Auswirkungen des Grenzwerts für den Übertragungsring

Überprüfen Sie die Auswirkungen der Übertragungsring-Grenze, die die im vorherigen Netzwerkdiagramm dargestellte Konfiguration verwendet. Gehen Sie von folgenden Faktoren aus:

• Der Datenverkehrsgenerator sendet Datenverkehr (1500-Byte-Pakete) an das Empfängergerät, und dieser Datenverkehr überlastet die PVC 0/102 zwischen Router1 und Router2.

• Router3 versucht, Router1 zu pingen.

• WFQ ist auf Router 2 aktiviert.

Sehen Sie sich zwei Konfigurationen an, bei denen unterschiedliche Übertragungsringgrenzen verwendet werden, um die Auswirkungen zu erkennen.

Beispiel A

In diesem Beispiel setzen Sie den Übertragungsring auf drei (tx-ring-limit=3). Dies sehen Sie, wenn Sie Router1 von Router3 pingen:

pound#ping ip
Target IP address: 6.6.6.6
Repeat count [5]: 100000
Datagram size [100]: 
Timeout in seconds [2]: 
Extended commands [n]: 
Sweep range of sizes [n]: 
Type escape sequence to abort.
Sending 100000, 100-byte ICMP Echos to 6.6.6.6, timeout is 2 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!![snip]
Success rate is 98 percent (604/613), round-trip min/avg/max = 164/190/232 ms   

router2#show queue atm 4/0.102 
   Interface ATM4/0.102 VC 0/102 
   Queuing strategy: weighted fair 
   Total output drops per VC: 1505772 
   Output queue: 65/512/64/1505772 (size/max total/threshold/drops) 
    Conversations  2/3/16 (active/max active/max total)    
    Reserved Conversations 0/0 (allocated/max allocated)    

(depth/weight/discards/tail drops/interleaves) 1/32384/0/0/0    
   Conversation 2, linktype: ip, length: 58 
   source: 8.0.0.1, destination: 6.6.6.6, id: 0x2DA1, ttl: 254, prot: 1  
   
!--- ping 
   

(depth/weight/discards/tail drops/interleaves) 64/32384/1505776/0/0    
   Conversation 15, linktype: ip, length: 1494 
   source: 7.0.0.1, destination: 6.6.6.6, id: 0x0000, ttl: 63, prot: 255 
   
!--- This is traffic from the traffic generator. 

Beispiel B

In diesem Beispiel setzen Sie den Übertragungsring auf 40 (tx-ring-limit=40). Dies wird angezeigt, wenn Sie den gleichen Ping wie in Beispiel A verwenden:

pound#ping ip
Target IP address: 6.6.6.6
Repeat count [5]: 10000
Datagram size [100]: 36
Timeout in seconds [2]: 10
Extended commands [n]: 
Sweep range of sizes [n]: 
Type escape sequence to abort.
Sending 10000, 36-byte ICMP Echos to 6.6.6.6, timeout is 10 seconds:
!!!!!!!!!!!!.
Success rate is 92 percent (12/13), round-trip min/avg/max = 6028/6350/6488 ms

Wie Sie hier sehen können, je größer der Grenzwert für den Übertragungsring ist, desto größer ist die Ping-Round-Trip-Zeit (RTT). Daraus können Sie schließen, dass ein großer Übertragungsring zu erheblichen Verzögerungen bei der Übertragung führen kann.

Berechnen des Gewichts

In der Ausgabe der show queueTM in Beispiel A wird jedem Gespräch ein Gewicht zugewiesen. Sehen Sie sich das genauer an:

router2#show queue ATM 4/0.102 
   Interface ATM4/0.102 VC 0/102 
   Queuing strategy: weighted fair 
   Total output drops per VC: 1505772 
   Output queue: 65/512/64/1505772 (size/max total/threshold/drops) 
    Conversations  2/3/16 (active/max active/max total)    
    Reserved Conversations 0/0 (allocated/max allocated)    

(depth/weight/discards/tail drops/interleaves) 1/32384/0/0/0    
   Conversation 2, linktype: ip, length: 58 
   source: 8.0.0.1, destination: 6.6.6.6, id: 0x2DA1, ttl: 254, prot: 1    

(depth/weight/discards/tail drops/interleaves) 64/32384/1505776/0/0    
   Conversation 15, linktype: ip, length: 1494 
   source: 7.0.0.1, destination: 6.6.6.6, id: 0x0000, ttl: 63, prot: 255  

Wenn Sie WFQ verwenden, können Sie das Gewicht jeder Konversation mithilfe der folgenden Formel berechnen:

• weight=32384/(Rangfolge+1) - für Cisco IOS Software Release 12.0(5)T und höher.

• weight=4096/(Rangfolge+1) - für Cisco IOS Software Releases vor 12.0(5)T.

Berechnung der Planungszeit

Sie können diese Gewichtungen jetzt verwenden, um die Planungszeit jedes Pakets zu berechnen, wenn das Paket von der IOS-Warteschlange an den Port-Adapter oder die FIFO-Warteschlange des Netzwerkmoduls weitergeleitet wird.

Sie können die Zeitplanung für die Ausgabe mithilfe dieser Formel berechnen, wobei queue_tail_time die aktuelle Planungszeit ist:

Ausgabeplanzeit= queue_tail_time + pktsize*weight

Funktionsweise von WFQ

In diesem Abschnitt wird die Funktionsweise von WFQ erläutert. Das Prinzip von WFQ besteht darin, dass Pakete mit einem geringen Gewicht oder kleine Pakete beim Senden Priorität erhalten sollten.

Erstellen Sie einen Fluss, der zehn große Pakete und vier kleinere Pakete (von 82 Byte) umfasst, die einen Datenverkehrsgenerator verwenden, um dies zu überprüfen.

In diesem Beispiel ist Router2 ein Cisco 7200-Router mit einem PA-A3 (ATM-Port-Adapter). Dies ist wichtig, da die Größe der FIFO-Ausgabewarteschlange auf dem Port-Adapter in Teilchen und nicht in Paketen ausgedrückt wird. Siehe Was ist ein Artikel? für weitere Informationen.

Was ist ein Artikel?

Anstelle der Zuweisung eines zusammenhängenden Speichers für einen Puffer weist die Partikelpufferung nicht zusammenhängende (verstreute) Speicherstücke, so genannte Partikel, zu und verbindet sie dann miteinander, um einen logischen Paketpuffer zu bilden. Dies wird als Teilchenpuffer bezeichnet. In einem solchen Schema kann ein Paket dann auf mehrere Partikel verteilt werden.

Im 7200-Router beträgt die Partikelgröße 512 Byte.

Verwenden Sie den Befehl show buffers, um zu überprüfen, ob Cisco 7200-Router Partikel verwenden:

router#show buffers
[snip]
Private particle pools: 
FastEthernet0/0 buffers, 512 bytes (total 400, permanent 400):
  0 in free list (0 min, 400 max allowed)
  400 hits, 0 fallbacks
  400 max cache size, 271 in cache
ATM2/0 buffers, 512 bytes (total 400, permanent 400): 
  0 in free list (0 min, 400 max allowed)
  400 hits, 0 fallbacks
  400 max cache size, 0 in cache

Test A

Dies sind einige Tests, um die WFQ-Funktionalität zu veranschaulichen. In diesem ersten Test prüfen Sie, ob die Bandbreite für verschiedene Gespräche freigegeben werden kann.

In diesem Test haben Sie den Datenverkehrsgenerator so schnell gesendet, dass er den PVC 0/102-Datenverkehr zwischen Router1 und Router2 überlasten kann. Senden Sie einen Ping von Router3 an Router1 über dieselbe PVC:

pound#ping ip
Target IP address: 6.6.6.6
Repeat count [5]: 100000
Datagram size [100]: 
Timeout in seconds [2]: 
Extended commands [n]: 
Sweep range of sizes [n]: 
Type escape sequence to abort.
Sending 100000, 100-byte ICMP Echos to 6.6.6.6, timeout is 2 seconds:
......... (WFQ is enabled here)!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.[break]
Success rate is 98 percent (604/613), round-trip min/avg/max = 164/190/232 ms

Wie Sie in der angezeigten Ausgabe sehen können, verhindert der Datenverkehr, dass der andere Datenverkehr die Leitung durchläuft, bis WFQ auf der Schnittstelle aktiviert ist. Sobald WFQ aktiviert ist, ist der Ping erfolgreich.

Sie können daraus ablesen, dass bei Verwendung von WFQ Bandbreite zwischen verschiedenen Gesprächen gemeinsam genutzt werden kann, ohne dass ein Gespräch die anderen blockiert.

Test B

So wird die Bandbreite gemeinsam genutzt.

Der Fluss, den der Datenverkehrsgenerator sendet, besteht aus zehn großen Paketen, gefolgt von vier kleineren Paketen mit 82 Byte. Sie senden diese mit 100 Mbit/s an Router2. Wenn Sie den Burst senden, ist die Ausgabewarteschlange auf der ATM-Schnittstelle von Router2 leer. Router2 sendet diese Pakete über eine PVC mit 10 KB (dies ist eine sehr langsame PVC), um sicherzustellen, dass es in der Ausgabewarteschlange zu Überlastungen kommt.

Führen Sie diesen Test in mehreren Phasen durch, um diesen Prozess zu vereinfachen:

Phase 1:

Der große Datenverkehr besteht aus zehn 482-Byte-Paketen. Da die Partikel auf dem PA-A3 512 Byte betragen, sollte jedes große oder kleine Paket ein Teilchen annehmen, wenn es in der Ausgabewarteschlange des Port-Adapters gespeichert wird. Der Router hat eine Übertragungsring-Grenze von drei (tx-ring-limit=3). Dies ist ein Beispiel für das Gerät, das Sie sehen können:

   .Nov  7 15:39:13.776: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, len 482, rcvd 4 
   .Nov  7 15:39:13.776: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, unknown protocol 
   .Nov  7 15:39:14.252: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
   .Nov  7 15:39:14.252: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, unknown protocol 
   .Nov  7 15:39:14.732: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
   .Nov  7 15:39:14.732: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, unknown protocol 
   .Nov  7 15:39:15.208: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
   .Nov  7 15:39:15.208: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, unknown protocol 

   
!--- Congestion occurs at this point. 


   .Nov  7 15:39:15.512: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, rcvd 4 
   .Nov  7 15:39:15.516: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, unknown protocol 
   .Nov  7 15:39:15.644: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, rcvd 4 
   .Nov  7 15:39:15.644: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, unknown protocol 
   .Nov  7 15:39:15.776: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, rcvd 4 
   .Nov  7 15:39:15.776: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, unknown protocol 
   .Nov  7 15:39:15.904: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, rcvd 4 
   .Nov  7 15:39:15.904: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, unknown protocol 
   .Nov  7 15:39:16.384: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
   .Nov  7 15:39:16.384: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, unknown protocol 
   .Nov  7 15:39:16.860: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
   .Nov  7 15:39:16.860: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, unknown protocol 
   .Nov  7 15:39:17.340: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
   .Nov  7 15:39:17.340: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, unknown protocol 
   .Nov  7 15:39:17.816: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
   .Nov  7 15:39:17.820: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, unknown protocol 
   .Nov  7 15:39:18.296: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
   .Nov  7 15:39:18.296: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, unknown protocol 
   .Nov  7 15:39:18.776: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
   .Nov  7 15:39:18.776: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, unknown protocol 

Sie können die vier Pakete mit 482 Byte sehen, die vor den 82-Byte-Paketen gesendet wurden, die normalerweise die Priorität erhalten sollten. Deshalb geschieht das.

Da der Burst hauptsächlich aus zehn 482-Byte-Paketen besteht, erreichen diese zuerst den Router, gefolgt von 82-Byte-Paketen. Da die 482-Byte-Pakete zu einem Zeitpunkt eintreffen, zu dem keine Überlastung vorliegt, da kein Datenverkehr besteht, wird sofort ein Paket in die Warteschlange zur Segmentierung und Reassemblierung (SAR) des Port-Adapters gestellt, um in Zellen unterteilt und über die Leitung gesendet zu werden. Mit anderen Worten, der Übertragungsring ist noch leer.

Sie können berechnen, dass die zum Senden eines 482-Byte-Pakets benötigte Zeit größer ist als die Zeit, die der Datenverkehrsgenerator zum Senden des gesamten Burst benötigt. Wenn das erste 482-Byte-Paket in die Warteschlange des Port-Adapters gestellt wird, sind im Router bereits mehr 482-Byte-Pakete vorhanden. Daher können mehr 482-Byte-Pakete in die Warteschlange zum Übertragungsring gestellt werden. Drei weitere Pakete von 482 Byte werden in die Warteschlange gestellt, wenn die drei freien Partikel dort vorhanden sind.

Hinweis: Pakete werden in die Warteschlange des Übertragungs-Rings gestellt, sobald ein freies Teilchen vorliegt, selbst wenn mehr als ein Teilchen gespeichert werden muss.

An diesem Punkt gibt es Verstopfung, da die drei Partikel voll sind. Daher beginnt die Warteschlangenverwaltung in IOS. Wenn die vier 82-Byte-Pakete den Router endlich erreichen, kommt es zu Überlastung. Diese vier Pakete werden in die Warteschlange gestellt, und für die beiden Datenflüsse wird WFQ verwendet. Sehen Sie sich die ATM-Warteschlange an, die den Befehl show queue ATM verwendet, um Folgendes anzuzeigen:

router2#show queue ATM 4/0.102 vc 0/102 
   Interface ATM4/0.102 VC 0/102 
   Queuing strategy: weighted fair 
   Total output drops per VC: 0 
   Output queue: 10/512/64/0 (size/max total/threshold/drops) 
     Conversations  2/4/16 (active/max active/max total)    
     Reserved Conversations 0/0 (allocated/max allocated)    

(depth/weight/total drops/no-buffer drops/interleaves) 4/32384/0/0/0    
   Conversation 6, linktype: ip, length: 82 
   source: 7.0.0.200, destination: 6.6.6.6, id: 0x0000, ttl: 63, prot: 255    

(depth/weight/total drops/no-buffer drops/interleaves) 6/32384/0/0/0    
   Conversation 15, linktype: ip, length: 482 
   source: 7.0.0.1, destination: 6.6.6.6, id: 0x0000, ttl: 63, prot: 255  

Sie können in den Debuggen sehen, dass die ersten vier Pakete mit 482 Byte gefolgt von den 82-Byte-Paketen sind. Diese kleinen Pakete gehen vor den großen Paketen aus dem Router. Dies weist darauf hin, dass bei einer Überlastung kleine Pakete Vorrang vor großen Paketen erhalten.

Überprüfen Sie dies anhand der im Abschnitt Berechnung des Gewichts angegebenen Formeln für Gewicht und Zeitplanung.

Phase 2:

Wenn Sie den Grenzwert für den Übertragungsring auf fünf erhöhen und die großen Pakete 482 Byte umfassen, sollten Sie entsprechend der vorherigen Ausgabe sechs Pakete von 482 Byte vor der Überlastung sehen, gefolgt von vier Paketen von 82 Byte und weiteren vier Paketen von 482 Byte:

   .Nov  7 15:49:57.365: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
   .Nov  7 15:49:57.365: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, unknown protocol 
   .Nov  7 15:49:57.841: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
   .Nov  7 15:49:57.845: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, unknown protocol 
   .Nov  7 15:49:58.321: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
   .Nov  7 15:49:58.321: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, unknown protocol 
   .Nov  7 15:49:58.797: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
   .Nov  7 15:49:58.801: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, unknown protocol 
   .Nov  7 15:49:59.277: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
   .Nov  7 15:49:59.277: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, unknown protocol 
   .Nov  7 15:49:59.757: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
   .Nov  7 15:49:59.757: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, unknown protocol 
   .Nov  7 15:49:59.973: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, rcvd 4 
   .Nov  7 15:49:59.973: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, unknown protocol 
   .Nov  7 15:50:00.105: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, rcvd 4 
   .Nov  7 15:50:00.105: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, unknown protocol 
   .Nov  7 15:50:00.232: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, rcvd 4 
   .Nov  7 15:50:00.232: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, unknown protocol 
   .Nov  7 15:50:00.364: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, rcvd 4 
   .Nov  7 15:50:00.364: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, unknown protocol 
   .Nov  7 15:50:00.840: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
   .Nov  7 15:50:00.844: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, unknown protocol 
   .Nov  7 15:50:01.320: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
   .Nov  7 15:50:01.320: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, unknown protocol 
   .Nov  7 15:50:01.796: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
   .Nov  7 15:50:01.800: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, unknown protocol 
   .Nov  7 15:50:02.276: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, rcvd 4 
   .Nov  7 15:50:02.276: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 482, unknown protocol  

Wie Sie hier sehen können, passiert genau das.

Phase 3:

Die Partikelgröße beträgt 512 Byte. Wenn der Übertragungsring also in Teilchen ausgedrückt wird und man Pakete verwendet, die etwas größer sind als die Partikelgröße, nimmt jeder einzelne zwei Partikel. Dies wird durch die Verwendung von Paketen mit 582 Byte und einem Übertragungsring von drei Paketen veranschaulicht. Bei diesen Parametern sollten Sie drei Pakete von 582 Byte sehen. Eine wird ohne Datenverkehr an die ATM-Schnittstelle gesendet, wodurch drei Teilchen frei bleiben. Aus diesem Grund können zwei weitere Pakete in die Warteschlange gestellt werden, gefolgt von vier Paketen mit 82 Byte und anschließend sieben Paketen mit 582 Byte:

   .Nov  7 15:51:34.604: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 582, rcvd 4 
   .Nov  7 15:51:34.604: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 582, unknown protocol 
   .Nov  7 15:51:35.168: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 582, rcvd 4 
   .Nov  7 15:51:35.168: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 582, unknown protocol 
   .Nov  7 15:51:35.732: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 582, rcvd 4 
   .Nov  7 15:51:35.736: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 582, unknown protocol 
   .Nov  7 15:51:35.864: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, rcvd 4 
   .Nov  7 15:51:35.864: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, unknown protocol 
   .Nov  7 15:51:35.996: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, rcvd 4 
   .Nov  7 15:51:35.996: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, unknown protocol 
   .Nov  7 15:51:36.124: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, rcvd 4 
   .Nov  7 15:51:36.124: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, unknown protocol 
   .Nov  7 15:51:36.256: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, rcvd 4 
   .Nov  7 15:51:36.256: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, unknown protocol 
   .Nov  7 15:51:36.820: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 582, rcvd 4 
   .Nov  7 15:51:36.820: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 582, unknown protocol 
   .Nov  7 15:51:37.384: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 582, rcvd 4 
   .Nov  7 15:51:37.388: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 582, unknown protocol 
   .Nov  7 15:51:37.952: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 582, rcvd 4 
   .Nov  7 15:51:37.952: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 582, unknown protocol 
   .Nov  7 15:51:38.604: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 582, rcvd 4 
   .Nov  7 15:51:38.604: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 582, unknown protocol 
   .Nov  7 15:51:39.168: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 582, rcvd 4 
   .Nov  7 15:51:39.168: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 582, unknown protocol 
   .Nov  7 15:51:39.732: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 582, rcvd 4 
   .Nov  7 15:51:39.736: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 582, unknown protocol 
   .Nov  7 15:51:40.300: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 582, rcvd 4 
   .Nov  7 15:51:40.300: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 582, unknown protocol  

Phase 4:

Nehmen Sie eine Paketgröße von 1482 (drei Partikel) und definieren Sie einen Übertragungsring von fünf. Wenn der Übertragungsring in Teilchen definiert ist, sehen Sie etwas Ähnliches:

• Ein Paket wird sofort übertragen

• Ein Paket, das drei der fünf Teilchen

• Ein Paket wird in die Warteschlange gestellt, da zwei Partikel frei sind

   .Nov  8 07:22:41.200: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   .Nov  8 07:22:41.200: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, unknown protocol 
   .Nov  8 07:22:42.592: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   .Nov  8 07:22:42.592: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, unknown protocol 
   .Nov  8 07:22:43.984: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   .Nov  8 07:22:43.984: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, unknown protocol 
   .Nov  8 07:22:44.112: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, rcvd 4 
   .Nov  8 07:22:44.112: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, unknown protocol 
   .Nov  8 07:22:44.332: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, rcvd 4 
   .Nov  8 07:22:44.332: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, unknown protocol 
   .Nov  8 07:22:44.460: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, rcvd 4 
   .Nov  8 07:22:44.460: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, unknown protocol 
   .Nov  8 07:22:44.591: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, rcvd 4 
   .Nov  8 07:22:44.591: IP: s=7.0.0.200 (FastEthernet0/1), d=6.6.6.6, Len 82, unknown protocol 
   .Nov  8 07:22:45.983: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   .Nov  8 07:22:45.983: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, unknown protocol 
   .Nov  8 07:22:47.371: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   .Nov  8 07:22:47.375: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, unknown protocol 
   .Nov  8 07:22:48.763: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   .Nov  8 07:22:48.767: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, unknown protocol 
   .Nov  8 07:22:50.155: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   .Nov  8 07:22:50.155: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, unknown protocol 
   .Nov  8 07:22:51.547: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   .Nov  8 07:22:51.547: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, unknown protocol 
   .Nov  8 07:22:53.027: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   .Nov  8 07:22:53.027: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, unknown protocol 
   .Nov  8 07:22:54.415: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, rcvd 4 
   .Nov  8 07:22:54.419: IP: s=7.0.0.1 (FastEthernet0/1), d=6.6.6.6, Len 1482, unknown protocol 

Zusammenfassung

Aus den durchgeführten Tests können Sie Folgendes schließen:

• Bei langsamen PVCs ohne WFQ wirkt sich Bulk-Datenverkehr auf kleinen Datenverkehr aus, z. B. Pings, die bis zur Aktivierung von WFQ blockiert werden.

• Die Größe des Übertragungsringes (Tx-Ring-Limit) legt fest, wie schnell der Warteschlangenmechanismus seine Arbeit aufnimmt. Sie sehen die Auswirkungen dieser Entwicklung bei einer Erhöhung des Ping-RTT, wenn der Grenzwert für den Übertragungsring steigt. Wenn WFQ oder LLQ implementiert werden muss, ist es daher sinnvoll, den Grenzwert für den Übertragungsring zu reduzieren.

• WFQ, die CBWFQ verwendet, priorisiert in der Tat kleinen Datenverkehr gegenüber Massendatenverkehr.

Zugehörige Informationen

• Support-Seiten für ATM-Technologie
• Überlastungsmanagement - Übersicht
• Technischer Support und Dokumentation - Cisco Systems