ASA 過負荷とインターフェースエラーのトラブルシューティング

tsmori · ‎2017-11-14

1 概要
2 問題の特定
2.1 問題の性質
2.2 CPU
2.3 インターフェース
2.4 負荷
3 緩和と軽減
3.1 プロセス
3.2 トラフィック
3.3 スループットの最適化
3.4 フローコントロール
3.5 Active/ Active フェールオーバー
3.6 ハードウェアの追加
4 参考情報

1 概要

オーバーサブスクリプション、もしくはファイアウォールやネットワークデバイスにおける過負荷の兆候は、過負荷が実際に発生しているかどうかを証明するのに十分でないことがよくあります。また、どのようにそれらの問題の特定や解決をすればよいか、分かりづらいことがよくあります。

本ドキュメントでは、Cisco ASAファイアウォールにおける過負荷の問題を特定する基本的なトラブルシューティングの手順と、問題を解消する可能性のある解決策を提示します。FWSMに対応する文書はこちらを参照してください。

2 問題の特定

過負荷の問題を解決するのに最も重要なポイントは、問題の特定です。

ネットワークエンジニアは多くの場合、ネットワークの問題を過度のトラフィックによるものと誤認し、ファイアウォールのようなデバイスが間違ってボトルネックとみなされます。

また、ファイアウォールの能力がトラフィック処理に十分でない場合に、ネットワークの他の箇所に焦点が当てられてしまうこともあります。ファイアウォールデバイスには、複数の負荷の問題がある可能性があります。

それらを総合して考えることは、実際にトラフィックが問題の原因となっているのか、それとも他の部分に焦点をあてるべきなのかを判断するのに役立ちます。それがこの章で説明しようとするものです。

2.1 問題の性質

過負荷は、それ単独ではほとんど発生しません。

ほとんどの場合、その結果として生じる別のネットワークの問題として提示されます。それにはしばしば、パケットロスや応答速度の低下、パケットドロップが含まれます。通常、処理能力を超える過負荷に陥ったデバイスは、パケットドロップを引き起こします。

パケットドロップは、重要なアプリケーションに影響を与えるか、もしくはTCPの再送信を引き起こし、完了に時間がかかるように見えることでユーザーエクスペリエンスに影響を与えます。

過負荷のために発生するその問題を要約したい場合、ネットワークの品質劣化と説明します。もちろん、これは慎重に判断されなければならず、品質劣化に該当するすべてのものを、負荷の問題とみなしてはいけません。以下に示すものは、そのような問題が過度の負荷に起因しているかどうかを識別する上で役立ちます。

2.2 CPU

ビジー状態のファイアウォールデバイスは、ほぼ常にそのCPUにそれを表示します。CPUの使用状況は"show cpu" コマンドを使用して、確認することができます。

ASA# show cpu
 
 CPU utilization for 5 seconds = 14%; 1 minute: 10%; 5 minutes: 10%

80％〜90％を超えるCPU使用率は、トラフィック負荷が高いことを示している可能性があります。また、CPU hogsは、CPUがビジーなためパケットを処理できないことを示します。

ASA# show process cpu-hog
 
 Process:      telnet/ci, NUMHOG: 1, MAXHOG: 12, LASTHOG: 12
 LASTHOG At:   20:18:08 EST Nov 8 2010
 PC:           888c7e5 (suspend)
 Call stack:   888c7e5  92f6581  92d65de  92d6d71  80cbaf7  80cbfcb   80c2575
               80c2d1f  80c3e66  80c4910  80626e3
 
 CPU hog threshold (msec):  3.47
 Last cleared: None

上の例ではtelnetプロセスがCPUをhog状態にしています。この間、CPUはNICのパケットを取り出して、ファイアウォールを通過させることはできません。

2.3 インターフェース

過負荷のもう一つの重要な指標は、インタフェースエラーです。インターフェースを確認するコマンドは、 "show interface"と "show interface | i errors"が利用できます。

ASA# show interface | i errors
         0 input errors, 0 CRC, 0 frame, 1567 overrun, 0 ignored, 0 abort
         0 output errors, 0 collisions, 0 interface resets
         0 input errors, 0 CRC, 0 frame, 124 overrun, 0 ignored, 0 abort
         0 output errors, 0 collisions, 0 interface resets
         0 input errors, 0 CRC, 0 frame, 987564 overrun, 0 ignored, 0 abort
         0 output errors, 0 collisions, 0 interface resets
 ...
 ASA#
 ASA# show interface
 ...
 Interface Ethernet0/1 "", is up, line protocol is up
   Hardware is 88E6095, BW 100 Mbps, DLY 100 usec
 
         Auto-Duplex(Full-duplex), Auto-Speed(100 Mbps)
         MAC address ffff.ffff.ffff, MTU 1500
         IP address 10.10.10.1, subnet mask 255.255.255.0
         2050839 packets input, 133555759 bytes, 0 no buffer
         Received 2044728 broadcasts, 0 runts, 0 giants
         0 input errors, 0 CRC, 0 frame, 3276 overruns, 0 ignored, 0 abort
         0 L2 decode drops
         6364 packets output, 2970714 bytes, 332 underruns
         0 output errors, 0 collisions, 0 interface resets
         0 babbles, 0 late collisions, 0 deferred
         0 lost carrier, 0 no carrier
         input queue (curr/max packets): hardware (4/13) software (0/0)
         output queue (curr/max packets): hardware (0/2) software (0/0)
 ...

インターフェースのoverruns、no buffer 、underrunsは、ファイアウォールが NICで受信しているすべての受信トラフィックを処理できていないことを示すことがよくあります。Overruns および no bufferは、受信トラフィックが所定のインターフェース上で多すぎることを示しています。

インターフェースはパケットが格納されている受信リング（バッファ）を、ASAによって処理される前に保持します。ASAが受信リングからトラフィックを取り出すより早く、NICがトラフィックを受け取った場合、パケットは破棄され、no buffer もしくは overrunカウンターが増加します。underrunsも同様ですが、こちらは代わりに送信リングに対応しています。

2.4 負荷

次に、デバイスが見ているトラフィックのチェックをする価値があります。"show traffic" でトラフィックの統計情報を確認する前に、"clear traffic" でそれをクリアする必要があります。これは、問題が発生している間のトラフィックを確認し、調査中の問題に負荷が関連しているか判断をするために行います。

show trafficで総トラフィック出力を見ると、前回の再起動時または最後のカウンタクリア時以降の情報が出てくるので、デバイスがトラブルシューティング中にどれくらいのトラフィックを見ているのか判別することができません。

"clear traffic"後、デバイスに2〜5分間の統計情報を収集させ、インターフェースが見たトラフィックを得るためにshow trafficを実行します。

ASA# clear traffic
 ...
 ...5 minutes go by...
 ...
 ASA# show traffic
 ...
 ----------------------------------------
 Aggregated Traffic on Physical Interface
 ----------------------------------------
 Ethernet0/0:
 
         received (in 1137.180 secs):
                 8985 packets    773519 bytes
                 7 pkts/sec      680 bytes/sec
         transmitted (in 1137.180 secs):
                 3946 packets    276317 bytes
                 3 pkts/sec      242 bytes/sec
       1 minute input rate 243555 pkts/sec,  731777777 bytes/sec
       1 minute output rate 3434534 pkts/sec,  291777777 bytes/sec
       1 minute drop rate, 0 pkts/sec
       5 minute input rate 35435353 pkts/sec,  792545454444 bytes/sec
       5 minute output rate 343423 pkts/sec,  3614444444 bytes/sec
       5 minute drop rate, 0 pkts/sec
 ...

モニタリングツールや NetFlowも、トラフィックやコネクション数を割り出すのに役立ちます。

すべての物理インターフェースが見たトラフィックを調べることで（"show traffic"の出力）、デバイスが伝送している総スループットを計算でき、それが限界に達しているのか判断することができます。そのためには、デバイスの仕様を確認する必要があります。

ASAについては、 ASA model comparisonをご覧ください。

Cisco ASA 5500 Series Model/License	5505 Base/Security Plus	5510 Base / Security Plus	5520	5540	5550	5580-20	5580-40
Maximum firewall throughput (Mbps)	150 Mbps	300 Mbps	450 Mbps	650 Mbps	1 Gbps (real-world HTTP), 1.2 Gbps (jumbo frames)	5 Gbps (real-world HTTP), 10 Gbps (jumbo frames)	10 Gbps (real-world HTTP), 20 Gbps (jumbo frames)
Maximum firewall connections	10,000 / 25,000	50,000 / 130,000	280,000	400,000	650,000	1,000,000	2,000,000
Maximum firewall connections/second	4000	9000	12,000	25,000	36,000	90,000	150,000
Packets per second (64 byte)	85,000	190,000	320,000	500,000	600,000	2,500,000	4,000,000

ファイアウォールやその他のデバイスがトラフィック処理の限界にぶつかっているのか、見分けることができるかという長い議論があります。数値が示しているものと、エンジニアが数値に近いと考えるものについては、これまでも論争がありました。いくつかの点を明確にすることが有意義です。

ASA5510を例にとってみましょう。上記のテーブルにあるようにスループットの名目値は300Mbpsです。ここで疑問なのは、もしあるASA5510が約280Mbpsでトラフィックを見ている場合、それはCPUの限界に達しているかということです。単純に答えれば答えはNOでしょう。ただしこの問いには、たくさんの要因が関係しているということを忘れてはいけません。

ネットワーク業界では、いくつかの決まったテストの下でデバイスの名目スピードが割り出されます。それらのテストが繰り返され、その平均が最高速度として提示されます。

しかし、「現実の」トラフィックは、必ずしもテストで使用されたものと同じとは限りません。私たちは例として前述のASA5510を使用することができます。通常、名目値を測るスピードテストは、大きなサイズのステートレスプロトコルが含まれます。(訳者注釈：データシート上の名目値を図るテストは、UDPのパケットサイズ1400バイトなど、性能を最大化できる通信方法で行うことが多いです。)

ところが、TCPウェブブラウジングアプリケーションにおいては、パケットはずっと小さものとなります。また、本来TCPはACKを使用し同期をとるプロトコルです。それはファイアウォールの処理負荷を増やし、最大スループット値を低下させるでしょう。

その上、もしASAにhttpインスペクションが設定されていれば（httpの詳細なパケット検査が行われる）、処理できる最大スループットが280Mbps未満となるであろうことは理解できます。

たとえ300Mbpsが本当にデバイスの達成できるスループットであったとしても、アプリケーションや実際のトラフィックの性質、設定に基づいた実効スループットは、実質的に低くなることもあるのは明らかです。

そのため、私たちはパフォーマンスドキュメントの中で、他の指標も提供しています。

これには、 "1秒あたりのパケット数"（pps）と、"real-world HTTP "と見なされているものが含まれています

例えばASAテーブルをみると、5510では190K pps（64-byte packets）を処理できることがわかります。これらの指標は、デバイスがその限界に達しているかどうかを判断するために、デバイスから収集されたインターフェース統計情報に対しても使用することができます。

ファイアウォールデバイスのトラフィック負荷における別の考慮事項は、コネクションとコネクション数です。これは、さまざまな不一致を引き起こす可能性のある別のフィールドです。ファイアウォールのコネクションを確認するために使用するコマンドは、「show conn count」と「show resource usage」です。

ASA5510# show conn count
 2 in use, 86 most used
 ASA5510# show resource usage
 Resource              Current         Peak      Limit        Denied Context
 Telnet                      1            1          5             0 System
 Syslogs [rate]              1          293        N/A             0 System
 Conns                       2           86      10000             0 System
 Xlates                      5          116        N/A             0 System
 Hosts                       6           49        N/A             0 System
  
 ASA5510-multi-context# show resource usage
 Resource              Current         Peak      Limit        Denied Context
 SSH                         1            1         15             0 admin
 Syslogs [rate]            118          348  unlimited             0 context1
 Conns                      89          893  unlimited             0 context1
 Xlates                    150         1115  unlimited             0 context1
 Hosts                      15           18  unlimited             0 context1
 Conns [rate]               103        4694 unlimited             0 context1
 ...

さて、上記のASA5510からの出力についてもう一つ質問をしてみましょう。上記を見るとピークのコネクション数は約5K、仕様書の最大サポート数を見ると、毎秒9Kコネクションとあります。5Kは9Kよりはるかに少ないので、ASAは限界を超えているでしょうか。この質問に答えるためには、仕様書に書かれているコネクション数は1秒あたりの平均値であることに留意する必要があります。分かりやすく説明するために、いくつかの例をあげます。

私たちが毎秒9Kの安定した速度を持っているとします。この接続速度は、ASA5510の制限に準拠しています。
さて、10秒間に90Kの新しいコネクションがあるのを見てみましょう。これもまた、毎秒9Kの速度であり、ASA5510の制限に準拠しています。
次に、1秒間に81Kの新規のコネクションを、次の9秒間に1Kのコネクションを持つとしましょう。これで10秒あたりの合計が90Kとなり、毎秒平均9Kとなります。これは9K 接続/秒に適います。しかし、ASAは81K /秒を見ている1秒の間に過負荷に陥りました。

このように、時間の経過に伴う平均値では限界を超えていないように見えても、トラフィックやコネクションの一時的なバーストが、ファイアウォールのパフォーマンスに影響を与える可能性があることは明らかです。

さらに、デバイスを通るコネクションが少ないことは、必ずしもトラフィックが少ないことを表してはいません。理論的に言えば、誰かがそれぞれ1Gbpsを超える10個のコネクションを持つことができ、そのため、ごく少数のコネクションでもASAは過負荷に陥る可能性があります。

3 緩和と軽減

さて、過負荷の問題を克服するためのオプションについて言及することも同様に重要です。デバイスが過負荷に陥っている場合、通常、より高性能なデバイスを使用して、処理能力を強化するのが最善であるということを覚えておいてください。ただし、高負荷の発生原因やトラフィック状況を特定した後、いくつかの回避策を実行することで問題を解決できる場合もあります。オーバーサブスクリプション/過負荷の原因の特定は、外部のツールやトラフィック分析に頼る必要があります。

3.1 プロセス

CPU使用率が高い場合はCPUがどこに費やされているかを調べることができ、CPUサイクルを最も費やしているプロセスからそれを軽減させることができるかもしれません。私たちは "show process"コマンドの出力を収集し、1分間待ってから再度収集することができます。

ASA# show process
 
     PC       SP       STATE       Runtime    SBASE     Stack Process
 
 Lwe 0805510c d52a0cf4 09fbeed8          0 d529edf0 7544/8192 block_diag
 Mrd 081beaa4 d52d087c 09fbe438        873 d52b0a38 123848/131072 Dispatch Unit
 Msi 08f6348f d5784f8c 09fbde4c         13 d5783088 7792/8192 y88acs06 OneSec Thread
 Mwe 08068bc6 d578938c 09fbde4c          0 d57874e8 7576/8192 Reload Control Thread
 Mwe 08070976 d5794314 09fc07f8          0 d5790760 12496/16384 aaa
 Mwe 08d094ed d60111ec 09fbde4c          4 d57948e8 6872/8192 UserFromCert Thread
 Mwe 08c331eb d57987f4 d57d47d0          0 d5796a70 6920/8192 Boot Message Proxy Process
 Mwe 080a49f6 d579d37c 09fc0854        107 d5799488 8968/16384 CMGR Server Process
 Mwe 080a4f05 d579f4a4 09fbde4c         20 d579d610 7696/8192 CMGR Timer Process
 Lwe 081bdecc d57a8b9c 09fceba8          0 d57a6c98 7216/8192 dbgtrace
 Mwe 08498525 d57b11c4 09fbde4c        172 d57af440 4712/8192 eswilp_svi_init
 Msi 0861af45 d57c4734 09fbde4c         28 d57c2850 6952/8192 MUS Timeout Check Thread
 Mwe 08d094ed d5a3845c 09fbde4c          0 d57cb0e0 7016/8192 netfs_thread_init
 Mwe 09378625 d57d952c 09fbde4c          0 d57d76d8 7612/8192 Chunk Manager
 Msi 0894d40e d57dbcdc 09fbde4c         22 d57d9df8 7560/8192 PIX Garbage Collector
 Mwe 08932ea4 d57eadfc 09ebdb4c          0 d57e8ef8 7904/8192 IP Address Assign
 Mwe 08b41146 d597d8dc 09f02838          0 d597b9d8 7904/8192 QoS Support Module
 Mwe 089c501f d597faa4 09ebebd0          0 d597dba0 7904/8192 Client Update Task
 Lwe 093c1dba d5984404 09fbde4c        685 d5980570 15888/16384 Checkheaps
 Mwe 08b44e65 d598c86c 09fbde4c       1535 d5988bf8 5648/16384 Quack process
 Mwe 08b9e1f2 d5994bf4 09fbde4c          1 d598cd80 31888/32768 Session Manager
 Mwe 08cb45b5 d599aae4 d7cbd3b0          4 d5997090 14312/16384 uauth
 Mwe 08c52475 d599d11c 09f0f884          0 d599b218 7376/8192 Uauth_Proxy
 Msp 08c893ce d59a35b4 09fbde4c          2 d59a16b0 7792/8192 SSL
 Mwe 08cb1f46 d59a5754 09f15434          0 d59a3870 7272/8192 SMTP
 Mwe 08caac96 d59a98dc 09f15398         30 d59a59f8 15096/16384 Logger
 Mwe 08cab4c5 d59ab9f4 09fbde4c          0 d59a9b80 7728/8192  Syslog Retry Thread
 Mwe 08ca511e d59adb9c 09fbde4c          0 d59abd08 7192/8192 Thread Logger
 Mwe 08e9c492 d59d83a4 09f492e8          0 d59d64c0 7040/8192 vpnlb_thread
 ...

そして、すべてのプロセスの”Runtime”列のdiffを実行することができます（プロセスが2回以上表示される可能性があることに注意してください）。

diffを最大から最小にソートすることで、CPUの大部分を使用しているプロセスを見つけることができます。 ASA 8.2で導入された show processes cpu-usage non-zero sorted コマンドを代わりに使用することもできます。

(訳者注釈：当コマンドを利用したトラブルシューティング方法は https://supportforums.cisco.com/t5/-/-/ta-p/3157321を参照してください。)

たとえば、場合によっては検査プロセスやロギングプロセスがCPUの大半を占めているのを見つけるかもしれません。このような場合、検査プロセスが必要ない時はそれを無効にしたり、ロギングレベルを下げたりして、デバイスのCPUを節約することができます。

"Dispatch_Unit"や "interface polling"のようなプロセスは、通常のパケット処理に関連しており、CPU軽減のためにできることはあまりないことに注意してください。

3.2 トラフィック

ファイアウォールに到達するトラフィックが過剰である場合は、必要なトラフィックだけをファイアウォールを介して送信することもできます。

このソリューションはほとんどのセットアップでは実用的ではありませんが、場合によってはトラフィックの代替ルートがあり、すべてのパケットを「ファイアウォール」で処理する必要がないことがあります。このような場合、ポリシーベースルーティング（PBR）を使用して、ファイアウォールを通過させる必要のあるトラフィックだけをファイアウォールに誘導することができます。

3.3 スループットの最適化

ASA5550およびASA5580では、I/Oブリッジを適切に活用することで、機器の最大スループットを最適化できる可能性があります。 ASA 5550と5580でそれを行うための詳細は、こちらをご覧ください。

3.4 フローコントロール

例えば、トラフィックが極めてバースト的(5ミリ秒間の5Gbpsのバーストなど)である場合、バーストがNICのFIFOバッファや受信リングバッファのバッファリング容量を超えると、パケットがドロップします。

フロー制御のためにPAUSEフレームを有効にすると、上流側のデバイスにバーストを「中断」させて、この問題を緩和することができます。フロー制御を有効にする方法の詳細は、こちらの対応するモデルの章を参照してください。

3.5 Active/ Active フェールオーバー

Active/Standby モードのフェールオーバー構成で、2つのファイアウォールを使用する場合、もしアクティブユニットがトラフィックを処理できない時は、アクティブ/アクティブ設定を一時的に使用して、両ユニット間でトラフィックを共有することができます。

ファイアウォールをマルチコンテキストモードにし、プライマリとセカンダリユニットで、それぞれ1つ以上のコンテキストをアクティブにする必要があります。そうすれば、両方のファイアウォールが（アクティブにしているコンテキストに対し）トラフィックを通過させ、過負荷を回避できる可能性があります。ただし、片方のユニットに障害が発生した場合は、すべてのコンテキスト（すなわち全てのトラフィック）が1つのユニットで実行され、その場合は過負荷シナリオに戻ってしまうことにご注意ください。

過負荷ケースのための Active/Active フェールオーバーは、使用する以上、恒久的な解決策が講じられるまでの一時的な解決策としてのみ用心して使われなければなりません。

3.6 ハードウェアの追加

最後に、究極の解決策は、自分のネットワークにハードウェアを追加するか、もしくはより多くのファイアウォールを使用することです。そうすれば、トラフィックを複数デバイスに分散させ処理させることができ、過負荷問題はなくなるでしょう。