На пограничных интернет-маршрутизаторах, поддерживающих eBGP с несколькими несущими и iBGP друг с другом, все интерфейсы на стороне LAN и WAN являются GE, за исключением одного Serial full-DS3 (~ 45 Мбит / с) на каждом маршрутизаторе. Хотя я думаю, что вряд ли я посылаю много трафика на последовательные интерфейсы - в диапазоне 3-10 Мбит / с - я вижу постоянные потери выходной очереди (OQD). Является ли вероятным объяснением того, что на самом деле существует интенсивный трафик, которого я не вижу, поскольку интервал загрузки составляет минимум 30 секунд, а опрос SNMP усредняет трафик в течение 5 минут, чтобы они не освещали пакетную передачу?
Платформа представляет собой Cisco 7204VXR NPE-G2. Серийная очередь - это fifo .
Serial1 / 0 установлен, линейный протокол включен
Аппаратное обеспечение M2T-T3 + pa
Описание: -removed-
Интернет-адрес abcd / 30
MTU 4470 байт, BW 44210 Кбит, DLY 200 мксек,
надежность 255/255, txload 5/255, rxload 1/255
Инкапсуляция HDLC, crc 16, петля не установлена
Набор Keepalive (10 секунд)
Перезапуск-Задержка составляет 0 секунд
Последний вход 00:00:02, выход 00:00:00, выход не зависает никогда
Последняя очистка счетчиков "show interface" 00:35:19
Входная очередь: 0/75/0/0 (размер / макс / сбрасывает / сбрасывает); Всего выпадений: 36
Стратегия очередей: fifo
Выходная очередь: 0/40 (размер / макс)
Скорость ввода 30 секунд 260000 бит / с, 208 пакетов / с
30-секундная скорость вывода 939000 бит / с, 288 пакетов / с
410638 входных пакетов, 52410388 байт, 0 без буфера
Получено 212 трансляций, 0 рантов, 0 гигантов, 0 дросселей
0 паритет
0 ошибок ввода, 0 CRC, 0 кадр, 0 переполнение, 0 игнорируется, 0 прерывается
Вывод 515752 пакетов, 139195019 байт, 0 опустошений
0 ошибок вывода, 0 аппликация, 0 сброс интерфейса
0 сбоев выходного буфера, 0 замененных выходных буферов
0 несущих переходов
rxLOS неактивен, rxLOF неактивен, rxAIS неактивен
txAIS неактивен, rxRAI неактивен, txRAI неактивен
24 часа спустя покажет тысячи OQD. Мы действительно увеличиваем трафик около 3 часов утра каждый день, так что, возможно, здесь есть какой-то шумный трафик, к которому я не придаю достаточного веса.
Last clearing of "show interface" counters 1d01h
Input queue: 0/75/0/158 (size/max/drops/flushes); Total output drops: 12049
Я бы хотел увеличить исходящий трафик на DS3, но не в связи с проблемой OQD. У провайдера 2-го уровня за DS3 есть POP, которые удваиваются как точки пиринга с 6+ уровнями 1, поэтому идея состоит в том, чтобы получить этот трафик внутри сети с клиентом как можно скорее, в отличие от нашего основного провайдера на GE, который является уровнем 1 , но должен пробиться к своим обменам. Входящий трафик не является проблемой.
Есть ли лучшая стратегия очередей, чем fifo в этой ситуации? Изучая документы Cisco по удалению входной и выходной очередей, увеличивать размер исходящей очереди не рекомендуется, поскольку пакеты уже находятся на маршрутизаторе, и было бы лучше отбросить при вводе, чтобы TCP мог отбросить приложение обратно. На наших GE-каналах достаточно пропускной способности, поэтому нет необходимости регулировать ввод. На этих роутерах нет политик-карт. 90% исходящего трафика поступает из наших HTTP-ответов; большая часть остальных из FTP и SMTP. Связи GE выдвигают 50-200 + Мбит / с.
Вы бы порекомендовали какие-либо корректировки буфера размера выходной очереди? Эти последовательные интерфейсы являются нашими резервными ссылками, которые я бы предпочел использовать больше по причине, указанной ранее (если она действительна), но в которой меняются мои политики BGP, которые пытаются не перегружать этот последовательный интерфейс (который в большинстве случаев выглядит сильно перегруженным).
OQD обычно вызваны одной из двух причин:
Вы перестали использовать ссылку; с постоянным интенсивным использованием или интенсивным трафиком.
У вас есть карта политик, примененная к интерфейсу, который настроен на что-то вроде применения политик или формирования части или всего трафика.
На интерфейсе есть какая-то ошибка, посмотрите на счетчики ошибок (
show interface Serial1/0 counters errors) и убедитесь, что пакеты не сбрасываются из-за ошибки.Вы можете посмотреть (если у вас его еще нет), чтобы создать карту политик, чтобы сделать такие вещи, как выделение критически важному трафику для своей миссии, включить предотвращение перегрузок при обычном трафике (WRED) или даже просто включить справедливую организацию очереди в трафике, чтобы что пропускная способность распределяется между потоками, проходящими через интерфейс.
Как вы упомянули, другой вариант - увеличить размер выходной очереди на интерфейсе, но если вы будете использовать карту политик, то в любом случае в этом не будет необходимости, так как политика создаст другие подпоследовательности.
источник