Linux change route metric ifmetric

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

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

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

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

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

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

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

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

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

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

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

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

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

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

И как называется 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.

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

Читайте также:  Kyocera fs 1125mfp драйвер mac os

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

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

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

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

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

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

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

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

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

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

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

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

Источник

Изменение существующей записи маршрута в Linux

Что такое команда для изменения метрики существующей записи маршрута в Linux? Я могу изменить шлюз существующей записи с помощью команды «ip route change», как показано ниже, но не могу изменить метрики. Есть ли другая команда для этого?

Как отмечено в комментарии к вопросу, цитируя сообщение в списке рассылки linux-net: «Метрика / приоритет не могут быть изменены [. ] Это ограничение текущего протокола [. ].»
Единственный способ — удалить маршрут и добавить новый.

Это делается с помощью route команды, пример:

(Объединение различных комментариев в ответ)

В настоящее время невозможно изменить метрику маршрута. В сообщении 2005 года о LKML говорится :

[. ] Метрика / приоритет не может быть изменена, потому что у нас нет отдельных полей для полей для сопоставления и новых значений, поэтому, если вы укажете метрику, запись просто не будет найдена, и запрос завершится неудачно с ENOENT, потому что NLM_F_CREATE не указано Это ограничение текущего протокола, и это может быть хорошей идеей, чтобы изменить это, однако это не тривиально [. ]

Похоже, что это применимо как к, так ip route change и к ip route replace — первое приводит к ошибке для меня, а второе создает дополнительный маршрут в соответствии с объявлением (на его странице руководства указано, что replace он заменит или создаст маршрут). Это согласуется с тем, что ядро ​​отвечает ENOENT и ip route replace выполняет запрос на создание маршрута.

Таким образом, решение состоит в том, чтобы удалить существующий маршрут и добавить новый. например

Источник

Как мне установить приоритет сетевых подключений в Ubuntu?

Если компьютер с Ubuntu 11.04 подключен к WiFi и 3G одновременно, как мне установить приоритет, чтобы приложения (браузер и т. Д.) Сначала использовали WiFi? Если это не доступно, он должен использовать 3G.

В принципе, я хотел бы установить порядок, в котором используются сетевые подключения.

Редактировать: я ищу более простой подход, который был бы полезен для тех, кто просто удобен и не является экспертом в Ubuntu / Linux.

Я удивлен , никто не упомянул простейшую команду , чтобы сделать это: ifmetric . Может быть установлен с помощью sudo apt-get install ifmetric . Эта команда может использоваться для изменения метрики любого интерфейса. Интерфейс с более низкой метрикой является предпочтительным для Интернета.

Чтобы использовать это, сначала посмотрите метрики с помощью route команды:

Здесь eth0 имеет более низкую метрику, поэтому будет предпочтительнее, чем wlan0 . Если вы хотите отдать предпочтение wlan0 , то уменьшите его показатель:

Теперь таблица маршрутизации будет выглядеть так:

Теперь Linux будет использовать wlan0 для Интернета. Изменение будет отражено немедленно.

Установка метрик — это то, как вы меняете приоритеты. Более высокая метрика является более «дорогой» в использовании, поэтому ОС будет использовать интерфейсы с самой низкой метрикой, если ей необходимо маршрутизировать трафик. В случае отключения интерфейса с более низкой метрикой он будет использовать интерфейс с более высокой метрикой, поскольку он является единственным интерфейсом, который можно использовать для маршрутизации трафика в эту конкретную сеть / пункт назначения.

Читайте также:  Активное время диска 100 windows 10 ssd

Метрики указаны в файле / etc / network / interfaces , ссылки на документацию.

Используйте любой текстовый редактор для редактирования файла, определения сетей, просто измените metric параметр и сохраните. Перезагрузка — это самый простой способ сбросить все значения, не вдаваясь в подробности перезапуска сетевых служб.

Приоритизация интерфейсов для общего трафика осуществляется путем манипулирования метриками маршрутизации. Каждый маршрут имеет связанные параметры, такие как количество переходов и пропускная способность. Смотрите параметр «метрика» на странице route руководства для команды.

Приоритизация доступа приложений к сетевым ресурсам часто решается путем «формирования трафика» — я бы использовал веб-поисковик, чтобы посмотреть, сможет ли это сделать Ubuntu или маршрутизатор.

В MS Windows, но не в Linux, netstat -nr команда выводит ту же информацию, что и route print . Включая метрики маршрутизации.

Я на самом деле не пробовал, но NCD (Network Configuration Daemon — 1) можно использовать для этой цели. Сайт утверждает, что облегчает настройку сети. Синтаксис кажется простым.

# Ждите какого-то сетевого соединения. Предпочитаю eth1, поставив его перед eth0.
list («NET-eth1», «NET-eth0») pnames;

Это все из-за метрик маршрута. Вы хотите удалить маршрут по умолчанию с самой низкой метрикой, а затем восстановить старый маршрут с более высокой метрикой. Пожалуйста, следуйте командам ниже.

Допустим, ваша таблица маршрутизации выглядит так:

Теперь удалите шлюз по умолчанию

Теперь восстановите старый шлюз по умолчанию (обратите внимание, что показатель в этом случае выше 102, чем текущий маршрут по умолчанию 101)

[Обновление] Начиная с Ubuntu 18.04 LTS (сервер), netplan это оболочка по умолчанию для управления сетью. Настройка Netplan по умолчанию выполняется через файл YAML /etc/netplan/01-netcfg.yaml (более подробно здесь ).

Метрика маршрутизации определяется параметром » metric «, который ожидает положительное целое число ( 100 обычно это значение по умолчанию). Вот пример со справочной страницы:

Маршрут с наименьшим metric (длина пути) становится «предпочтительным» шлюзом. (Используйте: sudo netplan try для включения изменений)

Обратите внимание, что в среде роуминга (несколько подключений, включение и выключение) может потребоваться установить для параметра optional (логическое значение) значение true (по умолчанию — false):

Обратите внимание на немного другой синтаксис для метрики маршрута в случае соединений DHCP.

Вы также можете использовать NetworkManager в качестве средства визуализации, которое, как я полагаю (я еще не проверял), позволит вам просматривать / редактировать эту часть конфигурации также с помощью инструментов GUI.

Используйте данный сетевой бэкэнд для этого определения. В настоящее время поддерживаются networkd и NetworkManager . Это свойство может быть указано глобально networks: , для типа устройства (например, ethernets: ) или для конкретного определения устройства. По умолчанию это networkd .

(Самый последний «большой» пример на странице ссылок показывает такое гибридное использование обоих средств визуализации).

Источник

Arch Linux

You are not logged in.

#1 2016-12-24 08:11:34

[Resolved]How to change the default route metric

I am running into a problem and would like to know a quick fix to that. Currently ip route default GW has got the values:
default via 192.168.10.1 dev eth0 proto static metric 100
default via 192.168.42.129 dev usb0 proto static metric 101

I would like to change the metric value of the usb0 interface temporarily lower than the eth0 to be chosen for the outgoing traffic. How can I achieve this?
Thanks

Last edited by h.safe (2016-12-27 11:59:48)

Why did Bodhidharma come from the west?

#2 2016-12-24 08:30:09

Re: [Resolved]How to change the default route metric

could be easily done with the

command. see man ip-route for more info.

#3 2016-12-24 09:21:14

Re: [Resolved]How to change the default route metric

I couldn’t and I appreciate you to share that «easily» one line code here .

Why did Bodhidharma come from the west?

#4 2016-12-24 13:11:04

Re: [Resolved]How to change the default route metric

How long did you try? Try again, maybe invoke google.
The solution is absolutely straightforward and posting it *will* be embarrassing.

#5 2016-12-26 05:49:19

Re: [Resolved]How to change the default route metric

Embarrassing is the hollow reply posts that gets people nowhere but a count up for you. try google and immediately will get to know it is not at all a simple straight forward solution to it in Linux boxes and particularly when multiple default routes are in question.

Why did Bodhidharma come from the west?

#6 2016-12-26 08:40:56

Re: [Resolved]How to change the default route metric

Do yourself a favor and use a smartphone instead.

#7 2016-12-26 10:25:55

Re: [Resolved]How to change the default route metric

There doesn’t seem to be a one-liner to change an existing metric, strangely.

In general, I would prefer adding the new route entry *first*, to prevent a short time period where there might be no route (not applicable to this particular example, I know).

Читайте также:  Windows server update services connect to server

#8 2016-12-26 12:33:06

Re: [Resolved]How to change the default route metric

The one-liner would be «ip route change . » but it fails on many realtek chips, unfortunately.
You can reverse the calls (add first, then del) — should bear no harm either.

#9 2016-12-26 12:49:25

Re: [Resolved]How to change the default route metric

The one-liner would be «ip route change . » but it fails on many realtek chips, unfortunately.

It fails on Intel chips, too. But anyway, why would setting network route metrics be dependent on hardware? Doesn’t routing happen in the kernel anyway?

#10 2016-12-26 13:11:53

Re: [Resolved]How to change the default route metric

I’ve never digged into it but it looks like some ioctl fails due to some blocked(?) rtnetlink socket. I’ve frankly no idea which causes this, the actual kernel module or its state *might* be relevant.
I recall it to have worked on an intel chip, but this might be just coincidental — I just checked and fails on a broadcom chip as well. It’s probably not HW related at all then.
Software or general kernel bug then.

#11 2016-12-26 13:27:34

Re: [Resolved]How to change the default route metric

The one-liner would be «ip route change . » but it fails on many realtek chips, unfortunately.

Let’s see an actual command that should *work*, from you, rather than insults.

AFAICT, it is not possible to *change* an existing metric, using the «ip» command — which I reckon is a bug with the «ip» command

#12 2016-12-26 13:50:15

Re: [Resolved]How to change the default route metric

I’ve never promised a one-liner, neither did «Into the Pit», that’s h.safe’s claim.
And add/remove *does* change this, is straight forward and *very* simple to figure?
You could even shadow ip route change with an alias that does so, so don’t jump around on insinuated promises and call me insulting — I said this is trivially easy to figure and it *is* on the first google result and requires nothing but copy + paste magic. The OP didn’t ask «why does ip change not work» (for he could have then googled the error and found «use add/del» on the first google result *again*

And what and do you believe would happen to your routing table when «change» did work? Either you got two routes (add/del) briefely none (del/add) or an atomic action (ie a grand kernel lock).

#13 2016-12-26 15:36:00

Re: [Resolved]How to change the default route metric

Embarrassing is the hollow reply posts that gets people nowhere but a count up for you. try google and immediately will get to know it is not at all a simple straight forward solution to it in Linux boxes and particularly when multiple default routes are in question.

Note, this is not based solely on my opinion.

Nothing is too wonderful to be true, if it be consistent with the laws of nature — Michael Faraday
Sometimes it is the people no one can imagine anything of who do the things no one can imagine. — Alan Turing

How to Ask Questions the Smart Way

#14 2016-12-27 11:53:51

Re: [Resolved]How to change the default route metric

Hello all,
Thanks everyone on this,
a reminder of the forum name :Newbie Corner.

Why did Bodhidharma come from the west?

#15 2016-12-27 13:53:22

Re: [Resolved]How to change the default route metric

Yes, and not «customer service».

The problem is not the newbieness, the problem is that you asked, got a good hint where to look, NOT EVEN ONE HOUR later said «i can’t, please tell me the exact line» and when being suggested that you should at least *try* for yourself first, because the answer really is so trivial, expressed to be offended to be asked to try google.

This is considered help vampirism and not how things work. You get assistance on learning or figuring things, but don’t get your problems solve, because you’re simply too lazy to figure yourself. And don’t tell me that you got the hint, really tried, failed and asked back — within 50 minutes, while just googling for «ip route change metric» virtually spams the answers in your face.

Had you returned with «tried ip route change but it always says error» or «i don’t understand what the NODE_SPEC in the manpage means», this discussion would have taken an entirely different route.

Источник

Оцените статью