Menemukan hilangnya paket firewall transparan

19

Kami menggunakan Cisco ASA 5585 dalam mode transparan layer2. Konfigurasi ini hanya dua tautan 10GE antara dmz mitra bisnis kami dan jaringan di dalam kami. Peta sederhana terlihat seperti ini.

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

ASA memiliki 8.2 (4) dan SSP20. Switch adalah 6500 Sup2T dengan 12.2. Tidak ada paket drop pada switch atau antarmuka ASA !! Lalu lintas maksimum kami adalah sekitar 1,8Gbps antara sakelar dan beban CPU pada ASA sangat rendah.

Kami punya masalah aneh. Admin nms kami melihat hilangnya paket yang sangat buruk yang dimulai sekitar bulan Juni. Paket loss tumbuh sangat cepat, tetapi kita tidak tahu mengapa. Lalu lintas melalui firewall tetap konstan, tetapi packet loss tumbuh dengan cepat. Ini adalah kegagalan ping nagios yang kita lihat melalui firewall. Nagios mengirim 10 ping ke setiap server. Beberapa kegagalan kehilangan semua ping, tidak semua kegagalan kehilangan semua ping.

masukkan deskripsi gambar di sini

Yang aneh adalah bahwa jika kita menggunakan mtr dari server nagios, paket loss tidak terlalu buruk.

                             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

Ketika kita melakukan ping di antara switch, kita tidak kehilangan banyak paket, tetapi jelas masalahnya dimulai di suatu tempat di antara switch.

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#

Bagaimana kita bisa mengalami begitu banyak kegagalan ping dan tidak ada paket drop pada interface? Bagaimana kita dapat menemukan di mana masalahnya? Cisco TAC akan berputar-putar pada masalah ini, mereka terus meminta teknologi acara dari begitu banyak switch yang berbeda dan jelas bahwa masalahnya adalah antara core01 dan dmzsw. Adakah yang bisa membantu?

Pembaruan 30 Juli 2013

Terima kasih kepada semua orang karena membantu saya menemukan masalah. Itu adalah aplikasi yang keliru yang mengirim banyak paket UDP kecil selama sekitar 10 detik setiap kalinya. Paket-paket ini ditolak oleh firewall. Sepertinya manajer saya ingin meningkatkan ASA kami sehingga kami tidak memiliki masalah ini lagi.

Informasi Lebih Lanjut

Dari pertanyaan di komentar:

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 
— pengguna2096
sumber
Apakah paket loss bertepatan dengan ketika tingkat lalu lintas memuncak? Pernahkah lingkungan ini terbebas dari masalah ini sebelumnya? apa yang telah dilakukan untuk memecahkan masalah sejauh ini?
— DrBru
Tingkat lalu lintas tidak masalah. Paket loss terjadi ketika lalu lintas melalui firewall rendah atau tinggi. Kami memiliki kasing terbuka dengan TAC selama seminggu dan mereka tidak dapat menemukan packet loss pada antarmuka apa pun. Tidak ada masalah CPU pada sakelar atau firewall. Kami memiliki dmz selama hampir satu tahun dan paket loss baru dimulai pada sekitar sebulan terakhir.
— user2096
Hai sobat, Apakah IPS Anda diaktifkan di salah satu dari dua antarmuka ASA? Saya percaya di sana kita mungkin menemukan pelakunya.
— laf
2
Berdasarkan info mtr, dan Anda dapat melakukan ping antar switch tanpa masalah, saya akan menawarkan bahwa masalahnya adalah antara switch core1 Anda dan lompatan berikutnya ke nms Anda.
— Santino
2
@ Santino, masih terlalu dini untuk mengatakan apakah ini kehilangan inti dari core01, atau di suatu tempat antara itu dan dmzsw. user2096, silakan posting output show interface detail | i ^Interface|overrun|errordan show resource usagepada firewall
— Mike Pennington

Jawaban:

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

Anda menunjukkan overruns pada interface InternalData, sehingga Anda akan menjatuhkan lalu lintas melalui ASA. Dengan begitu banyak tetes, tidak sulit untuk membayangkan bahwa ini berkontribusi pada masalah. Overruns terjadi ketika antrian Rx FIFO internal meluap (biasanya karena beberapa masalah dengan beban).

EDIT untuk menanggapi pertanyaan di komentar :

Saya tidak mengerti mengapa firewall kelebihan beban, tidak dekat dengan menggunakan 10Gbps. Bisakah Anda menjelaskan mengapa kami melihat kelebihan bahkan ketika CPU dan bandwidth rendah? CPU adalah sekitar 5% dan bandwidth kedua arah tidak pernah berjalan jauh lebih tinggi dari 1.4Gbps.

Saya telah melihat ini terjadi berulang kali ketika sebuah tautan melihat arus mikro , yang melebihi bandwidth, koneksi per detik, atau tenaga kuda paket per detik perangkat. Begitu banyak orang mengutip statistik 1 atau 5 menit seolah-olah lalu lintas relatif konstan dalam jangka waktu itu.

Saya akan melihat firewall Anda dengan menjalankan perintah ini setiap dua atau tiga detik (lari term pager 0untuk menghindari masalah paging) ...

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

Sekarang grafik berapa banyak lalu lintas yang Anda lihat setiap beberapa detik vs tetes; jika Anda melihat lonjakan besar dalam polis turun atau overruns ketika lalu lintas Anda lonjakan, maka Anda lebih dekat untuk menemukan pelakunya.

Jangan lupa bahwa Anda dapat mengendus ASA langsung dengan ini jika Anda perlu bantuan mengidentifikasi apa yang membunuh ASA ... Anda harus cepat menangkap ini kadang-kadang.

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

Netflow pada switch hulu Anda dapat membantu juga.

— Mike Pennington
sumber
manis! thanx untuk info tentang 'show int detail' ~
— Nachos
Overruns internaldata kami meningkat dengan sangat cepat, jadi ini sepertinya masalahnya. TETAPI saya tidak mengerti mengapa firewall kelebihan beban, tidak dekat dengan menggunakan 10Gbps. Bisakah Anda menjelaskan mengapa kami melihat kelebihan bahkan ketika CPU dan bandwidth rendah? CPU adalah sekitar 5% dan bandwidth kedua arah tidak pernah berjalan jauh lebih tinggi dari 1.4Gbps.
— user2096
@ user2096, saya mengedit jawaban saya untuk merespons ...
— Mike Pennington
Ini tampaknya tidak masuk akal - ini adalah firewall transparan, dengan 10GE masuk, dan 10GE keluar. Datapath internal tidak diberi peringkat untuk 10GE? Sepertinya kegagalan desain produk.
— nikotin
2
@nicotine, OP membeli SSP-20 dan SSP-20 secara internal terbatas tidak lebih dari 5Gbps (ref Cisco Data Sheet ). Jika Anda menginginkan firewall 10Gbps penuh, Anda harus membeli opsi lain (mungkin bahkan SSP-60, jika CPS merupakan masalah). Ini hanya kegagalan desain jika Anda melebihi kapasitas buffering internal kotak. Saya telah melihat kasus penggunaan di mana SSP-20 dengan 10GE baik-baik saja.
— Mike Pennington
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.