Выходные капли по последовательному интерфейсу: лучший порядок очередей или размер очереди вывода?

В пограничных маршрутизаторах Интернета, говорящих на eBGP, с несколькими несущими и iBGP друг с другом, все интерфейсы на стороне ЛВС и WAN являются GE, за исключением одного последовательного полного DS3 (~ 45 Мбит /с) на каждом маршрутизаторе. Хотя я думаю, что вряд ли отправляю много трафика на последовательные интерфейсы - в диапазоне 3-10 Мбит /с - я вижу постоянное падение очереди вывода (OQD). Является вероятным объяснением того, что на самом деле существует интенсивный трафик. . Я не вижу, что интервал загрузки составляет минимум 30 секунд, а опрос SNMP усредняет трафик в течение 5 минут, поэтому они не будут освещать пакетирования?

Платформа - это Cisco 7204VXR NPE-G2. Последовательная очередность fifo .

Serial1 /0 вверх, линейный протокол завершен
  Аппаратное обеспечение - M2T-T3 + pa
  Описание: -removed-
  Интернет-адрес: a.b.c.d /30
  MTU 4470 байт, BW 44210 Кбит, DLY 200 мкс,
     надежность 255/255, txload 5/255, rxload 1/255
  Инкапсуляция HDLC, crc 16, петля не установлена
  Keepalive set (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 часа ночи, поэтому, возможно, здесь есть несколько интенсивных трат, и я не придаю им достаточного веса.

  Последняя очистка счетчиков «show interface» 1d01h
Входная очередь: 0/75/0/158 (размер /макс /капли /сбрасывание); Общий выход: 12049
 

Я хотел бы увеличить количество исходящего трафика на DS3, но не с моей заботой о OQD. ISP уровня 2 позади DS3 имеет POP, которые удваиваются как точки пиринга с 6+ уровнями 1, поэтому идея состоит в том, чтобы получить этот трафик в сети с клиентом как можно скорее, в отличие от нашего основного провайдера на GE, который является уровнем 1 , но должны прокладывать себе путь к их обмену мнениями. Входящий трафик не вызывает беспокойства.

Есть ли лучшая стратегия очередей, чем fifo в этой ситуации? Взгляд на документы Cisco по вводу & amp; выходная очередь очереди, увеличение размера исходящей очереди не рекомендуется, поскольку пакеты уже находятся на маршрутизаторе, и было бы лучше отказаться от ввода, чтобы TCP мог отключить приложение обратно. На наших линиях GE имеется много полос пропускания, поэтому нет необходимости вводить данные в исходное положение. На этих маршрутизаторах нет карт политик. 90% исходящего трафика поступает из наших ответов HTTP; большая часть остального от FTP и SMTP. Соединения GE нажимают 50-200 + Мбит /с.

Вы порекомендовали бы какие-либо корректировки в буфере размера очереди вывода? Эти последовательные интерфейсы являются нашими резервными ссылками, которые я бы предпочел использовать больше по причине, приведенной ранее (если она действительна), но закалена с моим Политики BGP, которые пытаются не перегружать этот последовательный интерфейс (который в большинстве случаев кажется очень недогруженным).

15 голосов | спросил generalnetworkerror 1 J0000006Europe/Moscow 2013, 12:39:12

2 ответа


13

Вы правы, вы бы не увидели легкость в SNMP. 1GE может отправлять 1.48Mpps, поэтому требуется очень мало времени, чтобы укрепить 45Mbps, которые могут обрабатывать менее 75 кбит /с.

Если ваш вход равен 1GE, а выход - 45 Мбит /с, то, очевидно, точка перегрузки 45 Мбит /с должна будет отбрасывать пакеты. Это нормально и ожидается. Если вы увеличите количество буферов, вы получите дополнительную задержку.
1GE принимает 0,45 мс для отправки 40 1500-битных IP-фреймов, на данный момент это количество пакета, с которым вы можете справиться. Однако удаление их на 45 Мбит /с уже занимает 10 мс.

Если у вас нет какой-либо острой проблемы, я бы, вероятно, ничего не сделал. Но если какой-то трафик более подходит для удаления, чем другие, то вы должны заменить FIFO на классовую очередь. Скажем, вы хотите установить приоритеты, чтобы больше ftp было сброшено и меньше voip.
Тогда также будет иметь смысл добавить больше буферизации в ftp-трафик, поскольку он не очень чувствителен к задержке.

Если вы хотите испытать удачу с более глубокими буферами, достаточно чего-то вроде этого:

  policy-map WAN-OUT
 class class-default
    справедливая очередь
    200 пакетов
!
интерфейс Serial1 /0
  выход из системы обслуживания WAN-OUT
 

Это приведет к буферам 50 мс в Serial1 и позволит вам обрабатывать до 2,25 мс пакет с одного интерфейса Gige.

ответил ytti 1 J0000006Europe/Moscow 2013, 13:06:23
8

OQD обычно вызваны одной из двух вещей:

  1. Вы уже используете ссылку; либо с постоянным высоким уровнем использования, либо с интенсивным трафиком.

  2. У вас есть карта политик, применяемая к интерфейсу, который настроен на выполнение какого-то действия, например, с помощью политики или формирования некоторого или всего трафика.

  3. В интерфейсе есть какая-то ошибка, посмотрите на счетчики ошибок ( show interface Serial1 /0 counters errors ) и убедитесь, что он не отбрасывает пакеты из-за ошибка.

Вы можете заглянуть (если у вас есть уже есть), наложив карту политики на место, чтобы сделать что-то вроде критического трафика вашей миссии в собственной очереди, включить предотвращение перегрузки на обычном трафике (WRED) или даже просто разрешить честную очередь на трафик, чтобы полоса пропускания распределялась между потоками, проходящими через интерфейс.

Как вы уже упоминали, другим вариантом будет увеличение размера очереди вывода на интерфейсе, но если вы будете использовать карту политики, тогда в этом не было бы необходимости, так как политика создавала бы другие под-очереди.

ответил David Rothera 1 J0000006Europe/Moscow 2013, 13:07:48

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132