Знаходження прозорих втрат пакету брандмауера

19

Ми використовуємо Cisco ASA 5585 у прозорому режимі шару2. Конфігурація - це лише два 10GE зв’язку між нашим діловим партнером dmz та внутрішньою мережею. Проста карта виглядає приблизно так.

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

ASA має 8.2 (4) та SSP20. Вимикачі 6500 Sup2T з 12.2. На жодному комутаторі чи інтерфейсі ASA немає крапель пакетів !! Наш максимальний трафік становить близько 1,8 Гбіт / с між перемикачами, а завантаження процесора на ASA дуже низьке.

У нас є дивна проблема. Наш адміністратор nms бачить дуже погані втрати пакетів, які почалися десь у червні. Втрати пакетів зростають дуже швидко, але ми не знаємо чому. Трафік через брандмауер залишається постійним, але втрата пакетів швидко зростає. Це невдачі нагіо пінг, які ми бачимо через брандмауер. Nagios надсилає 10 пінг на кожен сервер. Деякі збої втрачають усі пінгви, не всі провали втрачають усі десять пінг.

введіть тут опис зображення

Дивна річ у тому, що якщо ми використовуємо mtr з nagios-сервера, втрата пакету не дуже погана.

                             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

Коли ми пінтуємо між перемикачами, ми не втрачаємо багато пакетів, але очевидно, що проблема починається десь між комутаторами.

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#

Як ми можемо мати стільки відмов пінгу і жодних крапель пакетів на інтерфейсах? Як ми можемо знайти де проблема? Проблема Cisco TAC проходить по колу з цією проблемою, вони продовжують просити шоу-технологій з такої кількості різних комутаторів, і очевидно, що проблема полягає в core01 та dmzsw. Може хтось допоможе?

Оновлення 30 липня 2013 року

Дякую всім за те, що допомогли мені знайти проблему. Це була недоброзичлива програма, яка надсилала багато невеликих пакетів UDP протягом приблизно 10 секунд одночасно. Ці пакети брандмауером було відмовлено. Схоже, мій менеджер хоче модернізувати наш 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
джерело
Чи збігаються втрати пакетів, коли рівень трафіку досягає піку? це середовище коли-небудь було випущено до цього? що було зроблено для усунення несправностей поки що?
— ДрБру
Рівень руху не має значення. Втрати пакету трапляються, коли трафік через брандмауер низький або високий. Ми працюємо з TAC упродовж тижня, і вони не можуть знайти втрати пакету в жодному інтерфейсі. Немає проблем з процесором на комутаторах або брандмауері. У нас був dmz майже рік, а втрата пакету почалася лише в останній місяць.
— користувач2096
Привіт друже, у вас включений IPS на будь-якому з двох інтерфейсів ASA? Я вірю, що там ми можемо знайти винуватця.
— laf
2
Виходячи з інформації про mtr, і що ви можете пінговувати між перемикачами без проблем, я б запропонував, що проблема полягає між вашим перемикачем 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 переповнюються (як правило, через певну проблему із завантаженням).

EDIT, щоб відповісти на запитання в коментарях :

Я не розумію, чому брандмауер перевантажений, він не близький до використання 10Gbps. Чи можете ви пояснити, чому ми спостерігаємо перевищення, навіть коли процесор і пропускна здатність низькі? Процесор складає близько 5%, а смуга пропускання в будь-якому напрямку ніколи не перевищує 1,4 Гбіт / с.

Я бачив, як це трапляється знову і знову, коли посилання бачить мікроперешкоди трафіку , які перевищують або смугу пропускання, з'єднання в секунду, або пакетну секунду в кінських силах пристрою. Так багато людей цитують статистику за 1 або 5 хвилин, ніби трафік є відносно постійним протягом цього часового періоду.

Я перегляну ваш брандмауер, виконуючи ці команди кожні дві-три секунди (запустіть, 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 на ваших комутаторах.

— Майк Пеннінгтон
джерело
солодкий! подякуємо за інформацію про «показати детальну інформацію» ~
— Nachos
Наші перевиконання внутрішніх даних збільшуються дуже швидко, тому це виглядає як проблема. Але я не розумію, чому брандмауер перевантажений, він не близький до використання 10Gbps. Чи можете ви пояснити, чому ми спостерігаємо перевищення, навіть коли процесор і пропускна здатність низькі? Процесор складає близько 5%, а смуга пропускання в будь-якому напрямку ніколи не перевищує 1,4 Гбіт / с.
— user2096
@ user2096, я змінив свою відповідь, щоб відповісти ...
— Майк Пеннінгтон,
Здається, це не має сенсу - це прозорий брандмауер, 10 В і 10 ГЕ. Внутрішній шлях даних не оцінюється як 10GE? Схоже, невдача дизайну продукту.
— нікотин
2
@nicotine, ОП придбав SSP-20, а SSP-20 внутрішньо обмежений не більше ніж 5 Гбіт / с (посилання Cisco Data Sheet ). Якщо ви хочете отримати повний брандмауер 10 Гбіт / с, вам доведеться придбати інший варіант (можливо, навіть SSP-60, якщо проблема з CPS). Це лише недолік конструкції, якщо ви перевищуєте внутрішню буферну ємність коробки. Я бачив випадки використання, коли SSP-20 з 10GE добре.
— Майк Пеннінгтон
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.