Существует ли способ разделить трафик TCP / IP по трем маршрутам и использовать первые пакеты, достигающие пункта назначения?
Я представляю себе что-то вроде множественной адресации, но с требованием, чтобы трафик отправлялся каждый раз по всем трем каналам.
У нас есть три маршрута (через разные физические интерфейсы к разным интернет-провайдерам) к IP-адресу, и мы хотим постоянно обеспечивать минимальную задержку с помощью резервирования / переключения при отказе. Мы бы хотели, чтобы прикладной уровень видел один IP-адрес, но чтобы трафик наилучшим образом использовал три соединения.
Задержка / доступность может меняться для всех трех подключений, поэтому мне было интересно узнать о возможности отправки пакетов по всем маршрутам и о том, что выигравший пакет будет тем, который был использован.
На мой взгляд, предлагаемый вами подход совершенно неверен.
Это пустая трата ресурсов, это похоже на исправление проблемы «безопасность через скрытность», вместо того, чтобы исправлять ее напрямую, и это создает сложность, которой можно избежать с помощью более продуманного решения (устранение неполадок сети сразу по трем ссылкам не представляю!)
Как вы сами сказали, задержка каждой ссылки будет колебаться. Я вижу здесь несколько подходов, в любом случае решение должно быть разработано для такого сценария (решение проблем с задержкой и RTT). Посмотрите на решения для этой вашей реальной проблемы, а не на мета-проблему «как использовать все три ссылки одновременно?».
Во-первых, если у вас есть три ссылки, откажитесь от 1 или 2 из них и повторно инвестируйте деньги во что-то с гарантированной задержкой. Интернет-провайдеры продают двухточечные ссылки (так что доставьте их до пункта назначения) с SLA при задержке, и вы сразу же получите победителя. Вы можете оставить третью ссылку в качестве резервной, если хотите.
Второй вариант использовать что-то лайк Cisco OER (оптимальная граничная маршрутизация). Другие поставщики имеют аналогичные технологии, или, например, если у вас есть брандмауэр / маршрутизатор / шлюз * nix, вы также можете написать сценарий или написать аналогичное решение для себя. Используя Cisco OER в качестве примера, он позволяет вам настраивать тесты (например, ping) до пункта назначения, он измеряет качество теста, если он ухудшается до определенной точки, трафик перенаправляется другим способом. Таким образом, вы можете настроить тесты на задержку и всегда использовать маршрут с наименьшей задержкой.
MPLS TE - Многопротокольная коммутация по меткам - Управление трафиком. Я знаю, что это немного громоздко, но MPLS-TE позволяет настраивать туннели между двумя конечными точками и снова направлять трафик по пути с наименьшей задержкой. Хотя это немного более специализировано; вам либо нужен хороший интернет-провайдер, который может сделать это за вас, либо вам нужно инвестировать в какие-то полуприличные маршрутизаторы и настроить их для себя. Вы можете запустить MPLS через GRE между удаленными маршрутами и настроить это.
Одна из возможных идей состоит в том, что вы можете использовать несколько VPN или туннелей между двумя концами вашей сети и ввести балансировку нагрузки по каждому пакету (циклическое ограбление) по всем трем каналам. Вы можете сделать это, например, с маршрутизаторами Cisco и Juniper, или, опять же, если вы используете Linux, вы можете использовать такой пакет, как teql, или купите аппаратное устройство, например FireBrick. Если все ссылки имеют одинаковую задержку (то есть вы не смешиваете ADSL, 3G и оптоволокно), это сработает. Обычно это не рекомендуется, поскольку пакеты, не соответствующие порядку, могут вызвать проблемы в приложениях, поэтому не смешивайте ссылки в стиле задержки, как я только что упомянул. Но сейчас у меня есть пара ссылок, и я сделал это на последнем месте, и с ними нет проблем. Я уверен, что пакет может время от времени приходить из строя, но это должно быть очень редко, так как я никогда не замечаю никаких проблем.
Вы упомянули, что задержка связана с вашим приложением. Поскольку я не знаю, что это за приложение и как оно работает, всегда может быть внешний шанс, что я разумно рекомендую вам что-то с этим сделать на уровне приложения. Я имею в виду, перекодировать приложение для обработки ссылок с более высокой задержкой. Дерьмо случается, даже если вы реализуете волшебное сетевое решение с малой задержкой, дерьмо случается, задержка возрастает, планируйте худшее, закодируйте это в свое приложение для обработки таких нежелательных сценариев, если произойдет худшее (ошибочное планирование и все, FMEA и т. Д.).
Нет никакого способа «многоадресной» рассылки одноадресных пакетов, как вы предлагаете. Вот несколько альтернатив:
Попробуйте запустить последнюю сборку OLSRD, такую как сборки OpenWRT OLSRd на каждом интерфейсе WAN и Debian или Ubuntu OLSRd на интерфейсах многосетевого хоста. OLSRD, настроенный с LinkQualityLevel, равным 2, должен приводить к использованию канала ISP с наименьшей задержкой, но не с наименьшей задержкой для любого конкретного пункта назначения в Интернете, кроме следующего перехода к поставщику услуг Интернета.
Если пункты назначения известны заранее или у вас есть хороший набор репрезентативных пунктов назначения, вы можете написать демон на Python или Perl, который периодически проверяет время отклика для каждого пункта назначения. Вы должны запустить демон на каждом интерфейсе WAN (вероятно, это означает, что каждый маршрутизатор обращен к Интернет-провайдеру) и запросить данные ping от многосетевого хоста с помощью клиентской программы, которая изменяет маршрут по умолчанию на многосетевом узле в соответствии с лучшим временем ping. . На написание и отладку этого, вероятно, у вас уйдет от пятидесяти до ста часов программирования.
Если вы используете BGP, вам нужно будет зарегистрировать ASN и попросить вашего интернет-провайдера настроить свои маршрутизаторы для связи BGP с вашим. Это, вероятно, невозможно, если вы не зарегистрируете большой блок IP-адресов.
Тип маршрутизации, который вы пытаетесь выполнить, обычно называется Оптимизированная маршрутизация состояния канала.
Это действительно, вероятно, действительно плохой метод для этого, поскольку вы просто насыщаете ссылки трафиком. Если я правильно понимаю это, тогда программное обеспечение VPN / туннеля на самом деле не то, что вам нужно, поскольку это скорее метод защиты трафика, входящего в вашу внутреннюю сеть или удаленного доступа.
Для меня это звучит так, как будто вам нужно приобрести аппаратное устройство, которое позволяет агрегировать каналы, и оно будет разумно решать, через какой порт ваш исходящий трафик должен маршрутизироваться. Многие современные межсетевые экраны могут это сделать, или вы, вероятно, можете использовать устройство Cisco и использовать BGP.