Sommario

Introduzione

Prerequisiti

Requisiti

Componenti usati

Convenzioni

Panoramica della compressione dei dati

Hardware Cisco Compression

Coda sofisticata e compressione hardware

Fancy Queueing e compressione software

Compressione header RTP e QoS

Problemi noti

Informazioni correlate

Introduzione

Questo documento esamina i problemi noti relativi all'abilitazione delle funzionalità software di compressione e Quality of Service (QoS) di Cisco IOS® sullo stesso router.

Il software Cisco IOS offre molte funzioni per ottimizzare i collegamenti WAN (Wide-Area Network) e ridurre i colli di bottiglia della larghezza di banda della WAN. La compressione è un metodo di ottimizzazione efficace e include due tipi:

- Compressione dei dati: fornisce a ciascuna estremità uno schema di codifica che consente la rimozione dei caratteri dai frame sul lato di invio del collegamento e la loro corretta sostituzione sul lato di ricezione. Poiché i frame condensati occupano meno larghezza di banda, è possibile trasmettere un numero maggiore di frame per unità di tempo. Esempi di schemi di compressione dati includono STAC, Microsoft Point-to-Point Compression (MPPC) e Frame Relay Forum 9 (FRF.9).

- Compressione header: comprime un'intestazione a vari livelli del modello di riferimento OSI (Open System Interconnection). Gli esempi includono la compressione dell'intestazione TCP (Transmission Control Protocol), il protocollo RTP compresso (cRTP) e il protocollo IP/UDP (Internet Protocol/User Datagram Protocol) compresso.

Prerequisiti

Requisiti

Nessun requisito specifico previsto per questo documento.

Componenti usati

Il documento può essere consultato per tutte le versioni software o hardware.

Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.

Convenzioni

Per ulteriori informazioni sulle convenzioni usate, consultare il documento Cisco sulle convenzioni nei suggerimenti tecnici.

Panoramica della compressione dei dati

La funzione di base della compressione dei dati consiste nel ridurre le dimensioni di un frame di dati trasmesso attraverso un collegamento di rete. Riducendo le dimensioni del frame si riduce il tempo necessario per trasmettere il frame attraverso la rete.

I due algoritmi di compressione dei dati più comunemente usati sui dispositivi di internetworking sono Stacker e Predictor.

Le seguenti configurazioni di esempio mostrano due modi per abilitare la compressione del payload su un'interfaccia o sottointerfaccia Frame Relay.

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

Hardware Cisco Compression

La compressione dei dati basata su hardware offre le stesse funzionalità generali della compressione basata su software, ma accelera i rapporti di compressione scaricando il carico di elaborazione dalla CPU principale. In altre parole:

- Compressione del software: la compressione è implementata nel software Cisco IOS installato nel processore principale del router.

- Compressione hardware - La compressione è implementata nell'hardware di compressione installato in uno slot di sistema. La compressione hardware elimina le responsabilità di compressione e decompressione dal processore principale installato nel router.

Nella tabella seguente vengono elencati l'hardware di compressione Cisco e le piattaforme supportate:

Hardware di compressione

Piattaforme supportate

Note

Adattatori servizi SA-Comp/1 e SA-Comp/4 (CSA)

Cisco serie 7200 Router e Versatile Interface Processor (VIP2) di seconda generazione nei router Cisco serie 7000 e 7500

Supporta l'algoritmo Stacker su interfacce seriali configurate con il protocollo PPP (Point-to-Point Protocol) o l'incapsulamento Frame Relay.

NM-COMPR

Cisco serie 3600 Router

Supporta l'algoritmo di compressione Stacker su collegamenti PPP e Frame Relay con l'algoritmo di compressione FRF.9.

AIM-COMPR4

Cisco serie 3660 Router

Supporta gli algoritmi LZS (Lempel-Ziv Standard) e MPPC.

Configurando la compressione su un'interfaccia seriale con un comando quale compress stack, la compressione hardware viene attivata automaticamente, se disponibile. In caso contrario, la compressione software è attivata. È possibile utilizzare il comando compress stack software per forzare l'uso della compressione software.

Coda sofisticata e compressione hardware

In questa sezione viene descritto un problema risolto con la funzionalità PQ (Priority Queueing) di Cisco legacy e l'hardware di compressione. L'hardware di compressione ha originariamente rimosso i pacchetti dai PQ in modo aggressivo, rimuovendo in modo efficace i vantaggi di PQ. In altre parole, PQ ha funzionato correttamente, ma le code funzionalmente vengono spostate nelle code dell'hardware di compressione (holdq, hw ring e compQ), che sono strettamente FIFO (First-In, First-Out). I sintomi di questo problema sono documentati nell'ID bug Cisco CSCdp33759 (contrassegnato come duplicato di CSCdm91180).

La risoluzione modifica il driver dell'hardware di compressione. In particolare, limita la velocità con cui l'hardware di compressione rimuove i pacchetti dalla coda, riducendo le dimensioni delle code hardware in base alla larghezza di banda dell'interfaccia. Questo meccanismo di contropressione garantisce che i pacchetti rimangano nelle code più sofisticate anziché essere tenuti nelle code dell'hardware di compressione. Per ulteriori informazioni, fare riferimento ai seguenti ID bug:

Nota: per ulteriori informazioni su questi ID, consultare il Bug Toolkit (solo utenti registrati).

- CSCdm91180 - Si applica all'incapsulamento Frame Relay e alla scheda CSA (Compression Service Adapter).

- CSCdp33759 (e CSCdr18251) - Si applica all'incapsulamento PPP e alla CSA.

- CSCdr18251 - Si applica all'incapsulamento PPP e alla compressione asincrona del modulo di interfaccia (AIM-COMPR).

Le code a livello di hardware della compressione Cisco 3660 sono riportate nell'output di esempio seguente del comando show pas caim status. Se le code di compressione hardware memorizzano molti pacchetti, un pacchetto rimosso dalla coda PQ attende alla fine di questa coda, con un conseguente ritardo.

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

Nota:  CSCdr8670 rimuove le modifiche implementate in CSCdm91180 dalle piattaforme che non supportano CSA.

Inoltre, durante la risoluzione del problema, i problemi di espansione dei pacchetti con pacchetti di piccole dimensioni (circa 4 byte) e particolari modelli ripetitivi, come i ping Cisco con modello 0xABCDABCD, sono stati risolti con l'ID bug CSCdm11401. È meno probabile che i pacchetti di piccole dimensioni siano correlati ad altri pacchetti nel flusso e il tentativo di comprimerli potrebbe causare l'espansione dei pacchetti o la reimpostazione del dizionario. La causa principale è un problema del chip utilizzato nel CSA. L'ID bug Cisco CSCdp64837 risolve questo problema modificando il codice di compressione FRF.9 in modo da evitare la compressione dei pacchetti con meno di 60 byte di payload.

Fancy Queueing e compressione software

A differenza della compressione hardware, la compressione software e le code avanzate, incluse le code personalizzate, di priorità e ponderate, non sono supportate sulle interfacce configurate con l'incapsulamento PPP. Questa limitazione è documentata negli ID bug CSCdj45401 e CSCdk86833.

Il motivo di questo limite è che la compressione PPP non è senza stato e mantiene una cronologia della compressione sullo streaming di dati per ottimizzare i rapporti di compressione. I pacchetti compressi devono essere conservati per conservare la cronologia della compressione. Se i pacchetti vengono compressi prima dell'accodamento, devono essere inseriti in un'unica coda. L'inserimento di questi pacchetti in code diverse, come avviene con le code personalizzate e con priorità, può causare l'uscita dei pacchetti dalla sequenza, interrompendo la compressione. Le soluzioni alternative non sono ottimali e non sono state implementate. Tali alternative includono la compressione dei pacchetti quando vengono rimossi dalla coda (inaccettabile per motivi di prestazioni), il mantenimento di una cronologia di compressione separata per ciascuna coda (non supportata e con un sovraccarico significativo) e la reimpostazione della cronologia di compressione per ciascun pacchetto (che influisce in modo sostanziale sui rapporti di compressione). Per ovviare al problema, è possibile configurare l'incapsulamento HDLC (High-Level Data Link Control), ma questa configurazione potrebbe influire sulle prestazioni del sistema e non è consigliata. Utilizzare invece la compressione hardware.

Compressione header RTP e QoS

RFC 1889 specifica il protocollo RTP, che gestisce il trasporto del percorso audio per il protocollo VoIP (Voice over IP). Il protocollo RTP fornisce servizi come il sequenziamento, per identificare i pacchetti perduti, e i valori a 32 bit, per identificare e distinguere tra più mittenti in un flusso multicast. È importante notare che non fornisce né garantisce la qualità del servizio.

I pacchetti VoIP sono composti da uno o più esempi di codec vocali o frame incapsulati in 40 byte di intestazioni IP/UDP/RTP. I 40 byte sono un sovraccarico relativamente grande per i tipici payload VoIP da 20 byte, in particolare sui collegamenti a bassa velocità. La RFC 2508 specifica il protocollo RTP compresso (cRTP), progettato per ridurre le intestazioni IP/UDP/RTP a due byte per la maggior parte dei pacchetti nel caso in cui non venga inviato alcun checksum UDP, o a quattro byte con checksum. L'algoritmo di compressione definito in questo documento si basa in gran parte sulla struttura della compressione dell'intestazione TCP/IP descritta nella RFC 1144 .

La RFC 2508 specifica effettivamente due formati di cRTP:

- RTP compresso (CR): utilizzato quando le intestazioni IP, UDP e RTP rimangono coerenti. Tutte e tre le intestazioni vengono compresse.

- Compressed UDP (CU) - Utilizzata quando si verifica una modifica importante nel timestamp RTP o quando cambia il tipo di payload RTP. Le intestazioni IP e UDP sono compresse, ma l'intestazione RTP no.

Il software Cisco IOS versione 12.1(5)T ha introdotto diversi miglioramenti per la compressione sui circuiti virtuali permanenti (PVC) Frame Relay sui router Cisco serie 2600, 3600 e 7200. Tali miglioramenti includono:

Prima di Cisco IOS release 12.1(5)T

Cisco IOS release 12.1(5)T e 12.2

I metodi di frammentazione edge della WAN a bassa velocità necessari per garantire la qualità della voce non funzionano sulle interfacce con compressione hardware. Questi metodi di frammentazione, che includono MLPPP/LFI, FRF.11 Allegato C e FRF.12, funzionano con la compressione basata su software.

La frammentazione (FRF.12 o Link Fragmentation and Interleaving (LFI)) è supportata insieme alla compressione hardware. Inoltre, FRF.12 e FRF.11 Allegato-C Frammentazione sono supportati con la compressione hardware FRF.9 sullo stesso PVC. I pacchetti voce dalla coda di priorità con LLQ (Low Latency Queueing) ignorano il motore di compressione FRF.9. I pacchetti di dati vengono compressi.

Le compressioni FRF.9 sono supportate solo su PVC IETF-encap

La compressione cRTP e FRF.9 sono supportate sullo stesso PVC. La compressione FRF.9 è supportata sui PVC configurati con l'incapsulamento Cisco e Internet Engineering Task Force (IETF).

Il protocollo cRTP è supportato solo sui PVC Frame Relay configurati con incapsulamento Cisco.

il protocollo cRTP continua a essere supportato solo sui PVC incapsulati da Cisco.

Problemi noti

Nella tabella seguente vengono elencati i problemi noti relativi alle funzionalità QoS di Cisco IOS e cRTP. L'elenco è accurato al momento della pubblicazione. Fare riferimento anche alle note sulla versione del software Cisco IOS in uso per ulteriori informazioni.

ID bug

Descrizione

CSCdv73543

Quando un criterio QoS gerarchico, che utilizza i comandi della CLI QoS modulare, viene applicato a un'interfaccia in uscita e specifica un policer a due livelli, la velocità del traffico conforme può essere inferiore al previsto. Il problema si verifica quando l'azione eseguita sul pacchetto in un livello è diversa da quella nel secondo livello. Ad esempio, conformarsi al primo livello e superare al secondo. Di seguito è riportato un esempio di criterio:
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

Si possono verificare perdite di pacchetti impreviste quando si utilizza LLQ (Low Latency Queueing) su Frame Relay. Il problema è stato causato dal sistema di coda che non ha preso in considerazione i guadagni di larghezza di banda della cRTP.

CSCds43465

In origine, il cRTP è stato eseguito dopo l'accodamento. Il risultato è stato che l'accodamento (potenzialmente) ha visto un pacchetto molto più grande di quello che veniva trasmesso sul cavo. Questo comportamento viene modificato con il bug. La coda ora considera i pacchetti compressi. Con questa modifica, è possibile configurare le istruzioni di larghezza di banda con CBWFQ in base alle velocità di dati compressi.

Informazioni correlate

- Pagina di supporto QoS

- Supporto tecnico – Cisco Systems