Балансировка между двумя каналами под FreeBSD и Linux

в OpenBSD это можно сделать при помощи pf + trunk

в OpenBSD этого нельзя сделать (попробуйте).

В ОСи которая катит только на роутеры этого нельзя сделать?

А Линукс микроядро тогда чтоли? :-)))))

Как обычно, на ЛОРе обсуждают что угодно, кроме статьи :)

Впрочем, от нее я ожидал большего...

P.S. Я про статью о Linux

http://tetro.net/misc/multilink.html :

You can't just trunk them together because they each have a different public IP address, gateway, etc.

Текст новости скопирован с http://www.opennet.ru/opennews/art.shtml?num=6494

да , так и есть . imho интересная новость , ожидал интересное обсуждение . пока тишина , наверное суббота ....

i che tut obsuzhdat'? ipfw? ping -f? uzhosnah. U menya ne tak. U menya PF, i razdaet PPPoE | pppd (ne zakonchil pravda nastrojku ALTQ eshe, stydno)

Нда, то что для Linux на статью тянет как-то с трудом

> Figure out a way to make FTP work.

ip_conntrack_ftp ?

> You can achieve pretty much the same result with Linux Advanced Routing techniques. One small difference, as the link mentions, is that routes are cached

Можно и в сторону equalize посмотреть

$IP route add table 8 equalize scope global nexthop via $GW1 weight 1 nexthop via $GW2 weight 1

другое дело оно просто так работать не будет ;)) Кстати, кто знает почему ?

Кому интересно, некоторые ссылки по теме

http://www.docum.org/docum.org/kptd/
http://www.ssi.bg/~ja/dgd-usage.txt
http://www.ssi.bg/~ja/nano.txt

этим ты будешь только исходящий траф. балансировать... а вот вход тебе будет отдаваться в зависимости от маршрутов у gw1 и gw2...

или я чего не догнал? ;)

>Можно и в сторону equalize посмотреть

оно не так работает.

> оно не так работает.

Не так, это как ?

equalize --- allow packet by packet randomization on multipath routes. Without this modifier route will be frozen to one selected nexthop, so that load splitting will occur only on per-flow base. Equalize works only if the appropriate kernel configuration option is chosen or if the kernel is patched.

То что я привел конечно работать не будет, так-как connection-tracking всеравно нужен. Но судя по этому

http://www.ussg.iu.edu/hypermail/linux/kernel/0003.3/1119.html

должно. А то-что медленно, так в случае с -j ROUTE --gw ... - кэш просматривается, выбирается маршрут, а дальше просто перезаписывается, что еще медленее.

>Не так, это как ?

Ага, не так. В том случае, о котором говоришь ты, при необходимости выбрать маршрут к некоему хосту, он действительно выбирается более-менее случайно. Но после этого, все пакеты на этот хост пойдут по этому маршруту, независимо от его загруженности. B это будет продолжаться до истечения времени жизни маршрутной записи.

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

Если говорить о большом периоде времени (месяц, например), то _количество_ трафика, переданное по маршрутам может и будет более-менее похожее при использовании `equalize ... weight 1 ... weight 1 ...`, и при использовании `random --average 50`. Но в конкретный момент времени, equalize более грубо делит канал.

Создается нехорошее чувство, что протокол SCTP не очень известен.

Я конечно извиняюсь, но по-моему балансировка на уровне multipath routing и подсчета кол-ва пакетов - это несколько некорректно. Т.к. ни что из этого не учитывает реальную загрузку каналов (не учитывает ОБЪЕМ), следовательно какая может быть балансировка ? Да, за большой промежуток времени согласен. Но с другой стороны, зачем нужно использовать неизвестно что, если можно явно определять текущую загрузку того или иного канала и на ее основании принимать то или иное решение ?
Ведь как-то пробегал на форуме вопрос про модуль width для iptables. Вот он как раз и может считать текущую загрузку. Соответственно если загрузка какого-либо канала в пределах нормы - используем к примеру multipath routing (если ни один канал не загружен полностью, то какая разница куда пойдут пакеты), если где-то загрузка начинает зашкаливать - начинаем "выпрямлять" маршруты (для новых соединений) с помощью firewall.
Или я что-то упустил в этой теме ? :-)

Да нет, я просто говорил, что euqalize работает не так, как -m random и -m nth :)

А о том, что что-то из перечисленного работает хорошо - я как раз молчал ;)

а для ядрышка разве нет патчика, чтобы эквалайз 'нормально' работал... т.е. без 'кэширования' маршрутов?

Не знаю. А что значит "нормально"?

> В том случае, о котором говоришь ты, при необходимости выбрать маршрут к некоему хосту, он действительно выбирается более-менее случайно. Но после этого, все пакеты на этот хост пойдут по этому маршруту

Как раз так будет без equalize, если я ничего не напутал.

А с _рабочим_ equalize, в случае с - equalize nexthop .. nexthop итд, получится что-то вроде teql.

Как я понял, судя по net/ipv4/route.c: ip_route_output_key, equalize работает следующим образом:

При поиске маршрута просматривается PDBB, если задано, например ip route add default equalize via 192.168.0.1 - в routing cache добавляется запись с полем RTCF_EQUALIZE. При следующем запросе, если dst, src, outif, также tos равны и запись помечена RTCF_EQUALIZE, запись из кэша выбрасывается и опять просматривается PDBB.

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

Я писал всеголишь о том как избавится от -j ROUTE --gw, а не о распределении нагрузки. Тоесть оставляем все, а -j ROUTE меняем на -j MARK и добавляем две таблицы

ip route add table 2 equalize default via 192.168.0.1
ip route add table 4 equalize default via 192.168.0.2

и два правила

ip route add mark .. 2
ip route add mark .. 4

и получаем тоже самое только с возможностью использования PDB. К вопросу зачем ? Например если некоторые сети ближе от одного провайдера, надо будет все это делать опять же через iptables, а как быть в случае с bgp ?

Кстати, без equalize можно обойтись и TOS полем, тогда дополнительно никаких патчей накладывать не надо и даже будет быстрее чем с equalize.

> а для ядрышка разве нет патчика, чтобы эквалайз 'нормально' работал... т.е. без 'кэширования' маршрутов?

Есть, но только без него он не то-что нормально, он вообще никак не работает :))

ftp://sliepen.warande.net/pub/eql/

http://www.ussg.iu.edu/hypermail/linux/kernel/0003.3/1268.html