LINUX.ORG.RU
ФорумAdmin

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


0

1

Здравствуйте :)

Есть два провайдера и подключения к ним через pppoe. Решил использовать каналы по полной, но в чем то промазал. После прописывания всех правил, один из каналов забивается полностью, а второй где то процентов на 10.

привожу списки всех правил которые получились в итоге:

iptables -v -t mangle -L

Chain PREROUTING (policy ACCEPT 173M packets, 93G bytes)
 pkts bytes target     prot opt in     out     source               destination
 4099  361K NOC        all  --  any    any     anywhere             anywhere            state NEW,RELATED
 182K  126M CONNMARK   all  --  any    any     anywhere             anywhere            CONNMARK restore

Chain INPUT (policy ACCEPT 36M packets, 8421M bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain FORWARD (policy ACCEPT 137M packets, 85G bytes)
 pkts bytes target     prot opt in     out     source               destination
  926 60233 NOC        all  --  any    ppp+    anywhere             anywhere            state NEW,RELATED
 178K  125M CONNMARK   all  --  any    any     anywhere             anywhere            CONNMARK restore

Chain OUTPUT (policy ACCEPT 35M packets, 11G bytes)
 pkts bytes target     prot opt in     out     source               destination
   57 26873 NOC        all  --  any    ppp+    anywhere             anywhere            state NEW,RELATED
 1875 1013K CONNMARK   all  --  any    any     anywhere             anywhere            CONNMARK restore

Chain POSTROUTING (policy ACCEPT 172M packets, 96G bytes)
 pkts bytes target     prot opt in     out     source               destination
  983 87106 NOC        all  --  any    ppp+    anywhere             anywhere            state NEW,RELATED
 180K  126M CONNMARK   all  --  any    any     anywhere             anywhere            CONNMARK restore

Chain NOC (4 references)
 pkts bytes target     prot opt in     out     source               destination
 6065  535K CONNMARK   all  --  any    any     anywhere             anywhere            CONNMARK set 0x1
 3032  265K RETURN     all  --  any    any     anywhere             anywhere            statistic mode nth every 2 packet 1
 3030  270K CONNMARK   all  --  any    any     anywhere             anywhere            CONNMARK set 0x2
 1514  127K RETURN     all  --  any    any     anywhere             anywhere            statistic mode nth every 2 packet 2

в iptables я пробовал так же и модуль random, разницы не ощутил.

ip rule show
0:      from all lookup 255
32764:  from all fwmark 0x2 lookup T2
32765:  from all fwmark 0x1 lookup T1
32766:  from all lookup main
32767:  from all lookup default

вся нагрузка ложится на шлюз лежащий в T2. я пробовал и в iptables менять местами правила маркировки и в ip rules пробовал менять местами таблицы - ничего не менялось :(

ip route show table T1
178.120.0.1 dev ppp0  proto kernel  scope link  src 178.124.160.115
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
ip route show table T2
178.121.0.1 dev ppp1  proto kernel  scope link  src 178.124.160.114
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 ppp1  scope link
ip route show
178.120.0.1 dev ppp0  proto kernel  scope link  src 178.124.160.115
178.121.0.1 dev ppp1  proto kernel  scope link  src 178.124.160.114
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
default equalize
        nexthop dev ppp0 weight 1
        nexthop dev ppp1 weight 1

из главной таблицы пробовал удалять шлюзы. то же разницы не ощутил. для чистоты эксперимента, после каждой операции очищал кэш маршрутов (ip route flush cache).

как уже писал выше, вся нагрузка ложится на шлюз ppp1, при этом ppp0 нагружается лишь процентов на 10 от силы.

по мануалам все должно работать, но что то не так, может кто знает где может быть причина?

Спасибо!

P.S. Заметил интересный момент. Если качать с FTP провайдера то балансировка работает на ура, если с какого либо другого места - ниразу.. :(

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

Pinkbyte ★★★★★ ()
Ответ на: комментарий от Pinkbyte

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

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.

kron0s ()
Ответ на: комментарий от kron0s

если вы про 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

kron0s ()
Ответ на: комментарий от kron0s

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

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

kron0s ()

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

Pinkbyte ★★★★★ ()

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

mky ★★★★★ ()
Ответ на: комментарий от mky

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

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

kron0s ()
Ответ на: комментарий от kron0s

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

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

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

mky ★★★★★ ()
Ответ на: комментарий от mky

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

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

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

kron0s ()
Ответ на: комментарий от kron0s

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

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

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

kron0s ()
Ответ на: комментарий от kron0s

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

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

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

kron0s ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.