Quality of Service-Optionen auf GRE-Tunnelschnittstellen

Einleitung

In diesem Dokument wird geprüft, welche Quality of Service (QoS)-Funktionen mithilfe von Generic Routing Encapsulation (GRE) an Tunnelschnittstellen konfiguriert werden können. Mit IP Security (IPsec) konfigurierte Tunnel werden in diesem Dokument nicht behandelt.

Voraussetzungen

Anforderungen

Es gibt keine spezifischen Anforderungen für dieses Dokument.

Verwendete Komponenten

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

Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netz Live ist, überprüfen Sie, ob Sie die mögliche Auswirkung jedes möglichen Befehls verstehen.

Konventionen

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

Überblick über die GRE

Bevor Sie mehr über QoS über GRE-Tunnel erfahren, müssen Sie zunächst das Format eines getunnelten Pakets verstehen.

Eine Tunnelschnittstelle ist eine virtuelle oder logische Schnittstelle auf einem Router, auf dem die Cisco IOS® Software ausgeführt wird. Es wird eine virtuelle Point-to-Point-Verbindung zwischen zwei Cisco Routern an Remote-Punkten über ein IP-Netzwerk erstellt.

GRE ist ein von IOS unterstütztes und in RFC 1702 definiertes Kapselungsprotokoll. Tunneling-Protokolle kapseln Pakete innerhalb eines Transportprotokolls ein.

Eine Tunnelschnittstelle unterstützt einen Header für jede der folgenden Aufgaben:

• Passagierprotokoll oder gekapseltes Protokoll, z. B. IP, AppleTalk, DECnet oder IPX.

• Ein Trägerprotokoll (hier GRE).

• Ein Transportprotokoll (hier nur IP).

Das Format eines Tunnelpakets wird hier veranschaulicht:

Weitere Informationen zum Konfigurieren von GRE-Tunneln finden Sie unter Configuring Logical Interfaces (Logische Schnittstellen konfigurieren).

Cisco QoS für GRE-Tunnel

Eine Tunnelschnittstelle unterstützt viele der gleichen QoS-Funktionen wie eine physische Schnittstelle. In diesen Abschnitten werden die unterstützten QoS-Funktionen beschrieben.

Formgebung

Seit Version 12.0(7)T der Cisco IOS Software besteht Unterstützung für die direkte Anwendung von Generic Traffic Shaping (GTS) an der Tunnelschnittstelle. Die folgende Beispielkonfiguration formt die Tunnelschnittstelle auf eine Gesamtausgangsrate von 500 Kbit/s. Weitere Informationen finden Sie unter Configuring Generic Traffic Shaping (Konfigurieren von generischem Datenverkehr).

interface Tunnel0 
  ip address 130.1.2.1 255.255.255.0 
  traffic-shape rate 500000 125000 125000 1000 
  tunnel source 10.1.1.1 
  tunnel destination 10.2.2.2

Die Cisco IOS Software, Version 12.1(2)T, bietet jetzt Unterstützung für klassenbasiertes Shaping über die modulare QoS-Kommandozeile (MQC). Die folgende Beispielkonfiguration zeigt, wie die gleiche Shaping-Richtlinie mit den MQC-Befehlen auf die Tunnelschnittstelle angewendet wird. Weitere Informationen finden Sie unter Configuring Class-Based Shaping (Klassenbasiertes Shaping konfigurieren).

policy-map tunnel 
  class class-default 
    shape average 500000 125000 125000 
interface Tunnel0 
  ip address 130.1.2.1 255.255.255.0 
  service-policy output tunnel 
  tunnel source 130.1.35.1 
  tunnel destination 130.1.35.2

Richtlinien

Wenn eine Schnittstelle überlastet ist und die Pakete in die Warteschlange gestellt werden, können Sie eine Warteschlangenmethode auf die zu übertragenden Pakete anwenden. Logische Cisco IOS-Schnittstellen unterstützen nicht automatisch den Zustand der Überlastung und nicht die direkte Anwendung einer Service-Richtlinie, die eine Warteschlangenmethode anwendet. Stattdessen müssen Sie eine hierarchische Richtlinie wie folgt anwenden:

1. Erstellen Sie eine Richtlinie der untergeordneten Ebene, die einen Warteschlangenmechanismus konfiguriert, z. B. Warteschlangen mit niedriger Latenz mit dem Prioritätsbefehl und klassenbasiertes Weighted Fair Queueing (CBWFQ) mit dem Bandbreiten-Befehl. Weitere Informationen finden Sie unter Überlastungsmanagement.

   policy-map child 
    class voice 
     priority 512

2. Erstellen Sie eine übergeordnete Richtlinie oder eine Richtlinie der obersten Ebene, die klassenbasiertes Shaping anwendet. Wenden Sie die untergeordnete Richtlinie als Befehl unter der übergeordneten Richtlinie an, da die Zugangskontrolle für die untergeordnete Klasse auf der Grundlage der Shaping-Rate für die übergeordnete Klasse erfolgt.

   policy-map tunnel 
    class class-default 
     shape average 2000000 
     service-policy child 

3. Wenden Sie die übergeordnete Richtlinie auf die Tunnelschnittstelle an.

   interface tunnel0 
      service-policy tunnel

Der Router druckt diese Protokollmeldung, wenn eine Tunnelschnittstelle mit einer Dienstrichtlinie konfiguriert wird, die Warteschlangen ohne Shaping anwendet.

router(config)# interface tunnel1
router(config-if)# service-policy output child
 Class Based Weighted Fair Queueing not supported on this interface

Tunnelschnittstellen unterstützen auch klassenbasiertes Policing, jedoch keine Committed Access Rate (CAR).

Hinweis: Servicerichtlinien werden an Tunnelschnittstellen auf dem 7500 nicht unterstützt.

Überlastungsvermeidung

In Version 11.3T der Cisco IOS Software wurden GRE Tunnel Marking und DSCP- bzw. IP Precedence Values eingeführt, wodurch der Router so konfiguriert wird, dass er die IP-Rangfolgebitwerte des ToS-Byte in den Tunnel- bzw. GRE-IP-Header kopiert, der das innere Paket kapselt. Früher wurden diese Bits auf Null gesetzt. Zwischengeschaltete Router zwischen den Tunnelendpunkten können die IP-Rangfolgewerte verwenden, um Pakete für QoS-Funktionen wie Richtlinienrouting, WFQ und Weighted Random Early Detection (WRED) zu klassifizieren.

Der Befehl qos pre-classify

Wenn Pakete durch Tunnel- oder Verschlüsselungs-Header gekapselt werden, können die QoS-Funktionen die ursprünglichen Paket-Header nicht untersuchen und die Pakete nicht richtig klassifizieren. Pakete, die über denselben Tunnel übertragen werden, haben dieselben Tunnel-Header, sodass die Pakete bei Überlastung der physischen Schnittstelle identisch behandelt werden. Mit der Einführung der Quality of Service für Virtual Private Networks (VPNs)-Funktion können Pakete jetzt vor dem Tunneling und der Verschlüsselung klassifiziert werden.

In diesem Beispiel ist tunnel0 der Tunnelname. Der Befehl qos pre-classify aktiviert die Funktion QoS für VPNs in tunnel0:

Router(config)# interface tunnel0
Router(config-if)# qos pre-classify

Anmerkung:  Der Befehl qos pre-classify kann verwendet werden, um Datenverkehr auf der Grundlage anderer Werte als IP-Rangfolge oder DSCP zu klassifizieren. Sie können Pakete z. B. anhand des IP-Datenflusses oder Layer-3-Informationen klassifizieren, z. B. anhand der Quell- und Ziel-IP-Adresse, für die dieser Befehl verwendet werden kann. Der Befehl qos pre-classify ist nur erforderlich, wenn Sie den Datenverkehr über IP, Protokoll oder Port klassifizieren. Wenn die Klassifizierung auf DSCP-Code basiert, ist keine QoS-Vorklassifizierung erforderlich.

Charakterisierung des Datenverkehrs für QoS-Richtlinien

Beim Konfigurieren einer Service-Richtlinie müssen Sie zunächst möglicherweise den Datenverkehr charakterisieren, der den Tunnel durchquert. Cisco IOS unterstützt NetFlow und IP Cisco Express Forwarding (CEF) Accounting an logischen Schnittstellen wie Tunneln. Weitere Informationen finden Sie im NetFlow Services Solutions Guide.

Wo wende ich die Servicerichtlinie an?

Sie können eine Servicerichtlinie entweder auf die Tunnelschnittstelle oder auf die zugrunde liegende physische Schnittstelle anwenden. Die Entscheidung, wo die Richtlinie angewendet wird, hängt von den QoS-Zielen ab. Es hängt auch davon ab, welchen Header Sie für die Klassifizierung verwenden müssen.

• Wenden Sie die Richtlinie ohne QoS-Preclassify auf die Tunnelschnittstelle an, wenn Sie Pakete anhand des Pre-Tunnel-Headers klassifizieren möchten.

• Wenden Sie die Richtlinie auf die physische Schnittstelle ohne QoS-Preclassify an, wenn Sie Pakete basierend auf dem Post-Tunnel-Header klassifizieren möchten. Wenden Sie die Richtlinie außerdem auf die physische Schnittstelle an, wenn Sie den gesamten Datenverkehr eines Tunnels steuern möchten, und die physische Schnittstelle unterstützt mehrere Tunnel.

• Wenden Sie die Richtlinie auf eine physische Schnittstelle an, und aktivieren Sie QoS-Preclassify auf einer Tunnelschnittstelle, wenn Sie Pakete anhand des Pre-Tunnel-Headers klassifizieren möchten.

Multipoint-Tunnelschnittstellen

Das klassenbasierte Shaping von CBWFQ wird auf einer Multipoint-Schnittstelle nicht unterstützt. Cisco Bug-ID CSCds87191 konfiguriert den Router so, dass er eine Fehlermeldung ausgibt, wenn die Richtlinie abgelehnt wird.

Bekannte Probleme

In seltenen Fällen führt die Anwendung einer mit dem Befehl shape konfigurierten Dienstrichtlinie zu hoher CPU-Auslastung und Ausrichtungsfehlern. Die CPU-Last wird durch die Protokollierung von Ausrichtungsfehlern verursacht, die wiederum durch das falsche Einstellen der Ausgabeschnittstelle und der Umschreibungsinformationen der Adjacency verursacht werden. Dieses Problem betrifft nur Nicht-RSP-Plattformen (Low-End) und Plattformen, die teilchenbasiertes CEF-Switching verwenden, und wird über die Cisco Bug-IDs CSCdu4504 und CSCuk30302 behoben. Sie können auch diese Problemumgehungen in Betracht ziehen:

• Ersetzen Sie die GRE-Kapselung durch ipip im Tunnelmodus.

• Ersetzen Sie den Befehl shape durch den Befehl police.

• Konfigurieren Sie das Shaping auf der physischen Schnittstelle, die den Tunnel unterstützt.

Zugehörige Informationen

• Quality of Service für virtuelle private Netzwerke
• Konfigurieren des GRE-Tunnels über Kabel
• QoS-Technologie-Support
• Konfigurieren eines GRE-Tunnels über IPSec mit OSPF
• Technischer Support und Dokumentation für Cisco Systeme