Die Paketzähler in der Befehlsausgabe mit Committed Access Rate (CAR) anzeigen

Einleitung

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.

Voraussetzungen

Anforderungen

Es gibt keine spezifischen Anforderungen für dieses Dokument.

Verwendete Komponenten

Dieses Dokument ist nicht auf bestimmte Software- und Hardware-Versionen beschränkt.

Konventionen

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

Grundlegendes zur Ausgabe des Befehls show interface rate

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.

1. Notieren Sie die aktuelle Uhrzeit.

2. Aktualisieren Sie den Token-Bucket mit der Anzahl der Token, die sich seit dem letzten Eintreffen eines Pakets kontinuierlich angesammelt haben.

3. Die Gesamtanzahl der akkumulierten Token darf den Höchstwert für Token nicht überschreiten. Überschüssige Token fallen lassen.

4. Ü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 

Bekannte Probleme mit CAR und Zählern für klassenbasiertes Policing

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.

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

Zugehörige Informationen

• Konfigurieren der zugesicherten Zugriffsrate
• Policing mit CAR
• Verwendung von CAR bei DOS-Angriffen
• Support-Seite für QoS-Technologie
• Support-Seite für IP-Routed-Protokolle
• IP Routing-Support-Seite
• Technischer Support und Dokumentation für Cisco Systeme