iptables / iproute2 - балансировка нагрузки между провайдерами

во-первых, для корректной работы IP от обоих провайдеров необходимо еще добавить маршрутизацию от источника. во-вторых, ИМХО, периодически необходимо делать ip route flush cache(но я не уверен)

маршрутизация от источника? разве это не она:

ip route show table T1
[b]178.120.0.1 dev ppp0  proto kernel  scope link  src 178.124.160.115[/b]
192.168.11.0/24 dev eth1  proto kernel  scope link  src 192.168.11.31
192.168.0.0/20 dev eth2  proto kernel  scope link  src 192.168.2.250
169.254.0.0/16 dev eth2  scope link
127.0.0.0/8 dev lo  scope link
default dev ppp0  scope link

для flush cache ИМХО нет необходимости, т.к. подключения метит iptables.

если вы про ip rule add from, то я попробовал.

ip rule show
0:	from all lookup 255 
32760:	from 178.124.160.114 lookup T2 
32761:	from 178.124.160.115 lookup T1 
32762:	from all iif ppp1 lookup T2 
32763:	from all iif ppp0 lookup T1 
32764:	from all fwmark 0x2 lookup T2 
32765:	from all fwmark 0x1 lookup T1 
32766:	from all lookup main 
32767:	from all lookup default 

ppp0      inet addr:178.124.160.115  P-t-P:178.121.0.1  Mask:255.255.255.255
          
ppp1      inet addr:178.124.160.114  P-t-P:178.121.0.1  Mask:255.255.255.255

попробывать настроить бондинг?

было бы круто, но у провайдера DSLAM, там bonding не прокатит..

глянул по tcpdump интерфес который мало загружен. для теста запустил многопоточную закачку с mirror.yandex.ru

закачка идет через оба интерфеса, но почему то один интерфейс забит до отказа, а второй через пень колоду :(

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

но это ЕМНИП больше не поддерживается(я про iptables target ROUTE)

кстати, а ширина каналов у тебя одинаковая? если нет - смотри в сторону weight

ИМХО, лучше ACCEPT, а не RETURN, и ещё, если первое правило срабатывает на какждый второй пакет, то почему потом сработка не для всех пакетов? Ведь половину пакетов уже отсеены?

Pinkbyte

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

но это ЕМНИП больше не поддерживается(я про iptables target ROUTE)

Спасибо за ссылку :) В принципе я по похожему мануалу и делал, а с -j ROUTE пока не пробовал.

Ширина каналов одинаковая, приблизительно. С weight то же баловался, но тоже особого результата не принесло. А может ядро не корректно раскидывать соединения по маршрутам?

mky

ИМХО, лучше ACCEPT, а не RETURN, и ещё, если первое правило срабатывает на какждый второй пакет, то почему потом сработка не для всех пакетов? Ведь половину пакетов уже отсеены?

Возможно для производительности ACCEPT и лучше, не пробовал. Но вот на маршрутизацию вряд ли влияет :( А отработку после маркировки я то же менял. Самое интересное в том, что по статистике маркирует все правильно. Т.е. по ровну, значит и на шлюзы должно правильно отправлять, но при этом нагрузка существенно отличается :(

Chain PREROUTING (policy ACCEPT 11M packets, 6335M bytes)
num   pkts bytes target     prot opt in     out     source               destination
1     168K   14M NOC        all  --  eth2   any     anywhere             anywhere            state NEW,RELATED

2      11M 6335M CONNMARK   all  --  any    any     anywhere             anywhere            CONNMARK restore

Chain INPUT (policy ACCEPT 2731K packets, 690M bytes)
num   pkts bytes target     prot opt in     out     source               destination

Chain FORWARD (policy ACCEPT 7810K packets, 5644M bytes)
num   pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 2592K packets, 665M bytes)
num   pkts bytes target     prot opt in     out     source               destination

Chain POSTROUTING (policy ACCEPT 10M packets, 6309M bytes)
num   pkts bytes target     prot opt in     out     source               destination

Chain NOC (1 references)
num   pkts bytes target     prot opt in     out     source               destination
1     168K   14M CONNMARK   all  --  any    any     anywhere             anywhere            CONNMARK set 0x1
2    84199 7271K RETURN     all  --  any    any     anywhere             anywhere            statistic mode nth every 2 packet 1
3    84161 7201K CONNMARK   all  --  any    any     anywhere             anywhere            CONNMARK set 0x2
4       28  2599 RETURN     all  --  any    any     anywhere             anywhere

Еще нюанс. Пробовал я маркировать пакеты от нескольких хостов и направлять на разные шлюзы, т.е. один хост на один шлюз, второй - на второй, работает на ура. Если же маркировать через один пакет и направлять на разные шлюзы (т.е. делать балансировку) - фиг там, преимущественно вся нагрузка ложится на один шлюз.

Попробуйте в таблице маршрутизации main поставить маршрут по умолчанию unreachable, тогда будет видно, есть ли не отмаркированные соединения (если что-то перестанет работать). Только для -t mangle OUTPUT тоже пропишите маркировку пактов/соединений.

Можно ещё установить правила/счётчики для NEW соединений в POSTROUTING для ppp0 и ppp1, тогда будет видно, как распределяется траффик с точки зрения новых соединений.

А траффик то у вас http или торренты?

Благодарю за ответ :)

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

Траффик богатый. Тут и торренты и http и VoIP. Поэтому, по идее, при хорошей балансировке все должно работать на ура, но пока где то косяк :/

Проблема кроется в чем то другом...

Посмотрел счетчики. iptables все раскидывает красиво, один водин, как на пометке так и на выходе через каждый pppoe интерфейс. Проблема оказывается в другом. Одновременно поднято два pppoe соединения и все бы ничего, но одно из них, почему то, ограничено по скорости.

Попробовал менять кабеля, модемы - ничего не помогает. pppoe соединение поднимаемое на определенном интерфейсе тупит и не поднимается по скорости выше мегабита... Ниразу ничего подобного не видел. Может кто сталкивался?

С расбрасыванием каналов разобрался. Косяк был на стороне провайдера :D

Спасибо всем за помощь!

Возник другой вопрос. При балансировке, если подключаться к ФТП серверу, то бывает так, что канал данных идет через другого провайдера и получается ошибка. С ФТП люди работают в пассивном режиме, поэтому канал данных задать явно не получится. Может у кого есть какие идеи?