Jump to content
Калькуляторы

Балансировка ipsec 2 провайдера, 2 ipsec - как сделать балансировку?

Может кто сталкивался или натолкнет на мысль:

Имеется 2 удаленных друг от друга офиса.

В каждом из них имеется по 2 провайдера.

На данный момент настроено резервирование ipsec каналов: Постоянно поднято 2 канала. Если 1 упадет, в течении минуты сработают скрипты и переключат политики на резервный.

Но хотелось бы еще и агрегировать каналы. Тоесть не держать 1 провайдера в резерве, а задействовать оба канала для работы, ну и соответственно с резервированием.

 

 

Вопрос решен. Конечный результат в этом посте.

Edited by monstr

Share this post


Link to post
Share on other sites

У меня просто два подключения работают одновременно, с разными метриками. Одно работает всегда, но если падает, второе подхватывает.

Для чего используют скрипты? Чтобы проверять работоспособность канала без падения сессии?

Edited by pandel

Share this post


Link to post
Share on other sites

А нельзя сначала линки лагом каким-нибудь собрать, а уже потом поверх получившегося сагрегированного интерфейса пробрасывать ipsec?

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

А нельзя сначала линки лагом каким-нибудь собрать, а уже потом поверх получившегося сагрегированного интерфейса пробрасывать ipsec?

Можно поверх провайдеров сделать два gre-туннеля, поверх них запустить какой-нибудь ospf, и на нем уже строить ipsec. Правда, остается вопрос балансировки... Т.е. можно, конечно, выставить одинаковые метрики на разных интерфейсах, и "как-нибудь" трафик таки дойдет. Но вот на это "как-нибудь" я бы как раз и не рассчитывал.

Share this post


Link to post
Share on other sites

У меня просто два подключения работают одновременно, с разными метриками. Одно работает всегда, но если падает, второе подхватывает.

Поподробнее можно?

Пытался выставить приоритет в политиках - так всегда работает политика с максимальным приоритетом. Даже если ipsec разваливается - политики не переключаются.

Share this post


Link to post
Share on other sites

А нельзя сначала линки лагом каким-нибудь собрать, а уже потом поверх получившегося сагрегированного интерфейса пробрасывать ipsec?

Можно поверх провайдеров сделать два gre-туннеля, поверх них запустить какой-нибудь ospf, и на нем уже строить ipsec. Правда, остается вопрос балансировки... Т.е. можно, конечно, выставить одинаковые метрики на разных интерфейсах, и "как-нибудь" трафик таки дойдет. Но вот на это "как-нибудь" я бы как раз и не рассчитывал.

FYI: http://wiki.mikrotik.com/wiki/Manual:Interface/Bonding

в жопу OSPF, он здесь не нужен.

Share this post


Link to post
Share on other sites

К сожалению pptp не бондятся.

 

Есть, конечно, идея. Поднять 2 EoIP тунеля, в открытом виде, засунуть их в бондинг, а сквозь них уже поднять ipsec.

но мне кажется в такой схеме будет довольно большая потеря скорости.

Edited by monstr

Share this post


Link to post
Share on other sites

К сожалению pptp не бондятся.

 

Есть, конечно, идея. Поднять 2 EoIP тунеля, в открытом виде, засунуть их в бондинг, а сквозь них уже поднять ipsec.

но мне кажется в такой схеме будет довольно большая потеря скорости.

К сожалению вы забыли указать это сразу.

 

Обойти pptp можно двумя способами:

1. Вашим. Приемлемо, причин для падения скорости лично я особо не вижу: один хрен будет активно оба канала сразу, и у вас будет отказоустойчивость. Почему бы и нет?

2. Не скажу. Хотя нет, скажу: щас придет саб и присоветует поставить ещё +1 микротик с каждой стороны. Это один из его фирменных советов - стопки микротиков xD

Share this post


Link to post
Share on other sites

2. Не скажу. Хотя нет, скажу: щас придет саб и присоветует поставить ещё +1 микротик с каждой стороны. Это один из его фирменных советов - стопки микротиков xD

 

Это самое правильное решение - в первом офисе поставили 2 микротика, во втором офисе поставили 2 микротика, связали каждую пару между собой - соответственно получили избыточные связи, после них ставите еще по микротику, на котором уже и запускаете туннель.

Share this post


Link to post
Share on other sites

2. Не скажу. Хотя нет, скажу: щас придет саб и присоветует поставить ещё +1 микротик с каждой стороны. Это один из его фирменных советов - стопки микротиков xD

 

Это самое правильное решение - в первом офисе поставили 2 микротика, во втором офисе поставили 2 микротика, связали каждую пару между собой - соответственно получили избыточные связи, после них ставите еще по микротику, на котором уже и запускаете туннель.

Итого на один туннель 6 микротиков, шикарно!

Share this post


Link to post
Share on other sites

в жопу OSPF, он здесь не нужен.

На разнородных линках от бондинга больше проблем, чем пользы. Так что я бы резервировался на IP.

Share this post


Link to post
Share on other sites

Микротиков и так 4 штуки.

С каждой стороны по 2шт в VRRP собраны, в качестве резерва.

Железки мощные: С одной стороны CCR-1016 (2шт), с другой CCR-1036-EM (2шт).

С каждой стороны имеются сервера, с vmware. Можно попробовать завиртуализировать кучку микротиков :)

 

Спасибо за идею. Будем пробовать.

 

P.S. Кстати экспиремент с 2-мя EoIP провалился. Уж очень большая потеря в скорости.

По чистому IpSEC в 1 поток, смотря видео по rdp, вытягивал до 23 мегабит, А через 2EoIP в bonding получилось максимум 10-15. Хотя Bandwish-test между микротиками показал канал в 80 мегабит, при аплинках с одной стороны по 50 мегабит.

Edited by monstr

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

В итоге: 2 EoIP тунеля с mtu в 1300, собраны в bonding с mtu 1300 и Link Moniroting по arp.

Сквозь bonding поднят l2tp тунель, в котором mtu автоматически выставился 1450, уменьшить не получается.

Скорость достигает 100 мегабит, на 2х 50 мегабитных каналах. При падении одного из каналов - переключение происходит без потерь по пингам.

 

Пока сделал на статик роутах.

 

Ткните носом в тему, или подскажите как поднять ospf сквозь l2tp?

Edited by monstr

Share this post


Link to post
Share on other sites

Ткните носом в тему, или подскажите как поднять ospf сквозь l2tp?

 

В меню Routing - OSPF зайдите на вкладку Networks, там введите подсети или IP адреса, которые используются для L2TP, тогда при подключении туннелей по ним автоматически установится связь. На устройстве со стороны центра сети, на вкладке Instances откройте дефолтный профиль и в пункте Radistribute Default Route поставьте always самый верхний и готово.

Share this post


Link to post
Share on other sites

На устройстве со стороны центра сети, на вкладке Instances откройте дефолтный профиль и в пункте Radistribute Default Route поставьте always самый верхний и готово.

А если мне не нужен дефаул роут, а нужно общение 2х офисов между собой и все. В интернет они по своему каналу выходят.

 

С одной стороны 172.22.0.0/16

С другой 192.168.0.0/24 192.168.10.0/24 192.168.100.0/24

Share this post


Link to post
Share on other sites

Разобрался - добавил сети во вкладку Networks. Маршруты вроде передались.

Правда есть лишняя сеть VPN-щиков (172.22.240.0/24), входящая в 172.22.0.0/16, как их НЕ передавать еще не разобрался.

 

Сегодня вечером генеральный тест. По результатам отпишусь.

Share this post


Link to post
Share on other sites

Если дефолтный роут не нужен, то и не отдавайте. Если нужно отделить определенную сеть, то не указывайте ее. Введите несколько подсетей, которые используются для соединения по туннелям, не обязательно одну широкую указывать.

Share this post


Link to post
Share on other sites

В итоге: 2 EoIP тунеля с mtu в 1300, собраны в bonding с mtu 1300 и Link Moniroting по arp.

Сквозь bonding поднят l2tp тунель, в котором mtu автоматически выставился 1450, уменьшить не получается.

Знаатное извращенство...

Share this post


Link to post
Share on other sites

Как и обещал отписываю.

Эксперемент считаю удачным.

Только пришлось еще побаловаться с mtu.

В итоге имеем:

2 EoIP с mtu 1400,

bonding из этих интерфейсов с mtu 1400,

поверх этого поднят l2tp с mtu 1400.

 

При проходжении пакетов, через провайдеров, размером в 1500 байт без фрагментации.

 

На первом скриншоте в центре суммарная скорость получившегося канала.

 

На втором скриншоте видно, что скорость прыгала, но это были экспиременты с отключением одного из провайдеров и размером mtu. Так скорость ровная.

 

Кстати, переключение, при падении одного из провайдеров, происходит моментально. Даже пинг не теряется и rdp сессия не разрывается.

post-123599-012259900 1416305056_thumb.png

post-123599-068528200 1416305062_thumb.png

Edited by monstr

Share this post


Link to post
Share on other sites

С буферами не пробовали играться? Что происходит если вдруг скорость через одного оператора кратковременно просаживается или идут потери? Потери можно сделать файрволом рандомом для теста.

Share this post


Link to post
Share on other sites

С буферами не пробовали играться?

Поподробнее, пожалуйста.

 

Что происходит если вдруг скорость через одного оператора кратковременно просаживается

 

В данный момент идет расширение каналов и как раз имею такую ситауцию:

на одном со вчерашнего дня 100 мегабит, на втором пока еще 50. tcp пакеты ходят отлично, максимальная скорость канала упирается в 100 мегабит, когда оба канала достигают 50мегабит. 50 мегабит первого провайдера пока не забействуются.

А вот с udp хуже. Когда скорость канала пытается подняться свыше 100 мегабит - бондинг начинает глючить и терять пакеты, следовательно скорость резко падает.

Но мне канал нужен для работы по rdp, а это tcp пакеты. Поэтому пока устраивает.

 

или идут потери? Потери можно сделать файрволом рандомом для теста.

А вот это не тестировал. Надо будет проверить. К сожалению время тестов ТОЛЬКО вечер, когда народ ене работает.

 

Подскажите как фаерволом сделать потери..?

Share this post


Link to post
Share on other sites

Поподробнее, пожалуйста.

 

В разделе Queues есть вкладка Queue Types, в них указаны типы буферов для различных применений, вам нужно подправить типы у default и default-small, ethernet-default и т.п., например увеличить количество пакетов до 1000, тогда при тесте по UDP пакеты начнут сначала буферизоваться, а только потом отбрасываться.

 

Подскажите как фаерволом сделать потери..?

 

Создаете правило на ближнем к вам устройстве, указываете dst.address = адресу на который настроен один из туннелей, то есть адрес, в сторону которого передаются данные, на вкладке Advanced в пункте Random указываете например 50, а в Action - Drop. Соответственно половина пакетов будет отброшена.

 

Другая проблема, которая может возникнуть в интернете, это нарушение очередности пакетов, но ее смоделировать можно только на связанных между собой маршрутизаторах, когда вы манглами так же через рандом отправляете часть пакетов по большому кругу через интерфейс, на котором указан большой буфер пакетов и запущен тест скорости, что бы увеличить задержку до нужного количества миллисекунд.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this