| ライター翻訳版 - September 14, 2004 |
| Document ID: 41160 |
ダウンロード: PDF  |
目次
概要
前提条件
要件
使用するコンポーネント
表記法
IP インプット
IP パケットのデバッグ セッションのサンプル
関連情報
概要
この文書では、IP インプット プロセスにより CPU 使用率が高い場合のトラブルシューティング方法を説明します。
注：この文書では、さまざまな種類の攻撃を防御する方法については説明していません。
前提条件
要件
この文書を読む前に、『Cisco ルータの CPU 使用率が高い場合のトラブルシューティング』をお読みいただくことをお勧めします。
使用するコンポーネント
この文書は、特定のソフトウェアまたはハードウェアのバージョンに限定されるものではありません。
この文書で紹介する情報は、特定のラボ環境にあるデバイスを使用して作成されました。この文書で使用するすべてのデバイスは、クリアな状態（デフォルト）から設定作業を始めています。実稼動中のネットワークで作業する場合は、コマンドの実行によって生じる影響について、事前に理解しておいてください。
表記法
文書表記の詳細については、『シスコ テクニカル ティップスの表記法』を参照してください。
IP インプット
「IP インプット」と呼ばれる Cisco IOS(R) ソフトウェアのプロセスが、IP パケットの交換プロセスを受け持ちます。 IP インプット プロセスによりきわめて高い CPU リソースが使用されている場合、ルータは大量の IP トラフィックのプロセス交換を行っていることを意味します。 次の問題を確認してください。
-
トラフィックが大量に存在する 1 つのインターフェイス（または複数のインターフェイス）で割り込みスイッチングが無効になっている
割り込みスイッチングとは、プロセス交換以外のスイッチング アルゴリズムの使用を指します。 例には、ファースト スイッチング、最適スイッチング、Cisco Express Forwarding スイッチングなどがあります（詳細は『パフォーマンス チューニングに関する基本事項』を参照）。 show interfaces switching コマンドの出力を調べ、どのインターフェイスにトラフィックの負荷がかかっているかを確認します。 show ip interface コマンドで調べると、各インターフェイスでどのスイッチング方式が使用されているかが確認できます。 そのインターフェイスで割り込みスイッチングを再度有効にします。 出力インターフェイスでは通常のファート スイッチングが設定されていることに注意してください。 インターフェイスでファースト スイッチングが設定されている場合、そのインターフェースから送信されるパケットはファースト スイッチングされます。 入力インターフェイスでは Cisco Express Forwarding スイッチングが設定されています。 特定のインターフェイスで Forwarding Information Base（FIB; 転送情報ベース）および隣接関係テーブルのエントリを作成するには、そのインターフェイスにルーティングされるすべてのインターフェイスで Cisco Express Forwarding スイッチングを設定します。
-
同一インターフェイスでファースト スイッチングが無効になっている
インターフェイスに大量のセカンダリ アドレスやサブインターフェイスがあり、そのインターフェイスが送信元でその同じインターフェース上のアドレスが宛先になっている大量のトラフィックが存在する場合、そのインターフェイスではそれらすべてのパケットのプロセス交換が行われます。 このような場合、そのインターフェイス上で ip route-cache same-interface を有効にする必要があります。 Cisco Express Forwarding スイッチングが使用されている場合、同じインターフェース上で別個に Cisco Express Forwarding スイッチングを有効にする必要はありません。
-
ポリシー ルーティングを行っているインターフェイスでファースト スイッチングが無効になっている
インターフェイス上で route-map が設定され、route-map により大量のトラフィックが処理されている場合、ルータがこのトラフィックのプロセス交換を行っています。 このような場合、そのインターフェイス上で ip route-cache policy を有効にする必要があります。 『ファースト スイッチングされるポリシーベース ルーティングの有効化』で説明されている制限を確認してください。
-
割り込みスイッチングが不可能なトラフィックが着信している
これは、次の種類のトラフィックのいずれにも該当する可能性があります。 詳細については、リンク付きの項目をクリックしてください。
-
スイッチング キャッシュ内にまだエントリがなかったパケット
ファースト スイッチング、最適スイッチング、または Cisco Express Forwarding スイッチング（*）が設定されている場合であっても、ファースト スイッチングのキャッシュや FIB テーブルおよび隣接関係テーブルに一致する項目がないパケットが処理されます。 続いて適切なキャッシュまたはテーブルにエントリが作成され、同じ基準に一致するそれ以降すべてのパケットには、ファースト スイッチング、最適スイッチング、または CEF スイッチングが適用されます。 通常、処理されるこれらのパケットは CPU 使用率を高める原因にはなりません。 ただし、ネットワーク内のデバイスが、1) ルータを経由して到達可能なデバイスに対してきわめて高いレートでパケットを生成している、および 2) 異なる送信元または宛先 IP アドレスを使用している場合、スイッチング キャッシュまたはテーブルにはこれらのパケットに一致するものが存在しないため、これらは IP インプット プロセスにより処理されます（NetFlow スイッチングが設定されている場合、送信元および宛先 TCP ポートは NetFlow キャッシュ内のエントリとも照合して確認されます）。 この送信元デバイスは、動作が正常ではないデバイスである可能性があり、さらに攻撃を試みているデバイスである可能性はもっと高いと考えられます。
（*）glean 隣接関係だけに関係します。 Cisco Express Forwarding の隣接関係の詳細については、『Cisco Express Forwarding』文書を参照してください。
-
ルータが宛先になっているパケット
ルータが宛先になっているパケットの例は次のようになります。
-
きわめて高いレートで着信しているルーティング更新。 ルータが、処理する必要がある膨大な量のルーティング更新を受信している場合、このタスクにより CPU が過負荷状態になる場合があります。 通常、安定したネットワークではこのようなことは起こりません。 詳細な情報を収集する方法は、設定したルーティング プロトコルに応じて異なります。 しかし、最初の手順として、show ip route summary コマンドの出力を定期的に確認する方法があります。 値が急速に変化している場合は、ネットワークが不安定である兆候です。 ルーティング テーブルの変更が頻発することはルーティング プロトコルの処理の増大を意味し、CPU 使用率を増大させます。 トラブルシューティングの詳細については、『インターネットワーク トラブルシューティング ガイド』の「TCP/IP のトラブルシューティング」を参照してください。
-
宛先がルータになっているその他すべての種類のトラフィック。 ルータにログオンしているユーザと、そのユーザの動作を確認します。 ログオンしているユーザが長大な出力を生成するコマンドを発行している場合、「IP インプット」プロセスによる高い CPU 使用率の後に、仮想 EXEC プロセスによるさらに高い CPU 使用率が続きます。
-
スプーフィング攻撃。 この問題を特定するには、show ip traffic コマンドを発行して、IP トラフィックの量を確認します。 問題が存在する場合、ローカルな宛先の受信パケットの数が重要になります。 続いて、show interfaces および show interfaces switching コマンドの出力を調べることで、どのインターフェイスにパケットが着信しているかを調べます。 パケットを受信しているインターフェイスを特定したら、発信インターフェイスで ip accounting を有効にしてパターンが存在するかどうかを確認します。 それが攻撃である場合は、必ずと言っていいほど、送信元アドレスが異なりますが、宛先アドレスは同じです。 アクセス リストを設定することでこの問題を一時的に解決できますが（パケットの送信元に最も近いデバイス上で行うのが望ましい）、真の解決は送信元デバイスを追跡し、攻撃をやめさせることです。
-
-
ブロードキャスト トラフィック
show interfaces コマンドの出力で、ブロードキャスト パケットの数を確認します。 ブロードキャストの数を、インターフェイス上で受信されたパケットの合計数と比較することで、ブロードキャストのオーバーヘッドが存在するかどうかが分かります。 複数のスイッチがルータに接続されている LAN が存在する場合、これはスパニングツリーに関する問題であることを示している場合があります。
-
オプション付きの IP パケット
-
プロトコル変換を必要とするパケット
-
マルチリンク ポイントツーポイント プロトコル（Cisco Express Forwarding スイッチングでサポート）
-
圧縮されたトラフィック
ルータに Compression Service Adapter（CSA; 圧縮サービス アダプタ）が存在しない場合、圧縮されたパケットをプロセス交換する必要が生じます。
-
暗号化されたトラフィック
ルータに Encryption Service Adapter（ESA; 暗号化サービス アダプタ）が存在しない場合、暗号化されたパケットをプロセス交換する必要が生じます。
-
X.25 カプセル化を使用するシリアル インターフェイスを通過するパケット
X.25 プロトコル スイートでは、フロー制御は Open System Interconnection（OSI）第 2 層に実装されています。
-
-
直接接続されたサブネット内の宛先に対して、きわめて高いレートで大量のパケットが着信していますが、Address Resolution Protocol（ARP）テーブル内には、これに対応するエントリが存在しません。 ウィンドウイング メカニズムにより、TCP トラフィックではこのようなことは発生しないはずですが、User Datagram Protocol（UDP; ユーザ データグラム プロトコル）では発生する可能性があります。 この問題を特定するには、上記のスプーフィング攻撃の追跡に推奨されている処置を繰り返します。
-
大量のマルチキャスト トラフィックがルータを通過する。 残念ながら、マルチキャスト トラフィックの量を調べる簡単な方法はありません。 show ip traffic コマンドは、要約情報だけを示します。 ただし、ルータでマルチキャスト ルーティングを設定している場合は、ip mroute-cache インターフェイス設定コマンドを使用してマルチキャスト パケットのファースト スイッチングを有効にできます（マルチキャスト パケットのファースト スイッチングはデフォルトではオフになっています）。
-
ルータが加入過多の状態になっている。 ルータが過剰に使用され、この量のトラフィックを処理できない場合は、他のルータ間で負荷の分散を試みるか、ハイエンド ルータの購入を検討してください。
-
ルータに IP Network Address Translation（NAT; ネットワーク アドレス変換）が設定されており、大量の Domain Name System（DNS; ドメイン ネーム システム）パケットがルータを通過している。 送信元/宛先ポートが 53（DNS）である UDP または TCP は、常に NAT によりプロセス レベルにパントされます。
-
処理にパントされるその他のパケットの種類が存在する。
IP インプット プロセスにおける CPU 使用率が高い理由が何であれ、IP パケットをデバッグすることで問題の発信源を追跡できます。 CPU 使用率がすでに高いため、デバッグは非常に注意深く行う必要があります。 デバッグにより大量のメッセージが生成されるため、logging buffered だけを設定する必要があります。
コンソールへのロギングは CPU への不必要な割り込みを発生させるため、CPU 使用率を上昇させます。 ホストへのロギング（またはモニタ ロギング）により、インターフェイス上でさらに多くのトラフィックが生成されます。
デバッグを開始するには、debug ip packet detail exec コマンドを発行します。 デバッグ セッションを、3 〜 5 秒以上は続けないでください。 デバッグ メッセージはロギング バッファに書き込まれます。 サンプル デバッグ セッションのキャプチャを、下記の「IP パケットのデバッグ セッションのサンプル」に示します。 不必要な IP パケットの送信元デバイスが見つかれば、そのデバイスをネットワークから切断したり、ルータ上でその送信元からのパケットを廃棄するアクセス リストを作成できます。
IP パケットのデバッグ セッションのサンプル
show logging コマンドを発行して、まず設定済みのロギングの宛先を確認する必要があります。
router#show logging
Syslog logging: enabled (0 messages dropped, 0 flushes, 0 overruns)
Console logging: level debugging, 52 messages logged
Monitor logging: level debugging, 0 messages logged
Buffer logging: level debugging, 148 messages logged
Trap logging: level informational, 64 message lines logged
Logging to 192.168.100.100, 3 message lines logged
Logging to 192.168.200.200, 3 message lines logged
--More--
ロギング バッファ以外のすべてのロギングの宛先を無効にし、ロギング バッファをクリアします。
router#configure terminal Enter configuration commands, one per line. End with CNTL/Z. router(config)#no logging console router(config)#no logging monitor router(config)#no logging 192.168.100.100 router(config)#no logging 192.168.200.200 router(config)#^Z router#clear logging Clear logging buffer [confirm] router#
デバッグ出力を読みやすくするため、日時とミリ秒のタイムスタンプをイネーブルにしておきます。
router#configure terminal Enter configuration commands, one per line. End with CNTL/Z. router(config)#service timestamps log datetime msec router(config)#service timestamps debug datetime msec router(config)#end router#
これでデバッグ セッションを開始できるようになりました。
router#debug ip packet detail IP packet debugging is on (detailed)
デバッグは、3 〜 5 秒以上続けないでください。 デバッグを停止するには、undebug all exec コマンドを発行します。
router#undebug all All possible debugging has been turned off
結果を確認するには、show logging exec コマンドを発行します。
router#show logging
Syslog logging: enabled (0 messages dropped, 0 flushes, 0 overruns)
Console logging: disabled
Monitor logging: disabled
Buffer logging: level debugging, 145 messages logged
Trap logging: level informational, 61 message lines logged
Log Buffer (64000 bytes):
*Mar 3 03:43:27.320: IP: s=192.168.40.53 (Ethernet0/1), d=144.254.2.204
(Ethernet0/0), g=10.200.40.1, len 100, forward
*Mar 3 03:43:27.324: ICMP type=8, code=0
*Mar 3 03:43:27.324: IP: s=192.168.40.53 (Ethernet0/1), d=144.254.2.205
(Ethernet0/0), g=10.200.40.1, len 100, forward
*Mar 3 03:43:27.324: ICMP type=8, code=0
*Mar 3 03:43:27.328: IP: s=192.168.40.53 (Ethernet0/1), d=144.254.2.206
(Ethernet0/0), g=10.200.40.1, len 100, forward
*Mar 3 03:43:27.328: ICMP type=8, code=0
...
ログには次の内容が示されています。
-
4 ミリ秒ごとにパケットが受信された
-
送信元 IP アドレスは 192.168.40.53 である
-
パケットはインターフェイス Ethernet0/1 上で着信した
-
パケットは異なる宛先 IP アドレスを持っている
-
パケットはインターフェイス Ethernet0/0 上で送出された
-
ネクストホップ IP アドレスは 10.200.40.1 である
-
パケットは ICMP 要求（タイプ=8）であった
この例では、IP インプット プロセスにおける高い CPU 使用率の原因は、IP アドレス 192.168.40.53 からの ping フラッドであることが分かります。
SYN フラグの存在がデバッグ出力に示されるため、SYN フラッドもこの方法で簡単に検出できます。
*Mar 3 03:54:40.436: IP: s=192.168.40.53 (Ethernet0/1), d=144.254.2.204 (Ethernet0/0), g=10.200.40.1, len 44, forward *Mar 3 03:54:40.440: TCP src=11004, dst=53, seq=280872555, ack=0, win=4128 SYN