Причиной высокой загрузки процессора на маршрутизатор пирингового маршрутизатора Juniper

В последнее время загрузка ЦП механизма маршрутизации на двух наших пиринговых маршрутизаторах Juniper увеличилась с ~ 10-20% средней нагрузки до 80 +%. Я пытаюсь выяснить, что вызывает это (и как уменьшить эту высокую нагрузку).

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

Вещи, которые я проверил:

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

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

Мои вопросы:

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

Там может быть полезная информация для вас в Центре знаний Juniper .

Если RPD потребляет высокую загрузку процессора, выполните следующие проверки и проверьте следующие параметры:

• Проверьте интерфейсы. Проверьте, нет ли каких-либо интерфейсов на маршрутизаторе. Это можно проверить, посмотрев выходные данные сообщений show log и подробных команд show interfaces ge-x / y / z. Выясните, почему они хлопают; если возможно, вы можете рассмотреть возможность включения времени удержания для соединения вверх и вниз.

• Проверьте, есть ли сообщения об ошибках системного журнала, связанные с интерфейсами или любой FPC / PIC, просматривая выходные данные сообщений show log.

• Проверьте маршруты. Проверьте общее число маршрутов, которые были изучены маршрутизатором, просмотрев выходные данные сводки show route. Проверьте, достиг ли он максимального предела.

• Проверьте задачи 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 по-прежнему рекомендуется. Однако я вижу, что вы сузили его до РПД.

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, вы можете использовать очень агрессивный интервал регулировки

Проверьте любые сбросы в «show system queue»: это очередь ядра, может появиться некоторая подсказка.