サービス品質(QoS) : QoS パケット マーキング

暗号設定およびQoS へのレファレンスガイド

2016 年 6 月 18 日 - 機械翻訳について
その他のバージョン: PDFpdf | ライター翻訳版 (2005 年 8 月 10 日) | 英語版 (2015 年 12 月 19 日) | フィードバック


目次


概要

VPN がデータ、音声およびビデオ トラフィックを含むようになると、ネットワークではトラフィック タイプに応じて異なる処理を行う必要があります。 Quality of service(QoS)と帯域幅を管理する機能によって、VPN では、音声やビデオなどの時間依存型アプリケーション向けの高度な伝送品質を提供できるようになりました。 各パケットには、そのペイロードの優先順位および時間の影響の受けやすさを識別するためのタグが付けられ、トラフィックは、その配信優先順位に基づいてソートされ、ルーティングされます。 Cisco VPN ソリューションでは、さまざまな QoS 機能をサポートします。

この資料は Cisco IOS を設定するユーザ向けの単一のレファレンスとして動作するために編集されますか。 ルータの同じネットワークまたはセットの暗号化および QoS 機能。 この文書によって、IP Security(IPSec)や generic routing encapsulation(GRE; 総称ルーティングカプセル化)トンネルが設定されている場面での、入力および出力 QoS ポリシーの基本的な設定が理解できるようになります。 また、この文書では、設定タスクについても説明します。 さらに、シスコ ルータを使用した拡張 IP サービスの最適なパフォーマンスと正常な実装を保証するために、制限と既知の問題に関する情報を提供します。

前提条件

要件

このドキュメントの読者は次のトピックについて理解している必要があります。

  • IPSec テクノロジー

IPSec に関するより包括的なマニュアルについては、『IP Security(IPSec)暗号化の概要』を参照してください。

使用するコンポーネント

このドキュメントは、特定のソフトウェアやハードウェアのバージョンに限定されるものではありません。

表記法

ドキュメント表記の詳細は、『シスコ テクニカル ティップスの表記法』を参照してください。

IPSec プロトコル

IPSec プロトコルの詳細な説明はこの文書の範囲を越えています。 そのため、ここではその概要について説明します。 IPSec それ以上のリソースについてはこの資料の「関連情報」セクションを参照して下さい。

IPsec はネットワーク層の認証および暗号化モデルを定義します。 これは、セキュアな接続を構築するための暗号キー交換と、2 つのピアがネゴシエートしてから暗号化された接続のライフタイムを通して使用する認証および暗号化プロトコルで構成されます。

Internet Security Association and Key Management Protocol(ISAKMP)は、暗号化ポリシーをネゴシエートして、IPSec ピアによって共有されるキーを生成するための共通フレームワークを提供します。 ISAKMP ネゴシエーションの結果、Security Association(SA; セキュリティ結合)が構築されます。 次の show crypto isakmp policy コマンドの出力例では、SA のネゴシエーションで使用されるパラメータを示します。

P5R0#show crypto isakmp policy 
Protection suite of priority 100 
        encryption algorithm:   DES - Data Encryption Standard (56 bit keys). 
        hash algorithm:         Secure Hash Standard 
        authentication method:  Pre-Shared Key 
        
!--- Supports pre-shared keys or a public/private 

		
!--- key mechanism such as RSA.
 
        Diffie-Hellman group:   #1 (768 bit) 
        lifetime:               86400 seconds, no volume limit 
        
!--- Lifetime can be based on time or on the  number of transmitted bytes.
 
Default protection suite 
        encryption algorithm:   DES - Data Encryption Standard (56 bit keys). 
        hash algorithm:         Secure Hash Standard 
        authentication method:  Rivest-Shamir-Adleman Signature 
        Diffie-Hellman group:   #1 (768 bit) 
        lifetime:               86400 seconds, no volume limit

ISAKMP ネゴシエーションによって、ピアが追加の IPSec パラメータをネゴシエートする暗号化された接続(と SA)が構築されます。 これには、IP ダイアグラムの保護に使用される実際のプロトコルが含まれます。 具体的には、2 つの暗号化ピア間で、次の表のパラメータがネゴシエートされます。

パラメータ オプション
IPSec プロトコル セット
  • 認証ヘッダー(AH)
  • Encapsulating Security Payload(ESP)
ほとんどのアプリケーションが AH または ESP で十分対応できます。
モード
  • トンネル モード:元の IP ヘッダーを保持および暗号化した上で、カプセル化 IP ヘッダーが新しく追加されます。
  • トランスポート モード:元の IP ヘッダーが保持されますが、プロトコル フィールドが AH または ESP を表すようにそれぞれ値 51 または 50 に変更されます。
ネゴシエーション フェーズでは、トランスポート モードにする場合、ISAKMP により自動的にトンネル モードに「フォール バック」されますが、確立はできません。

注:  RFC 2401 leavingcisco.com 「外側」または「封入」ヘッダーという用語がトンネル モードを使用した新しい IP ヘッダーを説明するために使用され、「内側」ヘッダーという用語がオリジナルの IP ヘッダーを説明するために使用されます。 RFC からの引用は次のとおりです。 "「外側の IP ヘッダーの送信元アドレスおよび宛先アドレスによって、トンネルの「エンドポイント」(カプセル化側と非カプセル化側)が識別されます。 内側の IP ヘッダーの発信元アドレスと宛先アドレスにより、データグラムの元々の発信元と宛先(トンネルの観点から)をそれぞれ識別する。」とあります。 以降では、これらの用語を使用します。

変換セット
  • 認証専用の AH。
  • 認証と暗号化用の ESP。

この show crypto ipsec sa address コマンドの出力は、IPSec SA を示しています。個々の SA はセキュリティ パラメータ インデックス(SPI)で識別されます。 たとえば、0x21A85375(564679541)の SPI で識別された接続では、AH 用の MD5-HMAC アルゴリズムと ESP 用の DES が使用されます。

P5R0#show crypto ipsec sa address 
dest address: 10.1.1.1 

!--- Address of the IPSec peer.
 
   protocol: AH 
      spi: 0x93B90183(2478375299) 
        transform: ah-md5-hmac , 
        in use settings ={Tunnel, } 
        slot: 0, conn id: 2808, flow_id: 405, crypto map: testibm 
        sa timing: remaining key lifetime (k/sec): (4607901/1654) 
        replay detection support: Y 
      spi: 0x21A85375(564679541) 
        transform: ah-md5-hmac , 
        
!--- AH  uses the MD5-HMAC algorithm.
 
        in use settings ={Transport, } 
        slot: 0, conn id: 2812, flow_id: 407, crypto map: testibm 
        sa timing: remaining key lifetime (k/sec): (4607915/1604) 
        replay detection support: Y 

   protocol: ESP 
      spi: 0xDFF0FEC3(3757113027) 
        transform: esp-des , 
        in use settings ={Tunnel, } 
        slot: 0, conn id: 2810, flow_id: 405, crypto map: testibm 
        sa timing: remaining key lifetime (k/sec): (4607901/1654) 
        IV size: 8 bytes 
        replay detection support: Y 
      spi: 0xDB00B862(3674257506) 
        transform: esp-des , 
        
!--- ESP  uses DES.
 
        in use settings ={Transport, } 
        
!--- Transport mode accepted for this flow.
 
        slot: 0, conn id: 2814, flow_id: 407, crypto map: testibm 
        sa timing: remaining key lifetime (k/sec): (4607914/1568) 
        IV size: 8 bytes 
        replay detection support: Y

AH と ESP

の表に示すように、AH と ESP は別々に使用することも、一緒に使用することもできます。 ただし、ほとんどのアプリケーションではどちらか一方で十分です。 両方のプロトコルにおいて、IPSec は使用する特定のセキュリティ アルゴリズムを定義しません。 代わりに、業界標準アルゴリズムを実装するためのオープン フレームワークを提供します。

AH は、SHA または MD5 ハッシュ アルゴリズムを使用した IP データグラムに強力な整合性と認証を提供します。 また、否認防止も提供します。 AH は最小 12 バイトで、次に図示してあります。 Internet Assigned Numbers Authority(IANA)では、AH にプロトコル番号 51 を割り当てています。 したがって、トンネル モードとトランスポート モードのどちらでも AH ヘッダーを使用する場合には、IP ヘッダーのプロトコル フィールドには 51 という値が使用されます。

この図では、IPSec AH によるパケットの形式を表しています。 トンネル モードでは、元の IP ヘッダーからトンネル ヘッダーへ、type of service(TOS; タイプ オブ サービス)バイトの値が自動的にコピーされます。 詳細については、この文書の「パケットの分類」の項を参照してください。

http://www.cisco.com/c/dam/en/us/support/docs/quality-of-service-qos/qos-packet-marking/18667-crypto-qos-01.gif

ESP は、暗号化されていないヘッダーの後ろに暗号化されたデータと暗号化されたトレーラーが続きます。 ESP は暗号化と認証の両方を提供します。 AH と同様に、ESP は、認証用の SHA および MD5 ハッシュ アルゴリズムをサポートします。 また、暗号化プロトコルとして DES と 3DES をサポートします。 ESP ヘッダーは最小 8 バイトで、次に図示してあります。 IANA では、ESP にプロトコル番号 50 を割り当てています。 したがって、トンネル モードおよびトランスポート モードのどちらでも、ESP ヘッダーだけを使用する場合には、IP ヘッダーそのプロトコル フィールドには 50 という値が使用されます。

この図では、IPSec ESP ヘッダーとトレーラが付いたパケットの形式が表されています。 トンネル モードでは、元の IP ヘッダーからトンネル ヘッダーへ、TOS バイトの値が自動的にコピーされます。 詳細については、この文書の「パケットの分類」の項を参照してください。

http://www.cisco.com/c/dam/en/us/support/docs/quality-of-service-qos/qos-packet-marking/18667-crypto-qos-02.gif

IPSec による GRE トンネルの使用

IPSec は、Internetwork Packet Exchange(IPA)や AppleTalk などのマルチキャストまたは非 IP トラフィックをサポートしません。 IPSec ではマルチキャスト トラフィックがサポートされていないということは、EIGRP(224.0.0.10)や OSPF(224.0.0.5 および 224.0.0.6)のようなマルチキャストのトラフィック ルーティング プロトコル情報が搬送できないことを意味します。 GRE がマルチキャスト トラフィックのカプセル化に使用されます。 この後、このトラフィックは、IPSec によって暗号化されるため、ルーティング プロトコル トラフィックが VPN 上を流れることができます。 IPSec と GRE の設定例については、『OSPF を使用した IPSec 経由の GRE トンネルの設定』を参照してください。

GRE トンネル ヘッダーにより、2 段階目のカプセル化ができます。 IPsec を使用せず、GRE トンネルのみを使用する場合は、『GRE トンネル インターフェイスのサービス オプションの品質』を参照してください。 この図では、IPSec、GRE でカプセル化されたパケットと、元の IP ヘッダーを表しています。

http://www.cisco.com/c/dam/en/us/support/docs/quality-of-service-qos/qos-packet-marking/18667-crypto-qos-03.gif

パケットの分類

分類は、パケットのレイヤ 2、3、または 4 ヘッダー内の 1 つ以上のフィールドを照合してから、そのパケットをトラフィックのグループまたはクラスに配置するプロセスを定義したものです。 パケットの分類により、ネットワークのトラフィックを複数の優先順位レベルやサービスのクラスに分けることができます。

IPSec と GRE をあわせて設定する場合、最も簡単な分類方法は、IP 優先順位または Differentiated Services Code Point(DSCP; DiffServ コード ポイント)の値を照合することです。 Cisco IOS ソフトウェア リリース 11.3T で、IPsec と一緒に ToS バイト保存機能のサポートが導入されました。 この機能を使用すると、トンネル モードの IPSec が使用されている場合、ルータによって、元の IP パケットからカプセル化された IP ヘッダーに ToS ヘッダーの値が自動的にコピーされます。

Cisco PIX ファイアウォール バージョン 5.1 以降と VPN 3000 シリーズ コンセントレータ バージョン 3.5 以降は、TOS バイト コピーをサポートします。 RFC 2401 の第 5.1.2 項「Header Construction for Tunnel Mode」では、 leavingcisco.com IP ToS ビットのコピーが必須です。

ToS バイトの維持は、AH にも該当します。 トランスポート モードの ESP はオリジナルの IP ヘッダーを保持することと、オリジナルの ToS 値は ToS バイト保存を使用せずに送信されることに注意してください。

IP プレシデンスまたは DSCP 値が設定されていないパケットがルータに到着した場合は、暗号化またはカプセル化の前に、パケット ヘッダーを再マーキングするためのクラスに基づいてマーキングすることができます。 パケットが出力インターフェイスに到達すると、QoS 出力ポリシーにより、再マークされた値に基づいて照合と処理が行えます。

IP 優先順位に基づいて QoS ポリシーを設定する際には、次の 2 つのポリシーが適用されます。

ポリシーのタイプ ポリシーの動作 ポリシーの場所
入力 オリジナルの IP ヘッダー内の IP プレシデンスをマーキングします。 入力インターフェイス
出力 IP 優先順位によって差別化されたトラフィックのクラスに対して、最低限の帯域幅の保証を付与。 出力インターフェイス

この表では、IP 優先順位に基づいた QoS ポリシーの設定を示しています。

ToS に基づいた QoS
入力ポリシー
access-list 150 permit tcp any any eq www
access-list 150 permit tcp any eq www any
access-list 151 permit tcp any any eq telnet
access-list 151 permit tcp any eq telnet any 
!
class-map match-any ingress-web
  match access-group 150
class-map match-any ingress-telnet
  match access-group 151
!
policy-map setToS
  class ingress-web
   set ip precedence 1
  class ingress-telnet
   set ip precedence 2
!
interface ethernet 0/0
  service-policy in setToS
出力ポリシー
class-map match-any egress-web
  match ip precedence 1
class-map match-any egress-telnet
  match ip precedence 2
!
policy-map useToS
  class egress-web
    bandwidth percent 25
  class egress-telnet
    bandwidth percent 15
!
interface serial 1/0
  bandwidth 512
  service-policy out useToS
  crypto-map TEST

図には表示されていませんが、テール ドロップに対する代替ドロップ メカニズムとしてクラスごとに重み付けランダム早期検出(WRED)を適用することもできます。

再マークされた IP 優先順位の値は、ネットワーク全体に適用されます。 そのため、予想外の分類やパフォーマンスが生じないように、QoS ドメイン全体を通して一貫性のあるポリシーが実装されていることを確認してください。

また、IP プレシデンスまたは DSCP 以外の値に基づいてトラフィックを分類したい場合があります。 たとえば、送信元 IP アドレスや宛先 IP アドレスなどの IP フローまたはレイヤ 3 情報に基づいてパケットを分類する場合です。 これを実行するには、VPN 向けの QoS 機能を使用する必要があります。 この機能は、qos pre-classify コマンドで有効になり、Cisco IOS ソフトウェア リリース 12.1(5)T 以降の Cisco 7100 シリーズ VPN ルータおよび Cisco 7200 シリーズ ルータと Cisco IOS ソフトウェア リリース 12.2(2)T 以降の Cisco 2600 および 3600 シリーズ ルータで使用できます。 『バーチャル プライベート ネットワーク向けの QOS の設定』を参照してください。

qos pre-classify メカニズムによって、シスコ ルータは、内側 IP ヘッダー内のフィールドに基づいて暗号化する前に、内側 IP ヘッダーのコピーを取って、QoS 分類を実行できるようになります。 この機能がない場合、同じトンネルを通過するパケットは、すべて同一のトンネル ヘッダーを持ち、輻輳の発生時には同じ扱いを受けます。このため分類エンジンでは、単一の方式で暗号化されてトンネル処理されたフローしか扱わないことになります。

分類ポリシーが ToS バイトと一致する場合は、デフォルトで、その ToS 値が外側ヘッダーにコピーされるため、qos pre-classify コマンドを使用する必要がありません。 IP 優先順位に基づいてトラフィックをクラスに分類するという、簡単な QoS ポリシーを作ることができます。 ただし、クラス内のトラフィックを区別して、複数のフロー ベースのキューに分割するには、qos pre-classify コマンドが必要です。

注: ToS バイトのコピーは、qos pre-classify コマンドではなく、トンネリング メカニズムによって実行されます。

qos pre-classify コマンドは、次の図に示すように、構成の中のさまざまな箇所で適用できます。

  • GRE のみ:トンネル インターフェイスで qos pre-classify コマンドを設定します。

    interface Tunnel0
      ip address 1.1.1.1 255.255.255.252
      qos pre-classify
      tunnel source 12.2.2.8
      tunnel destination 12.2.2.6
    !
    interface serial 0/0
      ip address 12.2.2.8 255.255.255.0
      fair-queue
  • IPsec のみ:暗号マップに基づいて qos pre-classify コマンドを設定します。

    crypto map TEST 10 ipsec-isakmp
      set peer 5.5.5.5
      set transform-set SET
      match address Test
      qos pre-classify
    !
    interface serial 0/0
      ip address 5.5.5.4 255.255.255.0
      crypto map TEST
      random-detect
      random-detect flow
  • IPSec と GRE:トンネル インターフェイスと暗号マップに基づいて qos pre-classify コマンドを設定します。

    crypto map TEST 10 ipsec-isakmp
      set peer 12.2.2.6
      set transform-set SET
      match address Test
      qos pre-classify
    !
    interface Tunnel0
      ip address 1.1.1.1 255.255.255.252
      qos pre-classify
      tunnel source 12.2.2.8
      tunnel destination 12.2.2.6
      crypto map TEST
    !
    interface serial 0/0
      ip address 12.2.2.8 255.255.255.0
      service-policy out matchPORTnumbers
      crypto map TEST

IPSec と GRE を使用した QoS 事前分類を設定するには、次の手順を実行します。

  1. 暗号マップを設定して、マップ コンフィギュレーション モードで qos pre-classify コマンドを指定します。

    crypto map cryptomap_gre1 10 ipsec-isakmp
    	set peer 172.32.241.9
    	set transform-set transf_GRE1_transport
    	match address 130
    	qos pre-classify
  2. show crypto map コマンドを使用して、設定を確認します。

    2621vpn1#show crypto map
    Crypto Map: "cryptomap_gre1" idb: Loopback0 local address: 172.31.247.1
    Crypto Map "cryptomap_gre1" 10 ipsec-isakmp
            Description: Crypto map on GRE1 tunnel mode transport - 10.240.252.0->3/30
            Peer = 172.32.241.9
            Extended IP access list 130
                access-list 130 permit gre host 172.31.247.1 host 172.32.241.9
            Current peer: 172.32.241.9
            Security association lifetime: 4608000 kilobytes/3600 seconds
            PFS (Y/N): N
            Transform sets={ transf_GRE1_transport, }
            QOS pre-classification
  3. GRE トンネル インターフェイスを定義して、crypto map コマンドqos pre-classify コマンドを適用します。

    interface Tunnel0
    ip address 10.240.252.1 255.255.255.252
    qos pre-classify
    tunnel source Loopback0
    tunnel destination 172.32.241.9
    crypto map cryptomap_gre1
  4. show interface tunnel 0 コマンドを使用して、QoS 事前分類が有効になっていることを確認します。

    2621vpn1#show interface tunnel 0
    Tunnel0 is up, line protocol is up
      Hardware is Tunnel
      Description: VPN resilience test - 1st GRE tunnel Interface mode transport - 10.240.252.0->3/3
      Internet address is 10.240.252.1/30
      Tunnel source 172.31.247.1 (Loopback0), destination 172.32.241.9
      Tunnel protocol/transport GRE/IP, key disabled, sequencing disabled
      Checksumming of packets disabled,  fast tunneling enabled
      Last input 00:00:04, output 00:00:04, output hang never
      Last clearing of "show interface" counters 00:00:51
      Queueing strategy: fifo (QOS pre-classification)
      Output queue 0/0, 0 drops; input queue 0/75, 0 drops

上記の出力では、トンネル インターフェイスで、QoS 事前分類と高度なキューイングが有効にされている状態でも、引き続きキューイング方式として First In First Out(FIFO; 先入れ先出し)が使用されていることを示しています。 これは、Queueing strategy:fifo (QOS pre-classification) 行を指定した show コマンド出力に表示されます。 宛先デバイスは間違った順序で到着した IPsec パケットをドロップするため、GRE トンネルと IPsec トンネルの両方に FIFO キューイングが必要です。

VPN 環境では、トンネル インターフェイスまたは基礎となる物理インターフェイスに QoS サービス ポリシーを適用できます。 qos pre-classify コマンドを設定する必要があるかどうかは、分類に使用するヘッダーとヘッダー値によって決まります。

  • 内側ヘッダーに基づいてパケットを分類する場合は、qos pre-classify コマンドを使用せずにポリシーをトンネル インターフェイスに適用します。

  • 外側ヘッダーに基づいてパケットを分類する場合は、qos pre-classify コマンドを使用せずにポリシーを物理インターフェイスに適用します。

  • 物理インターフェイスが輻輳ポイントになる可能性があるため、内側ヘッダーに基づいてパケットを分類し、ポリシーを物理インターフェイスに適用する場合は、ポリシーを物理インターフェイスに適用して、qos pre-classify コマンドを有効にします。

2002 年 5 月より、VPN 環境内の物理インターフェイスに階層型ポリシーを適用することが推奨されます。 『QOS ポリシーとしてのトラフィック ポリシー(階層化トラフィック ポリシー)の例』を参照してください。 この設定では、親ポリシーがトンネルごとにそれに属しているすべてのトラフィックを分類または照合するクラスを 1 つずつを含み、shape コマンドを使用してトンネルの出力を制限します。 トンネル内部のフローの分類は、子ポリシーを利用して適用され、qos pre-classify コマンドを使用して内側 IP ヘッダーに基づくことも、qos pre-classify コマンドを使用せずに外側 IP ヘッダーに基づくこともできます。 トンネルに関するすべての親ポリシーの shape コマンドで指定された帯域幅の値がインターフェイス レートをオーバーサブスクライブしていないことを確認します。

ここで、この設定手順を示します。

  1. 子ポリシーのクラスを作成します。 たとえば、トラフィック フローに対してすでに設定されている特定の DSCP または IP プレシデンスの値を照合するとします。

    class-map ef 
      match ip dscp ef 
    class-map af 
      match ip dscp af31
  2. 子ポリシー マップを作成します。 手順 1 で使用したクラスを指定します。これらのクラスに QoS アクションを適用します。 このようなアクションの例として、priority コマンドを使用したプライオリティ キューイングの指定や bandwidth コマンドを使用した最小帯域幅保証の指定が挙げられます。

    policy-map QoS 
      class ef 
        priority percent a% 
      class af 
        bandwidth percent b%
  3. 親ポリシーのクラスを作成します。 access-list コマンドを使用して、特定のトンネルの全トラフィックについて、トンネルの発信元と宛先の IP アドレスを照合して分類する ACL を指定します。 その後で、クラス マップを作成し、match access-group コマンドを使用して、その ACL を参照します。

    class-map class-tunnel1 
      match access-group 101 
    class-map class-tunnel2 
      match access-group 102 
    class-map class-tunnel3 
      match access-group 103
  4. 親ポリシー マップを作成します。 手順 3 で使用したクラスを指定します。shape コマンドを各クラスに適用して、トンネル インターフェイスから送られてくるすべてのトラフィックの出力を制限します。

    policy-map main 
      class class-tunnel1 
        shape average x1 bps 
        service-policy QoS 
      class class-tunnel2 
        shape average x2 bps 
        service-policy QoS 
      class class-tunnel3 
        shape average x3 bps 
        service-policy QoS 
      class class-default 
        shape average x4 bps
  5. service-policy コマンドを利用して親ポリシー マップを物理インターフェイスに適用します。

    interface serial 1/0 
      service-policy out main

注: アプリケーションに IPSec 環境または GRE を使用した IPsec 環境で QoS 事前分類が必要な場合は、暗号マップに対して qos pre-classify コマンドを有効にします。 親クラスの一致基準は、暗号マップで使用しているアクセス グループと同じであることが必要です。 例では、class-tunnel1 の一致基準で、物理インターフェイスまたは GRE トンネル インターフェイスにアタッチされた暗号マップと同じアクセス グループが使用されます。 シスコでは、ソフトウェア ベースの暗号化とハードウェア ベースの暗号化(暗号化アクセラレータとも呼ばれる)の両方をサポートしています。 次の表では、シスコの暗号化ハードウェア アクセラレータと、事前分類のサポートを一覧しています。

プラットフォーム 暗号化ハードウェア QoS 事前分類のサポート
Cisco 1700 シリーズ ハードウェア暗号化によるワイヤ速度の VPN。 Cisco IOS ソフトウェア リリース 12.2T は、暗号化前の低遅延キューイング(LLQ)をサポートします。
Cisco 2600 および 3600 シリーズ Cisco 2600 シリーズ ルータでは、内蔵型アドバンスド インテグレーション モジュール(AIM)スロットを 1 基サポート。 Cisco 3660 では 2 基の AIM スロットをサポート。
  • AIM-VPN/BP(基本パフォーマンス)
  • AIM-VPN/EP(拡張パフォーマンス)
  • AIM-VPN/MP(中間パフォーマンス)
  • AIM-VPN/HP(ハイ パフォーマンス)
Cisco 7200 シリーズ ルータ プレミア加入者宅内機器アプリケーションCisco 2600 および 3600 シリーズ向けモジュラ マルチサービス ルータ仮想プライベート ネットワーク モジュールCisco 2600 および 3600 VPN ルータ バンドル
Cisco IOS ソフトウェア リリース 12.2(2)T 以降で使用可能。
Cisco 7100 および 7200 シリーズ SA-VAM は VPN アクセラレーション モジュール。 Cisco 7200 または 7100 シリーズのポート アダプタ スロットと、Cisco 7100 シリーズのサービス モジュール スロットに実装します。 Cisco IOS ソフトウェア リリース 12.2T は、暗号化機能前の LLQ をサポートします。
Cisco 7100 および 7200 シリーズ SA-ISA(=) および SA-ISM(=) は、それぞれ統合型サービス アダプタおよび統合型サービス モジュール。 Cisco IOS ソフトウェア リリース 12.2、12.2T、12.1E、および 12.0(5)XE で使用可能。

暗号化ハードウェアがある場合、ルータ内のパケットのスイッチング パスを変更すると QoS ポリシーの動作が変化します。 暗号化ハードウェアがあると、CPU は、パケットを発信インターフェイスにキューイングする前に暗号化モジュールにリダイレクトします。 そのため、暗号化ハードウェアをともなう IPSec と GRE の環境では、次の 2 つの潜在的な輻輳ポイントが存在することになります。

  • 暗号キュー:FIFO のみをサポートします。 ハードウェアまたはソフトウェアによる暗号化のいずれかを使用している場合、Voice over IP(VoIP)Real-time Transport Protocol(RTP)ストリームなどの遅延に影響されやすいパケットについては、カプセル化プロセスの単一の FIFO キューで遅延が発生する可能性があります。 このキューにすでに大量のデータ トラフィックがあるときに遅延の影響を受けやすいパケットが到達すると、遅延は増大します。 影響を最小限にとどめるには、適切なスケールのアーキテクチャを備えたシスコ ルータ シリーズを選択して、ハードウェアによるアクセラレーションを使用します。 暗号化エンジンが輻輳していない場合は、FIFO がトラフィック バーストを緩和できないほど小さくなければ、暗号化エンジンに FIFO を使用しても問題ありません。 暗号化エンジンを介して VoIP を実行する場合は、そのエンジンにより生じる遅延を理解しておくことをお勧めします。

  • インターフェイス レベルのキュー:高度なキューイング方式をサポートします。 デフォルトで、トンネル インターフェイスは、帯域幅パラメータが 9 kbps の論理インターフェイスです。 この帯域幅パラメータは、EIGRP や OSPF などの上位レイヤのプロトコルだけで使用されます。 実際には、トンネルを通過するトラフィックに使用可能な出力レートまたはインターフェイス帯域幅は制限されません。 したがって、トンネル インターフェイスにクラスベース シェーピングを実装して、「人工的な」輻輳キューまたはシェーピング キューを構築する必要がある場合があります。 クラス ベースのシェーピングは、出力レートを制限するため、論理トンネル インターフェイス上で輻輳状態が発生します。 トンネル インターフェイスでは、シェーパによって保持されている超過パケットのキューイングを開始し、超過パケットには高度なキューイング ポリシーが適用されます。

ハードウェアによる暗号化エンジンでは、FIFO キューイングだけがサポートされています。 そのため、LLQ を使用するサービス ポリシーを、トンネル トラフィックが転送される出力側の物理インターフェイスに適用する場合は、IPSec プロセスのパフォーマンスが出力インターフェイスより大きくなるようにしてください。 これによって、このインターフェイスのプライオリティ キューイングのメカニズムが動作するようになり、暗号化エンジンが FIFO のボトルネックになることを避けることができます。

Cisco IOS ソフトウェア リリース 12.1 で、パケットがポリシー マップ内の 1 つのクラスと一致することを保証する共通分類が導入されました(詳細については、『操作の Quality of Service 順序』を参照してください)。 VPN 環境におけるこの機能強化の結果の 1 つは、サービス ポリシーでトンネル ヘッダー内の IP プレシデンスまたは DSCP の値に基づく照合が指定されている場合でも、IPSec トンネル内の暗号化されたトラフィック フローの分類が失敗することです。 この問題は、Cisco IOS ソフトウェア リリース 12.2(10) で解決されており、Cisco Bug ID CSCdw90486登録ユーザ専用)と CSCdx08427登録ユーザ専用)に記述されています。 これらのバグが原因で実施された変更を含む Cisco IOS ソフトウェア リリースでは、ハードウェアとソフトウェアの暗号化による分類の動作が一貫しています。

この表では、QoS の事前分類を設定している場合と、設定していない場合について、このバグ修正が行われた後の MQC 機能の動作を説明しています。 事前分類をサポートしていない、または、事前分類が有効になっていないプラットフォームでは、"no preclassify" 列内の MQC の動作が想定されます。 この文書全般に渡って内側と外側のヘッダーの定義に使用されているものと同じ定義が、この表でも使用されています。

事前分類あり 事前分類なし
ハードウェア暗号化アクセラレータと CEF
共通分類 内部 outside
set および police コマンド 内部 outside
キューイング 内部 outside
フローベース WFQ 内部 outside
ハードウェア暗号化アクセラレータとプロセス スイッチング
共通分類 内部 outside
set および police コマンド 内側(1) outside
キューイング 内部 outside
フローベース WFQ 内部 outside
ソフトウェア暗号化と CEF
共通分類 内部 outside
set および police コマンド 内部 outside
キューイング 内部 outside
フローベース WFQ 内部 outside
ソフトウェア暗号化とプロセス交換
共通分類 内部 outside
set および police コマンド 内側(1) outside
キューイング 内部 outside
フローベース WFQ 内部 outside

注: set コマンドと police コマンドは事前分類されたクラスに対して機能しますが、パケットのマーキングが外側ヘッダーでしか行われません。

設定例

この設定例では、IPSec と GRE の環境に対して QoS サービス ポリシーを作成するコマンドを説明しています。

  • GRE トンネルが IPsec ピアを接続し、トンネルを通過したパケットが IPsec を利用して暗号化されます。

  • IP プレシデンスを設定するためにクラス ベースのマーキングを適用する入力ポリシーを作成します。

  • クラス ベースのシェーピングを使用してすべての暗号化されたトンネルを最大帯域幅に制限し、クラスベース均等化キューイング(CBWFQ)を介して最小帯域幅保証も適用する出力ポリシーを作成します。

入力ポリシー

クラス ベースのマーキングを適用する入力ポリシーを作成するには、次の手順を実行します。

  1. ip cef コマンドで CEF をイネーブルにします。 CEF はクラス ベースのマーキングに不可欠です。 詳細については、『CEF はいつ Quality of Service に必要になるか』 参照してください。

  2. トラフィックをクラスに分類する基準を定義します。 この設定では、Telnet トラフィックに対して「flow-hi」クラスを、ICMP トラフィックに対して「flow-low」クラスを定義しています。

  3. ポリシー マップを定義して、定義されたクラスに対する QoS アクションを定義します。

  4. ポリシーをインターフェイスに適用します。 この場合は、シリアル サブインターフェイスに適用します。

この表では、クラスベース マーキングを行う入力ポリシーの設定を示しています。

クラス ベース マーキング入力ポリシー
ip cef 

! 
class-map match-any flow-low 
 match protocol icmp  
! 
class-map match-any flow-hi 
  match protocol telnet 

! 
policy-map qos-in 
 class flow-hi  
  set ip precedence 4 
! 
class flow-low 
  set ip precedence 2 
! 
int s0/0.1 
 service-policy input qos-in 

  
router#show policy-map interface s0/0.1 

Serial0/0.1  

Service-policy input: qos-in) 

!--- Apply input policy named "qos-in."
 

     Class-map: flow-hi (match-any) 
      447 packets, 227851 bytes 
      30 second offered rate 5000 bps, drop rate 0 bps  

!--- Input rate for class named "flow-hi."
 

      Match: protocol telnet 
        447 packets, 227851 bytes 
        30 second rate 5000 bps 

!--- Input rate for class named "flow-hi."
 
      QoS Set 
        ip precedence 4 
          Packets marked 447  

!--- Number of packets marked.
  

   Class-map: flow-low (match-any 
      237 packets, 337898 bytes 
      30 second offered rate 21000 bps, drop rate 0 bps 
      Match: protocol icmp 
        237 packets, 337898 bytes 
        30 second rate 21000 bps 
      QoS Set 
        ip precedence 2 
          Packets marked 237  

    Class-map: class-default (match-any) 

!--- The default class is automatically defined.
 
      1 packets, 48 bytes 
      30 second offered rate 0 bps, drop rate 0 bps 
      Match: any

出力ポリシー

この設定では、ネスト型ポリシーとも呼ばれる階層型の出力ポリシーを作成します(詳細については、『QOS ポリシーとしてのトラフィック ポリシー(階層化トラフィック ポリシー)の例』を参照してください)。 「親」ポリシーでクラスベース シェーピングを行って、トンネル インターフェイスの全体の出力レートを制限します。また、「子」ポリシーで、キューイングされた超過分に対して CBWFQ を使用して、最小帯域幅の保証を行います。

この設定の手順は次のとおりです。

  1. 子ポリシーを作成します。

    • この設定では、再マークされた Telnet トラフィックに対して「ipsec-hi」クラスを、再マークされた ICMP トラフィックに対して「ipsec-low」クラスを定義しています。

    • この設定では、ポリシー マップ "ipsec-flow" を使用して、bandwidth コマンドで Telnet トラフィックと ICMP トラフィックに CBWFQ を適用します。

  2. 親ポリシーを作成します。 この設定では、「ipsec」クラスを定義して、これで照合するトラフィックを 16 kbps にシェーピングしています。

  3. 親ポリシー内に子ポリシーを適用します。 この設定では、親ポリシー「qos-out」の中に、子ポリシー「ipsec-flow」を QoS アクションとして適用しています。 この QoS アクションは、シェーパによって保持およびキューイングされていたパケットに対する CBWFQ です。

  4. 親ポリシーをインターフェイスに適用します。 この場合は、シリアル サブインターフェイスに適用します。

この表では、再マークした値に基づいて、シェーピングを行い、CBWFQ を適用する出力ポリシーの設定を示しています。

シェーピングと CBWFQ を実行する出力ポリシー
class-map match-all ipsec-hi 
  match ip precedence 4  
class-map match-all ipsec-low 
  match ip precedence 2  
! 
policy-map ipsec-flow  
  class ipsec-hi 
   bandwidth 8  
  class ipsec-low 
   bandwidth 8 
! 
class-map match-all ipsec  
 match protocol gre 
!  
policy-map qos-out 
 class ipsec 
  shape average 16000 
   service-policy ipsec-flow 
! 
int fa0/0 
 service-policy output qos-out

!--- Apply the policy to the physical interface through
 

!--- which the tunnel traffic is transmitted.
 
router#show policy-map interface fast 0/0 
 FastEthernet0/0  

  Service-policy output: qos-out  

!--- "Parent" policy named "qos-out."
 

    Class-map: ipsec (match-all)  
      1422 packets, 1390125 bytes 
      30 second offered rate 38000 bps, drop rate 0 bps  

!--- Egress rate before shaping.


      Match: protocol gre  
      Traffic Shaping 

      Target  Byte   Sustain   Excess    Interval  Increment Adapt 
      Rate    Limit  bits/int  bits/int  (ms)      (bytes)   Active 
      16000   2000   8000      8000      500       1000      - 
  

      Queue  Packets   Bytes   Packets  Bytes     Shaping 
      Depth                     Delayed  Delayed   Active 
        69     641      611106  582      535364    yes  

  Service-policy : ipsec-flow  

!--- "Child" policy named "ipsec-flow." 


        Class-map: ipsec-hi (match-all)  
          788 packets, 464485 bytes 
          30 second offered rate 15000 bps, drop rate 0 bps 
          Match: ip precedence 4  
          Weighted Fair Queueing 
            Output Queue: Conversation 25  
            Bandwidth 8 (kbps) Max Threshold 64 (packets) 
            (pkts matched/bytes matched) 389/241922 
            (depth/total drops/no-buffer drops) 4/0/0 

        Class-map: ipsec-low (match-all)  
          634 packets, 925640 bytes 
          30 second offered rate 25000 bps, drop rate 0 bps 
          Match: ip precedence 2  
          Weighted Fair Queueing 
            Output Queue: Conversation 26  
            Bandwidth 8 (kbps) Max Threshold 64 (packets) 
            (pkts matched/bytes matched) 270/400140 
            (depth/total drops/no-buffer drops) 64/2/0 

        Class-map: class-default (match-any)  
          0 packets, 0 bytes 
          30 second offered rate 0 bps, drop rate 0 bps 
          Match: any  

       Class-map: class-default (match-any)  
         115 packets, 14827 bytes 
         30 second offered rate 0 bps, drop rate 0 bps 
         Match: any

注:  親ポリシーで、match protocol gre コマンドを使用して、IP ヘッダーの GRE に割り当てられたプロトコル値との照合を指定します。 Cisco IOS 機能の実行順序に基づいて、ACL と QoS 機能に暗号化されていないパケットが表示されます。 したがって、AH または ESP のプロトコル値(それぞれ 51 および 50)に一致する ACL の設定が、動作しません(Cisco Bug ID CSCdu63385登録ユーザ専用)および(CSCdv20737(登録ユーザ専用))。 この制限は、ハードウェアの暗号化とソフトウェアの暗号化の両方に該当します。 まれに、QoS 機能が、CEF スイッチング用に設定されたルータ上で暗号化されたパケットの修正された IP ヘッダーに基づいてパケットを分類する場合があります。 暗号化コードと CEF が誤って有効な CEF の隣接関係を特定できなかった際に、実際には CEF パケットがプロセス交換されていたのがこの理由です。

注: クラス マップ内で match protocol コマンドを使用して IPX や AppleTalk などの非 IP プロトコルを照合し、qos pre-classify も有効にして内側ヘッダー内の値を照合する場合は、内側ヘッダーに基づく分類が機能しません。

制限および関連問題

このセクションでは、同一のルータ上での暗号化と QoS の実行に関連する既知の問題と、回避策について説明します。

QoS および再生防止保護

一部の暗号変換セットにはリプレイ攻撃に対する防御機能が備わっており、暗号化ヘッダーにシーケンス番号を適用している場合に機能します。 高度なキューイングを行っていて輻輳しているインターフェイスでは、優先順位の低いパケットはキュー内で遅延する場合があり、リプレイ攻撃対策の枠が超過した後で、復号化を行うルータに到達することになります。 この場合は、受信したデバイスがパケットをドロップします。 加えて、暗号化されたパケットが特定のウィンドウ(現在 64 パケットに設定)によるシーケンス以外の宛先に到着した場合は、そのパケットがドロップされます。 シスコでは、現在、これらの制限に対処する方法を調査中です。 アンチリプレイ保護が実装された次のトランスフォームからこの機能を無効にできないことに注意してください。

  • esp-sha-hmac

  • esp-md5-hmac

  • ah-md5-hmac

  • ah-sha-hmac

アンチリプレイ サポートが各 IPSec SA に対して有効になっているかどうかを判断するには、show crypto ipsec sa コマンドを使用します。

2611-ch5#show crypto ipsec sa
interface: Tunnel0
Crypto map tag: Test, local addr. 12.2.2.6
inbound esp sas:
spi: 0xDE92271(233382513)
transform: esp-des esp-sha-hmac ,
in use settings ={Transport, }
slot: 0, conn id: 2000, flow_id: 1, crypto map: Test
sa timing: remaining key lifetime (k/sec): (4607996/99)
IV size: 8 bytes 
replay detection support: Y

NBAR

NBAR は、トンネリングまたは暗号化が使用されている論理インターフェイスでは設定できません。 また、暗号マップを使って設定された物理インターフェイスでもサポートされません。 したがって、GRE または IPSec、あるいはその両方が使用されている場合の QoS ポリシーでは、URL や Web サーバのホスト名などの高レイヤのパケット情報に基づくトラフィックの分類に、NBAR は使用できません。 この制限事項の原因となっているのは、事前分類機能によって保存と参照がされるパケット ヘッダーのバイト数です。 具体的には、QoS の事前分類では、パケットをカプセル化する前に、IOS の API を呼び出します。 この API では、元のパケットのヘッダー情報のコピーが使用されます。 パケットが出力側の QoS 機能にヒットすると、TCP ポートや実際の宛先の IP アドレスなどの保存されている情報に基づいて、このパケットに QoS が適用されます。

二重アカウンティング

show policy-map interface コマンドの出力にある分類カウンタには、CEF、GRE、および IPSec の設定で暗号化されたトンネルを通過する既知のパケットについて、倍の数が表示されることがあります。 次の出力は、この状況を示しています。

router#show policy-map interface fa0/0 
  FastEthernet0/0 

   Service-policy output: qos-out 

     Class-map: ipsec (match-all) 
       44 packets, 8580 bytes 
       30 second offered rate 1000 bps, drop rate 0 bps 
       Match: protocol gre 
       Traffic Shaping 
         Target    Byte   Sustain   Excess    Interval  Increment Adapt 
         Rate      Limit  bits/int  bits/int  (ms)      (bytes)   Active 
         16000     2000   8000      8000      500       1000      - 

         Queue     Packets   Bytes     Packets   Bytes     Shaping 
         Depth                         Delayed   Delayed   Active 
         0         22        4796      0         0         no 

CEF スイッチング パスで発生した出力パケットの分類が、暗号化プロセスでパケットがキューイングを解除されときに再度行われることが、この原因です。 この問題は、次の Cisco Bug ID で解決されています。

加えて、GRE トンネルと IPSec の両方が設定されている場合は、パケットが CEF 検索プロセスを 2 回通過します。1 回目は GRE カプセル化の後、2 回目は IPSec カプセル化の後です。 パケットが伝送されるのは IPSec カプセル化の後だけなので、CEF によるパケットごとのロード バランシングは失敗し、パケットは常に同じインターフェイスを使用します。

ソフトウェア暗号化およびファーストスイッチング/CEF

ソフトウェアによる暗号化、QoS の事前分類機能、および CBWFQ を使用する場合、ファースト スイッチングされたパケットは、正しく分類されないことがあります。 この問題は、show policy-map interface コマンドの出力で確認することができます。

3640-ch1#show policy-map interface 
 {snip} 
      Class-map: precedence (match-all) 
        5 packets, 520 bytes 
        
!--- Five packets matched the class.
 
        30 second offered rate 0 bps, drop rate 25000 bps 
        Match: ip precedence 5 
        Weighted Fair Queueing 
          Output Queue: Conversation 26 
          Bandwidth 10 (%) 
          Bandwidth 1 (kbps) Max Threshold 64 (packets) 
          (pkts matched/bytes matched) 11756/14350192 
          
!--- Many packets actually are  queued.
 
          (depth/total drops/no-buffer drops) 63/6359/0 

回避策として、ハードウェア暗号化モジュールを使用して、no ip route-cache cef コマンドでプロセス スイッチングを強制するか、QoS 事前分類を無効にします。 この結果、class-default クラスで、均等化キューイング システムが暗号化された単一のフローを扱うようになります。

この問題は、Cisco Bug ID CSCdw28771登録ユーザ専用)で解決されています。

レガシープライオリティキューイングおよびQoS PreClassify

priority-list コマンドと priority-group コマンドを使用するシスコの従来のプライオリティ キューイング機能と QoS 事前分類機能はともにサポートされません。 代わりに、MQC の priority コマンドを使用してポリシー マップを設定することによって LLQ を実装します。

ハードウェア暗号化およびQoS

ハードウェアによる暗号化と QoS で解決済の問題があります。

  • Cisco Bug ID CSCdv25358登録ユーザ専用):rate-limit コマンドを使用してシスコの従来の専用アクセス レート(CAR)機能経由でトラフィック ポリシングを実行するときに、ハードウェア暗号化も使用されていると、qos pre-classify コマンドが機能しません。 この機能の組み合わせでは、暗号化が実行されません。 回避策として、モジュラ QoS コマンドライン インターフェイス(CLI)(MQC)を使って設定されたポリシー マップ内で police コマンドを利用してクラス ベースのポリシングを実装します。 他の QoS 機能(MQC または非 MQC)は影響を受けません。

  • Cisco Bug ID CSCdw29595登録ユーザ専用):ハードウェア暗号化カードと一緒に Cisco IOS ソフトウェア リリース 12.2(6.8) が使用されている場合は、暗号化パスのパフォーマンスが低下します。 このパフォーマンスのロスは、暗号化されたパケットが、ファースト スイッチングではなく、プロセス交換されるためです。 この状況は、IPSec がインターフェイスに適用され、同時にハードウェア暗号化カードが使用されている場合に発生します。 回避策はありません。

  • Cisco Bug ID CSCdw30566登録ユーザ専用):GRE を使用した IPsec 環境で、CEF を有効にすると、パケットが実際にプロセス スイッチングされるため、転送パフォーマンスが低下します。 パケットが GRE カプセル化処理を受けた後に行われる、CEF のパケットの処理方法が、この状態の原因です。 回避策として、CEF を無効にして、パケットがファースト スイッチングされるようにします。

暗号化アクセラレータを使用している場合には、この文書の「パケットの分類」のセクションと、Cisco Bug ID CSCdw90486登録ユーザ専用)と CSCdx08427登録ユーザ専用)で行われた変更の説明を参照してください。

関連するシスコ サポート コミュニティ ディスカッション

シスコ サポート コミュニティは、どなたでも投稿や回答ができる情報交換スペースです。


関連情報


Document ID: 18667