Source-based routing & Quagga на FreeBSD

[Alex_K]

Здравствуйте
Жила была маленькая сетка, со своей АСкой, условно двумя блоками реальных ип и одним аплинком, предоставляла клиентам инет. Некоторое время назад появился второй аплинк, и поставили задачу

100.1.1.0/24 должен ходить через INET 1, а 100.2.2.0/24 через INET 2. Ну и в случаи падения одноги из INET, что бы всё работало через оставшийся.
Все роутеры и бордеры - компы с Quagga на FreeBSD.
Входящий траф, насколько я понял, полностью разделить не удасться, только частично через препенды, и инф в инете об этом очень много.

Вопрос возник по исходящему: как на Router 2 сделать, чтобы для трафа из сети 100.1.1.0/24 лутшим (но желательно не единственным) маршрутом по умолчанию (некст хопом?) был 3.0.0.2, а для трафа из сети 100.2.2.0/24 - 4.0.0.2?
Выделенный фиолетовым сегмент нам не пренадлежит и относительно не контролируеться.

[root]

Вопрос возник по исходящему: как на Router 2 сделать, чтобы для трафа из сети 100.1.1.0/24 лутшим (но желательно не единственным) маршрутом по умолчанию (некст хопом?) был 3.0.0.2, а для трафа из сети 100.2.2.0/24 - 4.0.0.2?

с помощью Policy Based Routing
PBR можно разрулить на PF или IPFW

Входящий траф, насколько я понял, полностью разделить не удасться, только частично через препенды

полностью это только если анонсить каждому прову, только один блок адресов.

через препенды, и инф в инете об этом очень много.

наш форум не исключение, тут эта тема уже много раз поднималась

100.1.1.0/24 должен ходить через INET 1, а 100.2.2.0/24 через INET 2. Ну и в случаи падения одноги из INET, что бы всё работало через оставшийся.

если ты на Router2 будешь направлять траф в соответствии с задачей с помощью PBR, то т.к. бордера у тя два и между ними есть линк тебе нуна поднять между ними iBGP сесиию, ну а дальше метриками разрулить маршруты приходящие от апстрима (eBGP) и от iBGP соседа. Получится что при падении канала на одном из Border он сразу же завернет трафик на другой бордер. Но что бы это работало, то оба блока адресов должны анонсится обоим апстримам.

[Alex_K]

Вопрос возник по исходящему: как на Router 2 сделать, чтобы для трафа из сети 100.1.1.0/24 лутшим (но желательно не единственным) маршрутом по умолчанию (некст хопом?) был 3.0.0.2, а для трафа из сети 100.2.2.0/24 - 4.0.0.2?

с помощью Policy Based Routing
PBR можно разрулить на PF или IPFW

М я читал про PBR через ipfw, а иначе чем жестко натить - можно сделать? Если я верно понимаю механизм, при разруливании пакетов натом в случаи падения прямой связи между Router 2 и одним из бордеров, ipfw не отработает эту ситуацию, понадобиться какой то "костыль", проверяющий доступность шлюза и переписывающий в случаи падения правила, а без костылей очень хотелось бы обойтись.

Могут в одной FIB FreeBSD существовать два дефолт роута с разными метриками? Если да. то setfib красиво решил бы задачу

Входящий траф, насколько я понял, полностью разделить не удасться, только частично через препенды

полностью это только если анонсить каждому прову, только один блок адресов.

Так и думал( Оч жалею что /24 не "соседние" - проанонсил бы обоим /23 и каждому по 1 /24 - была бы вообще сказка, верно?

через препенды, и инф в инете об этом очень много.

наш форум не исключение, тут эта тема уже много раз поднималась

Собстно настраивал BGP именно по вашей статье в основном, отличный ресурс и форум отличный особенно для тех, кто впервые сталкиваеться с какой то задачей. Спасибо огромное)

100.1.1.0/24 должен ходить через INET 1, а 100.2.2.0/24 через INET 2. Ну и в случаи падения одноги из INET, что бы всё работало через оставшийся.

если ты на Router2 будешь направлять траф в соответствии с задачей с помощью PBR, то т.к. бордера у тя два и между ними есть линк тебе нуна поднять между ними iBGP сесиию, ну а дальше метриками разрулить маршруты приходящие от апстрима (eBGP) и от iBGP соседа. Получится что при падении канала на одном из Border он сразу же завернет трафик на другой бордер. Но что бы это работало, то оба блока адресов должны анонсится обоим апстримам.

iBGP уже есть, разруливаю исход сейчас с помощью local preference.. а метриками будет лутше, потому что оба маршрута будут в FIB бордеров и в случаи отказа на аплинке траф "завернеться" быстрее? Или я что то не так понимаю?

[root]

а без костылей очень хотелось бы обойтись

ну ты тут уже выбирай или отказоустойчивость или 100% выполнение задачи
в текущей твоей ситуации лично я не могу тебе предложить иных решений от тех что написал выше

Могут в одной FIB FreeBSD существовать два дефолт роута с разными метриками?

а) это тебе не поможет решить задачу:

100.1.1.0/24 должен ходить через INET 1, а 100.2.2.0/24 через INET 2

т.к. пакеты от любой подсети будут уходить только на один GW
б) для этого ты можешь поднять между роутером и бордерами например OSPF и анонсить с бордюров default gateway с разными метриками

Оч жалею что /24 не "соседние"

попробуй вниктуть в описанное в статье BGP: Cisco 7206 и организация backup канала для клиента м.б. тебе это поможет.

проанонсил бы обоим /23 и каждому по 1 /24 - была бы вообще сказка, верно?

верно, при наличии iBGP между бордерами падение внешнего канала на одном из них не повлияло бы на инет для подсети /24 за ним, трафик пойдет через другой бордер т.к. он будет продолжать анонсировать в инет агрегированный /23 префикс.

отличный ресурс и форум отличный особенно для тех, кто впервые сталкиваеться с какой то задачей. Спасибо огромное)

спасибо за положительный отзыв о нашей работе и вам пожалуйста.
З.Ы. так же "спасиба" принимаются тут в виде напитка админов - пива

а метриками будет лутше, потому что оба маршрута будут в FIB бордеров и в случаи отказа на аплинке траф "завернеться" быстрее? Или я что то не так понимаю?

в таблице маршрутизации FreeBSD может быть только один активный маршрут. Это quagga его подменит в таблице маршрутизации в соответствии с метрикой, если активный маршрут по каким либо причинам (например падение интерфейса, прекращение анонсов) пропадет.

[Alex_K]

100.1.1.0/24 должен ходить через INET 1, а 100.2.2.0/24 через INET 2

т.к. пакеты от любой подсети будут уходить только на один GW
б) для этого ты можешь поднять между роутером и бордерами например OSPF и анонсить с бордюров default gateway с разными метриками

Думаю о такой конструкции:
ipfw setfib 0 ip from 100.1.1.0/24 to any out
ipfw setfib 1 ip from 100.2.2.0/24 to any out

При этом в FIB 0 дефолт 3.0.0.2 основной, а 4.0.0.2 запасной (с большей метрикой). В FIB 1 наоборот.

Возможна ли такая конструкция? И возможно ли принимать по OSPF маршрут в заданный FIB, в зависимости от того, от какого соседа маршрут пришел?

Если это возможно, то будет полностью динамическая сисетма..

попробуй вниктуть в описанное в статье BGP: Cisco 7206 и организация backup канала для клиента м.б. тебе это поможет.

Вникаю..

viewtopic.php?f=3&t=262

И действительно ли это есть в Quagga ?

если исходить из мануала по Quagga, то нет

Код: Выделить всё

border1-bgp(config-router)# neighbor 1.1.1.1 advertise-map
% There is no matched command.


[root]

Возможна ли такая конструкция?

без напильника нет. на просторах тырнета найдена статья: FreeBSD, несколько FIB'ов и динамическая маршрутизация с использованием BGP.
лично я бы такой конструкцией не пользовался, конструкция с PBR`ом и скриптом для меня в данном случае выглядит лучше, чем наложение подобных патчей, т.к. не ясно к каким последствиям в итоге это может привести.

VRF спас бы ситуацию, но quagga с ним не дружит.

И возможно ли принимать по OSPF маршрут в заданный FIB, в зависимости от того, от какого соседа маршрут пришел?

нет

[Alex_K]

Возможна ли такая конструкция?

без напильника нет. на просторах тырнета найдена статья: FreeBSD, несколько FIB'ов и динамическая маршрутизация с использованием BGP.
лично я бы такой конструкцией не пользовался, конструкция с PBR`ом и скриптом для меня в данном случае выглядит лучше, чем наложение подобных патчей, т.к. не ясно к каким последствиям в итоге это может привести.

Интересная статья, и задачку решить с её помощью можно красиво, но действительно надо хорошенько подумать, а лутше постестить на стенде, прежден чем применять - ведь приведёт это в лутшем случаи к необходимости эти патчи адаптироваnь к каждомоу серьёзному обновленияю quagga, да и kernel... думаю, для автора статьи это не представляется сложным, чего я не сказал на данном этапе о самом себе)

Проверил, kern/134931 полностью актуально во FreeBSD 8.2-RELEASE (