2 eth между офисами. Сделать надежный канал (без потерь)

В момент переключения на резерв, теряются пакеты.

Ничего страшного. Уменьши таймер в ospf. Можно еще помутить через vrrp

В какую сторону глянуть, чтобы из 2 каналов сделать один,
но надежный (интересует только стабильность) ?

Так не бывает. Даже если бы это было прямое соединение между железками, всё равно уходило бы время на перестроение маршрутов. Потерь, может, и не было бы, но задержки пакетов точно бы росли в этот момент. Но с VPN через интернет - это лучше забыть сразу про мечту о переключении без потерь. Можно только время уменьшать, как посоветовали уже.

А правильно - это софт писать так, чтобы он на потери не реагировал.

Закрутил в минимум: ip ospf dead-interval minimal hello-multiplier 10

ping -f -c 1000 192.168.16.189

1000 packets transmitted, 939 received, 6% packet loss, time 18993ms

за секунду которая необходима чтобы понять что канал умер, теряется 61 пакет, в принципе это логично.

Попробовал вариант с bonding. Поверх 2 туннелей поднял интерфейс bond0, mode: 3 (multicast) запустил тот же пинг, подергал кабеля. В таком раскладе потерь - НЕТ. В момент когда оба линка в норме на пинг прилетает 4 ответа: первый с нормальным временем ответа ~1ms остальные 3 с временем ответа ~10ms и флагом (DUP!)

В момент когда один линк в работе, пинг - с нормальным временем ответа ~1ms и без дубликатов.

Я думаю если есть такое решение как mode:3 (multicast), должно быть решение как избавится от (DUP!).

Почему интересует без потерь? Есть железяка которая шлет UDP пакеты ~2 в секунду. retransmit - Нет. Софт казенный.

Задержка - не проблема. Сеть eth «локалка» по городу.

Мне кажется должно быть решение ТРАТАТАможет_даже_vpn которое вешалось бы на оба канала и само контролировало поток. Софт казенный. Идет поток UDP пакетов.

Как побороть ДУПы?

фильтровать

Софт казенный. Идет поток UDP пакетов.

И он не может пережить кратковременный период потери пакетов ? Или это туда-сюда происходит постоянно ?

Подскажите пжлста чем? iptables судя по всему нет, лезть в ядро?

Сейчас попробую отписаться в сапорт centosa.

Не может, в момент переключения на резерв теряет 1-2 UDP пакета. При переключении с резерва - потерь нет.

Подскажите пжлста чем?

я анонимный теоретик.

iptables должен уметь, по идее. и было бы странно, если centos не умеет iptables.

Я думаю если есть такое решение как mode:3 (multicast)

mode3 - это broadcast, а не multicast. У тебя происходит передача данных во все объединенные интерфейсы. Ты не находишь, что странно жаловаться на пакеты-дубликаты, когда ты намеренно используешь такой режим?

за секунду которая необходима чтобы понять что канал умер

чуть лучше можно получить используя VRRP

P.S. если надо совсем без потерь, то используй sdh или rpr в кольце. Можешь найти провайдера, который тебе предоставит такое решение.

Не может,

Плохо.

в момент переключения на резерв теряет 1-2 UDP пакета.
При переключении с резерва - потерь нет.

Так и должно быть. Резерв же работать не перестаёт, когда основной восстанавливается, и трафик начинает идти по основному без потерь. А вот при разрыве основного проходит какое-то время, пока OSPF определяет, что анонсов нет, и убирает маршруты.

Если софт работает через UDP и не может пережить потерю пакетов..

[:///:] Хотел пошутить в тему, но, боюсь, не дойдет.. =)

Если каналы Ъ L2, то смотри в сторону 802.3ad и не забудь настроить miimon.

сделай ssh туннель, это не совсем то, что ты хочешь, за то работает.

Софт казенный. Идет поток UDP пакетов.

дык в UDP никто ничего не гарантировал. Ни порядка, ни вообще доставки. Это проблема твоего ПО.

не шути, скор срежут. Я уже дошутился.