Jump to content

bird и приоритеты маршрутов по ospf

HighTower
 Share

Recommended Posts

HighTower

HighTower

Posted
Posted

Приветствую.

 

есть 4 сервера, на каждом своя подсеть и через каждый доступны некоторые ресурты (непересающиеся по адресам)

каждый из этих серверов соединён как минимум с админ другим по vpn (два из них серверы)

настроен bird, все маршруты разлетаются и видятся,

 

но есть одно НО, очень часто вижу ситуацию, когда два сервера соеденены по vpn, а маршрут на подсети за ними анонсируются через третий сервер... что приводит к ненужной нагрузке этого третьего сервера и зачастую к потере скорости, т.к. очень часть почему то анонсируется через сервер с самым узким каналом..

 

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

 

спасибо.

HighTower

HighTower

Posted
  • Author
Posted

если правильно понял из доков, cost на интерфейс можно повесить, а не на сеть.... а что если в export фильтре выставлять завышенных preferenct или ospf_metric1 для подсетей?

agr

agr

Posted
Posted

если правильно понял из доков, cost на интерфейс можно повесить, а не на сеть.... а что если в export фильтре выставлять завышенных preferenct или ospf_metric1 для подсетей?

 

OSPF - это Link state протокол. Более приоритетный маршрут выбирается исходя из стоимости линка, т.е. интерфейса.

srg555

srg555

Posted
Posted

но есть одно НО, очень часто вижу ситуацию, когда два сервера соеденены по vpn, а маршрут на подсети за ними анонсируются через третий сервер

 

А почему оно вообще так происходит? В этом надо разбираться

У вас может отношения соседства не устанавливаются между двумя серверами напрямую?

HighTower

HighTower

Posted
  • Author
Posted
А почему оно вообще так происходит? В этом надо разбираться

У вас может отношения соседства не устанавливаются между двумя серверами напрямую?

 

а мне вот тоже интересно...

вот упрощёная схема, в которой проявляется проблема

 

1) сервер 1

его адрес 172.16.10.1

он имеет экспортируемый статический маршрут на 10.150/18

он же vpn сервер

 

2) сервер 2

его адрес 10.0.0.1

vpn клиент сервера 1

он vpn сервер

 

3) сервер 3

его адрес 172.16.19.1

vpn клиент сервера 1

и vpn клиент сервера 2

 

проблему вижу на 2 сервере,почему то маршрут на 10.150/18 всё вреся ставится через сервер 3, хотя его проще и быстрее поставить напрямую через vpn туннель...

 

 

в конфиге прописать neighbors { set } ?

srg555

srg555

Posted
Posted

проблему вижу на 2 сервере,почему то маршрут на 10.150/18 всё вреся ставится через сервер 3, хотя его проще и быстрее поставить напрямую через vpn туннель...

 

 

в конфиге прописать neighbors { set } ?

 

Во-первых, не очень понятно, почему вы используете bird, а не quagga, как большинство. Да, у bird есть свои преимущества, но в вашей схеме они не нужны. За то по cisco-like интерфейсу quagga тут 95% форума могут советы давать.

 

Во-вторых, покажите состояние ospf-соседей (аналог команды sh ip ospf nei)

srg555

srg555

Posted
Posted

да скорее всего таблицы нейборов хватит, на 95% уверен, что проблема в том, что отношения соседства поверх vpn не устанавливаются(проблемы с хождением mcast/фаервол и т.п.)

HighTower

HighTower

Posted
  • Author
Posted

vitalyb

пробовал и ospf_metric1 = 65000; писать - эффект тот же

 

srg555

использую bird т.к. он крутится прекрасно на роутерах с альтернативными прошивками типа dd-wrt, а кваггу там запустить не удалось

 

вот вывод с 2 сервера

 

bird> show ospf neighbors
ospf1:
Router ID       Pri          State      DTime   Interface  Router IP
172.16.19.1       1         full/bdr    00:30   br0        10.0.0.19
192.168.0.1       1         full/dr     00:29   tap1       192.168.0.1
10.10.0.10        1         full/bdr    00:32   tap1       192.168.1.4
172.16.19.1       1         2way/other  00:30   tap1       192.168.1.9
10.10.0.10        1         full/dr     00:32   tap3       10.10.0.10

 

bird> show route
192.168.0.0/24     dev tap1 [direct1 Jun27] * (240)
                  dev tap1 [ospf1 Jul01] I (150/10) [192.168.0.1]
10.0.0.0/24        dev br0 [direct1 Jun21] * (240)
                  dev br0 [ospf1 Jul03] I (150/10) [10.0.0.10]
10.150.0.0/15      via 10.0.0.19 on br0 [ospf1 13:25] * I (150/2010) [172.16.19.1]
172.16.10.0/24     via 10.0.0.19 on br0 [ospf1 13:43] * I (150/20) [172.16.19.1]
10.10.0.0/24    dev tap3 [direct1 Jul01] * (240)
                  dev tap3 [ospf1 Jul03] I (150/10) [10.10.0.10]
172.16.19.0/24     via 10.0.0.19 on br0 [ospf1 13:25] * I (150/20) [172.16.19.1]

srg555

srg555

Posted
Posted

bird> show ospf neighbors

ospf1:

Router ID       Pri          State      DTime   Interface  Router IP

172.16.19.1       1         full/bdr    00:30   br0        10.0.0.19

192.168.0.1       1         full/dr     00:29   tap1       192.168.0.1

10.10.0.10        1         full/bdr    00:32   tap1       192.168.1.4

172.16.19.1       1         2way/other  00:30   tap1       192.168.1.9

10.10.0.10        1         full/dr     00:32   tap3       10.10.0.10

 

У меня случился разрыв шаблона %) У вас tap-ы объединены в бридж и ospf трафик ходит через бридж? Если так, то серверы не могут узнать откуда реально нейбор. Вообщем без схемы с обозначением тунелей вместе, бриджей, ip и конфигов bird вряд ли получится Вам помочь

 

Или, чтоб не разбираться в вашей сложной схеме есть второй вариант. Сделать логически полносвязную топологию без бриджей. Чтобы у каждого сервера был тунель до другого. Тогда ospf маршруты будут ходить по оптимальному пути(если специально не выставлять cost-ы)

HighTower

HighTower

Posted
  • Author
Posted
У меня случился разрыв шаблона %) У вас tap-ы объединены в бридж и ospf трафик ходит через бридж? Если так, то серверы не могут узнать откуда реально нейбор. Вообщем без схемы с обозначением тунелей вместе, бриджей, ip и конфигов bird вряд ли получится Вам помочь

 

Или, чтоб не разбираться в вашей сложной схеме есть второй вариант. Сделать логически полносвязную топологию без бриджей. Чтобы у каждого сервера был тунель до другого. Тогда ospf маршруты будут ходить по оптимальному пути(если специально не выставлять cost-ы)

 

есть tap0, который интерфейс от vpn сервера, он в бридже c br0, а tap[1-9] как клиента vpn сервера - он ни разу не в бридже....

 

почему сделано так - потому что к этим всем серверам мобильные клиенты по vpn подключаются и как то мне не хотелось для vpn делать отдельные подсети, поэтому в бридж и положил...

srg555

srg555

Posted
Posted

А как у вас произошло такое?

10.10.0.10 1 full/bdr 00:32 tap1 192.168.1.4

10.10.0.10 1 full/dr 00:32 tap3 10.10.0.10

 

почему один и тот же router-id виден с двух логических линков?

 

И почему произошло так?

172.16.19.1 1 2way/other 00:30 tap1 192.168.1.9

 

Вообщем рабочее решение есть - логически полносвязная сеть, на каждом логическом линке сеть /30. Тривиальное, заведомо рабочее решение. Разбираться в ваших наворотах без красивой схемы не реально.

agr

agr

Posted
Posted

1) сервер 1

его адрес 172.16.10.1

он имеет экспортируемый статический маршрут на 10.150/18

он же vpn сервер

вот вывод с 2 сервера

 

bird> show ospf neighbors

ospf1:

Router ID Pri State DTime Interface Router IP

172.16.19.1 1 full/bdr 00:30 br0 10.0.0.19

192.168.0.1 1 full/dr 00:29 tap1 192.168.0.1

10.10.0.10 1 full/bdr 00:32 tap1 192.168.1.4

172.16.19.1 1 2way/other 00:30 tap1 192.168.1.9

10.10.0.10 1 full/dr 00:32 tap3 10.10.0.10

 

проблему вижу на 2 сервере,почему то маршрут на 10.150/18 всё вреся ставится через сервер 3, хотя его проще и быстрее поставить напрямую через vpn туннель...

 

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

HighTower

HighTower

Posted
  • Author
Posted

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

 

о, действительно.. первый сервер в принципе недоступен (проблемы с каналом)... тогда вопрос, почему маршрут от него до сих пор живой и распространён? по идее б умереть должен.... (10.150)

HighTower

HighTower

Posted
  • Author
Posted

подсеть 10.150 реально есть только на первом...

в ядре третьего маршрута на него нет

но второй считает что ходить на неё нужно через третий (получает proto bird)

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
 Share
Go to topic listing
×
×
  • Create New...
На сайте используются файлы cookie и сервисы аналитики для корректной работы форума и улучшения качества обслуживания. Продолжая использовать сайт, вы соглашаетесь с использованием файлов cookie и с Политикой конфиденциальности.