Агрегация "интернетов" MLPPP

[[anp/hsw]]

к слову, через сколько лет в микротике эту дыру решатся залатать?

Кстати, это ведь довольно серьезная дыра.

Т.е. теоретически достаточно заставить хост сформировать днс-запрос.

А это может быть как dns forwarding, так и банальный промежуточный хост в traceroute.

 

Вообще, микротик завалить никогда не было проблемой, а уж создать ему загрузку 100% cpu так вообще ребенок справится. Может еще CCR устоит, но "обычные" точно тупить начинают.

[NiTr0]

' timestamp='1457334421' post=1253953]

Кстати, это ведь довольно серьезная дыра.

угу и на CCR она 100% есть. потому что там 100% glibc. другие библиотеки (типа uclibc) тайлеру не поддерживают.

[grifin.ru]

Как насчет пары сисек 2811 ?

[NiTr0]

дык у вас же какая-то циска есть - почему бы на ней не поднять?

[grifin.ru]

дык у вас же какая-то циска есть - почему бы на ней не поднять?

Если я правильно понимаю, то для PfR их нужно минимум две - это раз.

Да и та циска в глубоком продакшене. Не хочется на ней "пробовать"

[zi_rus]

не нужно их две для pfr

[grifin.ru]

не нужно их две для pfr

Так. уже интереснее.

Обращаю внимание на то, что мне нужно делить по каналам трафик В ОБЕ СТОРОНЫ.

Ищется технология, которая просто делит ИСХОДЯЩИЙ трафик на два потока.

При этом на другой стороне стоит такой-же девайс и делит исходящий трафик на два потока.

МЫ все правильно понимаем что мне нужно ?

[zi_rus]

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

 

если технология интересная, рекомендую послушать INE

https://streaming.ine.com/play/2823bbb7-0225-4e6e-a5eb-f79b38ebd1dd/pfr-vseminar-part-1#/

длинновато, но полезное введение что это и зачем

 

если понравится, там еще есть видео как это готовить, пригодится, потому что это не bgp, это много круче

[grifin.ru]

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

Изначально об этом и была речь. И, мне кажется, что это сильно важный момент для выбора технологии.

В случае разруливания с одной стороны поставленная задача не может быть выполнена на уровне распределения пакетов ! Нужно делить сессии, иначе нихрена работать не будет. Весь смысл в том, что на той стороне должен стоять тот, кто эти пакеты вместе собирает. Если же вы говорите что PfR возможен только с одной стороны, то кто будет собирать пакеты с другой стороны ? Если никто, и оно работает, то PfR Это не то, что мне нужно...

[zi_rus]

Совсем не понял этого поста. Рекомендую все же ознакомиться с предложенным видео чтобы оценить возможности технологии.

 

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

[grifin.ru]

если технология интересная, рекомендую послушать INE

https://streaming.in...eminar-part-1#/

длинновато, но полезное введение что это и зачем

Короче начал я смотреть... хоть анггийский с речи я не очень хорошо понимаю, но суть уловил.

Не то это. Это просто интеллектуальная балансировака ну уровне соединений.

Штука очень хорошая для офиса, когда сидят сотрудники и что-то из двух интернетов качают (см картинку в видео).

У меня же ситуация другая. Иницииатором соединения может быть как внутренний сервис "объекта" так и внешний. Конечно можно поставить две железки навстречу друг-другу, но они будут балансировать на уровне СЕССИЙ.

Если же у меня,грубо говоря, с FTP кто-то качает файл (в один поток), то он не будет отдаваться на суммарной скорости двух каналов.

Это не то что нужно.

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

В случае аплоада файла - то-же самое но в другую сторону.

PS. За информацию по PfR все-равно спасибо, я эту технологию применю в другом проекте, именно для офиса. Такая задача тоже есть у меня в ToDo.

Все же давайте вернемся пока к этой задаче.

 

потому что обратный трафик пойдет на нат адрес туда же откуда пришел запрос

Это не то, что требуется.

выше написал.

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

Тоже самое в обратную сторону ! Делим и собираем на уровне ПАКЕТОВ. Пофиг кто по какому каналу запрос пришел. Ответ придет арбитру и он засунет ответ в более свободную трубу, или порвет на части и засунет в обе трубы. Все вперемешку. Важно максимально утилизировать трубы. Там на том конце должны из всего этого восстановить исходный поток.

[zi_rus]

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

[grifin.ru]

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

Технически оно (решение) очень простым должно быть.

Еще раз напомню про таинственный MultiLink PPP, про который я написал в теме. Почему-то никто про него ничего не знает (

[grifin.ru]

http://www.cisco.com/cisco/web/support/RU/107/1075/1075886_mppp-ddr.pdf

[grifin.ru]

Вроде то, что нужно. Но очень смущает дремучесть решения и что все статья наэту тему 15-20 летней давности и все про DialUP.

С другой стороны - а что тут такого инновационного ? Задача стара как дерьмо мамонта. Поменялись только скорости и не стало нужно набирать номер...

Или я не прав ?

[uxcr]

MPLSoGRE, mpls control word,  и поверх eigrp с его unequal cost load balancing? :)

[grifin.ru]

и поверх

Не хочу ничего "поверх". Уверен что должно быть что-то законченное именно для этих целей.

[NiTr0]

Технически оно (решение) очень простым должно быть.

не будет оно простым. любое решение, где трафик одиночной сессии будет гулять сразу по обеим линкам, натыкается на packet reordering (потому что RTT линков может различаться на десятки миллисекунд). который приводит к диким лагам в tcp (пакеты тупо считаются потерянными), и полной заднице в udp (типа voip). упаковывать это все в туннель с поддержкой обработки reordering-а - гарантированный гемор при дропах пакетов на канале.

 

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

[uxcr]

Ну остаётся только lisp, пожалуй.

[grifin.ru]

не будет оно простым. любое решение, где трафик одиночной сессии будет гулять сразу по обеим линкам, натыкается на packet reordering (потому что RTT линков может различаться на десятки миллисекунд). который приводит к диким лагам в tcp (пакеты тупо считаются потерянными), и полной заднице в udp (типа voip). упаковывать это все в туннель с поддержкой обработки reordering-а - гарантированный гемор при дропах пакетов на канале.

Вообще проблем не вижу. Нумеруй себе пакеты как сквозной нумерацией, так и в пределах канала. После пакета N ждем пакет N+1. Если во всех каналах пришел пакет с номером M>N+1, значит N не придет и его больше не ждем. Алгоритм в 10 строчек кода.

 

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

Так я не просто поболтать обратился к коллективному разуму.

[uxcr]

который приводит к диким лагам в tcp (пакеты тупо считаются потерянными)

 

Нет, есть retransmit

 

и полной заднице в udp (типа voip)

 

нет, есть джиттер

 

упаковывать это все в туннель с поддержкой обработки reordering-а - гарантированный гемор при дропах пакетов на канале

 

Да, нужны дикие буферы выдерживать sequencing.

[zi_rus]

MPLSoGRE, mpls control word,  и поверх eigrp с его unequal cost load balancing? :)

Мои скудные знания говорят мне что нумеруются пакеты в control word только при пробрасывании потоков E1. Для ethernet там другая информация передается, по крайней мере это то что я понял для себя когда пытался понять предназначение control word как такового

 

а специфичное решение (типа mlppp) - можете попробовать

только не на циске. в смысле mlppp over pppoe она не поддерживает. а вот от линукса можно всего чего угодно ожидать

[zi_rus]

Задача стара как дерьмо мамонта

за 15-20 лет изменилась ситуация. раньше несколько модемов можно поставить и один абонент получит увеличенную суммарную скорость, абонентов мало, закачки по ночам, все дела, секвенсинг и реордеринг были меньшей проблемой

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

 

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

[GrandPr1de]

НАТ-ом предлагали балансить? :)

[ShyLion]

Вот это job protection так job protection ТС замутить собрался....

 

По делу - если инет-каналы относительно равнозначные, делаете на кисах два тоннеля и по ним запускаете роутинг протокол, с одинаковыми метриками и наслаждаетесь хеш-функцией CEF.

Да, эффективность будет не 100% а например 90%, и что? вам от этого прямо кушать не захочется?

Чем проще сеть, тем надежней.

 

ИМХО