Перейти к содержимому
Калькуляторы

Проблемы с OSPFv2

Добрый день.

 

Есть головной офис с установленным 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

 

Спасибо

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

8 минут назад, Alexey_G сказал:

Добрый день.

 

Есть головной офис с установленным RB1100AHx2, к нему подключаются удаленные филиалы, где тоже установлены MT.

Подключение выполняется по L2TP/IPsec. В центральный офис заведено два внешних канала с белыми IP, и каждый удаленный филиал поднимает два канала в сторону центрального офиса для резервирования. При этом у каждого канала в сторону центрального офиса своя подсеть: 172.17.18.0/25 и 172.17.19.0/25 для балансировки между каналами (у одних филиалов по умолчанию трафик идет через один внешний канал центрального офиса, у других через другой).

 

Поверх всего этого настроен OSPF, все вроде работает, но периодически возникает проблема связанная с тем, что состояние соседей переходит в статус "exchange", при этом в логах куча одинаковых сообщений:

меняйте версию ОС, скриптом периодически что нибудь ребутайте

Изменено пользователем QWE

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

В конфигах ничего нет про Router-ID=) вы это поле вообще заполняете?

Центральное устройство и второе по производительности должны иметь там значения 0.0.0.1 и 0.0.0.2, на роутерах в филиалах уже указывается вручную, обычно по адресу одного из двух PPP туннелей. У вас же в конфигах адреса им раздаются автоматически, и не ясно что бывает при переподключении (выдается тот же адрес, или другой). Вот и получается, что при обрыве туннеля, этому роутеру выдается другой IP адрес и Router ID меняется, а остальные роутеры имеют в своих базах старые записи с теми же анонсируемыми адресами, вот и ругается.

 

На удаленных роутерах не надо ничего делать с метриками маршрутов. В центре обычно устанавливают 2 маршрутизатора, каждый имеет свой внешний канал и свой IP, удаленные роутеры подключаются к двум сразу. При этом лишнюю метрику, что бы данные через второй не бегали, при необходимости делают в центре. А на практике вообще не заморачиваются, и трафик бегает сразу через оба канала, балансировка сама собой происходит.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Saab95 

Разве ospf не устаревшая технология?

RouterID при обрыве не меняется

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

0001 и 0002. Лупбеки? Не, не слышал.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

В 01.12.2017 в 19:16, vvertexx сказал:

RouterID при обрыве не меняется

Если он вручную не указан, то он может меняться при включении/отключении интерфейсов, с которого получен адрес. Либо появится конфликт адресов, например при динамической раздачи IP в PPP туннелях.

 

В любом случае работа OSPF при правильной настройки не создает никаких проблем. Если что-то не так, то где-то не верные настройки.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

В 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?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Может и с МТУ, когда в одну сторону проходят пакеты 1500 байт, а в другую нет. Учитывая то, что это туннели, то фрагментация данных в интернете может влиять на работу. Например, когда очередность следования пакетов нарушается.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

В 04.12.2017 в 09:57, VolanD666 сказал:

С МТУ не может чего-нить происходить?

Да, это вариант

Попробую снизить MTU и помониторить 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

On 12/6/2017 at 8:34 AM, Alexey_G said:

Да, это вариант

Попробую снизить MTU и помониторить 

Вот не поверите. У меня проблема решилась отключением BFD. 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.