Logo
  • ГЛАВНАЯ
  • ОБО МНЕ
  • СЕРТИФИКАТЫ
nocip.ssh@mail.ru
Главная  >  Cisco Routing

Диагностика BGP-соседств (Troubleshooting BGP Neighbor Adjacencies)


Создана 07.09.2026
Отредактирована 24.09.2026
BGP устанавливает соседства (neighbor adjacencies) вручную. Это отличается от EIGRP и OSPF, где вы активируете процесс на интерфейсе, и соседства формируются динамически. Как следствие, конфигурация BGP более подвержена человеческим ошибкам (human error), что приводит к большим затратам усилий при диагностике (troubleshooting). Кроме того, существует две разновидности BGP: Internal BGP (iBGP) и External BGP (eBGP). Умение понимать различия между ними и распознавать проблемы, связанные с каждой из них, важно для диагностики.
В этом обзоре рассматривается, как формируются BGP-соседства (neighbor relationships) и как распознавать проблемы, которые могут помешать их формированию.
Для проверки (verification) IPv4 Unicast BGP-соседей можно использовать две команды show: show bgp ipv4 unicast summary (это то же самое, что и старая команда show ip bgp summary) и show bgp ipv4 unicast neighbors (это то же самое, что и старая команда show ip bgp neighbors). Для первичной проверки (initial verification) соседей лучше всего использовать show bgp ipv4 unicast summary, поскольку она выдает сжатый (condensed) вывод. Вывод команды show bgp ipv4 unicast neighbors очень подробный (verbose) и не требуется для первичной проверки соседей. В Примере 1, который является образцом вывода команды show bgp ipv4 unicast summary, показано, что R1 имеет двух BGP-соседей. Один находится по IP-адресу 10.1.12.2, а другой — по адресу 10.1.13.3. Оба являются eBGP-соседями, поскольку их номера автономных систем (autonomous system number) не совпадают с локальным номером AS. Обратите внимание на колонку State/PfxRcd (Состояние/Получено префиксов). Если в этой колонке указано число (как в данном случае ноль), это означает, что BGP-соседство (neighbor relationship) успешно установлено. Если вы видите состояние Idle или Active, значит, существует проблема с формированием соседства (neighbor relationship).
📌 Ключевая тема
Пример 1. Проверка BGP-соседей с помощью команды show bgp ipv4 unicast summary

R1#show bgp ipv4 unicast summary BGP router identifier 10.1.13.1, local AS number 65501 BGP table version is 1, main routing table version 1 Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 10.1.12.2 4 65502 16 16 1 0 0 00:11:25 0 10.1.13.3 4 65502 15 12 1 0 0 00:09:51 0

⚠️ Важно
При проверке BGP-соседей всегда начинайте с команды show bgp ipv4 unicast summary. Если в колонке State/PfxRcd вы видите число — соседство установлено. Если видите Idle или Active — ищите проблему в настройках (неправильный IP-адрес соседа, несовпадающий AS, фильтры ACL или проблемы с достижимостью next-hop).
Кроме того, когда соседство устанавливается, генерируется syslog-сообщение, аналогичное следующему:
%BGP-5-ADJCHANGE: neighbor 10.1.12.2 Up
📌 Ключевая тема

Вот перечень причин, по которым BGP-соседство может не установиться:

  • Интерфейс не работает: Интерфейс должен быть в состоянии up/up.
  • Нарушена связность на Layer 3 (сетевом): Вы должны иметь возможность достичь IP-адреса, с которым пытаетесь установить соседство (adjacency).
  • Путь к соседу проходит через маршрут по умолчанию: Вы должны иметь возможность достичь соседа, используя маршрут, отличный от маршрута по умолчанию.
  • У соседа нет маршрута к локальному маршрутизатору: Оба маршрутизатора, устанавливающие BGP-пиринг (peering), должны иметь маршруты друг к другу.
  • Некорректный оператор neighbor (neighbor statement): IP-адрес и номер автономной системы (autonomous system number) в операторе neighbor ip_address remote-as as_number должны быть указаны точно.
  • ACL (Access Control Lists): Список контроля доступа (ACL) или межсетевой экран (firewall) блокируют TCP-порт 179.
  • BGP-пакеты отправляются с неправильного IP-адреса: Исходный IP-адрес (source IP) входящего BGP-пакета должен совпадать с локальным оператором neighbor.
  • TTL BGP-пакета истек (TTL expires): Сосед (peer) находится дальше, чем разрешено.
  • Несовпадение аутентификации (Mismatched Authentication): Оба маршрутизатора должны согласовывать параметры аутентификации.
  • Неверно настроенная группа пиров (Peer Group): Группы пиров (peer groups) упрощают повторяющиеся конфигурации BGP; однако, если они реализованы неаккуратно, это может помешать формированию соседств (neighbor relationships) или изучению маршрутов (routes).
  • Таймеры: Таймеры не обязаны совпадать; однако, если установлен параметр minimum holddown from neighbor, это может помешать установлению соседства (neighbor adjacency).
При диагностике (troubleshooting) BGP-соседств необходимо уметь выявлять эти различные проблемы и понимать причины их возникновения. Давайте рассмотрим их по отдельности.
Интерфейс не работает
Интерфейс с IP-адресом, который используется для установления BGP-соседств (neighbor relationships), должен находиться в состоянии up/up. Будем четкими: это может быть физический (physical) или логический (logical) интерфейс. Помните, что вы можете использовать loopback-интерфейс (loopback interface) в качестве источника (source) BGP-пакетов. Эта практика популярна, когда у вас есть избыточные (redundant) пути между соседями (neighbors). В таком случае, если один путь выйдет из строя, например, локальный физический интерфейс перейдет в состояние down, соседство все равно будет доступно через другой локальный физический интерфейс, поскольку loopback-интерфейс является источником (source) и получателем (destination) пакетов. Следовательно, если вы используете IP-адрес Loopback 0 в качестве источника BGP-пакетов, loopback-интерфейс должен быть в состоянии up/up, как и любой физический интерфейс, который может обеспечить достижимость IP-адреса, с которым вы пытаетесь установить соседство. Проверить состояние интерфейса можно с помощью команды show ip interface brief.
💡 Дополнительное пояснение  (Additional Note)
Почему Loopback так популярен в BGP?
  • Loopback-интерфейс всегда в состоянии up/up (если только вы его не выключите вручную).
  • Если физический интерфейс, через который идет BGP-сессия, упадет, сессия не оборвется, а переключится на другой доступный путь (при условии, что IGP знает альтернативный маршрут к loopback-адресу соседа).
  • Это повышает отказоустойчивость (redundancy) BGP-пиринга.

Нарушена связность на Layer 3 (Layer 3 Connectivity Is Broken)

Вам не обязательно быть непосредственно подключенным (directly connected) для установления BGP-соседства или находиться в одной подсети (same subnet), однако у вас должна быть связность на сетевом уровне (Layer 3 connectivity). Для проверки связности на Layer 3 используется команда ping. Если ping выполняется успешно, значит, связность на Layer 3 есть. Обратите внимание, что для наличия связности на Layer 3 у маршрутизатора должен быть маршрут (route) в таблице маршрутизации (routing table), который укажет правильное направление. Если маршрута к соседу не существует, соседство не может установиться.
При просмотре вывода команды show bgp ipv4 unicast summary в Примере 2 вы можете увидеть в поле State/PfxRcd состояние Idle. Это состояние возникает, когда локальный маршрутизатор не может установить TCP-соединение (TCP connection) с соседом. В данном примере R5 пытается установить соседство с маршрутизатором 2.2.2.2. Просмотр таблицы маршрутизации на R5 с помощью команды show ip route 2.2.2.2 255.255.255.255 и выполнение ping до 2.2.2.2 с R5, как показано в Примере 3, доказывает, что связность на Layer 3 отсутствует. При выполнении ping рекомендуется указывать источник (source). Источником будет IP-адрес локального устройства, с которым вы планируете установить BGP-пиринг (BGP peering).
Пример 2. Проверка состояния BGP (BGP State) с помощью команды show bgp ipv4 unicast summary

R5#show bgp ipv4 unicast summary BGP router identifier 10.1.45.5, local AS number 65502 BGP table version is 1, main routing table version 1 Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 2.2.2.2 4 65502 0 0 1 0 0 never Idle

Пример 3. Проверка наличия маршрута к соседу и успешности ping

R5#show ip route 2.2.2.2 255.255.255.255 % Network not in table R5#ping 2.2.2.2 source 5.5.5.5 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds: ..... Success rate is 0 percent (0/5)

Путь к соседу (Path to Neighbor) проходит через маршрут по умолчанию (Default Route)
📌 Ключевая тема
Продолжая предыдущее обсуждение нарушения связности на Layer 3 (Layer 3 connectivity), в Примере 4 показано, что маршрут к 2.2.2.2 отсутствует, однако ping до 2.2.2.2 выполняется успешно. Это происходит потому, что в таблице маршрутизации (routing table) на R5 присутствует маршрут по умолчанию (default route), как показано в Примере 5.
Пример 4. Отсутствует маршрут к соседу (No Route to Neighbor), но ping выполняется успешно (Ping Is Successful)

R5#show ip route 2.2.2.2 255.255.255.255 % Network not in table R5#ping 2.2.2.2 source 5.5.5.5 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds: Packet sent with a source address of 5.5.5.5 !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 84/91/104 ms

Пример 5. Проверка наличия маршрута по умолчанию (Default Route) в таблице маршрутизации (Routing Table)

R5#show ip route ...output omitted... Gateway of last resort is 10.1.45.4 to network 0.0.0.0 D*EX 0.0.0.0/0 [170/3328] via 10.1.45.4, 00:08:37, GigabitEthernet1/0 3.0.0.0/32 is subnetted, 1 subnets D 3.3.3.3 [90/131072] via 10.1.45.4, 00:53:34, GigabitEthernet1/0 4.0.0.0/32 is subnetted, 1 subnets D 4.4.4.4 [90/130816] via 10.1.45.4, 00:53:19, GigabitEthernet1/0 ...output omitted...

Несмотря на то, что мы можем достичь соседа через маршрут по умолчанию (default route), BGP не считает этот маршрут действительным (valid) для установления соседства (adjacency). При просмотре вывода команды show bgp ipv4 unicast summary на R5 в Примере 6 вы можете увидеть, что состояние (State) — Idle, что указывает на невозможность установить TCP-сессию (TCP session).
Пример 6. Проверка состояния BGP (BGP State) на маршрутизаторе R5 с помощью команды show bgp ipv4 unicast summary

R5# show bgp ipv4 unicast summary BGP router identifier 10.1.45.5, local AS number 65502 BGP table version is 1, main routing table version 1 Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 2.2.2.2 4 65502 0 0 1 0 0 never Idle

💡 Дополнительное пояснение
Почему BGP игнорирует default route?
BGP требует наличия конкретного (не default) маршрута к IP-адресу соседа в таблице маршрутизации. Это сделано для того, чтобы:
  • Обеспечить детерминированность (предсказуемость) BGP-сессии.
  • Избежать ситуаций, когда BGP-сессия пытается установиться через интерфейс, который может быть нестабильным или непредназначенным для BGP-трафика.
  • Обеспечить симметричную маршрутизацию (пакеты туда и обратно идут по одному и тому же пути).
Как исправить:
  • Добавьте статический маршрут (static route) к IP-адресу соседа:

ip route 2.2.2.2 255.255.255.255 10.1.12.2

  • Или убедитесь, что протокол IGP (OSPF, EIGRP) изучает маршрут к этому адресу.

У соседа нет маршрута к локальному маршрутизатору (Local Router)

До сих пор мы видели, что локальный маршрутизатор отображает состояние idle (Idle), когда у него нет маршрута к IP-адресу, с которым он пытается установить пиринг (peer). Однако состояние idle также появляется на маршрутизаторе, когда у соседа нет маршрута обратно к локальному маршрутизатору. В Примере 7 вы можете видеть, что маршрутизатор, пытающийся установить BGP-пиринг (BGP peering) с R5 (это R2), также отображает состояние idle, даже несмотря на то, что у него есть маршрут к 5.5.5.5, как показано в Примере 7. Состояние idle возникает из-за того, что маршрутизаторы не могут установить TCP-сессию (TCP session).
Пример 7. Проверка (Verifying) состояния BGP (BGP State) на маршрутизаторе R2 и маршрута (Route) к 5.5.5.5

R2#show bgp ipv4 unicast summary BGP router identifier 2.2.2.2, local AS number 65502 BGP table version is 1, main routing table version 1 Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 5.5.5.5 4 65502 0 0 1 0 0 00:00:13 Idle 10.1.12.1 4 65501 2 2 1 0 0 00:00:12 0

R2#show ip route 5.5.5.5 255.255.255.255 Routing entry for 5.5.5.5/32 Known via "eigrp 100", distance 90, metric 131072, type internal Redistributing via eigrp 100 Last update from 10.1.24.4 on GigabitEthernet2/0, 00:23:58 ago Routing Descriptor Blocks: * 10.1.24.4, from 10.1.24.4, 00:23:58 ago, via GigabitEthernet2/0 Route metric is 131072, traffic share count is 1 Total delay is 5020 microseconds, minimum bandwidth is 1000000 Kbit Reliability 255/255, minimum MTU 1500 bytes Loading 1/255, Hops 2

💡 Дополнительное пояснение
Важное правило BGP:
Для успешного установления BGP-сессии оба маршрутизатора должны иметь маршрут друг к другу. Это двустороннее требование.
Аналогия: представьте, что вы звоните другу. Ваш телефон должен иметь возможность набрать его номер (маршрут к нему), и его телефон должен иметь возможность набрать ваш номер (маршрут обратно к вам). Если хотя бы одно из условий не выполнено — звонок не состоится.
Как проверить:
1. На локальном маршрутизаторе:

show ip route [IP-адрес_соседа]

2. На удаленном маршрутизаторе (соседе):

show ip route [IP-адрес_локального_роутера]

Если на любой из сторон маршрут отсутствует — BGP-сессия останется в состоянии Idle.

Некорректный оператор neighbor (Incorrect neighbor Statement)

📌 Ключевая тема
Для установления BGP-пиринга (BGP peering) используется команда neighbor ip_address remote-as as_number в режиме конфигурации BGP. В Примере 8 показаны две команды neighbor remote-as на R2. Команда neighbor 5.5.5.5 remote-as 65502 устанавливает iBGP-пиринг (iBGP peering), а команда neighbor 10.1.12.1 remote-as 65501 — eBGP-пиринг (eBGP peering). iBGP-пиринг устанавливается потому, что remote-as 65502 совпадает с локальным номером автономной системы (local autonomous system number), использованным при создании BGP-процесса (router bgp 65502). eBGP-пиринг устанавливается потому, что remote-as 65501 отличается от локального номера автономной системы, использованного при создании BGP-процесса (router bgp 65502).
Пример 8. Проверка команд neighbor remote-as на маршрутизаторе R2

R2#show run | s router bgp router bgp 65502 bgp log-neighbor-changes neighbor 5.5.5.5 remote-as 65502 neighbor 5.5.5.5 update-source Loopback0 neighbor 10.1.12.1 remote-as 65501

В этой команде есть две очень важные части:
  1. IP-адрес пира (peer), с которым вы будете устанавливать пиринг;
  2. автономная система (autonomous system), в которой находится этот пир. Если вы допустите ошибку в любой из них, вы увидите состояние active (Active) или idle (Idle).
Как мы уже обсуждали, если маршрут к указанному IP-адресу отсутствует, состояние будет idle. Однако если маршрут найден и трехстороннее TCP-рукопожатие (three-way TCP handshake) завершено, отправляется open-сообщение (open message). Если ответа на open-сообщение нет, состояние перейдет в active.
Если указанный номер автономной системы (autonomous system number) не совпадает с номером AS пира, состояние будет переключаться (toggle) между idle и active.
Вы можете проверить состояние TCP-сессии (TCP session) на маршрутизаторах с помощью команды show tcp brief all. В Примере 9 видно, что R2 имеет установленную TCP-сессию (established TCP session) с устройством 5.5.5.5 и еще одним устройством 10.1.12.1.
Пример 9. Проверка состояния TCP-сессий (TCP Sessions)

R2#show tcp brief all TCB Local Address Foreign Address (state) 68DD357C 10.1.12.2.179 10.1.12.1.35780 ESTAB 68DD24DC 2.2.2.2.179 5.5.5.5.45723 ESTAB

💡 Дополнительное пояснение
Как отличить проблемы с IP-адресом от проблем с AS:
  • Idle (постоянно): нет маршрута к IP-адресу соседа.
  • Active (постоянно): маршрут есть, TCP рукопожатие прошло, но open-сообщение не получило ответа (обычно проблема с ACL или firewall).
  • Переключение Idle ↔ Active: несовпадение AS-номеров или проблема с аутентификацией.

BGP-пакеты отправляются с неправильного IP-адреса (BGP Packets Sourced from Wrong IP Address)

В избыточной (redundant) топологии BGP-маршрутизатор будет иметь несколько активных IP-адресов (active IP addresses), настроенных на различных интерфейсах. На Рисунке 1 изображены две BGP-автономные системы (autonomous systems). Обратите внимание, что R2, R3 и R4 могут устанавливать BGP-пиринг (BGP peering) друг с другом, используя любой физический интерфейс, благодаря множественным путям (multiple paths). Например, R2 может установить пиринг с R4 через прямое соединение (direct connection) или через соединение через R3.

direct connection [dɪˈrekt kəˈnekʃn] прямое подключение, непосредственное подключение

Рис. 1. Пример BGP-автономной системы с избыточностью (redundancy)
Когда вы вводите команду neighbor ip_address remote-as as_number на маршрутизаторе, указанный адрес используется маршрутизатором для определения, пришло ли BGP open-сообщение (open message) от маршрутизатора, с которым он должен установить BGP-пиринг. BGP open-сообщение будет иметь исходный IP-адрес (source IP address), и этот исходный IP-адрес сравнивается с адресом в локальной команде neighbor remote-as. Если они совпадают, BGP-пиринг устанавливается, если нет — BGP-пиринг не устанавливается. Исходный адрес (source address) определяется на основе исходящего интерфейса (exit interface) маршрутизатора, отправляющего BGP open-сообщение. Следовательно, если R2 отправляет BGP open-сообщение через интерфейс Gi2/0 на R4, то R4 должен иметь оператор neighbor с IP-адресом интерфейса Gi2/0 маршрутизатора R2. Теперь, если линк (link) между R2 и R4 выйдет из строя, R2 и R4 все еще смогут установить пиринг через линки через R3. Однако теперь R2 отправляет BGP open-сообщение с исходным IP-адресом интерфейса Gi0/0, но в операторе neighbor remote-as на R4 все еще используется IP-адрес интерфейса Gi2/0 маршрутизатора R2, и в результате BGP-пиринг не устанавливается, потому что BGP-пакеты отправляются с неправильного IP-адреса.
📌 Ключевая тема
Для управления IP-адресом, который используется при отправке BGP-сообщений, используется команда neighbor ip_address update-source interface_type interface_number. В Примере 10 показан вывод команды show run | section router bgp на R2. Обратите внимание, что пиринг с R4 использует адрес 4.4.4.4 (который является loopback-интерфейсом на R4), и все BGP-сообщения, отправляемые на 4.4.4.4, будут использовать IP-адрес loopback 0, который равен 2.2.2.2, как также показано в Примере 10.
Пример 10. Проверка состояния TCP-сессий (TCP Sessions)

R2#show run | section router bgp router bgp 65502 bgp log-neighbor-changes neighbor 4.4.4.4 remote-as 65502 neighbor 4.4.4.4 update-source Loopback0 neighbor 10.1.12.1 remote-as 65501 R2#show ip interface brief | include Loopback Loopback0 2.2.2.2 YES manual up up

Крайне важно (imperative), чтобы R4 также был настроен соответствующим образом. В данном случае R4 должен иметь оператор neighbor remote-as с адресом R2 — 2.2.2.2, а также оператор neighbor с опцией update-source, которая позволяет ему управлять исходным адресом (source address) BGP-сообщений, отправляемых на R2. В Примере 11 показана соответствующая конфигурация на R4 для обеспечения успешного BGP-пиринга.
Пример 11. Проверка того, что BGP-конфигурация на R4 зеркально отражает конфигурацию R2

R4#show run | section router bgp router bgp 65502 bgp log-neighbor-changes neighbor 2.2.2.2 remote-as 65502 neighbor 2.2.2.2 update-source Loopback0 R4#show ip interface brief | include Loopback Loopback0 4.4.4.4 YES manual up up

💡 Дополнительное пояснение  (Additional Note)
Зачем нужен update-source?
В избыточных топологиях физические интерфейсы могут выходить из строя. Если BGP-сессия привязана к IP-адресу физического интерфейса, при его падении сессия оборвется.
Решение: использовать loopback-интерфейс как источник BGP-пакетов:
  • Loopback всегда в состоянии up/up.
  • Если один физический канал падает, BGP-пакеты пойдут через другой интерфейс (при условии, что IGP знает маршрут к loopback-адресу соседа).
  • Это повышает отказоустойчивость (redundancy) BGP-пиринга.
Важно: конфигурация должна быть зеркальной (mirrored) с обеих сторон. Если R2 использует update-source Loopback0 (2.2.2.2) для пиринга с R4, то R4 должен использовать neighbor 2.2.2.2 remote-as ... и также настроить update-source Loopback0 (4.4.4.4) для пиринга с R2.
ACL (Access Control Lists)
BGP использует TCP-порт 179 для установления TCP-сессий (TCP sessions). Эта TCP-сессия затем используется для формирования BGP-пиринга. Если на любом участке пути между маршрутизаторами, пытающимися установить BGP-пиринг, настроен список контроля доступа (access control list, ACL), блокирующий TCP-порт 179, пиринг не установится. В Примере 12 на R4 (см. Рисунок 2) к интерфейсу Gig0/0 применен ACL 100, который запрещает (deny) пакеты с источником или назначением на порт 179 (BGP). В результате BGP-пиринг между R2 и R5 невозможен, поскольку пакеты, относящиеся к BGP-порту 179, блокируются. В нижней части Примера 12 показано состояние idle на R5, потому что TCP-сессия с соседом 2.2.2.2 не может быть установлена из-за того, что R4 блокирует TCP-трафик, связанный с портом 179.
Рис. 2. На маршрутизаторе R4 к интерфейсу Gig0/0 применен ACL 100
Пример 12. Проверка ACL, блокирующих BGP-пакеты, и состояния соседства (Neighbor Relationship) на R5

R4#show access-lists Extended IP access list 100 10 deny tcp any any eq bgp 20 deny tcp any eq bgp any 30 permit ip any any R4#show ip interface gigabitEthernet 0/0 | include access list Outgoing access list is 100 Inbound access list is not set

R5#show bgp ipv4 unicast summary BGP router identifier 10.1.45.5, local AS number 65502 BGP table version is 1, main routing table version 1 Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 2.2.2.2 4 65502 0 0 1 0 0 00:02:24 Idle

В Примере 12 ACL блокирует BGP-пакеты с источником или назначением на порт 179. Однако что, если ACL блокирует BGP-пакеты на порт 179 только в одном направлении? Например, запись была бы только deny tcp any any eq bgp, но при этом применялась бы на интерфейсе Gig0/0 исходяще (outbound). Это означает, что будут блокироваться только пакеты, направленные на порт 179 при выходе через Gig0/0. А что, если бы они исходили (sourced) с порта 179 при выходе? Тогда они больше не блокировались бы. Таким образом, в этом случае, если бы вы могли контролировать, кто является сервером (server) и клиентом (client) для BGP-сессий, вы все равно могли бы установить BGP-сессию.
Верно, BGP-сессии представляют собой отношение сервер/клиент (server/client relationship). Один маршрутизатор использует порт 179 (сервер), а другой — эфемерный порт (ephemeral port) (клиент). По умолчанию оба маршрутизатора пытаются установить TCP-сессию с помощью трехстороннего рукопожатия (three-way handshake), поскольку оба отправляют TCP-пакет syn, источником которого является эфемерный порт, а назначением — порт 179. Они оба отвечают syn/ack с источником 179 и назначением на эфемерный порт, а затем оба отправляют ack с источником из эфемерного порта на порт 179. Это приводит к возникновению двух BGP-сессий между устройствами, хотя должна быть только одна. Такая ситуация называется коллизией BGP-соединений (BGP connection collision), и BGP разрешает ее автоматически. Если кратко, маршрутизатор с более высоким BGP RID становится сервером (server).
Если вы хотите избежать этой проблемы, вы можете контролировать, кто является сервером и клиентом, с самого начала, используя команду neighbor ip_address transport connection-mode { active | passive }. Указывая active, вы обозначаете, что хотите, чтобы маршрутизатор активно инициировал TCP-сессию, следовательно, active означает клиент (client). Указывая passive, вы обозначаете, что хотите, чтобы маршрутизатор пассивно ожидал, пока другой маршрутизатор инициирует TCP-сессию; следовательно, passive означает сервер (server).
Используя команду show bgp ipv4 unicast neighbor, можно увидеть локальные и удаленные номера портов (local and remote port numbers), которые используются. Если локальный порт (local port) — это порт 179, а удаленный порт (remote port) — эфемерный, то локальный маршрутизатор является сервером (server). Если удаленный порт — 179, а локальный — эфемерный, то локальный маршрутизатор является клиентом (client). В Примере 13 команда show bgp ipv4 unicast neighbors | i ^BGP neighbor|Local port|Foreign port была использована для отображения соседей R2 вместе с локальным номером порта (local port) и удаленным номером порта (foreign port). Обратите внимание, что R2 является клиентом для TCP-сессий с R1 (1.1.1.1), R4 (4.4.4.4) и R5 (5.5.5.5), поскольку локальный порт — это случайный номер порта (random port number). R2 является сервером для TCP-сессии с R3, поскольку локальный порт — это BGP-порт 179.
Пример 13. Проверка локальных и удаленных BGP-портов (Local and Foreign BGP Port Numbers)

R2#show bgp ipv4 unicast neighbors | i ^BGP neighbor|Local port|Foreign port BGP neighbor is 1.1.1.1, remote AS 65501, external link Local host: 2.2.2.2, Local port: 23938 Foreign host: 1.1.1.1, Foreign port: 179 BGP neighbor is 3.3.3.3, remote AS 65502, internal link Local host: 2.2.2.2, Local port: 179 Foreign host: 3.3.3.3, Foreign port: 45936 BGP neighbor is 4.4.4.4, remote AS 65502, internal link Local host: 2.2.2.2, Local port: 34532 Foreign host: 4.4.4.4, Foreign port: 179 BGP neighbor is 5.5.5.5, remote AS 65502, internal link Local host: 2.2.2.2, Local port: 49564 Foreign host: 5.5.5.5, Foreign port: 179

TTL BGP-пакета истек (TTL of BGP Packet Expires)

По умолчанию eBGP-пиринг (eBGP peering) устанавливается между непосредственно подключенными (directly connected) маршрутизаторами. Это означает, что маршрутизаторы, формирующие eBGP-пиринг, должны находиться в пределах одного маршрутизаторного прыжка (router hop) друг от друга, IP-адрес соседа (neighbor) должен находиться в той же подсети, что и интерфейс, с которого отправляются BGP-пакеты Рисунок 3. В Примере 14 как раз рассмотрен этот случай, где можно увидеть конфигурацию маршрутизаторов R1 и R2.
При iBGP-пиринге маршрутизаторы могут находиться на расстоянии до 255 маршрутизаторных прыжков друг от друга и все равно устанавливать пиринг.
Рис. 3. Установка BGP-пиринга между R1 и R2 с использованием физических интерфейсов
Ключевое условие: IP-адрес соседа (10.1.12.2) находится в той же подсети, что и интерфейс Gi1/0 (10.1.12.1/30). Это означает, что маршрутизаторы directly connected — между ними нет промежуточных устройств.
Пример 14. Конфигурация на R1 и R2, по умолчанию eBGP-пиринг устанавливается между непосредственно подключенными (directly connected) маршрутизаторами.

R1(config)# interface GigabitEthernet1/0 R1(config-if)# ip address 10.1.12.1 255.255.255.252 R1(config-if)# no shutdown R1(config-if)# exit R1(config)# router bgp 65001 R1(config-router)# bgp log-neighbor-changes R1(config-router)# neighbor 10.1.12.2 remote-as 65002 R1(config-router)# exit

R2(config)# interface GigabitEthernet1/0 R2(config-if)# ip address 10.1.12.2 255.255.255.252 R2(config-if)# no shutdown R2(config-if)# exit R2(config)# router bgp 65002 R2(config-router)# bgp log-neighbor-changes R2(config-router)# neighbor 10.1.12.1 remote-as 65001 R2(config-router)# exit

В Примере 15 показан вывод команды show bgp ipv4 unicast neighbors | include BGP neighbor|TTL, который отображает, что eBGP-сосед (eBGP neighbor) 10.1.12.1 должен быть достижим за 1 маршрутизаторный прыжок, а iBGP-сосед (iBGP neighbor) 5.5.5.5 может находиться на расстоянии до 255 прыжков. Если сосед недостижим за указанное количество прыжков, BGP-пакет отбрасывается маршрутизатором, и соседство не устанавливается.
Пример 15. Проверка TTL eBGP и iBGP-пакетов

R2#show bgp ipv4 unicast neighbors | include BGP neighbor|TTL BGP neighbor is 5.5.5.5, remote AS 65502, internal link Minimum incoming TTL 0, Outgoing TTL 255 BGP neighbor is 10.1.12.1, remote AS 65501, external link Minimum incoming TTL 0, Outgoing TTL 1

Как говорилось выше в избыточных топологиях физические интерфейсы могут выходить из строя. Если BGP-сессия привязана к IP-адресу физического интерфейса, при его падении сессия оборвется. Решением будет использовать loopback-интерфейс как источник BGP-пакетов. Это популярная практика, потому что loopback обеспечивает отказоустойчивость (redundancy), если один физический линк упадет, BGP-сессия не оборвется, а переключится на другой путь. Но при этом мы получим, что TTL буде недостаточно велик для поддержки расстояния, необходимого для установления BGP-пиринга, пакет будет отброшен (discarded). Loopback-интерфейсы не являются directly connected — между ними всегда есть как минимум один промежуточный прыжок. С TTL = 1 пакет не дойдёт до цели. Рассмотрим более подробно как это происходит:
Рис. 4. Почему TTL = 1 недостаточен для eBGP-пиринга (eBGP peering) через loopback-интерфейсы
Что происходит (пошагово):
1. R1 отправляет BGP-пакет с TTL = 1. Источник — Loopback0 (1.1.1.1), назначение — Loopback0 R2 (2.2.2.2).
2. Пакет физически выходит через Gi1/0 (10.1.12.1) и направляется к R2. На этом этапе TTL = 1.
3. Пакет доходит до Gi1/0 на R2 (10.1.12.2) — это первый прыжок. TTL уменьшается с 1 до 0.
4. R2 проверяет TTL = 0 и понимает, что пакет не может быть доставлен дальше. Но цель пакета — не Gi1/0, а Loopback0 (2.2.2.2), который находится внутри R2 (второй прыжок).
5. R2 отбрасывает пакет, потому что TTL = 0, и не доставляет его до Loopback0. R2 отправляет ICMP Time Exceeded обратно на R1 (если это не запрещено ACL).
6. BGP на R1 не получает ответа (ни TCP SYN-ACK, ни BGP Open) и остается в состоянии Idle.
Ключевой момент: цель пакета — Loopback0 (2.2.2.2), а не Gi1/0 (10.1.12.2). Поскольку loopback-интерфейс находится за Gi1/0, требуется дополнительный прыжок внутри R2. TTL = 1 истекает до того, как пакет достигнет loopback-интерфейса.
Давайте установим eBGP-пиринг между R1 и R2 на Рисунке 5 с использованием их loopback-интерфейсов. R1 имеет loopback-интерфейс 1.1.1.1, а R2 имеет loopback-интерфейс 2.2.2.2. Связность на Layer 3 (Layer 3 connectivity) была проверена с помощью ping, и она успешна. И она не через маршрут по умолчанию (default route).
Рис. 5. Установка BGP-пиринга между R1 и R2 с использованием loopback-интерфейсов
В Примере 16 показана конфигурация R1 и R2. Обратите внимание, что R1 устанавливает пиринг с R2, используя адрес соседа 2.2.2.2 (loopback R2) и исходный адрес loopback 0 (1.1.1.1). R2 устанавливает пиринг с R1, используя адрес соседа 1.1.1.1 (loopback 0 R1) и исходный адрес loopback 0 (2.2.2.2). Обратите внимание, что эти loopback-интерфейсы не являются непосредственно подключенными (directly connected) (находятся на расстоянии более одного прыжка), и поскольку это eBGP-соседство, мы ожидаем, что пиринг не установится.
Пример 16. Проверка BGP-конфигурации на R1 и R2

R1#show run | s router bgp router bgp 65501 bgp log-neighbor-changes neighbor 2.2.2.2 remote-as 65502 neighbor 2.2.2.2 update-source Loopback0 neighbor 10.1.13.3 remote-as 65502

R2#show run | s router bgp router bgp 65502 bgp log-neighbor-changes neighbor 1.1.1.1 remote-as 65501 neighbor 1.1.1.1 update-source Loopback0 neighbor 5.5.5.5 remote-as 65502 neighbor 5.5.5.5 update-source Loopback0

Просмотр вывода команды show bgp ipv4 unicast summary, как показано в Примере 17, четко указывает, что пиринг не устанавливается, поскольку оба маршрутизатора находятся в состоянии idle. Это результат того, что eBGP-пиры не являются непосредственно подключенными (directly connected) (находятся на расстоянии более одного маршрутизаторного прыжка).
Пример 17. Проверка состояний BGP на R1 и R2

R1#show bgp ipv4 unicast summary BGP router identifier 10.1.13.1, local AS number 65501 BGP table version is 1, main routing table version 1 Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 2.2.2.2 4 65502 0 0 1 0 0 never Idle 10.1.13.3 4 65502 36 35 1 0 0 00:29:49 0

R2#show bgp ipv4 unicast summary BGP router identifier 2.2.2.2, local AS number 65502 BGP table version is 1, main routing table version 1 Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 1.1.1.1 4 65501 0 0 1 0 0 never Idle 5.5.5.5 4 65502 27 26 1 0 0 00:20:52 0

Рассмотрим схему доставки пакета:
Рис. 6. Схема доставки пакета
📌 Ключевая тема
Чтобы решить эту проблему с eBGP-соседями, вы можете изменить TTL eBGP-пакетов с помощью команды neighbor ip_address ebgp-multihop [TTL] . В данном случае двух прыжков было бы достаточно для решения проблемы. Таким образом, на R1 вы можете ввести neighbor 2.2.2.2 ebgp-multihop 2, а на R2 — neighbor 1.1.1.1 ebgp-multihop 2. Как вы можете видеть в Примере 18, теперь на R2 указано, что сосед 1.1.1.1 может находиться на расстоянии до двух прыжков, и что пиринг установлен (established), как показано в выводе команды show bgp ipv4 unicast summary.
Пример 18. Проверка измененных TTL eBGP-пакетов

R2#show bgp ipv4 unicast neighbors | include BGP neighbor|TTL BGP neighbor is 1.1.1.1, remote AS 65501, external link External BGP neighbor may be up to 2 hops away. BGP neighbor is 5.5.5.5, remote AS 65502, internal link Minimum incoming TTL 0, Outgoing TTL 255

R2#show bgp ipv4 unicast summary BGP router identifier 2.2.2.2, local AS number 65502 BGP table version is 1, main routing table version 1 Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 1.1.1.1 4 65501 2 4 1 0 0 00:00:04 0 5.5.5.5 4 65502 38 37 1 0 0 00:30:57 0

💡 Дополнительное пояснение
Почему TTL = 2 решает проблему?
С ebgp-multihop 2 TTL увеличивается до 2. Теперь пакет может пройти два прыжка:
1. Прыжок 1: R1 → R2 (через Gi1/0). TTL уменьшается с 2 до 1.
2. Прыжок 2: R2 Gi1/0 → R2 Loopback0. TTL уменьшается с 1 до 0.
3. Пакет доставлен на Loopback0 R2 (2.2.2.2). ✅
Рис. 7. Схема доставки пакета с TTL 2
📊 Сводная таблица: TTL и количество прыжков
Сценарий
Цель пакета
Прыжков
TTL = 1
TTL = 2
Физические интерфейсы
Gi1/0 соседа (10.1.12.2)
1
✅ Доставлен
✅ Доставлен
Loopback-интерфейсы
Loopback0 соседа (2.2.2.2)
2
❌ Отброшен
✅ Доставлен

Несовпадение аутентификации (Mismatched Authentication)

BGP поддерживает аутентификацию на основе MD5 (message digest 5) между пирами (peers). Как и во всех обсуждениях аутентификации, если какие-либо параметры не совпадают, пиринг (peering) не установится. Если у вас включена отправка syslog-сообщений (syslog messaging), несовпадение BGP-аутентификации сгенерирует syslog-сообщение от подсистемы TCP (TCP facility), как показано ниже:
%TCP-6-BADAUTH: No MD5 digest from 2.2.2.2(179) to 1.1.1.1(45577) tableid – 0
Кроме того, состояние BGP будет idle, как показано в Примере 19.
Пример 19. Проверка состояния соседа (Neighbor State) при несовпадении аутентификации

R1#show bgp ipv4 unicast summary BGP router identifier 1.1.1.1, local AS number 65501 BGP table version is 1, main routing table version 1 Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 2.2.2.2 4 65502 0 0 1 0 0 00:02:49 Idle 10.1.13.3 4 65502 7 5 1 0 0 00:02:48 0

💡 Дополнительное пояснение
Как настроить MD5-аутентификацию в BGP:

neighbor [IP-адрес] password [пароль]

Важные моменты:
  • Пароль должен быть одинаковым на обоих маршрутизаторах.
  • Если пароли не совпадают, TCP-соединение не будет установлено, и BGP-сессия останется в состоянии Idle.
  • В syslog-сообщении будет указано No MD5 digest, что явно указывает на проблему с аутентификацией.
  • MD5-аутентификация защищает BGP-сессию от атак типа "man-in-the-middle" (подмена маршрутизатора).
⚠️ Важное предупреждение (Caution)
При включении MD5-аутентификации на уже установленной BGP-сессии сессия немедленно оборвется и переустановится заново с использованием аутентификации. Убедитесь, что пароль настроен корректно на обеих сторонах, чтобы избежать длительного простоя.

Неверно настроенные группы пиров (Misconfigured Peer Groups)

Когда маршрутизатор с включенным BGP должен отправить обновления (updates), он строит отдельное обновление для каждого из своих соседей. Когда у маршрутизатора большое количество BGP-соседей, это может оказывать значительную нагрузку на CPU маршрутизатора. Для экономии вычислительных ресурсов (processing power) можно использовать BGP-группы пиров (BGP peer groups). С BGP-группами пиров маршрутизатор должен обработать BGP-обновление только один раз для всей группы, вместо того чтобы делать это для каждого соседа индивидуально. Однако, даже несмотря на то, что обновление обрабатывается только один раз, TCP-передача (TCP transmission) должна выполняться для каждого соседа отдельно. В дополнение к экономии ресурсов CPU, группы пиров позволяют уменьшить объем вводимых команд (или копирования и вставки). В Примере 20 показан пример конфигурации группы пиров. При диагностике проблем с группами пиров следует обращать внимание на несколько общих моментов:
  • Вы забыли связать IP-адрес соседа с группой пиров: После того как группа пиров создана, необходимо использовать команду neighbor ip_address peer-group peer_group_name, чтобы связать соседа с конфигурациями в группе пиров. Если вы забудете это сделать, IP-адрес соседа не будет использовать конфигурации из группы пиров. Он будет использовать конфигурации BGP вне группы пиров, что может помешать формированию соседства.
  • Группа пиров настроена некорректно: Возможно, вы упустили из виду, что то, что работает для одного соседа, может не работать для другого. Например, использование update-source Loopback 0 может хорошо работать для iBGP-пира, но не для eBGP-пира.
  • Фильтр маршрутов (route filter), примененный к группе, не подходит для всех пиров: Фильтр, примененный через route-map или любым другим способом, может не давать ожидаемого результата на всех маршрутизаторах. Будьте осторожны с фильтрами и убедитесь, что они дают желаемый результат для всех соседей в группе пиров.
  • Порядок выполнения операций (order of operations) дает нежелательный результат: Если между группой пиров и конкретным оператором neighbor есть конфликтующие записи, оператор neighbor имеет приоритет. В Примере 20 в группе пиров указано, что источник обновлений (update source) — Loopback 0. Однако для соседа 3.3.3.3 явно указано, что будет использоваться Loopback 1 с помощью команды neighbor 3.3.3.3 update-source Loopback1. Этот конкретный оператор neighbor переопределяет (overrides) группу пиров.
Пример 20. Пример конфигурации группы пиров (Peer Group Configuration)

R2#show run | section router bgp router bgp 65502 bgp log-neighbor-changes network 10.1.5.0 mask 255.255.255.0 neighbor TSHOOT_IBGP_NEIGHBORS peer-group neighbor TSHOOT_IBGP_NEIGHBORS transport connection-mode passive neighbor TSHOOT_IBGP_NEIGHBORS update-source Loopback0 neighbor TSHOOT_IBGP_NEIGHBORS next-hop-self neighbor TSHOOT_IBGP_NEIGHBORS route-map TSHOOT_BGP_FILTER out neighbor 1.1.1.1 remote-as 65501 neighbor 1.1.1.1 password C neighbor 1.1.1.1 ebgp-multihop 2 neighbor 1.1.1.1 update-source Loopback0 neighbor 3.3.3.3 remote-as 65502 neighbor 3.3.3.3 peer-group TSHOOT_IBGP_NEIGHBORS neighbor 3.3.3.3 update-source Loopback1 neighbor 4.4.4.4 remote-as 65502 neighbor 4.4.4.4 peer-group TSHOOT_IBGP_NEIGHBORS neighbor 5.5.5.5 remote-as 65502 neighbor 5.5.5.5 peer-group TSHOOT_IBGP_NEIGHBORS

📌 Ключевая тема
Приоритет конфигурации в BGP:
  1. Конкретные настройки для отдельного соседа (neighbor X.X.X.X ...) имеют приоритет над настройками группы пиров (peer-group).
  2. Если в группе пиров и в индивидуальной настройке есть конфликтующие параметры — побеждает индивидуальная настройка.
Пример из конфигурации выше:
  • Группа пиров TSHOOT_IBGP_NEIGHBORS задает update-source Loopback0.
  • Для соседа 3.3.3.3 явно задано update-source Loopback1.
  • В результате для соседа 3.3.3.3 будет использоваться Loopback1, а не Loopback0.
💡 Дополнительное пояснение
Когда использовать группы пиров:
  • Когда у вас много iBGP-соседей с одинаковыми настройками (например, update-source Loopback0, next-hop-self).
  • Для экономии CPU маршрутизатора (обновление генерируется один раз для всей группы).
  • Для упрощения конфигурации (меньше команд, меньше ошибок).
Когда НЕ использовать группы пиров:
  • Когда у соседей разные настройки (например, разные route-maps, разные update-source).
  • Для eBGP-соседей, у которых часто разные AS и настройки TTL.
Важно: если вы используете группу пиров, но для одного соседа нужны особые настройки — вы всегда можете переопределить их индивидуальной командой neighbor.
⚠️ Важное предупреждение
Если вы добавили соседа в группу пиров, но забыли применить к нему индивидуальные настройки (например, remote-as), соседство может не установиться. В примере выше у соседа 3.3.3.3 есть remote-as 65502, а у 4.4.4.4 и 5.5.5.5 — тоже. Убедитесь, что все необходимые параметры (особенно remote-as и update-source) присутствуют либо в группе, либо у каждого соседа индивидуально.

Таймеры в BGP

📌 Ключевая тема
Давайте внесем ясность, BGP-таймеры (BGP timers) не обязаны совпадать. Это связано с тем, что BGP будет использовать наименьшие значения таймеров, установленные между двумя соседями. Если R1 настроен с интервалом hello по умолчанию 60 и временем удержания (hold time) 180, а R3 настроен с hello 30 и hold time 90, то между двумя соседями будут использоваться hello 30 и hold time 90, как показано в Примере 21.
Обратите внимание, как R3 был настроен с минимальным временем удержания (minimum hold-time) в 90 секунд, это сделано для того, чтобы гарантировать, что если сосед использует агрессивные (aggressive) таймеры, они не будут использованы. Однако ситуация может быть гораздо хуже, чем простое неприменение таймеров. Соседство (neighbor relationship) вообще не установится.
Пример 21. Проверка BGP-таймеров

R1#show bgp ipv4 unicast neighbors 10.1.13.3 | include hold time|holdtime Last read 00:00:02, last write 00:00:29, hold time is 90, keepalive interval is 30 seconds Configured hold time is 180, keepalive interval is 60 seconds Minimum holdtime from neighbor is 90 second

R3#show bgp ipv4 unicast neighbors 10.1.13.1 | include hold time|holdtime Last read 00:00:10, last write 00:00:23, hold time is 90, keepalive interval is 30 seconds Configured hold time is 90, keepalive interval is 30 seconds Minimum holdtime from neighbor is 90 second

💡 Пояснение к Примеру 21:
  • R1 предлагает 180/60 (значения по умолчанию), но принимает от R3 минимум 90 (строка Minimum holdtime from neighbor is 90 second — это значение, полученное от R3, а не настроенное на R1).
  • R3 предлагает 90/30 и требует от соседа минимум 90.
  • BGP выбирает наименьшее → 90/30 для обоих.
Перейдем к Примеру 22. Давайте изменим таймеры: R1 будет иметь интервал hello = 10 и hold time = 30. R3 имеет минимальное время удержания (minimum hold time) = 90 секунд. Следовательно, R3 не согласится с 30-секундным hold time, предложенным R1, и соседство не установится.
После изменения таймеров на R1 сбросим BGP-сессию командой clear ip bgp 10.1.13.3, чтобы новые значения вступили в силу. При переустановке сессии R3 отправляет BGP-уведомление (BGP notification) на R1 с кодом unacceptable hold time, потому что предложенное значение (30 секунд) меньше минимального, которое принимает R3 (90 секунд).
В выводе вы можете увидеть, что R1 получает BGP-уведомление (BGP notification) от R3:
Пример 22. Изменение BGP-таймеров на значения, которые R3 не принимает

R1#config t Enter configuration commands, one per line. End with CNTL/Z. R1(config)#router bgp 65501 R1(config-router)#neighbor 10.1.13.3 timers 10 30 R1(config-router)#do clear ip bgp 10.1.13.3 R1(config-router)# %BGP-5-ADJCHANGE: neighbor 10.1.13.3 Down User reset %BGP_SESSION-5-ADJCHANGE: neighbor 10.1.13.3 IPv4 Unicast topology base removed from session User reset %BGP-3-NOTIFICATION: received from neighbor 10.1.13.3 active 2/6 (unacceptable hold time) 0 bytes %BGP-5-NBR_RESET: Neighbor 10.1.13.3 active reset (BGP Notification received) %BGP-5-ADJCHANGE: neighbor 10.1.13.3 active Down BGP Notification received %BGP_SESSION-5-ADJCHANGE: neighbor 10.1.13.3 IPv4 Unicast topology base removed from session BGP Notification received R1(config-router)# %BGP-3-NOTIFICATION: received from neighbor 10.1.13.3 active 2/6 (unacceptable hold time) 0 bytes R1#

💡 Пояснение к Примеру 22:
  • Уведомление unacceptable hold time появляется дважды — R1 после сброса сессии снова пытается установить соседство, и R3 снова отклоняет его, потому что hold time = 30 по-прежнему меньше минимума 90.
  • После второго отклонения строка %BGP-5-ADJCHANGE не появляется, потому что сессия уже находилась в состоянии Active (не Established). R1 продолжает попытки установить соседство, но R3 каждый раз отклоняет их.
Резюмируя по таймерам (timers): они не обязаны совпадать, но если установлено минимальное время удержания (minimum hold time), наименьшие таймеры не должны быть меньше этого минимума; в противном случае соседство (neighbor relationship) не установится. После изменения таймеров необходимо сбросить BGP-сессию командой clear ip bgp, чтобы новые значения вступили в силу.
💡 Дополнительное пояснение

Как работают BGP-таймеры:

  • Keepalive (hello): интервал между отправкой Keepalive-сообщений (по умолчанию 60 секунд).
  • Hold time: время, в течение которого маршрутизатор ждет Keepalive от соседа перед разрывом сессии (по умолчанию 180 секунд, обычно = 3 × Keepalive).
  • При установке сессии BGP выбирает наименьшие значения из предложенных обоими соседями.

Зачем нужен minimum hold time:

  • Защита от слишком агрессивных таймеров (например, Keepalive = 1 секунда), которые могут создать излишнюю нагрузку на CPU и каналы связи.
  • Если сосед предлагает hold time меньше, чем установленный minimum — сессия не установится, и вы получите уведомление unacceptable hold time.
⚠️ Важное предупреждение
Настройка таймеров — это единственный параметр BGP, который не обязан совпадать на обеих сторонах. Однако будьте осторожны с параметром minimum hold time — если вы установите его слишком высоким, а сосед предложит меньшее значение, сессия не установится, и вы получите ошибку в логах:
%BGP-3-NOTIFICATION: received from neighbor X.X.X.X active 2/6 (unacceptable hold time)
Всегда проверяйте, что ваш minimum hold time не превышает то значение, которое готов предложить сосед.

Приветствуем всех любителей ретро-игровой индустрии на канале RetraR
Сувенирная и брендированная продукция с персонажами из любимых игр.
RetraR — Компьютерные игры для Nintendo Game Boy
RetraR - Computer games for Nintendo Game Boy 🌌🛸👽👾☄️🤖
RetraR - 任天堂ゲームボーイ用コンピュータゲーム 🎮🕹️👾

RetraR в VK
Канал - RetraR в Telegram
Канал - RetraR в Telegram

Оформить заказ

Нажимая на кнопку, вы даете согласие на обработку персональных данных

Спасибо за заказ

Ваш заказ принят в обработку. 

Мы свяжемся с вами в ближайшее время.