Динамическая маршрутизация bird + setfib + FreeBSD.

18th Ноябрь 2010 | Метки: , , , , , , ,
Опубликовал: Andrey [rtty] Shidakov

Представляю вашему вниманию патч для bird, который позволяет корректно работать с фибами.
Cкачиваем  исходник. Версия от 27.02.2011

ChangeLog:
1. фибы переведены в глобальный протокол кернел
2. птичка больше не гадит (вылет по sigfault при завершении работы)

 

 
Далее как обычно:

./configure --prefix=/usr/local --mandir=/usr/local/man \
 --infodir=/usr/local/info/ --with-protocols="ospf bgp static pipe rip"
make && make install

За патч спасибо Дмитрию Калинину.

Пример конфигурационного файла bird.conf:

log syslog { debug, trace, info, remote, warning, error, auth, fatal, bug };
log stderr all;
 
# Устанавливаем router ID (уникальный для каждого роутера)
router id 0.0.0.20;
 
# Задаем другие таблицы маршрутизации
table fib0;
table fib2;
table fib3;
table fib5;
table fib6;
table fib7;
 
# reject rfc1918 filter
filter rfc1918_reject  {
   if net ~ [ 10.0.0.0/8+, 172.16.0.0/12+, 192.168.0.0/16+ ] then reject;
   else accept;
}
 
# Turn on global debugging of all protocols
debug protocols all;
 
# Протокол kernel - нужен для того, чтобы привязать таблицы птички к системным таблицам.
protocol kernel {
   table fib0;
   scan time 20;
   import none;
   export all;
   kernel table 0;
}
 
protocol kernel {
   table fib2;
   scan time 20;
   import none;
   export all;
   kernel table 2;
}
 
protocol kernel {
   table fib3;
   scan time 20;
   import none;
   export all;
   kernel table 3;
}
 
protocol kernel {
   table fib5;
   scan time 20;
   import none;
   export all;
   kernel table 5;
}
 
protocol kernel {
   table fib6;
   scan time 20;
   import none;
   export all;
   kernel table 6;
}
 
protocol kernel {
   table fib7;
   scan time 20;
   import none;
   export all;
   kernel table 7;
}
 
# Протокол static - статическая маршрутизация
protocol static {
   table fib0;
   /* MKS */
   route 10.68.0.0/14 via 91.211.29.30;
   route  91.211.28.0/22 via 91.211.29.30;
   /* Lanta */
   route 83.234.112.0/24 via 93.186.105.89;
   route 193.203.60.0/22 via 93.186.105.89;
   route 93.186.96.0/20 via 93.186.105.89;
   route 172.16 .0.0/12 via 93.186.105.89;
   route 10.0.0.0/8 via 93.186.105.89;
   /* Tstu */
   route  195.19.96.0/19 via "ng0";
   route 82.179.144.0/20 via "ng0";
   /* Domolink */
   route 78.132.128.0/17 via "ng0";
   route 213.135.128.0/19 via "ng0";
}
 
protocol static {
   table fib2;
   route 0.0.0.0/0 via 91.211.29.30;
   route 83.166.48.34/32 via "ng0";
}
 
protocol static {
   table fib3;
   route 0.0.0.0/0 via 172.27.0.9;
}
 
protocol static {
   table fib5;
   route 0.0.0.0/0 via 192.168.10.2;
}
 
protocol static {
   table fib6;
   route 0.0.0.0/0 via 192.168.135.14;
}
 
protocol static {
   table fib7;
   route 0.0.0.0/0 via 93.186.105.89;
}
 
# Протокол pipe - перелив маршрутов из таблицы peer table в таблицу table
protocol pipe {
   table fib2;
   peer table fib0;
   export none;
   import all;
}
 
protocol pipe {
   table fib5;
   peer table fib0;
   export none;
   import all;
}
 
protocol pipe {
   table fib7;
   peer table fib0;
   export none;
   import all;
}
# Псевдо-протокол, следящий за всеми интерфейсами (событиями up/down)
# This pseudo-protocol watches all interface up/down events.
protocol device {
       scan time 10;           # Сканировать интерфейсы каждые 10 секунд
}
 
# Протокол OSPF
protocol ospf {
   table fib0;
   rfc1583compat yes;
   area 0.0.0.0 {
       interface "gif1" {
            authentication cryptographic;
            password "pass";
       };
       interface "gif2" {
            authentication cryptographic;
            password "pass";
       };
   };
 
   area 0.0.0.1 {
       interface "gif0" {
            authentication cryptographic;
            password "pass";
       };
   };
 
   export filter rfc1918_reject;
   import filter rfc1918_reject;
}

Стартовый скрипт /usr/local/etc/rc.d/bird:

#!/bin/sh
#
# PROVIDE: bird
# REQUIRE: LOGIN
# KEYWORD: shutdown
#
# Add the following lines to /etc/rc.conf.local or /etc/rc.conf
# to enable this service:
#
# bird_enable (bool):   Set to NO by default.
#               Set it to YES to enable bird.
# bird_config (path):   Set to /usr/local/etc/bird.conf
#               by default.
#
 
. /etc/rc.subr
 
name="bird"
rcvar=${name}_enable
command=/usr/local/sbin/${name}
 
load_rc_config $name
 
: ${bird_enable="NO"}
: ${bird_config="/usr/local/etc/bird.conf"}
 
command_args="-c $bird_config"
 
run_rc_command "$1"
  1. 11th Январь 2011 в 20:20

    Чуток переписал патч. Что изменено:
    — сокет закрепляется за нужным фибом без переключения контекста процесса (setsockopt вместо setfib).
    — при сканировании маршрутов — фибы переключаются при необходимости. т.е. если фиб по-умолчания «1» и сканируемый тоже «1», то переключения не будет.
    — в сканировании маршрутов добавлена проверка на протокол «device». для этого протокола фиб не переключается
    — добавление оформление ifdef-ами для фибов

    В планах — перевести чтение маршрутов с sysctl на чтение kmem, что избавит от переключения фиба процесса и позволит в плотную приблизится к реализации ECMP (equal cast multi-path) routing.

  2. 11th Январь 2011 в 20:23

    Спасибо!

  3. parta
    20th Январь 2011 в 08:52

    2Dmitriy Kalinin:

    все отлично и замечательно, но есть проблема PR Kern/134931. есть валидный патч для 7.Х, но для 8.Х не особо. как быть ? :)

  4. 20th Январь 2011 в 09:13

    2parta:

    отличное замечание :) bird использует два механизма опроса текущих маршрутов системы:
    1) сканирование того, что есть (через sysctl);
    2) прослушивания routing socket.

    п.2 проявит себя — когда будет использоваться импорт маршрутов из системы (protocol kernel {… import !none }. Ситуация возможна, когда при добавление в один фиб, сокет поймает этот маршрут в другом фибе.

    Надо, кстати, смоделировать такую ситуацию, о результатах отпишусь чуть позже.

  5. parta
    11th Февраль 2011 в 07:43

    2Dimtriy Kalinin:

    пробую сейчас 8-stable с огрызками патчей из PR, вроде даже работает «как надо». правда не совсем уверен что «не работает» теперь и чем оно аукнется в продуктиве, да и обновы будут запиливать мои костыли. Ж) не смотрели ли вы на завязку bird вокруг vimage ? правда с vimage всё еще печальнее: оно виртуализация целиком стэка, а нам надо то просто несколько таблиц маршрутизации с возможностью делать между ними рут ликинг, вобщем мне кажется vimage супер для жайлов, но совсем не то что нужно для маршрутизаторов. :( с fib’ами то позиция жулиана примерна «они не для этого, ждите вимаж, жрите что дают», хотя вроде планы с переделками для «нормальных» fib’ов + поддержки ifconfig’ом добавлять интерфейс в нужный fib существуют, но когда это будет сделано и будет ли — вопрос.

    насчет патчей для bird с поддержкой fib’ов, энивей, дело то полезное и нужное. может быть стоит замылить их мантайнеру порта птыца ?

  6. dk
    12th Февраль 2011 в 18:08

    parta :2Dimtriy Kalinin:
    пробую сейчас 8-stable с огрызками патчей из PR, вроде даже работает «как надо». правда не совсем уверен что «не работает» теперь и чем оно аукнется в продуктиве, да и обновы будут запиливать мои костыли. Ж) не смотрели ли вы на завязку bird вокруг vimage ? правда с vimage всё еще печальнее: оно виртуализация целиком стэка, а нам надо то просто несколько таблиц маршрутизации с возможностью делать между ними рут ликинг, вобщем мне кажется vimage супер для жайлов, но совсем не то что нужно для маршрутизаторов. :( с fib’ами то позиция жулиана примерна «они не для этого, ждите вимаж, жрите что дают», хотя вроде планы с переделками для «нормальных» fib’ов + поддержки ifconfig’ом добавлять интерфейс в нужный fib существуют, но когда это будет сделано и будет ли – вопрос.
    насчет патчей для bird с поддержкой fib’ов, энивей, дело то полезное и нужное. может быть стоит замылить их мантайнеру порта птыца ?

    В общем попытался смоделировать ситуацию, когда маршрут летит не с того фиба … Отрабатывает как положено :) import none на протоколе kernel, результат просто игнорируется. Похоже, пока единственное решение — ждать когда/если сделают идентификацию маршрутов в роутинг сокетах. На текущий момент, увы, только отсекать импорт из кернела.
    Как вариант — откидывать все маршруты с роутинг сокета, сканированием они определятся правильно.

    с vimage все ужасно, совместно с pf — 100% kernel panic, ipfw — 50% kernel panic, без fw — как-то работает, но точно не для этих целей он.

    мейнтейнеру два раза отсылал патчи, оба раза игнорирование :(

    ps: net.add_addr_allfibs=0 — вроде только в активный фиб линк-маршруты пишет.

  7. dk
    14th Февраль 2011 в 12:29

    Чуток подправил …
    Было — при реконфигурации (birdc configure) ресурсы закрепленные за пулом освобождались. В эти ресурсы входил и роутинг сокет, в результате чего птыц не мог синхронизировать маршруты с ядром.
    Сейчас, при реконфигурации сокет пересоздается.

  8. 27th Февраль 2011 в 11:47

    Update:
    Версия от 27.02.2011 скачать

    ChangeLog:
    1. фибы переведены в глобальный протокол кернел
    2. птичка больше не гадит (вылет по sigfault при завершении работы)

  9. Rhamzin
    12th Март 2011 в 07:53

    Впервые столкнулся с BIRD. Подскажите, что может означать данная строка в логах BIRD:
    bird: KRT: Error sending route 0.0.0.0/0 to kernel

    Bird стоит на NAS VPN сервере.

    в конфиге такое:
    protocol kernel {
    # learn; # Learn all alien routes from the kernel
    persist; # Don’t remove routes on bird shutdown
    scan time 20; # Scan kernel routing table every 20 seconds
    # import none; # Default is import all
    export filter rfc1918_reject; # Default is export none
    # kernel table 5; # Kernel table to synchronize with (default: main)
    }

  10. 12th Март 2011 в 16:54

    Rhamzin, скорее всего в кернеле есть такой маршрут уже.

  11. Rhamzin
    29th Март 2011 в 07:15

    Да, вы правы. Подкорректировал фильтр и все нормально стало.
    Однако вопрос встал в отношении стабильности работы BIRD на FreeBSD 7.4. Процесс bird вылетает из памяти, прекращая всякую дин. маршрутизацию. Пришлось написать внешний скрипт, который бы отслеживал жив/мертв процесса и восстанавливал его. Bird используется для трансляции по OSPF реальных IP на VPN сервера. Можете сообщить, куда копать?
    Логи ничего конкретного не показывают, кроме как сообщения о проблеме сокета.
    Вот пример логов по падению:
    24.03.2011-20.25.45 : Падение BIRD
    25.03.2011-16.38.04 : Падение BIRD
    25.03.2011-21.02.44 : Падение BIRD
    25.03.2011-22.25.25 : Падение BIRD
    26.03.2011-21.13.18 : Падение BIRD
    27.03.2011-09.13.27 : Падение BIRD
    27.03.2011-16.09.27 : Падение BIRD
    27.03.2011-17.57.47 : Падение BIRD
    27.03.2011-19.31.47 : Падение BIRD

  12. dk
    31st Март 2011 в 19:33

    Ну в общем нужны логи + .core (если есть), было вываливание — когда реконфигурация протокола идет, но это исправил уже.

  13. 31st Март 2011 в 19:37

    Выложим новую версию чуток попожее.

  14. dk
    31st Март 2011 в 19:38

    Version 1.3.0 (2011-03-31)
    o Proper iBGP (can be used with IGP).
    o Multipath support (OSPF and static).
    o L2 link state detection.
    o IPv6 router advertisements.
    o Much improved OSPF reconfiguration.
    o Point-to-MultiPoint interfaces (OSPF).
    o Minor changes and improvements in config file grammar.
    o Better community list matching
    o Changes default behavior of BGP IPv6 socket to v6only.
    Use ‘listen bgp dual’ for the old behavior.
    o Changes default for handling missing link-local addresses on
    route servers. Use ‘missing lladdr drop’ for the old behavior.
    o Important bugfix for OSPF.
    o Several minor bugfixes.

  15. Rhamzin
    20th Апрель 2011 в 09:32

    Как можно взять консультацию у разработчиков BIRD?

    Интересует вопрос:
    1. Что означает данная запись:
    protocol static {
    preference 1500; # Кол-во обрабатываемых маршрутов??????
    route 0.0.0.0/0 via 195.18.23.1; # Маршрут для новых интерфейсов или для вещания маршрута по умолчанию всем ospf соседям?

    2. tick 2 — что это? Для чего его придумали?
    3. Что за обучение в команде learn?
    Команда persist за что отвечает?

    Пожалуйста, ответьте!

  16. 20th Апрель 2011 в 11:41

    mail-list — http://bird.network.cz/?m_list, вроде обсуждения живые, разработчики отвечают

    preference — это административное расстояние. вкратце — может быть несколько протоколов маршрутизации (static, bgp, ospf …). внутри каждого протокола есть понятие метрика маршрута — т.е. приоритет этого маршрута. Причем для разных протоколов маршрутизации метрики свои.

    Для статического маршрута допустим метрика = 100, а по BGP маршрут имеет метрику — 1000. Какой из этих маршрутов более оптимальный на основании метрики сказать нельзя. Для этого существует понятие административное расстояние (http://img.nag.ru/projects/setup/c4b/00f8c2aecc071b49475c2483c47d0212.pdf), которое образно говорит — что этого протокола маршруты более предпочтительны.

    route 0.0.0.0/0 via 195.18.23.1 — говорит что шлюз по умолчанию будет 195.18…. Пока этот маршрут нигде не участвует. Касательно bird — чтоб маршрут ушел в таблицу маршрутизации ОС — его нужно разрешить экспортировать в протоколе kernel.
    Чтоб его разрешить передавать на соседей по ospf — соответственно разрешить в протоколе ospf.

    В общем, п.1 вопрос — это статический маршрут, с адм. расстоянием 1500 указывающий, что шлюз по умолчанию — 195.18.23.1

    п.2 — когда меняется состояние линка в ospf — происходит пересчет таблицы маршрутизации. tick 2 — указывает, что после изменения состояния линка нужна подождать две секунды и запустить пересчет таблицы.

    п.3 — разрешить получать маршруты из таблицы маршрутизации системы

    persist. после завершения работы bird удаляем из таблицы все маршруты порожденные собой. persist — запрещает удалять их.

  17. 20th Апрель 2011 в 20:39

    Спасибо за пояснения! Некоторые вещи стали более понятны!
    Написал в группу обсуждения (User Maling List) некоторые свои проблемы с BIRD.
    Но там англичане, думаю, а понимаю их язык не очень. Ваши пояснения более для меня более понятны. Пожалуйста, помогите Dmitriy Kalinin!

    Суть проблемы такова! Имеется N-кол-во НАС серверов с поднятым VPN с PPTP/L2TP, цель которых маршрутизировать две подсети реальников на 3000 адресов.

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

    Пример конфига:
    router id 10.230.0.8;
    filter rfc1918_reject {
    if net ~ [ 0.0.0.0/0, 10.0.0.0/8+, 172.16.0.0/16+, 192.168.1.0/24+ ] then reject;
    else accept;
    }
    protocol direct {
    interface «ng*»; # Restrict network interfaces it works with
    }
    protocol kernel {
    scan time 20; # Scan kernel routing table every 20 seconds
    import filter rfc1918_reject;
    export filter rfc1918_reject; # Default is export none
    }
    protocol device {
    scan time 10; # Scan interfaces every 10 seconds
    }
    protocol static {
    preference 1000; # Default preference of routes
    }
    protocol ospf myospfd {
    rfc1583compat yes;
    export filter rfc1918_reject;
    import filter rfc1918_reject;
    area 0.0.0.0 {
    networks {
    191.118.20.0/22;
    148.131.123.0/21;
    };
    interface «igb1» {
    retransmit 5;
    cost 10;
    priority 1;
    };

    };

    };

    Сети примерные для наглядности.
    Вопрос:
    1. Правильно ли все сконфигурировано?
    2. При подключении интернета связь появляется только через 10 сек. Где это лечится до 2 сек.?
    3. При перезагрузки BIRD в таблице маршрутизации все три интерфейса переключаются на внешний.Например, для локального интерфейса (em2) ставится (igb1)
    Было так, до перезагрузки
    192.168.1.0/24 link#4 UC 0 0 em1
    Становится так……..
    192.168.1.0/24 link#2 UC 0 0 igb1

    4. Как в Bird указать, чтобы вещать другим (соседям) маршрут по умолчанию, типа как в quagga «default-information originate»?

  18. 20th Апрель 2011 в 20:50

    5. Как в BIRD прописать с соседом в режиме точка-точка, т.е. чтобы обменивались маршрутом только конкретные роутеры?

  19. 20th Апрель 2011 в 20:53

    Rhamzin :5. Как в BIRD прописать с соседом в режиме точка-точка, т.е. чтобы обменивались маршрутом только конкретные роутеры?

    т.е. Есть один пограничный роутер с поднятым BGP с одной (внешней) стороны и OSPF (для внутренних роутеров). Роутер в режиме VPN сервера с анонсированием реальных IP. VPN сервером N штук. Как сконфигурировать BIRD так, чтобы все VPN общались только с пограничным роутером?

  20. 20th Апрель 2011 в 21:44

    К сожалению ни visio ни dia под рукой нет, топология такая (http://opentmb.ru/media/image/2113ccf9f6bbf6ffb4f707870bf22ca5_15.png)?

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

    по пункту 2 — при подключении интернета где? у клиента или на пограничном? или после установления соседства внутренний-пограничный?

    protocol kernel {
    scan time 20; # Scan kernel routing table every 20 seconds
    import filter rfc1918_reject;
    export filter rfc1918_reject; # Default is export none
    }
    scan time 20 — говорит, что внутренняя таблицы маршрутазации bird будет синхронизироваться с таблицей ОС каждые 20 секунд. т.е. время разсинхронизации не превысит максимум 20 секунд, но динамические маршруты сбрасываются в ОС моментально, по факту появления. Просто каждые 20 секунд проверяется соотв. маршрутов.
    Например: приехал динамический маршрут 0.0.0.0/0 на пограничный маршрутизатор. Маршрут вписался в ядро ОС. По каким-то непонятным причин админ (возможно пятница, возможно много пива) решил этот маршрут удалить в ручную (route delete 0.0.0.0/0 …). Не позднее чем 20 секунд bird обнаружит эту проблему и впишет его заново.

    дальнейшие предположения: пограничный и внутренние лежат в одном сегменте в одной подсети. при таком раскладе они действительно будут пытаться связаться каждый с каждым. чтоб это избежать есть несколько способов:
    1. зарезать на фаерволе трафик с ненужных соседей
    2. жестко объявить в bird соседей
    3. извращения с фильтрами
    4. побить оспф на зону

    на п.1 останавливаться не буду, сразу к п.2.
    — ставим небродкаст тип линка на врутренних маршрутизаторах type nbma;
    — отрубаем отсылка HELLO всем неизвстным дружбанам — strict nonbroadcast on;
    — объявляем своих корешей с помощью neigbors (в Вашем случае — это будет один штук, пограничный роутер).
    protocols ospf {

    interface «igb1» {

    type nbma;
    strict nonbroadcast on;
    nieghbors { ; };
    };

    теперь по п.3. фильтрами можно запретить брать маршрут от того, кто не нужен (все, кроме пограничного). получится картина — что все роутеры будут в одной куче, но маршруты будут браться только с пограничного. но тут есть одна проблема — в отличии от бгп — оспф — протокол состояния линии. а при установленном отношении с соседом, пусть и ни принимая от него маршрутов — линк считается существующим. как при этом поведет себя расчет таблицы маршрутизации — не берусь ответить. скорей всего повернется на ближайшего соседа, в обход в пограничного. с помощью фильтров порезать маршруты с нежелательных соседей можно так:
    export filter {
    if ospf_router_id = ROUTER_ID_СОСЕДА then reject;
    accept;
    };
    import filter {
    if ospf_router_id = ROUTER_ID_СОСЕДА then reject;
    accept;
    };
    эти два фильтра запретят прием/передачу маршрутов определенному соседу.

    ну и п.4
    кажду пару внутренний-пограничный выделить в отдельную оспф зону.

    @При перезагрузки BIRD в таблице маршрутизации все три интерфейса переключаются на внешний.Например, для локального интерфейса (em2) ставится (igb1)@
    Очень осторожно относитесь к фильтрам, которые используете при импорте/экспорте из ядра. они с легкостью могут переписать коннектед адрес сетевых. например, не надо из ядра ничего импортировать в bird:
    protocol kernel {

    import none;
    };
    ну и разумеется не надо экспортировать в ядро свои локальные маршруты, которые могут приехать по оспф:
    protocol kernel {
    export filter my_kern_filter;
    };
    и в my_kern_filter описать свои локальные адреса.

    @ Как в Bird указать, чтобы вещать другим (соседям) маршрут по умолчанию, типа как в quagga «default-information originate»?@
    бирд вещает все маршруты, которые не порезали фильтры. в вашем примере rfc1918_reject срезает кроме локальных подсеток еще и 0.0.0.0/0. в отличии от кваги — бёрд имеет очень функциональные средства по фильтрации маршрутов.

    ps:
    рекомендую постоянно синхронизировать кодовую базу bird с офиц. репозиторием git://git.nic.cz/bird.git
    git clone git://git.nic.cz/bird.git bird
    переодически там фиксят косяки

  21. Rhamzin
    21st Апрель 2011 в 07:16

    2. При подключении интернета связь появляется только через 10 сек. Где это лечится до 2 сек.?
    Клиент подключается к VPN серверу и у него появляется интернет только через 10 сек. Я думал, что достаточно поменять время вещания HELLO пакетов, но оказалось, что это не так.

  22. Rhamzin
    21st Апрель 2011 в 07:37

    Схема которую вы привели в точности соответствует задаче. Все роутеры подключены непосредственно к пограничному маршрутизатору!

  23. 21st Апрель 2011 в 08:24

    я правильно понял — что при подключении клиенту выдается ип из пула адресов. и этот ип берется на маршрутизацию через 10 секунд. т.е. до пограничного маршрутизатора — этот адрес анонсируется 10 секунд.

    protocol device {
    scan time 10; # Scan interfaces every 10 seconds
    }
    проверять интерфейсы раз в 10 секунд. здесь происходит проверка ип клиентов.

    а не проще-ли, привязать подсеть клиентов за роутером?

  24. Rhamzin
    21st Апрель 2011 в 11:30

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

    Вопрос: BIRD не имеет мониторинга по SNMP как это сделано в Quagga?

  25. 21st Апрель 2011 в 11:44

    снмп к сожалению нет :(

    по поводу 10 секунд — это влияет протокол device, выше писал.

    но.
    2010-11-11 10:03 Implements link state detection.
    Also changes some symbol names (IFF_ADMIN_DOWN -> IFF_SHUTDOWN,
    IFF_LINK_UP -> IFF_ADMIN_UP).

    попробуйте с репозитория последнею версию bird, для bsd вроде сделали определение линка. сам не проверял. пока как вариант уменьшить значение scan time.

    еще можно попробывать вариант — разрешить импорт из ядра ип-адресов клиентов, должно моментально при поднятии линка срабатывать.

  26. 21st Апрель 2011 в 14:55

    Цитата: разрешить импорт из ядра ип-адресов клиентов, должно моментально при поднятии линка срабатывать.

    А как это сделать? Вы же писали что нужно в kernel прописать import none?

  27. dk
    21st Апрель 2011 в 15:33

    ну это как-раз тот осторожный случай :)

    допустим, клиентам выдаются адреса из подсетки 5.5.5.5/23

    рисуем фильтр, на эти адреса:

    filter imp_kernel {
    if net ~ [ 5.5.5.5/23+ ] then accept;
    reject;
    }

    т.е., если подсеть(адрес) принадлежит 5.5.5.5/23 — то разрешаем, иначе запрещаем

    и прикручиваем его к кернелу
    protocol kernel {

    import filter imp_kernel;
    }

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

    пс: на практике такое не проверял, но в теории сработать должно

  28. 21st Апрель 2011 в 20:28

    Огромное спасибо за позновательное общение….. многое уже применил…. по последнему посту отпишусь завтра как внедрю на тесте…

  29. 21st Апрель 2011 в 21:53

    Да не зачто :)

Вы должны авторизоваться для отправки комментария.