Отправляйте пакеты TCP/IP по трем маршрутам и выбирайте самый быстрый

Подход, который вы предлагаете, на мой взгляд, совершенно неверен.

Зачем?

Это пустая трата ресурсов, это как "безопасность через неизвестность", исправляющая проблему, а не исправляющая ее напрямую, и создающая сложность, которую можно избежать с помощью более качественного решения (устранение неполадок в сети по трем ссылкам одновременно, я не не за что!)

Так что тогда?

Как вы сами сказали, задержка каждой ссылки будет колебаться. Здесь я вижу несколько подходов, так или иначе, решение должно быть таким, которое было разработано для такого сценария (решение проблем задержки и RTT). Посмотрите на решения этой, вашей реальной проблемы, а не мета-проблему "как использовать все три ссылки одновременно?".

Решение первое

Во-первых, если у вас есть три ссылки, отбросьте 1 или 2 из них и реинвестируйте деньги в что-то с гарантированной задержкой. Интернет-провайдеры продают ссылки "точка-точка" (так что доставьте их к месту назначения) с SLA с задержкой и готовностью к победителю. Вы можете сохранить третью ссылку в качестве резервной копии, если хотите.

Решение второе

Второй вариант использовать что-то вроде OER Cisco (оптимальная граничная маршрутизация). Другие поставщики имеют аналогичные технологии, или, например, если у вас есть *nix брандмауэр / маршрутизатор / шлюз, вы также можете написать сценарий или написать аналогичное решение для себя. Используя Cisco OER в качестве примера, он позволяет вам настроить тесты (т. Е. Ping) к месту назначения, он измеряет качество теста, если он ухудшается до определенной точки, трафик перенаправляется другим способом. Таким образом, вы можете настроить тесты на задержку и всегда использовать маршрут с наименьшей задержкой.

Решение третье

MPLS TE - Многопротокольная коммутация по меткам - проектирование трафика. Я знаю, что это немного скучно, но MPLS-TE позволяет вам устанавливать туннели между двумя конечными точками и, опять же, направлять трафик по пути с наименьшей задержкой. Это немного более специализировано, хотя; вам либо нужен хороший провайдер, который может сделать это для вас, либо вам нужно вложить деньги в несколько приличных маршрутизаторов и настроить их для себя. Вы можете запустить MPLS через GRE между удаленными маршрутами и настроить это.

Решение четвертое

Одна из возможных идей заключается в том, что вы можете использовать несколько VPN или туннелей между двумя концами вашей сети и внедрять балансировку нагрузки для каждого пакета (циклический разбой) по всем трем каналам. Вы можете сделать это, например, с помощью маршрутизаторов Cisco и Juniper, или снова, если вы используете Linux, вы можете использовать такой пакет, как teqlИли купите аппаратное устройство, например FireBrick. Если все ссылки имеют одинаковые задержки (то есть вы не смешиваете ADSL, 3G и оптоволокно), это будет работать. Обычно это не рекомендуется, поскольку неупорядоченные пакеты могут вызывать проблемы в приложениях, поэтому не нужно смешивать ссылки в стиле задержки, как я только что упомянул. Но теперь я включил его через пару ссылок, и сделал это на моем последнем месте, и они без проблем. Я уверен, что пакет может время от времени приходить из строя, но это должно происходить очень редко, так как я никогда не замечаю никаких проблем.

Решение Пятое

Вы упомянули задержку, связанную с вашей заявкой. Поскольку я не знаю, что такое ваше приложение или как оно работает, всегда может быть внешний шанс, что во мне есть здравый смысл, и я рекомендую вам что-то сделать на уровне приложений. Я имею в виду, перекодировать приложение для обработки ссылок с более высокой задержкой. Дерьмо случается, даже если вы реализуете магическое сетевое решение с низкой задержкой, дерьмо случается, задержка будет расти, планируйте худшее, кодируйте его в своем приложении для обработки таких нежелательных сценариев на случай худшего (неправильное планирование и все такое, FMEA и т. Д.).

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

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

Не существует способа "многоадресной передачи" одноадресных пакетов, как вы предлагаете. Вот несколько альтернатив:

Попробуйте запустить последнюю сборку OLSRD, например, сборки OpenWRT OLSRd на каждом интерфейсе WAN и Debian или Ubuntu OLSRd на интерфейсах многосетевого хоста. OLSRD, настроенный с LinkQualityLevel, установленным в 2, должен привести к использованию канала ISP с наименьшей задержкой, хотя и не наименьшей задержки для какого-либо конкретного интернет-пункта назначения, кроме следующего перехода к ISP.

Если адресаты известны заранее или у вас есть хороший набор репрезентативных адресатов, вы можете написать демон на Python или Perl, который периодически проверяет время пинга для каждого адресата. Вы должны запустить демон на каждом интерфейсе WAN (возможно, имея в виду каждый маршрутизатор, обращенный к провайдеру) и запросить данные ping с хоста с несколькими компьютерами, используя клиентскую программу, которая изменяет маршрут по умолчанию на хосте с несколькими компьютерами в соответствии с наилучшим временем пинга, Это, вероятно, займет от пятидесяти до ста часов программирования для написания и отладки.

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

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