[monstr]

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

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

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

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

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

 

 

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

Изменено 18 ноября, 2014 пользователем monstr

[pandel]

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

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

Изменено 11 ноября, 2014 пользователем pandel

[ChargeSet]

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

[Saab95]

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

[Night_Snake]

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

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

[monstr]

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

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

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

[ChargeSet]

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

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

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

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

[monstr]

http://wiki.mikrotik...terface/Bonding

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

 

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

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

Изменено 12 ноября, 2014 пользователем monstr

[ChargeSet]

http://wiki.mikrotik...terface/Bonding

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

 

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

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

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

 

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

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

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

[Saab95]

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

 

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

[SSD]

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

 

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

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

[Night_Snake]

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

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

[monstr]

Микротиков и так 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 мегабит.

Изменено 13 ноября, 2014 пользователем monstr

[Saab95]

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

[monstr]

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

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

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

 

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

 

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

Изменено 17 ноября, 2014 пользователем monstr

[Saab95]

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

 

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

[monstr]

На устройстве со стороны центра сети, на вкладке 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

[monstr]

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

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

 

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

[Saab95]

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

[Night_Snake]

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

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

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

[monstr]

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

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

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

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

2 EoIP с mtu 1400,

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

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

 

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

 

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

 

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

 

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

Изменено 18 ноября, 2014 пользователем monstr

[Saab95]

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

[monstr]

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

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

 

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

 

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

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

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

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

 

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

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

 

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

[Saab95]

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

 

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

 

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

 

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

 

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