透過ファイアウォールのパケット損失を見つける

19

レイヤ2トランスペアレントモードでCisco ASA 5585を使用します。構成は、ビジネスパートナーdmzと内部ネットワークの間の2つの10GEリンクのみです。シンプルなマップは次のようになります。

10.4.2.9/30                    10.4.2.10/30
core01-----------ASA1----------dmzsw

ASAには8.2（4）およびSSP20があります。スイッチは、12.2を備えた6500 Sup2Tです。スイッチまたはASAインターフェイスでのパケットドロップはありません!! スイッチ間の最大トラフィックは約1.8Gbpsで、ASAのCPU負荷は非常に低くなっています。

奇妙な問題があります。nms管理者は、6月に開始された非常に悪いパケット損失を見ています。パケット損失は非常に急速に増加していますが、その理由はわかりません。ファイアウォールを通過するトラフィックは一定のままですが、パケット損失は急速に増加しています。これらは、ファイアウォールを介して発生するnagios pingの失敗です。Nagiosは、すべてのサーバーに10のpingを送信します。一部の障害ではすべてのpingが失われますが、すべての障害で10個のpingがすべて失われるわけではありません。

ここに画像の説明を入力してください

奇妙なことは、nagiosサーバーからmtrを使用する場合、パケット損失はそれほど悪くないということです。

                             My traceroute  [v0.75]
nagios    (0.0.0.0)                                    Fri Jul 19 03:43:38 2013
Keys:  Help   Display mode   Restart statistics   Order of fields   quit
                                  Packets               Pings
 Host                           Loss%   Snt Drop   Last  Best   Avg  Wrst StDev
 1. 10.4.61.1                    0.0%  1246    0    0.4   0.3   0.3  19.7   1.2
 2. 10.4.62.109                  0.0%  1246    0    0.2   0.2   0.2   4.0   0.4
 3. 10.4.62.105                  0.0%  1246    0    0.4   0.4   0.4   3.6   0.4
 4. 10.4.62.37                   0.0%  1246    0    0.5   0.4   0.7  11.2   1.7
 5. 10.4.2.9                     1.3%  1246   16    0.8   0.5   2.1  64.8   7.9
 6. 10.4.2.10                    1.4%  1246   17    0.9   0.5   3.5 102.4  11.2
 7. dmz-server                   1.1%  1246   13    0.6   0.5   0.6   1.6   0.2

スイッチ間でpingを実行すると、多くのパケットが失われることはありませんが、スイッチ間のどこかで問題が発生することは明らかです。

core01#ping ip 10.4.2.10 repeat 500000

Type escape sequence to abort.
Sending 500000, 100-byte ICMP Echos to 10.4.2.10, timeout is 2 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 99 percent (499993/500000), round-trip min/avg/max = 1/2/6 ms
core01#

どのようにして、多くのpingエラーが発生し、インターフェイスでパケットがドロップされないのでしょうか？問題がどこにあるのかを見つけるにはどうすればよいですか？Cisco TACはこの問題について円を描いており、非常に多くの異なるスイッチからshow techを求め続けており、問題がcore01とdmzswの間にあることは明らかです。誰か助けてもらえますか？

2013年7月30日更新

問題の発見にご協力いただき、ありがとうございます。一度に約10秒間、大量の小さなUDPパケットを送信する不正な動作をするアプリケーションでした。これらのパケットはファイアウォールによって拒否されました。私のマネージャーはASAをアップグレードしたいので、この問題は二度とありません。

詳しくは

コメントの質問から：

ASA1# show inter detail | i ^Interface|overrun|error
Interface GigabitEthernet0/0 "", is administratively down, line protocol is down
        0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
        0 output errors, 0 collisions, 0 interface resets
Interface GigabitEthernet0/1 "", is administratively down, line protocol is down
        0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
        0 output errors, 0 collisions, 0 interface resets
Interface GigabitEthernet0/2 "", is administratively down, line protocol is down
        0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
        0 output errors, 0 collisions, 0 interface resets
Interface GigabitEthernet0/3 "", is administratively down, line protocol is down
        0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
        0 output errors, 0 collisions, 0 interface resets
Interface GigabitEthernet0/4 "", is administratively down, line protocol is down
        0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
        0 output errors, 0 collisions, 0 interface resets
Interface GigabitEthernet0/5 "", is administratively down, line protocol is down
        0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
        0 output errors, 0 collisions, 0 interface resets
Interface GigabitEthernet0/6 "", is administratively down, line protocol is down
        0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
        0 output errors, 0 collisions, 0 interface resets
Interface GigabitEthernet0/7 "", is administratively down, line protocol is down
        0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
        0 output errors, 0 collisions, 0 interface resets
Interface Internal-Data0/0 "", is up, line protocol is up
     2749335943 input errors, 0 CRC, 0 frame, 2749335943 overrun, 0 ignored, 0 abort
         0 output errors, 0 collisions, 0 interface resets
           RX[00]: 156069204310 packets, 163645512578698 bytes, 0 overrun
           RX[01]: 185159126458 packets, 158490838915492 bytes, 0 overrun
           RX[02]: 192344159588 packets, 197697754050449 bytes, 0 overrun
           RX[03]: 173424274918 packets, 196867236520065 bytes, 0 overrun
Interface Internal-Data1/0 "", is up, line protocol is up
    26018909182 input errors, 0 CRC, 0 frame, 26018909182 overrun, 0 ignored, 0 abort
    0 output errors, 0 collisions, 0 interface resets
           RX[00]: 194156313803 packets, 189678575554505 bytes, 0 overrun
           RX[01]: 192391527307 packets, 184778551590859 bytes, 0 overrun
           RX[02]: 167721770147 packets, 179416353050126 bytes, 0 overrun
           RX[03]: 185952056923 packets, 205988089145913 bytes, 0 overrun
Interface Management0/0 "Mgmt", is up, line protocol is up
        0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
        0 output errors, 0 collisions, 0 interface resets
Interface Management0/1 "", is administratively down, line protocol is down
        0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
        0 output errors, 0 collisions, 0 interface resets
Interface TenGigabitEthernet0/8 "Inside", is up, line protocol is up
        0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
        0 output errors, 0 collisions, 0 interface resets
Interface TenGigabitEthernet0/9 "DMZ", is up, line protocol is up
        0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
        0 output errors, 0 collisions, 0 interface resets

ASA1#
cisco  switch  cisco-asa  firewall  packet-loss 
— user2096
ソース
パケット損失は、トラフィックレベルがピークに達したときに一致しますか？この環境はこれまでに無料で発行されたことがありますか？これまでトラブルシューティングするために何が行われましたか？
— DrBru
トラフィックレベルは関係ありません。ファイアウォールを通過するトラフィックが低または高の場合、パケット損失が発生します。TACで1週間のケースを開いており、どのインターフェイスでもパケット損失を見つけることができません。スイッチまたはファイアウォールでCPUに問題はありません。ほぼ1年間dmzを使用していましたが、パケット損失は先月かそこらでのみ始まりました。
— user2096
こんにちは、2つのASAインターフェイスのいずれかでIPSが有効になっていますか？犯人を見つけるかもしれないと信じています。
— ラフ
2
mtr情報に基づいて、問題なくスイッチ間でpingできることから、問題はcore1スイッチとnmsへの次のホップの間にあると申し上げます。
— サンティーノ
2
@Santino、これがcore01の上流での損失なのか、それともdmzswの間の損失なのかを言うのは時期尚早です。user2096の出力を投稿してくださいshow interface detail | i ^Interface|overrun|errorし、show resource usageファイアウォール上
— マイク・ペニントン

回答:

8 
Interface Internal-Data0/0 "", is up, line protocol is up
     2749335943 input errors, 0 CRC, 0 frame, 2749335943 overrun, 0 ignored, 0 abort
                                              ^^^^^^^^^^^^^^^^^^
         0 output errors, 0 collisions, 0 interface resets

あなたは示してオーバーラン InternalDataインターフェイス上を、あなたがしている ASAを通過するトラフィックをドロップします。多くのドロップがあるため、これが問題の原因であると想像するのは難しくありません。オーバーランは、内部Rx FIFOキューがオーバーフローしたときに発生します（通常、負荷の問題が原因です）。

コメント内の質問に応答するために編集します。

ファイアウォールが過負荷になっている理由がわかりません。10Gbpsを使用することには近づいていません。CPUと帯域幅が低い場合でもオーバーランが発生する理由を説明できますか？CPUは約5％であり、いずれの方向の帯域幅も1.4Gbpsを超えることはありません。

リンクでトラフィックのマイクロバーストが発生し、デバイスの帯域幅、1秒あたりの接続、または1秒あたりのパケット馬力のいずれかを超えると、これが繰り返し発生します。そのため、多くの人は、1時間または5分の統計を引用して、その時間枠全体でトラフィックが比較的一定であるかのように引用します。

これらのコマンドを2〜3秒ごとに実行して、ファイアウォールを調べます（term pager 0ページングの問題を回避するために実行します）...

show clock
show traffic detail | i ^[a-zA-Z]|overrun|packets dropped
show asp drop

次に、数秒ごとに表示されるトラフィックとドロップのグラフを作成します。トラフィックが急増したときにポリシーのドロップまたはオーバーランが大幅に急増した場合は、原因の特定に近づいています。

何がASAを殺しているのかを特定するのに助けが必要な場合、これでASAを直接探ることができることを忘れないでください。

capture FOO circular-buffer buffer <buffer-size> interface <intf-name>

アップストリームスイッチのNetflowも役立ちます。

— マイク・ペニントン
ソース
甘い！'show int detail'に関する情報をお寄せください〜–
— ナチョス
内部データのオーバーランは非常に急速に増加しているため、これは問題のように見えます。しかし、なぜファイアウォールが過負荷になっているのかはわかりません。10Gbpsを使用することには近づいていません。CPUと帯域幅が低い場合でもオーバーランが発生する理由を説明できますか？CPUは約5％であり、どちらの方向の帯域幅も1.4Gbpsを超えることはありません。
— user2096
user2096 @、私は...応答するために私の答えを編集した
— マイク・ペニントン
これは理にかなっていないように見えます-それは透過的なファイアウォールで、10GEが入っており、10GEが出ています。内部データパスは10GEに対応していませんか？製品設計の失敗のようです。
— ニコチン
2
@ nicotine、OPはSSP-20を購入し、SSP-20は内部で5Gbpsに制限されています（Ciscoデータシートを参照）。完全な10Gbpsファイアウォールが必要な場合は、別のオプションを購入する必要があります（CPSが問題である場合は、おそらくSSP-60も）。ボックスの内部バッファリング容量を超えた場合にのみ、設計が失敗します。10GEのSSP-20で問題ないユースケースを見てきました。
— マイクペニントン
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.