Вихідні краплі на послідовний інтерфейс: краща черга чи розмір вихідної черги?

На крайових маршрутизаторах Інтернету, що говорять про eBGP на декількох операторах, а iBGP один на одного, всі інтерфейси на стороні LAN та WAN є GE, за винятком одного Послідовного повного DS3 (~ 45 Мбіт / с) на кожному маршрутизаторі. Хоча я думаю, що я навряд чи надсилаю багато трафіку на послідовні інтерфейси - в діапазоні 3-10 Мбіт / с - я бачу постійні падіння черги на вихід (OQD). Чи є ймовірне пояснення того, що насправді є бурхливий трафік, якого я не бачу, оскільки інтервал завантаження становить мінімум 30 секунд, а опитування SNMP становить усереднення трафіку протягом 5 хвилин, тож вони не висвітлюють бурхливість?

Платформа - це Cisco 7204VXR NPE-G2. Серійна черга - фіфо .

Serial1 / 0 вгору, протокол рядка вгору
  Апаратне забезпечення - M2T-T3 + pa
  Опис:
  Інтернет-адреса abcd / 30
  MTU 4470 байт, BW 44210 Кбіт, DLY 200 Usec,
     надійність 255/255, txload 5/255, rxload 1/255
  Інкапсуляція HDLC, crc 16, циклічне відключення не встановлено
  Набір Keepalive (10 сек)
  Перезапуск-затримка становить 0 сек
  Останній вхід 00:00:02, вихід 00:00:00, вихід не зависає ніколи
  Останнє очищення лічильників "шоу-інтерфейсу" 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. ISP 2-го рівня за DS3 має POP, які вдвічі перевищують точки зрівнювання з 6+ рівнем 1, тому ідея полягає в тому, щоб цей трафік став мережевим з клієнтом якнайшвидше, ніж наш основний провайдер в GE, який є рівнем 1 , але вони повинні прокласти шлях до своїх пірингових обмінів. Вхідний трафік не викликає занепокоєння.

Чи є в цій ситуації краща стратегія черги, ніж фіфо? Переглядаючи документи Cisco щодо падіння черги на вхід та вихід, збільшення розміру черги вихідної черги не рекомендується, оскільки пакети вже є на маршрутизаторі, і було б краще опуститися при введенні, щоб TCP міг відкинути додаток. На наших посиланнях GE є багато пропускної здатності, тому насправді не потрібно заглушувати вхід. На цих маршрутизаторах немає карт-політики. 90% вихідного трафіку надходить від наших відповідей HTTP; більшість решти - від FTP та SMTP. GE-посилання висувають 50-200 + Мбіт / с.

Чи рекомендуєте ви будь-які коригування буфера розміру черги виводу? Ці послідовні інтерфейси - це наші резервні посилання, які я скоріше використовую більше з тієї причини, що була раніше (якщо дійсно), але загартована моєю політикою BGP, яка намагається не перевантажувати цей послідовний інтерфейс (який, як видається, сильно перевантажений більшою частиною часу).

Ви маєте рацію, насправді на SNMP легко не побачити поривчастості. 1GE може надіслати 1.48Mpps, тому потрібно дуже мало часу для того, щоб збільшити 45Mbps, який може працювати менше ніж 75kpps.

Якщо ваш вхід дорівнює 1GE, а вихід становить 45 Мбіт / с, тоді, очевидно, в точку перевантаження в 45 Мбіт / с потрібно буде скинути пакети. Це нормально і очікувано. Якщо ви збільшуєте буфери, ви введете більше затримки.
1GE займає 0,45 мс, щоб надіслати 40 кадрів з 1500В IP, що зараз становить кількість вибухів, з якими ви можете впоратися. Однак видалення їх на 45 Мбіт / с вже займає 10 мс.

Якщо у вас немає жодної гострої проблеми, я, мабуть, нічого з цього не зробив. Але якщо деякий трафік є більш придатним для скидання, ніж інший, тоді слід замінити FIFO на черзі на основі класів. Скажіть, можливо, ви хочете розставити пріоритети, щоб збільшити більше ftp і менше VoIP.
Тоді також буде доцільніше додати більше буферизації на ftp-трафіку, оскільки це не дуже чутливо до затримки.

Якщо ви хочете спробувати свою удачу з глибшими буферами, чогось подібного має бути достатньо:

policy-map WAN-OUT
 class class-default
    fair-queue
    queue-limit 200 packets
!
interface Serial1/0
  service-policy output WAN-OUT

Це спричинить буфери 50 мс на Serial1 і дозволить вам обробляти до 2,25 мс лопнув з одного інтерфейсу Gige.

ОКД зазвичай викликається однією з двох речей:

1. Ви надмірно використовуєте посилання; з постійним високим рівнем використання або бурхливим трафіком.

2. У вас застосована карта політики, застосована до інтерфейсу, який налаштований на те, щоб виконувати щось на зразок функціонування або формування певного або всього трафіку

3. В інтерфейсі є якась помилка, погляньте на лічильники помилок ( show interface Serial1/0 counters errors) і переконайтеся, що його не випадає пакетів через помилку.

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

Як ви вже згадували, іншим варіантом було б збільшити розмір вихідної черги на інтерфейсі, але якби ви використовували мапу політики, то в цьому все одно не було б потреби, оскільки політика створювала б інші підрядки.