このドキュメントでは、同じルータで圧縮および Quality of Service(QoS)の Cisco IOS® ソフトウェア機能を有効にするときの既知の問題について説明します。
Cisco IOS ソフトウェアでは、ワイドエリア ネットワーク(WAN)リンクを最適化して、WAN 帯域幅のボトルネックを緩和する機能を多数用意しています。圧縮は効果的な最適化手法で、次の 2 種類があります。
データ圧縮:リンクの送信側でフレームから文字を削除し、受信側で削除した文字を正しく復元する符号化方式を各端に提供します。圧縮フレームでは、占有する帯域幅が減少するため、単位時間あたりに送信できるフレーム数が増加します。データ圧縮方式の例には、STAC、Microsoft Point-to-Point Compression(MPPC)、Frame Relay Forum 9(FRF.9; フレームリレー フォーラム 9)などがあります。
ヘッダー圧縮:OSI(Open System Interconnection; オープン システム インターコネクション)参照モデルの各レイヤで、ヘッダーを圧縮します。例としては、Transmission Control Protocol(TCP)ヘッダー圧縮、compressed RTP(cRTP)、compressed Internet Protocol/User Datagram Protocol(IP/UDP)などがあります。
このドキュメントに特有の要件はありません。
このドキュメントの内容は、特定のソフトウェアやハードウェアのバージョンに限定されるものではありません。
このマニュアルの情報は、特定のラボ環境に置かれたデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、初期(デフォルト)設定の状態から起動しています。実稼動中のネットワークで作業をしている場合、実際にコマンドを使用する前に、その潜在的な影響について理解しておく必要があります。
ドキュメントの表記法の詳細は、「シスコ テクニカル ティップスの表記法」を参照してください。
データ圧縮の基本的な機能は、ネットワーク リンクで送信するデータ フレームのサイズを小さくすることです。フレームのサイズを小さくすると、ネットワークでフレームの送信にかかる時間が短縮されます。
インターネットワーキング デバイスで最も一般的に使用されているデータ圧縮アルゴリズムは、Stacker と Predictor の 2 つです。
次の設定例では、フレームリレーのインターフェイスとサブインターフェイスで、ペイロード圧縮を有効にする 2 つの方法を示しています。
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
ハードウェアの支援を伴うデータ圧縮では、ソフトウェア ベースのデータ圧縮と同じ機能が得られますが、演算にかかる負荷からメイン CPU が解放されるため、圧縮速度が高速化します。まとめると、次のようになります。
ソフトウェア圧縮:圧縮機能は、ルータのメイン プロセッサにインストールされる Cisco IOS ソフトウェアに実装されています。
ハードウェア圧縮:圧縮機能は、システム スロットに取り付けられている圧縮ハードウェアに実装されています。ハードウェア圧縮を使用すると、ルータに搭載されているメイン プロセッサに、圧縮および圧縮解除の処理の負担がかからなくなります。
次の表に、シスコの圧縮ハードウェアとサポートするプラットフォームを示します。
圧縮ハードウェア | 対応プラットフォーム | 注意事項 |
---|---|---|
SA-Comp/1 および SA-Comp/4 サービス アダプタ(CSA) | Cisco 7200 シリーズ ルータおよび、Cisco 7000 と 7500 シリーズ ルータの Second-generation Versatile Interface Processor(VIP2) | Point-to-Point Protocol(PPP; ポイントツーポイント プロトコル)またはフレームリレーのカプセル化が設定されているシリアル インターフェイスで、Stacker アルゴリズムをサポートします。 |
NM-COMPR | Cisco 3600 シリーズ ルータ | FRF.9 圧縮アルゴリズムを使用する PPP リンクおよびフレームリレー リンクで、Stacker アルゴリズムをサポートします。 |
AIM-COMPR4 | Cisco 3660 シリーズ ルータのみ | Lempel-Ziv Standard(LZS)および MPPC アルゴリズムをサポートします。 |
シリアル インターフェイスで compress stac などのコマンドを使用して圧縮を設定すると、ハードウェア圧縮が使用可能な場合は、自動的にハードウェア圧縮が有効になります。そうでない場合は、ソフトウェア圧縮が有効になります。compress stac software コマンドを使用すると、強制的にソフトウェア圧縮を有効にできます。
このセクションでは、シスコの従来の Priority Queueing(PQ; プライオリティ キューイング)機能と圧縮ハードウェアに関する解決済みの問題について説明します。当初の圧縮ハードウェアは、PQ からパケットを強制的に取り出していたため、事実上 PQ の利点を損なっていました。つまり PQ は正常に機能していたものの、キューイング機能は、First-In, First-Out(FIFO; ファーストイン ファーストアウト)を原則とする圧縮ハードウェアのキュー(holdq、hw リングおよび compQ)で行われていました。 この問題の症状は、Cisco Bug ID CSCdp33759 に記載されています(CSCdm91180 の複製としてマークされています)。
この解決策では、圧縮ハードウェアのドライバを変更します。具体的には、インターフェイスの帯域幅に応じてハードウェア キューのサイズを小さくすることで、圧縮ハードウェアがパケットを取り出す率を制限します。このバック プレッシャ メカニズムにより、パケットが圧縮ハードウェアのキューで待機せず、高度なキューで待機するようになります。詳細については、次の Bug ID を参照してください。
注:これらのバグIDの詳細は、Bug Toolkit(登録ユーザ専用)を使用して確認できます。
CSCdm91180:フレームリレーのカプセル化および Compression Service Adapter(CSA)に適用されます。
CSCdp33759(および CSCdr18251):PPP カプセル化および CSA に適用されます。
CSCdr18251:PPP カプセル化および Asynchronous Interface Module-Compression(AIM-COMPR)に適用されます。
Cisco 3660 の圧縮のハードウェアレベルのキューは、show pas caim stats コマンドの次の出力例で確認できます。ハードウェア圧縮キューに多数のパケットが格納されると、PQ から取り出されたパケットはこのキューの一番後ろで待機するため、遅延が発生します。
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
注: CSCdr86700 では、CSA をサポートしないプラットフォームから、CSCdm91180 で実装した変更内容を取り除いています。
また、この問題のトラブルシューティング中に、小さなパケット(約4バイト)やパターン0xABCDABCDのCisco pingなどの特定の繰り返しパターンのパケット拡張の問題がバグID CSCdm11401で解決されました。根本原因は、CSA で使用しているチップに伴う問題です。Cisco Bug ID CSCdp64837 では、60 バイト未満のペイロードのパケットの圧縮は回避するように FRF.9 圧縮コードを変更することで、この問題を解決しています。
ハードウェア圧縮とは異なり、ソフトウェア圧縮と高度なキューイング(カスタム、プライオリティ、均等化などのキューイング)は、PPP カプセル化が設定されているインターフェイスでは、サポートされません。この制限事項については、Bug ID CSCdj45401 および CSCdk86833 に記載されています。
この制限がある理由は、PPP 圧縮がステートレスではなく、データ ストリームの圧縮履歴を維持更新することにより圧縮比を最適化するためです。圧縮履歴を維持更新するには、圧縮パケットを保持する必要があります。パケットがキューイングの前に圧縮される場合は、単一のキューに入れる必要があります。カスタム キューイングやプライオリティ キューイングで行われるように、パケットを異なる複数のキューに入れると、パケットの到着順序が前後してしまい、圧縮が損なわれる場合があります。代替ソリューションは最適とはいえないため、実装されていません。このような代替ソリューションには、パケットを取り出すときに圧縮する(パフォーマンス上の理由から望ましくない)、各キューごとに圧縮履歴を維持更新する(サポートされておらず、相当量のオーバーヘッドが発生する)、パケット単位で圧縮履歴をリセットする(圧縮比に大きな影響を与える)、などがあります。 回避策として、High-level Data Link Control(HDLC; ハイレベル データリンク コントロール)カプセル化を設定することもできますが、この設定はシステムのパフォーマンスに影響を及ぼす可能性があるため、推奨しません。代わりに、ハードウェア圧縮を使用してください。
RFC 1889は 、Voice over IP(VoIP)の音声パス転送を管理するRTPを指定します。RTP では、損失パケットを識別するために順番付けを行うサービスや、マルチキャスト ストリームで複数の送信元を識別して区別するための 32 ビット値が提供されます。重要なのは、RTP では、QoS が提供および保証されない点です。
VoIP パケットは、40 バイトの IP/UDP/RTP ヘッダーにカプセル化された 1 つ以上の音声コーデック サンプルまたはフレームで構成されています。一般的な 20 バイトの VoIP ペイロードにとって、特に低速リンクでは、40 バイトは比較的大きなオーバーヘッドです。RFC 2508は 、圧縮RTP (cRTP)を指定しています。これは、UDPチェックサムが送信されない場合に、ほとんどのパケットでIP/UDP/RTPヘッダーを2バイトに減らすように設計されています。このドキュメントで定義されている圧縮アルゴリズムは、RFC 1144で説明されているTCP/IPヘッダー圧縮の設計に大きく基づいて作成されます 。
RFC 2508 では次の 2 つの cRTP のフォーマットを規定しています。
Compressed RTP(CR):IP、UDP および RTP ヘッダーの整合性を維持できる場合に使用されます。3 つのヘッダーは、すべて圧縮されます。
Compressed UDP(CU):RTP タイムスタンプに大きな変更がある場合や、RTP ペイロード タイプが変わる場合に使用されます。IP および UDP ヘッダーは圧縮されますが、RTP ヘッダーは圧縮されません。
Cisco IOS ソフトウェア リリース 12.1(5)T では、Cisco 2600、3600 および 7200 シリーズ ルータでのフレームリレー Permanent Virtual Circuit(PVC; 相手先固定接続)の圧縮処理が、いくつか改善されています。改善内容は、次のとおりです。
Cisco IOS リリース 12.1(5)T より前のリリース | Cisco IOS リリース 12.1(5)T および 12.2 |
---|---|
音声品質の保証に必要な低速 WAN エッジのフラグメンテーション方式が、ハードウェア圧縮を使用するインターフェイスで機能していなかった。これらのフラグメンテーション方式(MLPPP/LFI、FRF.11 Annex C、FRF.12 など)は、ソフトウェアベースの圧縮では機能する。 | フラグメンテーション(FRF.12 または Link Fragmentation and Interleaving(LFI))は両方、ハードウェア圧縮でサポートされている。さらに、FRF.12 および FRF.11 Annex-C フラグメンテーションが、同じ PVC 上の FRF.9 ハードウェア圧縮でサポートされている。Low Latency Queueing(LLQ; 低遅延キューイング)を使用しているプライオリティ キューの音声パケットは、FRF.9 圧縮エンジンをバイパスする。データ パケットは圧縮される。 |
FRF.9 圧縮は、IETF-encap PVC でのみサポートされている。 | cRTP および FRF.9 圧縮は、同じ PVC 上でサポートされている。FRF.9 圧縮は、シスコおよび Internet Engineering Task Force(IETF; インターネット技術特別調査委員会)のカプセル化が設定されている PVC 上でサポートされる。 |
cRTP は、シスコのカプセル化が設定されているフレームリレー PVC でのみサポートされている。 | cRTP は引き続き、シスコのカプセル化が設定されている PVC でのみサポートされている。 |
次の表に、cRTP および Cisco IOS の QoS 機能に関する既知の問題を示します。この表は、このドキュメントの発行時点の内容です。詳細については、ご使用のバージョンの Cisco IOS ソフトウェアのリリース ノートを参照してください。
Bug ID | 説明 |
---|---|
CSCdv73543 | モジュラ QoS CLI のコマンドを使用する階層型 QoS ポリシーが、発信インターフェイスに適用され、2 レベルのポリサーを指定している場合に、トラフィックの適合レートが予想より低くなることがあります。この問題は、第 1 レベルのパケットで実行する処理と、第 2 レベルのパケットで実行する処理が異なる場合に発生します。たとえば、レートが第 1 レベルに適合して、第 2 レベルで超過する場合があります。次に、ポリシーの例を示します。 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 | フレームリレーで Low Latency Queueing(LLQ)を使用している場合に、予期しないパケットの廃棄が発生することがあります。この問題は、cRTP の帯域幅のゲインを考慮していないキューイング システムが原因で発生していました。 |
CSCds43465 | 当初、cRTP はキューイングの後に行われていました。そのため場合によっては、キューイングでは、パケットを実際に回線上に送信されるよりもかなり大きいサイズであると認識していました。この不具合に伴って動作が変更されています。現在は、キューイングで圧縮パケットを考慮しています。この変更により、bandwidth 文を使用して、圧縮データ レートに基づく CBWFQ を設定できます。 |