Протокол IP : Протокол BGP

Устранение проблем с перегрузкой CPU, вызываемой процессом сканера или маршрутизатора BGP

20 октября 2016 - Машинный перевод
Другие версии: PDF-версия:pdf | Английский (22 августа 2015) | Отзыв


Содержание


Введение

Этот документ описывает ситуации, в которых Cisco маршрутизатор IOS� мог бы испытать высокую загрузку ЦП или из-за процесса Маршрутизатора пограничного протокола шлюза (BGP) или из-за процесса сканера BGP, как показано в выходных данных команды show process cpu . Продолжительность состояния высокой загрузки CPU переменна и зависит от ряда условий, в частности размера таблицы межсетевой маршрутизации и количества маршрутов, которые конкретный маршрутизатор хранит в таблицах маршрутизации и BGP.

Команда show process cpu показывает среднюю загрузку CPU за последние пять секунд, одну минуту и пять минут. Показатели использования ЦП не дают точных сведений о загрузке по сравнению с абонентской нагрузкой. Это некоторые основные причины:

  • CPU в реальной сети должен выполнять различные функции обслуживания системы, например, управление сетью.

  • CPU должен обрабатывать периодические и запущенные событиями обновления маршрута.

  • Существуют другие внутренние системные служебные операции, например, опрос доступности ресурсов, которые не пропорциональны трафику.

Можно также использовать команду show processes cpu для получения некоторой индикации активности CPU.

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

Перед началом работы

Условные обозначения

Дополнительные сведения об условных обозначениях см. в документе Условные обозначения технических терминов Cisco.

Предварительные условия

Этот документ требует понимания того, как интерпретировать команду show process cpu. См. Устранение проблем Высокой загрузки ЦП на маршрутизаторах Cisco как справочный материал.

Используемые компоненты

Сведения в этом документе основываются на программном обеспечении Cisco IOS версии 12.0.

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

Общие сведения о процессах BGP

Процесс Cisco IOS, в целом, состоит из отдельных потоков и привязанных данных, которые выполняют задачи, такие как обслуживание системы, коммутируемые пакеты и протоколы маршрутизации реализации. Несколько процессов Cisco IOS, выполняемых на маршрутизаторе, позволяют BGP работать. Используйте команду show process cpu | include BGP для наблюдения суммы загрузки ЦПУ из-за процессов BGP.

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

Имя процесса Описание Интервал
Открытый BGP Устанавливает одноранговое соединение BGP. В инициализации, при установлении TCP - подключения с Одноранговым соединением по протоколу BGP.
Ввод-вывод BGP Формирование очередей дескрипторов и обработка пакетов BGP, таких как UPDATE и KEEPALIVE. При поступлении контрольных пакетов BGP.
Сканер BGP Просматривает таблицу BGP и подтверждает достижимость следующих узлов. Сканер BGP также проверяет условные объявления, чтобы определить, должен ли BGP объявлять префиксы состояния, и проводит разгрузку маршрутов. В среде MPLS VPN импорт Сканера bgp и экспорт направляют в определенный экземпляр VPN Routing и Forwarding (VRF). Одна минута.
Маршрутизатор BGP Вычисляет наилучший путь BGP и обрабатывает осцилляции маршрута. Он также отправляет и получает маршруты, устанавливает одноранговые соединения и взаимодействует с базой данных маршрутизации (RIB). Один раз в секунду, а также при добавлении, удалении или перенастройке программного обеспечения одноуровнего узла BGP.

Высокое использование CPU из-за сканера BGP

Высокая загрузка CPU из-за процесса сканера BGP может ожидаться для небольших времен на маршрутизаторе, несущем большую интернет-таблицу маршрутизации. Один раз в минуту BGP сканер переходит к таблице BGP RIB и выполняет важные задания техобслуживания. Эти задачи включают проверку следующего узла, указанного в таблице BGP маршрутизатора, и достижимости устройств следующего узла. Таким образом, большая таблица BGP занимает равнозначно большой промежуток времени для прохождения и проверки.

Поскольку процесс сканера BGP пробегает всю таблицу BGP, продолжительность состояния высокой загрузки CPU меняется в зависимости от количества соседних узлов и количества маршрутов, изученных на соседний узел. Используйте для сбора этих сведений команды show ip bgp summary и show ip route summary.

Процесс сканера BGP обходит таблицу BGP для обновления любых структур данных и обходит таблицу маршрутизации в целях перераспределения маршрутов. (В этом контексте таблица маршрутизации также известна как база информации маршрутизации (RIB), которую отображает маршрутизатор при выполнении команды show ip route) . Обе таблицы являются сохраненными отдельно в памяти маршрутизатора и могут быть очень большими, таким образом использовав циклы ЦПУ.

Следующий пример вывода команды debug ip bgp updates захватывает выполнение сканера BGP, который начинает сканирование с наименьшего нумерованного префикса 0.0.0.0.

router# 
2d17h: BGP: scanning routing tables 
2d17h: BGP: 3.0.0.0 computing updates, neighbor version 8, 
     table version 9, starting at 0.0.0.0 
2d17h: BGP: 3.0.0.0 update run completed, ran for 0ms, neighbor
     version 8, start version 9, throttled to 9, check point net 0.0.0.0 
2d17h: BGP: 4.0.0.0 computing updates, neighbor version 8, 
     table version 9, starting at 0.0.0.0 
2d17h: BGP: 4.0.0.0 update run completed, ran for 4ms, neighbor
     version 8, start version 9, throttled to 9, check point net 0.0.0.0 
router#

Когда запущен сканер BGP, процессам с низким приоритетом приходится дольше ждать доступа к CPU. Один низкоприоритетный процесс управляет пакетами ICMP, например проверкой доступности адресатов. Пакеты, предназначенные для или исходящие от маршрутизатора, могут испытывать задержку выше ожидаемой из-за ожидания процесса ICMP за сканером BGP. Цикл - то, что Сканер bgp выполняется в течение некоторого времени и приостанавливает себя, и затем выполнения ICMP. Эхо-тесты, которые пересылаются через маршрутизатор, должны быть направлены через CEF без дополнительных задержек. При устранении проблем периодических скачков в задержке сравните времена переадресации для пакетов, переданных через времена пакетов, отправленных через маршрутизатор, с пакетами, обработанными непосредственно CPU на маршрутизаторе, обработанные непосредственно ЦП на маршрутизаторе.

Примечание: Команды ping, которые задают IP - режимы, такие как рекордный маршрут, также требуют непосредственной обработки данных ЦП и могут испытать более длинные задержки передачи.

Используйте команду show process | include bgp scanner для наблюдения приоритета ЦПУ. В значении "Lsi" в следующем примере символ "L" обозначает низкоприоритетный процесс.

6513# show processes | include BGP Scanner
 172 Lsi 407A1BFC       29144     29130    1000 8384/9000  0 BGP Scanner

Высокая загрузка CPU из-за процесса маршрутизации BGP

Процесс маршрутизатора под управлением BGP выполняется об один раз во второй для проверки для работы. Согласование BGP определяет продолжительность между временем, когда первое Одноранговое соединение по протоколу BGP установлено и точка, в которой сходится BGP. Для обеспечения самых коротких времен согласования маршрутизатор под управлением BGP использует все свободные циклы ЦПУ. Однако после запуска он периодически уменьшает загрузку CPU или приостанавливает его.

Время согласования является непосредственным измерением того, сколько времени маршрутизатор под управлением BGP тратит на ЦП, не общее время. Эта процедура показывает состояние высокой загрузки CPU во время согласования BGP и обменивается префиксами BGP с двумя узлами подключенный по внешнему протоколу bgp (EBGP).

  1. Перед выполнением теста сделайте снимок базы при обычной загрузке CPU.

    router# show process cpu
      CPU utilization for five seconds: 0%/0%; one minute: 4%; five minutes: 5%
  2. После начала теста загрузка CPU достигает 100%. Команда show process cpu показывает, что состояние высокой загруженности CPU вызывается маршрутизатором BGP, на что указывает значение 139 (идентификатор процесса IOS для маршрутизатора BGP) в приведенных ниже выходных данных.

    router# show process cpu
      CPU utilization for five seconds: 100%/0%; one minute: 99%; five minutes: 81%
    
    !--- Output omitted.
    
    139     6795740   1020252       6660 88.34% 91.63% 74.01%   0 BGP Router
  3. Контролируйте маршрутизатор путем получения множественных выходных данных команд show ip bgp summary и show process cpu во время события. Команда show ip bgp summary захватывает состояние соседей BGP.

    router# show ip bgp summary
      Neighbor    V    AS  MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down State/PfxRcd
      10.1.1.1    4  64512  309453  157389    19981    0  253 22:06:44 111633
      172.16.1.1  4  65101  188934    1047    40081   41    0 00:07:51 58430
  4. Когда маршрутизатор завершает обмен префиксами с узлами BGP, загруженность CPU должна вернуться на нормальный уровень. Вычисленные средние значения за минуту и за пять минут также установятся и могут показать уровни выше обычного за более длительный период, чем скорость за пять секунд.

    router# show process cpu
      CPU utilization for five seconds: 3%/0%; one minute: 82%; five minutes: 91%
  5. При помощи записи вывода приведенных выше команд "show" можно рассчитать время конвергентности протокола BGP. В частности, используйте столбец "Up/Down" команды show ip bgp summary и сравните время начала и окончания состояния высокой загрузки CPU. Обычно согласование BGP может занимать несколько минут, когда происходит обмен большими таблицами маршрутизации интернета.

Примечание: Высокая загрузка CPU на устройстве могла также произойти из-за нестабильности таблицы BGP. Если маршрутизатор получает две копии таблицы маршрутизации, один от Равноправного информационного обмена eBGP с интернет-провайдером и другим от Однорангового телефонного соединения IBGP в сети. Основная причина для этого является количеством памяти на устройстве. Cisco рекомендует минимум 1 ГБ ОЗУ для единственной копии интернет-таблицы маршрутизации. Для хитрости этой нестабильности увеличьте ОЗУ на устройстве или фильтруйте префиксы так, чтобы были уменьшены таблица BGP и память, занятая им.

Повышение производительности

Когда количество маршрутов в интернет-таблице маршрутизации растет, так также делает время, которое требуется для BGP для схождения. В общем согласование определяется как процесс приведения всех таблиц маршрутизации в состояние согласованности. Считается, что BGP будет конвергироваться при выполнении следующих условий:

  • Все маршруты были приняты.

  • Все маршрутизаторы были занесены в таблицу маршрутизации.

  • Версия таблицы для всех узлов равняется версии таблицы таблицы BGP.

  • InQ и OutQ для всех узлов являются нулем.

В этом разделе описываются некоторые повышения производительности IOS для сокращения времени согласования BGP, которые приводят к сокращению состояния высокой загрузки CPU из-за процесса BGP.

Очередь на одноранговое подключение протокола управления передачей (TCP)

Вместо постановки данных в очередь один раз в секунду, BGP постоянно передает данные из исходящей очереди BGP на сокет TCP для каждого однорангового соединения до тех пор, пока очереди не станут пустыми. Увеличение скорости передачи данных BGP привело к повышению скорости конвергенции BGP.

Группы сторон BGP

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

MTU пути и команда ip tcp path-mtu-discovery

Все сеансы TCP ограничены пределом на количестве байтов, которые могут быть транспортированы в одном пакете. Этот предел, известный как максимальный размер сегмента (MSS), по умолчанию равен 536 байтам. Другими словами, протокол TCP разделяет пакеты в очереди передачи на куски величиной 536 байт, а уже потом передает пакеты на уровень IP. Используйте команду show ip bgp neighbors | include max data для отображения MSS Одноранговых соединений по протоколу BGP:

Router# show ip bgp neighbors | include max data 
Datagrams (max data segment is 536 bytes): 
Datagrams (max data segment is 536 bytes): 
Datagrams (max data segment is 536 bytes): 
Datagrams (max data segment is 536 bytes): 

Преимущество 536-байтового MSS заключается в том, что фрагментация пакетов на IP-устройстве мало вероятна на всем пути к узлу назначения, так как большая часть каналов использует MTU не меньше 1500 байт. Недостаток - то, что пакеты меньшего размера увеличивают сумму пропускной способности, используемой к транспортным издержкам. Так как BGP создает TCP - подключение ко всем узлам, 536-байтовый MSS влияет на времена согласования BGP.

Решение в том, чтобы включить функцию Path MTU (PMTU), используя команду ip tcp path-mtu-discovery. Можно использовать эту функцию, чтобы динамично определить, насколько большой значение MSS может быть, не создавая пакеты, которые должны быть фрагментированы. PMTU позволяет TCP определять самый маленький максимальный размер передаваемого блока данных среди всех ссылок на сеансе TCP. TCP тогда использует это значение MTU, минус место для IP и заголовков TCP, как MSS для сеанса. Если в сеансе TCP обходятся только сегменты Ethernet, то MSS будет 1460 байт. Если он передает только пакет по сегментам SONET (POS), то MSS будет составлять 4430 байт. Увеличение MSS от 536 до 1460 или 4430 байтов уменьшает издержки TCP/IP, которые помогают BGP сходиться быстрее.

После включения PMTU снова используйте команду show ip bgp neighbors | include max data для наблюдения значения MSS на узел:

Router# show ip bgp neighbors | include max data 
Datagrams (max data segment is 1460 bytes): 
Datagrams (max data segment is 1460 bytes): 
Datagrams (max data segment is 1460 bytes): 
Datagrams (max data segment is 1460 bytes): 

Увеличьте очереди на входе интерфейса

Если BGP объявляет тысячи маршрутов ко многим одноранговым узлам, TCP должен переслать тысячи пакетов за короткий отрезок времени. Одноранговые соединения по протоколу BGP получают эти пакеты и передают подтверждения приема TCP рекламному динамику BGP, который заставляет динамик BGP получать лавинную рассылку ACK TCP в коротком периоде времени. Если пакеты ACK прибывают с частотой, слишком высокой для данного маршрутного процессора, пакеты данных сохраняются в очередях входного интерфейса. По умолчанию, в интерфейсах маршрутизатора используется входящая очередь размером 75 пакетов. Кроме того, особые управляющие пакеты, такие как BGP UPDATES, используют специальную очередь с выборочным отбрасыванием пакетов. Специальная очередь содержит 100 пакетов. Во время сходимости BGP сообщения ACK TCP могут быстро заполнить 175 ячеек буферизации на входе и вновь поступающие пакеты должны будут сброшены. Маршрутизаторы с 15 и более одноранговыми узлами BGP, которые обмениваются полной таблицей Интернет-маршрутизации, могут регистрировать свыше 10000 сбросов в минуту на интерфейс. Вот примерный результат работы маршрутизатора через 15 минут после перезагрузки:

Router# 
show interface pos 8/0 | include input queue 
Output queue 0/40, 0 drops; input queue 0/75, 278637 drops 
Router#

Увеличение глубины входящей очереди интерфейса (использующий hold-queue <1-4096> в команде) помогает сокращать количество отброшенных ACK TCP, которое уменьшает BGP объема работы, должен сделать для схождения. Обычно, значение 1000 проблем решений вызвано отбрасыванием входящей очереди.

Примечание: Серия Cisco 12000 теперь использует значение размера заголовка SPD по умолчанию 1000. Это сохраняет размер входящей очереди по умолчанию 75. Для просмотра специальных входных очередей используйте команду show spd.

Дополнительные улучшения в IOS 12.0(19)S

Программное обеспечение IOS версии 12.0(19)S предусматривает несколько усовершенствований кода одноранговой группы BGP, обеспечивающих сжатие и репликацию обновления. Прежде чем мы обсудим эти улучшения, давайте посмотрим на упаковку обновления и репликацию более подробно.

Обновление BGP состоит из комбинации атрибутов (таких как MED = 50 и LOCAL_PREF = 120) и Информация о доступности Уровня списка сетей (NLRI) префиксы, которые совместно используют ту комбинацию атрибутов. Чем уменьшено больше префиксов NLRI, которые BGP может перечислить в одиночном обновлении, тем более быстрый BGP может сходиться начиная с издержек (таких как IP, TCP и заголовки протокола BGP). "Упаковка обновления" обращается к упаковке NLRI в Обновления BGP. Например, если таблица BGP держит 100,000 маршрутов 15,000 комбинаций уникального атрибута, BGP должен передать только 15,000 обновлений, если NLRI упакован 100-процентной эффективностью.

Примечание: Нулевой процент, упаковывающий эффективность, означает, что BGP должен был бы передать 100,000 обновлений в этой среде.

Используйте команду show ip bgp peer-group, чтобы узнать эффективность обновлений BGP.

Если член группы точек вызова находится в режиме синхронизации, то маршрутизатор BGP повторяет для него сообщение об обновлении, отформатированное для главного узла группы. Гораздо эффективнее реплицировать обновление для члена группы одноранговых узлов, чем повторно форматировать обновление. Например, предположим, что группа одноранговых узлов насчитывает 20 членов и все они должны получить 100 сообщений BGP. Стопроцентная репликация означает, что маршрутизатор BGP форматирует 100 сообщений для главного узла в группе равноправных узлов и реплицирует эти сообщения для остальных 19 узлов в группе. Для подтверждения усовершенствований репликации сравните количество сообщений, реплицированных в количество отформатированных сообщений, как показано командой show ip bgp peer-group. Улучшения дают существенное изменение времени схождения и позволяют BGP поддерживать гораздо больше участников. Рассмотрим пример.

Чтобы проверить эффективность сжатия и репликации обновления, выполните команду show ip bgp peer-group. Следующие выходные данные получены в результате проверки сходимости с 6 группами одноранговых узлов: 20 одноранговых узлов в каждой из первых 5 групп (одноранговые узлы eBGP) и 100 одноранговых узлов в шестой группе (внутренние одноранговые узлы BGP (iBGP)). Кроме того, таблица BGP, которая использовалась, имела 36,250 комбинаций атрибутов.

Следующий пример выходных данных команды show ip bgp peer-group | include replicated на маршрутизаторе рабочий IOS 12.0 (18) S отображает следующую информацию:

Update messages formatted 836500, replicated 1668500 
Update messages formatted 1050000, replicated 1455000 
Update messages formatted 660500, replicated 1844500 
Update messages formatted 656000, replicated 1849000 
Update messages formatted 501250, replicated 2003750 

!-- The first five lines are for eBGP peer groups.
 
Update messages formatted 2476715, replicated 12114785 

!-- The last line is for an iBGP peer group.

Для вычисления коэффициента повторяемости для каждой группы одноранговых узлов разделите количество обновлений, реплицированных количеством отформатированных обновлений:

1668500/836500 = 1.99 1455000/1050000 = 1.38 1844500/660500 = 2.79 1849000/656000 = 2.81 2003750/501250 = 3.99 12114785/2476715 = 4.89

Если бы BGP реплицировал отлично, то группы одноранговых узлов EBGP каждый имели бы коэффициент повторяемости 19, потому что существует 20 узлов в группе одноранговых узлов. Обновление должно быть отформатировано для начала группы одноранговых узлов и затем реплицировано в другие 19 узлов, предоставив оптимальный коэффициент повторяемости 19. Идеальный коэффициент повторяемости для одноуровневой группы узлов iBGP был бы 99, так как существует 100 узлов.

Если сжатый BGP обновится нормально, окажется лишь 36,250 форматированных обновлений. Потребуется создать только 36 250 обновлений для каждой группы одноранговых узлов, т. е. число комбинаций атрибутов в таблице BGP. Одноранговая группа iBGP форматирует около 2 500 000 обновлений, а одноранговые группы eBGP генерируют от 500 000 до 1 000 000 обновлений каждая.

На маршрутизаторе рабочий IOS 12.0 (19) S, команда show ip bgp peer-group | include replicated предоставляет эту информацию:

Update messages formatted 36250, replicated 688750 
Update messages formatted 36250, replicated 688750 
Update messages formatted 36250, replicated 688750 
Update messages formatted 36250, replicated 688750 
Update messages formatted 36250, replicated 688750 
Update messages formatted 36250, replicated 3588750

Примечание: Создание пакетов обновления является оптимальным. Ровно 36 250 обновлений форматируются для каждой одноранговой группы.

688750/36250 = 19 688750/36250 = 19 688750/36250 = 19 688750/36250 = 19 688750/36250 = 19 3588750/36250 = 99

Примечание: Репликация обновлений также является оптимальной.

Устранение неисправностей

Используйте эти процедуры для устранения проблем высокой загрузки CPU из-за Сканера bgp или маршрутизатора под управлением BGP:

  • Соберите информацию о своей топологии BGP. Определите число одноранговых узлов BGP и число маршрутов, объявленных каждым узлом. Длительность высокой загруженности процессора соответствует среде?

  • Определите, когда произойдет высокая загрузка CPU. Совпадает ли оно с регулярно планируемым обходом таблицы BGP?

  • Выполните команду show ip bgp flap-statistics . Высокая загруженность CPU приводит к переброске интерфейса?

  • Отправьте эхо-тест в маршрутизатор, а затем из маршрутизатора. Эхо-пакеты ICMP обрабатываются как процесс с низким приоритетом. Документ, Понимая Команды эхо-запрос и Traceroute объясняет это более подробно. Убедитесь, что стандартное перенаправление функционирует правильно.

  • Гарантируйте, что пакеты могут придерживаться быстрого пути переадресации путем проверки, включены ли быстрая коммутация и/или CEF на входящем и исходящих интерфейсах. Гарантируйте, что вы не видите команду no ip route-cache cef на интерфейсе или команду no ip cef на глобальной конфигурации. Для включения CEF в режиме глобальной конфигурации используйте команду ip cef .

  • Получите выходные данные из этих команд:

    Команда Описание
    Show mls cef summary Отображает количество маршрутов в Многоуровневой коммутации (MLS) аппаратная таблица Коммутации уровня 3 для всех протоколов.
    show mls cef maximum-routes Отображает текущую максимальную конфигурацию системы маршрута.
    show mls cef exception <статус> Отображает информацию о статусе исключения скоростной маршрутизации Cisco.

  • Проверьте DRAM на маршрутизаторе. Согласно рекомендации, должен быть минимум 512 МБ Пространства DRAM на Одноранговое соединение по протоколу BGP, которое передает полную таблицу Internet-маршрутизации. Если маршрутизатор имеет два узла EBGP, которые выполняют полную таблицу Internet-маршрутизации, то минимальный 1 ГБ Пространства DRAM рекомендуется. Пространство DRAM, упомянутое здесь, является просто памятью, требуемой для BGP. Другие функции, которые работают на маршрутизаторе, потребуют дополнительного Пространства DRAM.


Дополнительные сведения


Document ID: 107615