Committed Access Rate (CAR) ist eine Funktion zur Ratenbegrenzung, die zur Bereitstellung von Klassifizierungs- und Policing-Services verwendet werden kann. CAR kann verwendet werden, um Pakete anhand bestimmter Kriterien zu klassifizieren, z. B. IP-Adressen und Portwerte, die Zugriffslisten verwenden. Die Aktion für Pakete, die dem Durchsatzgrenzwert entsprechen und diesen überschreiten, kann definiert werden. Weitere Informationen zur Konfiguration der CAR finden Sie unter Configuring Committed Access Rate (CAR konfigurieren).
In diesem Dokument wird erläutert, warum die Ausgabe des Befehls show interface x/x rate-limit einen BPS-Wert anzeigt, der ungleich null ist, wenn der konforme BPS-Wert kleiner als die konfigurierte Committed Information Rate (CIR) ist.
Es gibt keine spezifischen Anforderungen für dieses Dokument.
Dieses Dokument ist nicht auf bestimmte Software- und Hardware-Versionen beschränkt.
Weitere Informationen zu Dokumentkonventionen finden Sie unter Cisco Technical Tips Conventions (Technische Tipps von Cisco zu Konventionen).
Es gibt drei Bedingungen, unter denen in der Ausgabe dieses Befehls Überschreitungsraten ungleich null angezeigt werden:
Burst-Werte sind zu niedrig eingestellt, um eine ausreichende Durchsatzrate zu ermöglichen. Beispiel: Cisco Bug-ID CSCdw42923 (nur registrierte Kunden).
Problem mit doppelter Abrechnung in Cisco IOS®-Software behoben
Softwarefehler in Cisco IOS
Sehen Sie sich die Beispielausgabe einer Virtual-Access-Schnittstelle an. In dieser Konfiguration wird RADIUS verwendet, um der dynamisch erstellten Schnittstelle für den virtuellen Zugriff eine Durchsatzbegrenzung zuzuweisen.
AV Pair from Radius Cisco-AVPair = "lcp:interface-config#1=rate-limit input 256000 7500 7500 conform-action continue exceed-action drop", Cisco-AVPair = "lcp:interface-config#2=rate-limit output 512000 7500 7500 conform-action continue exceed-action drop",
Verwenden Sie den Befehl show interface x rate-limit , um die Leistung der alten Cisco Richtlinienvergabe (CAR) zu überwachen. In diesem Beispiel gibt die Ausgabe dieses Befehls Hinweise, warum die Bit-Rate ungleich null überschritten wird. Der aktuelle Burst-Wert beträgt 7392 Byte, während der Wert für Committed Burst (Bc), der durch den Grenzwert angegeben wird, auf 7500 Byte festgelegt wird.
router#show interfaces virtual-access 26 rate-limit Virtual-Access26 Cable Customers Input matches: all traffic params: 256000 bps, 7500 limit, 7500 extended limit conformed 2248 packets, 257557 bytes; action: continue exceeded 35 packets, 22392 bytes; action: drop last packet: 156ms ago, current burst: 0 bytes last cleared 00:02:49 ago, conformed 12000 bps, exceeded 1000 bps Output matches: all traffic params: 512000 bps, 7500 limit, 7500 extended limit conformed 3338 packets, 4115194 bytes; action: continue exceeded 565 packets, 797648 bytes; action: drop last packet: 188ms ago, current burst: 7392 bytes last cleared 00:02:49 ago, conformed 194000 bps, exceeded 37000 bps
Wenn Sie die CAR oder eine neuere Richtlinienzuweisung von Cisco, die klassenbasierte Richtlinienzuweisung, konfigurieren, müssen Sie ausreichend hohe Burst-Werte konfigurieren, um den erwarteten Durchsatz sicherzustellen und um sicherzustellen, dass die Richtlinienzuweisung Pakete verwirft, nur um eine kurzfristige Überlastung zu bestrafen.
Wenn Sie Burst-Werte auswählen, ist es wichtig, vorübergehende Erhöhungen der Warteschlangengröße zu berücksichtigen. Sie können nicht einfach davon ausgehen, dass Pakete gleichzeitig eintreffen und abgehen. Sie können auch nicht davon ausgehen, dass sich die Warteschlange von einem leeren Paket zu einem einzigen ändert und dass die Warteschlange bei einem Paket bleibt, basierend auf einer konsistenten Ein-/Ein-Aus-Ankunftszeit. Ist der typische Verkehr recht sprunghaft, so müssen die sprunghaften Werte entsprechend groß sein, um die Verbindungsauslastung auf einem akzeptabel hohen Niveau halten zu können. Eine zu geringe Burst-Größe oder ein zu niedriger Mindestwert kann zu einer inakzeptabel niedrigen Verbindungsauslastung führen.
Ein Burst kann einfach als eine Reihe von Back-to-Back-Frames mit MTU-Größe definiert werden, z. B. Frames mit 1500 Byte, die von einem Ethernet-Netzwerk ausgehen. Wenn ein Burst solcher Frames an einer Ausgabeschnittstelle ankommt, kann er die Ausgabepuffer überlasten und die konfigurierte Tiefe des Token-Buckets zu einem momentanen Zeitpunkt überschreiten. Bei Verwendung eines Token-Messsystems trifft eine Richtlinie eine binäre Entscheidung darüber, ob ein eingehendes Paket die konfigurierten Richtlinienwerte erfüllt, überschreitet oder verletzt. Bei Burst-Datenverkehr wie einem FTP-Stream kann die momentane Ankunftsrate dieser Pakete die konfigurierten Burst-Werte überschreiten und zu CAR-Verlusten führen.
Darüber hinaus variiert der Gesamtdurchsatz in Zeiten von Engpässen je nach Art des Datenverkehrs, der von der Richtlinienvergabe ausgewertet wird. Während der TCP-Datenverkehr auf Überlastungen reagiert, reagieren andere Datenflüsse nicht. Beispiele für nicht reagierende Datenflüsse sind UDP- und ICMP-basierte Pakete.
TCP basiert auf einer positiven Bestätigung mit erneuter Übertragung. TCP verwendet ein gleitendes Fenster als Teil seines Mechanismus zur Bestätigung der positiven Aktivität. Protokolle mit gleitenden Fenstern nutzen die Netzwerkbandbreite besser, da sie es dem Sender ermöglichen, mehrere Pakete zu übertragen, bevor er auf eine Bestätigung wartet. Bei einem Schiebefensterprotokoll mit einer Fenstergröße von 8 ist es beispielsweise dem Sender gestattet, 8 Pakete zu übertragen, bevor er eine Bestätigung erhält. Wenn Sie die Fenstergröße vergrößern, wird die Leerlaufzeit im Netzwerk weitgehend eliminiert. Ein gut abgestimmtes Sliding Window Protocol sorgt dafür, dass das Netzwerk mit Paketen voll ausgelastet ist und einen hohen Durchsatz aufrechterhalten kann.
Da die Endpunkte den spezifischen Überlastungsstatus des Netzwerks nicht kennen, wurde TCP als Protokoll entwickelt, um auf Überlastungen im Netzwerk durch die Reduzierung seiner Übertragungsraten bei einer Überlastung zu reagieren. Dabei kommen zwei Methoden zum Einsatz:
Technik | Beschreibung |
---|---|
Vermeidung von Staus durch Multiplikationsmaßnahmen | Wenn ein Segment verloren geht (das Äquivalent eines Pakets zu TCP), reduzieren Sie das Überlastungsfenster um die Hälfte. Das Überlastungsfenster ist ein zweiter Wert oder ein zweites Fenster, in dem die Anzahl der Pakete begrenzt wird, die ein Sender in das Netzwerk übertragen kann, bevor er auf eine Bestätigung wartet. |
Langsamer Start der Wiederherstellung | Wenn Sie den Datenverkehr über eine neue Verbindung starten oder den Datenverkehr nach einer Überlastungsperiode erhöhen, starten Sie das Überlastungsfenster in der Größe eines einzelnen Segments, und erhöhen Sie das Überlastungsfenster um ein Segment, jedes Mal, wenn eine Bestätigung eingeht. TCP initialisiert das Überlastungsfenster mit 1, sendet ein Anfangssegment und wartet. Wenn die Bestätigung eingeht, vergrößert sie das Überlastungsfenster auf 2, sendet zwei Segmente und wartet. Weitere Informationen finden Sie unter RFC 2001![]() |
Pakete können verloren gehen oder zerstört werden, wenn Übertragungsfehler die Daten beeinträchtigen, wenn die Netzwerkhardware ausfällt oder wenn Netzwerke zu stark ausgelastet sind, um die Belastung zu bewältigen. TCP geht davon aus, dass verlorene Pakete oder Pakete, die aufgrund extremer Verzögerungen nicht innerhalb des Zeitintervalls bestätigt werden können, auf eine Überlastung im Netzwerk hinweisen.
Das Token-Bucket-Messsystem einer Überwachung wird bei jeder Paketankunft aufgerufen. Die angepasste Rate und die Überschreitungsrate werden auf der Grundlage dieser einfachen Formel berechnet:
(conformed bits since last clear counter)/(time in seconds elapsed since last clear counter)
Da die Formel die Zinssätze für einen Zeitraum ab dem letzten Zeitpunkt berechnet, zu dem die Zähler gelöscht wurden, empfiehlt Cisco, die Zähler zu löschen, um den aktuellen Satz zu überwachen. Wenn die Zähler nicht gelöscht werden, bedeutet die vorherige Formelrate effektiv, dass die Befehlsausgabe show einen über einen potenziell sehr langen Zeitraum berechneten Durchschnitt anzeigt und die Werte möglicherweise bei der Bestimmung der aktuellen Rate nicht aussagekräftig sind.
Der durchschnittliche Durchsatz muss über einen bestimmten Zeitraum der konfigurierten Committed Information Rate (CIR) entsprechen. Burst-Größen ermöglichen eine maximale Burst-Dauer zu einem bestimmten Zeitpunkt. Wenn kein Datenverkehr oder weniger als der CIR-Datenverkehr vorhanden ist und der Token-Bucket nicht voll ist, ist ein sehr großer Burst immer noch auf eine bestimmte Größe beschränkt, die auf dem normalen Burst und dem erweiterten Burst basiert.
Die Verlustrate ergibt sich aus diesem Mechanismus.
Notieren Sie die aktuelle Uhrzeit.
Aktualisieren Sie den Token-Bucket mit der Anzahl der Token, die sich seit dem letzten Eintreffen eines Pakets kontinuierlich angesammelt haben.
Die Gesamtanzahl der akkumulierten Token darf den Höchstwert für Token nicht überschreiten. Überschüssige Token fallen lassen.
Überprüfen der Paketkonformität
Eine Ratenbegrenzung kann auch mit Policing erreicht werden. Dies ist eine Beispielkonfiguration, um eine Ratenbegrenzung für die Ethernet-Schnittstelle bereitzustellen, die klassenbasiertes Policing verwendet.
class-map match-all rtp1 match ip rtp 2000 10 ! policy-map p3b class rtp1 police 200000 6250 6250 conform-action transmit exceed-action drop violate-action drop policy-map p2 class rtp1 police 250000 7750 7750 conform-action transmit exceed-action drop violate-action drop ! interface Ethernet3/0 service-policy output p3b service-policy input p2
Diese Beispielausgabe aus dem Befehl show policy-map interface (Schnittstelle anzeigen) veranschaulicht ordnungsgemäß berechnete und synchronisierte Werte für die angebotene Rate und die Verlustrate sowie konforme und höhere Bit/s-Raten.
router#show policy-map interface ethernet 3/0 Ethernet3/0 Service-policy input: p2 Class-map: rtp1 (match-all) 88325 packets, 11040625 bytes 30 second offered rate 400000 bps, drop rate 150000 bps Match: ip rtp 2000 10 police: 250000 bps, 7750 limit, 7750 extended limit conformed 55204 packets, 6900500 bytes; action: transmit exceeded 33122 packets, 4140250 bytes; action: drop conformed 250000 bps, exceed 150000 bps violate 0 bps Service-policy : p3b Class-map: rtp1 (match-all) 88325 packets, 11040625 bytes 30 second offered rate 400000 bps, drop rate 50000 bps Match: ip rtp 2000 10 police: 200000 bps, 6250 limit, 6250 extended limit conformed 44163 packets, 5520375 bytes; action: transmit exceeded 11041 packets, 1380125 bytes; action: drop conformed 200000 bps, exceed 50000 bps violate 0 bps Class-map: class-default (match-any) 0 packets, 0 bytes 30 second offered rate 0 bps, drop rate 0 bps Match: any
In dieser Tabelle sind die behobenen Probleme mit den Zählern aufgeführt, die in den Befehlen show policy-map oder show interface rate-limit angezeigt werden. Registrierte Kunden, die eingeloggt sind, können die Fehlerinformationen im Bug Search Tool einsehen.
Symptom | Behobene Bug-IDs und Problemumgehungen |
---|---|
Zähler für unerwarteten Datenverlust niedriger als erwartet |
|
Verdoppeln der erwarteten Rate von Verlusten und Durchsatz |
|
Keine Verlustraten oder eine Absturzrate von Null | Im Allgemeinen besteht der erste Schritt bei der Fehlerbehebung bei der Anwendung klassenbasierter QoS-Funktionen darin, sicherzustellen, dass der QoS-Klassifizierungsmechanismus ordnungsgemäß funktioniert. Mit anderen Worten, stellen Sie sicher, dass die Pakete, die in den Match-Anweisungen in Ihrer Klassenzuordnung angegeben sind, die richtigen Klassen treffen. router#show policy-map interface ATM4/0.1 Service-policy input: drop-inbound-http-hacks (1061) Class-map: http-hacks (match-any) (1063/2) 149 packets, 18663 bytes 5 minute offered rate 2000 bps, drop rate 0 bps Match: protocol http url "*cmd.exe*" (1067) 145 packets, 18313 bytes 5 minute rate 2000 bps Match: protocol http url "*.ida*" (1071) 0 packets, 0 bytes 5 minute rate 0 bps Match: protocol http url "*root.exe*" (1075) 4 packets, 350 bytes 5 minute rate 0 bps Match: protocol http url "*readme.eml*" (1079) 0 packets, 0 bytes 5 minute rate 0 bps police: 1000000 bps, 31250 limit, 31250 extended limit conformed 0 packets, 0 bytes; action: drop exceeded 0 packets, 0 bytes; action: drop violated 0 packets, 0 bytes; action: drop conformed 0 bps, exceed 0 bps violate 0 bps
|
Anomalische oder inkonsistente Verlustrate |
|
Überarbeitung | Veröffentlichungsdatum | Kommentare |
---|---|---|
1.0 |
18-Nov-2002
|
Erstveröffentlichung |