Informationen darüber, wie Routing-Updates und Layer-2-Steuerungspakete auf einer Schnittstelle mit einer QoS-Dienstrichtlinie in Warteschlange gestellt werden

Einführung

In diesem Dokument wird erläutert, wie Routing-Protokollmeldungen wie Hellos und Datenbankdeskriptoren sowie anderer wichtiger Kontrolldatenverkehr in die Warteschlange gestellt werden, wenn eine ausgehende Router-Schnittstelle mithilfe von Befehlen der MQC (Modular Quality of Service Command Line Interface) mit einer Dienstrichtlinie konfiguriert wird.

Im Einzelnen werden in diesem Dokument die folgenden beiden Mechanismen vorgestellt, die von Cisco IOS^® Routern zur Priorisierung von Steuerungspaketen verwendet werden:

Feld	Standort	Bei Berücksichtigung der Priorität
Bit mit IP-Rangfolge	Type of Service (TOS)-Byte im IP-Header	Bietet Netzwerkpriorität
pak_priority	Internes Paketlabel im Router, zugewiesen durch Schnittstellentreiber	Priorisierung über den Router (pro Hop)

Beide Mechanismen wurden entwickelt, um sicherzustellen, dass Schlüsselkontrollpakete nicht verworfen oder zuletzt vom Router und dem Warteschlangensystem verworfen werden, wenn eine ausgehende Schnittstelle überlastet wird.

Voraussetzungen

Anforderungen

Für dieses Dokument bestehen keine speziellen Anforderungen.

Verwendete Komponenten

Die Informationen in diesem Dokument basieren auf der Cisco IOS Software-Version 12.2.

Die Informationen in diesem Dokument wurden von den Geräten in einer bestimmten Laborumgebung erstellt. Alle in diesem Dokument verwendeten Geräte haben mit einer leeren (Standard-)Konfiguration begonnen. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die potenziellen Auswirkungen eines Befehls verstehen.

Konventionen

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

Tags für die externe Paketpriorisierung

Request for Comments (RFC) 791 definiert das TOS-Byte im Header eines IP-Pakets. Obwohl RFC 2474 und RFC 2475 dieses Byte als DSCP-Werte (Differentiated Services Code Point) neu definieren, verwendet ein Cisco IOS-Router weiterhin die ursprünglichen IP-Rangfolgebits des TOS-Bytes gemäß RFC 791. Beachten Sie, wie die RFC das TOS-Byte definiert:

"Der Type of Service gibt einen Hinweis auf die abstrakten Parameter der gewünschten Quality of Service. Diese Parameter sollen bei der Auswahl der tatsächlichen Dienstparameter für die Übertragung eines Datagramms durch ein bestimmtes Netzwerk verwendet werden. Mehrere Netzwerke bieten eine Dienstpriorität, wodurch Datenverkehr mit hoher Priorität als wichtiger behandelt wird als anderer Datenverkehr (in der Regel, wenn bei hoher Auslastung nur Datenverkehr über eine bestimmte Priorität hinausgeht)."

Wie im Diagramm gezeigt, belegt das Feld für die IP-Rangfolge die drei wichtigsten Bits des TOS-Bytes. Nur die drei IP-Prioritätsbits spiegeln die Priorität oder Wichtigkeit des Pakets wider, nicht den vollen Wert des TOS-Bytes.

In dieser Tabelle sind die Werte der Prioritätsbits aufgeführt:

Nummer	Bit-Wert	Name
0	000	Routine
1	001	Priorität
2	010	Sofort
1	011	Flash
4	100	Überschreiben von Flash
5	101	KRITIK/ECP
6	110	Internetwork Control
7	111	Netzwerkkontrolle

Cisco IOS weist Routing-Protokollpaketen auf der Kontrollebene eine IP-Priorität von 6 zu. RFC 791: "Die Bezeichnung "Internetwork Control" ist nur für die Verwendung durch Initiatoren der Gateway-Steuerung vorgesehen." Insbesondere markiert Cisco IOS die folgenden IP-basierten Steuerungspakete: Open Shortest Path First (OSPF), Routing Information Protocol (RIP), Enhanced Interior Gateway Routing Protocol (EIGRP)-Hellos und Keepalives. Telnet-Pakete vom und zum Router erhalten ebenfalls einen IP-Rangfolgewert von 6. Der zugewiesene Wert verbleibt bei den Paketen, wenn die Ausgabeschnittstelle sie in das Netzwerk überträgt.

Interne Tags zur Paketpriorisierung

Während der IP-Rangfolgewert die Behandlung eines Datagramms innerhalb seiner Übertragung über das Netzwerk angibt, gibt der pak_priority-Mechanismus die Behandlung eines Pakets während seiner Übertragung innerhalb des Routers an.

Neben dem Kern einer Router-CPU verwendet jede Schnittstelle einen Netzwerk-Controller oder eine lokale CPU, die eine spezielle Software namens Treiber ausführt. Der Treibercode enthält schnittstellenspezifische Anweisungen.

Wenn ein Paket empfangen wird, kopiert der Schnittstellentreiber das Paket aus einem kleinen FIFO-Puffer (First-In, First-Out) in einen Datenpuffer im E/A-Speicher (Input/Output). Anschließend wird ein kleiner Paket-Header an den Puffer angefügt. Der Paket-Header, der in der Cisco IOS-Terminologie als Paketstruktur bezeichnet wird, enthält wichtige Informationen zum Datenblock im Puffer. Je nach Inhalt des Pakets kann der Paket-Header auf die Adresse im Speicher verweisen, an der der Ethernet-Kapselungs-Header, der Internet Protocol (IP)-Header und der Transmission Control Protocol (TCP)-Header gestartet werden.

Die Cisco IOS-Software verwendet die Felder im Paket-Header, um die Behandlung des Pakets in Schnittstellenwarteschlangen zu steuern. Der Paket-Header enthält das Flag pak_priority, das die relative Bedeutung markierter Pakete für das Warteschlangensystem angibt.

Die RIP- und OSPF-Routing-Prozesse, die auf der Core-CPU eines Routers ausgeführt werden, markieren den gesamten Datenverkehr, der von ihnen ausgeht, sowohl mit der IP-Priorität 6 als auch mit der pak_priority. Im Gegensatz dazu weist das Border Gateway Protocol (BGP) TCP an, seinen Datenverkehr mit der IP-Priorität 6 zu kennzeichnen, legt jedoch keine pak_priority fest.

Cisco IOS muss auch eine geringe Verlustrate für verschiedene Arten von Nicht-IP-Steuerungspaketen sicherstellen. Zu diesen Pakettypen gehören:

• IS-IS-Nachrichten (Intermediate System-to-Intermediate System)

• EIGRP-Meldungen (Enhanced Interior Gateway Routing Protocol)

• Point-to-Point Protocol (PPP)- und High-Level Data Link Control (HDLC)-Keepalive-Verbindungen an seriellen und PoE-Schnittstellen (POS)

• OAM-Zellen (Operations, Administration and Maintenance) und ARP-Nachrichten (Address Resolution Protocol) an ATM-Schnittstellen

Da es sich bei diesem Datenverkehr nicht um IP-Datenverkehr handelt, kann Cisco IOS nicht mit dem IP-Rangfolgewert übereinstimmen, um eine Priorisierung zu ermöglichen. Stattdessen wird nur der interne Wert pak_priority im Paket-Puffer-Header verwendet.

Hinweis: Die Cisco Catalyst Switches der Serien 6000/7600 unterstützten zunächst nur das pak_priority-Verfahren für FlexWAN. Anschließend wurden Verbesserungen bei der Priorisierung von IP- und Nicht-IP-Kontrollpaketen implementiert.

Tags und Warteschlangen für die Paketpriorisierung

Router wie der Cisco 7500 Route/Switch Processor (RSP) und einfache Router (z. B. der Cisco 7200 und 3600) verwenden einen anderen Mechanismus zur Weiterleitung und Steuerung des Datenverkehrs als der Cisco 7500 VIP (Versatile Interface Processor). In dieser Tabelle werden die beiden Ansätze zusammengefasst. Es wird davon ausgegangen, dass eine mit dem MQC konfigurierte Dienstrichtlinie auf die ausgehende Schnittstelle angewendet wird.

Plattform	Warteschlangenverwaltung für pak_priority-Nachrichten
Cisco Serie 7500 (mit verteilter QoS und VIPs)	Platziert pak_priority-Datenverkehr standardmäßig in der Klassenstandardklassenwarteschlange oder in einer speziell konfigurierten (separaten) Warteschlange. Wenn Pakete in die Klassenstandardeinstellung gestellt werden, gehen sie zum Tail-End der Warteschlange. Das pak_priority-Flag dient dazu, das Verwerfen von Paketen mit hoher Priorität zu vermeiden.
RSP-basierte QoS und andere Plattformen, darunter die Cisco Serien 7200, 3600 und 2600	Platziert pak_priority-Datenverkehr in einem separaten Satz von Warteschlangen, die nicht der Klassenstandardeinstellung entsprechen. (Siehe Abschnitt "Spezielle Warteschlangen mit Nicht-RSP-Plattformen verstehen".) Markiert solche Nachrichten mit einem besonderen Gewichtungswert (derzeit 1024).

Mit anderen Worten: Wenn bei der Cisco Serie 7500 eine Richtlinie für Ausgabeservices an die Schnittstelle angehängt wird, werden die Pakete in Bezug auf die Klassen in dieser Richtlinie klassifiziert, und das Paket pak_priority wird am Ende der ausgewählten Klassenwarteschlange platziert. Wenn das pak_priority-Paket keiner benutzerdefinierten Klasse entspricht, wird es am Ende der Klassenstandardwarteschlange platziert.

Hinweis: Bei veralteten Warteschlangenmethoden wie Prioritätswarteschlange und benutzerdefinierter Warteschlangenverwaltung oder mit einer FIFO-Standardschnittstellen-Warteschlange (default interface, nicht RSP) geben die Router pak_priority-Meldungen an den Leiter der Warteschlange ein, um sowohl minimale Latenz als auch minimale Verlustrate sicherzustellen.

Spezielle Warteschlangen mit Plattform ohne RSP

Wie in der Tabelle für Paketpriorisierungs-Tags und Warteschlangen angegeben, platzieren Cisco Router-Plattformen wie die Cisco Serien 7200, 3600 und 2600 pak_priority-Meldungen in einem separaten Satz von Warteschlangen und nicht in der Klassenstandardgruppe von Warteschlangen.

Auf einer Schnittstelle stehen drei Warteschlangen-Sets zur Verfügung:

• 2^n Satz von Flow-basierten Warteschlangen, die Headerwerte als Quell- und Ziel-IP-Adressen berücksichtigen. Die tatsächliche Anzahl der Warteschlangen basiert auf der Bandbreite der Schnittstelle oder des virtuellen Schaltkreises. Weitere Informationen finden Sie in der Beschreibung des Befehls fair-queue in der Cisco IOS-Befehlsreferenz.

• Warteschlangen für benutzerdefinierte Klassen.

• Warteschlangen, auf die aufgrund eines Hashs des Verbindungstyps zugegriffen wird. IP-Mikroflows werden beispielsweise durch das Fair Queuing-System anhand eines Hashs aus Quell- und Zieladressen und -Ports, TOS-Bits und IP-Protokollnummer in Warteschlangen klassifiziert. Frame Relay Local Management Interface (LMI)-Meldungen werden auf Basis eines Hashs der magischen Nummer in die Warteschlange gestellt, der angibt, dass es sich bei der Nachricht um LMI handelt. Nachrichten mit dem Flag pak_priority gehen in diese separaten Warteschlangen des Verbindungstyps.

In dieser Tabelle sind die verschiedenen Warteschlangen und ihre Konversations-IDs (wie in der Ausgabe der show policy-map interface oder show queue-Commands zu sehen) für eine Schnittstelle mit einer Bandbreite von mehr als 512 Kbit/s aufgeführt.

Gespräche/Warteschlangennummer	Art des Datenverkehrs
1-256	Generelle datenflussbasierte Datenverkehrswarteschlangen. Datenverkehr, der nicht mit einer benutzerdefinierten Klassenzuordnung übereinstimmt, entspricht der Klassenstandardeinstellung und einer der Flow-basierten Warteschlangen.
257-263	Reserviert für Cisco Discovery Protocol und für Pakete, die mit einer internen Markierung mit hoher Priorität gekennzeichnet sind.
264	Reservierte Warteschlange für die Prioritätsklasse (Klassen, die mit dem priority-Befehl konfiguriert wurden). Suchen Sie in der Ausgabe der Richtlinienzuordnungs-Schnittstelle nach dem Wert "Strict Priority" (Strict-Priorität) für die Klasse. Die Prioritätswarteschlange verwendet eine Konversations-ID, die der Anzahl der dynamischen Warteschlangen plus 8 entspricht.
265 und höher	Warteschlangen für benutzerdefinierte Klassen.

Hinweis: Die Werte in dieser Tabelle sind implementierungsabhängig und können geändert werden.

IS-IS-Pakete priorisieren

Die Routing-Kontrollpakete von Intermediate System to Intermediate System (IS-IS) sind ein Sonderfall für Warteschlangen und Paketpriorisierung.

IS-IS ist das Routing-Protokoll für das Connectionless Network Protocol (CLNP) der International Organization for Standardization (ISO). Die Entwickler von CLNP betrachteten TCP/IP als vorläufige Protokoll-Suite, die durch die OSI-Suite (Open System Interconnection) ersetzt werden sollte. Zur Unterstützung dieses voraussichtlichen Übergangs wurde Integrated IS-IS (oder Dual IS-IS) als Erweiterung von IS-IS erstellt, um ein einziges Routing-Protokoll bereitzustellen, das sowohl Connectionless-Mode Network Service (CLNS) als auch IP-Routing unterstützt. Das Protokoll wurde für den Betrieb in einer reinen CLNS-Umgebung, einer reinen IP-Umgebung oder einer dualen CLNS/IP-Umgebung entwickelt.

Auch wenn IS-IS nur für die Weiterleitung von TCP/IP verwendet wird, ist IS-IS immer noch ein ISO-CLNP-Protokoll. Die Pakete, über die IS-IS mit seinen Peers kommuniziert, sind CLNS-Protokolldateneinheiten (Protocol Data Units, PDUs). Dies bedeutet, dass das Warteschlangensystem und Cisco IOS selbst in einer reinen IP-Umgebung keine IP-Rangfolge verwenden können, um CLNS-Kontrollnachrichten zu priorisieren. Stattdessen erhalten IS-IS-Pakete über den pak_priority-Mechanismus im Router Priorität.

Konfigurieren einer Warteschlangenstrategie für das Routing von Paketen

In diesem Abschnitt werden die drei allgemeinen Ansätze für die Entwicklung einer Warteschlangenstrategie behandelt, um die Wahrscheinlichkeit von Kontrollpaketen bei starker Überlastung bei der Cisco Serie 7500 und VIPs zu minimieren. (Denken Sie daran, dass Nicht-RSP-Plattformen standardmäßig Steuerungspakete in separate Warteschlangen einreihen.)

Strategie	Einsatzmöglichkeiten	Beschreibung der Konfiguration
Ordnen Sie eine separate Warteschlange zu.	Konservativste Strategie. Sorgt für geringe oder keine Verluste.	Verwenden Sie die modulare QoS-CLI, um eine separate Klasse zu konfigurieren, und verwenden Sie den Befehl bandwidth (Bandbreite), um dem entsprechenden Datenverkehr in Zeiten der Überlastung eine Mindestbandbreitenzuweisung zuzuweisen. Eine Klasse, die mit dem Befehl Bandbreite konfiguriert wurde, verwendet ein Scheduling-"Gewicht", das auf der Bandbreite und nicht auf der IP-Rangfolge basiert. Informationen zu Class-Based Weighted Fair Queuing auf ATM.
Ordnen Sie dem Klassenstandard eine faire Warteschlange zu.	Ausreichend für die meisten Konfigurationen. Manche Kontrollpakete können bei Überlastung verworfen werden.	Verwenden Sie die IP-Priorität 6, die Cisco IOS dem Paket automatisch zugewiesen hat, um sein Gewicht und damit seinen Anteil an der Bandbreite zu beeinflussen. Siehe Erläuterungen zu gewichteten Fair Queuing im Geldautomaten.
Ordnen Sie FIFO-Warteschlangen der Standardklasse zu.	Nicht empfohlen für überlastete Links. Manche Kontrollpakete können bei Überlastung verworfen werden.	Bei diesem Ansatz wird die IP-Rangfolge nicht berücksichtigt. Bei VIP-basierter QoS werden die pak_priority-Meldungen in die Warteschlange am Tail-End der FIFO-Warteschlange gestellt.

Dies ist ein Beispiel dafür, wie eine separate Warteschlange für RIP-Steuerungspakete erstellt wird.

 class-map match-all rp 
   match access-group 104 
! 
 access-list 104 permit udp any eq rip any eq rip 

!--- Create a class-map that matches an ACL permitting RIP. 

! 
 policy-map bandwidth 
   class voip 
     priority 64 
   class bus 
    bandwidth 184 
   class RP 
    bandwidth 8 

!--- Create a policy-map (named "bandwidth") and specify !--- class RP. 
! 
interface Serial1/0:0.1 point-to-point 
  bandwidth 256 
  ip unnumbered Loopback0 
  ip accounting precedence input 
  no cdp enable 
  frame-relay class sample 
  frame-relay interface-dlci 100 IETF 

!--- Apply the map-class named "sample" to the PVC. 

! 
map-class frame-relay sample 
  frame-relay cir 256000 
  frame-relay bc 2560 
  frame-relay mincir 256000 
  no frame-relay adaptive-shaping 
  service-policy output bandwidth 
  frame-relay fragment 160 

!--- Create a frame relay map-class and apply the service !--- policy inside the map-class.

Berücksichtigen Sie bei der Auswahl eines der folgenden Ansätze folgende Faktoren:

• Das verwendete Routing-Protokoll und die konfigurierten Timer-Werte für Hellos und Datenbankaktualisierungen

• Die Größe der Datenbank, die ausgetauscht werden muss und ob nur Updates/Änderungen oder vollständige Tabellen regelmäßig aktualisiert werden

• Die erwartete Menge an Überlastungen an der Schnittstelle oder dem virtuellen Schaltkreis

Anders ausgedrückt: Man denke an die Wahrscheinlichkeit, dass Pakete mit hoher Priorität bei Überlastung in die Warteschlange gestellt werden.

QoS und lokal generierte Pakete

Der vom Router generierte Datenverkehr stellt einen Sonderfall für ausgehende QoS-Service-Richtlinien dar. Ein Teil des lokal generierten Datenverkehrs muss wie jeder andere Benutzerdatenverkehr behandelt werden, und das QoS-System muss die konfigurierten QoS-Mechanismen auf diesen Datenverkehr anwenden. Ein Beispiel für diesen Datenverkehr sind Leistungstests, mit denen das Verhalten von Paketen einer bestimmten Klasse gemessen werden soll. Andere lokal generierte Zugriffe, insbesondere Layer-2-Keepalives und Routing-Protokollmeldungen, sind für die grundlegende Funktion des Routers unerlässlich und dürfen nicht bestimmten QoS-Funktionen unterliegen. WRED (Weighted Random Early Detection) darf beispielsweise keine Layer-2-Keepalives verwerfen, wenn die durchschnittliche Warteschlangentiefe ein hohes Wasserzeichen erreicht

Darüber hinaus müssen Pakete, die an den Router gerichtet sind, sorgfältig behandelt werden. Denken Sie beispielsweise daran, dass eine Dienstrichtlinie, die klassenbasierte Richtlinien anwendet, nicht auf Pakete angewendet werden darf, die für den Router bestimmt sind, um das Verwerfen wichtiger Kontrollnachrichten zu vermeiden.

Hinweis: RP-generierte Pakete werden standardmäßig nicht in modularen QoS-CLI-Zählern verbucht, obwohl diese Pakete korrekt klassifiziert/in die Warteschlange gestellt wurden. Diese Pakete werden nicht in der Befehlsausgabe show policy-map interface verbucht.

In dieser Tabelle wird aufgelistet, wie Pakete, die zum und vom Router bestimmt sind, derzeit mit den wichtigsten QoS-Funktionen interagieren.

QoS-Funktion	Beschreibung
Klassenbasierte Markierung	Ursprünglich nur für CEF-Switched-Pakete (Cisco Express Forwarding) verwendet. Die Unterstützung für Prozess-Switching und schnelle Switching-Methoden ist in der Cisco IOS Software, Version 12.2(5) (CSCdt74738), enthalten.
Richtlinienvergabe	Eingehend - Es kann eine Ratenbegrenzung angewendet werden. Die eingehende Schnittstelle muss mit CEF konfiguriert werden, wenn die Committed Access Rate (CAR) (und keine klassenbasierte Richtlinienvergabe) verwendet wird. Auf einem Cisco Router der Serie 7500 kann die Datenverkehrsüberwachung ausschließlich CEF-Switching-Pfade überwachen. Outbound - Übertragungsratenbegrenzung mit CAR oder klassenbasierter Richtlinienvergabe funktioniert.

Priorisieren von Paketen auf dem Catalyst 6000

Wenn Sie Cisco IOS sowohl auf dem Supervisor als auch auf der MultiLayer Switch Feature Card (MSFC) des Catalyst 6000 ausführen, markiert der RP Routing-Kontrollpakete mit der IP-Priorität 6. Dieser Wert kann mit der Ausgabeplanung verwendet werden, um die Routingkontrollpakete der hohen Warteschlange, dem hohen Grenzwert im WRR-System (Weighted Round Robin) zuzuordnen. Eine solche Zuordnung von Routing-Kontrollpaketen, die von der MSFC bezogen werden, erfolgt automatisch, solange QoS global mit dem Befehl mls qos aktiviert ist. Wenn Sie QoS aktivieren, werden vom System alle Warteschlangenparameter eingerichtet, z. B. WRED-Drop-Schwellenwerte, WRR-Bandbreiten und Warteschlangenbeschränkungen. Wenn QoS global deaktiviert ist, werden alle Pakete der niedrigen Warteschlange, dem niedrigen Grenzwert für die Ausgabeplanung, des WRR zugeordnet.

Wie im Kapitel Konfiguration der QoS im Catalyst 6000 Konfigurationsleitfaden angegeben, unterstützt QoS die Klassifizierung, Markierung, Planung und Überlastungsvermeidung mithilfe von CoS-Werten (Class of Service) auf Layer 2 an Ethernet-Eingangsports. Bei der Klassifizierung, Markierung, Planung und Überlastungsvermeidung an Ethernet-Eingangsports werden IP-Rangfolge oder DSCP-Werte für Layer 3 weder verwendet noch festgelegt. Darüber hinaus unterstützt QoS bei jeder Switching-Engine die Planung von Ethernet-Ausgangsports und die Vermeidung von Überlastungen mit Layer-2-CoS-Werten. Aus diesem Grund müssen wichtige IP- und Nicht-IP-Pakete einem CoS-Wert zugeordnet werden, auch wenn diese Werte nur intern als Teil des Datenbus-Headers verwendet werden. Wichtige IP-Pakete haben einen IP-Prioritätswert von 6, der einem entsprechenden CoS-Wert von 6 zugeordnet ist. Wesentliche Nicht-IP-Pakete, zu denen IS-IS-Pakete gehören, die von der MSFC stammen, werden mit dem pak_priority-Flag markiert, und diese markierten Pakete werden dann einem CoS-Wert von 6 zugeordnet. Diese Zuordnung erfolgt automatisch in aktuellen Cisco IOS-Versionen.

Weder Eingangs- noch Ausgangs-Policer kennzeichnen Pakete, die von der MSFC stammen und für die Übertragung über eine physische Ethernet-Schnittstelle bestimmt sind.

Die QoS-Konfiguration auf dem Catalyst 6000 wird in diesem Dokument nicht behandelt. Weitere Informationen finden Sie auf der Support-Seite Konfiguration von QoS und Catalyst LAN- und ATM-Switches.

Zugehörige Informationen

• QoS-Support-Seiten
• Technischer Support und Dokumentation - Cisco Systems