Причина великого навантаження процесора на маршрутизатор Juniper peering router

Нещодавно використання CPU для двигуна на двох наших пілінг-роутерах Juniper зросло з ~ 10-20% середнього навантаження до 80 +%. Я намагаюся розібратися, що це спричиняє (і як повернути це велике навантаження).

Деяка інформація про маршрутизатори: обидва запускають одну і ту ж версію JunOS, обидві підключені до одних і тих самих двояких однорідних локальних мереж IXP і мають велику кількість (кілька сотень) (майже однакових) сеансів IPv4 та IPv6. Обидва маршрутизатори мають підключення до іншого постачальника послуг IP-транзиту і підключені однаково до решти нашої мережі. Навантаження процесора на двигунах маршрутизації не є рівним на 80 +%, падіння повертається до нормального рівня за хвилини до години, але ці падіння трапляються не так часто.

Що я перевірив:

• в момент початку збільшення не було змінено конфігурацію
• не збільшується неодноразовий трафік, спрямований на площину управління
• немає (суттєвої) зміни кількості переданого трафіку (хоча навіть збільшення не має значення)
• show system processes summaryвказує на те, що rpdпроцес викликає велике навантаження процесора
• не спостерігається швидкого плескання однолітків BGP, що спричиняє велику кількість змін BGP

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

Мої запитання:

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

У Центрі знань з ялівцю для вас може бути корисна інформація .

Якщо RPD споживає високий процесор, виконайте такі перевірки та перевірте наступні параметри:

• Перевірте інтерфейси. Перевірте, чи якісь інтерфейси плескаються на маршрутизаторі. Це можна перевірити, подивившись на висновок повідомлень журналу шоу та показати інтерфейси розширених команд ge-x / y / z. Усуньте, чому вони плескають; якщо можливо, ви можете розглянути можливість активації часу затримки для зв’язку та відключення.

• Перевірте, чи є повідомлення про помилки syslog, пов'язані з інтерфейсами або будь-яким FPC / PIC, поглянувши на висновок повідомлень журналу показу.

• Перевірка маршрутів: Перевірте загальну кількість маршрутів, які вивчає маршрутизатор, переглянувши вихідний підсумок показу маршруту. Перевірте, чи досяг максимальної межі.

• Перевірте завдання RPD: Визначте, що забезпечує процес зайнятим. Це можна перевірити, спершу включивши встановлений облік завдань. Важливо: саме по собі це може збільшити навантаження на процесор і його використання; тому не забудьте вимкнути його, коли закінчите потрібний збір вихідних даних. Потім запустіть показ обліку завдань і шукайте потік з високим часом процесора:

  user@router> show task accounting
  Task                       Started    User Time  System Time  Longest Run
  Scheduler                   146051        1.085        0.090        0.000
  Memory                           1        0.000            0        0.000  <omit>
  BGP.128.0.0.4+179              268       13.975        0.087        0.328
  BGP.0.0.0.0+179      18375163 1w5d 23:16:57.823    48:52.877        0.142
  BGP RT Background              134        8.826        0.023        0.099
  

Дізнайтеся, чому нитка, яка пов'язана з певним префіксом або протоколом, займає високий процесор.

• Ви також можете перевірити, чи маршрути коливаються (або маршрутизація), переглянувши вихід команди оболонки: %rtsockmon –t

• Перевірте пам'ять RPD. Іноді Високе використання пам'яті може опосередковано призвести до високого процесора.

Я знаю, що ця тема стара, але заради повноти:

Якщо високий процесор відбувається випадковим чином, і ви не в змозі визначити процес, що викликає це, ми можемо створити сценарій нижче.

За допомогою цього сценарію ми збираємося зафіксувати обширний процес, коли процес підвищує більше, ніж звичайний або очікуваний поріг, це не повинно порушити трафіку, але MW все ж рекомендується. Однак я бачу, що ви звузили його як RPD.

snmp {
    health-monitor {
        interval 30;
        rising-threshold 60;
        falling-threshold 50;
    }
}

event-options {
    policy MONITOR-CPU {
        events snmpd_health_mon_thresh_cross;
        attributes-match {
            snmpd_health_mon_thresh_cross.event-name matches "Health Monitor.+CPU.+rising";
        }
        then {
            execute-commands {
                commands {
                    "show system processes extensive";
                }
                output-filename cpu-processes;
                destination local-flash;
                output-format text;
            }
        }                               
    }
    destinations {
        local-flash {
            archive-sites {
                /var/tmp;
            }
        }
    }
}

ВИДАЛЕННЯ ДИСПЛЕЙ>

set snmp health-monitor interval 30
set snmp health-monitor rising-threshold 60
set snmp health-monitor falling-threshold 50
set event-options policy MONITOR-CPU events snmpd_health_mon_thresh_cross
set event-options policy MONITOR-CPU attributes-match snmpd_health_mon_thresh_cross.event-name matches "Health Monitor.+CPU.+rising"
set event-options policy MONITOR-CPU then execute-commands commands "show system processes extensive"
set event-options policy MONITOR-CPU then execute-commands output-filename cpu-processes
set event-options policy MONITOR-CPU then execute-commands destination local-flash
set event-options policy MONITOR-CPU then execute-commands output-format text
set event-options destinations local-flash archive-sites /var/tmp

Ви також перевіряли, чи не надходили повідомлення з форматом ddos? Ви можете виконати такі команди:

show ddos-protection protocols statistics brief
show ddos-protection statistics
show ddos-protection version

Тоді залежно від того, що ви бачите, наприклад, можна звузити:

show ddos-protection protocols ttl statistics
show ddos-protection protocols ttl violations
show ddos-protection protocols ttl flow-detection detail  */*this cm needs prior config*/*

Juniper також має список колекцій для цього типу випусків під KB22637

Команди CLI з високим процесором

set cli timestamp
show chassis routing-engine (multiple snapshots, atleast 5)
show system processes extensive (multiple snapshots atleast 5)
show system users
show system connections
show system statistics

Увімкніть облік завдань і збирайте дані про облік завдань (три рази з проміжком 30 секунд). Не забудьте вимкнути його після закінчення.

set task accounting on 
show task accounting detail
set task accounting off

show task memory detail
show task memeory summary
show task io
show task history
show task statistics
show task job
show task jobs
show krt queue
show krt state

Колода

Архів / var / log, як зазначено в кроці 1 вище Traceoptions

user@router# show routing-options 
traceoptions { 
file routing-trace size 10m files 20 world-readable; 
flag task; 
flag state; 
flag timer; 
}

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

http://www.juniper.net/support/eol/junos.html

Ще один момент, який слід зазначити, що може бути векторною атакою, - це не захист вашого RE від небажаного трафіку виключень. Переконайтеся, що у вас є фільтр брандмауера під петлею.

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

Якщо ви побачите в журналах багато звернень із RPD_MPLS_PATH_BANDWIDTH_CHANGE, можливо, ви використовуєте дуже агресивний інтервал регулювання

Перевірте краплі на "показати систему черги: це черга ядра, може з’явитися деяка підказка.