LINUX.ORG.RU
ФорумAdmin

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


0

1

Дано:
1. Прямой маршрут от хоста А до хоста Б, время прохождения пакета t1
2. «Кривой» маршрут от хоста А до хоста Б через хост В, время прохождения пакета t2
3. t1<t2 или даже t1 <<< t2

Требуется:
Автоматически перенастраивать маршрутизацию таким образом, чтобы при падении прямого линка между А и Б маршруты на хостах А и Б перенастраивались на промежуточный хост В.

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

★★★★★

Ответ на: комментарий от Spuddy

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

DRVTiny ★★★★★ ()

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

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

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

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

DRVTiny ★★★★★ ()

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

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

no-dashi ★★★★★ ()

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

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

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

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

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

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

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

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

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

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

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

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;
};
А можно и забить, оно не мешает.

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

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

Ага...

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

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

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

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

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

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

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

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

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

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

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

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

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

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

blind_oracle ★★★★★ ()

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

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

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

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

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

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

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
Также неочевидно, что за line vty, но это небось для подключения на консоль зебры что-то (тип терминала).

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

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

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

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

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

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

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

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

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

Вот такая вот печальная штука наблюдается...
Думаю, действительно может быть проблема в хождении мультикаст-пакетов. Например, в том, что они банально режутся фаерволлом...
[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]

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

Нет, ну одно дело «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

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

На 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'е...

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

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

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

Вот кстати - 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, но это не страшно: можно по факту посмотреть, блокируется ли мультикаст и если нужно - разрешить.
Боюсь только с уже существующей конфигурацией будет конфликтовать: все маршруты-то уже есть, а делать что-либо с ними не могу: кроме одного, все сервера работают у чёрта на куличиках, не дай Бог вообще потерять коннект.

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

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

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

interface eth0
!
interface eth1

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

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

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

Ну и тд.

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

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

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

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

ip ospf network point-to-point
и смени маску на /32 и, возможно, оно сразу и заработает :)

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

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

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

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

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

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

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

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

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

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

tazhate ★★★★★ ()
Ответ на: комментарий от blind_oracle
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...

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

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

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

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

blind_oracle ★★★★★ ()
Ответ на: комментарий от blind_oracle
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 без самой зебры. Но по-моему сама зебра ничего и не делает, это просто фронтэнд.

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

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

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

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

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

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

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

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

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

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

blind_oracle ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.