Petric Posted September 27, 2015 · Report post Коллеги, всех приветствую.. Вопрос по теме - как устйчиво оргнаизовать бондинг WAN от двух операторов... Знаю, что тема непростая и набившая аскому.. Интрересет ваше мнение на эту тему.. Что имеем: - L2TP ISP BeeLine -все хорошо и все работает.. Что не устраивает: раз в кратал "слуается чудо", и все отваливается... Так же как "нормальному хомячку" - периодически канал уплывает в никуда.. То маленький DL, то маленький UL.. - DHCP ISP NetbyNet - Пока статистика не сильно набрана, но так же плавают DL/UL.. Что хочется? - сделать нормальный бондинг двух каналов.. Как видется этот вопрос? - покупка VPS в AWS, который будет выступать шлюзом/роутером в основной интернет - поднятие на моей стороне протокола, который будет позволять делать бондингг до VPS по двум каналам.. На текущий момент идет осмысление как ЭТо можно сделать? Начинал думать про MLPPP - так как вроде как "все есть".. Но наступил на то, что все достаточно старое.. И из "клиента" - такое сможет потянуть только pfsense.. На стороне LNS нужно так же будет думать - как заставить это работать.. И тут я вспомнил про GRE/EoIP.. Руками пока ничего не трогал, но кажется, что это может жить.. Имел ли кто опыт сборки такого чуда? Будет ли это работать по вашему мнению, учитывая плавающие проблемы с DL/UL? Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Petric Posted September 27, 2015 · Report post На этот вопрос меня вдохновила статья http://simonmott.co.uk/vpn-bonding Но хочу понять: - Какой транспорт в таком варианте предпочтительней.. Заранее спасибо всем, кто откликнется.. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
KaraVan Posted September 27, 2015 · Report post Что хочется? - сделать нормальный бондинг двух каналов.. Поведение агрегированных ("bonded") интерфейсов зависит от режима ("mode"). Проще говоря, режимы обеспечивают либо балансировку нагрузки, либо горячий резерв. Что именно в итоге нужно? Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Petric Posted September 27, 2015 · Report post Балансировку. Я так понимаю, что она не отменяет резервирования.. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
[anp/hsw] Posted September 27, 2015 · Report post Вы сильно удивитесь, когда узнаете, что скорость до амазона (и вообще ресуров других стран) плавает еще сильнее, чем в ваших замерах. А вообще, балансировать такие каналы - дохлая идея. Начиная от того, что пинг до вашего сервера через двух провайдеров будет очень разный, и пакетная балансировка будет рушить логику работы приложений, работающих с UDP, и кончая тем, что балансировка по номеру AS или по сессиям ожидаемого результата не даст, т.к. если вдруг у одного из провайдеров будет авария по типу "атас, канал сдох, даем 100 килобит на юзера, чтобы хоть как-то работало", то у вас отвалятся определенные ресурсы, и вы даже не сразу узнаете в чем собственно проблема. Нет, т.е. конечно, решения существуют, но это уже не фантазии на форумах, а работа программиста под ваши требования. А по тунелям я бы остановился на IPIP или GRE (если оба провайдера дают внешний IP), это максимально простой способ. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Petric Posted September 28, 2015 · Report post НА сколько я понимаю, 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 мсек.. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
[anp/hsw] Posted September 29, 2015 · Report post Так что - если потерь в канналах нет, мне кажется, что должно работать.. Зависит от того, как будете балансировать. Гуглите "udp packet out of order". Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...