Inhalt

Einführung

Voraussetzungen

Anforderungen

Verwendete Komponenten

Konventionen

Anwenden von Warteschlangen auf Schnittstellen mit einer Vielzahl von Bandbreiten

CBWFQ und LLQ auf Dialer-Schnittstellen

LLQ und CBWFQ mit verteiltem MLPPP

CBWFQ und LLQ mit PPPoA und MLPPPoA

Zugehörige Informationen

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.

Beispielkonfiguration

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:

QoS

Aktivierung

Sofern unterstützt

Bei Verarbeitung

RSP-basiert

Automatischer Zugriff auf ältere Schnittstellenprozessoren.

Ältere Schnittstellenprozessoren. Auf VIPs kann nicht mehr aktiviert werden.

RSP-CPU

VIP-basiert (verteilt)

Automatische Konfiguration dieser beiden Befehle:

- Der Befehl ip cef distributed im globalen Konfigurationsmodus.

- Der Befehl ip route-cache distributed im Schnittstellenkonfigurationsmodus.

VIPs

VIP-CPU

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:

Beispielkonfiguration von dLLQ auf einer MLPPP-Paketschnittstelle

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