Konfigurieren von CBWFQ und LLQ auf MLPPP- und Dialer-Schnittstellen

Einführung

Der Befehl service-policy wendet in der Regel eine Richtlinienzuordnung an, die mit den Befehlen der modularen QoS-CLI (MQC) konfiguriert wurde, und zwar auf eine Hauptschnittstelle, Subschnittstelle oder einen virtuellen Schaltkreis. Sie können diesen Befehl auch auf eine virtuelle Vorlagenschnittstelle, eine Multilink-Schnittstelle und eine Dialer-Schnittstelle anwenden, die mit PPP-Kapselung (Point-to-Point Protocol) und Multilink PPP (MLPPP) konfiguriert ist. Diese Schnittstellen führen zu einer Schnittstelle für den virtuellen Zugriff, in der die Warteschlangenverwaltung funktionell erfolgt. Dieses Dokument bietet eine zentrale Referenz für das Verständnis empfohlener Konfigurationen und damit zusammenhängender Probleme, um Class-Based Weighted Fair Queuing (CBWFQ) und Low Latency Queuing (LLQ) auf MLPPP-Paketschnittstellen und Dialer-Schnittstellen anzuwenden.

Voraussetzungen

Anforderungen

Für dieses Dokument bestehen keine besonderen Voraussetzungen.

Verwendete Komponenten

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

Konventionen

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

Anwenden von Warteschlangen auf Schnittstellen mit einer Vielzahl von Bandbreiten

RFC 1990 definiert Multilink-PPP, die eine oder mehrere physische Schnittstellen in einer virtuellen "Bündelschnittstelle" kombiniert. Die Bandbreite der Paketschnittstelle ist gleich der Summe der Bandbreite der Komponentenverbindungen. Die Paketschnittstelle hat daher einen maximalen Bandbreitenwert, der zu einem bestimmten Zeitpunkt variiert.

Ursprünglich unterstützten die Befehle Bandbreite und Priorität nur einen absoluten Kbit/s-Wert. Wenn Sie eine Service-Richtlinie mit CBWFQ und LLQ auf eine Paketschnittstelle angewendet haben und die erste aktive Schnittstelle den absoluten Kbit/s-Wert nicht unterstützt hat, hat die Service-Richtlinie die Zugangskontrolle nicht unterstützt. Der Router hat die Service-Richtlinie entfernt und ähnliche Fehlermeldungen ausgegeben:

May 18 17:32:34.766 MEST: CBWFQ: Not enough available bandwidth for all 
classes Available 48 (kbps) Needed 96 (kbps) 
May 18 17:32:34.766 MEST: CBWFQ: Removing service policy on Dialer100

Ab der Cisco IOS® Software-Version 12.2T versucht der Router nun, die Richtlinie erneut anzuwenden, wenn er feststellt, dass dem Paket eine zusätzliche Schnittstelle (z. B. ein zweiter BRI-B-Kanal) hinzugefügt wurde. Ein überlegener Ansatz besteht darin, die Priorität und die Bandbreitenbefehle als Prozentsatz der verfügbaren Bandbreite zu konfigurieren. Durch die Verwendung eines Prozentwerts wird der Router so konfiguriert, dass eine relative Bandbreite zugewiesen wird, die angepasst wird, da das Paket mindestens eine Mitgliedsverbindung enthält. In der Cisco IOS Software-Version 12.2(2)T wurde der Befehl priority percentage (Prioritätsprozentsatz) auf Cisco Routern der Serie 7500 und anderen Plattformen unterstützt. Weitere Informationen finden Sie unter Low Latency Queuing with Priority Percentage Support (Low Latency Queuing mit Prioritätsprozentsatz-Unterstützung).

CBWFQ und LLQ auf Dialer-Schnittstellen

Das DFÜ-Routing (Dial-on-Demand Routing, DDR) kann auf zwei Arten konfiguriert werden:

• Legacy DDR: Wendet die Wählparameter und die Protokollparameter direkt auf die physische Schnittstelle an.

• Dialer-Profile - Wendet die Wählparameter und Protokollparameter dynamisch auf eine Dialer-Schnittstelle an, die wiederum an physische Schnittstellen gebunden ist. Beispielsweise umfasst eine Dialer-Schnittstelle eine oder mehrere Wählzeichenfolgen, um einen Remote-Standort zu erreichen, einen PPP-Authentifizierungstyp und MLPPP.

Ursprünglich wurde das Legacy-DDR erst in der FIFO-Warteschlange (First Out) unterstützt, wenn eine serielle oder ISDN-Schnittstelle mit MLPPP konfiguriert wurde. Diese Einschränkung galt auch dann, wenn die beiden Enden der Verbindung kein MLPPP aushandeln und die physische Schnittstelle als nicht-bündelte Schnittstelle verwendet wurde, die die PPP-Kapselung ausführt. Herkömmliches Weighted Fair Queuing (WFQ) über den Befehl Fair Queue wird nun unterstützt.

Wenn Sie Dialer-Profile konfigurieren möchten, unterstützen sowohl die Dialer-Schnittstelle als auch die zugrunde liegenden physischen Schnittstellen den Befehl service-policy. Wenn Sie eine Richtlinie auf die physische Schnittstelle anwenden, geben Sie entweder den Befehl show policy-map interface serial oder den Befehl show policy-map interface bri 0/0:1 (und bri0/0:2) ein, um die Konfiguration zu bestätigen. Der in IOS als BRI0/0 bezeichnete D-Kanal unterstützt die Signalisierung und nicht den Datenverkehr. Wenn Sie eine Richtlinie auf die Dialer-Schnittstelle anwenden, geben Sie den Befehl show queueing interface dial <0-255> ein, um die Konfiguration zu bestätigen.

Mit den Cisco IOS Software-Versionen 12.2(4) und 12.2(4)T wurde die Unterstützung von Warteschlangen-basierten Service-Richtlinien für virtuelle Zugriffsschnittstellen eingeführt, die über eine mit MLPPP konfigurierte Dialer-Schnittstelle erstellt wurden. In früheren Versionen werden die Service-Richtlinienparameter nicht in die geklonte Virtual-Access-Schnittstelle kopiert, in der die Warteschlange tatsächlich stattfindet. Diese Ausgabe veranschaulicht diese Symptome:

Router#show policy interface dialer1
  Dialer1 
   Service-policy output: foo 

     Class-map: class-default (match-any) 
       0 packets, 0 bytes 
       5 minute offered rate 0 bps, drop rate 0 bps 
       Match: any 
       Weighted Fair Queueing 
         Flow Based Fair Queueing 
         Maximum Number of Hashed Queues 256 
         (total queued/total drops/no-buffer drops) 0/0/0 

Router#show policy interface virtual-access 2
 Router#

Hinweis: Cisco IOS Software Release 12.2(8) und 12.2(8)T werden empfohlen, um die Cisco Bug-ID CSCdu87408 zu vermeiden, durch die Router-Reloads als seltene Nebenwirkung dieser Konfiguration aufgelöst werden.

Diese Beispielkonfiguration zeigt, wie CBWFQ und LLQ auf eine Dialer-Schnittstelle angewendet werden. Diese Konfiguration bietet folgende Vorteile:

• Verwendet eine Dialer-Schnittstelle, um die Protokoll-Parameter der Verbindung dynamisch auf die ISDN BRI-Schnittstellen anzuwenden. Die Dialer-Schnittstelle soll an die ISDN BRI-Schnittstellen "gebunden" sein.

• Platziert zwei ISDN BRI-Schnittstellen in einem Multilink-Paket.

• Nutzt die Last-Grenzwert-Last für den Dialer [ausgehend | Eingehend | Entweder] festlegen, wann der Router zusätzliche B-Kanäle aktivieren und die Bandbreite der Paketschnittstelle erhöhen muss.

• Erstellt eine Virtual-Access-Schnittstelle mit dem ppp-Multilink-Befehl.

• Wendet über die Dialer-Schnittstelle eine Service-Richtlinie mit CBWFQ und LLQ auf die Virtual Access Interface an.

access-list 101 permit udp any any range 16384 32767
access-list 101 permit tcp any any eq 1720
!
access-list 102 permit tcp any any eq 23
! 
class-map voice
    match access-group 101

!--- Traffic that matches ACL 101 is classified as class voice.

class-map data
    match access-group 102

!--- Traffic that matches ACL 102 is classified as class data.

policy-map mlppp 
   class voice 
      priority percent 50 
   class data 
      bandwidth percent 25 
   class class-default 
     fair-queue 
!
interface BRI2/1  
  no ip address  
  encapsulation ppp  
  dialer pool-member 1  

!--- Member of dialer pool 1.

  isdn switch-type basic-net3  
  no cdp enable  
  ppp authentication chap  
! 
interface BRI2/2 
  no ip address  
  encapsulation ppp  
  dialer pool-member 1  

!--- Member of dialer pool 1.

  isdn switch-type basic-net3  
  no cdp enable  
  ppp authentication chap  
!  
interface Dialer2  
  ip unnumbered Loopback0  
  encapsulation ppp  
  dialer pool 1  
  dialer load-threshold 1 either  
  
!--- Load level (in either direction) for !--- traffic at which additional connections !--- are added to the MPPP bundle !--- load level values that range from 1 (unloaded) !--- to 255 (fully loaded).

  dialer string 6113 
  dialer string 6114  
  dialer-group 1  
  ppp authentication chap  
  ppp multilink  

!--- Allow MLPPP for the four BRI channels.

  service-policy output mlppp 
  
!--- Apply the service policy to the dialer interface.

LLQ und CBWFQ mit verteiltem MLPPP

Die Cisco 7500-Serie verwendet eine verteilte Architektur, die einen hohen Paketdurchsatz sicherstellt, indem die Entscheidungen zur Paketweiterleitung vom Route Switch Processor (RSP) auf die VIPs (Versatile Interface Processors) verschoben werden. Diese Architektur ermöglicht auch die Bereitstellung umfangreicher erweiterter IP-Services, wie z. B. QoS, indem die Verarbeitungslast auf mehrere unabhängige Prozessoren der VIPs verteilt wird.

Basierend auf der Schnittstellenhardware unterstützt die Cisco Serie 7500 zwei QoS-Formen:

Die VIP-basierten QoS-Mechanismen, die über die modulare QoS-CLI (MQC) angewendet werden, werden in den folgenden drei Cisco IOS Software-Release-Zügen eingeführt:

• Cisco IOS Software Release 12.0(XE), die Cisco IOS Software Version 12.1(E) wurde

• Cisco IOS Softwareversion 12.0(9)S

• Cisco IOS Software Release 12.1(5)T, die zum Cisco IOS Software Release 12.2 Mainline und zur Cisco IOS Software Version 12.2T wurde

Mit der verteilten MLPPP-Funktion können Sie die Bandbreite mehrerer T1/E1-Schnittstellen auf einem VIP in einer Paketschnittstelle kombinieren. Weitere Informationen finden Sie unter Distributed Multilink Point-to-Point Protocol für Cisco Router der Serie 7500. Die Cisco IOS Software-Version 12.2(13)T bietet Unterstützung für verteiltes MLPPP (dMLPPP) auf nicht-Channelized Port-Adaptern wie PA-4T+ und PA-8T.

Mit der Cisco IOS Software-Version 12.2(8)T wurde die Unterstützung für verteilte LLQ- und CBWFQ-Schnittstellen auf dMLPPP-Paketschnittstellen auf Channelized Port-Adaptern wie PA-MC-xT1/E1 und PA-MC-xT3/E3 eingeführt. Wie die nicht verteilte Version dieser Funktion verwendet dMLPPP eine Schnittstelle Multilink, um eine Schnittstelle für den virtuellen Zugriff zu erstellen, in der die Warteschlange funktionell stattfindet. Weitere Informationen zu Cisco IOS Software, Version 12.2T, finden Sie unter Neue und geänderte Informationen. Wenn Sie verteilte Warteschlangen mit dMLPPP anwenden, wird die Cisco IOS Software Version 12.2(10)T oder höher empfohlen, um die Cisco Bug-ID CSCdw47678 zu vermeiden.

Mit dMLPPP/dLFI werden nur CBWFQ und LLQ unterstützt, die mit dem Befehl service-policy angewendet werden. Legacy-Warteschlangenfunktionen wie Fair Queuing mit dem Befehl fair queue, Priority Queuing mit dem Befehl priority-group und benutzerdefiniertes Queuing mit dem Befehl queue-list werden nicht unterstützt.

Das FlexWAN für die Cisco 7600-Serie unterstützt dLLQ an Schnittstellen, die keine Pakete sind. Sie unterstützt keine dLLQ für MLPPP-Paketschnittstellen. Diese Unterstützung ist für die Cisco IOS Software, Version 12.2S, verfügbar.

Bei dieser Beispielkonfiguration wird dLLQ auf eine Schnittstelle mit mehreren Verbindungen angewendet:

Interface 
! 
access-list 100 permit udp any any range 16384 32000
access-list 100 permit tcp any any eq 1720
access-list 101 permit tcp any any eq 80
access-list 102 permit tcp any any eq 23
!
class-map voip 
   match access-group 100
class-map data1
    match access-group 101
class-map data2 
    match access-group 102
!
policy-map llq-policy
    class voip 
     bandwidth 40 
    class data1 
     bandwidth 15 
    class data2 
     bandwidth 15
    class class-default 
     fair-queue
!
policy-map set-policy
    class voip 
     bandwidth 40 
    class data1 
     bandwidth 15
    class data2 
     bandwidth 15 
    class class-default 
     fair-queue
!
interface Serial5/0/0:0 
   no ip address 
   encapsulation ppp 
   keepalive 10 
   ppp chap hostname G2 
   ppp multilink 
   multilink-group 2 
!  
interface Serial5/1/0:0 
  no ip address 
  encapsulation ppp 
  keepalive 10 
  ppp chap hostname G2 
  ppp multilink 
  multilink-group 2 
!  
interface Multilink2 
  ip address 106.0.0.2 255.0.0.0 
  ppp multilink 
  service-policy output llq-policy 
  service-policy input set-policy 
  multilink-group 2

Link Fragmentation and Interleaving (LFI) fügt die Befehle für die ppp-Multilink-Fragmentierung-Verzögerung und für die Multilink-Interleaving zu einer virtuellen Schnittstellenvorlage hinzu, die mit MLPPP und einer Service-Richtlinie konfiguriert wurde. Diese Konfiguration reduziert Verzögerungen bei langsameren Verbindungen, indem große Datagramme aufgebrochen werden und Pakete mit niedriger Verzögerung mit kleineren Paketen, die aus dem fragmentierten Datagramm resultieren, verbunden werden. Weitere Informationen finden Sie unter Konfigurieren der Link-Fragmentierung und -Verschachtelung für Frame-Relay und virtuelle ATM-Schaltungen.

Mit der Cisco IOS Software-Version 12.2(8)T wurde die Unterstützung für verteilte LFI (dLFI)-überkanalisierte serielle Leitungen der Cisco Serie 7500 mit VIPs eingeführt. Diese Funktion ist auch bei Catalyst Switches der Serie 6500 und Cisco Routern der Serie 7600 verfügbar. Informationen zu den Versionen, die dLFI unterstützen, finden Sie im Feature Navigator Tool (nur registrierte Kunden) und in den Versionshinweisen für die jeweiligen Produkte. Weitere Informationen zu dieser Funktion finden Sie unter Verteilte Link-Fragmentierung und Verschachtelung über Mietleitungen.

Das FlexWAN für die Cisco Serie 7600 mit Cisco IOS Software Release Train 12.1E unterstützt kein dLFI.

Nachdem Sie die maximale Fragmentverzögerung mit dem Befehl ppp multilink fragment-delay <msec> konfiguriert haben, berechnet die dLFI-Funktion die tatsächliche Fragmentgröße auf kanalisierten seriellen Schnittstellen mithilfe dieser Formel (wobei die Bandbreite in Kbit/s liegt):

fragment size = bandwidth x fragment-delay  / 8

Darüber hinaus wird die Fragmentgröße basierend auf der Memberverbindung mit der kleinsten Bandbreitenmenge berechnet. In einer Konfiguration mit Memberverbindungen von 64.000 und 128.000 wird die Fragmentgröße auf Basis der 64.000 Verbindung berechnet.

CBWFQ und LLQ mit PPPoA und MLPPPoA

Mit der Cisco IOS Software-Version 12.2(8) wurde die Unterstützung von Per-VC-Warteschlangen auf virtuellen ATM-Schaltungen eingeführt, die mit einer PPP over ATM (PPPoA)-Kapselung konfiguriert wurden. Diese Unterabschnitte enthalten Konfigurationsbeispiele für Class-Based Marking, Policing und Queuing.

1. Klassenbasierte Markierung

Der Befehl service-policy kann zur klassenbasierten Markierung an die Virtual-Template-Schnittstelle oder ATM PVC angeschlossen werden.

In diesem Beispiel wird die Klassenzuordnung PEER2PEER definiert, die Richtlinienzuordnung MARK_PEER2PEER erstellt und der DSCP-Standardwert für die Klasse PEER2PEER konfiguriert. dann wird die Service-Richtlinie der virtuellen Vorlage oder dem ATM-PVC zugeordnet.

Router(config)#class-map PEER2PEER
Router(config-cmap)#match access-group 100
Router(config-cmap)#exit

Router(config)#policy-map MARK_PEER2PEER
Router(config-pmap)#class PEER2PEER
Router(config-pmap-c)#set dscp default
Router(config-pmap-c)#end


Attaching Service-policy to Virtual Template


Router(config-subif)#int atm1/0.1 point-to-point
Router(config-subif)#ip address 10.10.10.1 255.255.255.0
Router(config-subif)#pvc 1/50
Router(config-if-atm-vc)#encapsulation aal5mux ppp virtual-Template 1

Router(config)#interface Virtual-Template1
Router(config-if)#ip address negotiated
Router(config-if)#service-policy output MARK_PEER2PEER 


Attaching Service-policy to ATM pvc

Router(config)#int atm1/0.1 point-to-point
Router(config-subif)#ip address 10.10.10.1 255.255.255.0
Router(config-subif)#pvc 1/50
Router(config-if-atm-vc)#service-policy output MARK_PEER2PEER

2. Klassenbasiertes Policing:

Der Befehl service-policy kann zur klassenbasierten Richtlinienzuweisung an die Virtual-Template-Schnittstelle oder an ATM pvc angeschlossen werden.

Router(config)#policy-map POLICE_PEER2PEER
Router(config-pmap)#class PEER2PEERRouter(config-pmap-c)#police 8000 conform-action transmit exceed-action drop

Attaching Service-policy to Virtual Template

Router(config-subif)#int atm1/0.2 multipoint
Router(config-subif)#no ip address
Router(config-subif)#pvc 1/100
Router(config-if-atm-vc)#encapsulation aal5mux ppp virtual-Template 2

Router(config)#interface Virtual-Template2
Router(config-if)#ip address negotiated
Router(config-if)#service-policy output POLICE_PEER2PEER 



Attaching Service-policy to ATM pvc

Router(config)#int atm1/0.2 multipoint
Router(config-subif)#no ip address
Router(config-subif)#pvc 1/100
Router(config-if-atm-vc)#service-policy output POLICE_PEER2PEER

3. Klassenbasiertes Queuing:

Für Class-Based Queuing, d. h. Bandbreite, Form, Priorität und willkürliche Erkennung, kann der Service-Policy-Befehl an die virtuelle Vorlage oder die ATM-PVC angefügt werden.

Router(config)#policy-map QUEUE_PEER2PEER
 Router(config-pmap)#class PEER2PEER
 Router(config-pmap-c)#bandwidth 768

Attaching Service-policy to Virtual Template

Router(config-subif)#int atm1/0
Router(config-subif)#no atm ilmi-keepalive
Router(config-subif)#pvc 1/150
Router(config-if-atm-vc)#encapsulation aal5mux ppp virtual-Template 3

Router(config)#interface Virtual-Template3
Router(config-if)#ip address negotiated
Router(config-if)#service-policy output QUEUE_PEER2PEER

Attaching Service-policy to ATM pvc 

Router(config)#int atm1/0
Router(config-subif)#no atm ilmi-keepalive
Router(config-subif)#pvc 1/150
Router(config-if-atm-vc)#service-policy output QUEUE_PEER2PEER

Hinweis: Wenn Sie eine Kombination aus klassenbasiertem Marking oder klassenbasiertem Policing und klassenbasiertem Queuing verwenden, lautet die Reihenfolge der Vorgänge:

1. Der auf der Virtual-Template-Schnittstelle konfigurierte Service-Policy-Befehl markiert oder regelt die Pakete.

2. Der Service-Policy-Befehl auf der ATM-PVC stellt die Pakete in die Warteschlange.

Siehe folgendes Beispiel:

policy-map MARK_PEER2PEER
  class PEER2PEER
   set dscp default
! 
 interface ATM0/0
 no ip address
 no atm ilmi-keepalive
 pvc 1/100
  encapsulation aal5mux ppp Virtual-Template1
  service-policy output QUEUE_PEER2PEER
!
interface Virtual-Template1 
ip address negotiate
service-policy output MARK_PEER2PEER

Wenn Sie eine frühere Version der Cisco IOS-Software ausführen, können Sie für ATM VC eine MLPPPoA-Kapselung konfigurieren und eine Warteschlangenbasierte Servicerichtlinie auf die Virtual-Template-Schnittstelle anwenden. Weitere Informationen finden Sie unter Link Fragmentation and Interleaving for Frame Relay and ATM Virtual Circuits und unter Übersicht über Verbindungseffizienzmechanismen.

In der Cisco IOS Software-Version 12.2(4)T3 wird eine verteilte Version dieser Funktion für die Cisco 7500-Serie eingeführt. Weitere Informationen zu dieser Funktion finden Sie unter Distributed Link Fragmentation and Interleaving für ATM und Frame Relay.

Zugehörige Informationen

• Class-Based, Weighted Fair Queuing (Per-VC CBWFQ) auf den Cisco Routern 7200, 3600 und 2600
• Low Latency Queuing
• QoS-Technologieunterstützung
• Technischer Support und Dokumentation - Cisco Systems