Alexey_G Опубликовано 1 декабря, 2017 · Жалоба Добрый день. Есть головной офис с установленным RB1100AHx2, к нему подключаются удаленные филиалы, где тоже установлены MT. Подключение выполняется по L2TP/IPsec. В центральный офис заведено два внешних канала с белыми IP, и каждый удаленный филиал поднимает два канала в сторону центрального офиса для резервирования. При этом у каждого канала в сторону центрального офиса своя подсеть: 172.17.18.0/25 и 172.17.19.0/25 для балансировки между каналами (у одних филиалов по умолчанию трафик идет через один внешний канал центрального офиса, у других через другой). Поверх всего этого настроен OSPF, все вроде работает, но периодически возникает проблема связанная с тем, что состояние соседей переходит в статус "exchange", при этом в логах куча одинаковых сообщений: route,ospf,info OSPFv2 neighbor 1.1.1.100: state change from Full to 2-Way route,ospf,info Database Description packet has different master status flag route,ospf,info new master flag=false Проблема может быть как на одном, так и на обоих интерфейсах, поднятых в сторону центрального офиса. Конфигурация центрального MT: /ip pool add name=pool-l2tp-vpn-ch2 ranges=172.17.18.1-172.17.18.126 add name=pool-l2tp-vpn-ch1 ranges=172.17.19.1-172.17.19.126 /ppp profile add local-address=172.17.18.1 name=pr-l2tp-vpn-ch2 remote-address=pool-l2tp-vpn-ch2 add local-address=172.17.19.1 name=pr-l2tp-vpn-ch1 remote-address=pool-l2tp-vpn-ch1 /interface l2tp-server server enabled: yes max-mtu: 1450 max-mru: 1450 mrru: disabled authentication: mschap2 keepalive-timeout: 30 max-sessions: unlimited default-profile: pr-l2tp-vpn-ch2 use-ipsec: yes ipsec-secret: ******* caller-id-type: ip-address one-session-per-host: no allow-fast-path: no /routing ospf network add area=backbone network=172.17.18.0/25 add area=backbone network=172.17.19.0/25 /routing ospf interface add cost=5 interface=l2tp-mof2-ch2 network-type=point-to-point add interface=l2tp-mof2-ch1 network-type=point-to-point Настройки филиала: /interface l2tp-client add allow=mschap2 connect-to=srv1.ru disabled=no ipsec-secret="****" max-mtu=1450 name=l2tp-mo-ch1 password="****" use-ipsec=yes user=mof2-ch1 add allow=mschap2 connect-to=srv2.ru disabled=no ipsec-secret="****" max-mtu=1450 name=l2tp-mo-ch2 password="****" use-ipsec=yes user=mof2-ch2 /routing ospf network add area=backbone network=172.17.18.0/25 add area=backbone network=172.17.19.0/25 /routing ospf interface add cost=5 interface=l2tp-mo-ch2 network-type=point-to-point add interface=l2tp-mo-ch1 network-type=point-to-point Включал логирование, ospf пакеты между маршрутизаторами ходят, по виду одинаковы (на 172.17.18.2 состояние Full, на 172.17.19.2 нет): route,ospf,debug RECV: Hello <- 172.17.19.1 on l2tp-mo-ch1 (172.17.19.2) ... route,ospf,debug RECV: Hello <- 172.17.18.1 on l2tp-mo-ch2 (172.17.18.2) ... route,ospf,debug SEND: Hello 172.17.19.2 -> 224.0.0.5 on l2tp-mo-ch1 ... route,ospf,debug SEND: Hello 172.17.18.2 -> 224.0.0.5 on l2tp-mo-ch2 ... route,ospf,debug RECV: Hello <- 172.17.19.1 on l2tp-mo-ch1 (172.17.19.2) ... route,ospf,debug RECV: Hello <- 172.17.18.1 on l2tp-mo-ch2 (172.17.18.2) ... route,ospf,debug SEND: Hello 172.17.19.2 -> 224.0.0.5 on l2tp-mo-ch1 ... route,ospf,debug SEND: Hello 172.17.18.2 -> 224.0.0.5 on l2tp-mo-ch2 ... route,ospf,debug RECV: Hello <- 172.17.19.1 on l2tp-mo-ch1 (172.17.19.2) ... route,ospf,debug RECV: Hello <- 172.17.18.1 on l2tp-mo-ch2 (172.17.18.2) Проблема сама уходит, либо с перезагрузкой коммутатора, либо перезапуском интерфейса, либо сама собой. Правильна ли такая схема настройки? И как можно диагностировать причину проблем с OSPF? Версии ROS одинаковы (для приведенного примера): 6.40.3 Спасибо Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
QWE Опубликовано 1 декабря, 2017 (изменено) · Жалоба 8 минут назад, Alexey_G сказал: Добрый день. Есть головной офис с установленным RB1100AHx2, к нему подключаются удаленные филиалы, где тоже установлены MT. Подключение выполняется по L2TP/IPsec. В центральный офис заведено два внешних канала с белыми IP, и каждый удаленный филиал поднимает два канала в сторону центрального офиса для резервирования. При этом у каждого канала в сторону центрального офиса своя подсеть: 172.17.18.0/25 и 172.17.19.0/25 для балансировки между каналами (у одних филиалов по умолчанию трафик идет через один внешний канал центрального офиса, у других через другой). Поверх всего этого настроен OSPF, все вроде работает, но периодически возникает проблема связанная с тем, что состояние соседей переходит в статус "exchange", при этом в логах куча одинаковых сообщений: меняйте версию ОС, скриптом периодически что нибудь ребутайте Изменено 1 декабря, 2017 пользователем QWE Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Saab95 Опубликовано 1 декабря, 2017 · Жалоба В конфигах ничего нет про Router-ID=) вы это поле вообще заполняете? Центральное устройство и второе по производительности должны иметь там значения 0.0.0.1 и 0.0.0.2, на роутерах в филиалах уже указывается вручную, обычно по адресу одного из двух PPP туннелей. У вас же в конфигах адреса им раздаются автоматически, и не ясно что бывает при переподключении (выдается тот же адрес, или другой). Вот и получается, что при обрыве туннеля, этому роутеру выдается другой IP адрес и Router ID меняется, а остальные роутеры имеют в своих базах старые записи с теми же анонсируемыми адресами, вот и ругается. На удаленных роутерах не надо ничего делать с метриками маршрутов. В центре обычно устанавливают 2 маршрутизатора, каждый имеет свой внешний канал и свой IP, удаленные роутеры подключаются к двум сразу. При этом лишнюю метрику, что бы данные через второй не бегали, при необходимости делают в центре. А на практике вообще не заморачиваются, и трафик бегает сразу через оба канала, балансировка сама собой происходит. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vvertexx Опубликовано 1 декабря, 2017 · Жалоба Saab95 Разве ospf не устаревшая технология? RouterID при обрыве не меняется Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vurd Опубликовано 1 декабря, 2017 · Жалоба 0001 и 0002. Лупбеки? Не, не слышал. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Saab95 Опубликовано 3 декабря, 2017 · Жалоба В 01.12.2017 в 19:16, vvertexx сказал: RouterID при обрыве не меняется Если он вручную не указан, то он может меняться при включении/отключении интерфейсов, с которого получен адрес. Либо появится конфликт адресов, например при динамической раздачи IP в PPP туннелях. В любом случае работа OSPF при правильной настройки не создает никаких проблем. Если что-то не так, то где-то не верные настройки. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Alexey_G Опубликовано 4 декабря, 2017 · Жалоба В 01.12.2017 в 17:29, Saab95 сказал: В конфигах ничего нет про Router-ID=) вы это поле вообще заполняете? Да, оно заполнено, забыл указать: Центр: /routing ospf instance set [ find default=yes ] distribute-default=if-installed-as-type-1 redistribute-connected=as-type-1 redistribute-other-ospf=as-type-1 \ redistribute-rip=as-type-1 router-id=1.1.1.100 Филиал: /routing ospf instance set [ find default=yes ] redistribute-connected=as-type-1 router-id=172.17.18.2 В 01.12.2017 в 17:29, Saab95 сказал: А на практике вообще не заморачиваются, и трафик бегает сразу через оба канала, балансировка сама собой происходит. Это вынужденная мера, т.к. пропускная способность каждого из внешних каналов в центре меньше суммарно необходимой всем филиалам. В 01.12.2017 в 20:59, vurd сказал: 0001 и 0002. Лупбеки? Не, не слышал. Т.е. лучше переделать: завести loopback с виртуальными адресами и назначить из в качестве RouterID? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
VolanD666 Опубликовано 4 декабря, 2017 · Жалоба С МТУ не может чего-нить происходить? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Saab95 Опубликовано 4 декабря, 2017 · Жалоба Может и с МТУ, когда в одну сторону проходят пакеты 1500 байт, а в другую нет. Учитывая то, что это туннели, то фрагментация данных в интернете может влиять на работу. Например, когда очередность следования пакетов нарушается. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Alexey_G Опубликовано 6 декабря, 2017 · Жалоба В 04.12.2017 в 09:57, VolanD666 сказал: С МТУ не может чего-нить происходить? Да, это вариант Попробую снизить MTU и помониторить Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
anemosphere Опубликовано 9 ноября, 2020 · Жалоба On 12/6/2017 at 8:34 AM, Alexey_G said: Да, это вариант Попробую снизить MTU и помониторить Вот не поверите. У меня проблема решилась отключением BFD. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Saab95 Опубликовано 13 ноября, 2020 · Жалоба BFD по умолчанию отключен. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...