Добрый день.
Есть поток UDP пакетов, который приходит на MikroTik. Этот поток с помощью bridge попадает на bounding (балансировка - round robin), состоящий из двух портов (то есть поток раздваивается). Далее поток с этих двух портов проходит через несколько устройств и попадает на другой MikroTik, который настроен аналогичным образом. Таким образом, раздвоенный поток собирается в один. Так вот, тест на потерю пакетов (из методики RFC 2544) показывает, что ничего не теряется. Но тест BERT (Bit Error Rate Test) выдает коэффициент, отличный от 0, то есть я делаю вывод, что пакеты приходят не в правильном порядке из-за появления некоторой задержки при проходе через устройства между маршрутизаторами.
Вопрос такой: можно ли настроить агрегацию (например, какая-нибудь волшебная балансировка) так, чтобы UDP пакеты приходили в правильном порядке, если связь между маршрутизаторами может быть ТОЛЬКО СИМПЛЕКСНОЙ? Или же, при такой постановке задачи, за порядком пакетов можно следить только используя свой контроль на генерирующем поток и приемном устройствах (например, использовать часть байт в пакете для нумерации пакетов и тому подобное)?
>[оверквотинг удален]
> не теряется. Но тест BERT (Bit Error Rate Test) выдает коэффициент,
> отличный от 0, то есть я делаю вывод, что пакеты приходят
> не в правильном порядке из-за появления некоторой задержки при проходе через
> устройства между маршрутизаторами.
> Вопрос такой: можно ли настроить агрегацию (например, какая-нибудь волшебная балансировка)
> так, чтобы UDP пакеты приходили в правильном порядке, если связь между
> маршрутизаторами может быть ТОЛЬКО СИМПЛЕКСНОЙ? Или же, при такой постановке задачи,
> за порядком пакетов можно следить только используя свой контроль на генерирующем
> поток и приемном устройствах (например, использовать часть байт в пакете для
> нумерации пакетов и тому подобное)?НЕТ!
Повторите торию -- IP НЕ ГАРАНТИРУЕТ ПОРЯДОК!!! от слова вообЧе и СОВСЕМ.
Каждый IP пакет (и как следствие UDP дейтаграмма) независимый блок данных и прийти они могут в произвольном порядке и без агрегации каналов.
И именно в UDP понятие "неправильный порядок пакетов" лишино смысла.
Задача "собрать в правильном порядке" -- задача приложения, а никак не стека UDP.Для "на выходе" получить "правильный порядок" был придуман tcp...
>[оверквотинг удален]
>> за порядком пакетов можно следить только используя свой контроль на генерирующем
>> поток и приемном устройствах (например, использовать часть байт в пакете для
>> нумерации пакетов и тому подобное)?
> НЕТ!
> Повторите торию -- IP НЕ ГАРАНТИРУЕТ ПОРЯДОК!!! от слова вообЧе и СОВСЕМ.
> Каждый IP пакет (и как следствие UDP дейтаграмма) независимый блок данных и
> прийти они могут в произвольном порядке и без агрегации каналов.
> И именно в UDP понятие "неправильный порядок пакетов" лишино смысла.
> Задача "собрать в правильном порядке" -- задача приложения, а никак не стека
> UDP.Так что надежное решение -- только на уровне генерирующего/принимающего приложений.
Все прочее ненадежно, изменятся политики QoS на трассе и прилетит к вам опять винегрет.> Для "на выходе" получить "правильный порядок" был придуман tcp...
>[оверквотинг удален]
>> Повторите торию -- IP НЕ ГАРАНТИРУЕТ ПОРЯДОК!!! от слова вообЧе и СОВСЕМ.
>> Каждый IP пакет (и как следствие UDP дейтаграмма) независимый блок данных и
>> прийти они могут в произвольном порядке и без агрегации каналов.
>> И именно в UDP понятие "неправильный порядок пакетов" лишино смысла.
>> Задача "собрать в правильном порядке" -- задача приложения, а никак не стека
>> UDP.
> Так что надежное решение -- только на уровне генерирующего/принимающего приложений.
> Все прочее ненадежно, изменятся политики QoS на трассе и прилетит к вам
> опять винегрет.
>> Для "на выходе" получить "правильный порядок" был придуман tcp...Благодарю всех за ответы
Можно, если маршрутизаторы в середине балансируют per flow, а не per packet.
Но это не микротики, конечно, да и в Линукс-бсд-боксах надо приложить усилия руками, из коробки не будет. А те рутеры, где есть CEF и похожие методики, те умеют.