Dieses Dokument enthält eine Beispielkonfiguration für Frame Relay Traffic Shaping.
Für dieses Dokument bestehen keine besonderen Voraussetzungen.
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.
Weitere Informationen zu Dokumentkonventionen finden Sie in den Cisco Technical Tips Conventions.
Häufige Implementierungen von Frame Relay Traffic Shaping sind:
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.
Ü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.
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.
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.
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.
In diesem Dokument werden folgende Konfigurationen verwendet:
Hub
Remote
Hub |
---|
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 ! |
Remote |
---|
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.
Dieser Abschnitt enthält Informationen, mit denen Sie überprüfen können, ob Ihre Konfiguration ordnungsgemäß funktioniert.
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
Dies zeigt in Echtzeit, ob der Traffic Shaping-Mechanismus aktiviert wurde oder nicht. Traffic Shaping ist in den folgenden Szenarien aktiv:
BECNs werden empfangen, und DLCI wurde so konfiguriert, dass es BECNs formatiert.
Die Anzahl der Daten-Byte, die über eine Schnittstelle übertragen werden, übersteigt die verfügbare Kreditwürdigkeit (Bytelimit) in einem bestimmten Intervall (Tc).
FRF.12-Fragmentierung wurde konfiguriert, und Pakete warten auf Fragmentierung.
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.
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
Überarbeitung | Veröffentlichungsdatum | Kommentare |
---|---|---|
1.0 |
31-May-2005 |
Erstveröffentlichung |