Поиск прозрачной потери пакетов брандмауэра
Мы используем 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 писем каждому серверу. Некоторые из неудач освобождают все пины, не все отказы теряют все десять пинов.
![введите описание изображения здесь>> </p>
<p> Странно то, что если мы используем mtr с сервера nagios, потеря пакетов не очень плохая. </p>
<pre><code>My traceroute [v0.75]
nagios (0.0.0.0) Пт Июл 19 03:43:38 2013
Клавиши: Справка Режим отображения Перезагрузка статистики Порядок полей закрыт
Пакеты Pings
Хост-урон% Snt Drop Последний Лучший 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-сервер 1,1% 1246 13 0,6 0,5 0,6 1,6 0,2
</code></pre>
<p> Когда мы ping между коммутаторами, мы не теряем много пакетов, но очевидно, что проблема начинается где-то между коммутаторами. </p>
<pre><code>core01 # ping ip 10.4.2.10 repeat 500000
Введите escape-последовательность для отмены.
Отправка 500000, 100-байтных ICMP Echos до 10.4.2.10, тайм-аут составляет 2 секунды:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!
Показатель успеха - 99% (499993/500000), мин. /Авг /макс = 1/2/6 мс
core01 #
</code></pre>
<p> Как у нас может быть так много ошибок ping и никаких пакетов не падает на интерфейсы? Как мы можем найти, где проблема? Cisco TAC собирается в кругах по этой проблеме, они продолжают просить шоу-технологии из множества разных коммутаторов, и очевидно, что проблема связана с core01 и dmzsw. Может кто-нибудь помочь? </p>
<p> <strong> Обновление 30 июля 2013 г. </strong> </p>
<p> Спасибо всем, кто помог мне найти проблему. Это было неправильное приложение, которое отправляло множество небольших UDP-пакетов в течение примерно 10 секунд за раз. Эти пакеты были запрещены брандмауэром. Похоже, мой менеджер хочет обновить нашу ASA, чтобы у нас снова не было этой проблемы. </p>
<p> <strong> Дополнительная информация </strong> </p>
<p> Из вопросов в комментариях: </p>
<pre><code>ASA1 # показать inter detail | i ^ Ошибка интерфейса | переполнение |
Интерфейс GigabitEthernet0 /0](https://i.stack.imgur.com/nKyU4.png)
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 на ваших восходящих коммутаторах также может помочь.