Категорії
FreeBSD Routers, GW, Internet

Несколько машрутов к одному источнику.

По умолчанию во FreeBSD можно использовать только 1 маршрут к одному и тому же источнику (в отличии от linux и Solaris этот функционал существует уже давно) Но Qing Li добавил , а Kip Macy дополнил такую поддержку и теперь можно не только задавать множество маршрутов к одному источнику, но и задавать “вес”, делать балансировку на уровне соединений.

Данная функциональность работает, начиная с версии 8.0

Что бы добавить такую возможность, нужно пересобрать ядро с опцией

options RADIX_MPATH

На данный момент существует баг (http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/173477) с невозможностью удаления некоторых маршрутов. Будьте внимательно.

После этого можно полноценно использовать множественные маршруты. Вот примеры использования:

– добавим несколько маршрутов:

#route add -net 192.103.54.0/24 10.10.10.44
add net 192.103.54.0: gateway 10.10.10.44
#route add -net 192.103.54.0/24 10.10.10.66
add net 192.103.54.0: gateway 10.10.10.66

– удаление только определённого машрута:

#route del 192.103.54.0/24 10.10.10.66
del net 192.103.54.0: gateway 10.10.10.66

– смотрим информацию о конкретном маршруте:

# route show 192.103.54.0/24 10.10.10.1
   route to: 192.103.54.0
destination: 192.103.54.0
       mask: 255.255.255.0
    gateway: 10.10.10.1
  interface: em0
      flags: <UP,GATEWAY,DONE,STATIC>
 recvpipe  sendpipe  ssthresh  rtt,msec    mtu        weight    expire
       0         0         0         0      1500        1         0

– меняем “вес” маршрута (чем меньше число, тем больше приоритет данного маршрута)

#route change -weight 10 192.103.54.0/24 10.10.10.1
#route show 192.103.54.0/24 10.10.10.1
   route to: 192.103.54.0
destination: 192.103.54.0
       mask: 255.255.255.0
    gateway: 10.10.10.1
  interface: em0
      flags: <UP,GATEWAY,DONE,STATIC>
 recvpipe  sendpipe  ssthresh  rtt,msec    mtu        weight    expire
       0         0         0         0      1500        10         0

– добавляем балансировку (задаём шлюзы 10.10.10.1 и 10.10.10.88 для балансировки соединений, при этом можно регулировать балансировку с помощью параметра weight, значения которого будут обратно пропорциональными к распределению трафика):

freebsd9# route change -sticky 192.103.54.0/24 10.10.10.1
change net 192.103.54.0: gateway 10.10.10.1
freebsd9# route change -sticky 192.103.54.0/24 10.10.10.88
change net 192.103.54.0: gateway 10.10.10.88
freebsd9# route show 192.103.54.0/24 10.10.10.1
   route to: 192.103.54.0
destination: 192.103.54.0
       mask: 255.255.255.0
    gateway: 10.10.10.1
  interface: em0
      flags: <UP,GATEWAY,DONE,STATIC,STICKY>
 recvpipe  sendpipe  ssthresh  rtt,msec    mtu        weight    expire
       0         0         0         0      1500        10         0
freebsd9# route show 192.103.54.0/24 10.10.10.88
   route to: 192.103.54.0
destination: 192.103.54.0
       mask: 255.255.255.0
    gateway: 10.10.10.88
  interface: em0
      flags: <UP,GATEWAY,DONE,STATIC,STICKY>
 recvpipe  sendpipe  ssthresh  rtt,msec    mtu        weight    expire
       0         0         0         0      1500         1         0

в данном примере трафик поделиться в соотношении 1:10. Убрать балансировку можно с помощью параметра nostick

FIB

Пару слов хочется сказать о FIB – множественные таблицы маршрутизации. Это возможность позволяет для разных приложений использовать свои таблицы маршрутизации. Например. Для почты используется один маршрут, для VPN – совсем другой.

Для включения этой возможности нужно пересобрать ядро с опцией

options ROUTETABLES=N

где N число таблиц маршрутизации. Максимальное значение N=15 (начиная с 10-ой версии доступно 65536 таблиц маршрутизации) Итого, максимально получаем 16 возможных (нулевая – это обычная таблица).

Для работы с разными таблицами используется команда setfib. Данный функционал доступен, начиная с версии 7.0

Что бы иметь возможность указывать fib для конкретного демона, например, так:

apache22_enable="YES"
apache22_fib="1"

используем патч отсюда

9 коментарів “Несколько машрутов к одному источнику.”

Как хорошо что есть люди, которым проще изобрести велосипед чем освоить протоколы RIP EIGRP OSPF BGP – хотя б один из них…

Как хорошо, что есть люди, которые думают, что АБСОЛЮТНО ВСЕ провайдеры могут предоставить хотя бы один из них.
Да, и если разобрать предложенные вами протоколы, то имеем следующее:
– OSPF – вообще не подходит
– RIP – устаревший и мало кто использует
– EIGRP – не на любом оборудовании можно завести, особенно не на железных роутерах (например, *nix)
– BGP – для него нужно иметь AS+PI и для небольшой организации получить это очень проблематично, учитывая, что IPv4 уже не раздают, а IPv6 сейчас мало где реально поддерживается, особенно у нас.
Так, что вы не правы.

Якщо у вас більше одного каналу і на одному із них, наприклад BGP чи OSPF, і т.д. недоступне, тоді саме ця стаття й допоможе задіяти усі канали, отже “skeletor” – правий на усі 100%.
А “DNK” забув, що динамічна маршрутизація без neighbor працювати не буде!

Бред какой-то, честное слово.
Сначала вы добавляете
#route add -net 192.103.54.0/24 10.10.10.44
а потом ниже
# route change -sticky 192.103.54.0/24 10.10.10.1

Ну и откуда 10.10.10.44 взялось? Зачем добавлять, а потом изменять со stiсky?
Следуя вашей инструкции, никакого эффекта нет, трафик так и дальше идет через шлюз из последней команды.
Да, ядро пересобрано, толку 0. Баланса нет.
И опять же, вы пишите о EQUAL COST, а сами тыкаете weight 10:1 и в чем суть статьи? Мне нужно что бы трафик рандомно распределялся через оба шлюза, то есть выставить одинаковый weight, но как я уже сказал, никакого эффекта нет.

Бред – это ваш комментарий. В статье рассмотрены возможности мультироутинга с примерами, а не то, как вам распределять трафик между вашими серверами. Не вырывайте фразы из контекста и не делайте из них последовательность действий, а лучше прочтите ещё раз, если не поняли с первого раза суть статьи.

Я все прекрасно понял:
1) FreeBSD оказывается полным УГ, где по сравнению с Linux уже сто лет как можно достичь ECMP одной командой “add default scope global nexthop via x.x.x.x dev eth0 weight 1 nexthop via y.y.y.y dev eth2 weight 1”

Да, ECMP здесь ни при чём. Имелся ввиду мультироутинг. Статью поправил.

Залишити коментар до skeletor Скасувати коментар

Ваша e-mail адреса не оприлюднюватиметься. Обов’язкові поля позначені *

Домашняя страничка Andy
Записки молодого админа
Самостоятельная подготовка к Cisco CCNA
Самостоятельная подготовка к Cisco CCNP
Powered by Muff