sire Опубликовано 19 февраля, 2007 · Жалоба Есть два подключения к двум разным провайдерам (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 Подскажите, пожалуйста, что попроавить. Заранее очень благодарен. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
BETEPAH Опубликовано 19 февраля, 2007 · Жалоба http://gazette.lrn.ru/rus/articles/lartc/x348.html делал как здесь - работало, единственный недостаток, маршруты кешируются и балансировка немного неправильно работает, но там есть ссылки на патчи, устраняющие данную проблему Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sire Опубликовано 19 февраля, 2007 · Жалоба http://gazette.lrn.ru/rus/articles/lartc/x348.htmlделал как здесь - работало, единственный недостаток, маршруты кешируются и балансировка немного неправильно работает, но там есть ссылки на патчи, устраняющие данную проблему C этим вариантом вообще всё отрубилось :-( Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sire Опубликовано 19 февраля, 2007 (изменено) · Жалоба >Ещё я обратил внимание на странные маршруты в кэше: 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sire Опубликовано 26 февраля, 2007 · Жалоба Такое впечатление, что это глюк Debian Etch. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sire Опубликовано 26 февраля, 2007 · Жалоба Как оказалось, это глюк Debian Etch. Немало народу задаёт этот же вопрос в Инете, в основном на английском. Буду искать решение. Возможно пересборка ядра или iproute. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sire Опубликовано 28 февраля, 2007 (изменено) · Жалоба К стати, та же конфигурация прекрасно работает на ALT Linux Master 2.4 с ядром 2.4.26 и на ASP Linux с ядром 2.6.18.1. Изменено 28 февраля, 2007 пользователем sire Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
BETEPAH Опубликовано 1 марта, 2007 · Жалоба ставь freebsd Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sire Опубликовано 1 марта, 2007 (изменено) · Жалоба ставь freebsd FreeBSD на том же сервере с той же нагрузкой очень тормозит. Загрузка проца под 100%. К тому же, говорю, что на других линуксах балансировка нагрузки пашет. Это проблема Debian Etch. Изменено 1 марта, 2007 пользователем sire Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
BETEPAH Опубликовано 1 марта, 2007 · Жалоба jab молчит почему то, он бы счас рассказал, что фрю готовить не умеете :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
jab Опубликовано 1 марта, 2007 · Жалоба Да я хотел, но думаю - а что толку-то ? :-) Они и линух готовить не умеют. Пусть ставят cisco. На juniper у них денюг не хватит. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sire Опубликовано 1 марта, 2007 · Жалоба Проблему удалось решить пересборкой ядра Debian Etch без параметра CONFIG_IP_ROUTE_MULTIPATH_CACHED=y. Теперь всё работает как надо. Зачем они вообще его включили? Столько времени из-за него потерял! Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...