rulinux.net - Форум - Admin - multipath route http://rulinux.net/ rulinux.net - Форум - Admin - multipath route http://rulinux.net/ http://rulinux.net/rss_icon.png Re: multipath route https://rulinux.net/message.php?newsid=7374&page=1#52742 https://rulinux.net/message.php?newsid=7374&page=1#52742 Mon, 28 Jun 2010 19:03:26 +0400 Я это делаю на баше. передергиваю роут до гуглов по очереди между провайдерами и пингую. три пинга подряд не прошли - сетка сфейлила. запускаем хендлер, который пытается поднять снова интерфейс, а тем временем дефолт роут перебрасываем на другого прова. Я правда скрипты не до конца закончил, кое-какие баги имеются.

]]> Re: multipath route https://rulinux.net/message.php?newsid=7374&page=1#52741 https://rulinux.net/message.php?newsid=7374&page=1#52741 Thu, 24 Jun 2010 22:52:25 +0400 > Тебя по-прежнему не отпускает мысль задосить Брина?
Карфаген должен быть разрушен!

> Как выяснить, что траффик не идёт? Непрерывно пинговать какие-то хосты, которые находятся заведомо за провайдером? Вот они обрадуются!
У меня на домашней машине так и сделано - кадые пять минут стартует ddclient и если обнаруживает смену адреса стучится сам знаешь куда. Плюс, поскольку пару раз ddclient дурковал, для надёжности, с минутной периодичностью по крону толкается скрипт на внешнем хостинге, а скрипт просто откладывает в файл адрес откуда пришёл запрос. Это на случай если мне воссрётся найти свою машину при отвале ddclient-а. Никого ещё этим не задосил. По идее на скрипт можно подвесить какую-нить обработку отвала коннекта и пускать чаще, скажем с 15-секундными интервалами. Для пингования вообще можно составить список хостов и пинать их поочереди.

]]> Re: multipath route https://rulinux.net/message.php?newsid=7374&page=1#52740 https://rulinux.net/message.php?newsid=7374&page=1#52740 Thu, 24 Jun 2010 21:55:55 +0400 >>вот если трафик через провайдера не идёт - разве не достаточный признак?
Тебя по-прежнему не отпускает мысль задосить Брина?

Как выяснить, что траффик не идёт? Непрерывно пинговать какие-то хосты, которые находятся заведомо за провайдером? Вот они обрадуются! Если же статистически анализировать траффик, то это будет более муторно, чем maillog. Потому что даже если провайдер лежит, то через тебя какой-то траффик все равно будет идти, хотя бы до самого провайдера плюс будут попытки установки соединения с теми, кто за провайдером.

]]> Re: multipath route https://rulinux.net/message.php?newsid=7374&page=1#52739 https://rulinux.net/message.php?newsid=7374&page=1#52739 Thu, 24 Jun 2010 16:44:10 +0400 > когда после звонков по телефону и переговоров выясняется, что провайдер упал и вставать не хочет.
Неужели в принципе невозможно автоматически отловить ситуацию "провайдер упал и вставать не хочет"? По внешним признакам. Например вот если трафик через провайдера не идёт - разве не достаточный признак?

]]> Re: multipath route https://rulinux.net/message.php?newsid=7374&page=1#52738 https://rulinux.net/message.php?newsid=7374&page=1#52738 Thu, 24 Jun 2010 15:57:29 +0400 >>автоматический бэкап MX для получения внешней почты
Блин. Так нужно ж просто maillog фильтровать и смотреть когда статистика подключений через бэкап интерфейс будет больше, чем через основной. Для верности можно будет по черным спискам входящие проверить - если нет контакта, то можно смело переключать route ...

Вот и от спаммеров какую-то пользу можно получить.

]]> Re: multipath route https://rulinux.net/message.php?newsid=7374&page=1#52737 https://rulinux.net/message.php?newsid=7374&page=1#52737 Thu, 24 Jun 2010 07:10:42 +0400 Ну, вообщем эта задача (падение одного маршрута) на практике неразрешима. Т.е. можно обнаружить пропажу какого-то маршрута внутри своей сети, но не в сети находящейся вне вашего контроля. В случае с двумя провайдерами это равносильно предложению, чтоб оба эти провайдера слились в экстазе, чтоб обеспечить вас бесперебойной связью. Разумеется, никто на это не пойдет. Максимум, что можно - это автоматический бэкап MX для получения внешней почты и ручное переключение интернета (например, с помощью отключения оборванного route), когда после звонков по телефону и переговоров выясняется, что провайдер упал и вставать не хочет.

]]> Re: multipath route https://rulinux.net/message.php?newsid=7374&page=1#52736 https://rulinux.net/message.php?newsid=7374&page=1#52736 Wed, 23 Jun 2010 20:31:30 +0400 >>Заодно гугла может задосишь.
Кто о чем, а невесть_кто о Сереже Брине ... Ты, я смотрю, такую личную неприязнь к нему испытываешь, что кушать не можешь.

]]> Re: multipath route https://rulinux.net/message.php?newsid=7374&page=1#52735 https://rulinux.net/message.php?newsid=7374&page=1#52735 Wed, 23 Jun 2010 18:40:10 +0400 проблем особых не вижу, для изратных случаев извратные решения. А так, всё равно лучше поиспытывать на практике.

]]> Re: multipath route https://rulinux.net/message.php?newsid=7374&page=1#52734 https://rulinux.net/message.php?newsid=7374&page=1#52734 Wed, 23 Jun 2010 18:13:07 +0400 >> http://www.linux.com/archive/feature/113988
Вот-вот ... Именно на эту байку я и повелся. Но там самый жЫр в камментах, когда аффтара на чистую воду выводят. Выяснилось, что он практически полностью скопипастил статью с какого-то индийского журнала, где это было рассчитано на шаткие модемные линии ...

]]> Re: multipath route https://rulinux.net/message.php?newsid=7374&page=1#52733 https://rulinux.net/message.php?newsid=7374&page=1#52733 Wed, 23 Jun 2010 16:25:10 +0400 полистай, может это чем-то поможет, мне при беглом осмотре последнее понравилось

 http://linux-ip.net/html/adv-multi-internet.html

 http://blog.taragana.com/index.php/archive/how-to-load-balancing-failover-with-dual-multi-wan-adsl-cable-connections-on-linux/

 http://www.wlug.org.nz/FailoverInternetConnection

 http://www.linux.com/archive/feature/113988

]]> Re: multipath route https://rulinux.net/message.php?newsid=7374&page=1#52732 https://rulinux.net/message.php?newsid=7374&page=1#52732 Wed, 23 Jun 2010 16:17:26 +0400 таки да, нужен RIP

]]> Re: multipath route https://rulinux.net/message.php?newsid=7374&page=1#52731 https://rulinux.net/message.php?newsid=7374&page=1#52731 Wed, 23 Jun 2010 15:57:49 +0400 Повесь на крон скрипт который будет пинговать гугл и дропать интерфейс если чо. Заодно гугла может задосишь.

]]> Re: multipath route https://rulinux.net/message.php?newsid=7374&page=1#52730 https://rulinux.net/message.php?newsid=7374&page=1#52730 Wed, 23 Jun 2010 15:01:57 +0400 Хрень какая-то ... Нифига он не детектирует отключение линка. Если вручную один route уронить (можно вместе с интерфейсом), то тогда, ясен пень, маршрутизация идет через оставшийся default gw, но самостоятельно ядро это не детектирует. Если подумать, то задача-то достаточно нетривиальная, обнаружить падение сети где-нибудь в недрах провайдера. Это какая-то Quagga нужна, и то если удастся договориться с провайдером об используемом протоколе. Ну, или какой-то скрипт, чтоб проверял, что текущий провайдер виден.

Блин, повёлся на эти интернетовские байки, как школьник ...

]]> Re: multipath route https://rulinux.net/message.php?newsid=7374&page=1#52729 https://rulinux.net/message.php?newsid=7374&page=1#52729 Wed, 23 Jun 2010 10:55:59 +0400 Ты только не из сетевой карты выдёргивай а где-нить за внешним хабом/модемом - что бы интерфейсы оставались поднятыми для чистоты эксперимента.

]]> Re: multipath route https://rulinux.net/message.php?newsid=7374&page=1#52728 https://rulinux.net/message.php?newsid=7374&page=1#52728 Wed, 23 Jun 2010 09:49:44 +0400 оказалось, что это стэк. Т.е. основной - тот, что последний. Щас попробую шнуры повыдергивать ...

]]> Re: multipath route https://rulinux.net/message.php?newsid=7374&page=1#52727 https://rulinux.net/message.php?newsid=7374&page=1#52727 Wed, 23 Jun 2010 07:47:35 +0400 >Вопрос - кто из маршрутов главный, а кто запасной?
Наверное, который первый в таблице - тот и главный. Я бы например, эмпирическим методом проверил с tcpdump'ом

]]> multipath route https://rulinux.net/message.php?newsid=7374&page=1#52726 https://rulinux.net/message.php?newsid=7374&page=1#52726 Wed, 23 Jun 2010 06:43:00 +0400 Помогите с failover каналом через второго провайдера. Чтоб если один провайдер (основной) упал, то можно было бы работать через второго.

Нарыл два варианта решения проблемы.

Один:

route add default gw a.a.a.a dev eth0 route add default gw b.b.b.b dev eth1

И если один грохнется, то через (cat /proc/sys/net/ipv4/route/gc_interval) секунд заработает второй. Вопрос - кто из маршрутов главный, а кто запасной? Или в порядке поступления (fifo,стэк?)? И если главный поднимется после падения, то восстановится ли маршрут через него?

Второй вариант с iproute2 (в духе  http://lartc.org/howto/lartc.rpdb.multiple-links.html). Там всё вроде бы явно расписано, но не является ли это просто эквивалентом первого варианта (с тем же таймаутом из gc_interval)? Вроде ж iproute2 - это только узерспейс утилиты, системные вызовы должны были бы остаться теми же самыми ...

]]>