Сценарий (http://sources.homelink.ru/fallback-gw/) для переключения маршрутов на резервный канал, если основной шлюз перестал отвечать на пинг. Умеет проверять несколько шлюзов, каждому набору шлюзов может быть назначено несколько подсетей. Вызывается через cron. Проверен на FreeBSD и на Linux c iproute2. Команды проверки и переключения при желании можно переопределять в файле настроек.URL: http://sources.homelink.ru/fallback-gw/
Новость: http://www.opennet.me/opennews/art.shtml?num=21545
2автор:Хороший скрипт.
Ещё могу посоветовать посмотреть в сторону распараллеливания пингов.
Чтобы не ждать <количество пингуемых точек> * <количество пингов> секунд.Сам в свое время сделал так:
shell скрипт в цикле запускает пинги командой "ping ... $ip > /file.$ip &"
Ждет нужное количество секунд и извлекает информацию из всех файлов разом.
Таким образом опрашивалось 7 точек по 25 пингов каждые 40 секунд.В perl можно посмотреть в сторону fork или в сторону threads.
Я бы ещё предложил system("ping $ip &"), но понимаю, что это не по фен-шую)
Во фряхе перл системный без тредов собран по дефолту. С форками - гемора было бы больше, чем толку, ИМХО.
>Во фряхе перл системный без тредов собран по дефолту. С форками -
>гемора было бы больше, чем толку, ИМХО.Да, без тредов.
А насчет гемора - смотря какие приоритеты.
Если приоритет, чтобы работало быстро, важнее лени, то программист заморочится.
В fallback-gw пинг работает до первого ответа,
поэтому ждать придётся только в случае отказа,
который бывает не каждый месяц.
В нормальной ситуации всё отрабатывает мгновенно.
>В fallback-gw пинг работает до первого ответа,
>поэтому ждать придётся только в случае отказа,
>который бывает не каждый месяц.
>В нормальной ситуации всё отрабатывает мгновенно.Да, вижу.
Тогда у нас с вами были немного разные цели.
В моем случае ещё был такой фактор, как процент потерь в канале.
Советую использовать perlcritic и книгу Perl Best Practices для доработки скрипта.