Проект DMVPN с двумя концентраторами – падение соседства BGP несмотря на стабильную работу IPSec/NHRP

[bravealikhan]

Привет всем, Мы используем среду DMVPN с двумя концентраторами (фаза 3) на маршрутизаторах Cisco ISR 4400 (IOS-XE 17.9.x).
Все маршрутизаторы-спицы имеют двойное подключение — каждый из них формирует туннели как к концентратору DC-A, так и к концентратору DC-B. Недавно несколько spoke потеряли BGP-пиринг с DC-A, в то время как DC-B остается полностью стабильным.
Туннели DMVPN полностью работают — сеансы NHRP и IPSec установлены, и хаб показывает все записи spoke в базе данных NHRP. Однако при проверке BGP соседи spoke под DC-A: Успешно устанавливают соединение, обмениваются несколькими обновлениями,
Затем отключаются в течение нескольких секунд,
и сразу же пытаются восстановить соединение (непрерывное колебание). До появления этого поведения не было никаких изменений в конфигурации или работ по техническому обслуживанию — оно началось внезапно на нескольких спиках. Мы проверили и перепроверили оба концентратора:
![:white_heavy_check_mark:]
Конфигурация туннеля DMVPN идентична (включая
tunnel vrf
,
protection ipsec profile
параметры NHRP).
![:white_heavy_check_mark:]
Профили IPSec и IKEv2 совпадают на обоих концентраторах.
![:white_heavy_check_mark:]
Настройки MTU и TCP MSS верны.
![:white_heavy_check_mark:]
ACL и правила NAT согласуются
![:white_heavy_check_mark:]
Настройка маршрутного рефлектора, VRF и политики BGP идентичны. Были сделаны следующие наблюдения: show dmvpn
подтверждает, что все туннели spoke работают и стабильны на DC-A.
show ip bgp all summary
Показывает, что под подсетью DMVPN формируются динамические соседи, но каждая сессия обрывается через несколько секунд.
Нет связанных сбоев syslog или криптосессий.
Таймеры BGP и NHRP настроены по умолчанию.
Концентратор DC-B продолжает поддерживать BGP-пиринг с теми же спицами без каких-либо проблем. Кто-нибудь сталкивался с подобным ранее — туннели DMVPN работают, но динамические пиринги BGP постоянно сбрасываются только на одном концентраторе? Буду очень благодарен за любые предложения, идеи или подобный опыт. Спасибо

[bravealikhan]

Проблема теперь решена. Мы обнаружили, что IP-адрес туннеля концентратора также рекламировался с одного из филиалов из-за настроенного там статического маршрута. В результате спицы DMVPN получали IP-адрес туннеля как от концентратора, так и от этого филиала. Удаление статического маршрута из филиала полностью решило проблему.

[M02@rt37]

Здравствуйте
[, @bravealikhan] Выполните команду
telnet x.x.x.x179
со спиков на концентратор A. Поделитесь результатом, пожалуйста. Кроме того, поскольку вы ничего не изменяете на своей стороне, если путь WAN изменится или MTU уменьшится, IPsec может продолжить работу, в то время как протоколы, основанные на TCP, такие как ваш BGP, будут перезагружены. «Настройки MTU и TCP MSS верны» Вы выполняете MSS clamp на интерфейсе туннеля? С уважением
.ı|ı.ı|ı. Если это помогло, пожалуйста, оцените.ı|ı.ı|ı.

[paul driver]

Здравствуйте. Вы
проверили, что ваше подключение к подстилке стабильно?
Также можете ли вы подтвердить, что ваш туннель наложения NHRP пиринга является iBGP/eBGP,
вы используете статический или динамический bgp пиринг Пожалуйста, оцените и отметьте как принятое решение, если вы нашли полезной какую-либо из предоставленной информации.
Это поможет другим участникам форума найти ценный ответ и расширит глобальную сеть сообщества.
С уважением,
Пол

[bravealikhan]

Здравствуйте, ниже приведены некоторые подробности: DMVPN-подложка и сеансы NHRP полностью стабильны — все спицы отображаются как
активные
на обоих концентраторах.
Туннели IPSec/IKEv2 установлены и остаются стабильными без перегенерации ключей или потерь.
BGP работает как динамический iBGP над DMVPN-оверлеем.
Проблема возникает только на одном концентраторе, в то время как второй концентратор остается полностью стабильным при использовании идентичной конфигурации и политик.
Telnet к TCP/179 от спиц к затронутому концентратору не завершается, даже если туннель работает.
Тестирование MTU пути (DF-bit pings) показывает фрагментацию или потерю сверх определенного размера полезной нагрузки, в то время как второй концентратор проходит все тесты.
Настройки MTU и MSS идентичны и правильны на обоих концентраторах (
ip tcp adjust-mss 1360
,
ip mtu 1400
).
Cisco TAC обнаружил асимметричные счетчики ESP (Encapsulating Security Payload) на затронутом концентраторе — значительно больше зашифрованных пакетов, чем расшифрованных, что указывает на возможную одностороннюю потерю или асимметрию пути на уровне подстилающего слоя.
ISP подтвердил отсутствие перегрузки, фильтрации или ошибок интерфейса на линиях доступа, хотя входящий трафик для нашего публичного диапазона может поступать в их сеть через несколько точек агрегации, что потенциально может привести к асимметричным обратным путям. На данный момент DMVPN и IPSec остаются работоспособными, но TCP-сессии, инкапсулированные в ESP, никогда не завершают полное трехстороннее рукопожатие, что приводит к флаппингу динамических BGP-пиров только на затронутом концентраторе.

[M02@rt37]

Здравствуйте
[, @bravealikhan] Большое спасибо за ваш отзыв. С уважением
.ı|ı.ı|ı. Если это помогло, пожалуйста, оцените .ı|ı.ı|ı.

[nicolesilvera]

В DMVPN с двумя концентраторами часто происходят сбои соседства BGP,
несмотря на стабильную работу IPSec/NHRP
, обычно из-за
недоступности следующего прыжка, таймеров BGP или проблем с разделением горизонта
. Даже если туннели работают, кратковременные задержки или пересчет маршрутов могут вызвать сбои. Быстрая проверка: Убедитесь, что следующие прыжки BGP всегда доступны из спиц.
Настройте
таймеры BGP keepalive/hold
для задержки DMVPN.
Проверьте
стабильность разрешения NHRP
и настройки раздвоенного горизонта концентратора.
Мониторинг CPU/IPSec на предмет временных задержек. Стабильный IPSec сам по себе не гарантирует стабильность BGP; обычно эту проблему можно решить, настроив таймеры и обработку следующих прыжков.