Subnets.ru

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

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?
Выделенный фиолетовым сегмент нам не пренадлежит и относительно не контролируеться.

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

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

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

Alex_K писал(а):через препенды, и инф в инете об этом очень много.

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

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

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

root писал(а):

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 красиво решил бы задачу

root писал(а):

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

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

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

root писал(а):

Alex_K писал(а):через препенды, и инф в инете об этом очень много.

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

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

root писал(а):

Alex_K писал(а):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 бордеров и в случаи отказа на аплинке траф "завернеться" быстрее? Или я что то не так понимаю?

Alex_K писал(а):а без костылей очень хотелось бы обойтись

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

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

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

Alex_K писал(а):100.1.1.0/24 должен ходить через INET 1, а 100.2.2.0/24 через INET 2

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

Alex_K писал(а):Оч жалею что /24 не "соседние"

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

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

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

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

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

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

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

root писал(а):

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, в зависимости от того, от какого соседа маршрут пришел?

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

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

Вникаю..

viewtopic.php?f=3&t=262

root писал(а):

budmo писал(а):И действительно ли это есть в Quagga ?

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

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

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


Alex_K писал(а):Возможна ли такая конструкция?

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

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

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

нет

root писал(а):

Alex_K писал(а):Возможна ли такая конструкция?

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

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

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