Code 4 hold timer expired error

Коллеги, доброго дня на днях оказался в анлогичной ситуации

Mar 8 00:47:51 br-4 rpd[1116]: bgp_recv: read from peer Х.Х.Х.Х (Internal AS ХХХХХ) failed: Connection reset by peer
Mar 8 00:47:51 br-4 rpd[1116]: bgp_recv: read from peer Х.Х.Х.Х (Internal AS ХХХХХ) failed: Connection reset by peer
Mar 8 00:47:55 br-4 rpd[1116]: bgp_hold_timeout:3675: NOTIFICATION sent to Х.Х.Х.Х (Internal AS ХХХХХ): code 4 (Hold Timer Expired Error),
Reason: holdtime expired for Х.Х.Х.Х (Internal AS ХХХХХ), socket buffer sndcc: 57 rcvcc: 0 TCP state: 4,
snd_una: 219186777 snd_nxt: 219186815 snd_wnd: 12600 rcv_nxt: 1543988835 rcv_adv: 1544005219, hold timer 0
Mar 8 00:47:59 br-4 rpd[1116]: bgp_recv: read from peer Х.Х.Х.1 (Internal AS ХХХХХ) failed: Connection reset by peer
Mar 8 00:47:59 br-4 rpd[1116]: bgp_hold_timeout:3675: NOTIFICATION sent to Х.Х.Х.Х (Internal AS ХХХХХ): code 4 (Hold Timer Expired Error),
Reason: holdtime expired for Х.Х.Х.Х (Internal AS ХХХХХ), socket buffer sndcc: 57 rcvcc: 0 TCP state: 4, snd_una: 426976337 snd_nxt: 426976375 snd_wnd: 14600 rcv_nxt: 796298714 rcv_adv: 796315098, hold timer 0
Mar 8 00:48:01 br-4 rpd[1116]: bgp_hold_timeout:3675: NOTIFICATION sent to Х.Х.Х.2 (External AS YYYYY): code 4 (Hold Timer Expired Error),
Reason: holdtime expired for Х.Х.Х.Х (External AS YYYYY), socket buffer sndcc: 57 rcvcc: 0 TCP state: 4, snd_una: 3815310661 snd_nxt: 3815310699 snd_wnd: 29440 rcv_nxt: 3950147902 rcv_adv: 3950164286, hold timer 0

Изменено 11 марта, 2018 пользователем kvasyan

Hi, do you know where this problem can come from?

It’s about a peer to a Tier 2 provider, which shows us its full routing table.

> show log messages

Nov 20 23:30:14 rpd[1437]: bgp_hold_timeout:4169: NOTIFICATION sent to 200.69.129.43 (External AS 11664): code 4 (Hold Timer Expired Error), Reason: holdtime expired for 200.69.129.43 (External AS 11664), socket buffer sndcc: 57 rcvcc: 0 TCP state: 4, snd_una: 4049026493 snd_nxt: 4049026550 snd_wnd: 16023 rcv_nxt: 1889923684 rcv_adv: 1889940068, hold timer out 90s, hold timer remain 0s
Nov 20 23:30:25 rpd[1437]: bgp_pp_recv: rejecting connection from 200.69.129.43 (External AS 11664), peer in state Idle
Nov 20 23:30:25 rpd[1437]: bgp_pp_recv:3592: NOTIFICATION sent to 200.69.129.43+36398 (proto): code 6 (Cease) subcode 5 (Connection Rejected)
Nov 20 23:30:37 rpd[1437]: bgp_pp_recv: rejecting connection from 200.69.129.43 (External AS 11664), peer in state Idle
Nov 20 23:30:37 rpd[1437]: bgp_pp_recv:3592: NOTIFICATION sent to 200.69.129.43+40567 (proto): code 6 (Cease) subcode 5 (Connection Rejected)

neighbor 200.69.129.43 {
        description claro;
        multihop {
            ttl 4;
        }
        import set-local-pref;
        export claro-out;
        peer-as 11664;
    }

Thank You!

Luciano

Материал из Xgu.ru

Перейти к: навигация, поиск

Данная страница находится в разработке. Эта страница ещё не закончена. Информация, представленная здесь, может оказаться неполной или неверной. Если вы считаете, что её стоило бы доработать как можно быстрее, пожалуйста, скажите об этом.

BGP (Border Gateway Protocol) — это основной протокол динамической маршрутизации, который используется в Интернете.

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

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

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

Так как BGP оперирует большими объемами данных (текущий размер таблицы для IPv4 более 450 тысяч маршрутов), то принципы его настройки и работы отличаются от внутренних протоколов динамической маршрутизации (IGP).

[править] Терминология протокола

• Внутренний протокол маршрутизации (interior gateway protocol) – протокол, который используется для передачи информации о маршрутах внутри автономной системы.
• Внешний протокол маршрутизации (exterior gateway protocol) – протокол, который используется для передачи информации о маршрутах между автономными системами.
• Автономная система (autonomous system, AS) — набор маршрутизаторов, имеющих единые правила маршрутизации, управляемых одной технической администрацией и работающих на одном из протоколов IGP (для внутренней маршрутизации AS может использовать и несколько IGP).
• Транзитная автономная система (transit AS) — автономная система, через которую передается трафик других автономных систем.
• Путь (path) — последовательность состоящая из номеров автономных систем через которые нужно пройти для достижения сети назначения.
• Атрибуты пути (path attributes, PA) — характеристики пути, которые позволяют выбрать лучший путь.
• BGP speaker — маршрутизатор, на котором работает протокол BGP.
• Соседи (neighbor, peer) — любые два маршрутизатора, между которыми открыто TCP-соединение для обмена информацией о маршрутизации.
• Информация сетевого уровня о доступности сети (Network Layer Reachability Information, NLRI) — IP-префикс и длина префикса.

[править] Описание протокола

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

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

[править] Основные характеристики протокола

BGP это path-vector протокол с такими общими характеристиками:

• Использует TCP для передачи данных, это обеспечивает надежную доставку обновлений протокола (порт 179)
• Отправляет обновления только после изменений в сети (нет периодических обновлений)
• Периодически отправляет keepalive-сообщения для проверки TCP-соединения
• Метрика протокола называется path vector или атрибуты (attributes)

[править] Автономная система

Автономная система (autonomous system, AS) — это система IP-сетей и маршрутизаторов, управляемых одним или несколькими операторами, имеющими единую, четко определенную политику маршрутизации с Интернетом (RFC 1930).

Диапазоны номеров автономных систем (autonomous system number, ASN):

• 0-65535 (изначально определенный диапазон для ASN 16 бит)
• 65536-4294967295 (новый диапазон для ASN 32 бита (RFC 4893))

Использование:

• 0 и 65535 (зарезервированы)
• 1-64495 (публичные номера)
• 65552-4294967295 (публичные номера)
• 64512-65534 (приватные номера)
• 23456 (представляет 32-битный диапазон на устройствах, которые работают с 16-битным диапазоном)

[править] Описание работы протокола

• Таблица соседей (neighbor table) — список всех соседей BGP
• Таблица BGP (BGP table, forwarding database, topology database):
  • Список сетей, полученных от каждого соседа
  • Может содержать несколько путей к destination сетям
  • Атрибуты BGP для каждого пути
• Таблица маршрутизации — список лучших путей к сетям

По умолчанию BGP отправляет keepalive-сообщения каждые 60 секунд.

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

[править] Внутренний BGP (Internal BGP) и Внешний BGP (External BGP)

• Внутренний BGP (Internal BGP, iBGP) — BGP работающий внутри автономной системы. iBGP-соседи не обязательно должны быть непосредственно соединены.
• Внешний BGP (External BGP, eBGP) — BGP работающий между автономными системами. По умолчанию, eBGP-соседи должны быть непосредственно соединены.

Если iBGP-маршрутизаторы работают в нетранзитной AS, то соединение между ними должно быть full mesh.
Это следствие принципов работы протокола — если маршрутизатор, находящийся на границе AS, получил обновление, то он передает его всем соседям; соседи, которые находятся внутри автономной системы, больше это обновление не распространяют, так как считают, что все соседи внутри AS уже его получили.

[править] Таймеры протокола

• Keepalive Interval — Интервал времени в секундах, между отправкой сообщений keepalive. По умолчанию 60 секунд.
• Hold Time — Интервал времени в секундах, по истечении которого сосед будет считаться недоступным. По умолчанию 180 секунд.

[править] Типы сообщений BGP

У всех сообщений BGP такой формат заголовка:

|<-------------------------- 32 бита --------------------------->|

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                                                               |
+                                                               +
|                           Marker                              |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Length               |      Type     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Поля заголовка BGP-сообщений:

• Marker — поле, которое включено в заголовок для совместимости. Размер поля — 16 байт, все байты должны быть 1.
• Length — длина всего сообщения в октетах, включая заголовок. Поле может принимать значения от 19 до 4096.
• Type — тип передаваемого сообщения:
  • 1 — OPEN
  • 2 — UPDATE
  • 3 — NOTIFICATION
  • 4 — KEEPALIVE

[править] Open

Open — используется для установки отношений соседства и обмена базовыми параметрами. Отправляется сразу после установки TCP-соединения.

Формат сообщения Open:

|<-------------------------- 32 бита --------------------------->|

+-+-+-+-+-+-+-+-+
|    Version    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     My Autonomous System      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Hold Time           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         BGP Identifier                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opt Parm Len  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                       Optional Parameters                     |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Кроме стандартного заголовка пакета BGP, в сообщении Open такие поля:

• Version — версия протокола BGP
• My Autonomous System — номер автономной системы отправителя
• Hold Time — максимальное время в секундах, которое может пройти между получением Keepalive и сообщением Update. Время выбирается минимальным
• BGP Identifier — играет роль в выборе пути пересылки BGP-сообщений при наличии более одного канала связи между BGP-соседями
• Optional Parameters Length — если равен 0, то в маркер записываются единицы, а Optional Parameters имеет нулевую длину; если не равен 0, то в Optional Parameters записываются данные для определения кода, который указывается в маркере.
• Optional Parameters — играет роль в формировании и последующем определении кода в поле маркер.

[править] Update

Update — используется для обмена информацией маршрутизации.

Формат сообщения Update:

+-----------------------------------------------------+
|   Unfeasible Routes Length (2 octets)               |
+-----------------------------------------------------+
|  Withdrawn Routes (variable)                        |
+-----------------------------------------------------+
|   Total Path Attribute Length (2 octets)            |
+-----------------------------------------------------+
|    Path Attributes (variable)                       |
+-----------------------------------------------------+
|   Network Layer Reachability Information (variable) |
+-----------------------------------------------------+

[править] Notification

Notification — используется когда возникают ошибки BGP. После отправки сообщения сессия с соседом разрывается.

Формат сообщения Notification:

|<-------------------------- 32 бита --------------------------->|

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error code    | Error subcode |           Data                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Кроме стандартного заголовка пакета BGP, в сообщении Notification такие поля:

• Error Code — тип оповещения:
  • 1 — Message Header Error
  • 2 — OPEN Message Error
  • 3 — UPDATE Message Error
  • 4 — Hold Timer Expired
  • 5 — Finite State Machine Error
  • 6 — Cease

[править] Keepalive

Keepalive — используется для поддерживания отношений соседства, для обнаружения неактивных соседей.

Сообщения Keepalive состоят только из заголовка пакета (длина 19 октетов).

Если периодичность отправки keepalive-сообщений выставлена в 0, то сообщения не отправляются.

[править] Отношения соседства

Для того чтобы установить отношения соседства, в BGP надо настроить вручную каждого соседа.

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

• Внутренний BGP сосед (iBGP-сосед) — сосед, который находится в той же автономной системе, что и локальный маршрутизатор. iBGP-соседи не обязательно должны быть непосредственно соединены.
• Внешний BGP сосед (eBGP-сосед) — сосед, который находится в автономной системе отличной от локального маршрутизатора. По умолчанию, eBGP-соседи должны быть непосредственно соединены.

Тип соседа мало влияет на установку отношений соседства. Более существенные отличия между различными типами соседей проявляются в процессе отправки обновлений BGP и добавлении маршрутов в таблицу маршрутизации.

BGP выполняет такие проверки, когда формирует отношения соседства:

1. Маршрутизатор должен получить запрос на TCP-соединение с адресом отправителя, который маршрутизатор найдет указанным в списке соседей (команда neighbor).
2. Номер автономной системы локального маршрутизатора должен совпадать с номером автономной системы, который указан на соседнем маршрутизаторе командой neighbor remote-as (это требование не соблюдается при настройках конфедераций).
3. Идентификаторы маршрутизаторов (Router ID) не должны совпадать.
4. Если настроена аутентификация, то соседи должны пройти её.

BGP выполняет проверку таймеров keepalive и hold, однако несовпадение этих параметров не влияет на установку отношений соседства. Если таймеры не совпадают, то каждый маршрутизатор будет использовать меньшее значение таймера hold.

[править] Состояния связи с соседями

• Idle
• Connect
• Open sent
• Open confirm
  • active
• Established

Если не совпали IP-адреса с соседом, то этот сосед будет в состоянии active.

[править] Атрибуты пути (path attributes)

Атрибуты пути разделены на 4 категории:

1. Well-known mandatory — все маршрутизаторы, работающие по протоколу BGP, должны распознавать эти атрибуты. Должны присутствовать во всех обновлениях (update).
2. Well-known discretionary — все маршрутизаторы, работающие по протоколу BGP, должны распознавать эти атрибуты. Могут присутствовать в обновлениях (update), но их присутствие не обязательно.
3. Optional transitive — могут не распознаваться всеми реализациями BGP. Если маршрутизатор не распознал атрибут, он помечает обновление как частичное (partial) и отправляет его дальше соседям, сохраняя не распознанный атрибут.
4. Optional non-transitive — могут не распознаваться всеми реализациями BGP. Если маршрутизатор не распознал атрибут, то атрибут игнорируется и при передаче соседям отбрасывается.

Примеры атрибутов BGP:

• Well-known mandatory:
  • Autonomous system path
  • Next-hop
  • Origin
• Well-known discretionary:
  • Local preference
  • Atomic aggregate
• Optional transitive:
  • Aggregator
  • Communities
• Optional non-transitive:
  • Multi-exit discriminator (MED)
  • Originator ID
  • Cluster list

[править] Autonomous system path

Атрибут Autonomous system path (AS Path):

• Описывает через какие автономные системы надо пройти, чтобы дойти до сети назначения.
• Номер AS добавляется при передаче обновления из одной AS eBGP-соседу в другой AS.

Используется для:

• обнаружения петель
• применения политик

Каждый сегмент атрибута AS path представлен в виде поля TLV (path segment type, path segment length, path segment value):

• path segment type — поле размером 1 байт для которого определены такие значения:
  • 1 — AS_SET: неупорядоченное множество автономных систем, через которые прошел маршрут в сообщении Update,
  • 2 — AS_SEQUENCE: упорядоченное множество автономных систем, через которые прошел маршрут в сообщении Update
• path segment length — поле размером 1 байт. Указывает сколько автономных систем указано в поле path segment value
• path segment value — номера автономных систем, каждая представлена полем размером 2 байта.

[править] Next-hop

Атрибут Next-hop

• IP-адрес следующей AS для достижения сети назначения.
• Это IP-адрес eBGP-маршрутизатора, через который идет путь к сети назначения.
• Атрибут меняется при передаче префикса в другую AS

Third party next hop:

[править] Origin

Атрибут Origin — указывает на то, каким образом был получен маршрут в обновлении.

Возможные значения атрибута:

• 0 — IGP: NLRI получена внутри исходной автономной системы;
• 1 — EGP: NLRI выучена по протоколу Exterior Gateway Protocol (EGP). Предшественник BGP, не используется
• 2 — Incomplete: NLRI была выучена каким-то другим образом

[править] Local preference

Атрибут Local preference:

• Указывает маршрутизаторам внутри автономной системы как выйти за её пределы.
• Этот атрибут передается только в пределах одной автономной системы.
• На маршрутизаторах Cisco по умолчанию значение атрибута — 100.
• Выбирается та точка выхода у которой значение атрибута больше.
• Если eBGP-сосед получает обновление с выставленным значением local preference, он игнорирует этот атрибут.

[править] Atomic aggregate

Метка, указывающая, что NLRI является summary.

[править] Aggregator

Список RID и ASN маршрутизаторов, создавших summary NLRI.

[править] Communities

Атрибут community:

• Тегирование маршрутов
• Существуют предопределенные значения
• По умолчанию не пересылаются соседям
• Один из вариантов применения: передается соседней AS для управления входящим трафиком

Значения от 0x00000000 до 0x0000FFFF и от 0xFFFF0000 до 0xFFFFFFFF зарезервированы.

Как правило community отображаются в формате ASN:VALUE.
В таком формате, доступны для использования community от 1:0 до 65534:65535.
В первой части указывается номер автономной системы, а во второй значение community, которое определяет политику маршрутизации трафика.

Некоторые значения communities предопределены. RFC1997 определяет три значения таких community. Эти значения должны одинаково распознаваться и обрабатываться всеми реализациями BGP, которые распознают атрибут community.

Если маршрутизатор получает маршрут в котором указано предопределенное значение communities, то он выполняет специфическое, предопределенное действие основанное на значении атрибута.

Предопределенные значения communities (Well-known Communities):

• no-export (0xFFFFFF01) — Все маршруты которые передаются с таким значением атрибута community не должны анонсироваться за пределы конфедерации (автономная система, которая не является частью конфедерации считается конфедерацией). То есть, маршруты не анонсируются EBGP-соседям, но анонсируются внешним соседям в конфедерации,
• no-advertise (0xFFFFFF02) — Все маршруты которые передаются с таким значением атрибута community не должны анонсироваться другим BGP-соседям,
• no-export-subconfed (0xFFFFFF03) — Все маршруты которые передаются с таким значением атрибута community не должны анонсироваться внешним BGP-соседям (ни внешним в конфедерации, ни настоящим внешним соседям). В Cisco это значение встречается и под названием local-as.

[править] Multi exit discriminator (MED)

Атрибут MED:

• Используется для информирования eBGP-соседей о том, какой путь в автономную систему более предпочтительный.
• Атрибут передается между автономными системами.
• Маршрутизаторы внутри соседней автономной системы используют этот атрибут, но, как только обновление выходит за пределы AS, атрибут MED отбрасывается.
• Чем меньше значение атрибута, тем более предпочтительна точка входа в автономную систему.

[править] Weight (проприетарный атрибут Cisco)

Атрибут Weight:

• Позволяет назначить «вес» различным путям локально на маршрутизаторе.
• Используется в тех случаях, когда у одного маршрутизатора есть несколько выходов из автономной системы (сам маршрутизатор является точкой выхода).
• Имеет значение только локально, в пределах маршрутизатора.
• Не передается в обновлениях.
• Чем больше значение атрибута, тем более предпочтителен путь выхода.

[править] Выбор пути

Характеристики процедуры выбора пути протоколом BGP:

• В таблице BGP хранятся все известные пути, а в таблице маршрутизации — лучшие.
• Пути выбираются на основании политик.
• Пути не выбираются на основании пропускной способности.

Сначала проверяется:

• Доступен ли next-hop (Route Resolvability Condition)

  Для того чтобы next-hop считался доступным (accessible), необходимо чтобы в таблице маршрутизации был IGP-маршрут, который ведет к нему.

[править] Cisco

На маршрутизаторе Cisco, если не настроены никакие политики выбора пути, выбор пути происходит таким образом (на каждый следующий шаг маршрутизатор переходит только при совпадении значений на предыдущем):

1. Максимальное значение weight (локально для маршрутизатора).
2. Максимальное значение local preference (для всей AS).
3. Предпочесть локальный маршрут маршрутизатора (next hop = 0.0.0.0).
4. Кратчайший путь через автономные системы. (самый короткий AS_PATH)
5. Минимальное значение origin code (IGP < EGP < incomplete).
6. Минимальное значение MED (распространяется между автономными системами).
7. Путь eBGP лучше чем путь iBGP.
8. Выбрать путь через ближайшего IGP-соседа.
9. Выбрать самый старый маршрут для eBGP-пути.
10. Выбрать путь через соседа с наименьшим BGP router ID.
11. Выбрать путь через соседа с наименьшим IP-адресом.

[править] Juniper

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

1. проверка на доступность next-hop в локальной таблице маршрутизации. Если next-hop не доступен, маршрут отбрасывается.
2. маршрутизатор выбирает маршрут с наибольшим Local Preference атрибутом.
3. маршрутизатор выбирает маршрут с кратчайшим AS Path length.
4. маршрутизатор выбирает маршрут с наименьшим значением атрибута Origin (то есть отдается предпочтение IGP).
5. маршрутизатор выбирает маршрут с наименьшим значением MED. Этот шаг выполняется, по умолчанию, только для маршрутов из одной AS.
6. маршрутизатор выбирает маршруты, полученные от соседей EBGP нежели полученные от IBGP соседей. Если остальные маршруты EBGP-маршруты, маршрутизатор переходит к шагу 9.
7. маршрутизатор выбирает маршрут с наименьшей метрикой IGP к анонсируемому BGP Next Hop.
8. если используется Route Reflection для IBGP пиринга, маршрутизатор выбирает путь с наименьшим Cluster-List length.
9. маршрутизатор выбирает маршрут от партнера с наименьшим Router ID.
10. маршрутизатор выбирает маршрут от партнера с наименьшим Peer Address.

[править] BGP в маршрутизаторах Cisco

Основная страница: BGP в Cisco

[править] BGP в маршрутизаторах Juniper

Основная страница: BGP_в_Juniper

[править] BGP в Quagga

Основная страница: Quagga

[править] Конфигурационные файлы qua2, qua4, qua6

Конфигурационные файлы на странице BGP/config.

[править] Дополнительная информация

RFC:

• RFC 4456 — BGP Route Reflection: An Alternative to Full Mesh Internal BGP (iBGP)
• RFC 5065 — Autonomous System Confederations for BGP

Cisco Systems, Inc.
Устройства	Cisco 871 • Cisco Router • Cisco Switch • Сisco Сatalyst  • Cisco IPS • Cisco ASA • PIX • Dynamips
Безопасность (коммутаторы и маршрутизаторы)	Cisco Security • Port security • DHCP snooping • Dynamic ARP Protection • IP Source Guard • Аутентификация при доступе к сети • 802.1X в Cisco • Zone-Based Policy Firewall • Cisco NAT • NAT в Cisco  • Cisco SSH
Cisco ASA	Cisco ASA/NAT • Cisco ASA/Troubleshooting • Cisco ASA/IPS • Cisco ASA failover • Cisco ASA/Transparent firewall • Cisco ASA/Site-to-Site_VPN • Cisco ASA/Easy_VPN • Cisco ASA/WebVPN • Объединение OSPF-сетей туннелем между двумя системами ASA (без GRE) • Центр сертификатов на Cisco ASA
VPN	IPsec в Cisco • Cisco IOS Site-to-Site VPN  • DMVPN  • Cisco Easy VPN • Cisco Web VPN • Cisco ipsec preshared
Канальный уровень	CDP  • VLAN в Cisco  • ISL  • VTP  • STP в Cisco  • Cisco Express Forwarding  • Агрегирование каналов  • Зеркалирование трафика  • QinQ  • Frame Relay
Сетевой уровень	Маршрутизация в Cisco  • RIP  • EIGRP  • IS-IS  • OSPF • BGP  • PIM  • Multicast  • GLBP  • VRRP  • HSRP  • DHCP  • IPv6  • IPv6 vs IPv4  • Резервирование Интернет-каналов без использования BGP • Использование BGP для резервирования Интернет-каналов
Разное	Режим ROMMON в Cisco • Опция 82 DHCP • 802.1X и RADIUS • SNMP в Cisco • QoS в Cisco  • EEM  • Troubleshooting  • Автоматизация работы устройств Cisco  • Cisco NTP  • Cisco IP SLA  • Cisco Enhanced Object Tracking

BGP — Border Gateway Protocol
Основы	BGP  • Типы сообщений BGP  • BGP full view  • BGP RFC  • Bogon  • RIPE NCC  • RIS
Атрибуты BGP	BGP AS path  • BGP next-hop  • BGP origin  • BGP MED  • BGP weight  • BGP local preference  • BGP community
IBGP	BGP confederation  • BGP route reflector
Cisco	Cisco BGP filter order  • Cisco distribute-list  • Cisco prefix-list  • BGP AS path filter  • Cisco route-map  • Изменение значения AD для BGP в Cisco  • Команды отладки BGP  • Применение изменений в настройках политик BGP  • BGP synchronization  • BGP timers  • BGP ORF  • Процессы BGP в Cisco  • Просмотр информации BGP в Cisco
Маршрутизация	Выбор лучшего маршрута в BGP  • Маршрут по умолчанию в BGP  • Перераспределение маршрутов в BGP  • Суммирование маршрутов BGP
MP-BGP	BGP address-family
Безопасность	BGP Security  • Аутентификация BGP
Управление трафиком	Управление входящим трафиком BGP  • Управление исходящим трафиком BGP  • Балансировка трафика в BGP  • Использование BGP для резервирования Интернет-каналов  • BGP AS path prepend  • BGP conditional route injection  • BGP backdoor
Реализации	BGP в Cisco  • BGP в Quagga  • Zebra BGP
Утилиты BGP	BGP tools  • BGP Looking Glass  • BGPlay
Разное	BGP/config

Problem
You want to figure out why the BGP session is not being established.

Solution
Start by looking at the current state of the TCP sessions on the router:

aviva@RouterF> show system connections extensive

Also look at the information in the system logging files:

aviva@RouterF> show log messages

Check that the TCP session can pass Internet control packets:

aviva@RouterF> ping tos 0xc0 RouterD

Discussion
When two BGP peers have a problem establishing a BGP session, one of the first indications is that you see BGP hold-time expired error messages on the routers in the router’s system logging files. You also see that the State field in the show bgp neighbor command output is not Established and that the State field in the show bgp summary command is Active or Connect, indicating that the BGP session is not established.

The hold-time expired errors usually occur because the TCP session between a pair of peers cannot effectively transmit data between the routers, not because of a problem with BGP itself. When the TCP session doesn’t work properly, the BGP session times out, and BGP signals the problem by sending hold-time expired messages and generating a BGP Notification message to the remote peer. Notification messages are logged at the system logging severity level warning.

Some of the most frequent causes of hold-time expired errors are MTU issues on a directly connected link, issues related to forwarding of Internet control packets, and IGP failures on IBGP sessions.

Looking at the TCP MTU path behavior, first let’s look at the TCP session. By default, a TCP session transmits 576 bytes in a single packet to minimize the chances that the packet will be fragmented at a device along the path to the destination. Most links use an MTU of at least 1,500 bytes. Path MTU discovery, which is disabled by default in the JUNOS BGP, allows BGP to dynamically determine how large the packets can be in a TCP session without being fragmented. This means that BGP tries to use 576-byte packets for the TCP sessions. However, on directly connected EBGP sessions, TCP uses MTU-sized packets. If there is an MTU mismatch between the two sides of the TCP connection, the BGP session cannot be established. One workaround is to enable path MTU discovery within the BGP group:

[edit protocols bgp group external ]
aviva@RouterF# set mtu-discovery

When path MTU discovery is enabled, the don’t fragment ( DF) bit is set on all TCP packets sent by the BGP session.

When you are testing session connectivity, in addition to the standard ping command, send packets in which the Internet control CoS bit is set:

aviva@RouterF> ping tos 0xc0 RouterD

If the QoS parameters are misconfigured on a transit router, TCP connectivity can work for regular best-effort traffic but will break for Internet control traffic. The same behavior can happen when you are testing new software or new PICs.

Another way to get information about the TCP session and what might be malfunctioning is to look at the current state of TCP sessions:

aviva@RouterF> show system connections extensive | find tcp
tcp4 0 2 192.168.70.143.23 172.17.28.108.3350 ESTABLISHED
sndsbcc: 2 sndsbmbcnt: 256 sndsbmbmax: 266432
sndsblowat: 2048 sndsbhiwat: 33304
rcvsbcc: 0 rcvsbmbcnt: 0 rcvsbmbmax: 463360
rcvsblowat: 1 rcvsbhiwat: 57920
iss: 2677798142 sndup: 2677853922 sndcc: 0
snduna: 2677853922 sndnxt: 2677853924 sndwnd: 57920
sndmax: 2677853924 sndcwnd: 65535 sndssthresh: 1073725440
irs: 1577022682 rcvup: 1577023284 rcvcc: 0
rcvnxt: 1577023292 rcvadv: 1577081212 rcvwnd: 57920
rtt: 200130618 srtt: 301 rttv: 12
rttmin: 100 duration: 0 mss: 1448
flags: REQ_SCALE RCVD_SCALE REQ_TSTMP RCVD_TSTMP [0x1e0]

Also, use the information in the system logging files, which is very extensive and is similar to the output of the show system connections extensive command:

Aug 24 13:15:46 RouterF rpd[2797]: bgp_traffic_timeout: NOTIFICATION sent to 192.168.
14.1 (Internal AS 3356): code 4 (Hold Timer Expired Error), Reason: holdtime expired
for 192.168.14.1 (Internal AS 3356), socket buffer
sndcc: 0
rcvcc: 0 TCP state: 4,

snd_una: 1404695285
snd_nxt: 1404695285
snd_wnd: 16384
rcv_nxt: 4086106368
rcv_adv:
4086157473, keepalive timer 0

You can learn a lot of information about the TCP connection from the socket buffer information in the system logging message, which is a subset of BSD transmission control block ( TCB) parameters:

sndcc

Bytes on send buffer. A full send buffer typically means that packets from this host are not being acknowledged.

rcvcc

Bytes on receive buffer. Expect 0 bytes here because RPD should not declared a hold time expired if information is available about the buffer.

snd_una

snd_nxt

The difference between these two (snd_nxtsnd_una) is the amount of unacknowledged data on the TCP session.

snd_wnd

Size of the window advertised by the peer.

rcv_adv

rcv_nxt

The difference between these two (rcv_advrcv_nxt) is the size of the window advertised by the local TCP stack.

It is important to try to collect the information on both sides of the session. This gives an indication about whether the data path failure is unidirectional, bidirectional, or dependent on packet size.

If you are seeing hold-time expired errors between IBGP peers, check the IGP logs. If this correlates to a link failure in your IGP, this should probably be your starting point for diagnostics.

See Also
For information about BSD TCBs, see TCP/IP Illustrated (Addison-Wesley).

Introduction

This document describes how to troubleshoot the most common issues in Border Gateway Protocol (BGP) and provides basic guidelines.

Prerequisites

Requirements

There are no specific prerequisites for this document, basic BGP protocol knowledge is useful, you can refer to the BGP configuration guide for reference.

Components used

This document is not restricted to specific software and hardware versions, but commands are applicable for Cisco IOS® and Cisco IOS-XE®.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, ensure that you understand the potential impact of any command.

Background Information

This document describes a basic guide to troubleshoot the most common issues in Border Gateway Protocol (BGP), gives corrective actions, useful commands/debugs to detect the root cause of the problems, and best practices to avoid potential issues. Keep in mind that all possible variables and scenarios cannot be considered and a deeper analysis could be required by Cisco TAC.

Topology

Use this diagram as reference for outputs provided in this document.

Scenarios and Problems

Adjacency Down

If a BGP session is down and does not come up, issue the command: «show ip bgp all summary». Here you can find the current status of the session:

• If the session is not up state can vary between IDLE and ACTIVE (depends on the Finite State Machine process).
• If session is up, you see the number of prefixes received.

R2#show ip bgp all summary 
For address family: IPv4 Unicast
BGP router identifier 198.51.100.2, local AS number 65537
BGP table version is 19, main routing table version 19
18 network entries using 4464 bytes of memory
18 path entries using 2448 bytes of memory
1/1 BGP path/bestpath attribute entries using 296 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 7208 total bytes of memory
BGP activity 18/0 prefixes, 18/0 paths, scan interval 60 secs
18 networks peaked at 11:21:00 Jun 30 2022 CST (00:01:35.450 ago)

Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.0.23.3       4        65537       6       5       19    0    0 00:01:34       18
198.51.100.1    4        65536       0       0        1    0    0 never    Idle

No Connectivity

The first requirement that has to be ensured, is the connectivity between both peers so TCP session on port 179 can be established, either they are directly connected or not. A simple ping is useful for this matter. If peering is established between loopback interfaces, a loopback to loopback ping must be done. If a ping test is performed without specific loopback as the source interface, the outgoing physical interface IP address is used as the packet’s source IP address instead of the router’s loopback IP address.

If ping is not successful, consider these causes:

• No connected route peer or no route at all: «show ip route peer_IP_address« can be used
• Layer 1 issue: physical interface, SFP (connector), cable or external issue (transport and provider if applicable) needs to be considered.
• Check any firewall or access lists which can block connection.

If ping is successful, consider this:

Configuration Issues

• Wrong IP address or AS configured: For wrong IP address, there is no such message displayed but ensure proper configuration is done. For wrong AS,  you must see a message like this via «show logging»:

%BGP-3-NOTIFICATION: sent to neighbor 198.51.100.1 passive 2/2 (peer in wrong AS) 2 bytes 1B39

Check BGP configuration on both ends to correct AS numbers or peer IP address.

• Duplicate router ID:

%BGP-3-NOTIFICATION: sent to neighbor 198.51.100.1 passive 2/3 (BGP identifier wrong) 4 bytes 0A0A0A0A

Check BGP identifier on both ends via «show ip bgp all summary» and correct the duplicate issue, this can be achieved manually with global command «bgp router-id X.X.X.X» under bgp router configuration. As a best practice, ensure router ID is set manually to unique number.

• BGP source and TTL:

Most of the iBGP sessions are configured over the loopback interfaces reachable via an IGP. This loopback interface must be explicitly defined as the source, this is done by command «neighbor ip-address update-source interface-id«.

For eBGP peer, directly connected interfaces are usually used for peering and there is a check for Cisco IOS/Cisco IOS-XE to fulfill this purpose or does not even try to establish session. If eBGP is tried from loopback to loopback on directly connected routers, this check can be disabled for a specific neighbor on both ends via «neighbor ip-address disable-connected-check».

However, if there are multiple hops between the eBGP peers, a proper hop count is required, ensure the «neighbor ip-address ebgp-multihop [hop-count]« is configured with the correct hop count so session can be established.

If the hop-count is not specified, the default TTL value for iBGP sessions is 255, while the default TTL value for eBGP sessions is 1.

TCP Session Issues

A useful action to test port 179 is a manual telnet from one peer to the other:

R1#telnet 198.51.100.2 179
Trying 198.51.100.2, 179 ... Open

[Connection to 198.51.100.2 closed by foreign host]

Either Open/connection closed, or Connection refused by remote host indicates packets reach remote end, then, ensure there are no problems with control plane at far end. Otherwise, if there is a Destination unreachable, check any firewall or access lists which can block TCP port 179 or BGP packets or any packet loss on the path.

In case of authentication problem, the messages you can see:

%TCP-6-BADAUTH: Invalid MD5 digest from 198.51.100.1(179) to 198.51.100.2(20062) tableid - 0
%TCP-6-BADAUTH: No MD5 digest from 198.51.100.1(179) to 198.51.100.2(20062) tableid - 0

Check authentication methods, password and related configuration, and to further troubleshoot refer to this page: MD5 Authentication Between BGP Peers Configuration Example

If the TCP session does not come up, you can use the next commands for isolation:

show tcp brief all
show control-plane host open-ports
debug ip tcp transactions

Adjacency Bounces

If session is up and down, please look for «show log» and we can see some scenarios.

Interface Flap

%BGP-5-ADJCHANGE: neighbor 198.51.100.2 Down Interface flap

As message indicates, reason for this failure is the interface down situation, look for any physical issues on port/SFP, cable or disconnections.

Hold Timer Expired

%BGP-3-NOTIFICATION: sent to neighbor 198.51.100.2 4/0 (hold time expired) 0 bytes

It is a very common situation; it means that router did not receive or process a keepalive message or any update message before the hold timer expired. Device sends a notification message and closes the session. The most commons reasons for this issue are listed here:

• Interface issues: Look for any input errors, input queue drops or physical issues on both peers’ connected interfaces; «show interface» can be used for this purpose.
• Packet loss in transit: Sometimes, Hello packets can be dropped in transit, the best way to ensure this is a packet capture at interface level.
  • You can use Embedded Packet Capture on Cisco IOS and Cisco IOS—XE devices. 
  • In case packets are seen at interface level we need to be sure they reach control plane, EPC on control plane or «debug bgp [vrf name] ipv4 unicast keepalives» is useful.
• High CPU: A high CPU condition can cause drops on control plane, «show processes cpu [sorted|history]» is useful to identify problem and, depends on platform, the next troubleshooting. CPU Reference document 
• CoPP policy issues: Troubleshoot methodology varies for each platform and is out of scope for this document.
• MTU mismatch: If there are MTU discrepancies in the path, and if ICMP messages are blocked in the path from source to destination, PMTUD does not function and can result in session flap. Updates are sent with the negotiated MSS value and a DF bit set. If a device in the path or even the destination is not able to accept the packets with higher MTU, it sends an ICMP error message back to BGP speaker. The destination router either waits for the BGP keepalive or BGP update packet to update its hold down timer.
  • You can check the MSS negotiated with «show ip bgp neighbors ip_address«.

A Ping test to a specific neighbor with df set can show you if such MTU is valid along the path:

ping 198.51.100.2 size max_seg_size df

If MTU issues are found, an accurate review of the configuration must be done to ensure that the MTU values are consistent throughout the network.

Note: More information on MTU can be found here: BGP Neighbor Flaps with MTU Troubleshooting

AFI/SAFI Issues

%BGP-5-ADJCHANGE: neighbor 198.51.100.2 passive Down AFI/SAFI not supported
%BGP-3-NOTIFICATION: received from neighbor 198.51.100.2 active 2/8 (no supported AFI/SAFI) 3 bytes 000000

Address-family identifier (AFI) is a capability extension added by Multi-Protocol BGP (MP-BGP), it correlates to a specific network protocol, such as IPv4, IPv6, and the like, and additional granularity through a subsequent address-family identifier (SAFI), such as unicast and multicast. MBGP achieves this separation by BGP path attributes (PAs) MP_REACH_NLRI and MP_UNREACH_NLRI. These attributes are carried inside BGP update messages and are used to carry network reachability  information for different address families.

The message gives you the numbers of these AFI/SAFI registered by IANA:

IANA Address Family Numbers

Subsequent Address Family Identifiers (SAFI) Parameters

• Check BGP configuration for the address-families intended on both sides to correct any undesired address families.
• Use «neighbor ip-address dont-capability-negotiate» on both ends, for further information you can check: Unsupported Capabilities Cause BGP Peer Malfunction

Path Install and Selection

For a better explanation about how BGP works and select best path refer to document BGP Best Path Selection Algorithm.

Next Hop

For a route to be installed into our routing table, next hop needs to be reachable, otherwise, even if prefix is on our Loc-RIB BGP table, it does not get into RIB. As a loop avoidance rule, on Cisco IOS/Cisco IOS-XE, iBGP does not change next hop attribute and leaves AS_PATH alone while eBGP rewrites next hop and prepends its AS_PATH. 

You can check next hop via «show ip bgp [prefix]», it gives you the next hop and inaccessible word. In the example, this is a prefix announced by R1 via eBGP to R2 and learnt by R3 via iBGP connection from R2.

R3#show ip bgp 192.0.2.1
BGP routing table entry for 192.0.2.1/32, version 0
Paths: (1 available, no best path)
  Not advertised to any peer
  Refresh Epoch 1
  65536
    198.51.100.1 (inaccessible) from 10.0.23.2 (10.2.2.2)
      Origin incomplete, metric 0, localpref 100, valid, internal
      rx pathid: 0, tx pathid: 0
      Updated on Jul 1 2022 13:44:19 CST

On the output, next hop is the outgoing interface of R1 which is not known by R3. In order to fix this situation either you can advertise next-hop via IGP, static route… or use «neighbor ip-address next-hop-self» command on iBGP peer to modify the next-hop IP (which is directly connected). On diagram example, this configuration needs to be on R2; the neighbor towards R3 (neighbor 10.0.23.3 next-hop-self).

As a result, next hop changes (after a «clear ip bgp 10.0.23.2 soft») to directly connected interface (reachable) and prefix is installed.

R3#show ip bgp 192.0.2.1
BGP routing table entry for 192.0.2.1/32, version 24
Paths: (1 available, best #1, table default)
  Not advertised to any peer
  Refresh Epoch 1
  65536
    10.0.23.2 from 10.0.23.2 (10.2.2.2)
      Origin incomplete, metric 0, localpref 100, valid, internal, best
      rx pathid: 0, tx pathid: 0x0
      Updated on Jul 1 2022 13:46:53 CST

RIB failure

This happens when route cannot be installed into the Global RIB, which results in a RIB failure, common reason is when same prefix is already on RIB for another routing protocol with lower administrative distance but the exact reason for a RIB failure is seen with the command show ip bgp rib-failure. For deeper explanation you can consult link below:

Note: You can identify and correct such issue as explained in link Understand BGP RIB-failure and The Command bgp suppress-inactive

Race condition

The most common issue seen is when IGP is preferred over eBGP on mutual redistribution scenario. When an IGP route is redistributed into BGP, it is considered locally generated by BGP and gets a weight of 32768 by default. All prefixes received from a BGP peer are assigned a local weight of 0 by default. Therefore, if the same prefix must be compared, the prefix with the higher weight is installed in the routing table based on the BGP best path selection process and this is why IGP route is installed on RIB.

The solution for this problem, is to set a higher weight to for all routes received from the BGP peer under router bgp configuration:

neighbor ip-address weight 40000

Note: Refer to this page for a deeper explanation Understand the Importance of BGP Weight Path Attribute in Network Failover Scenarios

Other Issues

BGP Slow Peer

It is a peer that cannot keep up with the rate at which the sender generates update messages. There are many reasons for a peer to exhibit this problem; high CPU in one of the peers, excess traffic or traffic loss on a link, bandwidth resource, among others.

Note: Refer to this page to help identify and correct slow peers issues Use the BGP «Slow Peer» Feature to Resolve Slow Peer Issues

Memory Issues

BGP uses memory that is assigned to the Cisco IOS process to maintain network prefixes, best paths, polices and all related configuration to operate properly. The overall processes are seen with command «show processes memory sorted» 

R1#show processes memory sorted 
Processor Pool Total: 2121414332 Used:  255911152 Free: 1865503180
reserve P Pool Total:     102404 Used:         88 Free:     102316
 lsmpi_io Pool Total:    3149400 Used:    3148568 Free:        832

 PID TTY  Allocated      Freed    Holding    Getbufs    Retbufs Process
   0   0  266231616   81418808  160053760          0          0 *Init*          
 662   0   34427640      51720   34751920          0          0 SBC main process
  85   0    9463568          0    8982224          0          0 IOSD ipc task   
   0   0   34864888   25213216    8513400    8616279          0 *Dead*          
 504   0     696632          0     738576          0          0 QOS_MODULE_MAIN 
 518   0     940000       8616     613760          0          0 BGP Router      
 228   0     856064     345488     510080          0          0 mDNS            
  82   0     547096     118360     417520          0          0 SAMsgThread     
   0   0          0          0     395408          0          0 *MallocLite* 

Processor pool is the memory used; around 2.1 GB in the example. Next, we must look at the Holding column to identify the sub-process holding most of it. Then, we need to check the BGP sessions we have, how many routes are received, and configuration used.

Common steps to reduce memory holding by BGP:

• BGP filtering: If it is not necessary to receive a full BGP table, use policies to filter routes and install only the prefixes you need.
• Soft reconfiguration: Look for «neighbor ip_address soft-reconfiguration inbound» under BGP configuration; this command allows you to see all prefixes received before any inbound policy (Adj-RIB-in). However, this table needs around half of the current BGP Local RIB table to store this information so you can avoid this configuration unless it is compulsorily required, or your current prefixes are few.

Note: For further information on how to optimize BGP refer to this page Configure BGP Routers for Optimal Performance and Reduced Memory Consumption

High CPU

Routers use different processes for BGP to operate. To verify the BGP process is the cause of high CPU utilization, use the «show process cpu sorted» command.

R3#show processes cpu sorted 
CPU utilization for five seconds: 0%/0%; one minute: 0%; five minutes: 0%
 PID Runtime(ms)     Invoked      uSecs   5Sec   1Min   5Min TTY Process
 PID Runtime(ms)     Invoked      uSecs   5Sec   1Min   5Min TTY Process 
 163          36        1463         24  0.07%  0.00%  0.00%   0 ADJ background   
  62          28         132        212  0.07%  0.00%  0.00%   0 Exec             
   2          39         294        132  0.00%  0.00%  0.00%   0 Load Meter       
   1           0           4          0  0.00%  0.00%  0.00%   0 Chunk Manager    
   3          27        1429         18  0.00%  0.00%  0.00%   0 BGP Scheduler    
   4           0           1          0  0.00%  0.00%  0.00%   0 RO Notify Timers
  63           4          61         65  0.00%  0.00%  0.00%   0 BGP I/O          
  83         924          26      35538  0.00%  0.03%  0.04%   0 BGP Scanner      
  96         142       11651         12  0.00%  0.00%  0.00%   0 Tunnel BGP  
   7           0           1          0  0.00%  0.00%  0.00%   0 DiscardQ Backgro 

Here are the common processes, causes, and general steps to overcome high CPU utilization due to BGP:

• BGP Router: Runs once per second to safeguard faster convergence. Is one of the most important threads, it reads the bgp update messages, validates the prefixes/networks and attributes, update the per AFI/SAFI network/prefix table and attribute table, perform best-path calculation among many other tasks. 
  Huge route churn is a very common scenario that leads to this situation.
• BGP Scanner: Low-priority process that runs every 60 seconds by default. This process checks the entire BGP table to verify the next-hop reachability and updates the BGP table accordingly in case there is any change for a path. It runs through the Routing Information Base (RIB) for redistribution purposes.
  Check platform scale, as more prefixes and routes installed and TCAM used, more resources needed and, usually, an overloaded device leads into such situations.

Note: For further information on how to troubleshoot these two processes reference this page Troubleshoot High CPU Caused by the BGP Scanner or Router Process

• BGP I/O: Runs when BGP control packets are received and manages the queuing and processing of BGP packets. If there are excessive packets received in the BGP queue for a long period, or if there is a problem with TCP, the router shows symptoms of high CPU due to BGP I/O process. (Usually, BGP Router is also high in this situation. Look at the message counts to identify peer and capture packets to identify the source of these messages.)
• BGP Open: Process used on session establishment. Not a common high CPU issue unless session is stuck in Open State.
• BGP Event: Is responsible for next-hop processing. Look for next-hops flaps on prefixes received.

Related Information

• Technical Support & Documentation — Cisco Systems
• BGP configuration guide
• MD5 Authentication Between BGP Peers Configuration Example
• Embedded Packet Capture
• BGP Neighbor Flaps with MTU Troubleshooting

• IANA Address Family Numbers

• Subsequent Address Family Identifiers (SAFI) Parameters

• Unsupported Capabilities Cause BGP Peer Malfunction
• BGP Best Path Selection Algorithm
• Understand BGP RIB-failure and The Command bgp suppress-inactive
• Understand the Importance of BGP Weight Path Attribute in Network Failover Scenarios
• Use the BGP «Slow Peer» Feature to Resolve Slow Peer Issues
• Configure BGP Routers for Optimal Performance and Reduced Memory Consumption
• Troubleshoot High CPU Caused by the BGP Scanner or Router Process