Поиск прозрачной потери пакетов брандмауэра
Мы используем 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 admin видит очень плохую потерю пакетов, которая началась где-то в июне. Потеря пакетов растет очень быстро, но мы не знаем почему. Трафик через брандмауэр оставался постоянным, но потеря пакетов быстро растет. Это ошибки nagios ping, которые мы видим через брандмауэр. Nagios отправляет 10 писем каждому серверу. Некоторые из неудач освобождают все пины, не все отказы теряют все десять пинов.
1 ответ
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 ответить на вопрос в комментариях :
Я не понимаю, почему брандмауэр перегружен, он не близок к использованию 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 на ваших восходящих коммутаторах также может помочь.