Inhalt

Einführung

Voraussetzungen

Anforderungen

Verwendete Komponenten

Konventionen

Übersicht über die Datenkomprimierung

Cisco Komprimierungs-Hardware

Fancy Queuing und Hardware-Komprimierung

Fancy Queuing und Softwarekomprimierung

RTP Header Compression und QoS

Bekannte Probleme

Zugehörige Informationen

Einführung

In diesem Dokument werden bekannte Probleme bei der Aktivierung der Cisco IOS®-Softwarefunktionen für Komprimierung und Quality of Service (QoS) auf demselben Router beschrieben.

Die Cisco IOS-Software bietet zahlreiche Funktionen zur Optimierung von WAN-Verbindungen (Wide Area Network), um Engpässe bei der WAN-Bandbreite zu vermeiden. Die Komprimierung ist eine effektive Optimierungsmethode und umfasst zwei Typen:

- Datenkomprimierung - Stellt jedem Ende ein Codierungsschema zur Verfügung, mit dem Zeichen aus den Frames auf der Absenderseite der Verbindung entfernt und dann auf der Empfängerseite korrekt ersetzt werden können. Da die kondensierten Frames weniger Bandbreite beanspruchen, können pro Zeiteinheit größere Zahlen übertragen werden. Beispiele für Datenkomprimierungsschemata sind STAC, Microsoft Point-to-Point Compression (MPPC) und Frame Relay Forum 9 (FRF.9).

- Header Compression - Komprimiert einen Header auf verschiedenen Ebenen des OSI-Referenzmodells (Open System Interconnection). Beispiele hierfür sind die Transmission Control Protocol (TCP)-Header-Komprimierung, komprimiertes RTP (cRTP) und das komprimierte Internet Protocol/User Datagram Protocol (IP/UDP).

Voraussetzungen

Anforderungen

Für dieses Dokument bestehen keine speziellen Anforderungen.

Verwendete Komponenten

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

Die in diesem Dokument enthaltenen Informationen wurden aus Geräten in einer bestimmten Laborumgebung erstellt. Alle in diesem Dokument verwendeten Geräte haben mit einer leeren (Standard-)Konfiguration begonnen. Wenn Sie in einem Live-Netzwerk arbeiten, stellen Sie sicher, dass Sie die potenziellen Auswirkungen eines Befehls verstehen, bevor Sie es verwenden.

Konventionen

Weitere Informationen zu Dokumentkonventionen finden Sie unter Cisco Technical Tips Conventions.

Übersicht über die Datenkomprimierung

Die grundlegende Funktion der Datenkomprimierung besteht darin, die Größe eines über eine Netzwerkverbindung übertragenen Datenrahmens zu reduzieren. Durch die Reduzierung der Frame-Größe wird die Zeit für die Übertragung des Frames über das Netzwerk reduziert.

Die beiden am häufigsten verwendeten Datenkomprimierungsalgorithmen auf Internetarbeitsgeräten sind Stacker und Predictor.

Die folgenden Beispielkonfigurationen zeigen zwei Möglichkeiten zur Aktivierung der Payload-Komprimierung auf einer Frame-Relay-Schnittstelle oder Subschnittstelle.

interface Serial0/5

ip address 10.0.0.1 255.255.255.0

no ip directed-broadcast

encapsulation frame-relay IETF

clockrate 1300000

frame-relay map ip 10.0.0.2 16 broadcast IETF payload-compression FRF9 stac

interface Serial0/0.105 point-to-point

ip address 192.168.162.1 255.255.255.0

no ip directed-broadcast

frame-relay interface-dlci 105 IETF

class 128k

frame-relay payload-compression FRF9 stac

Cisco Komprimierungs-Hardware

Hardwareunterstützte Datenkomprimierung bietet dieselbe allgemeine Funktionalität wie softwarebasierte Datenkomprimierung, beschleunigt jedoch die Komprimierungsrate, indem sie diese Computing-Leistung von der Haupt-CPU auslagert. Mit anderen Worten:

- Softwarekomprimierung - Die Komprimierung wird in der Cisco IOS-Software implementiert, die im Hauptprozessor des Routers installiert ist.

- Hardwarekomprimierung - Komprimierung wird in der Komprimierungshardware implementiert, die in einem Systemsteckplatz installiert ist. Durch Hardwarekomprimierung werden die Verantwortlichkeiten für Komprimierung und Dekomprimierung vom Hauptprozessor in Ihrem Router entfernt.

In der folgenden Tabelle sind Cisco Hardware für Komprimierung und unterstützte Plattformen aufgeführt:

Komprimierungshardware

Unterstützte Plattformen

Hinweise

SA-Comp/1- und SA-Comp/4-Service-Adapter (CSA)

Cisco Router der Serie 7200 und VIP2 der zweiten Generation für Router der Serien 7000 und 7500

Unterstützt Stacker-Algorithmen über serielle Schnittstellen, die mit Point-to-Point Protocol (PPP)- oder Frame Relay-Kapselung konfiguriert sind.

NM-COMPR

Cisco Router der Serie 3600

Unterstützt den Stacker-Algorithmus über PPP-Links und Frame Relay-Verbindungen mit dem FRF.9-Komprimierungsalgorithmus.

AIM-COMPR4

Nur Cisco Router der Serie 3660

Unterstützt Lempel-Ziv-Standard (LZS)- und MPPC-Algorithmen.

Die Konfiguration der Komprimierung auf einer seriellen Schnittstelle mithilfe eines Befehls wie Komprimierungsstatus ermöglicht automatisch eine Hardwarekomprimierung, sofern verfügbar. Andernfalls ist die Softwarekomprimierung aktiviert. Sie können den Befehl compress stac software verwenden, um die Verwendung von Softwarekomprimierung zu erzwingen.

Fancy Queuing und Hardware-Komprimierung

In diesem Abschnitt wird ein gelöstes Problem mit der Funktion für Legacy Priority Queueing (PQ) und der Komprimierungshardware von Cisco beschrieben. Bei der Komprimierungshardware wurden Pakete ursprünglich aggressiv von den PQs dewartete, wodurch die Vorteile von PQs praktisch wegfielen. Mit anderen Worten, PQ funktionierte ordnungsgemäß, aber Warteschlangen funktionell in die eigenen Warteschlangen der Komprimierungshardware (holdq, hw ring und compQ) verschoben, die streng First-In, First-Out (FIFO) sind. Die Symptome dieses Problems sind in der Cisco Bug-ID CSCdp33759 (als Duplikat von CSCdm91180 gekennzeichnet) dokumentiert.

Die Auflösung ändert den Treiber der Komprimierungshardware. Insbesondere wird die Geschwindigkeit gedrosselt, mit der die Komprimierungshardware Pakete dewartet, indem die Größe der Hardware-Warteschlangen auf Basis der Bandbreite der Schnittstelle reduziert wird. Dieser Rückdruckmechanismus stellt sicher, dass Pakete in den Fancy Queues verbleiben, anstatt in den Warteschlangen der Komprimierungshardware gehalten zu werden. Weitere Informationen finden Sie unter den folgenden Bug-IDs:

Hinweis: Weitere Informationen zu diesen Bug-IDs finden Sie im Bug Toolkit (nur registrierte Kunden) .

- CSCdm91180 - Gilt für Frame-Relay-Kapselung und den Compression Service Adapter (CSA).

- CSCdp33759 (und CSCdr18251) - Gilt für PPP-Kapselung und das CSA.

- CSCdr18251 - Gilt für PPP-Kapselung und die asynchrone Schnittstellenmodul-Komprimierung (AIM-COMPR).

Die Warteschlangen auf Hardwareebene der Cisco 3660-Komprimierung sind in der folgenden Beispielausgabe des Befehls show pas caim stats zu sehen. Wenn die Hardware-Komprimierungswarteschlangen viele Pakete speichern, wartet ein vom PQ dewartetes Paket am Ende dieser Warteschlange und vergeht somit Verzögerungen.

Router> show pas caim stats 0

CompressionAim0

ds:0x80F56A44 idb:0x80F50DB8

422074 uncomp paks in  -->      422076 comp paks out

422071 comp paks in    -->      422075 uncomp paks out

633912308 uncomp bytes in -->    22791798 comp bytes out

27433911 comp bytes in   -->   633911762 uncomp bytes out

974 uncomp paks/sec in -->      974 comp paks/sec out

974 comp paks/sec in -->        974 uncomp paks/sec out

11739116 uncomp bits/sec in -->   422070 comp bits/sec out

508035 comp bits/sec in -->   11739106 uncomp bits/sec out

433 seconds since last clear

holdq: 0  hw_enable: 1  src_limited: 0  num cnxts: 4

no data: 0  drops: 0  nobuffers: 0 enc adj errs: 0 fallbacks: 0

no Replace: 0 num seq errs: 0 num desc errs: 0 cmds complete: 844151

Bad reqs: 0  Dead cnxts: 0 No Paks: 0 enq errs: 0

rx pkt drops: 0  tx pkt drops: 0 >dequeues: 0 requeues: 0

drops disabled: 0 clears: 0 ints: 844314 purges: 0

no cnxts: 0  bad algos: 0 no crams: 0 bad paks: 0

# opens: 0 # closes: 0 # hangs: 0

Hinweis: CSCdr86700 entfernt die in CSCdm91180 implementierten Änderungen von Plattformen, die kein CSA unterstützen.

Zusätzlich wurden bei der Behebung dieses Problems Paketerweiterungsprobleme bei kleinen Paketen (ca. 4 Byte) und bestimmten sich wiederholenden Mustern, wie z. B. Cisco Pings mit dem Muster 0xABCDABCD, mit der Bug-ID CSCdm1401 behoben. Kleine Pakete sind weniger wahrscheinlich mit anderen Paketen im Stream verwandt, und der Versuch, diese zu komprimieren, kann zu erweiterten Paketen führen oder zu einem Zurücksetzen des Wörterbuchs führen. Die Ursache hierfür ist ein Problem mit dem Chip, der auf dem CSA verwendet wird. Die Cisco Bug-ID CSCdp64837 löst dieses Problem, indem der FRF.9-Komprimierungscode geändert wird, um zu verhindern, dass Pakete mit einer Nutzlast von weniger als 60 Byte komprimiert werden.

Fancy Queuing und Softwarekomprimierung

Im Gegensatz zur Hardwarekomprimierung werden Softwarekomprimierung und Fancy Queueing, einschließlich benutzerdefinierter Warteschlangen, Priorität und gewichteter fairer Warteschlangen, auf Schnittstellen, die mit der PPP-Kapselung konfiguriert sind, nicht unterstützt. Diese Einschränkung ist in den Bug-IDs CSCdj45401 und CSCdk86833 dokumentiert.

Der Grund für diese Einschränkung ist, dass die PPP-Komprimierung nicht stateless ist und einen Komprimierungsverlauf über den Datenstrom aufrechterhält, um die Komprimierungsraten zu optimieren. Die komprimierten Pakete müssen aufbewahrt werden, um den Komprimierungsverlauf aufrechtzuerhalten. Wenn Pakete vor der Warteschlange komprimiert werden, müssen sie in einer einzigen Warteschlange gespeichert werden. Wenn sie in verschiedene Warteschlangen gestellt werden, wie dies bei der benutzerdefinierten Warteschlange und der Prioritätswarteschlange der Fall ist, können Pakete aus dieser Sequenz kommen, wodurch die Komprimierung unterbrochen wird. Alternative Lösungen sind nicht optimal und wurden nicht implementiert. Zu diesen Alternativen gehören das Komprimieren von Paketen während der Dewarteschlange (aus Leistungsgründen nicht akzeptabel), das Beibehalten eines separaten Komprimierungsverlaufs für jede Warteschlange (nicht unterstützt und mit erheblichem Overhead verbunden) und das Zurücksetzen des Komprimierungsverlaufs für jedes Paket (was sich erheblich auf Komprimierungsraten auswirkt). Als Problemumgehung können Sie eine High-Level Data Link Control (HDLC)-Kapselung konfigurieren. Diese Konfiguration kann sich jedoch auf die Systemleistung auswirken und wird nicht empfohlen. Verwenden Sie stattdessen Hardwarekomprimierung.

RTP Header Compression und QoS

RFC 1889 legt das RTP fest, das den Audio-Path-Transport für Voice over IP (VoIP) verwaltet. RTP stellt Dienste wie Sequenzierung zur Identifizierung verlorener Pakete und 32-Bit-Werte bereit, um mehrere Absender in einem Multicast-Stream zu identifizieren und zwischen diesen zu unterscheiden. Wichtig ist, dass keine QoS bereitgestellt oder sichergestellt wird.

VoIP-Pakete bestehen aus einem oder mehreren Sprach-Codec-Beispielen oder Frames, die in 40 Byte von IP-/UDP-/RTP-Headern gekapselt sind. 40 Byte sind eine relativ große Menge an Overhead für die typischen 20-Byte-VoIP-Payloads, insbesondere bei Verbindungen mit niedriger Geschwindigkeit. RFC 2508 gibt komprimiertes RTP (cRTP) an, das darauf ausgelegt ist, die IP/UDP/RTP-Header für die meisten Pakete auf zwei Byte zu reduzieren, wenn keine UDP-Prüfsummen gesendet werden, oder auf vier Byte mit Prüfsummen. Der in diesem Dokument definierte Komprimierungsalgorithmus basiert stark auf dem Design der TCP/IP-Header-Komprimierung, wie in RFC 1144 beschrieben.

RFC 2508 gibt zwei Formate von cRTP an:

- Komprimiertes RTP (CR) - Wird verwendet, wenn die IP-, UDP- und RTP-Header konsistent bleiben. Alle drei Header sind komprimiert.

- Komprimiertes UDP (CU) - Wird verwendet, wenn der RTP-Zeitstempel stark geändert wird oder sich der RTP-Payload-Typ ändert. Die IP- und UDP-Header sind komprimiert, der RTP-Header jedoch nicht.

Mit der Cisco IOS Software Version 12.1(5)T wurden bei den Cisco Routern der Serien 2600, 3600 und 7200 verschiedene Verbesserungen für die Komprimierung über permanente Virtual Circuits (PVCs) mit Frame-Relay eingeführt. Zu diesen Verbesserungen gehören:

Vor Cisco IOS Release 12.1(5)T

Cisco IOS-Versionen 12.1(5)T und 12.2

Fragmentierungsmethoden für das WAN-Edge mit niedriger Geschwindigkeit waren erforderlich, um die Sprachqualität bei Schnittstellen mit Hardwarekomprimierung zu gewährleisten. Diese Fragmentierungsmethoden wie MLPPP/LFI, FRF.11 Annex C und FRF.12 arbeiten mit softwarebasierter Komprimierung.

Fragmentierung (FRF.12 oder Link Fragmentation and Interleaving (LFI)) werden zusammen mit Hardwarekomprimierung unterstützt. Darüber hinaus werden FRF.12 und FRF.11 Annex-C Fragmentation mit FRF.9 Hardwarekomprimierung auf demselben PVC unterstützt. Sprachpakete aus der Prioritätswarteschlange mit Low Latency Queueing (LLQ) umgehen die FRF.9 Kompressor-Engine. Datenpakete werden komprimiert.

FRF.9-Kompressionen werden nur auf PVCs mit IETF-Einschluss unterstützt.

cRTP- und FRF.9-Komprimierung werden auf demselben PVC unterstützt. Die FRF.9-Komprimierung wird auf PVCs unterstützt, die mit der Cisco- und IETF-Kapselung (Internet Engineering Task Force) konfiguriert sind.

cRTP wird auf Frame-Relay-PVCs unterstützt, die nur mit Cisco Kapselung konfiguriert sind.

cRTP wird weiterhin nur auf von Cisco gekapselten PVCs unterstützt.

Bekannte Probleme

In der folgenden Tabelle sind bekannte Probleme mit cRTP- und Cisco IOS QoS-Funktionen aufgeführt. Diese Liste ist zum Zeitpunkt der Veröffentlichung korrekt. Weitere Informationen finden Sie in den Versionshinweisen für Ihre Version der Cisco IOS-Software.

Bug-ID

Beschreibung

CSCdv73543

Wenn eine hierarchische QoS-Richtlinie unter Verwendung der Befehle der modularen QoS-CLI auf eine ausgehende Schnittstelle angewendet wird und eine zweistufige Richtlinie angibt, kann die konforme Datenverkehrsrate geringer sein als erwartet. Das Problem tritt auf, wenn sich die Aktion auf einer Ebene von der auf der zweiten Ebene unterscheidet. Zum Beispiel konform auf der ersten Ebene und überschreiten auf der zweiten Ebene. Eine Beispielrichtlinie wird unten veranschaulicht:
policy-map test-policer

class class-default

police 10000 1500 1500 conform-action

transmit exceed-action transmit

service-policy inner-police

!

policy-map inner-police

class prec5

police 20000 1500 1500 conform-action

transmit exceed-action transmit

CSCdt52094

Bei Verwendung von LLQ (Low Latency Queuing) über Frame Relay können unerwartete Paketverluste auftreten. Das Problem wurde durch das Warteschlangensystem verursacht, das die Bandbreitenzuwächse von cRTP nicht berücksichtigt.

CSCds43465

Ursprünglich erfolgte cRTP nach der Warteschlangenverwaltung. Das Ergebnis war, dass die Warteschlange (potenziell) ein viel größeres Paket sah als das, was tatsächlich über das Kabel übertragen wurde. Dieses Verhalten wird mit diesem Fehler geändert. Bei der Warteschlangenverwaltung werden jetzt komprimierte Pakete berücksichtigt. Mit dieser Änderung können Sie auf der Grundlage komprimierter Datenraten Bandbreitenanweisungen mit CBWFQ konfigurieren.

Zugehörige Informationen

- QoS-Support-Seite

- Technischer Support - Cisco Systems