+7 495 320-55-52
- Назад
- Телефоны
- +7 495 320-55-52
- Заказать звонок
info@mikrotik.moscow
г. Москва, ул. Бакунинская, 84
Пн-Пт: 09-00 до 18-00
Сб-Вс: выходной

BGP-сессии закрываются, когда закрывается другая сессия с тем же IP.

BGP-сессии закрываются, когда закрывается другая сессия с тем же IP., RouterOS

pe1chl

Guest

24.04.2024 12:33:00

В RouterOS v7, похоже, если у двух или более пиров BGP сессия к одному и тому же локальному IP, и один из них закрывается, то закрываются все. В логах для таких сессий появляется статус «Idle». Обычно пир быстро переподключается, и сессии снова остаются активными. В моей конфигурации это происходит с несколькими пирами, подключёнными через L2TP/IPsec. У меня есть loopback-интерфейс с подсетью /24 из RFC1918, и на роутере один адрес из этой подсети. Все клиенты L2TP/IPsec подключаются к роутеру, получают IP (фиксированный «remote address» из списка PPP secrets), а BGP настроен (статично) между этими удалёнными адресами и локальным адресом роутера. Я знаю, что в v7 это можно сделать более автоматически, но часть клиентов ещё на v6. Эти пиры часто работают по LTE, и регулярно связь прерывается, так как провайдер отключает их через некоторое время и после переподключения выдаёт новый публичный IP. Я вижу, что в этот момент BGP сессии с одним и тем же локальным адресом падают. Но другие BGP сессии, которые идут через GRE-туннели и используют другой локальный IP на центральном роутере, при этом остаются активными. Кто-нибудь ещё сталкивался с этим? Это «нормально» для v7 или стоит поискать в конфигурации что-то, что косвенно это вызывает? На той же конфигурации в v6 такого не происходит. Следует ли это считать багом? Или это особенность, прописанная глубоко в BGP-спецификациях и просто не реализованная в v6?

pe1chl

Guest

15.05.2024 07:12:00

Кажется, я приближаюсь к решению проблемы… Оказывается, адреса клиентов L2TP разных роутеров распространяются через BGP, в основном из-за того, как в версии 7 работают сети BGP и фильтрация по сравнению с версией 6. Каждый раз, когда L2TP-ссылка разрывается, эта информация распространяется по всей сети, и хотя я не могу объяснить, почему так происходит, кажется, это вызывает флап маршрутизации или что-то в этом роде у других клиентов, из-за чего они тоже отключаются. Сейчас я изменил фильтры маршрутизации так, чтобы эти отдельные адреса больше не принимались (ограничив dst-len до максимум 29), и спустя пару дней ситуация заметно улучшилась. Всегда можно поспорить, стоит ли распространять маршруты для туннелей по всей сети или лучше держать их закрытыми только для пирингов. Это может быть хорошей идеей, если «предпочитаемый исходный адрес» некорректно настроен в маршрутах и фильтрах, ведь роутер при отправке будет выбирать адрес туннеля как источник. Кроме того, так удобнее для мониторинга. Но для фиктивного моста L2TP/IPsec достаточно отправлять маршрут для всей подсети, а не для каждого отдельного адреса.

pe1chl

Guest

17.05.2024 12:46:00

Нет, к сожалению, это не оно... Я всё ещё вижу такие последовательности:

2024-05-17T14:37:50+02:00 N0280 n0211-1 {l_addr: 172.22.32.126, r_addr: 172.22.32.12} Connection closed
2024-05-17T14:37:50+02:00 N0280 n0211-1 {l_addr: 172.22.32.126, r_addr: 172.22.32.12} Idle
2024-05-17T14:37:50+02:00 N0280 n0211-1 {l_addr: 172.22.32.126:179, r_addr: 172.22.32.12:38505} Entering OpenSent state
2024-05-17T14:37:50+02:00 N0280 n0211-1 {l_addr: 172.22.32.126, r_addr: 172.22.32.12} Starter {openOk: false} Entering OpenConfirm state
2024-05-17T14:37:50+02:00 N0280 n0211-1 {l_addr: 172.22.32.126, r_addr: 172.22.32.12} Starter {openOk: true} Entering Established state
2024-05-17T14:37:50+02:00 N0280 n0211-1 {l_addr: 172.22.32.126, r_addr: 172.22.32.12} Established
2024-05-17T14:37:50+02:00 N0280 n0343-l-1 {l_addr: 172.22.32.126, r_addr: 172.22.32.15} Idle
2024-05-17T14:37:50+02:00 N0280 n0344-l-1 {l_addr: 172.22.32.126, r_addr: 172.22.32.16} Idle
2024-05-17T14:37:50+02:00 N0211 1 {l_addr: 172.22.32.12, r_addr: 172.22.32.126} Established
2024-05-17T14:37:51+02:00 N0343 n0280-l-1 {l_addr: 172.22.32.15, r_addr: 172.22.32.126} Connection closed
2024-05-17T14:37:51+02:00 N0343 n0280-l-1 {l_addr: 172.22.32.15, r_addr: 172.22.32.126} Idle
2024-05-17T14:37:51+02:00 N0344 n0280-l-1 {l_addr: 172.22.32.16, r_addr: 172.22.32.126} Connection closed
2024-05-17T14:37:51+02:00 N0344 n0280-l-1 {l_addr: 172.22.32.16, r_addr: 172.22.32.126} Idle
2024-05-17T14:37:51+02:00 N0343 n0280-l-1 {l_addr: 172.22.32.15:37289, r_addr: 172.22.32.126:179} Entering OpenSent state
2024-05-17T14:37:51+02:00 N0280 n0343-l-1 {l_addr: 172.22.32.126:179, r_addr: 172.22.32.15:37289} Entering OpenSent state
2024-05-17T14:37:51+02:00 N0280 n0343-l-1 {l_addr: 172.22.32.126, r_addr: 172.22.32.15} Starter {openOk: false} Entering OpenConfirm state
2024-05-17T14:37:51+02:00 N0280 n0343-l-1 {l_addr: 172.22.32.126, r_addr: 172.22.32.15} Starter {openOk: true} Entering Established state
2024-05-17T14:37:51+02:00 N0344 n0280-l-1 {l_addr: 172.22.32.16:36369, r_addr: 172.22.32.126:179} Entering OpenSent state
2024-05-17T14:37:51+02:00 N0343 n0280-l-1 {l_addr: 172.22.32.15, r_addr: 172.22.32.126} Starter {openOk: false} Entering OpenConfirm state
2024-05-17T14:37:51+02:00 N0343 n0280-l-1 {l_addr: 172.22.32.15, r_addr: 172.22.32.126} Starter {openOk: true} Entering Established state
2024-05-17T14:37:51+02:00 N0280 n0343-l-1 {l_addr: 172.22.32.126, r_addr: 172.22.32.15} Established
2024-05-17T14:37:51+02:00 N0280 n0344-l-1 {l_addr: 172.22.32.126:179, r_addr: 172.22.32.16:36369} Entering OpenSent state
2024-05-17T14:37:51+02:00 N0280 n0344-l-1 {l_addr: 172.22.32.126, r_addr: 172.22.32.16} Starter {openOk: false} Entering OpenConfirm state
2024-05-17T14:37:51+02:00 N0280 n0344-l-1 {l_addr: 172.22.32.126, r_addr: 172.22.32.16} Starter {openOk: true} Entering Established state
2024-05-17T14:37:51+02:00 N0343 n0280-l-1 {l_addr: 172.22.32.15, r_addr: 172.22.32.126} Established
2024-05-17T14:37:51+02:00 N0344 n0280-l-1 {l_addr: 172.22.32.16, r_addr: 172.22.32.126} Starter {openOk: false} Entering OpenConfirm state
2024-05-17T14:37:51+02:00 N0344 n0280-l-1 {l_addr: 172.22.32.16, r_addr: 172.22.32.126} Starter {openOk: true} Entering Established state
2024-05-17T14:37:51+02:00 N0280 n0344-l-1 {l_addr: 172.22.32.126, r_addr: 172.22.32.16} Established
2024-05-17T14:37:51+02:00 N0344 input: in:l2tp out:(unknown 0), connection-state:invalid proto TCP (RST), 172.22.32.126:179->172.22.32.16:33881, len 40
2024-05-17T14:37:51+02:00 N0344 n0280-l-1 {l_addr: 172.22.32.16, r_addr: 172.22.32.126} Established

Маршрутизатор n0211 закрывает соединение (это L2TP/IPsec), и в итоге два других соединения через L2TP/IPsec тоже закрываются и сразу же восстанавливаются. Но почему?

pe1chl Guest	#4 0 15.06.2024 09:30:00 Обновил роутер до 7.15.1, но проблема осталась той же…

pe1chl

Guest

02.10.2024 08:35:00

Обновился до версии 7.16, и теперь стало гораздо хуже... Когда пир по L2TP/IPsec отключается из-за смены своего публичного IP и повторно устанавливает сессию L2TP/IPsec, я не раз замечал, что все BGP-сессии (всего их 15) уходят в состояние Idle и потом приходится их заново подключать.

mblfone Guest	#6 0 24.10.2024 02:10:00 Я вижу то же самое. РЕБЯТА, ДАВАЙТЕ ЭТО ПОЧИНИМ, ПОЖАЛУЙСТА!

Larsa Guest	#7 0 24.10.2024 05:30:00 @mblfone - Это просто форум пользователей. Пожалуйста, создайте отчет об ошибке в службу поддержки Mikrotik.

pe1chl Guest	#8 0 24.10.2024 11:01:00 У меня открыт тикет с 23 июля с ID SUP-159987, можете на него тоже сослаться.

Читают тему

Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры