BGP_HOLD_TIMER_EXPIRED Сетевое оборудование и VPN

BGP Error Notification Code 4: Hold Timer Expired — Причины флапа пиров

Обновлено: 25.08.2026 · Официальная документация ↗

BGP сессия переходит в состояние Idle ровно через 90 или 180 секунд после установления.
Маршрутизатор логирует ошибку: %BGP-3-NOTIFICATION: sent/received 4/0 (Hold Timer Expired).
В выводе show ip bgp summary счетчики MsgRcvd перестают увеличиваться, несмотря на активный линк.
Пакеты BGP KEEPALIVE теряются в очередях Control Plane Policing (CoPP) или на перегруженных L2 каналах.

1. Проверка текущих таймеров BGP соседа

# Cisco IOS / FRR:
show ip bgp neighbors <PEER_IP> | grep -E "Hold time|Keepalive"

По умолчанию Keepalive = 60s, Hold Time = 180s (или 30s / 90s). Если за время Hold Time не получено ни одного KEEPALIVE или UPDATE, сессия разрывается.

2. Проверка загрузки CPU Control Plane маршрутизатора

Если процесс BGP не успевает обработать входящие KEEPALIVE из-за 100% утилизации CPU:

# Linux / FRR:
top -b -n 1 | grep bgpd
# Cisco:
show processes cpu sorted | exclude 0.00

3. Проверка дропов в политиках CoPP (Control Plane Policing)

Убедитесь, что фильтр защиты управляющего процессора не отбрасывает BGP трафик (TCP порт 179):

show policy-map control-plane | section class-default|bgp

4. Диагностика односторонней потери пакетов (Unidirectional Link)

# Запустите пинг большими пакетами с установленным DF-битом:
ping <PEER_IP> size 1400 df-bit repeat 100

5. Настройка BFD (Bidirectional Forwarding Detection) для быстрого детектирования

Вместо уменьшения таймеров BGP используйте протокол BFD для аппаратного контроля линка:

router bgp 65001
 neighbor 192.0.2.2 bfd
 neighbor 192.0.2.2 timers 30 90

💡 Практика специалистов: Не занижайте BGP таймеры до экстремальных значений (например, 1s / 3s) без аппаратной поддержки BFD. Любой кратковременный всплеск загрузки CPU вызовет лавинообразный сброс BGP пирингов.

Частые вопросы (FAQ)

Почему Hold Timer Expired часто случается во время передачи полной таблицы Full-View?

При передаче сотен тысяч маршрутов поток UPDATE сообщений забивает очередь сокета или перегружает CPU, из-за чего легковесные KEEPALIVE пакеты задерживаются и не обрабатываются вовремя.

Что произойдет, если установить Hold Time = 0?

Значение Hold Time 0 полностью отключает проверку активности (таймер никогда не истекает), и KEEPALIVE пакеты не отправляются. Сессия будет жить вечно, пока жив TCP сокет.

Как влияет MTU Mismatch на ошибку Hold Timer Expired?

Мелкие KEEPALIVE (19 байт) проходят успешно, но как только начинается передача крупного UPDATE пакета, превышающего реальный L2 MTU, пакет теряется, блокируя весь последующий TCP поток до истечения Hold Time.

Каково оптимальное соотношение таймеров Keepalive и Hold Time?

Стандартное соотношение: Keepalive = 1/3 от Hold Time (например, 10s / 30s для быстрого обнаружения или 60s / 180s для стабильных медленных сетей).