crypto_qos.pdf

(1)

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

概要前提条件要件使用するコンポーネント表記法 IPSecプロトコル AHおよびESP IPSec による GRE トンネルの使用パケットを分類して下さい設定例入力ポリシー出力ポリシー制限および関連問題 QoS および再生防止保護 NBAR 二重アカウンティングソフトウェア暗号化およびファーストスイッチング/CEF レガシープライオリティキューイングおよびQoS PreClassify ハードウェア暗号化およびQoS 関連情報

概要

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

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

前提条件

要件

この文書をお読みになる前に以下の情報を通読し、理解して下さい。 IPSec技術 IPSecのより多くの包括的なドキュメントに関しては、IPセキュリティ(IPSec)暗号化入門を参照して下さい。

使用するコンポーネント

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

表記法

文書の表記法の詳細は、「シスコテクニカルティップスの表記法」を参照してください。

(2)

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 つの暗号化ピア間で、次の表のパラメータがネゴシエートされます。

パラメータ Options

IPSecプロトコルセット

Authentication Header (AH) Encapsulating Security Payload (ESP) ほとんどのアプリケーションに関しては、 AHかESPは十分です。 Mode トンネルモード：元の IP ヘッダーを保持および暗号化した上で、カプセル化 IP ヘッダーが新しく追加されます。トランスポートモード：元の IP ヘッダーが保持されますが、プロトコルフィールドが AH または ESP を表すようにそれぞれ値 51 または 50 に変更されます。ネゴシエーションフェーズでは、トランスポートモードにする場合、ISAKMP により自動的にトンネルモードに「フォールバック」されますが、確立はできません。「Note: RFC 2401は用語「外側」か元の IPヘッダーを記述するためにトンネルモードおよび「内部」ヘッダとの新しいIPヘッダーを記述するようにヘッダを「カプセル化すること」を使用します。 RFC からの引用は次のとおりです。「外側の IP ヘッダーの送信元アドレスおよび宛先アドレスによって、トンネルの「エンドポイント」（カプセル化側と非カプセル化側）が識別されます。内側の IP ヘッダーの発

(3)

信元アドレスと宛先アドレスにより、データグラムの元々の発信元と宛先（トンネルの観点から）をそれぞれ識別する。」とあります。以降では、これらの用語を使用します。変換セット認証だけのためのAH。_{認証および暗号化のためのESP。}

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

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は独自にまたは併用することができます。ただし、なぜならほとんどのアプリケーション1 だけ十分です。両方のプロトコルに関しては、IPSecは使用するために特定のセキュリティアルゴリズムを定義しません。その代り、それは業界標準アルゴリズムを設定するために開かれたフレームワークを提供します。

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

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

(4)

ESPは暗号化されたデータおよび暗号化されたトレーラに先行している非暗号化ヘッダーで構成されています。 ESPは暗号化および認証を両方提供します。 AHと同様に、ESPは認証のためのSHAおよびMD5ハッシュ・アルゴリズムをサポートします。それは暗号化プロトコルとしてDESおよびトリプルDESをサポートします。 ESP ヘッダーは最小 8 バイトで、次に図示してあります。 IANA では、ESP にプロトコル番号 50 を割り当てています。したがって、トンネルモードおよびトランスポートモードのどちらでも、ESP ヘッダーだけを使用する場合には、IP ヘッダーそのプロトコルフィールドには 50 という値が使用されます。この図では、IPSec ESP ヘッダーとトレーラが付いたパケットの形式が表されています。トンネルモードでは、元の IP ヘッダーからトンネルヘッダーへ、TOS バイトの値が自動的にコピーされます。詳細については、この文書の「パケットの分類」のセクションを参照してください。

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 段階目のカプセル化ができます。 GREトンネルおよびIPSecだけ使用しない場合、GREトンネル・インターフェイスのQuality of Serviceオプションを参照して下さい。この図では、IPSec、GRE でカプセル化されたパケットと、元の IP ヘッダーを表しています。

(5)

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

IPSec と GRE をあわせて設定する場合、最も簡単な分類方法は、IP 優先順位または Differentiated Services Code

Point（DSCP; DiffServ コードポイント）の値を照合することです。 IPSecのためのおよびそれと共にCisco IOSソフトウェアリリース11.3Tによって導入されるサポートTOSバイト保存機能。この機能を使用すると、トンネルモードの IPSec が使用されている場合、ルータによって、元の IP パケットからカプセル化された IP ヘッダーに ToS ヘッダーの値が自動的にコピーされます。

Cisco PIX Firewallバージョン5.1およびそれ以降およびVPN 3000シリーズコンセントレータバージョン3.5およびそれ以降はTOS バイトコピーをサポートします。セクション5.1.2、「トンネルモードのためのヘッダ構築」、RFC 2401で IP TOSビットをコピーすることの統治を委任します。

ToS バイトの維持は、AH にも該当します。転送するモードのESPが元のIPヘッダーを保つ、オリジナルTOS値はTOSバイト保存なしで送信されますまたことに注目すれば。パケットがset ip precedenceかDSCP値なしでルータで着く場合、暗号化かカプセル化の前にパケットヘッダーをマークし直すためにクラスに基づいてマークできます。パケットが出力インターフェイスに到達すると、QoS 出力ポリシーにより、再マークされた値に基づいて照合と処理が行えます。 IP 優先順位に基づいて QoS ポリシーを設定する際には、次の 2 つのポリシーが適用されます。ポリシーのタイプポリシーのアクションポリシーの位置

Input 元のIPヘッダーのIPprecedenceをマークして下さ

い。入力インターフェイス出力 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

(6)

示されていなくてが、またテール・ドロップに代替ドロップ・メカニズムとして各クラスに重み付けランダム早期検出(WRED)を適用できます。

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

また、IP precedenceかDSCP以外値に基づいてトラフィックを分類したいと思う場合もあります。たとえば、送信元および宛先IP アドレスのようなIPフローかレイヤ3情報に、基づいてパケットを分類したいと思う場合もあります。これを実行するには、VPN 向けの QoS 機能を使用する必要があります。この機能は qos pre-classify コマンドで使用可能になり、Cisco 7100 シリーズ VPN ルータと Cisco 7200 シリーズルータでは Cisco IOS ソフトウェアリリース 12.1(5)T 以降で、さらに Cisco 2600 と Cisco 3600 シリーズルータでは Cisco IOS ソフトウェアリリース 12.2(2)T 以降で使用できます。『バーチャルプライベートネットワーク向けの QOS の設定』を参照してください。 qos pre-classify のメカニズムによって、シスコルータが、内側の IP ヘッダーのフィールドに基づいた暗号化を行う前に、内側の IP ヘッダーのコピーを作成し、QoS の分類を実行できるようになります。この機能がない場合、同じトンネルを通過するパケットは、すべて同一のトンネルヘッダーを持ち、輻輳の発生時には同じ扱いを受けます。このため分類エンジンでは、単一の方式で暗号化されてトンネル処理されたフローしか扱わないことになります。分類のポリシーがTOSバイトと一致する場合、TOS値が外ヘッダにデフォルトでコピーされるのでqos pre-classifyコマンドを使用する必要はありません。 IP 優先順位に基づいてトラフィックをクラスに分類するという、簡単な QoS ポリシーを作ることができます。ただし、クラス内のトラフィックを分類し、複数のフローベースのキューにそれを分けるために、qos pre-classifyコマンドが必要となります。

「Note: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事前分類を設定するためにこれらのステップを完了して下さい。

クリプトマップを設定し、マップ設定モードのqos pre-classifyコマンドを規定して下さい。 1.

(7)

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

show crypto map コマンドを使用して、設定を確認します。 2.

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 GREトンネル・インターフェイスを定義し、クリプトマップおよびqos pre-classifyコマンドを適用して下さい。 3. 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

show interface tunnel 0 コマンドを使用して、QoS 事前分類が有効になっていることを確認します。 4.

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コマンド出力で説明されます: fifo (QOS事前分類)。デスティネーションデバイスが順番が異なる着くIPsecパケットを廃棄するのでGREおよびIPSecトンネルは両方FIFOキューイングを必要とします。 VPN環境では、トンネルインターフェイスまたは根本的な物理インターフェイスにQoSサービスポリシーを適用できます。 qos pre-classify コマンドの設定が必要かどうかは、分類でどのヘッダー、およびどのヘッダー値を使用するかによって決まります。内部ヘッダーに基づいてパケットを分類したいと思う場合qos pre-classifyコマンドなしでトンネルインターフェイスにポリシーを適用して下さい。外ヘッダに基づいてパケットを分類したいと思う場合qos pre-classifyコマンドなしで物理インターフェイスにポリシーを適用して下さい。物理インターフェイスが輻輳ポイントであるかもしれないので内部ヘッダーに基づいてパケットを分類し、物理インターフェイスにポリシーを適用したいと思ったらポリシーを物理インターフェイスに適用し、qos pre-classifyコマンドを有効にして下さい。 2002年5月現在で、CiscoはVPN環境の物理インターフェイスに階層型ポリシーのアプリケーションを推奨します。『QOS ポリシーとしてのトラフィックポリシー（階層化トラフィックポリシー）の例』を参照してください。この設定では、親ポリシーはすべてのトラフィックで分類するか、または一致するためにそのトンネルに属し、トンネルの出力を制限するshapeコマンドを使用するトンネル毎に1つのクラスが含まれています。トンネルの中のフローの分類は子ポリシーの助けによって適用し、qos pre-classifyコマンドで内部IPヘッダーまたは外IPヘッダーにqos pre-classifyコマンドなしで基づいていることができます。トンネルのための親ポリシーのそれぞれのshapeコマンドの指定された帯域幅の値がインターフェイス比率をオーバーサブスクライブしないようにして下さい。ステップはこの設定にここにあります。子ポリシーのクラスを作成して下さい。たとえばそれらの値がトラフィックフローで既に設定されている場合、特定のDSCP またはIP precedence値で一致する選択して下さい。 1.

(8)

class-map ef match ip dscp ef class-map af match ip dscp af31 子ポリシーマップを作成して下さい。手順 1 で使用したクラスを指定します。これらのクラスに QoS アクションを適用します。そのようなアクションの例はpriorityコマンドでプライオリティキューイングの仕様かbandwidthコマンドで最小帯域幅保証の仕様が含まれています。 2. policy-map QoS class ef priority percent a% class af bandwidth percent b% 親ポリシーのクラスを作成して下さい。 access-list コマンドを使用して、特定のトンネルの全トラフィックについて、トンネルの発信元と宛先の IP アドレスを照合して分類する ACL を指定します。その後、クラスマップを作成し、match access-group コマンドを使用して、その ACL を参照します。 3. class-map class-tunnel1 match access-group 101 class-map class-tunnel2 match access-group 102 class-map class-tunnel3 match access-group 103 親ポリシーマップを作成して下さい。手順 3 で使用したクラスを指定します。shape コマンドを各クラスに適用して、トンネルインターフェイスから来るすべてのトラフィックの出力を制限します。 4. 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 service-policyコマンドの助けによって物理インターフェイスに親ポリシーマップを適用して下さい。 5. interface serial 1/0 service-policy out main

「Note:アプリケーションがGRE環境のIPSecまたはIPSecのQoS事前分類を必要とする場合、クリプトマップのqos pre-classifyコマンドを有効にして下さい。親クラスの一致基準は、暗号マップで使用しているアクセスグループと同じであることが必要です。例では、class-tunnel1のためのマッチ基準は物理インターフェイスかGREトンネル・インターフェイスに接続するクリプトマップと同じアクセスグループを使用します。 Ciscoはソフトウェアベースの暗号化およびハードウェアベースの暗号化、別名暗号化アクセラレータ両方サポートします。次の表では、シスコの暗号化ハードウェアアクセラレータと、事前分類のサポートを一覧しています。プラットフォーム暗号化ハードウェア 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/High Performance (HP) Cisco 7200シリーズルータCisco 2600およ、Cisco IOSソフトウェアリリース12.2(2)T 現在で利用可能。

(9)

び3600シリーズCisco 2600および3600 VPN ルータBundlesのための首位顧客宅内機器アプリケーションモジュラマルチサービスルータ仮想プライベートネットワークモジュール 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キロビット/秒の帯域幅パラメータの論理インターフェイスです。この帯域幅パラメータは、EIGRP や OSPF などの上位レイヤのプロトコルだけで使用されます。それは実際に使用トンネルトラフィックができるインターフェイス帯域幅か出力レートを制限しません。したがって、トンネルインターフェイスにクラスベースシェーピングを実装して、「人工的な」輻輳キューまたはシェーピングキューを構築する必要がある場合があります。クラス・ベースのシェーピングは出力レートを制限し、論理トンネル・インターフェイスの混雑した状態の原因となります。トンネルインターフェイスでは、シェーパによって保持されている超過パケットのキューイングを開始し、超過パケットには高度なキューイングポリシーが適用されます。ハードウェアによる暗号化エンジンでは、FIFO キューイングだけがサポートされています。そのため、LLQ を使用するサービスポリシーを、トンネルトラフィックが転送される出力側の物理インターフェイスに適用する場合は、IPSec プロセスのパフォーマンスが出力インターフェイスより大きくなるようにしてください。これによって、このインターフェイスのプライオリティキューイングのメカニズムが動作するようになり、暗号化エンジンが FIFO のボトルネックになることを避けることができます。 Cisco IOSソフトウェアリリース12.1ではpolicy-mapの単一クラスにことをパケットマッチ確認するために、一般的な分類はもたらされました(詳細についてはQuality of Service操作手順を参照して下さい)。 VPN環境では、この改良の1つの結果はサービスポリシーがIP precedenceで一致するか、またはトンネルヘッダーのDSCP値を規定する時でさえIPSecトンネル内の暗号化トラフィックフローの分類が失敗することです。この問題は、Cisco IOS ソフトウェアリリース 12.2(10) で解決されており、Cisco Bug ID CSCdw90486（登録ユーザ専用）と CSCdx08427（登録ユーザ専用）に記述されています。含んでいるCisco IOSソフトウェアリリースでは変更はこれらの不具合が理由で、ハードウェアおよびソフトウェア暗号化との分類の動作現在一貫しています設定しました。この表では、QoS の事前分類を設定している場合と、設定していない場合について、このバグ修正が行われた後の MQC 機能の動作を説明しています。事前分類をサポートしないし、有効になる事前分類がないプラットフォームに関しては「」のMQC動作はカラムを期待されますnot preclassify。この文書全般に渡って内側と外側のヘッダーの定義に使用されているものと同じ定義が、この表でも使用されています。事前分類あり Preclassify無しハードウェア暗号化アクセラレータおよびCEF 共通分類内側 outside

set および police コマンド内側 outside

キューイング内側 outside

フローベース WFQ 内側 outside

ハードウェア暗号化アクセラレータおよびプロセススイッチング

(10)

set および police コマンド内側（1） outside

ソフトウェア暗号化と CEF

共通分類内側 outside

set および police コマンド内側 outside

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

共通分類内側 outside

set および police コマンド内側（1） outside

「Note:setおよびpoliceコマンドがpreclassifiedクラスで機能するが、パケットのマーキングは外ヘッダにだけ発生します。

設定例

この設定例では、IPSec と GRE の環境に対して QoS サービスポリシーを作成するコマンドを説明しています。 GREトンネルはIPSecピアを接続し、トンネル伝送されたパケットはIPSecの助けによって暗号化されます。 set ip precedenceにクラスベースマーキングを加える入力ポリシーを作成して下さい。

クラス・ベースのシェーピングを使用して最大帯域幅に各暗号化されたトンネルを制限し、またClass-Based Weighted Fair Queuing (CBWFQ)によって最小帯域幅保証を適用する出力ポリシーを作成して下さい。

入力ポリシー

クラスベースマーキングを加える入力ポリシーを作成するためにこれらのステップを完了して下さい。

ip cef コマンドで CEF をイネーブルにします。クラスベースマーキングにCEFが必要となります。 QoSでCEFが必要とされる場合を参照して下さいを参照してください。 1. トラフィックをクラスにソートするため基準を定義して下さい。この設定では、Telnet トラフィックに対して「flow-hi」クラスを、ICMP トラフィックに対して「flow-low」クラスを定義しています。 2. ポリシーマップを定義し、定義されたクラスにQoSアクションを定義して下さい。 3. インターフェイスにポリシーを適用して下さい。この場合、それはシリアルサブインターフェイスです。 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

(11)

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 を適用しています。親ポリシーを作成して下さい。この設定では、「ipsec」クラスを定義して、これで照合するトラフィックを 16 kbps にシェーピングしています。 2. 親ポリシー内の子ポリシーを適用して下さい。この設定では、親ポリシー「qos-out」の中に、子ポリシー「ipsec-flow」を QoS アクションとして適用しています。この QoS アクションは、シェーパによって保持およびキューイングされていたパケットに対する CBWFQ です。 3. インターフェイスに親ポリシーを適用して下さい。この場合、それはシリアルサブインターフェイスです。 4. この表では、再マークした値に基づいて、シェーピングを行い、CBWFQ を適用する出力ポリシーの設定を示しています。シェーピングと CBWFQ を実行する出力ポリシー

class-map match-all ipsec-hi match ip precedence 4 class-map match-all ipsec-low

(12)

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

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

(13)

Match: any

「Note: 親ポリシーでは、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 パケットがプロセス交換されていたのがこの理由です。「Note:クラスマップで非IPプロトコルで、IPXおよびAppleTalkのような一致するmatch protocolコマンドを使用しまた内部ヘッダーの値で一致するためにqos pre-classifyを有効にすれば内部ヘッダーに基づく分類ははたらきません。

制限および関連問題

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

QoS および再生防止保護

一部の暗号変換セットにはリプレイ攻撃に対する防御機能が備わっており、暗号化ヘッダーにシーケンス番号を適用している場合に機能します。高度なキューイングを行っていて輻輳しているインターフェイスでは、優先順位の低いパケットはキュー内で遅延する場合があり、リプレイ攻撃対策の枠が超過した後で、復号化を行うルータに到達することになります。この場合、受け取るデバイスはパケットを廃棄します。さらに、暗号化されたパケットがある特定のウィンドウによって宛先で(現在64のパケットに設定される)順序が狂って着けば、パケットは廃棄されます。 Ciscoはこれらの制限を克服するメソッドのための眺望に現在あります。再生防止保護が設定されているこれらのトランスフォームから無効である場合もないことに注目して下さい。 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

(14)

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が両方設定されるとき、パケットはGREカプセル化と一度IPSecカプセル化の後で2回CEFルックアップ・プロセスによる、一度動作します。パケットが伝送されるのは 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.

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の事前分類機能は一緒にサポートされませんCiscoのレガシー・プライオリティ・キューイング機能。その代り、MQCのpriorityコマンドでポリシーマップを設定することによる実装する LLQ。

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

ハードウェアによる暗号化と QoS で解決済の問題があります。 CiscoバグID CSCdv25358 (登録ユーザだけ) - Ciscoレガシー専用アクセスレート(CAR)機能を通してトラフィック・ポリシングを設定するrate-limitコマンドを使用するときqos pre-classifyコマンドはハードウェア暗号化も使用されるときはたらきません。この機能の組み合わせでは、暗号化が実行されません。対応策として、モジュラQoS Command Line

Interface (CLI) (MQC)で設定されるpolicy-mapのpoliceコマンドの助けによる実装するクラスベースのポリシング。他の QoS 機能（MQC または非 MQC）は影響を受けません。

CiscoバグID CSCdw29595 (登録ユーザだけ) -暗号化パスのパフォーマンスはCisco IOSソフトウェアリリース12.2(6.8)がハードウェア暗号化カードと使用されるとき低下します。このパフォーマンスのロスは、暗号化されたパケットが、ファーストスイッチングではなく、プロセス交換されるためです。この状況は、IPSec がインターフェイスに適用され、同時にハードウェア暗号化カードが使用されている場合に発生します。回避策はありません。 CiscoバグID CSCdw30566 (登録ユーザだけ) - GRE環境のIPSecでは、CEFを有効にすれば、それは低下した転送パフォーマンスのパケットが実際にプロセス交換されるので原因となります。パケットが GRE カプセル化処理を受けた後に行われる、 CEF のパケットの処理方法が、この状態の原因です。対応策として、ディセーブルCEFは、パケットがファスト・スイッチされるようにし。暗号化アクセラレータを使用している場合には、この文書の「パケットの分類」のセクションと、Cisco Bug ID CSCdw90486（登

(15)

録ユーザ専用）と CSCdx08427（登録ユーザ専用）で行われた変更の説明を参照してください。