[sire]

Есть два подключения к двум разным провайдерам (P1 и P2). Стоит задача разделить трафик между провайдерами в отношении 80% к 20%. На маршрутизаторе - Linux Debian Etch. Ядро 2.6.18.

 

Прочитал LARTC, кучу разных примеров, настроил.

В итоге - весь трафик идёт через того провайдера, маршрут к шлюзу которого прописан последним.

То есть если ip route говорит

default equalize
        nexthop via GW_P2  dev IF_P2 weight 20
        nexthop via GW_P1  dev IF_P1 weight 80

,

то весь трафик идёт через провайдера P1.

Стоит поменять записи nexthop местами, как весть трафик постепенно перетекает на провайдера P2.

 

Что интересно, команда

ip route show cache|grep GW_P1 |wc -l;
ip route show cache|grep GW_P2 |wc -l

выдаёт количество маршрутов в кэше для GW_P1 =~ 2.2 * GW_P2, то есть маршрутов через GW_P1 примерно в 2 раза больше, чем через GW_P2. Хотя в соответствии с указанными весами маршрутов отношение должно быть 4 к 1.

 

Привожу свою конфигурацию

ip route
NET_P1/29 dev IF_P1  proto kernel  scope link  src IP_P1
NET_P2/29 dev IF_P2  proto kernel  scope link  src IP_P2
10.253.253.0/24 dev IF_INT  proto kernel  scope link  src 10.253.253.104  # внутренняя сеть
default equalize
        nexthop via GW_P2  dev IF_P2 weight 20
        nexthop via GW_P1  dev IF_P1 weight 80

ip route show table prov1
несколько маршрутов через внутренние шлюзы via 10.253.253.154 dev IF_INT
default via GW_P1 dev IF_P1

ip route show table prov2
несколько маршрутов через внутренние шлюзы via 10.253.253.154 dev IF_INT
default via GW_P2 dev IF_P2

iptables-save
*mangle
-A PREROUTING -j CONNMARK --restore-mark
-A POSTROUTING -o IF_P1 -m state --state NEW -j MARK --set-mark 0x1
-A POSTROUTING -o IF_P2 -m state --state NEW -j MARK --set-mark 0x2
-A POSTROUTING -m state --state NEW -j CONNMARK --save-mark
COMMIT
*nat
-A POSTROUTING -m mark --mark 0x1 -j SNAT --to-source IP_P1
-A POSTROUTING -m mark --mark 0x2 -j SNAT --to-source IP_P2
COMMIT
*filter
-A FORWARD -j ACCEPT
COMMIT

 

Ещё я обратил внимание на странные маршруты в кэше:

ip route show cache #(фрагмент)
85.118.176.227 from 10.1.148.238 tos throughput via [b]GW_P1 dev IF_P1[/b]  src [b]IP_P2[/b]
    cache  mtu 1500 advmss 1460 hoplimit 64 iif IF_INT
85.118.176.227 from 10.1.148.238 tos throughput via [b]GW_P2 dev IF_P2[/b]  src [b]IP_P2[/b]
    cache  mtu 1500 advmss 1460 hoplimit 64 iif eth3
10.1.146.111 from 203.131.198.76 via 10.253.253.154 dev IF_INT  src IP_P2
    cache  mtu 1500 advmss 1460 hoplimit 64 iif IF_P1
10.1.150.36 from 194.67.57.206 via 10.253.253.154 dev IF_INT  src IP_P1
    cache  mtu 1500 advmss 1460 hoplimit 64 iif IF_P1
212.143.210.244 from IP_P1 via GW_P1 dev IF_P1
    cache  mtu 1500 advmss 1460 hoplimit 64
local IP_P1 from 125.2.30.104 dev lo  src IP_P1
    cache <local>  iif IF_P1
10.1.151.238 from 64.207.161.110 via 10.253.253.154 dev IF_INT  src IP_P2
    cache  mtu 1500 advmss 1460 hoplimit 64 iif IF_P1

 

Подскажите, пожалуйста, что попроавить. Заранее очень благодарен.

[BETEPAH]

http://gazette.lrn.ru/rus/articles/lartc/x348.html

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

[sire]

http://gazette.lrn.ru/rus/articles/lartc/x348.html

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

C этим вариантом вообще всё отрубилось :-(

[sire]

>Ещё я обратил внимание на странные маршруты в кэше:

ip route show cache #(фрагмент) 
85.118.176.227 from 10.1.148.238 tos throughput via [b]GW_P1 dev IF_P1[/b]  src [b]IP_P2[/b] 
cache  mtu 1500 advmss 1460 hoplimit 64 iif IF_INT 
85.118.176.227 from 10.1.148.238 tos throughput via [b]GW_P2 dev IF_P2[/b]  src [b]IP_P2[/b] 
cache  mtu 1500 advmss 1460 hoplimit 64 iif eth3

 

"Странные" маршруты победил добавлением в таблицу main тех маршрутов во внутреннюю сеть, которые были прописаны в таблицах prov1 и prov2 (несколько маршрутов через внутренние шлюзы via 10.253.253.154 dev IF_INT).

 

Обнаружил новую "странность"

ip route show cache |grep 'src IP_P2'

выдаёт записи вида

10.1.150.100 from 38.99.76.89 via 10.253.253.154 dev IF_INT  src IP_P2

В то время как

ip route show cache |grep 'src IP_P1'

выдаёт записи вида

local IP_P1 from 74.12.206.112 dev lo  src IP_P1

 

Обнаружил ещё одну "странность".

Это нормально, что в кэше содержатся маршруты для одних и тех же точек через разные шлюзы?

Ещё и по несколько раз одно и то же.

83.9.82.101 from 10.1.149.152 via GW_P1 dev IF_P1  src 10.253.253.104
    cache  mtu 1500 advmss 1460 hoplimit 64 iif IF_INT
83.9.82.101 from 10.1.149.152 via GW_P1 dev IF_P1  src 10.253.253.104
    cache  mtu 1500 advmss 1460 hoplimit 64 iif IF_INT
83.9.82.101 from 10.1.149.152 via GW_P2 dev IF_P2  src 10.253.253.104
    cache  mtu 1500 advmss 1460 hoplimit 64 iif IF_INT

Изменено 20 февраля, 2007 пользователем sire

[sire]

Такое впечатление, что это глюк Debian Etch.

[sire]

Как оказалось, это глюк Debian Etch. Немало народу задаёт этот же вопрос в Инете, в основном на английском. Буду искать решение. Возможно пересборка ядра или iproute.

[sire]

К стати, та же конфигурация прекрасно работает на ALT Linux Master 2.4 с ядром 2.4.26 и на ASP Linux с ядром 2.6.18.1.

Изменено 28 февраля, 2007 пользователем sire

[BETEPAH]

ставь freebsd

[sire]

ставь freebsd

FreeBSD на том же сервере с той же нагрузкой очень тормозит. Загрузка проца под 100%. К тому же, говорю, что на других линуксах балансировка нагрузки пашет. Это проблема Debian Etch.

Изменено 1 марта, 2007 пользователем sire

[BETEPAH]

jab молчит почему то, он бы счас рассказал, что фрю готовить не умеете :)

[jab]

Да я хотел, но думаю - а что толку-то ? :-) Они и линух готовить не умеют. Пусть ставят cisco. На juniper у них денюг не хватит.

[sire]

Проблему удалось решить пересборкой ядра Debian Etch без параметра CONFIG_IP_ROUTE_MULTIPATH_CACHED=y. Теперь всё работает как надо. Зачем они вообще его включили? Столько времени из-за него потерял!