[zi_rus]

гарантии доступности

то есть продаем дар предвидения пожаров и экскаваторщиков?

[zoro]

Привет. У меня есть разработка которая делает именно то что вам нужно. Это модуль под ядро Linux. Он организует L2 либо L3 туннель. В качестве транспорта используется UDP либо ICMP. Модуль оперирует понятием подканалов(UDP/ICMP сессиями). Подканалы можно или объединять вместе или включать режим так называемого "Горячего резервирования" когда передаваемый пакет дублируется 2-3-4...n раз(в зависимости от кол-ва подканалов) и передается пиру. Первый принятый успешно пакет передается дальше в интерфейс, остальные отбрасываются.

Так же туннель умеет восстанавливать последовательность пакетов(в какой последовательности влетело на вход интерфейса в той же и вылетит на стороне пира).

Вау, в принципе мы рассматривали/реализовывали такую же задачу, в 2004 году, и потом 2010 году, даже те же времена реализовывали посредством UTP и SCTP туннели, L2 c шифрованием по ГОСТ. до ICMP правда не додумались :) Но у нас всегда был режим горячее резервирование, но наткнулись на то что с маленькими пакетами пролетало все ок, и хорошо, а когда требовалась фрагментация то скорость падала, и кучка приколов вылазило... Да и философский Вопрос "Резервирование маршрутизатора Резервирования" в таком случае также оставалось актуальным. При выходе из строя "Концентратора" все равно потеряется пакет во время поднятия железа "резерва"

 

ЗЫ №1: И всегда проблема решалась не путем допиливания до ума туннеля, а допиливание самого приложения в котором сразу задавались в начале какой максимальный МТУ, а также жесткие адреса "начала/конца"... Т.Е. имели две сетевые в начале и в конце... Имели два шифратора в начале и в конце... Т.Е. После Источника пакеты реально шли в разных каналах, железках... И "женились" на шине компьютера точки назначения...

 

Присутствует быстрое(не особо ресурсоемкое) шифрование и свой алгоритм фрагментации(т.к. тот что у IP протокола не всегда работает).

Модуль полностью интегрирован в LEDE(Бывший OpenWRT). Так что можно его запускать на любой совместимой с OpenWRT железке.

На ARM-ах тоже работает. И на эльбрусах(Пробовал на 2C+ и 4C).

Писалось это под свои задачи. Если интересно - можем посотрудничать.

В двойне Вау... И респект... У нас реализация только PTS-DOS и редхат :) хотели на эльбрусе, но расточительно... подняли на багете, даже начали на ос2000 переписывать.. Но другим путем пошли...

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

 

гарантии доступности

то есть продаем дар предвидения пожаров и экскаваторщиков?

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

[grifin.ru]

Вот уже пошла движуха, я смотрю )

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

Но вообще:

- отрадно что задача такая встала не только у меня, а то налетели тус все с рассказами про негарантированность UDP и советами почитать про TCP

- очень интересно и познавательно как люди решают такие нестандартные задачи.

Спасибо за информацию. Буду думать

[zoro]

Вот уже пошла движуха, я смотрю )

Движуха возникает практически постоянно, просто вы с этим только сейчас столкнулись, еще в начале 200х когда еще WAN каналы были тонкие и не надежные... Но тогда скорости ван были маленькие... И программеры приложений писали код отвечающий за обмен еще более менее оптимальный... Но в 2008 году например уже массово вылазили приложения которые требовали сетевые скорости 10/100мбит на клиента, а ван канал был до 10мбит... И начались проблемы... Потом пошел массовое расширение WAN но все равно...

 

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

Я говорю Практика- 2-3 раза реально всплывала задача... Решение вам сразу сказал Выше: Изучайте ТСР, переписывайте если нужна надежность Софт.

Но это я думаю не ваша компетенция.

 

Не ищите черную кошку в черной комнате причем Кошку и комнату вы сами придумали... Добиваться 0 потерь через сеть не подконтрольную вами, при скоростях 10 мбит и выше, при непонятности какой трафик(приложения) будет ходить внутри Это бред...

 

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

Потому что в основном борются на уровне приложения, и общей концепцией, и это получается дешевле и проще... Плюс кто имеет такую задачу часто имеют и свои каналы... Пускай и тонкие но свои, и знают что гарантированно надо доставить 300-400 байт, зато гарантированно и пускай даже с скоростью 1200бод. Весь остальной мусор просто не пускают. Т.Е. гарантированно пройдет 502 TCP порт, а ICMP, UDP даже не пройдет...

 

Но вообще:

- отрадно что задача такая встала не только у меня, а то налетели тус все с рассказами про негарантированность UDP и советами почитать про TCP

- очень интересно и познавательно как люди решают такие нестандартные задачи.

Если задача у вас встала только сейчас, то это означает Только Что она У вас только сейчас встала... Не надо думать что вы уникальные...

Подумайте почему вообще придумали IP сети... Почитайте эволюцию протоколов... И тогда вам не покажется то я вас постоянно тыкаю в TCP.

-Почитайте историю создания сетей.. Удивитесь что ее решают чуть ли не с 12хх годов когда посылали два курьера-гонца...

[Alex/AT]

Если я не ошибаюсь, то всякие RR и MultiLink бла-бла-бла - это технологиии БАЛАНСИРОВКИ трафика межу каналами. Там нет избыточности данных. И если пакет полетел в канал1, и там потерялся, то его придется перепосылать. У меня уже настроено и работает

Речь о TCP поверх RR (внимание - чистого RR, без кеширования маршрута) и P2P-линка. Все единичные потери и реордеринг скомпенсирует TCP, ценой снижения полосы и увеличения latency. А уже в этот TCP (туннель) загонять что угодно (IP/ICMP/UDP/TCP, Ethernet/PPPoE, whatever), главное при этом буферы не переполнить.

 

мне кажется, что ещё пару уровней вложенности стоит добавить )))

выглядит ужасно, как по мне.

По мне - не лучше. Но как решение для небольшого потока UDP с требованием гарантированной доставки и без требований к latency - вполне себе. Единственное что, готовых решений я лично не встречал (да их на каждый конкретный случай жизни и не придумать) - придётся сначала докручивать и тестировать в условиях, приближенных к боевым.

 

В любом случае, надо закладывать возможность падения, кстати. Кто гарантирует, что разом не лягут все 3 канала?

[Ivan_83]

Да всё просто решается, особенное если у тебя л2 свой и ты можешь туда пулять до 1536 байт эзернет фреймы.

Корябается по быстрому эзернет нода по типу one-to-many (а можно и её скопипастить), она с one берёт пакет, добавляет туда свой заголовок: меняем эзернет тип и дописываем 2-4 байта порядковый номер и шлём во все many.

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

 

Если канал L3 то всё грустнее и за пару вечеров уже не накорябаешь.

Ну или если нужно не тупо лить в три трубы одно и тоже то тоже сложнее, но в целом логика та же.

[Butch3r]

Как-то неправильно ставится задача. Есть 3 говёных канала, я хочу сделать их не говёными. Нужно просто потратить больше денег, подключить качественных аплинков и ваша задача сама собой решится.

И не совсем ясна что за сервисы вы такие оказываете где потеря 3х пингов является критичной. В тот же самый мультикаст добавляют fec, который компенсирует эти потери. У голоса крутятся буферы и тд.

[edo]

Если канал L3 то всё грустнее и за пару вечеров уже не накорябаешь.

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

на сервере принимаем пакет, смотрим, есть ли src ip/port в списке коннектов, если нет - добавляем.

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

 

ну и в обратную сторону (от сервера к клиенту) передаём аналогично по динамическому списку коннектов. протухшие записи из этого списка периодически чистим.

 

остаётся вставить полученный канал "в разрыв" любому udp-vpn - и готово.

навскидку пара-тройка сотен loc на си.

 

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

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

 

Как-то неправильно ставится задача. Есть 3 говёных канала, я хочу сделать их не говёными. Нужно просто потратить больше денег, подключить качественных аплинков и ваша задача сама собой решится.

да нормальная задача. два канала в любом случае будут надёжнее, чем один.

и не во всех дырах можно получить надёжный канал (за вменяемые деньги)

 

И не совсем ясна что за сервисы вы такие оказываете где потеря 3х пингов является критичной

вот тут полностью согласен

[edo]

Смотрите выше- TCP, т.е. Если надо приложение сделать с гарантированной доставкой то это уже уровень Транспорта и выше... Все зависит от разработчика Приложения.

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

[zoro]

И не совсем ясна что за сервисы вы такие оказываете где потеря 3х пингов является критичной

вот тут полностью согласен

Повторяю :) Человек выдумал проблему, и героически с ней борется... :) точнее мы боремся :)

А для чего он выдумал- чтобы за это взять больше денег :)...

Я вообще хотел не отвечать- так как сразу вижу суть проекта/проблемы.

Но так как этой проблемой занимался несколько раз, но там действительно не деньги проблема была- а действительно нужно было доставить Пакетики с гарантией 99,99999% потому что:

1- технология Сразу же вылетит железка на лярд... Да еще 2-3 человека пострадает минимум физически...

2- ну возможно под лярд людей погибнут/не погибнут :)

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

[edo]

вот случайно подвернулось под руку:

под конец как раз рассматривался вариант с дублированием пакетов в разные каналы

[zoro]

вот случайно подвернулось под руку:

под конец как раз рассматривался вариант с дублированием пакетов в разные каналы

Вы не подскажите с какой минуты/секунды смотреть :) а то 30минут потратить на микротик...

[edo]

27:23

 

да я не говорю, что надо на микротике делать, просто:

- тут адепт микротика вещал про схему с 6 устройствами (честно говоря, я прихожу к мнению, что он нас троллил);

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

 

Поэтому захотел посмотреть как другие видят решение проблем/чем занимались...

ну так и я захожу сюда потому, что задача резервирования vpn есть, а хорошего решения я не вижу. мы у себя внедряли пинговалку, которая перебрасывает на резервный канал при падении основного, да, это решает >>90% проблем, но всё-таки это не то.

Изменено 21 марта, 2017 пользователем edo

[NiTr0]

- тут адепт микротика вещал про схему с 6 устройствами (честно говоря, я прихожу к мнению, что он нас троллил);

нет, это суровая реальность адептов микротика.

[Saab95]

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

[zoro]

- тут адепт микротика вещал про схему с 6 устройствами (честно говоря, я прихожу к мнению, что он нас троллил);

нет, это суровая реальность адептов микротика.

ну так он для L3 предлагал...

А там так оно и есть 6 штук...

Для двух каналов L2 там их нужно 2 шт :)

[edo]

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

был свободный воскресный вечер, решил я попробовать. получилось.

программа принимает udp-пакеты, пересылает их с дублированием, на другой стороне отсекает повторы и передаёт дальше. всё это запускал совместно с openvpn.

 

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

 

вот один канал ("тонкий и быстрый"):

100 packets transmitted, 100 received, 0% packet loss, time 9980ms

rtt min/avg/max/mdev = 1.586/2.876/27.618/4.863 ms

закачка тестового файла через wget: 65.96 KB/s

 

вот второй канал ("потолще, но с задержками"):

100 packets transmitted, 100 received, 0% packet loss, time 9954ms

rtt min/avg/max/mdev = 32.109/34.724/49.980/2.321 ms

закачка тестового файла через wget: 2.34 MB/s

 

вот объединённый (+ openvpn):

100 packets transmitted, 100 received, 0% packet loss, time 9954ms

rtt min/avg/max/mdev = 1.698/3.675/17.716/4.495 ms

закачка того же тестового файла: 2.21 MB/s (это уже с оверхедом openvpn и моей программки)

 

почему я написал, что работает лучше, чем я ожидал: tcp на удивление спокойно отнёсся к packet reordering (впрочем, тут с обеих сторон был linux, надо бы с виндой проверить)

 

 

попробовал в локалке - по гигабитной сетке 100Мбит/c с дублированием прожевал легко (то есть по сетке бежало 200Мбит/с), дальше пошли потери, нужно крутить буферы, наверное.

 

код, если кому интересно, тут:

https://github.com/edo1/replicateit

(прошу сделать скидку на то, что это результат одного вечера работы, просто proof of concept)

для продакшена в текущем виде он непригоден, впрочем, допилить не так уж и сложно. буду ли пилить дальше - не решил, пока на филиале оставил для тестов.

 

 

сейчас попробую описать, почему я всё-таки решил попробовать:

решение со скриптами, пингующими разные интерфейсы, и переключающими между ними, всё-таки "не то".

тут решается не только проблема "A упал", но и "на A низкая скорость", "на A потери"; пинговалкой этого не увидеть - проблемы зачастую проявляются именно под нагрузкой (в частности, если делать автоматическое переключение на канал с наименьшими пингами, то легко поймать циклическое перекключение: переключились, пинги выросли, переключаемся обратно, ...)

 

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

 

что мне не нравится:

трафика вдвое больше, каналы в точке, куда мы терминируем наши vpn, загружаются вдвое сильнее.

да, вроде бы расширить и несложно/недорого, да и помегабайтная плата давно в прошлом, но всё равно "неаккуратно как-то".

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

 

P.S. я понимаю, что занимаюсь пионерством, но проблема есть, а хорошего решения я так и не нашёл.

 

P.P.S. чтобы было понятно: я корпоративщик с сотнями филиалов.

Изменено 28 марта, 2017 пользователем edo

[verhoum]

WAN оптимизатор поставить? Riverbed SteelHead по кошельку подходящий?

https://support.riverbed.com/bin/support/static/fbunsuuo632vi3jrspe0evbko9/html/u2pi6l52l4drmhq3uhck9tu7hm/sh_9.2_dg_html/index.html#page/sh_9.2_dg/path_selection.html