LINUX.ORG.RU
ФорумAdmin

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


0

2

Добрый день.

Есть пара офисов. Соединены между собой 2мя провайдерами по eth. IP серые получаются по DHCP. На концах стоит Centos 6.3. Подняты 2 туннеля ( через 1 и через 2 провайдера ). Настроен OSPF (QUAGGA). Все работает. При падении любого из линков переключается на резервный канал.

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

Подскажите:

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

Смотрел в сторону bond (multicast). Идут (DUP!) пакеты. Как побороть ДУПы?


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

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

andrew667 ★★★★★
()

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

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

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

AS ★★★★★
()
Ответ на: комментарий от andrew667

Закрутил в минимум: 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 - Нет. Софт казенный.

nesen
() автор топика
Ответ на: комментарий от AS

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

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

nesen
() автор топика
Ответ на: комментарий от nesen

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

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

AS ★★★★★
()
Ответ на: комментарий от MyTrooName

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

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

nesen
() автор топика
Ответ на: комментарий от AS

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

nesen
() автор топика
Ответ на: комментарий от nesen

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

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

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

MyTrooName ★★★★★
()
Ответ на: комментарий от nesen

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

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

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

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

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

andrew667 ★★★★★
()
Ответ на: комментарий от nesen

Не может,

Плохо.

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

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

AS ★★★★★
()
Ответ на: комментарий от nesen

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

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

Kiborg ★★★
()

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

D4rk4
()

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

emulek
()
Ответ на: комментарий от nesen

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

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

emulek
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.