The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]



"Дублирование трафика внутри l2tp"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Маршрутизаторы CISCO и др. оборудование. (VPN, VLAN, туннель)
Изначальное сообщение [ Отслеживать ]

"Дублирование трафика внутри l2tp"  +1 +/
Сообщение от Vova email(??) on 18-Мрт-15, 15:16 
Доброго всем времени суток.

Имеется прозрачный L2TP туннель построенный поверх интернета для соединения двух точек в одну сеть. Сконструировано всё на двух цисках 2801. Туннель работает исправно, но есть одно НО.

Поскольку как я описал выше канал построен поверх интернета (~7 хопов по дороге), зачастую, в особенности в дневные часы пакеты периодически теряются внутри туннеля, что крайне негативно сказывается на терминальных сессиях и IP телефонии.

Суть вопроса: возможно ли средствами циски настроить дублирование трафика туннельного ? т.е. пусть всё отсылает друг на друга в двойном количестве, интернет каналы широкие, полоса свободна. Здесь важна не столько скорость внутри туннеля, сколько качество.

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения по теме [Сортировка по времени | RSS]


1. "Дублирование трафика внутри l2tp"  +/
Сообщение от cant email on 18-Мрт-15, 15:37 
> Суть вопроса: возможно ли средствами циски настроить дублирование трафика туннельного
> ? т.е. пусть всё отсылает друг на друга в двойном количестве,
> интернет каналы широкие, полоса свободна. Здесь важна не столько скорость внутри
> туннеля, сколько качество.

Идея здравая, но ширпотребного решения не имеет.

Некоторые делают tcp-туннели, в них loss почти отсутствует, но появляется джиттер.

А так теоретически можно mirrir-порт на свиче дополнительно выплевывать наружу. Выглядеть эта конструкция будет конечно странно.

Майнстрим же такой: предоставлять только те сервисы, которые позволяет имеющийся по качеству транспорт.
Или под требования сервисов, строить новый транспорт.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

2. "Дублирование трафика внутри l2tp"  +/
Сообщение от fantom (ok) on 18-Мрт-15, 16:54 
>[оверквотинг удален]
>> ? т.е. пусть всё отсылает друг на друга в двойном количестве,
>> интернет каналы широкие, полоса свободна. Здесь важна не столько скорость внутри
>> туннеля, сколько качество.
> Идея здравая, но ширпотребного решения не имеет.
> Некоторые делают tcp-туннели, в них loss почти отсутствует, но появляется джиттер.
> А так теоретически можно mirrir-порт на свиче дополнительно выплевывать наружу. Выглядеть
> эта конструкция будет конечно странно.
> Майнстрим же такой: предоставлять только те сервисы, которые позволяет имеющийся по качеству
> транспорт.
> Или под требования сервисов, строить новый транспорт.

Поднимаете 2 тунеля и роутмапом отправлять пакеты сразу в 2 интерфейса.

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

3. "Дублирование трафика внутри l2tp"  +/
Сообщение от Vova email(??) on 18-Мрт-15, 16:56 
>[оверквотинг удален]
>>> интернет каналы широкие, полоса свободна. Здесь важна не столько скорость внутри
>>> туннеля, сколько качество.
>> Идея здравая, но ширпотребного решения не имеет.
>> Некоторые делают tcp-туннели, в них loss почти отсутствует, но появляется джиттер.
>> А так теоретически можно mirrir-порт на свиче дополнительно выплевывать наружу. Выглядеть
>> эта конструкция будет конечно странно.
>> Майнстрим же такой: предоставлять только те сервисы, которые позволяет имеющийся по качеству
>> транспорт.
>> Или под требования сервисов, строить новый транспорт.
> Поднимаете 2 тунеля и роутмапом отправлять пакеты сразу в 2 интерфейса.

Увы, но физически аплинк с провадйерами только один с одним внешним IP

Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

4. "Дублирование трафика внутри l2tp"  +/
Сообщение от fantom (ok) on 18-Мрт-15, 17:00 
>[оверквотинг удален]
>>>> туннеля, сколько качество.
>>> Идея здравая, но ширпотребного решения не имеет.
>>> Некоторые делают tcp-туннели, в них loss почти отсутствует, но появляется джиттер.
>>> А так теоретически можно mirrir-порт на свиче дополнительно выплевывать наружу. Выглядеть
>>> эта конструкция будет конечно странно.
>>> Майнстрим же такой: предоставлять только те сервисы, которые позволяет имеющийся по качеству
>>> транспорт.
>>> Или под требования сервисов, строить новый транспорт.
>> Поднимаете 2 тунеля и роутмапом отправлять пакеты сразу в 2 интерфейса.
> Увы, но физически аплинк с провадйерами только один с одним внешним IP

Так поднимите второй внутри первого и отправляйте туда только критический трафик.
Оверхед получите конечно некислый, но если туда только терминалки с голосом отправить то может в mtu нормально и поместитесь.


Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

5. "Дублирование трафика внутри l2tp"  +/
Сообщение от ShyLion (ok) on 18-Мрт-15, 17:49 
>>[оверквотинг удален]

интересно, как приложения отнесутся к дублям

Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

6. "Дублирование трафика внутри l2tp"  +/
Сообщение от fantom (ok) on 18-Мрт-15, 18:12 
>>>[оверквотинг удален]
> интересно, как приложения отнесутся к дублям

Ну у нормального ids/ips точно должна паника начаться :)
А так - сильно зависит от приложения.

Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

11. "Дублирование трафика внутри l2tp"  +/
Сообщение от Vova (??) on 19-Мрт-15, 14:06 
>>>>[оверквотинг удален]
>> интересно, как приложения отнесутся к дублям
> Ну у нормального ids/ips точно должна паника начаться :)
> А так - сильно зависит от приложения.

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

Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

7. "Дублирование трафика внутри l2tp"  +/
Сообщение от eek (ok) on 18-Мрт-15, 21:32 
Посредством ISR вы такое не сделаете.

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

Т.е. мы говорим про движок который позволяет вам доставить в приложение уже нормальзованную tcp сессию без зависимости от каналов.

Решение которое это делает уже продается (velocloud), правда не знаю доступно оно в России или нет. Нужно купить его или подождать пока их купит Cisco и продаст вам под своим брендом.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

28. "Дублирование трафика внутри l2tp"  +/
Сообщение от Andy1e (ok) on 04-Апр-18, 11:30 
> Посредством ISR вы такое не сделаете.
> Решение которое это делает уже продается (velocloud), правда не знаю доступно оно
> в России или нет. Нужно купить его или подождать пока их
> купит Cisco и продаст вам под своим брендом.

Здравствйте. Кто-нибудь может подсказать, воз и ныне там, или такая возможность все же появилась к 2018му на цисках? Или, прости г-поди, на чем-нибудь импортозаместительном@сертифицированном?
Стоит аналогичная задача, не могу даже придумать, какое умное слово гуглить, чтобы поиск выдавал что-нибудь, кроме обычной агрегации каналов.

Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

29. "Дублирование трафика внутри l2tp"  +1 +/
Сообщение от Vova email(??) on 04-Апр-18, 12:13 
>> Посредством ISR вы такое не сделаете.
>> Решение которое это делает уже продается (velocloud), правда не знаю доступно оно
>> в России или нет. Нужно купить его или подождать пока их
>> купит Cisco и продаст вам под своим брендом.
> Здравствйте. Кто-нибудь может подсказать, воз и ныне там, или такая возможность все
> же появилась к 2018му на цисках? Или, прости г-поди, на чем-нибудь
> импортозаместительном@сертифицированном?
> Стоит аналогичная задача, не могу даже придумать, какое умное слово гуглить, чтобы
> поиск выдавал что-нибудь, кроме обычной агрегации каналов.

Насчёт кошек не подскажу, а так на линухе отлично работает. Уже 3 года серваки коптят, трафик летает отлично. По скорости при 300 МБит/с 4 ядра Core i5 грузятся процентов на 30, не более. Зеркалируется в сумме двумя тунелями без шифрования.

Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

30. "Дублирование трафика внутри l2tp"  +/
Сообщение от Andy1e (ok) on 05-Апр-18, 07:16 
> Насчёт кошек не подскажу, а так на линухе отлично работает. Уже 3
> года серваки коптят, трафик летает отлично. По скорости при 300 МБит/с
> 4 ядра Core i5 грузятся процентов на 30, не более. Зеркалируется
> в сумме двумя тунелями без шифрования.

Меня мучает непонимание сути происходящего при разных скоростях на каналах (да, забыл уточнить, вопрос не в том, чтобы пихать дубли в один канал, а чтобы распихивать их по разным, как предлагалось выше). Нужно будет принудительно занизить bandwith? Или пакеты будут спокойно дропаться даже если один канал будет условной медью на 100мбс, а второй - узкой радиорелейкой? Скорости вряд ли будут большими (но все же не хочется резать на постоянку потенциально более широкий канал... ), вопрос скорее в том, что туннелей в центре будет целая пачка, в сторону разных точек, да и хотелось бы [нужно] чтобы все это счастье работало значительно дольше, чем 3 года. Напихать таких мини-серваков с избытком в ЗИП на все площадки?)

Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

31. "Дублирование трафика внутри l2tp"  +/
Сообщение от Vova email(??) on 05-Апр-18, 07:52 
>[оверквотинг удален]
> уточнить, вопрос не в том, чтобы пихать дубли в один канал,
> а чтобы распихивать их по разным, как предлагалось выше). Нужно будет
> принудительно занизить bandwith? Или пакеты будут спокойно дропаться даже если один
> канал будет условной медью на 100мбс, а второй - узкой радиорелейкой?
> Скорости вряд ли будут большими (но все же не хочется резать
> на постоянку потенциально более широкий канал... ), вопрос скорее в том,
> что туннелей в центре будет целая пачка, в сторону разных точек,
> да и хотелось бы [нужно] чтобы все это счастье работало значительно
> дольше, чем 3 года. Напихать таких мини-серваков с избытком в ЗИП
> на все площадки?)

bandwith занижать не придётся, первый пришедший пакет успешно пойдёт дальше, все остальные (задублированные) корректно дропнутся. Конкретно в одном из моих случаев такая схема построена из двух каналов: АОЛС и радиорелейка. В другом случае такая схема работает между двумя объектами на двух каналах 100 Мбит и 10 Мбит, когда 100 отваливается, люди ощущают лишь уменьшение скорости до 10 без каких-либо перебоев и разрывов открытых сессий.
Идея из центральной точки разбросаться задублированными туннелями - хорошая, у самого также работает. Работать будет пока серваки не помрут :)

Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

32. "Дублирование трафика внутри l2tp"  +/
Сообщение от Andy1e (ok) on 05-Апр-18, 10:25 
> bandwith занижать не придётся, первый пришедший пакет успешно пойдёт дальше, все остальные
> (задублированные) корректно дропнутся.

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

Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

33. "Дублирование трафика внутри l2tp"  +/
Сообщение от Vova email(??) on 05-Апр-18, 11:14 
>> bandwith занижать не придётся, первый пришедший пакет успешно пойдёт дальше, все остальные
>> (задублированные) корректно дропнутся.
> Так ээ... дропнутся-то они уже на том конце, у получателя. А чтобы
> дропнуться - им нужно сначала туда долететь. А они еще не
> долетели, они в очереди стоят на стороне отправителя (или на маршрутизаторе
> по дороге, L3 каналы-то в схеме точно присутствуют) из-за низкой пропускной
> способности. В моем понимании они должны тупо забить буфер на отправку
> (и возможно сдыхать по таймауту? Но таймаут все равно достаточно большой)...
> или как?

Бесспорно, на стороне отправителя (да и принимающей стороны) мощности надо рассчитывать так чтобы не создавалось очередей.
Например зеркалируя канал в 300 Мбит, мы рассчитали так чтобы 600мбит система обрабатывала без перегрузок. По дороге конечно пакеты могут затерятся и не долететь, но в этом случае как раз дублирование спасает. Чтобы затерялись по двум разным провайдерам, такого у нас ещё не было. А так можно и тройное зеркалирование сделать :)

Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

8. "Дублирование трафика внутри l2tp"  +/
Сообщение от ShyLion (ok) on 19-Мрт-15, 09:22 
> прозрачный L2TP туннель ... всё на двух цисках 2801

Не роутинг чтоли? x-connect?

> зачастую, в особенности в дневные часы пакеты периодически теряются внутри
> туннеля
> интернет каналы широкие, полоса свободна

Противоречие тут вижу я.
Нужно выносить мозг (или вообще менять) оператору или делать обрезание доступной пользователю полосы для интернта.

В свете L2TP не исключено что вообще CPU не справляется. 2801 по нынешним каналам - тупенькие.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

9. "Дублирование трафика внутри l2tp"  +/
Сообщение от fantom (ok) on 19-Мрт-15, 10:14 
>> прозрачный L2TP туннель ... всё на двух цисках 2801
> Не роутинг чтоли? x-connect?
>> зачастую, в особенности в дневные часы пакеты периодически теряются внутри
>> туннеля
>> интернет каналы широкие, полоса свободна
> Противоречие тут вижу я.
> Нужно выносить мозг (или вообще менять) оператору или делать обрезание доступной пользователю
> полосы для интернта.

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

Более-менее гарантированные транзиты стоят на порядок дороже "доступа в инет".


> В свете L2TP не исключено что вообще CPU не справляется. 2801 по
> нынешним каналам - тупенькие.

Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

13. "Дублирование трафика внутри l2tp"  +/
Сообщение от ShyLion (ok) on 19-Мрт-15, 16:53 
> Никакого противоречия - оператор предоставляет "доступ к сети интернет на скорости ххх"
> а НЕ "канал из точки А в точку В с оговоренными
> характеристиками".

Это значит оператор - г..но и его нужно поменять.

Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

15. "Дублирование трафика внутри l2tp"  +/
Сообщение от Vova (??) on 19-Мрт-15, 17:08 
>> Никакого противоречия - оператор предоставляет "доступ к сети интернет на скорости ххх"
>> а НЕ "канал из точки А в точку В с оговоренными
>> характеристиками".
> Это значит оператор - г..но и его нужно поменять.

Насчёт операторов не согласен. С двух сторон чистый интернет, а потери действительно появляются по дороге.

Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

18. "Дублирование трафика внутри l2tp"  +/
Сообщение от ShyLion (ok) on 19-Мрт-15, 20:05 
>>> Никакого противоречия - оператор предоставляет "доступ к сети интернет на скорости ххх"
>>> а НЕ "канал из точки А в точку В с оговоренными
>>> характеристиками".
>> Это значит оператор - г..но и его нужно поменять.
> Насчёт операторов не согласен. С двух сторон чистый интернет, а потери действительно
> появляются по дороге.

Ну раз чистый, нет проблем. Хотя о чем тогда тема?

Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

12. "Дублирование трафика внутри l2tp"  +/
Сообщение от Vova (??) on 19-Мрт-15, 14:09 
>> прозрачный L2TP туннель ... всё на двух цисках 2801
> Не роутинг чтоли? x-connect?
>> зачастую, в особенности в дневные часы пакеты периодически теряются внутри
>> туннеля
>> интернет каналы широкие, полоса свободна
> Противоречие тут вижу я.
> Нужно выносить мозг (или вообще менять) оператору или делать обрезание доступной пользователю
> полосы для интернта.
> В свете L2TP не исключено что вообще CPU не справляется. 2801 по
> нынешним каналам - тупенькие.

x-connect, он самый. Задача - отдать прозрачный L2 канал.

Насчёт оператора была идея что проблема по дороге, но связь не в тунеле идёт без потерь. Что полосу зажирают с излишком - тут в точку, это я уже выяснил :)

с CPU всё номр, при загрузке канала на 80 Mbps процессор больше 70% не поднимается

Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

14. "Дублирование трафика внутри l2tp"  +/
Сообщение от ShyLion (ok) on 19-Мрт-15, 16:56 
с единичными потерями легко должен справляться протокол верхнего уровня

от x-connect никак не уйти? а если хорошенько подумать?

Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

16. "Дублирование трафика внутри l2tp"  +/
Сообщение от Vova (??) on 19-Мрт-15, 17:08 
> с единичными потерями легко должен справляться протокол верхнего уровня
> от x-connect никак не уйти? а если хорошенько подумать?

Вариант, а подскажите как её сконфигурировать для прозрачного L2 канала другим способом ?

Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

17. "Дублирование трафика внутри l2tp"  +/
Сообщение от ShyLion (ok) on 19-Мрт-15, 20:01 
>> с единичными потерями легко должен справляться протокол верхнего уровня
>> от x-connect никак не уйти? а если хорошенько подумать?
> Вариант, а подскажите как её сконфигурировать для прозрачного L2 канала другим способом ?

Вопрос был в том, на сколько так необходим L2 канал через инет? Как правило такие решения вот именно так, как у вас и "работают". Приложения написаные под L2 обычно ожидают неких характеристик от среды, которых проброс по интернету не может дать впринципе.

Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

19. "Дублирование трафика внутри l2tp"  +/
Сообщение от fantom (ok) on 20-Мрт-15, 10:30 
>>> с единичными потерями легко должен справляться протокол верхнего уровня
>>> от x-connect никак не уйти? а если хорошенько подумать?
>> Вариант, а подскажите как её сконфигурировать для прозрачного L2 канала другим способом ?
> Вопрос был в том, на сколько так необходим L2 канал через инет?
> Как правило такие решения вот именно так, как у вас и
> "работают". Приложения написаные под L2 обычно ожидают неких характеристик от среды,
> которых проброс по интернету не может дать впринципе.

Можно openvpn попробовать поверх tcp, джиттер вырастет, но в теории потерь быть не должно.

Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

10. "Дублирование трафика внутри l2tp"  +/
Сообщение от cant email on 19-Мрт-15, 10:47 
> Поскольку как я описал выше канал построен поверх интернета (~7 хопов по
> дороге), зачастую, в особенности в дневные часы пакеты периодически теряются внутри
> туннеля, что крайне негативно сказывается на терминальных сессиях и IP телефонии.

По территории, например, России loss больше 1% это ненормально сегодня. (мои наблюдения по видеоконференц-связи между различным регионам, это тоже типа voip).

Вы точно локализовали место и причину потерь пакетов?
Можете показать src-ip и dst-ip, хотябы с точностью операторских префиксов.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

20. "Дублирование трафика внутри l2tp"  +/
Сообщение от cant email on 20-Мрт-15, 13:17 
>[оверквотинг удален]
> в особенности в дневные часы пакеты периодически теряются внутри туннеля...
>
> ...интернет каналы широкие, полоса свободна. Здесь важна не столько скорость внутри туннеля, сколько качество.
>
> ...С двух сторон чистый интернет, а потери действительно появляются по дороге.
>
> Насчёт оператора была идея что проблема по дороге, но связь не в тунеле идёт без потерь. Что полосу зажирают с излишком - тут в точку, это я уже выяснил :)
>
> с CPU всё номр, при загрузке канала на 80 Mbps процессор больше 70% не поднимается
>

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

Можете начать и с этой очевидной - кратковременные исчерпания полосы, ограничив некритичный трафик.
Потом ковырять более изощренные, типа: мгновенные всплески мелко-пакетной скорости (из-за L2 особенно), небольших по объему в полосе, но на пару секунд убивающих cpu насмерть, а на 1мин усреднении cpu не заметны.

А можете и пойти переделкой всего дизайна, и технологий, и оборудования, и каналов операторов.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

21. "Дублирование трафика внутри l2tp"  +/
Сообщение от Vova email(??) on 25-Мрт-15, 11:16 
>[оверквотинг удален]
> Имеется прозрачный L2TP туннель построенный поверх интернета для соединения двух точек
> в одну сеть. Сконструировано всё на двух цисках 2801. Туннель работает
> исправно, но есть одно НО.
> Поскольку как я описал выше канал построен поверх интернета (~7 хопов по
> дороге), зачастую, в особенности в дневные часы пакеты периодически теряются внутри
> туннеля, что крайне негативно сказывается на терминальных сессиях и IP телефонии.
> Суть вопроса: возможно ли средствами циски настроить дублирование трафика туннельного
> ? т.е. пусть всё отсылает друг на друга в двойном количестве,
> интернет каналы широкие, полоса свободна. Здесь важна не столько скорость внутри
> туннеля, сколько качество.

Уважаемые коллеги, проблема решена.

Пришлось уйти от оборудования циски и построить всё на двух обычных линуксовых машинах.

В итоге: 2 компа с 3мя сетевухами в каждом. Одна - внутрь смотрит, 2е другие на разных провайдеров. Строится 2 openvpn туннеля, на каждом направлении + один общий. Настраивается маршрутизация через iptables с дублированием трафика в каждый отдельный туннель. И с другой стороны трафик корректно собирается. Далее туннельный интерфейс и eth[смотрящий в локалку] объединяется в бридж интерфейс и L2 стабильно работает.

3ий день полёт нормальный.

В итоге вместо 5% потерь, 0% + не одной порванной сессии

P.S. Можно наплодить туннелей для дублирования сколько угодно внутри одного физического интерфейса. Главное просчитать запас скорости.

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

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

22. "Дублирование трафика внутри l2tp"  +/
Сообщение от fantom (ok) on 25-Мрт-15, 11:24 
>[оверквотинг удален]
> каждом направлении + один общий. Настраивается маршрутизация через iptables с дублированием
> трафика в каждый отдельный туннель. И с другой стороны трафик корректно
> собирается. Далее туннельный интерфейс и eth[смотрящий в локалку] объединяется в бридж
> интерфейс и L2 стабильно работает.
> 3ий день полёт нормальный.
> В итоге вместо 5% потерь, 0% + не одной порванной сессии
> P.S. Можно наплодить туннелей для дублирования сколько угодно внутри одного физического
> интерфейса. Главное просчитать запас скорости.
> Реализацию сей схемы нашли на заграничном ресурсе, не помню адрес, но если
> кому понадобится, могу выложить/выслать статью.

"Тренированный инвалид на костылях бегает быстрее зажравшегося клерка"
Фразу выдал один мой знакомый после замены cisco ASA на линуховый сервак.

Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

23. "Дублирование трафика внутри l2tp"  +/
Сообщение от Vova email(??) on 25-Мрт-15, 11:28 
>[оверквотинг удален]
>> собирается. Далее туннельный интерфейс и eth[смотрящий в локалку] объединяется в бридж
>> интерфейс и L2 стабильно работает.
>> 3ий день полёт нормальный.
>> В итоге вместо 5% потерь, 0% + не одной порванной сессии
>> P.S. Можно наплодить туннелей для дублирования сколько угодно внутри одного физического
>> интерфейса. Главное просчитать запас скорости.
>> Реализацию сей схемы нашли на заграничном ресурсе, не помню адрес, но если
>> кому понадобится, могу выложить/выслать статью.
> "Тренированный инвалид на костылях бегает быстрее зажравшегося клерка"
> Фразу выдал один мой знакомый после замены cisco ASA на линуховый сервак.

:)))))))

Циска - хорошая и стабильная железяка, но линукс своё берёт и прежде всего ценой железа относительно кошатины

Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

24. "Дублирование трафика внутри l2tp"  +/
Сообщение от cant email on 25-Мрт-15, 12:34 
> В итоге: 2 компа с 3мя сетевухами в каждом. Одна - внутрь смотрит, 2е другие на разных провайдеров. Строится 2 openvpn туннеля, на каждом направлении + один общий.

+1
Сразу бы сказали, что не ограничены в выборе провайдеров, в религии железа, и у вас стаж в ИТ десятки лет.

Даже вспомнился multilink ppp почуму-то.

Ещё интересны были бы решения (именно для L2) с более тонкой логикой, чем просто дублирование.
Типа, четыре туннеля L3 (крест-накрест между провайдерами) -- связаны ospf fast -- (тут нехватает логики выбора bestpath по качеству) -- через этот L3 делается tcp-туннель L2.

Киньте пожалуйста ссылку, чисто их академичекого интереса.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

25. "Дублирование трафика внутри l2tp"  +/
Сообщение от Vova email(??) on 25-Мрт-15, 14:53 
>[оверквотинг удален]
> +1
> Сразу бы сказали, что не ограничены в выборе провайдеров, в религии железа,
> и у вас стаж в ИТ десятки лет.
> Даже вспомнился multilink ppp почуму-то.
> Ещё интересны были бы решения (именно для L2) с более тонкой логикой,
> чем просто дублирование.
> Типа, четыре туннеля L3 (крест-накрест между провайдерами) -- связаны ospf fast --
> (тут нехватает логики выбора bestpath по качеству) -- через этот L3
> делается tcp-туннель L2.
> Киньте пожалуйста ссылку, чисто их академичекого интереса.

Как всегда сперва хочется пойти простым путём :)
А шаманский бубен и немного фантазии рождают новые идеи

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

"
(Ab)using OpenVPN to make two unrealiable Internet connections act asone reliable connection (Success!)


Hi, I'm Troy McClure. You might remember me from such posts as Failure #1 and Failure #2. Today I'm here to tell you about "OpenVPN inside OpenVPN".


Some time ago I was asked if it's possible to bond multiple 3G mobile wireless links from different operators together for one reliable connection. Bit later there was need to stream live video over 3G network from moving vehicle. Another age old question is how to make reliable low-latency VPN over public Internet by utilizing more than one provider. At that time I didn't have solution to any of these. Now I have something. It's still going to need testing and fine tuning, but at least something to try.

Say you got two Internet connections and both are equally bad with varying latency, bandwidth and packet loss. Perhaps you have two wireless links between buildings but due nature of unlicensed wireless – all those baby-monitors, video links, microwave ovens and other crap around – there’s some packet loss. Don’t worry, there’s way to make connections like these bit more reliable.

Proper solution would be of course implementing FEC. There’s few papers on subject, but no code to use so we resort to hacks. Ugly hacks. Hacks that send all traffic both ways thru all available links. Result is lesser probability for packet loss and whatever link was fastest transferring packet gets used. Downsides include large number out-of-order packets when fastest link loses packet. Duplicates are dropped early by OpenVPN’s replay protection feature and therefore they’re not visible to applications.

After banging my head against wall with horrible hacks I came to my senses. Since I already knew this was working fine between two computers connected using L2 network why not create L2 network over Internet with OpenVPN? Result will be OpenVPN inside OpenVPN. Some overhead and reduction of MTU size are downsides.

So far all my testing has been with virtual machines connected to each other. That doesn't exactly match real world situation where this hack might be needed. I'll do another post some day with real world results using multiple uplinks utilizing different technologies and different operators. Likely DSL, couple USB 3G dongles and maybe even adding Flash OFDM to the mix.

Notes below assume that you already have required packages installed and working L3 network between Client and Server. To keep things simple I'm not posting how to selectively route traffic over three different interfaces based on source/destination ports. There's plenty of documentation available on Internet for how to do it.

P.S. You can get similar results with Linux broadcast mode bonding. It's not good solution since you need to encrypt traffic twice and also end up with significant number of duplicate packets playing havoc with various applications.

•Configure OpenVPN on server side.

# Server
mkdir -p /etc/openvpn
cd /etc/openvpn

# 1st link is named 101
openvpn --genkey --secret openvpn101.key
cat > openvpn101.conf <<__END__
port 20101
dev tap101
ifconfig 172.31.101.1 255.255.255.0
verb 4
secret openvpn101.key
cipher none
__END__

# 2nd link is named 102
openvpn --genkey --secret openvpn102.key
cat > openvpn102.conf <<__END__
port 20102
dev tap102
ifconfig 172.31.102.1 255.255.255.0
verb 4
secret openvpn102.key
cipher none
__END__

# 3rd link is named 103
openvpn --genkey --secret openvpn103.key
cat > openvpn103.conf <<__END__
port 20103
dev tap103
ifconfig 172.31.103.1 255.255.255.0
verb 4
secret openvpn103.key
cipher none
__END__

# main link is named 088
openvpn --genkey --secret openvpn088.key
cat > openvpn088.conf <<__END__
local 172.31.255.1
port 20088
dev tap088
ifconfig 172.31.88.1 255.255.255.0
verb 4
secret openvpn088.key
mute-replay-warnings
replay-window 512 10
tun-mtu 1500
fragment 1372
mssfix 1282
passtos
comp-lzo
__END__


•Configure OpenVPN on client side.

# Client
mkdir -p /etc/openvpn
cd /etc/openvpn
scp 172.16.0.1:/etc/openvpn/openvpn*.key .

# 1st
cat > openvpn101.conf <<__END__
remote 172.16.0.1 20101
port 20101
dev tap101
ifconfig 172.31.101.2 255.255.255.0
verb 4
secret openvpn101.key
cipher none
__END__

# 2nd
cat > openvpn102.conf <<__END__
remote 172.16.0.1 20102
port 20102
dev tap102
ifconfig 172.31.102.2 255.255.255.0
verb 4
secret openvpn102.key
cipher none
__END__

# 3rd
cat > openvpn103.conf <<__END__
remote 172.16.0.1 20103
port 20103
dev tap103
ifconfig 172.31.103.2 255.255.255.0
verb 4
secret openvpn103.key
cipher none
__END__

# main
cat > openvpn088.conf <<__END__
local 172.31.255.2
remote 172.31.255.1 20088
port 20088
dev tap088
ifconfig 172.31.88.2 255.255.255.0
verb 4
secret openvpn088.key
mute-replay-warnings
replay-window 512 10
tun-mtu 1500
fragment 1372
mssfix 1282
passtos
comp-lzo
__END__


•Launch OpenVPN and add required iptables rules to server.

# SERVER
cd /etc/openvpn; openvpn --config openvpn101.conf --daemon
cd /etc/openvpn; openvpn --config openvpn102.conf --daemon
cd /etc/openvpn; openvpn --config openvpn103.conf --daemon

# Magic starts here. We need "always on" connection and dummy0 does exactly that
modprobe dummy
ifconfig dummy0 down
ifconfig dummy0 172.31.255.1 netmask 255.255.255.255 up
ip route add 172.31.255.2 dev dummy0

# Create three copies of OpenVPN packets
# Would be nice to discard original but doing so sends false icmp unreachables even with -j DROP
iptables -t mangle -A OUTPUT -d 172.31.255.2 -o dummy0 -j TEE --gateway 172.31.101.2
iptables -t mangle -A OUTPUT -d 172.31.255.2 -o dummy0 -j TEE --gateway 172.31.102.2
iptables -t mangle -A OUTPUT -d 172.31.255.2 -o dummy0 -j TEE --gateway 172.31.103.2

# Launch actual encrypting OpenVPN process
cd /etc/openvpn; openvpn --config openvpn088.conf


•Launch OpenVPN and add required iptables rules to client.

# CLIENT
cd /etc/openvpn; openvpn --config openvpn101.conf --daemon
cd /etc/openvpn; openvpn --config openvpn102.conf --daemon
cd /etc/openvpn; openvpn --config openvpn103.conf --daemon

# Magic starts here. We need "always on" connection and dummy0 does exactly that
modprobe dummy
ifconfig dummy0 down
ifconfig dummy0 172.31.255.2 netmask 255.255.255.255 up
ip route add 172.31.255.1 dev dummy0

# Create three copies of OpenVPN packets
# Would be nice to discard original but doing so sends false icmp unreachables even with -j DROP
iptables -t mangle -A OUTPUT -d 172.31.255.1 -o dummy0 -j TEE --gateway 172.31.101.1
iptables -t mangle -A OUTPUT -d 172.31.255.1 -o dummy0 -j TEE --gateway 172.31.102.1
iptables -t mangle -A OUTPUT -d 172.31.255.1 -o dummy0 -j TEE --gateway 172.31.103.1

# Launch actual encrypting OpenVPN process
cd /etc/openvpn; openvpn --config openvpn088.conf

That's it.

About parameters, 'mute-replay-warnings' is mandatory to avoid flooding logs with error message for every duplicated packet - and with this setup there is going to be no shortage of those.

You might want to tune 'replay-window' setting depending on your link speed and latency. It's currently set to accept up to 512 packets out-of-order but no packets that are more than 10 seconds late. It might be best to shorten timeout as I don't think kernel nor applications really expect packet that is normally received in 10ms to come after 10 seconds.

Since different paths can have different MTU sizes we're limiting main OpenVPN process (one that does encryption) to maximum of 1372 bytes including any OpenVPN added headers. Hopefully this is small enough to pass thru any uplinks we might have. If not reduce values of both 'fragment' and 'mssfix' by same amount. Assuming I've interpreted OpenVPN docs correctly settings above allow transferring full 1500 byte IP packet but "recommend" that clients limit packet size to 1280 bytes. Anything that will be after compression, encryption and adding headers over 1372 byte limit will be fragmented to two approximately equal sized packets. Reason for allowing fragmentation with large packets is to make OpenVPN link as transparent as possible.

If you're CPU bound or have fast uplinks disabling adaptive compression (comp-lzo) is probably good idea. Passing TOS bits ('passtos') gives no performance improvements in typical setup. However by keeping TOS bits "public" you can use them to prioritize encrypted packets per-uplink when they're leaving your router. For this just follow your favourite QoS document to mark packets when they enter your router and then apply policing to those OpenVPN connections going out over your ISP links.

To test above setup try sending some traffic between 172.31.88.1 (server) and 172.31.88.2 (client). All packets, both ways, will be sent three times but apps only see one of them.

I tried applying 5% input and 5% output packet loss on VMware Workstation settings. Result was ping going directly without OpenVPN tunneling showed 17% packet loss after 12 hours. One using three tunnels showed 0,07% packet loss. Very un-scientific test, but at least I know that it's doing what I'm expecting.
"

Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

26. "Дублирование трафика внутри l2tp"  +/
Сообщение от fantom (ok) on 25-Мрт-15, 14:58 
>[оверквотинг удален]
> to those OpenVPN connections going out over your ISP links.
> To test above setup try sending some traffic between 172.31.88.1 (server) and
> 172.31.88.2 (client). All packets, both ways, will be sent three times
> but apps only see one of them.
> I tried applying 5% input and 5% output packet loss on VMware
> Workstation settings. Result was ping going directly without OpenVPN tunneling showed
> 17% packet loss after 12 hours. One using three tunnels showed
> 0,07% packet loss. Very un-scientific test, but at least I know
> that it's doing what I'm expecting.
> "

Хм.. поиск отменили??
http://blog.asiantuntijakaveri.fi/2011/12/abusing-openvpn-to...

Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

27. "Дублирование трафика внутри l2tp"  +/
Сообщение от Vova email(??) on 25-Мрт-15, 15:02 
>[оверквотинг удален]
>> 172.31.88.2 (client). All packets, both ways, will be sent three times
>> but apps only see one of them.
>> I tried applying 5% input and 5% output packet loss on VMware
>> Workstation settings. Result was ping going directly without OpenVPN tunneling showed
>> 17% packet loss after 12 hours. One using three tunnels showed
>> 0,07% packet loss. Very un-scientific test, but at least I know
>> that it's doing what I'm expecting.
>> "
> Хм.. поиск отменили??
> http://blog.asiantuntijakaveri.fi/2011/12/abusing-openvpn-to...

Оно, мне yahoo.com повторно не нашёл

Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Спонсоры:
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2021 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру