Konfigurieren von Frame-Relay-Traffic-Shaping auf Routern der Serie 7200 und untergeordneten Plattformen

Einführung

Dieses Dokument enthält eine Beispielkonfiguration für Frame Relay Traffic Shaping.

Voraussetzungen

Anforderungen

Für dieses Dokument bestehen keine besonderen Voraussetzungen.

Verwendete Komponenten

Frame-Relay Traffic Shaping wird seit Version 11.2 der Cisco IOS® Software unterstützt.

Es wird auf Cisco 7200-Routern und niedrigeren Plattformen unterstützt. Verteiltes Traffic Shaping wird auf Cisco 7500-Routern, 7600-Routern und dem FlexWAN-Modul unterstützt.

Konventionen

Weitere Informationen zu Dokumentkonventionen finden Sie in den Cisco Technical Tips Conventions.

Hintergrundinformationen

Häufige Implementierungen von Frame Relay Traffic Shaping sind:

1. Unstimmigkeiten zwischen Hochgeschwindigkeits- und Niedergeschwindigkeits-Schaltungen: Hier gibt es zwei Möglichkeiten:

   • Der Hub-Standort verfügt über eine T1-Leitung in die Cloud, während der Remote-Standort eine geringere Geschwindigkeit (56 Kbit/s) aufweist. In diesem Fall müssen Sie den Hub-Standort so begrenzen, dass er die Geschwindigkeit des Remote-Seitenzugriffs nicht überschreitet.

   • Der Hub-Standort verfügt über eine einzige T1-Leitung in die Cloud, während die Remote-Standorte auch über eine vollständige T1-Leitung mit der Cloud verbunden sind. In diesem Fall müssen Sie die Remote-Standorte begrenzen, um den Hub nicht zu überlaufen.

2. Überbelegung: Wenn beispielsweise der garantierte Tarif für einen permanenten virtuellen Stromkreis (PVC) 64 Kbit/s beträgt und die Zugriffsrate auf beiden Seiten 128 Kbit/s beträgt, ist es möglich, die garantierte Rate zu überschreiten, wenn keine Überlastung vorliegt, und bei einer Überlastung auf die garantierte Rate zurückzufallen.

3. Quality of Service: Informationen zur Implementierung von FRF.12-Fragmentierung oder Low Latency Queuing-Funktionen für eine bessere Quality of Service finden Sie unter VoIP over Frame Relay mit Quality of Service.

Hinweis: Die Zugriffsrate ist die physische Leitungsgeschwindigkeit der Schnittstelle, die mit dem Frame-Relay verbunden ist. Der garantierte Satz ist der verbindliche Informationssatz (CIR), den der Telekommunikationsanbieter für die PVC angegeben hat. Das Festlegen der CIR- oder minCIR-Werte für die Zugriffsrate sollte vermieden werden, da dies zu Ausgabeverwerfungen führen kann, die zu einer Drosselung des Datenverkehrs führen können. Der Grund dafür ist, dass die Bildrate die Overhead-Bytes der Felder Markierung und CRC (Cyclische Redundancy Check) nicht berücksichtigt. Das Shaping bei der Leitungsgeschwindigkeit überbelegt also tatsächlich und führt zu Schnittstellenüberlastung. Eine Anpassung der Zugriffsrate wird nicht empfohlen. Sie sollten den Datenverkehr immer mit 95 Prozent der Zugriffsrate gestalten. Im Allgemeinen sollte die aggregierte Shaped Rate nicht mehr als 95 Prozent der Zugriffsrate betragen.

Konfigurieren

In diesem Abschnitt erhalten Sie Informationen zum Konfigurieren der in diesem Dokument beschriebenen Funktionen.

Hinweis: Um weitere Informationen zu den in diesem Dokument verwendeten Befehlen zu erhalten, verwenden Sie das IOS-Befehlssuchwerkzeug.

Netzwerkdiagramm

In diesem Dokument wird die folgende Netzwerkeinrichtung verwendet:

Im obigen Beispiel haben wir die folgenden Werte:

• HUB - Zugriffsrate = 192 Kbit/s, garantierte Rate = 32 Kbit/s

• REMOTE - Zugriffsrate = 64 Kbit/s, garantierte Rate = 32 Kbit/s

Hier wird Traffic Shaping an beiden Enden implementiert, sodass die durchschnittliche Übertragungsrate 64 Kbit/s beträgt. Bei Bedarf kann der HUB darüber platzen. Im Fall einer Überlastung kann der Wert auf mindestens 32 Kbit/s reduziert werden. Die Benachrichtigung über Überlastungen aus der Cloud erfolgt über BECN (Backward Explicit Congestion Notification). Daher ist das Shaping so konfiguriert, dass es an BECN angepasst wird.

Hinweis: Frame-Relay-Traffic-Shaping ist an der Hauptschnittstelle aktiviert und gilt für alle DLCIs (Data Link Connection Identifiers) unter dieser Schnittstelle. Traffic Shaping kann nicht nur für eine bestimmte DLCI oder Subschnittstelle unter der Hauptschnittstelle aktiviert werden. Wenn einem bestimmten DLCI keine Zuordnungsklasse zugeordnet ist und Traffic Shaping auf der Hauptschnittstelle aktiviert ist, wird dem DLCI eine Standardzuordnungsklasse mit CIR = 56000 zugewiesen.

Konfigurationen

In diesem Dokument werden folgende Konfigurationen verwendet:

• Hub

• Remote

interface Serial0/0 
 no ip address 
 encapsulation frame-relay 
 no fair-queue 
 frame-relay traffic-shaping 

!--- Apply traffic shaping to main interface (step 3).
 
interface Serial0/0.1 point-to-point 
 ip address 10.1.1.1 255.255.255.0 
 frame-relay interface-dlci 16  
 frame-relay class cisco 

!--- Apply map class to the DLCI / subinterface (step 2).
 
! 
! 

!--- Configure map class parameters (step 1).
 
map-class frame-relay cisco 
 frame-relay cir 64000  
 frame-relay mincir 32000 
 frame-relay adaptive-shaping becn 
 frame-relay bc 8000 
 frame-relay be 16000 
!

interface Serial0/0 
no ip address 
encapsulation frame-relay 
no fair-queue 
frame-relay traffic-shaping 
! 
interface Serial0/0.1 point-to-point 
ip address 10.1.1.2 255.255.255.0 
frame-relay interface-dlci 16                            
frame-relay class cisco 
! 
map-class frame-relay cisco 
frame-relay cir 64000 
frame-relay mincir 32000 
frame-relay adaptive-shaping becn 
frame-relay bc 8000 
!

Dieses Diagramm zeigt den Datenverkehr, der vom HUB-Router gesendet wird:

Wenn der Datenverkehr mit einem Burst von 80000 Bit gesendet wird, wird dieser in 8-Tc-Intervallen (jeweils 125 ms) aus der PVC gesendet. Wir können dies erreichen, weil im ersten Intervall die verfügbare Gutschrift Bc + Be = 8000 + 16000 = 24000 Bit ist. Dies bedeutet, dass die Rate 24.000 Bit / 125 ms = 192 Kbit/s ist.

In den nächsten sieben Intervallen ist es nur Bc = 8000 Bits. Daher beträgt die Rate 8.000 / 125 ms = 64 Kbit/s.

Wenn wir beispielsweise eine Burst von 88.000 Bit empfangen, können wir diesen gesamten Datenverkehr nicht in Intervallen von 8 Tc senden. Die letzten 8000 Bit werden im 9. Tc-Intervall gesendet. Dieser Datenverkehr wird daher durch den Traffic Shaping-Mechanismus verzögert.

Überprüfen

Dieser Abschnitt enthält Informationen, mit denen Sie überprüfen können, ob Ihre Konfiguration ordnungsgemäß funktioniert.

Befehle anzeigen

Bestimmte show-Befehle werden vom Output Interpreter Tool unterstützt (nur registrierte Kunden), mit dem Sie eine Analyse der show-Befehlsausgabe anzeigen können.

Verwenden Sie den Befehl show frame relais pvc <dlci>, um die Konfigurationsdetails anzuzeigen:

Hub#show frame relay pvc 16
     PVC Statistics for interface Serial0/0 (Frame Relay DTE)
     DLCI = 16, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0.1
       input pkts 8743          output pkts 5            in bytes 2548330
       out bytes 520            dropped pkts 0           in FECN pkts 0
       in BECN pkts 0           out FECN pkts 0          out BECN pkts 0
       in DE pkts 0             out DE pkts 0
       out bcast pkts 0         out bcast bytes 0
       Shaping adapts to BECN
       pvc create time 6d01h, last time pvc status changed 6d01h
       
cir 64000 bc 8000 be 16000 byte limit 3000 interval 125 
      mincir 56000 byte increment 1000 Adaptive Shaping BECN 
      pkts 5 bytes 170 pkts delayed 0 bytes delayed 0 
      shaping inactive 
      traffic shaping drops 0
 
       Queueing strategy: fifo 
       Output queue 0/40, 0 drop, 0 dequeued

Shaping inaktiv/aktiv

Dies zeigt in Echtzeit, ob der Traffic Shaping-Mechanismus aktiviert wurde oder nicht. Traffic Shaping ist in den folgenden Szenarien aktiv:

1. BECNs werden empfangen, und DLCI wurde so konfiguriert, dass es BECNs formatiert.

2. Die Anzahl der Daten-Byte, die über eine Schnittstelle übertragen werden, übersteigt die verfügbare Kreditwürdigkeit (Bytelimit) in einem bestimmten Intervall (Tc).

3. FRF.12-Fragmentierung wurde konfiguriert, und Pakete warten auf Fragmentierung.

Pakete verzögert/Byte verzögert

Dies zeigt die Anzahl der Pakete und Bytes, die durch die Aktivierung des Traffic Shaping-Mechanismus verzögert wurden. Dies gilt vor allem dann, wenn die Anzahl der zu übertragenden Bytes die verfügbare Kreditwürdigkeit pro Intervall überschreitet oder wenn Pakete fragmentiert werden müssen (FRF.12). Diese Pakete und Bytes werden in der Shaping-Warteschlange gespeichert (pro VC zugewiesen) und anschließend in nachfolgenden Intervallen übertragen, wenn genügend Gutschriften verfügbar sind.

Traffic Shaping sinkt

Zeigt die Anzahl der Verwerfen in der Shaping-Warteschlange an. Byte werden zuerst durch den Shaping-Mechanismus verzögert und in dieser Warteschlange gespeichert. Wenn die Warteschlange voll ist, werden Pakete verworfen. Standardmäßig lautet der Warteschlangentyp FCFS (First Come First Serve) oder FIFO, kann jedoch in WFQ, PQ, CQ, CBWFQ oder LLQ geändert werden. Weitere Informationen