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

Вопрос такой реально ли поднять два впн соединения и агрегировать их посредством стандарта например 802.3ad. и работать с единым абстрагированным каналом, тем самым повысив отказоустойчивость и скорость передачи. Как это можно реализовать? кто ни-будь подобное делал?

Поднимаю тему

ты уже практически нашел ответ

(2) подводные камни какие? одно дело когда абстрагирование в пределах Роутер - сервер или роутер - роутер, другое когда это через ВПН заворачивается с разными скоростями пингами итд.

(0) Реально. Такое эксплуатировалось в одной из известных мне компаний.

В качестве маршрутизатора был комп с осью Gentoo и тремя сетёвками. В одну был вставлен кабель от провайдера, в другую беспроводной маршрутизатор SkyLink (резервный), в третью локалка.

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

Стабильно работало в течении 5 лет точно.

ИМХО нет смысла. У тех пользователей, которые висели на падающем канале, связь на какой-то момент все равно будет пропадать.

(4) связь будет падать, нужно именно агрегировать

(4) Ты описываешь то, что у ТС сейчас.

VLAN ?

(9) не то...

вот посоветовали
lagg
lacp

(11) это всё относиться к 802.3ad то что я в (0) писал,
мне именно как это через VPN завернётся и взлети

(12) никто не пробовал еще. Будь пионером

(12) C VPN не взлетит. 802.3ad только для железа. И характеристики каналов должны совпадать.

(14) так 802.3ad это же канальный уровень а не физический? на крайний случай через vmware завернуть
две виртуальные машины на входе по прову с тунелью, выход на виртуальный коммутатор на котором эти каналы агрегегируються

(0) Что - то такое , может?

http://geektimes.ru/post/131933/

(0) не получится. Причем непрерывность не может быть обеспечена даже просто несколькими каналами к разным провайдерам безо всякого VPN, потому что если произойдет обрыв канала A, соединение с узлом будет восстановлено через канал B с другим IP-адресом. Как на это отреагирует узел и как он поймет что это тот же клиент к нему коннектится - одному Богу известно. 802.3ad это вообще не о том, даже не рядом.

802.3ad это агрегация портов, т.е. есть у вас две одинаковых сетевухи и два порта на одном свитче, вы хотите из 100+100 МБит получить канал 200 - да, это возможно. Но здесь у вас совершенно разные провайдеры с разным оборудованием. Канал может быть собран только программно, с заданными приоритетами распределения нагрузки и соединений в случае обрывов.

А в случае с VPN у вас получается два шлюза из одной локальной сети в другую. В любой момент времени работает только какой-то один, если он упал - переключаем маршрутизацию на второй. В общем, (4) в чистом виде. По-другому, мне кажется, никак.

(0)Можно, главное выбрать правильный алгоритм балансировки нагрузки по каналам.
Роунд-робин не пойдет, ибо будут меняться айпишники в пределах сессии. И будет слетать авторизация.
В общем это сделает невозможной работу с большинством современных сайтов и сервисов.
Зато позволить почти полностью утилизировать канал, если допустим использовать его для закачек по торренту.

Поэтому балансировку лучше устраивать по приоритетам трафика.
Не такая полная утилизация, но максимально комфортная работа.

(8) Оба канала были подняты одновременно.
Переключалась только маршрутизация.

Я подозреваю, что были скрипты, которые следили за каждым каналом.

Падение канала у пользователя проявлялось как небольшие тормоза (менее 30 сек) - а потом опять всё работает. Таким образом пользователь не знал на каком из каналов он работает.

Мне кажется, что ТС именно это и нужно. Стабильность работы пользователя.

(21)Два канала работают одновременно.
Каждый второй пакет идет в другой канал.
Каждую секунду скрипт проверяет доступность канала - если все ок, значит ничего не меняется, если отзыва нет, значит канал перестает использоваться, пока не станет доступным снова.
На микротике такое реализовывается без проблем.

(22) Да. Я подозревал что оборудование для решения этой задачи существует))

(20) но обрыв-то все равно будет заметен. ТС, как я понял, хочет чтобы обрывов вообще не было видно пока работает хоть один канал. Мне кажется, не получится так.

+ (24) и кроме того, обратите внимание, это немаловажно: он хочет всего этого не просто на интернет-канале. Ему это требуется на VPN-соединениях, т.е. по сути ему требуется получить на VPN-линке полную функциональность LAN, возможно, с потерей скорости.

(24)Не обязательно.
Тут все дело в настройках самого VPN - чтобы он не рвал коннект при небольших проблемах.

(25)А в чем проблема?

(26) Ну для VPN отсутствие ответных пакетов от VPN сервера как бы проблема.

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

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

(29) Да можно это запилить, но будет много сложных плясок - тут 2 варианта:
1. Свой хитропопый VPN.
2. Что типа VPN кластера.

(27)Настраивается, хотя зависит от конкретной реализации VPN.

(28)Ну вообще то можно поднять один тоннель, используя два соединения.

Т.е есть два физических линка А и Б
На шлюзе пакет 1 кидаем на линк А, пакет 2 на линк Б, и так далее.
Т.е банальный раунд-робин, утилизируем максимально полно оба линка.

Поверх линков поднимаем VPN тоннель, в интернет ходим через шлюз в удаленной сети.

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

Т.е работает так -
два линка, поверх VPN
Допустим упал линк Б, значит половина пакетов будет терятся, однако связь не порвется.
Сработает скрипт, и отключит проблемный канал, в результате VPN будет ходить только по каналу А.
И так пока Б не поднимется.

(32) но пакеты а и b будут приходить от разных отправителей. IPSec VPN точно не сможет работать с такой системой...

(33)Если VPN сервер ваш, то будет, куда он денется.
Если VPN сервер чужой, и вам не подконтрольный - да возможны проблемы.

(32) принцип, по которому исходящие пакеты сортируешь, какой? А самое главное, как будешь приходящие пакеты отдавать обратно, как определить, кому что пришло?

(35)А что их сортировать? Каждый второй пакет в другой интерфейс.
Не совсем понимаю для чего приходящие пакеты отдавать обратно...

(0) Конечно, можно. OSPF, BGP.

Собственно, VPN ведь не самоцель а используется для закрытия межофисного трафика от любопытного внешнего мира? Так, подымайте сколько угодно VPN соответственно числу имеющихся каналов связи, а "хвосты", торчащие у вас в офисах изнутри VPN уже маршрутизируйте OSPF/BGP. На выходе -- чистый защищённый отказоустойчивый единственный межофисный канал.