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

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

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

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

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

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

Мои вопросы:

  • Есть ли какие-либо другие вещи, которые я должен проверить, чтобы найти причину этого увеличение загрузки процессора на маршрутизаторы?
  • Как я могу легко узнать, какие сеансы вызывают эти проблемы? (если мое предположение верно)? Включение трассировки BGP создает огромные количество данных, но я не уверен, дает ли он мне какие-либо реальные идеи.
20 голосов | спросил Teun Vink 28 J0000006Europe/Moscow 2013, 11:33:31

2 ответа


16

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

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

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

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

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

  • Проверьте задачи RPD: Определите, что делает процесс занятым. Это можно проверить, сначала включив учет заданного задания. Важно: это само по себе может увеличить нагрузку на процессор и его использование; поэтому не забудьте выключить его, когда закончите с необходимой сборкой выходных данных. Затем запустите отчет о задании задач и найдите поток с высоким временем процессора:

    пользователь @ маршрутизатор > показать задачу учета
    Задача, начатая пользователем Время в системе Длительное время
    Планировщик 146051 1.085 0.090 0.000
    Память 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. В некоторых случаях использование высокой памяти может косвенно приводить к высокому процессору.

ответил Artanix 28 J0000006Europe/Moscow 2013, 11:45:00
2

Я знаю, что эта ветка устарела, но для полноты:

Если высокий CPU происходит случайным образом, и вы не можете определить процесс, вызывающий это, мы можем создать сценарий ниже.

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

snmp {
    здоровье-монитор {
        интервал 30;
        восходящий порог 60;
        падающий порог 50;
    }
}

event-options {
    политика MONITOR-CPU {
        события snmpd_health_mon_thresh_cross;
        attributes-match {
            snmpd_health_mon_thresh_cross.event-name соответствует «Монитор работоспособности. + CPU. + повышение»;
        }
        тогда {
            execute-commands {
                команды {
                    «показать системные процессы обширными»;
                }
                output-filename cpu-процессы;
                локальная вспышка назначения;
                формат выходного формата;
            }
        }
    }
    пункты назначения {
        local-flash {
            архивные сайты {
                /Var /TMP;
            }
        }
    }
}

DISPLAY SET OUTPUT>

установить интервал работоспособности snmp 30
установить восходящий порог здоровья монитора snmp 60
установить снип-порог монитора работоспособности snmp 50
установить политику событий-событий. События MONITOR-CPU snmpd_health_mon_thresh_cross
установить параметры политики событий. MONITOR-CPU атрибуты-match snmpd_health_mon_thresh_cross.event-name соответствует "Health Monitor. + CPU. + повышение"
установить политику опций событий MONITOR-CPU, а затем выполнить команды-команды «показать системные процессы обширными»,
установить политику опций событий MONITOR-CPU, а затем выполнить команды output-filename cpu-процессы
установить политику опций событий. MONITOR-CPU, затем выполнить команду local local
установить политику параметров событий MONITOR-CPU, затем выполнить команду-output text
задавать назначения событий-мест локально-flash-архивные сайты /var /tmp

Также вы проверили, были ли сообщены какие-либо сообщения ddos? Вы можете выполнить следующие команды:

показать статистику протоколов ddos-protection
показать статистику ddos-protection
Показать версию ddos-protection

Тогда в зависимости от того, что вы видите, его можно сузить, например:

показать протоколы ddos-protection ttl statistics
показать протоколы ddos-protection ttl
показать ddos-протоколы защиты ttl описание обнаружения потока * /* этот cm требует предварительной конфигурации * /*

У Juniper также есть список коллекций для этого типа проблем под KB22637

Высокий CPU Команды CLI

set cli timestamp
show chassis routing-engine (несколько снимков, по крайней мере 5)
показать процессы системы обширные (несколько снимков по крайней мере 5)
показывать пользователям системы
показать системные соединения
показать статистику системы

Включить учет задач и собрать отчет о детализации задачи (три раза с промежутком в 30 секунд). Не забудьте выключить его после завершения.

установить учет задачи на
показать подробное описание задачи
отключить учет заданий

показать детали памяти задачи
показать краткое описание задачи
показать задачу io
показать историю задач
показать статистику задач
показать задание задания
показать задания задания
show krt queue
показать статус krt

Журналы

Архив /var /log, как указано в шаге 1 выше Traceoptions

user @ router # show routing-options
traceoptions {
file routing-trace size 10m файлов 20 читаемых в мире;
задача флага;
состояние флага;
таймер флага;
}

Также, если вы используете старую версию, которая была подвержена ошибкам, вы можете проверить жизненную поддержку кода:

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

Еще один момент, который можно назвать векторной атакой, не защитил ваш RE от нежелательного трафика исключений. Убедитесь, что у вас есть фильтр брандмауэра в loopback.

Я видел в прошлом скрипты на маршрутизаторе, вызывающие высокий CPU, не уверенный, что rpd пришел в мой взгляд, но это то, что вы, возможно, не захотите упустить.

Если вы видите в журналах много просмотров с RPD_MPLS_PATH_BANDWIDTH_CHANGE, вы можете использовать очень агрессивный интервал настройки

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

ответил DRP 28 MarpmTue, 28 Mar 2017 22:59:37 +03002017-03-28T22:59:37+03:0010 2017, 22:59:37

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

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

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