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

В поисках счасья по бондингу Dual Wan с бекджеком и куртизанками.. mlppp, EoIP, ipip, GRE

Коллеги, всех приветствую..

Вопрос по теме - как устйчиво оргнаизовать бондинг WAN от двух операторов... Знаю, что тема непростая и набившая аскому.. Интрересет ваше мнение на эту тему..

Что имеем:

- L2TP ISP BeeLine -все хорошо и все работает.. Что не устраивает: раз в кратал "слуается чудо", и все отваливается... Так же как "нормальному хомячку" - периодически канал уплывает в никуда.. То маленький DL, то маленький UL..

- DHCP ISP NetbyNet - Пока статистика не сильно набрана, но так же плавают DL/UL..

Что хочется? - сделать нормальный бондинг двух каналов..

Как видется этот вопрос?

- покупка VPS в AWS, который будет выступать шлюзом/роутером в основной интернет

- поднятие на моей стороне протокола, который будет позволять делать бондингг до VPS по двум каналам..

На текущий момент идет осмысление как ЭТо можно сделать?

Начинал думать про MLPPP - так как вроде как "все есть".. Но наступил на то, что все достаточно старое.. И из "клиента" - такое сможет потянуть только pfsense.. На стороне LNS нужно так же будет думать - как заставить это работать..

И тут я вспомнил про GRE/EoIP.. Руками пока ничего не трогал, но кажется, что это может жить..

Имел ли кто опыт сборки такого чуда?

Будет ли это работать по вашему мнению, учитывая плавающие проблемы с DL/UL?

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


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

На этот вопрос меня вдохновила статья http://simonmott.co.uk/vpn-bonding

Но хочу понять: - Какой транспорт в таком варианте предпочтительней..

Заранее спасибо всем, кто откликнется..

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


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

Что хочется? - сделать нормальный бондинг двух каналов..

Поведение агрегированных ("bonded") интерфейсов зависит от режима ("mode"). Проще говоря, режимы обеспечивают либо балансировку нагрузки, либо горячий резерв.

 

Что именно в итоге нужно?

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


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

Балансировку.

Я так понимаю, что она не отменяет резервирования..

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


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

Вы сильно удивитесь, когда узнаете, что скорость до амазона (и вообще ресуров других стран) плавает еще сильнее, чем в ваших замерах.

А вообще, балансировать такие каналы - дохлая идея. Начиная от того, что пинг до вашего сервера через двух провайдеров будет очень разный, и пакетная балансировка будет рушить логику работы приложений, работающих с UDP, и кончая тем, что балансировка по номеру AS или по сессиям ожидаемого результата не даст, т.к. если вдруг у одного из провайдеров будет авария по типу "атас, канал сдох, даем 100 килобит на юзера, чтобы хоть как-то работало", то у вас отвалятся определенные ресурсы, и вы даже не сразу узнаете в чем собственно проблема.

Нет, т.е. конечно, решения существуют, но это уже не фантазии на форумах, а работа программиста под ваши требования.

А по тунелям я бы остановился на IPIP или GRE (если оба провайдера дают внешний IP), это максимально простой способ.

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


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

НА сколько я понимаю, EoIP/GRE - предусматривает проброс всего трафика поверх UPD пакетов.. Так что - если потерь в канналах нет, мне кажется, что должно работать..

Вопрос вызывает конечно плавающие DL/UL. Но вот их то и нужно проверить.. Как система будет жить в таком режиме..

Вот трассы к моему серверу от разных провайдеров одна за одной:

traceroute to каой то сервер, 30 hops max, 38 byte packets

1 78.107.125.117 (78.107.125.117) 0.398 ms 0.337 ms 0.610 ms

2 krasnaya-bng2-local.msk.corbina.net (85.21.0.234) 0.479 ms 0.549 ms 0.475 ms

3 10.2.255.252 (10.2.255.252) 0.027 ms 0.586 ms 0.613 ms

4 hq-crs-be10.corbina.net (195.14.54.100) 18.886 ms 18.866 ms 18.913 ms

5 tc-bb-hq-crs.msk.corbina.net (195.14.62.171) 18.373 ms 19.092 ms 19.037 ms

6 corbina-gw-140G.mx01.stockholm.gldn.net (85.21.224.102) 18.378 ms 18.875 ms 80.044 ms

7 62.141.106.16 (62.141.106.16) 53.835 ms 54.051 ms 53.764 ms

8 ae-15.r02.amstnl02.nl.bb.gin.ntt.net (80.249.208.36) 54.975 ms * 55.972 ms

9 ae-3.r23.amstnl02.nl.bb.gin.ntt.net (129.250.2.158) 54.562 ms ae-2.r22.amstnl02.nl.bb.gin.ntt.net (129.250.2.112) 55.316 ms ae-3.r23.amstnl02.nl.bb.gin.ntt.net (129.250.2.158) 55.515 ms

10 ae-5.r23.londen03.uk.bb.gin.ntt.net (129.250.5.197) 48.498 ms 49.234 ms 49.409 ms

11 ae-3.r03.frnkge03.de.bb.gin.ntt.net (129.250.6.249) 43.350 ms ae-0.r22.londen03.uk.bb.gin.ntt.net (129.250.4.85) 55.164 ms 47.432 ms

12 212.119.27.174 (212.119.27.174) 41.682 ms ae-3.r21.frnkge03.de.bb.gin.ntt.net (129.250.3.138) 50.598 ms 212.119.27.174 (212.119.27.174) 42.355 ms

13 54.239.107.8 (54.239.107.8) 82.753 ms ae-2.r03.frnkge03.de.bb.gin.ntt.net (129.250.6.217) 52.893 ms 54.239.107.164 (54.239.107.164) 55.193 ms

14 54.239.107.161 (54.239.107.161) 43.426 ms 54.239.107.183 (54.239.107.183) 42.423 ms 54.239.5.134 (54.239.5.134) 43.105 ms

15 54.239.5.98 (54.239.5.98) 47.617 ms 54.239.107.162 (54.239.107.162) 55.303 ms 54.239.107.140 (54.239.107.140) 64.358 ms

16 * 54.239.107.183 (54.239.107.183) 46.662 ms *

17 54.239.5.134 (54.239.5.134) 48.440 ms 48.984 ms *

 

И вторая

traceroute to какой то сервер, 30 hops max, 38 byte packets

1 msk-b22-r12.ti.ru (212.1.254.161) 14.497 ms 28.752 ms 26.716 ms

2 msk-r1-r12-ae16-4000.ti.ru (212.1.236.49) 1.334 ms 1.328 ms 1.352 ms

3 fra-r1-r25-xe-2-2-0-910.ti.ru (212.1.243.113) 52.962 ms 53.099 ms 53.049 ms

4 decix.amazon.com (80.81.194.152) 48.862 ms 48.632 ms 48.931 ms

5 54.239.107.124 (54.239.107.124) 65.838 ms 54.239.5.122 (54.239.5.122) 51.582 ms 54.239.107.58 (54.239.107.58) 70.600 ms

6 54.239.107.95 (54.239.107.95) 52.209 ms 54.239.107.73 (54.239.107.73) 63.204 ms 54.239.107.117 (54.239.107.117) 51.585 ms

7 54.239.5.134 (54.239.5.134) 49.921 ms 52.545 ms 49.545 ms

 

Из трасс видно, что AWS разбигается на 2 мсек..

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


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

Так что - если потерь в канналах нет, мне кажется, что должно работать..

Зависит от того, как будете балансировать.

Гуглите "udp packet out of order".

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


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

Join the conversation

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

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

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

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

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

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

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