Нахождение прозрачной потери пакетов межсетевого экрана

Мы используем Cisco ASA 5585 в прозрачном режиме layer2. Конфигурация - это всего лишь два канала 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 ping, которые мы видим через брандмауэр. 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#

Как у нас может быть так много сбоев ping и без отбрасывания пакетов на интерфейсах? Как мы можем найти, где проблема? Центр технической поддержки Cisco обсуждает эту проблему, они продолжают требовать передачи технологий от стольких различных коммутаторов, и очевидно, что проблема заключается в 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
источник

Совпадает ли потеря пакетов с пиковыми уровнями трафика? была ли эта среда бесплатной до этого? что было сделано для устранения неполадок до сих пор?

DrBru

Уровни трафика не имеют значения. Потеря пакета происходит, когда трафик через межсетевой экран низкий или высокий. У нас есть дело, открытое с TAC в течение недели, и они не могут найти потерю пакетов на любом интерфейсе. Нет проблем с процессором на коммутаторах или брандмауэре. У нас был dmz почти год, а потеря пакетов началась только в прошлом месяце или около того.

user2096

Привет, приятель, у тебя IPS включен на любом из двух интерфейсов ASA? Я верю, что мы могли бы найти виновника.

Лаф

На основании информации mtr и того, что вы можете пинговать между коммутаторами без проблем, я бы предложил, чтобы проблема была между вашим коммутатором core1 и его следующим переходом к вашей nms.

Сантино

@ Сантино, преждевременно говорить, является ли это потерей до core01 или где-то между ним и dmzsw. user2096, пожалуйста, опубликуйте вывод show interface detail | i ^Interface|overrun|errorи show resource usageна брандмауэре

Майк Пеннингтон,

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 (обычно из-за проблем с нагрузкой).

РЕДАКТИРОВАТЬ, чтобы ответить на вопрос в комментариях :

Я не понимаю, почему брандмауэр перегружен, он не близок к использованию 10 Гбит / с. Можете ли вы объяснить, почему мы наблюдаем переполнение даже при низкой загрузке процессора и пропускной способности? Процессор составляет около 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 на ваших вышестоящих коммутаторах также может помочь.

Майк Пеннингтон
источник

сладкий! Спасибо за информацию о 'show int detail' ~

Nachos

Наши переполнения внутренних данных увеличиваются очень быстро, поэтому это похоже на проблему. НО я не понимаю, почему брандмауэр перегружен, это не близко к использованию 10 Гбит / с. Можете ли вы объяснить, почему мы наблюдаем переполнение даже при низкой загрузке процессора и пропускной способности? Процессор составляет около 5%, а полоса пропускания в обоих направлениях никогда не идет намного выше, чем 1,4 Гбит / с.

user2096

@ user2096, я отредактировал свой ответ, чтобы ответить ...

Майк Пеннингтон

Похоже, это не имеет смысла - это прозрачный брандмауэр с входом 10GE и выходом 10GE. Внутренний канал данных не рассчитан на 10GE? Похоже, провал дизайна продукта.

никотин

@nicotine, OP приобрел SSP-20, а SSP-20 внутренне ограничен скоростью не более 5 Гбит / с (см. Лист данных Cisco ). Если вам нужен полноценный брандмауэр со скоростью 10 Гбит / с, вам нужно приобрести другой вариант (возможно, даже SSP-60, если проблема в CPS). Это только ошибка проекта, если вы превысили внутреннюю буферную емкость блока. Я видел случаи использования, когда SSP-20 с 10GE в порядке.

Майк Пеннингтон

Нахождение прозрачной потери пакетов межсетевого экрана

Ответы: