Задачка на маршруты (динамические)

Не ужели ни это?! http://www.linux.org.ru/forum/admin/4810239#comment-4811210 (комментарий)

Ну хорошо, упрощу вопрос: есть ли способ настроить ЭТО, не прибегая к стрельбе из танка по воробьям? Я имею в виду: есть ли лёгкие демоны динамической маршрутизации для таких простых вещей или без разницы какой гвоздь, всё равно у нас кроме микроскопов ничего нет?

чтобы при падении прямого линка

а по каким признакам будет определяться падение линка? :)

http://ru.wikipedia.org/wiki/RIP_(сетевой_протокол) Падение линка = превышение интервала ожидания. Понятно, что линк с бесконечной задержкой пакетов (разрыв) и линк с задержкой в несколько секунд для большинства применений - равнозначны.

Как это настроить за минимальное количество шагов?

google://настроить+динамическую+маршрутизацию+linux+quagga

quagga ?

На самом деле вы зря боитесь OSPF и прочих, они настраиваются в несколько строк, ресурсов не хотят (у меня OSPF работает, вместе с парой OpenVPN тоннелей на openwrt роутере с 16 мегами мозгов).

Для реализации OSPF можно юзать всем известную Кваггу или менее известный, но гораздо менее требовательный к ресурсам BIRD.

Если нужен пример конфига - могу привести.

А вот и молоток, не кувалда, но молоток. Спасибо, на заметку!

Если нужен пример конфига - могу привести.

Да, пригодился бы. Поскольку у зебры уродский цискосинтаксис, мне гораздо больше приглянулась птичка (да и комментарии там в конфиге очень душевные!). Вот для неё, если можно.

Ну, поработав долгое время с цысками начинаешь находить прелесть в их конфигах :)

Птица настраивается несколько сложнее, чем квагга, но тоже достаточно просто:

log syslog all;
router id 192.168.0.1;

protocol kernel {
        export all;
        scan time 15;
};

protocol ospf {
        import all;
        export all;

        area 0 {
                interface "eth0" {
                        cost 1;
                        hello 5;
                        priority 100;
                        dead 15;
                        authentication cryptographic;
                        password "ololo";
                };
         };
};

Это в общем-то минимальный вариант, можно еще убрать авторизацию. Т.е. OSPF будет работать с интерфейсом eth0, анонсировать его подсеть соседям.

Какая у тебя топология фиг знает, но я думаю адаптировать будет не сложно.

Грубо говоря, если роутеры А Б и В соединены треугольником и на каждой его стороне своя подсеть, то тупо запускаем OSPF на всех интерфейсах и оно договорится само.

ЗЫ: Оно может срать в логи во время работы что-то вроде RNETLINK: File Exists, это из-за того, что птица похоже анонсирует обратно в т.ч. те маршруты, которые получила с той же стороны. А получив их, пытается добавить в таблицу маршрутизации, хотя они там и так есть. Лечится написанием фильтров, вроде:

protocol kernel {
        export filter {
            if net ~ [ 192.168.254.2/32+ ] then {
                reject;
            }

            if net ~ [ 192.168.254.4/32+ ] then {
                reject;
            }

            if net ~ [ 192.168.254.6/32+ ] then {
                reject;
            }

            if net ~ [ 192.168.254.8/32+ ] then {
                reject;
            }

            if net ~ [ 192.168.254.10/32+ ] then {
                reject;
            }

            if net ~ [ 192.168.254.254/32+ ] then {
                reject;
            }

            accept;
        };

        scan time 15;
};

У квагги такой проблемы нет, хотя может она ее тщательно скрывает :)

Ага...

Интересно. Слушайте, а ведь можно не прописывать в настройках OpenVPN все эти директивы route add, а просто распространять «пути» с помощью OSPF?

А ещё: если у меня к маршрутизатору подрублены 5 сетей (так оно и есть), как анонсировать только одну из них на данном интерфейсе. Ну т.е.чтобы на других маршрутизаторах не добавлялся маршрут в ненужные сети, тем более, что всё равно им доступ закрыт фаерволом. Это фильтр нужно написать?

Насчёт цисок - я их синтаксис не перевариваю по той же причине, по которой органически не выношу slapd.conf и очень уважаю дерево cn=config: у Quagga настройки выглядят как сплошной поток сознания без конца и края.

Победные интерпрайз инженеры настраивают роутинг.

Ну т.е.чтобы на других маршрутизаторах не добавлялся маршрут в ненужные сети,
тем более, что всё равно им доступ закрыт фаерволом. Это фильтр нужно написать?

C ospf/quagga не выйдет: https://bugzilla.quagga.net/show_bug.cgi?id=414

у Quagga настройки выглядят как сплошной поток сознания без конца и края.

Но это самый живой вариант пока. А так xorp ещё есть...

Да, у меня так и сделано. Топология - два сервера, основной и резервный, и клиенты. На каждом клиенте два тоннеля, оспф кост к резервному выше, чтобы траффик через него не ходил, пока есть основной. Клиенты анонсируют каждый свою сеть. В итоге все всех видят безо всякой настойки роутинга вручную.

Только нужно учитывать, что в режиме point multipoint в опенвпн со стороны сервера все клиенты сидят за одним интерфейсом и косты настраивать в сторону клиентов невозможно, только сразу на всех. Но это в общем не особо и нужно.

Просто пометить эту сеть в конфиге как стаб, т.е. сеть, которую нужно анонсировать, но в ней самой других роутеров нет и все.

Взять cisco, настроить Cisco SLA и радоваться

man ospfd, не?

а ospfd тяжелый штоле? не знал

RIP - унылое говно, поверь мне

по поводу BIRD вопрос, я вижу вы знаток, а я мануал по ней только мельком читал. Можно ли на птице реализовать такую штуку - 2 независимых процесса ospf, каждый из которых будет держать backbone-зону(0.0.0.0). Между эти двумя зонами обмен маршрутов производить НЕ НУЖНО. Понимаю, задача специфическая, но не заменить одну из 0.0.0.0 областей, ни тем более virtual-link сделать я не могу. Поставить еще один роутер тоже не вариант - свободного железа нет

бэкбон зоны в данном случае висят на разных интерфейсах и они разные, каждая со своим набором маршрутов, не пересекающихся друг с другом

blind_oracle, посмотри, пож., я скоммуниздил конфиг для зебры и переделал под себя. Но... что-то OSPF интерфейсы не видит.. Здесь сеть 192.168.5.0/24 - локальная сеть, в которой находится маршрутизатор.
Все 10.55.X, кроме 10.55.102. - это VPN-линки к соседним маршрутизаторам (они и физически, и логически очень далеко находятся).
10.55.102. - сеть для подключения клиентов - road-warrior'ов из любой точки Шарика:

hostname boson
password 123
log file /var/log/quagga/ospfd.log
!
!
!
interface eth0
!
interface eth1
!
interface lo
!
interface tun0
ip ospf authentication message-digest
ip ospf message-digest-key 1 md5 rowars_boson
ip ospf cost 10
!
interface tun1
ip ospf authentication message-digest
ip ospf message-digest-key 1 md5 proton_boson
ip ospf cost 3
!
interface tun2
ip ospf authentication message-digest
ip ospf message-digest-key 1 md5 kaon_boson
ip ospf cost 2
!
interface tun3
ip ospf authentication message-digest
ip ospf message-digest-key 1 md5 gluon_boson
ip ospf cost 8
!
interface tun5
ip ospf authentication message-digest
ip ospf message-digest-key 1 md5 fermion_boson
ip ospf cost 7
!
router ospf
ospf router-id 192.168.5.1
redistribute connected route-map Local_Network
network 192.168.36.0/24 area 0.0.0.0
network 10.55.10.0/24 area 0.0.0.0 
network 10.55.15.0/24 area 0.0.0.0 
network 10.55.16.0/24 area 0.0.0.0 
network 10.55.20.0/24 area 0.0.0.0 
network 10.55.102.0/24 area 0.0.0.0
area 0.0.0.0 authentication message-digest
!
ip prefix-list Local_Network seq 10 permit 192.168.5.0/24
ip prefix-list Local_Network seq 100 deny any
!
route-map Local_Network permit 10  
match ip address prefix-list Local_Network
!
line vty
!

Особо во всём этом смущает то, что network'и прописываются не под определениями интерфейсов и вот это:

ip prefix-list Local_Network seq 10 permit 192.168.5.0/24
ip prefix-list Local_Network seq 100 deny any

Ой, да, забыл сказать, что за проблема :) Проблема в том, что OSPF не видит интерфейсы (show ip ospf interfaces в консоли зебры)

Я, по правде говоря, не пробовал.

Но, по идее, процессы OSPF полностью независимы, и если они будут работать с разными подсетями и наборами интерфейсов, то никаких проблем я не вижу в общем-то.

Line vty убрать можно я думаю, у меня без него консоль пахала.

А интерфейсы tunX (OpenVPN?) мультикаст умеют пробрасывать? Т.к. по умолнчанию OSPF работает мультикастом. ip addr бы посмотреть что показывает. Ну и логи тоже. Но на первый взгляд вроде бы всё верно. Area 0.0.0.0 можно писать просто 0.

Вот такая вот печальная штука наблюдается...
Думаю, действительно может быть проблема в хождении мультикаст-пакетов. Например, в том, что они банально режутся фаерволлом...
[code]
boson.someshit.com# show ip ospf interface
eth0 is down
OSPF not enabled on this interface
eth1 is down
OSPF not enabled on this interface
lo is down
OSPF not enabled on this interface
tun0 is down
OSPF not enabled on this interface
tun1 is down
OSPF not enabled on this interface
tun2 is down
OSPF not enabled on this interface
tun3 is down
OSPF not enabled on this interface
tun5 is down
OSPF not enabled on this interface
[/code]

Нет, ну одно дело «not enabled», что странно, другое дело если бы он просто не видел OSPF-соседей на этих интерфейсах.

Я бы конфиг переписал так, чтобы не было route-map и прочих ненужностей:

hostname boson
password 123
log file /var/log/quagga/ospfd.log
!
interface tun0
 ip ospf authentication message-digest
 ip ospf message-digest-key 1 md5 rowars_boson
 ip ospf cost 10
!
interface tun1
 ip ospf authentication message-digest
 ip ospf message-digest-key 1 md5 proton_boson
 ip ospf cost 3
!
interface tun2
 ip ospf authentication message-digest
 ip ospf message-digest-key 1 md5 kaon_boson
 ip ospf cost 2
!
interface tun3
 ip ospf authentication message-digest
 ip ospf message-digest-key 1 md5 gluon_boson
 ip ospf cost 8
!
interface tun5
 ip ospf authentication message-digest
 ip ospf message-digest-key 1 md5 fermion_boson
 ip ospf cost 7
!
router ospf
 ospf router-id 192.168.5.1
 network 10.55.10.0/24 area 0
 network 10.55.15.0/24 area 0
 network 10.55.16.0/24 area 0
 network 10.55.20.0/24 area 0
 network 10.55.102.0/24 area 0
 network 192.168.5.0/24 area 100

 area 100 stub
 area 0 authentication message-digest

Что за сеть 192.168.36.0/24 я не понял, убрал. Ну и смотри ospfd.log

И покажи ip addr

На ip addr говорит % Unknown command., то же самое - в ответ на show ip addr.
Сети 192.168.36.0/24 здесь нет, это я ошибся: скопировал с другого роутера и не исправил.
Кстати, сеть 192.168.5.0/24 должна анонсироваться на прочие маршрутизаторы (в ней как раз сидят люди, которые должны по удалённым сервакам ходить, так что там должен быть обратный маршрут в 5-ю подсетку). Наверное, stub нужно удалить?
С мультикастом всё странно. Вот что меня смущает: я добавил iptables -I INPUT -s 224.0.0.0/4 -j LOG --log-prefix 'MCAST_IN:' и не вижу ни одного пакета в syslog'е...

Ну... ip addr в линухе, а не в зебре. Сеть стаб как раз говорит о том, что ее надо анонсировать, но в ней самой других роутеров, кроме этого нет. Мультикаста не будет пока OSPF на интерфейсах не включится.

Вот кстати - http://openmaniak.com/openvpn_routing
Прямо то, что нужно. Я попробую настроить тестовые VPN-каналы по такому принципу, как в статье. Иначе, мне кажется, я долго ещё буду мучаться (статья по ссылке - вообще _единственная_ понятная вещь из всего вороха доков, которые я за последнее время перечитал).
Там, кстати, интересный какой-то хак применяется: на loopback поднимаются некие фейковые адреса 10.1.1.1/32, 10.2.2.2/32 и 10.3.3.3/32 соотв.-но. Как думаешь, для чего так сделано?
А вообще по-моему очень красиво сделано: крохотные по объёму конфиг-файлы VPN'а, лаконичные конфиги ospf'а, все маршруты прописываются автоматически. Ничего не сказано о правилах iptables, но это не страшно: можно по факту посмотреть, блокируется ли мультикаст и если нужно - разрешить.
Боюсь только с уже существующей конфигурацией будет конфликтовать: все маршруты-то уже есть, а делать что-либо с ними не могу: кроме одного, все сервера работают у чёрта на куличиках, не дай Бог вообще потерять коннект.

ip addr:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
2: eth2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop qlen 1000
    link/ether 00:1b:21:67:05:62 brd ff:ff:ff:ff:ff:ff
3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 00:21:91:f4:67:9e brd ff:ff:ff:ff:ff:ff
    inet 82.53.74.251/27 brd 82.53.74.255 scope global eth0
4: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 00:21:91:f4:68:fe brd ff:ff:ff:ff:ff:ff
    inet 192.168.5.1/24 brd 192.168.5.255 scope global eth1
5: tun5: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 100
    link/[65534] 
    inet 10.55.15.1 peer 10.55.15.2/32 scope global tun5
6: tun3: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 100
    link/[65534] 
    inet 10.55.20.1 peer 10.55.20.2/32 scope global tun3
7: tun2: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 100
    link/[65534] 
    inet 10.55.16.1 peer 10.55.16.2/32 scope global tun2
8: tun1: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 100
    link/[65534] 
    inet 10.55.10.1 peer 10.55.10.4/32 scope global tun1
9: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 100
    link/[65534] 
    inet 10.55.102.1 peer 10.55.102.2/32 scope global tun0

а зачем redistribute connected?

interface eth0
!
interface eth1

А почему ты айпишки им не задаешь то?

Вот так правильно, по идее:

interface eth0
ip address *.*.*.*/24
ipv6 nd suppress-ra7

Ну и тд.

На лупбеках поднимают сети для теста, на практике оно нахер не нужено.

У тебя проблема простая - не зря я ip addr просил. У тебя туннели строятся в режиме пир-ту-пир с маской /32, а в конфигах ты пишешь маску /24. Зёбра таких сетей не находит и оспф не активирует. Мультикаст в таком случае работать не будет никак.

Сделай в конфиге в каждом интерфейсе:

ip ospf network point-to-point

Брр.. зачем ему на этих интерфейсах айпишники? Это не цыска) Эти интерфейсы вообще надо выкинуть из конфига как я выше писал.

По поводу того, что всё сломается - статические маршруты имеют вес больше, чем динамические. Так что если динамика и заработает, то пока статику не уберешь траффик в нее ходить не будет.

А почему ты айпишки им не задаешь то?

Так они жеж не OSPF'ом назначаются, это статические адреса... Или их ospf может как-то назначить?

Так они жеж не OSPF'ом назначаются, это статические адреса... Или их ospf может как-то назначить?

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

8: tun1: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 100
    link/[65534] 
    inet 10.55.10.1 peer 10.55.10.4/32 scope global tun1

Вот! Кстати, ключевой вопрос: а что прописывать с маской /32?
Можно прописать 10.55.10.1, а можно и 10.55.10.4...

Дело не в этом, не путай человека. Айпишники интерфейсов задаются в системе, оспфу они нафиг не сдались.

Прописывать свой локальный интерфейс. По идее зёбра его опознает и посмотрит кто у него на дальнем конце (10.55.10.4) и будет ему отправлять пакеты уникастом, а не мультикастом.

Мда... лучше не стало :(

Покеж конфиг

hostname boson
password 051
log file /var/log/quagga/ospfd.log
!
interface tun0
 ip ospf authentication message-digest
 ip ospf message-digest-key 1 md5 rowars_boson
 ip ospf cost 10
!
interface tun1
 ip ospf authentication message-digest
 ip ospf message-digest-key 1 md5 proton_boson
 ip ospf cost 3
!
interface tun2
 ip ospf authentication message-digest
 ip ospf message-digest-key 1 md5 kaon_boson
 ip ospf cost 2
!
interface tun3
 ip ospf authentication message-digest
 ip ospf message-digest-key 1 md5 gluon_boson
 ip ospf cost 8
!
interface tun5
 ip ospf authentication message-digest
 ip ospf message-digest-key 1 md5 fermion_boson
 ip ospf cost 7
!
router ospf
 ospf router-id 192.168.5.1
 network 10.55.10.1/32 area 0
 network 10.55.15.1/32 area 0
 network 10.55.16.1/32 area 0
 network 10.55.20.1/32 area 0
 network 10.55.102.0/24 area 0
 network 192.168.5.0/24 area 100

 area 100 stub
 area 0 authentication message-digest

Как всегда, пишет, что не нашёл интерфейсы. И в типичном стиле очень плохо написанных приложений - не пишет ни как разбирал конфиг, ни что он при этом думал, ни хотя бы вообще что он делает и как, этот ospfd.
Кстати, я запускал в последние разы ospfd без самой зебры. Но по-моему сама зебра ничего и не делает, это просто фронтэнд.

И где в интерфейсах «ip ospf network point-to-point» про который я выше писал?

Без зебры оно не работает вроде, как раз она разруливает роуты между разными протоколами и ядром.

ip ospf network point-to-point Ёлы-палы, а теперь работает! Спасибо огромное, теперь бы ещё связку этих серверов-маршрутизаторов настроить, чтоб они друг друга засоседили :) Надо же, кто бы мог подумать, что оно при определённом сочетании загадочных буковок всё-таки увидит интерфейсы...

Тройное «УРА» :D

Ваще OSPF создан для работы по броадкастным сетям, вроде езернета. Там он заводится вообще на ура безо всяких шаманств.

А для всяких p2p и p2mp нужны уже подобные ухищрения...

Теперь просто настраивай аналогично девайсы на других концах туннелей и все друг друга увидят.