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

暗号化と QoS の実装に関するリファレンス ガイド

2005 年 8 月 10 日 - ライター翻訳版
その他のバージョン: PDFpdf | 機械翻訳版 (2013 年 8 月 21 日) | 英語版 (2006 年 5 月 24 日) | フィードバック

目次

概要
前提条件
      要件
      使用するコンポーネント
      表記法
IPSec プロトコル
AH と ESP
IPSec による GRE トンネルの使用
パケットの分類
設定例
      入力ポリシー
      出力ポリシー
制約事項と関連問題
      QoS とリプレイ攻撃に対する防御
      NBAR
      二重アカウント
      ソフトウェアの暗号化とファースト スイッチング/CEF
      従来のプライオリティ キューイングと QoS の事前分類
      ハードウェアによる暗号化と QoS
関連するシスコ サポート コミュニティ ディスカッション
関連情報

概要

VPN の利用が増大し、データ、音声、ビデオのトラフィックに使用されるようになるに従って、異なるタイプのトラフィックをネットワーク上でそれぞれの方法で処理することが必要となってきました。 Quality of service(QoS)と帯域幅を管理する機能によって、VPN では、音声やビデオなどの時間依存型アプリケーション向けの高度な伝送品質を提供できるようになりました。 各パケットは、プライオリティとそのペイロードの時間依存性を識別するために、タグ付けされています。またトラフィックは、その配送のプライオリティに基づいて分類およびルーティングされます。 シスコの VPN ソリューションでは幅広い QoS 機能がサポートされています。

この文書は、同じネットワークやルータ群に対して Cisco IOS(R) の暗号化と 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 
         
 !--- 事前共有キーまたは RSA などの 
 
 		
 !--- パブリック/プライベート キーのメカニズムをサポート。
  
         Diffie-Hellman group:   #1 (768 bit) 
         lifetime:               86400 seconds, no volume limit 
         
 !--- ライフタイムは時間または伝送バイト数に依存。
  
 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 は Security Parameter Index(SPI; セキュリティ パラメータ インデックス)で識別されます。 たとえば、SPI が 0x21A85375 (564679541) の接続では、AH について MD5-HMAC アルゴリズムを、ESP については DES を使用しています。

P5R0#show crypto ipsec sa address 
 dest address: 10.1.1.1 
 
 !--- IPSec ピアのアドレス。
  
    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 では MD5-HMAC アルゴリズムを使用。
  
         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 では DES を使用。
  
         in use settings ={Transport, } 
         
 !--- このフローに対してトランスポート モードを使用。
  
         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 には、IP データグラムに対して、SHA や MD5 のハッシュ アルゴリズムによる強固な整合性機能と認証機能が備わっています。 また、否認防止機能も備わっています。 AH は最小 12 バイトで、次に図示してあります。 Internet Assigned Numbers Authority(IANA)では、AH にプロトコル番号 51 を割り当てています。 したがって、トンネル モードとトランスポート モードのどちらでも AH ヘッダーを使用する場合には、IP ヘッダーのプロトコル フィールドには 51 という値が使用されます。

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

crypto_qos_01.gif

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

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

crypto_qos_02.gif

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

IPSec では、Internetwork Packet Exchange(IPX)や 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 段階目のカプセル化ができます。 GRE トンネルだけを使用して、IPSec を使用しない場合は、『GRE トンネル インターフェイスでの QoS オプションの品質』を参照してください。 この図では、IPSec、GRE でカプセル化されたパケットと、元の IP ヘッダーを表しています。

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 Firewall バージョン 5.1 以降、および VPN 3000 シリーズ コンセントレータ バージョン 3.5 以降では、ToS バイトのコピーがサポートされています。 RFC 2401 leavingcisco.com のセクション 5.1.2、『Header Construction for Tunnel Mode』では、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

ここでは示されていませんが、Weighted Random Early Detection(WRED; 重み付けランダム早期検出)を、テール ドロップに代わる廃棄方式として各クラスに適用することもできます。

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

あるいは、トラフィックを IP 優先順位や DSCP 以外の値に基づいて分類する必要がある場合があります。 たとえば、パケットを、発信元 IP アドレスや宛先 IP アドレスのような IP フローまたはレイヤ 3 の情報に基づいて分類する必要がある場合があります。 これを実行するには、VPN 向けの QoS 機能を使用する必要があります。 この機能を有効にするには、qos pre-classify コマンドを使用します。また、この機能は、Cisco 7100 シリーズ VPN ルータと Cisco 7200 シリーズ ルータ(Cisco IOS ソフトウェア リリース 12.1(5)T 以降)、および 2600 シリーズ ルータと 3600 シリーズ ルータ(Cisco IOS ソフトウェア リリース 12.2(2)T 以降)で使用できます。『バーチャル プライベート ネットワーク向けの 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; 先入れ先出し)が使用されていることを示しています。 このことは、上記の show コマンドの出力の Queueing strategy: fifo (QOS pre-classification) の行で分かります。 GRE トンネルと IPSec トンネルでは、正しい順序で到着しなかった 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 または IPSec と GRE の環境で 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 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 クラスに確実に一致するようになりました(詳細については、『QoS 動作順位』を参照してください)。 VPN 環境では、この拡張により、サービス ポリシーでトンネル ヘッダーの IP 優先順位や DSCP 値との一致が指定されている場合でも、IPSec トンネル内で暗号化トラフィック フローの分類に失敗するようになりました。 この問題は、Cisco IOS ソフトウェア リリース 12.2(10) で解決されており、Cisco Bug ID CSCdw90486登録ユーザ専用)と CSCdx08427登録ユーザ専用)に記述されています。 このバグに対応するための修正が行われた Cisco IOS ソフトウェア リリースでは、ハードウェアおよびソフトウェアによる暗号化の分類処理は矛盾しないものとなっています。


一部ツールについては、ゲスト登録のお客様にはアクセスできない場合がありますことを、ご了承ください。

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

事前分類あり

事前分類なし

ハードウェア暗号化アクセラレータと CEF

共通分類

内側

外側

set および police コマンド

内側

外側

キューイング

内側

外側

フローベース WFQ

内側

外側

ハードウェア暗号化アクセラレータとプロセス交換

共通分類

内側

外側

set および police コマンド

内側(1)

外側

キューイング

内側

外側

フローベース WFQ

内側

外側

ソフトウェア暗号化と CEF

共通分類

内側

外側

set および police コマンド

内側

外側

キューイング

内側

外側

フローベース WFQ

内側

外側

ソフトウェア暗号化とプロセス交換

共通分類

内側

外側

set および police コマンド

内側(1)

外側

キューイング

内側

外側

フローベース WFQ

内側

外側

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

設定例

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

  • GRE トンネルによって IPSec ピアを接続し、トンネルを通過するパケットは IPSec によって暗号化されます。

  • クラスベース マーキングを適用する入力ポリシーを作成し、IP 優先順位を設定します。

  • クラスベース シェーピングを使用して、それぞれの暗号化されたトンネルに対して最大帯域幅以下に制限する出力ポリシーを作成します。また、Class-Based Weighted Fair Queuing(CBWFQ; クラスベースの重み付け均等化キューイング)を使用して、最小帯域幅を保証します。

入力ポリシー

以下の手順を実行して、クラスベース マーキングを実行する入力ポリシーを作成します。

  1. ip cef コマンドを使って、CEF をイネーブルにします。 CEF は、クラスベース マーキングに必要です。 詳細については、『QOS で CEF が必要とされる場合』を参照してください。

  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) 
 
 !--- 「qos-in」という名前の入力ポリシーを適用します。
  
      Class-map: flow-hi (match-any) 
       447 packets, 227851 bytes 
       30 second offered rate 5000 bps, drop rate 0 bps  
 
 !--- 「flow-hi」クラスの入力レート。
  
       Match: protocol telnet 
         447 packets, 227851 bytes 
         30 second rate 5000 bps 
 
 !--- 「flow-hi」クラスの入力レート。
  
       QoS Set 
         ip precedence 4 
           Packets marked 447  
 
 !--- マーキングされたパケットの数。
   
    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) 
 
 !--- デフォルトのクラスは自動的に定義されます。
  
       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
 
 !--- トンネル トラフィックが発信される物理インターフェイスに
  
 
 !--- ポリシーを適用します。
  
 router#show policy-map interface fast 0/0 
  FastEthernet0/0  
   Service-policy output: qos-out  
 
 !--- 「qos-out」という名前の「親」ポリシーを適用します。
  
     Class-map: ipsec (match-all)  
       1422 packets, 1390125 bytes 
       30 second offered rate 38000 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 
         69     641      611106  582      535364    yes  
   Service-policy : ipsec-flow  
 
 !--- 「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(登録ユーザ専用))。 この制限は、ハードウェアの暗号化とソフトウェアの暗号化の両方に該当します。 まれなケースでは、CEF スイッチング用に設定されたルータでは、QoS 機能により、暗号化されたパケットの変更された 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 で解決されています。

  • CSCdu17976登録ユーザ専用) - パケットを分類済とマークするフラグを追加することで、この問題を解決。

  • CSCdv79109登録ユーザ専用) - CEF スイッチングおよび Cisco IOS ソフトウェア リリース 12.2 メインライン。

  • CSCdt62225登録ユーザ専用) - ファースト スイッチングおよび Cisco IOS ソフトウェア リリース 12.2 メインライン。

さらに、GRE トンネルと IPSec の両方が設定されている場合には、パケットが CEF ルックアップの処理を 2 回受けます。1 回目は GRE カプセル化の後で、もう 1 回は 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 
         
 !--- 5 つのパケットがクラスに一致しました。
  
         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 
           
 !--- 実際には多数のパケットがキューイングされています。
  
           (depth/total drops/no-buffer drops) 63/6359/0 

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

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


一部ツールについては、ゲスト登録のお客様にはアクセスできない場合がありますことを、ご了承ください。

従来のプライオリティ キューイングと QoS の事前分類

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

ハードウェアによる暗号化と QoS

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

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

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

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

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


一部ツールについては、ゲスト登録のお客様にはアクセスできない場合がありますことを、ご了承ください。


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

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


関連情報


Document ID: 18667