девайс, протокол?

хотя если все настроено правильно, то: 1) пойдут 2) вернется в не зависимости от того, статическая или динамическая маршрутизация используется.

«откажет» - это исчезнет из роут таблицы?

Некорректная постановка задачи. В общем случае «нет, ничего автоматически не переключится». В частных случаях - когда например рассматриваемые каналы это VPN-линки, то переключится. А если оба канала ethernet - то не переключится. Но если задействованы протоколы динамической маршрутизации - может и переключится. Слишком много неизвестных :-)

Уточню: обычная статическая маршрутизация (eth)

«Откажет» - перестанет пропускать, но не исчезнет из записей.

Пока маршрут с меньшей метрикой есть в таблице маршрутизации, он и будет использован. Маршрут удаляется из таблицы маршрутизации при падении интерфейса.

Если у вас несколько маршрутов через eth[0-9] через разных провайдеров, то пишите скрипт, который определит факт «отказа» и поправит маршруты.

>Если у вас несколько маршрутов через eth[0-9] через разных провайдеров, то пишите скрипт, который определит факт «отказа» и поправит маршруты.

Динамическая маршрутизация по ЛОРовски.

Метрики в линуксе не используются вообще, man route

metric M
              set the metric field in the routing table (used by routing  dae‐
              mons) to M.

используются, еще как. Кстати, сфейлил, извините, при падении-поднятии интерфейса статический маршрут не восстановится, так что надо писать скрипт, как посоветовали выше или использовать динамическую маршрутизацию. В любом случае, при падении интерфейса будет задействован маршрут с большей метрикой.

Интересует ситуация без падения интерфейса. Т.е. проблема на маршруе где то дальше ... Все сохраняется - и таблица и интерфейсы.

И как называется routing daemon в твоей системе? Каких демонов ты уже настраивал?

ospfd настраивал. Статической маршрутизацией не увлекался, но как-то странно слышать, что линукс метрики статических маршрутов игнорирует.

а ты ман дочитал? Сделай поиск дальше.

Может я не правильно понял вашу мысль, но метрики позволяют задать несколько машрутов.

Допустим маршруты в локальную сеть удаленного офиса (сети 10.2.3.x) --- один через ppp, а другой маршрут особого типа «unreachable», с большей метрикой. При падении ppp маршрутизатор на все пакеты в сеть 10.2.3.x будет отвечать «Destination Host Unreachable», а не отправлять их по default-маршруту.

Топикстартер не уточнил задачу, но бывают провайдеры, у которых иногда просто большие потери пакетов, и в этой ситуации, ИМХО, лучше всего скрипт-велосипед, который переключит на запасного провайдера по результатам пинга «ya.ru, google.com» и/или в определённые часы суток.

Там в мане(man route) написано что метрики ядро метрики не использует вообще. Я не спец по вопросам маршрутизации и могу ошибаться, но везде где я видел про маршрутизацию пишут что по барабану на всякие метрики.

на метрики по барабану, только если маршруты к разным по размеру сетям. Например если сети /27 и /28, то пакет пойдет по маршруту в сторону сети /28, невзирая на метрики. Если сети одинаковые, то разные метрики отработают, как миленькие. Однако ТС своего все равно таким способом не добъется.

> Метрики в линуксе не используются вообще, man route

man route прочел намного раньше вас, выводы такие - метрики используются, вы либо тролль, либо дурак

Это прочёл?

Metric The 'distance' to the target (usually counted in hops). It is not used by recent kernels, but may be needed by routing dae‐ mons.

[root@beta viking]# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
194.87.0.50     127.0.0.1       255.255.255.255 UGH   1      0        0 lo
194.87.0.50     192.168.1.1     255.255.255.255 UGH   20     0        0 wlan0
192.168.101.0   0.0.0.0         255.255.255.0   U     0      0        0 virbr0
192.168.1.0     0.0.0.0         255.255.255.0   U     2      0        0 wlan0
0.0.0.0         192.168.1.1     0.0.0.0         UG    0      0        0 wlan0
[root@beta viking]# ping www.ru
PING www.ru (194.87.0.50) 56(84) bytes of data.
^C
--- www.ru ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2843ms
========================
[root@beta viking]# route del -host 194.87.0.50 metric 1
[root@beta viking]# ping www.ru
PING www.ru (194.87.0.50) 56(84) bytes of data.
64 bytes from www.ru (194.87.0.50): icmp_seq=1 ttl=54 time=43.3 ms
64 bytes from www.ru (194.87.0.50): icmp_seq=2 ttl=54 time=39.4 ms
^C
--- www.ru ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1662ms
rtt min/avg/max/mdev = 39.456/41.419/43.382/1.963 ms
[root@beta viking]# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
194.87.0.50     192.168.1.1     255.255.255.255 UGH   20     0        0 wlan0
192.168.101.0   0.0.0.0         255.255.255.0   U     0      0        0 virbr0
192.168.1.0     0.0.0.0         255.255.255.0   U     2      0        0 wlan0
0.0.0.0         192.168.1.1     0.0.0.0         UG    0      0        0 wlan0
[root@beta viking]#

Можешь читать дальше, можешь спорить дальше, а у нас тут метрика замечательно используется. Хотя конечно, модет быть что ядро 2.6.33 недостаточно «recent»?

P.S.: я знаю как можно написатьь код, который не будет использовать использовать метрику явно при выборе маршрута, но метрика тогда окажет влияние на таблицу маршрутов в другой момент времени.

а можно поподробнее?

Вы не могли бы объяснить, что доказал этот эксперимент? Было 2 маршрута до корня ru, один дохлый через лупбэк, другой дублирует дефолтный маршрут. После удаления маршрута с лупбэком, трафик пошёл через дефолт gw. И это говорит нам о чём...?

значит я ошибся

Ну вот тебе без дефолта

[root@beta viking]# route add -host 194.87.0.50 dev lo gw 127.0.0.2 metric 1
[root@beta viking]# route add -host 194.87.0.50 dev wlan0 gw 192.168.1.1 metric 20
[root@beta viking]# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
194.87.0.50     127.0.0.2       255.255.255.255 UGH   1      0        0 lo
194.87.0.50     192.168.1.1     255.255.255.255 UGH   20     0        0 wlan0
192.168.101.0   0.0.0.0         255.255.255.0   U     0      0        0 virbr0
192.168.1.0     0.0.0.0         255.255.255.0   U     2      0        0 wlan0
169.254.0.0     0.0.0.0         255.255.0.0     U     1004   0        0 virbr0
[root@beta viking]# ping www.ru
PING www.ru (194.87.0.50) 56(84) bytes of data.
^C
--- www.ru ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2832ms

[root@beta viking]# route del -host 194.87.0.50
[root@beta viking]# route del -host 194.87.0.50
[root@beta viking]# route add -host 194.87.0.50 dev lo gw 127.0.0.2 metric 20
[root@beta viking]# route add -host 194.87.0.50 dev wlan0 gw 192.168.1.1 metric 1
[root@beta viking]# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
194.87.0.50     192.168.1.1     255.255.255.255 UGH   1      0        0 wlan0
194.87.0.50     127.0.0.2       255.255.255.255 UGH   20     0        0 lo
192.168.101.0   0.0.0.0         255.255.255.0   U     0      0        0 virbr0
192.168.1.0     0.0.0.0         255.255.255.0   U     2      0        0 wlan0
169.254.0.0     0.0.0.0         255.255.0.0     U     1004   0        0 virbr0
[root@beta viking]# ping www.ru
PING www.ru (194.87.0.50) 56(84) bytes of data.
64 bytes from www.ru (194.87.0.50): icmp_seq=1 ttl=54 time=37.0 ms
64 bytes from www.ru (194.87.0.50): icmp_seq=2 ttl=54 time=37.0 ms
64 bytes from www.ru (194.87.0.50): icmp_seq=3 ttl=54 time=37.1 ms
^C
--- www.ru ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2958ms
rtt min/avg/max/mdev = 37.048/37.095/37.182/0.168 ms

Метрика маршрута это последний аргумент в выборе маршрутов. Из двух маршрутов, приоритет имеет тот, что с наиболее точной маской. Если маски совпадают, приоритет имеет тот, что с меньшей метрикой. И даже если метрика будет просто определять позицию в которую вставляется запись маршрута, это все равно значит, что ядро _использует_ метрику для упорядочивания табицы маршрутов в правильном порядке.

В моих RedHat'ах «man route» датирован 2 January 2000, похоже, его с этого момента не правили, ибо есть команда ip (ip route).

А кто-нибудь помнит, в 2.0.x ядрах метрики маршрутов использовались?

Протоколы динамической маршрутизации всегда исходят из собственных метрик. Нагуглил мейл-лист, где обсуждался RIPv2 на линухе, сообщения датированы '99м годом, то есть метрики использовались и в 2.0.х.

> Протоколы динамической маршрутизации всегда исходят из собственных метрик

Метрика это интегральная характеристика маршрута, учитывающая множество характеристик - например, полосу пропускания канала связи, стоимость, дистанцию и т.д.. А демоны динамической маршрутизации считают метрики в зависимости от протокола, и в конечном итоге, на выходе получается список маршрутов (с метриками), который скармливается в ядро, и ядро используя его проводит маршрутизацию по стандартным правилам.

> Статической маршрутизацией не увлекался, но как-то странно слышать, что линукс метрики статических маршрутов игнорирует.

Не игнорирует, конечно.