The OpenNET Project / Index page

[ новости/++ | форум | wiki | теги | ]

Распределение трафика между двумя каналами во FreeBSD
Во FreeBSD 7 появилась возможность задания множественных таблиц маршрутизаций.
В ядре отвечает за это опция:

    options ROUTETABLES=[количество таблиц]

Распределения трафика будет осуществляться средствами пакетного фильтра ipfw.

Задаем маршруты по умолчанию:

    setfib 0 route add default 1.0.1.1 # таблица по умолчанию
    setfib 1 route add default 1.1.1.1 # новая таблица

Файл конфигурации для запуска ipfw:

    cmd="/sbin/ipfw"
    $cmd add 10 check-state
    $cmd add 20 prob 0.5 setfib 0 tcp from 192.168.0.0/16 to not 192.168.0.0/16 setup keep-state
    $cmd add 30 setfib 1 tcp from 192.168.0.0/16 to not 192.168.0.0/16 setup keep-state
    $cmd add 40 allow all from any to any

Таким образом мы задаем распределение трафика 50/50. Если каналы не равноценные
то нужно выставить процентную весомость этих каналов.

Трансляция адресов (NAT).

Под эту задачу я выбрал ipnat, реализацию NAT от фаервола ipf.

пример /etc/ipnat.rules:

    map vlan0 192.168.0.0/16 -> 1.0.1.1/32
    map tun0 192.168.0.0/16 -> 1.1.1.1/32

Также можно выбрать демон natd или новый, работающий на уровне ядра, NAT,
который появился во FreeBSD 7.
 
18.08.2009 , Автор: pehlle , Источник: http://bsd.ucd.uz/raspredelenie-tra...
Ключи: nat, ipfw, balance, bandwidth, limit, traffic, freebsd / Лицензия: CC-BY
Раздел:    Корень / Администратору / Сетевая подсистема, маршрутизация / Пакетные фильтры и фаерволы / Пакетный фильтр в FreeBSD: ipfw, IP-Filter

Обсуждение [ Линейный режим | Показать все | RSS ]
 
  • 1.1, john doe (?), 14:05, 18/08/2009 [ответить] [показать ветку] [···]    [к модератору]
  • +/
    А то-же самое, но для pf -- реализуемо?

     
     
  • 2.2, mr_gfd (?), 14:19, 18/08/2009 [^] [ответить]    [к модератору]
  • +/
    http://unix.derkeiler.com/Mailing-Lists/FreeBSD/net/2009-01/msg00119.html

    Рекомендуют все-же ipfw для этих целей.

     
     
  • 3.10, nanodaemon (ok), 04:07, 19/08/2009 [^] [ответить]    [к модератору]
  • +/
    по каким же причинам рекомендуют ? pf в *BSD умел балансировать задолго до того как прикрутили мультипл роут тейблс во фрибсд. да и при помощи ipfw можно сделать по-человечески, я думаю, не прибегая ко мультипл роут тейблс. предназначение мультипл роут тейблс иное чем балансинг каналов.

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

     
  • 2.9, iZEN (ok), 00:14, 19/08/2009 [^] [ответить]     [к модератору]
  • +/
    Насчёт балансировки трафика между двумя каналами есть статья в журнале Системны... весь текст скрыт [показать]
     
  • 1.3, pehlle (?), 14:48, 18/08/2009 [ответить] [показать ветку] [···]    [к модератору]  
  • +/
    там ошибка в скрипте, не $cmd="/sbin/ipfw",
    а cmd="/sbin/ipfw"
     
  • 1.4, shutdown now (?), 14:52, 18/08/2009 [ответить] [показать ветку] [···]    [к модератору]  
  • +/
    а почему два раза "prob 0.5", по идее, должно быть один раз, а то 1/4 трафика будет 40-ым правилом обрабатываться.
     
     
  • 2.6, pehlle (?), 15:23, 18/08/2009 [^] [ответить]    [к модератору]  
  • +/
    вы правильно говорите.
    правильнее будет так:
    $cmd add 20 prob 0.5 setfib 0 tcp from 192.168.0.0/16 to not 192.168.0.0/16 setup keep-state
    $cmd add 30 setfib 1 tcp from 192.168.0.0/16 to not 192.168.0.0/16 setup keep-state
     
  • 1.5, terminus (ok), 15:05, 18/08/2009 [ответить] [показать ветку] [···]    [к модератору]  
  • +/
    Проверяли, это нормально работает? Просто мне кажется что при таком конфиге TCP пакеты с вероятностью 1/2 будут прыгать между каналами, даже в случае когда обмен происходит в рамках одной сесии (IP:TCP <-> IP:TCP). Если потом пропускать еще и через нат, то в итоге IP_назначения будет получать TCP пакеты с двух IP.
    ЕМНИП то дополнительные параметры такие как prob будут срабатывать даже при проходе через check-stale. У nuclight подробно было написано про это:
    http://nuclight.livejournal.com/124348.html
     
  • 1.7, pehlle (?), 16:26, 18/08/2009 [ответить] [показать ветку] [···]    [к модератору]  
  • +/
    сорри :(, оказывается такое не работает. заметку можно удалить или наоборот дополнить, может быть у кого нить что нибудь с данным направлением че нить получиться. Меня сбило с понтолыки, что пакетики бегали на обоих каналах, оказывается, при проверке когда в правило ставиш флаг setup, то при keep-state, оно должно как бы закэшироваться, но не кэшируется.
     
     
  • 2.12, XoRe (ok), 16:20, 19/08/2009 [^] [ответить]    [к модератору]  
  • +/
    >сорри :(, оказывается такое не работает. заметку можно удалить или наоборот дополнить,
    >может быть у кого нить что нибудь с данным направлением че
    >нить получиться. Меня сбило с понтолыки, что пакетики бегали на обоих
    >каналах, оказывается, при проверке когда в правило ставиш флаг setup, то
    >при keep-state, оно должно как бы закэшироваться, но не кэшируется.

    Да ладно, рациональное зерно все равно есть)
    Могу порекомендовать тот вариант, который я описал ниже.

     
  • 1.8, shutdown now (?), 16:54, 18/08/2009 [ответить] [показать ветку] [···]    [к модератору]  
  • +/
    в 8-ой фре есть ECMP (Equal Cost Multipath Routing), он должен делить поровну.
    А если ещё и NAT, то тогда вот - http://wiki.opennet.ru/FreeBSD_Balance
     
  • 1.11, XoRe (ok), 16:19, 19/08/2009 [ответить] [показать ветку] [···]    [к модератору]  
  • +/
    Для раскидывания пакетов по двум каналам не обязательны множественные таблицы маршрутизации.
    Достаточно двух fwd в ipfw и двух натов.

    После некоторго исследования этой темы могу сказать свое имхо.

    Если пакеты одного клиента будут лететь через двух разных провайдеров (пусть даже с сохранением сессии, т.е. до одного ip адреса - через один канал), все равно возникнут проблемы с порталами типа mail.ru, vkontakte и т.д.
    Там может слетать авторизация, если запросы клиента будут приходить то с одного ip адреса, то с другого.
    Помню, mail.ru ругалась, когда я примерно через такую систему на неё заходил.
    То могут быть проблемы с любым более менее серьёзным интернет проектом, который имеет более одного ip адреса.

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

    Ну и плюс там пингование шлюзов и т.д.

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

     
     
  • 2.13, iZEN (ok), 19:40, 19/08/2009 [^] [ответить]    [к модератору]  
  • +/
    PF&ALTQ
     
     
  • 3.15, XoRe (ok), 13:05, 21/08/2009 [^] [ответить]    [к модератору]  
  • +/
    >PF&ALTQ

    А можно поподробнее?
    Если честно, не понятно, о чем это вы)
    Вы поддерживаете мою мысль и говорите, чем это можно сделать?
    Или хотите сказать, что с помощью PF&ALTQ можно сделать балансировку без проблем с mail.ru?

     
     
  • 4.17, iZEN (ok), 16:16, 21/08/2009 [^] [ответить]    [к модератору]  
  • +/
    >>PF&ALTQ
    >
    >А можно поподробнее?
    >Если честно, не понятно, о чем это вы)
    >Вы поддерживаете мою мысль и говорите, чем это можно сделать?
    >Или хотите сказать, что с помощью PF&ALTQ можно сделать балансировку без проблем
    >с mail.ru?

    Подробнее:
    1. http://house.hcn-strela.ru/BSDCert/BSDA-course/apcs02.html#pf-queue
    2. http://house.hcn-strela.ru/BSDCert/BSDA-course/apcs02.html#pf-pools-balance-o


     
     
  • 5.18, XoRe (ok), 13:05, 22/08/2009 [^] [ответить]     [к модератору]  
  • +/
    gt оверквотинг удален Ход ваших мыслей мне понятен Во всяком случае, я на это... весь текст скрыт [показать]
     
  • 1.14, Alive (??), 13:58, 20/08/2009 [ответить] [показать ветку] [···]    [к модератору]  
  • +/
    Согласен с товаришем XoRe. Без полноценного multipath routing правильную балансировку не сделаешь.
     
     
  • 2.16, XoRe (ok), 13:05, 21/08/2009 [^] [ответить]    [к модератору]  
  • +/
    >Согласен с товаришем XoRe. Без полноценного multipath routing правильную балансировку не сделаешь.
    >

    Я бы сказал, без своих IP адресов)

     
  • 1.20, ro (?), 20:50, 25/08/2009 [ответить] [показать ветку] [···]    [к модератору]  
  • +/
    а можно сделать ,как в линуксе,чтобы в зависимости от нагрузки каналов распределял?
     
     
  • 2.21, XoRe (ok), 21:48, 31/08/2009 [^] [ответить]    [к модератору]  
  • +/
    >а можно сделать ,как в линуксе,чтобы в зависимости от нагрузки каналов распределял?
    >

    А можно поподробнее про "как в линуксе"? )

     
     
  • 3.22, Merridius (?), 23:54, 19/12/2010 [^] [ответить]    [к модератору]  
  • +/
    >>а можно сделать ,как в линуксе,чтобы в зависимости от нагрузки каналов распределял?

    А можно купить циску в которой есть и multipath routing и ip sla и не парить себе мозг.

     

    Ваш комментарий
    Имя:         
    E-Mail:      
    Заголовок:
    Текст:



      Закладки на сайте
      Проследить за страницей
    Created 1996-2018 by Maxim Chirkov  
    ДобавитьПоддержатьВебмастеруГИД  
    Hosting by Ihor