Использование команд debug в BGP (Using debug Commands)

Создана 07.09.2026
Отредактирована 23.09.2026

Большинство изменений, происходящих в BGP, генерируют syslog-сообщения в режиме реального времени. Следовательно, вы будете уведомлены через syslog, если возникнут какие-либо проблемы с соседями (neighbor issues). Поэтому, если вам действительно не нужно, избегайте использования большого количества доступных отладок (debugs), потому что они создают большую нагрузку на ресурсы маршрутизатора (routers' resources). Используйте их только в крайнем случае (as a last resort)! Ниже вы найдёте несколько команд debug, которые могут быть полезны. Однако до этого момента все команды show, которые мы рассмотрели, и ваши знания могут определить то же самое.

Пример 3 содержит образец вывода команды debug ip routing. Вывод этой команды показывает обновления (updates) таблицы IP-маршрутизации маршрутизатора. В этом примере next-hop шлюз (next-hop gateway) для сети 10.3.3.3/32 изменился с 172.16.1.1 на 172.16.2.2, а затем вернулся обратно на 172.16.1.1. Поскольку next-hop шлюз изменился, вы можете видеть, что маршрут 10.3.3.3/32 был удалён, а затем добавлен обратно в таблицу IP-маршрутизации этого маршрутизатора. Обратите внимание, что этот вывод не специфичен для BGP. Следовательно, вы можете использовать команду debug ip routing с другими процессами маршрутизации, а не только с BGP.

Пример 3. Вывод команды debug ip routing (debug ip routing Command Output)

R2#debug ip routing IP routing debugging is on RT: 10.3.3.3/32 gateway changed from 172.16.1.1 to 172.16.2.2 ← next hop изменился RT: NET-RED 10.3.3.3/32 RT: del 10.3.3.3/32 via 172.16.2.2, bgp metric [20/0] ← маршрут удалён RT: delete subnet route to 10.3.3.3/32 RT: NET-RED 10.3.3.3/32 RT: SET_LAST_RDB for 10.3.3.3/32 NEW rdb: via 172.16.1.1 ← next hop вернулся RT: add 10.3.3.3/32 via 172.16.1.1, bgp metric [20/0] ← маршрут добавлен RT: NET-RED 10.3.3.3/32

Пример 4 содержит образец вывода команды debug ip bgp. Вывод этой команды не показывает содержимое BGP-обновлений (BGP updates), однако эта команда может быть полезна для наблюдения за изменениями состояния (state changes) в реальном времени для IPv4 BGP-соседств (peering relationships).

Пример 4. Вывод команды debug ip bgp (debug ip bgp Command Output)

R2#debug ip bgp BGP debugging is on for address family: IPv4 Unicast *Mar 1 00:23:26.535: BGP: 172.16.1.1 remote close, state CLOSEWAIT *Mar 1 00:23:26.535: BGP: 172.16.1.1 -reset the session *Mar 1 00:23:26.543: BGPNSF state: 172.16.1.1 went from nsf_not_active to nsf_not_active *Mar 1 00:23:26.547: BGP: 172.16.1.1 went from Established to Idle *Mar 1 00:23:26.547: %BGP-5-ADJCHANGE: neighbor 172.16.1.1 Down Peer closed the session *Mar 1 00:23:26.547: BGP: 172.16.1.1 closing *Mar 1 00:23:26.651: BGP: 172.16.1.1 went from Idle to Active *Mar 1 00:23:26.663: BGP: 172.16.1.1 open active delayed 30162ms (35000ms max, 28% jitter)

В этом примере вы можете видеть, как сессия соседства (peering session) закрывается для соседа с IP-адресом 172.16.1.1, а затем маршрутизатор пытается установить её заново. Разберём вывод построчно:

1. BGP: 172.16.1.1 remote close, state CLOSEWAIT — удалённая сторона (сосед 172.16.1.1) инициировала закрытие TCP-соединения. Локальный маршрутизатор переходит в состояние CLOSEWAIT (ожидание завершения закрытия).

2. BGP: 172.16.1.1 -reset the session — сессия сбрасывается.

3. BGPNSF state: 172.16.1.1 went from nsf_not_active to nsf_not_active — состояние механизма BGP NSF (Non-Stop Forwarding) не изменилось (осталось nsf_not_active). Это означает, что отказоустойчивость BGP не задействована.

4. BGP: 172.16.1.1 went from Established to Idle — сессия переходит из состояния Established (установлена) в Idle (не установлена).

5. %BGP-5-ADJCHANGE: neighbor 172.16.1.1 Down Peer closed the session — syslog-сообщение: сосед 172.16.1.1 закрыл сессию (Peer closed the session).

6. BGP: 172.16.1.1 closing — сессия закрывается.

7. BGP: 172.16.1.1 went from Idle to Active — маршрутизатор начинает новую попытку установить TCP-соединение (переход в состояние Active).

8. BGP: 172.16.1.1 open active delayed 30162ms (35000ms max, 28% jitter) — BGP откладывает попытку установить сессию на ~30 секунд (с случайным отклонением до 35 секунд). Это защита от флаппинга (flapping) — чтобы не пытаться установить сессию слишком часто.

📌 Ключевая тема

Что показывает debug ip bgp:

Изменения состояния BGP-соседств (Established → Idle → Active).

Причины закрытия сессии (remote close, Peer closed the session).

Механизмы защиты (BGP NSF, задержка перед повторной попыткой).

НЕ показывает содержимое BGP-обновлений (для этого нужен debug ip bgp updates).

💡 Дополнительное пояснение

Расшифровка состояний BGP

Состояние	Что означает
Idle	Сессия не установлена. Маршрутизатор не пытается установить соединение.
Active	Маршрутизатор пытается установить TCP-соединение (отправляет SYN).
Established	Сессия установлена. Маршрутизаторы обмениваются BGP-обновлениями.
CLOSEWAIT	TCP-соединение закрывается удалённой стороной.

Что такое BGP NSF (Non-Stop Forwarding)

BGP NSF — это механизм, который позволяет маршрутизатору сохранять маршруты во время перезагрузки контрольной панели (control plane). Если NSF активен, BGP-сессия не разрывается при перезагрузке.

В примере:

BGPNSF state: 172.16.1.1 went from nsf_not_active to nsf_not_active

Это означает, что NSF не активен — сессия разрывается при перезагрузке.

Что такое "open active delayed"

BGP: 172.16.1.1 open active delayed 30162ms (35000ms max, 28% jitter)

30162ms — фактическая задержка (~30 секунд).

35000ms max — максимальная задержка (35 секунд).

28% jitter — случайное отклонение (jitter), чтобы избежать синхронизации попыток.

Зачем это нужно: если сессия постоянно падает и восстанавливается (флаппинг), BGP увеличивает интервал между попытками, чтобы не перегружать CPU и сеть.

⚠️ Важное предупреждение

debug ip bgp — безопаснее, чем debug ip bgp updates.

debug ip bgp показывает только изменения состояния — вывод небольшой.

debug ip bgp updates показывает содержимое обновлений — вывод огромный, может перегрузить CPU.

Но: даже debug ip bgp может создать нагрузку на больших сетях с частыми изменениями состояния. Используйте с осторожностью.

Команда debug ip bgp updates в Примере 5 выдаёт более подробный вывод, чем debug ip bgp. В частности, вы можете видеть содержимое IPv4 BGP-обновлений (BGP updates). В этом примере вы видите, как маршрут 10.3.3.3/32 добавляется в таблицу IP-маршрутизации маршрутизатора.

Пример 5. Вывод команды debug ip bgp updates (debug ip bgp updates Command Output)

R2# debug ip bgp updates BGP updates debugging is on for address family: IPv4 Unicast *Mar 1 00:24:27.507: BGP(0): 172.16.1.1 rcv UPDATE about 10.3.3.3/32 — withdrawn *Mar 1 00:24:27.515: BGP(0): Revise route installing 1 of 1 routes for 10.3.3.3/32 -> 172.16.2.2(main) to main IP table ...выходные данные опущены...