Şeffaf güvenlik duvarı paket kaybını bulma

19

Cisco ASA 5585'i bir layer2 saydam modunda kullanıyoruz. Yapılandırma, iş ortağımız dmz ve iç ağımız arasındaki iki 10GE bağlantısıdır. Basit bir harita şöyle görünür.

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

ASA 8.2 (4) ve SSP20'ye sahiptir. Anahtarlar 12.2 ile 6500 Sup2T'dir. Herhangi bir anahtar veya ASA arayüzünde paket damlası yoktur !! Anahtarlarımız arasındaki maksimum trafiğimiz yaklaşık 1.8Gbps'dir ve ASA'daki CPU yükü çok düşüktür.

Garip bir sorunumuz var. Nms yöneticimiz Haziran ayında başlayan çok kötü paket kaybı görüyor. Paket kaybı çok hızlı büyüyor, ancak nedenini bilmiyoruz. Güvenlik duvarı üzerinden trafik sabit kaldı, ancak paket kaybı hızla artıyor. Bunlar, güvenlik duvarı üzerinden gördüğümüz nagios ping hatalarıdır. Nagios her sunucuya 10 ping gönderir. Bazı arızalar tüm pingleri kaybeder, tüm başarısızlıklar on pingin tümünü kaybetmez.

resim açıklamasını buraya girin

Garip olan şey, nagios sunucusundan mtr kullanırsak, paket kaybının çok kötü olmamasıdır.

                             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

Anahtarlar arasında ping attığımızda, çok fazla paket kaybetmiyoruz, ancak sorunun anahtarlar arasında bir yerde başladığı açıktır.

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#

Arayüzlerde nasıl bu kadar çok ping hatası olabilir ve paket damlası olmaz? Sorunun nerede olduğunu nasıl bulabiliriz? Cisco TAC bu sorunla ilgili daireler çiziyor, birçok farklı anahtardan gösteri teknolojisi istiyorlar ve sorunun core01 ve dmzsw arasında olduğu açık. Birisi yardımcı olabilir mi?

Güncelleme 30 Temmuz 2013

Sorunu bulmama yardım ettiği için herkese teşekkürler. Bir seferde yaklaşık 10 saniye boyunca çok sayıda küçük UDP paketi gönderen hatalı çalışan bir uygulamadır. Bu paketler güvenlik duvarı tarafından reddedildi. Yöneticim ASA'mızı yükseltmek istiyor gibi görünüyor, bu yüzden bu sorunu tekrar yaşamıyoruz.

Daha fazla bilgi

Yorumlardaki sorulardan:

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
kaynak
Trafik seviyeleri zirveye çıktığında paket kaybı çakışıyor mu? bu ortam bundan önce hiç sorun çıkarmadı mı? şu ana kadar sorun gidermek için neler yapıldı?
— DrBru
Trafik seviyeleri önemli değil. Paket kaybı, güvenlik duvarından gelen trafik düşük veya yüksek olduğunda meydana gelir. Bir hafta boyunca TAC ile açık bir vakamız var ve herhangi bir arayüzde paket kaybı bulamıyorlar. Anahtarlarda veya güvenlik duvarında CPU sorunu yok. Neredeyse bir yıl boyunca dmz vardı ve paket kaybı sadece geçen ay başladı.
— user2096
Merhaba dostum, İki ASA arabiriminden birinde IPS etkin mi? Sanırım suçlu bulabiliriz.
— laf
2
Mtr bilgisine dayanarak ve sorunsuz bir şekilde anahtarlar arasında ping atabileceğinizi, sorunun core1 anahtarınız ve nms'nize doğru bir sonraki atlaması arasında olduğunu öneririm.
— Santino
2
@Santino, bunun core01'in akış yukarısında mı yoksa dmzsw arasında bir yerde mi olduğunu söylemek erken. user2096, lütfen güvenlik duvarının çıktısını show interface detail | i ^Interface|overrun|errorve show resource usagegüvenlik duvarını gönderin
— Mike Pennington

Yanıtlar:

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

Gösterebilir taşmaları böylece, DahiliVeriler arayüzleri üzerinde olan ASA üzerinden trafik bırakarak. Bu kadar damla ile, bunun soruna katkıda bulunduğunu hayal etmek zor değil. Dahili Rx FIFO kuyrukları taştığında taşmalar meydana gelir (normalde yük ile ilgili bir sorun nedeniyle).

Yorumlardaki bir soruya yanıt vermek için DÜZENLE :

Güvenlik duvarının neden aşırı yüklendiğini anlamıyorum, 10Gbps kullanmaya yakın değil. İşlemci ve bant genişliği düşük olsa bile neden taşmalar gördüğümüzü açıklayabilir misiniz? CPU yaklaşık% 5'tir ve her iki yönde bant genişliği asla 1.4Gbps'den daha yüksek değildir.

Bir bağlantının, cihazın bant genişliğini, saniyede bağlantıyı veya saniyede paket başına beygir gücünü aşan trafik mikro patlamaları gördüğünde bunu tekrar tekrar gördüm . Pek çok kişi 1 veya 5 dakikalık istatistikleri, trafik bu zaman diliminde göreceli olarak sabit gibi gösteriyor.

Bu komutları iki veya üç saniyede bir çalıştırarak güvenlik duvarınıza bir göz atarım ( term pager 0çağrı sorunlarını önlemek için çalıştırın ) ...

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

Şimdi her birkaç saniyede bir ne kadar trafiği düşürdüğünüze bakın; trafiğiniz arttığında politika düşüşlerinde veya fazlalıklarda büyük artışlar görürseniz, suçluyu bulmaya daha yakınsınız demektir.

ASA'yı neyin öldürdüğünü belirleme konusunda yardıma ihtiyacınız olursa, bununla doğrudan ASA'yı koklayabileceğinizi unutmayın ... bunu bazen yakalamak için hızlı olmalısınız.

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

Yukarı akış anahtarlarınızdaki ağ akışı da yardımcı olabilir.

— Mike Pennington
kaynak
tatlı! 'show int detail' hakkında bilgi için teşekkürler, ~
— Nachos
Dahili veri taşmaları çok hızlı bir şekilde artıyor, bu yüzden sorun gibi görünüyor. AMA Güvenlik duvarının neden aşırı yüklendiğini anlamıyorum, 10Gbps kullanmaya yakın değil. İşlemci ve bant genişliği düşük olsa bile neden taşmalar gördüğümüzü açıklayabilir misiniz? CPU yaklaşık% 5'tir ve her iki yönde bant genişliği asla 1.4Gbps'den daha yüksek değildir.
— user2096
@ user2096, yanıt vermek için cevabımı düzenledim ...
— Mike Pennington
Bu mantıklı görünmüyor - 10GE girişi ve 10GE çıkışı olan şeffaf bir güvenlik duvarı. Dahili veri yolu 10GE için derecelendirilmedi mi? Bir ürün tasarım hatası gibi görünüyor.
— nikotin
2
@nicotine, OP bir SSP-20 satın aldı ve SSP-20 dahili olarak 5Gbps'den fazla olmayacaktır (ref Cisco Veri Sayfası ). Tam bir 10Gbps güvenlik duvarı istiyorsanız, başka bir seçenek satın almanız gerekir (belki de CPS bir sorunsa SSP-60 bile). Bu, yalnızca kutunun dahili tamponlama kapasitesini aşarsanız bir tasarım hatasıdır. 10GE'li bir SSP-20'nin iyi olduğu kullanım durumlarını gördüm.
— Mike Pennington
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.