LINUX.ORG.RU
Форум — Admin  

Маршрутизация с помощью метрик


1

0

Подскажите. Допустим, установлены различные метрики на маршруты (к одной цели). Ес-но будет выбираться маршрут с меньшей метрикой. Но, если этот маршрут «откажет», пойдут ли соединения через другой маршрут (автоматически)?
И вернется ли все в «нормальное русло», когда первый маршрут восстановится?



Последнее исправление: anonymus123 (всего исправлений: 1)
← на сервере не работает RTMP протокол
У меня сейчас крыша поедет. find -mtime →

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

templar
()

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

ventilator ★★★
()

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

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

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

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

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

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

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

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

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

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

dn2010 ★★★★★
()
Ответ на: комментарий от true_admin 
metric M
              set the metric field in the routing table (used by routing  dae‐
              mons) to M.

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

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

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

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

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

templar
()
Ответ на: комментарий от true_admin

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

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

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

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

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

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

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

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

anonymous
()
Ответ на: комментарий от true_admin

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

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

no-dashi ★★★★★
()
Ответ на: комментарий от true_admin 
[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.: я знаю как можно написатьь код, который не будет использовать использовать метрику явно при выборе маршрута, но метрика тогда окажет влияние на таблицу маршрутов в другой момент времени.

no-dashi ★★★★★
()
Ответ на: комментарий от no-dashi

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

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

zolden ★★★★★
()
Ответ на: а можно поподробнее? от zolden

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

[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
Стало легче? Почему в первом случае пинг не идет, а во втором идёт? Согласно моим знаниям - за счет метрики. А если посмотреть по вашей гипотезе (что ядро не использует метрику), то в обоих случаях должно либо не работать, либо работать. Ведь маршруты даже добавляются в одинаковом порядке - из-за чего же разница в поведении, если не из-за метрики?

no-dashi ★★★★★
()
Ответ на: комментарий от no-dashi

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

no-dashi ★★★★★
()
Ответ на: комментарий от no-dashi

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

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

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

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

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

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

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

no-dashi ★★★★★
()
Ответ на: комментарий от templar

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

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

AS ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← на сервере не работает RTMP протокол
Admin
У меня сейчас крыша поедет. find -mtime →