route & ip route

скорее всего в одном просто предусмотрели проверку на дубликаты а во втором нет, безо всяких скрытых смыслов

прикол в том - что я думал что всегда работает по 1 варианту
а когда обнаружился 2ой - он для одного применения - крайне - очень сильно облегчает логику работы
во почему так и почему - и не отключат ли 2ой(старый) вариант - неизвестно

Что он облегчает? Маршрут всё равно один, остальные три не учитываются. Или оно по-другому работает?

до одной сети - один роутинг
когда появляется второй путь (лучше) - то просто заносиш его в роутинг через 2 вариант - даже без применения метрик - и он заноситься и начинает работать перекрывая первый роутинг
а потом - если 2ой путь отгадывает - то удаление именно его - оставляет один (старый) роутинг и он опять работает

и это все работает автоматом само по себе - и без применения метрик (который в моем варианте проблемно применить)

когда появляется второй путь (лучше) - то просто заносиш его в роутинг через 2 вариант

Для этого придумали протоколы динамической маршрутизации и метрики маршрутов. Тогда весь список маршрутов хранятся в демоне(quagga, frr, bird), а в маршрутной таблице - только лучший маршрут(или несколько, если настроен multipath).

и это все работает автоматом само по себе - и без применения метрик (который в моем варианте проблемно применить)

не вижу проблемы чем здесь не применить метрику

не отключат ли 2ой(старый) вариант - неизвестно

Проверки судя по всему находятся внутри самой утилиты, потому что сама ситуация с множеством маршрутов в ядре - она в общем-то валидна.

Другое дело что route(наряду с ifconfig) успешно закапывают уже не один год в пользу ip route. И рано или поздно просто возникнет ситуация, когда в новом дистрибутиве net-utils(кажется так называется пакет, в составе которого эти утилиты располагаются) тупо не опакетят.

а тупо неудобна метрика - она конечно работает - но ...
суть в том - что вот так - работает автоматом без ничего

а frr с ospf есть - и еще начинает мешаться - он думает что удаление одного роутинга равноценно удалению всех роутингов до нужной сети - что не так в этом случае

я по strace-сил - именно ядро ругаеться на такой роутинг - не утилита

Значит если это так, тогда какой-то индекс у маршрута всё-таки разный в одно случае, а в другом - он совпадает, отсюда и ругань на дубликат.

Если интересно - сравни маршруты в /proc/net/routes.

он думает что удаление одного роутинга равноценно удалению всех роутингов до нужной сети - что не так в этом случае

Так если они одинаковые - тогда да. Для этого метрика и нужна - чтобы их различать.

Не нравится метрика? Используй tag:

ip route 10.1.1.1 255.255.255.255 127.0.0.2 tag 2

Update: не, ошибся, одним tag-ом разные маршруты по крайней мере в frr не сделать. Но удалить конкретный маршрут с конкретным шлюзом по умолчанию(а не все сразу) в frr - вполне реально.

если 2 статик роутинга до сети - с разными метриками
то если удалить один - то frr подумает что удалено все - и начинает добавлять свое

/proc/net/routes смотрел - идентичны

изначально я пытался приделать добавление роута в C программу - без вызова внешних утилит - там есть 2 способа
через ioctl и через netlink
вот старый - простой - это через ioctl - вот тут и заметил что они по разному работают - сначала подумал что глюк какой то

root@gw3: ~# ip ro add 10.1.1.1 via 127.0.0.2
root@gw3: ~# ip ro add 10.1.1.1 via 127.0.0.2
RTNETLINK answers: File exists
root@gw3: ~# ip ro add 10.1.1.1 via 127.0.0.2 prio 10
root@gw3: ~# ip ro add 10.1.1.1 via 127.0.0.2 prio 20
root@gw3: ~# ip ro
default via 10.7.0.254 dev eth0 
10.1.1.1 via 127.0.0.2 dev lo 
10.1.1.1 via 127.0.0.2 dev lo metric 10 
10.1.1.1 via 127.0.0.2 dev lo metric 20 

Но смысла в это IMHO нет.

если 2 статик роутинга до сети - с разными метриками то если удалить один - то frr подумает что удалено все - и начинает добавлять свое

Я хз, что ты делаешь не так - добавил два маршрута в frr с разными метриками:

mini-router [~]# vtysh
mini-router# conf t
mini-router(config)# ip route 10.1.1.1 255.255.255.255 192.168.1.11 1
mini-router(config)# ip route 10.1.1.1 255.255.255.255 192.168.1.12 2

Смотрим результат:

mini-router [~]# vtysh
mini-router# show ip route 10.1.1.1
Routing entry for 10.1.1.1/32
  Known via "static", distance 2, metric 0
  Last update 00:00:21 ago
    192.168.1.12, via br0, weight 1

Routing entry for 10.1.1.1/32
  Known via "static", distance 1, metric 0, best
  Last update 00:00:23 ago
  * 192.168.1.11, via br0, weight 1
mini-router# quit
mini-router [~]# ip route get 10.1.1.1
10.1.1.1 via 192.168.1.11 dev br0 src 192.168.1.10 uid 0
    cache

Удаляем маршрут через 192.168.1.1:

mini-router [~]# vtysh
mini-router# conf t
mini-router(config)# no ip route 10.1.1.1 255.255.255.255 192.168.1.11 1
mini-router(config)# quit
mini-router# quit

Смотрим что у нас в результате:

mini-router [~]# vtysh
mini-router# show ip route 10.1.1.1
Routing entry for 10.1.1.1/32
  Known via "static", distance 2, metric 0, best
  Last update 00:02:13 ago
  * 192.168.1.12, via br0, weight 1

mini-router# quit
mini-router [~]# ip route get 10.1.1.1
10.1.1.1 via 192.168.1.12 dev br0 src 192.168.1.10 uid 0
    cache

Хм, про pref в ip rule знал, а вот что есть prio в ip route - нет. Век живи - век учись, а всё равно дураком помрешь.Может на какой-нибудь хитрой штуке это пригодится.

Еще бы где-нибудь гайд по логике выбора лучшего маршрута в Linux учитывая все вот эти приоритеты, метрики и прочее.

Вспоминаю просто шикарнейший по своей всеобъемлимости гайд по выбору лучшего маршрута BGP в Cisco...

2 статик роута - просто в системе - а не в frr

так это просто метрики - название другое

Один вопрос - нафига тебе такая конструкция понадобилась?

Какую логику оно упрощает?

а тупо неудобна метрика - она конечно работает - но ...

Метрика как раз удобнее, так как есть однозначность.

изначально я пытался приделать добавление роута в C программу - без вызова внешних утилит - там есть 2 способа

Так флаги у нетлинка то посмотри, с которыми команду ядру шлешь.

/* Modifiers to NEW request */
#define NLM_F_REPLACE   0x100   /* Override existing        */
#define NLM_F_EXCL      0x200   /* Do not touch, if it exists   */
#define NLM_F_CREATE    0x400   /* Create, if it does not exist */
#define NLM_F_APPEND    0x800   /* Add to end of list       */

route - NLM_F_CREATE (само ядро добавляет для ioctl)
ip route add - NLM_F_CREATE | NLM_F_EXCL
ip route append - NLM_F_CREATE | NLM_F_APPEND

Как хочешь, так и комбинируешь

да - когда пробовал и через него получалось добиться этой странной работы
вопрос то в том - что я и не думал что оно так вообще способно работать
что на 1 сеть - можно прописать 2 роутинга с одинаковыми метриками - и что при этом из этих 2 - работало бы последнее добавленное (а если его удалить - то автоматом работало первое)

при очередной переборке системы - захотелось как то упростить вот эту раздачу роутинга сетям (сделать крисивше)
до этого оно работало с внешней базой данных - которая помнила все пути до сети - и при отпадание текущего пути - восстанавливала предыдущий путь
нет не через frr а просто скриптами

а вот с этим ... вообще не надо ничего - оно тупо работает автоматом как надо (но терь frr начинает гадить)

с метриками - их надо помнить - надо помнить какую последнею метрику ты выдал
и может быть ситуация
вот выдал ты пути метрику 10
подключился путь 2 - ему выдаешь 9
1вый путь отпадывает - и заново подключается - и ему как самому новому будешь выдать метрику 8
и так далее до 0
что не есть хорошо

а с этим - когда роутинги до сети просто добавлены по порядку - и работает последний добавленный - вообще ничего не надо более делать

1вый путь отпадывает - и заново подключается - и ему как самому новому будешь выдать метрику 8

Я говорю про статическое присвоение меток. Когда у вас пути10 всегда присваивается метрика10.

такое для этой задачи нельзя
путь должен быть всегда тот который последний появился