Was ist der Vorteil der Verwendung von CBWFQ mit Fair-Queue-Statement?

Ich sehe meistens die Konfiguration von QoS-Warteschlangen basierend auf CBWFQ, die durch das Formen der Karte ausgelöst werden. So etwas wie das folgende Beispiel.

policy-map test
 class test
  bandwidth remaining percent 20
  random-detect dscp-based
 class test2
  bandwidth remaining percent 20
  random-detect dscp-based
 class test3
  bandwidth remaining percent 20
  random-detect dscp-based
 class test4
  bandwidth remaining percent 20
  random-detect dscp-based
 class class-default
  bandwidth remaining percent 20
  random-detect dscp-based      
policy-map shape-test
 class class-default
  shape average xxx
  service-policy test

Natürlich ist es auf der entsprechenden Schnittstelle (out) konfiguriert.

Ich kenne eine einfache Variante von CBWFQ namens WFQ. Wo ich keine Klassen angeben muss (automatische Erstellung von Klassen). Ja, ich weiß auch, dass es durch Hash aus dem Header gemacht wird und jede Klasse Gewicht hat ... Und so eine ... Fast immer sehe ich die Konfiguration der fairen Warteschlange auf der Schnittstelle oder einfach in der Standardklasse namens 'class-default' '. Diese Standardklasse wird dank Police-Map auf geeigneten Schnittstellen konfiguriert. Beide Wege sollten also das gleiche Ergebnis haben.

Aber heute habe ich etwas gesehen, das mich nervös gemacht hat. Ich habe so etwas wie CBWFQ mit Fair-Queue-Anweisung in Class-Default gesehen. Zur besseren Erklärung Beispiel.

policy-map test
 class test
  bandwidth remaining percent 20
  random-detect dscp-based
 class test2
  bandwidth remaining percent 20
  random-detect dscp-based
 class test3
  bandwidth remaining percent 20
  random-detect dscp-based
 class test4
  bandwidth remaining percent 20
  random-detect dscp-based
 class class-default
  fair-queue
  queue-limit 1024 packets
policy-map shape-test
 class class-default
  shape average xxx
  service-policy test

Hier beginnt meine Frage ... Bedeutet das, dass der Typ, der den Klassenstandard mit 'fair-queue', 'queue-limit 1024 pakete' konfiguriert hat, aus CBWFQ normalem WFQ hergestellt wurde? Gleich wie wir es auf der Schnittstelle konfigurieren können? Und nur die WFQ-Klassen fest angegeben, anstatt automatisch anzugeben, was Cisco-Geräte tun?

Aber warum? Es sieht nicht nach einer Standardlösung aus, oder? Es ist möglich, dass der Mann nicht wusste, was er tat ...

Vielen Dank für jede Antwort oder für Links, die mich darauf hinweisen könnten, sie richtig zu verstehen!

Daniel

Um meine Kommentare zusammenzufassen:

Der Vorteil der Verwendung von CBWFQ (klassenbasierte gewichtete faire Warteschlange) mit der fair-queueAnweisung in der class-defaultWarteschlange (Ihr zweites Beispiel):

...
 class class-default
  fair-queue
  queue-limit 1024 packets
...

• Pakete verwenden WFQ (Weighted Fair Queuing) für die Planung und werden basierend auf ihrem berechneten Gewicht aus der Warteschlange entfernt.

Wenn Sie CBWFQ ohne die fair-queueAnweisung in der class-defaultWarteschlange verwenden (Ihr erstes Beispiel):

...
 class class-default
  bandwidth remaining percent 20
  random-detect dscp-based      
...

• Pakete werden mit der FIFO- Methode (First In First Out) aus der Warteschlange entfernt .