ASR 9000 QoS-Offload - Konfigurationsbeispiel

Einleitung

In diesem Dokument wird die Konfiguration der QoS-Offload-Funktion (Quality of Service) auf der ASR9K-Plattform (Aggregated Services Router) der Cisco Serie 9000 beschrieben. Zweck, Anwendung und Einschränkungen der Funktion werden ebenfalls beschrieben.

Anforderungen

Stellen Sie vor dem Versuch der Konfiguration sicher, dass Ihr System die folgenden Anforderungen erfüllt:

• Es muss mindestens ein Paket-Installationsumschlag (Packet Installation Envelopes, PIEs) für die jeweilige Satelliten-Hardware installiert und aktiviert sein:
  
  
  • asr9k-asr9000v-nV-px.pie-5.1.1
    
    
  • asr9k-asr901-nV-px.pie-5.1.2
    
    
• Der Satellit muss über aktualisierte Software und Field-Programmable Devices (FPDs) verfügen.

Verwendete Komponenten

Die Informationen in diesem Dokument basierend auf folgenden Software- und Hardware-Versionen:

• Cisco IOS^® XR Version 5.1.1 auf dem ASR9K für ASR-9000v.
  
  
• Cisco IOS XR Version 5.1.2 auf dem ASR9K für den ASR-901.

Hinweis: Die QoS-Offload-Funktion auf dem ASR-903 wird derzeit nicht offiziell unterstützt.

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.

Hintergrundinformationen

QoS-Offload - Übersicht

Die Inter-Chassis-Verbindung (ICL) zwischen dem Satelliten und dem ASR9K (in der Regel 10 Gbit/s) kann durch die Zugriffsschnittstellen am Satelliten selbst überlastet werden. Die QoS-Offload-Funktion stellt QoS-Funktionen in der Hardware des tatsächlichen Satelliten (im Gegensatz zum ASR9K-Host) bereit, um den Verlust wichtiger Daten auf der ICL in Überlastungszeiten zu verhindern.

Die QoS-Offload-Funktion wurde eingeführt, um den Datenverkehr über die ICL vor Überlastung in Richtung vom Satellitenzugriffsport zum ASR9K zu schützen, wie durch die gestrichelten roten Pfeile im nächsten Bild angedeutet. Dieses Konzept hilft Ihnen, einige der Einschränkungen zu verstehen, und hilft Ihnen, wenn Sie die QoS-Implementierung entwerfen.

Kritische Prozesse für QoS-Offload

In diesem Abschnitt werden die beiden kritischen Prozesse beschrieben, die für die QoS-Auslagerung verwendet werden.

Interface Control Plane Extender (icpe_cpm)-Prozess

Der ICPE-Prozess (Interface Control Plane Extender) verwaltet das SDAC-Protokoll (Satellite Discovery and Control), das den Kommunikationskanal zwischen dem ASR9K-Host und dem Satelliten bereitstellt.

QoS-Richtlinienmanager (qos_ma) - Prozess

Der QoS-Richtlinien-Manager-Prozess führt folgende Aktionen aus:

• Überprüft und speichert die Klassen- und Richtlinienzuordnungen in einer Datenbank auf dem Route Switch Processor (RSP).
  
  
• Verwaltet eine Datenbank mit Satellitenschnittstellen zu Dienstrichtlinienzuordnungen.
  
  
• Regelmäßige Erfassung der QoS-Statistiken aus den Satellitenboxen für ausgelagerte Service-Richtlinien
  
  
• Funktioniert auf allen Knoten mit Kontrollebenenschnittstellen, einschließlich RSPs und Line Cards (LCs).

Konfigurieren

In diesem Abschnitt können Sie die QoS-Offload-Funktion auf dem ASR9K konfigurieren.

QoS-Offload-Konfiguration

Dieses Diagramm dient als visuelle Darstellung des Standorts, an dem die Dienstrichtlinie installiert ist:

Satellitenzugriffsschnittstelle

Nachfolgend finden Sie eine Beispielkonfiguration für die Satellitenzugriffsschnittstelle:

interface GigabitEthernet200/0/0/1
 service-policy output NQoSOff_Out  
 service-policy input NQoSOff_In 
 nv
  service-policy input ACCESS 

Hinweis: Der Service-Policy-Ausgang NQoSOff_Out gibt Nicht-QoS-Offload-Verkehr an, der von der ASR9K-ICL-Schnittstelle zur Satellitenzugangsschnittstelle (1) übertragen wird, und der Eingang NQoSOff_In gibt Nicht-QoS-Verkehr an, der auf dem ASR9K von der Satellitenzugangsschnittstelle (1) empfangen wird. Der Dienstrichtlinieneingang ACCESS gibt außerdem den QoS-Offload-Verkehr an, der von dem PC (2) an der Satellitenzugriffsschnittstelle empfangen wird.

ICL-Schnittstelle

Nachfolgend finden Sie eine Beispielkonfiguration für die ICL-Schnittstelle:

interface TenGigE0/0/0/1
service-policy output NOT_SUPPORTED
service-policy input NOT_SUPPORTED 
nv
  satellite-fabric-link network
   redundancy
    iccp-group 1
   !
   satellite 200
    service-policy output ICL_OFFLOAD
    remote-ports GigabitEthernet 0/0/1-2

Hinweis: Die Ausgabe und Eingabe der Dienstrichtlinie wird für diese Schnittstelle NICHT unterstützt. Lesen Sie den nächsten Abschnitt, und entwerfen Sie sorgfältig. Die Ausgabe von ICL_OFFLOAD der Dienstrichtlinie gibt außerdem den QoS-Offload-Datenverkehr an, der von der Satelliten-ICL an den ASR9K (3) gesendet wird.

ICL-Überbelegung

Die QoS-Dienstrichtlinien werden nicht direkt auf den ICL-Schnittstellen unterstützt (kein QoS-Offload). Es muss daher darauf geachtet werden, dass die Satelliten-ICL-Schnittstellen nicht überbelegt werden. In diesem Abschnitt werden zwei Methoden beschrieben, die verwendet werden, um eine ICL-Überbelegung zu verhindern. Die erste Methode beschränkt die Anzahl der Zugriffsschnittstellen für jede ICL, sodass keine Überlastung möglich ist. Die zweite Methode wendet Shaper auf jede Zugriffsschnittstelle an, sodass die Summe aller Shaper die Bandbreite der ICL nicht überschreitet.

Einschränken der Zugriffsschnittstellen für jede ICL

Um fünfzehn 1-Gbit/s-Verbindungen auf einem Satelliten (bei einem Potenzial von 15 Gbit/s) ohne Paketverluste während einer Überlastung zu unterstützen, müssen zwei separate 10-Gbit/s-ICL-Verbindungen konfiguriert werden. Ordnen Sie die ersten zehn Satellitenzugriffsschnittstellen mit 1 Gbit/s einer 10-Gbit/s-ICL-Verbindung und die nächsten fünf Satellitenzugriffsschnittstellen mit 1 Gbit/s der zweiten 10-Gbit/s-ICL-Verbindung zu. Andere Kombinationen sind möglich, solange die Anzahl der jeder 10-Gbit/s-ICL zugeordneten Zugriffsschnittstellen zehn nicht überschreitet.

Nachfolgend finden Sie ein Beispiel für eine Konfiguration:

interface TenGigE0/0/0/1
description ICL_LINK_1_FOR_SAT100
nv
 satellite-fabric-link network
  satellite 100
  remote-ports GigabitEthernet 0/0/0-9
!
interface TenGigE0/0/0/2
description ICL_LINK_2_FOR_SAT100
nv
 satellite-fabric-link network
  satellite 100
  remote-ports GigabitEthernet 0/0/10-14

Shaper auf Zugriffsschnittstellen anwenden

Die zweite Methode, die verwendet wird, um Überbelegung zu verhindern, ist, einen Shaper direkt auf jede Satellitenzugriffsschnittstelle (z. B. GigE100/0/0/9) anzuwenden, um die Übertragung von mehreren Leitungsraten über die ICL zum Satelliten zu verhindern. Wenn z. B. mit einer einzelnen 10-Gbit/s-ICL ein 500-Mbit/s-Shaper für 20 Gigabit-Ethernet-Satellitenschnittstellen verwendet wird, werden pro ICL nicht mehr als 10 Gbit/s (500 Mbit/s x 20) übertragen.

Nachfolgend finden Sie ein Beispiel für eine Konfiguration:

interface TenGigE0/0/0/1
 nv
  satellite-fabric-link network
   satellite 100
   remote-ports GigabitEthernet 0/0/0-19
!
interface GigE100/0/0/0 (For all Gi100/0/0/0-19)
 service-policy output 500MBPS_SHAPE

Hinweis: Vollständige MQC-Funktionen (Modular QoS CLI) sind für Nicht-QoS-Offloads an Satellitenzugriffsschnittstellen verfügbar, die virtuelle Einheiten auf dem ASR9K-Host sind.

Schutz des Datenverkehrs auf der Kontrollebene über ICL

In diesem Abschnitt wird ein Konfigurationsbeispiel beschrieben, das den auf einer Satellitenzugriffsschnittstelle empfangenen Datenverkehr der Netzwerkkontrollebene schützt, während dieser die ICL durchläuft. Dies ist eine Demonstration dessen, wie dies erreicht werden könnte:

Satellite Access Interface Config:
class-map match-any routing
 match precedence 6

policy-map Protect_NCP
 class routing
  set qos-group 4
 !
 class class-default
  set qos-group 0

interface Gi100/0/0/1
 description Satellite Access Interface
 service-policy input Protect_NCP
 
ICL Interface Config:
class-map match-any qos-group-4
 match qos-group 4

policy-map ICL-Policy
 class qos-group-4
  bandwidth remaining percent 5
 !
 class class-default
  bandwidth remaining percent 90

interface TenGigE0/0/0/1
description Satellite ICL
nv
  satellite-fabric-link network
   redundancy
    iccp-group 1
   !
   satellite 100
    service-policy output ICL-Policy

Im vorherigen Konfigurationsbeispiel vergleicht die Richtlinienzuordnung "Protect_NCP" alle Pakete mit einer IP-Rangfolge von 6 und gruppiert sie in die interne QoS-Gruppe 4. Sobald die Leitung über die ICL zum ASR9K-Host gelangt, wird sie über die konfigurierte Bandbreitenreservierung in der Class-Map für die QoS-Gruppe 4 geschützt.

Erinnerung: Eine QoS-Gruppe ist keine tatsächliche Markierung auf dem ToS-Byte des Pakets, sondern eine interne Markierung, die nur lokale Bedeutung für den Satelliten und den ASR9K-Host hat.

WICHTIG! Bei Verwendung von QoS-Offload können nur die QoS-Gruppen 1, 2, 4 und 5 vom Benutzer definiert werden. Die QoS-Gruppen 3, 6 und 7 sind für die zugrunde liegende Funktionalität reserviert, spezifisch für nV-Satelliten und sollten nie verwendet werden. QoS-Gruppe 0 ist für Datenverkehr reserviert, der der Standardklasse angehört.

QoS-Offload-Beschränkungen

 In diesem Abschnitt werden die Einschränkungen der QoS-Offload-Funktion beschrieben.

Einschränkungen bei der Platzierung von Servicerichtlinien

QoS-Offload wird implementiert, um QoS-Funktionen aus der Richtung des Satellitenzugriffsports zum ASR9K-Host bereitzustellen. Es gelten die folgenden Platzierungsbeschränkungen:

• Eine QoS-Servicerichtlinie kann nicht direkt auf einer ASR9K-ICL-Schnittstelle platziert werden, um sie auszulagern oder zu entfernen.
  
  
• Ausgangs-(Ausgabe-)Dienstrichtlinien werden nur für QoS-Offload an den ICL-Schnittstellen des Satelliten unterstützt, die dem aktiven Host gegenüberliegen.
  
  
• Richtlinien für eingehende Dienste werden nur für QoS-Offloads an den Schnittstellen des Satellitenzugriffsports oder für Pakete für Datenverkehr unterstützt, der direkt an der Satellitenzugriffsschnittstelle oder dem Satellitenzugriffspaket empfangen wird. Im Fall eines Pakets wird die QoS-Richtlinie auf jedem Mitglied auf Linkbasis installiert.
  
  
• Eine ausgelagerte Dienstrichtlinie kann nicht auf eine Subschnittstelle angewendet werden.

Unterstützte QoS-Offload-Funktionen

Die unterstützten QoS-Offload-Funktionen sind im Abschnitt Unterstützte plattformspezifische Informationen für QoS-Offload des Konfigurationshandbuchs für modulare Quality of Service auf dem Cisco Aggregation Services Router der Serie ASR 9000, Version 5.1.x, dokumentiert.

Hinweis: Derzeit werden SNMP-bezogene QoS-Offload-Statistiken nicht unterstützt.

Nicht-QoS-Offload-Beschränkungen für Satellitenzugriffsschnittstellen

In diesem Abschnitt werden die Nicht-QoS-Offload-Einschränkungen für die Satellitenzugriffsschnittstellen beschrieben.

Einschränkungen bei der Platzierung von Servicerichtlinien

Diese Einschränkungen für die Platzierung von Servicerichtlinien gelten für die Nicht-QoS-Auslagerung an Satellitenzugriffsschnittstellen:

• Die Eingangs- und Ausgangs-Service-Richtlinien können unter der tatsächlichen Access-Port-Konfiguration (nicht nv) angewendet werden. Diese Richtlinien werden nicht ausgelagert, und die Pakete werden in die Warteschlange gestellt, bevor sie über die Leitung vom ASR9K zum Satelliten übertragen werden.
  
  
• Eine QoS-Servicerichtlinie kann nicht direkt auf einer ASR9K ICL-Schnittstelle platziert werden, um sie auszulagern oder zu deaktivieren.

Einschränkungen in der Service-Richtlinientopologie

Für Hub-and-Spoke-Topologien werden dreistufige QoS-Richtlinien (übergeordnet, übergeordnet und untergeordnet) unterstützt. Für die neueren Topologien Ring und Layer-2-Fabric (L2) werden nur Dual-Level-QoS-Richtlinien unterstützt.

Überprüfung

In diesem Abschnitt können Sie überprüfen, ob Ihre QoS-Offload-Konfiguration ordnungsgemäß funktioniert.

Das Output Interpreter-Tool (nur registrierte Kunden) unterstützt bestimmte show-Befehle. Verwenden Sie das Output Interpreter-Tool, um eine Analyse der show-Befehlsausgabe anzuzeigen.

 

Installation der QoS-Offload-Richtlinie auf Satellit

Geben Sie den Befehl show qos status interface (QoS-Statusanzeige mit der Option nv satellite) ein, um zu ermitteln, ob er bei ausgelagerten QoS-Richtlinien in der Satelliten-Hardware ordnungsgemäß installiert wurde. Wenn der Status in der Befehlsausgabe "Active" (Aktiv) anzeigt, wurde die QoS-Richtlinie für ausgelagerte Geräte erfolgreich installiert. Wenn der Status in der Ausgabe Inaktiv anzeigt, liegt ein Fehler vor.

Tritt ein Fehler auf, liegt häufig ein Problem mit der tatsächlichen ICL-Verbindung oder der QoS-Richtlinie vor, die versucht, die Auslagerung vorzunehmen. Diese wird in der aktuellen IOS XR-Softwareversion unterstützt, die auf dem ASR9K-Host ausgeführt wird, wird jedoch möglicherweise nicht auf dem tatsächlichen Satelliten unterstützt. Weitere Informationen finden Sie im Abschnitt Unterstützte QoS-Auslagerungsfunktionen dieses Dokuments.

Wenn der Status in der Befehlsausgabe einen In-Progress-Status anzeigt, bedeutet dies, dass die Satellitenverbindung unterbrochen wurde. In diesem Zwischenzustand zwischen aktiv und inaktiv wurde die QoS-Richtlinie nicht erfolgreich ausgelagert.

Im Folgenden finden Sie zwei Beispielausgaben, die einen erfolgreichen Offload und einen fehlgeschlagenen Offload anzeigen:

OUTPUT:
RP/0/RSP0/CPU0:ASR9001#show qos status interface gig 0/0/0/0 nv satellite 100
Wed Apr 16 23:50:46.575 UTC
GigabitEthernet0/0/0/0 direction input: Service Policy not installed
GigabitEthernet0/0/0/0  Satellite: 100 output: test-1
     Last Operation Attempted :  ADD
     Status                   :  ACTIVE

OUTPUT:
RP/0/RSP0/CPU0:ASR9001#show qos status interface gig 0/0/0/0 nv satellite 100
Wed Apr 16 23:51:34.272 UTC
GigabitEthernet0/0/0/0 direction input: Service Policy not installed
GigabitEthernet0/0/0/0  Satellite: 100 output: test-2
     Last Operation Attempted :  ADD
     Status                   :  INACTIVE
     Failure description   :Apply Servicepolicy: Handle Add Request  AddSP
      test-2 CliParserWrapper:
Remove shape action under class-default first.

QoS-Statistik der ausgelagerten QoS-Richtlinie für die Satellitenzugriffsschnittstelle

Geben Sie die folgenden Befehle ein, um die Statistiken einer QoS-Richtlinienzuordnung anzuzeigen oder zu löschen, die auf die Schnittstelle für den Remote-Satellitenzugriff angewendet wird:

• show policy-map interface Gi100/0/0/9 input nv
  
  
• clear qos counters interface Gi100/0/0/9 input nv

QoS-Statistik der ausgelagerten QoS-Richtlinie an der ICL-Schnittstelle des Satelliten

Geben Sie die folgenden Befehle ein, um die Statistiken einer QoS-Richtlinienzuordnung anzuzeigen oder zu löschen, die auf die Remote-ICL-Schnittstelle für Satelliten angewendet wird:

• show policy-map interface Ten0/0/0/1 output nv satellite-fabric-link 100
  
  
• clear qos counters interface Ten0/0/0/1 input nv satellite-fabric-link 100

Hinweis: Die QoS-Statistiken werden alle dreißig Sekunden auf den ASR9K-Host aktualisiert.

Fehlerbehebung

Geben Sie die folgenden Befehle ein, um Debugging-Informationen zu erfassen, wenn Sie versuchen, eine Fehlerbehebung für die QoS-Offload-Funktion durchzuführen, oder wenn Sie eine Serviceanfrage beim Cisco Technical Assistance Center (TAC) stellen:

• show policymgr process trace [all|intermittent|critical]
  
  
• Technologie-QoS anzeigen
  
  
• show policy-lib trace [all|critical|intermittent]
  
  
• show policy-lib trace client <Clientname> location <loc>
  
  
• app-obj trace anzeigen
  
  
• show app-obj db <db_name> jid <jid> location <loc>
  
  
• show qos-ma trace

Hinweis: <db_name> ist entweder class_map_qos_db oder policy_map_qos_db.

Bekannte Fehler

Informationen zu bekannten Fehlern in Bezug auf die in diesem Dokument bereitgestellten Informationen erhalten Sie, wenn Sie die Cisco Bug-ID CSCuj87492 - service-policy option unter non-state interface nv (Nicht-Statiter-Schnittstelle nv) entfernen. Dieser Fehler wurde behoben, um die nv-Option von Nicht-Satelliten-Schnittstellen zu entfernen.