mr.Scamp Опубликовано: 9 августа, 2014 Опубликовано: 9 августа, 2014 (изменено) Заметил в микротике прикольную фичу - PCC. Позволяет разделить трафик на несколько потоков, причем равномерно. Очень полезно для overload NAT-а кучи сеток через несколько внешних адресов, например /ip firewall mangle add action=mark-connection chain=prerouting new-connection-mark=nat-1 passthrough=yes per-connection-classifier=src-address:8/0 \ src-address=10.100.0.0/16 add action=mark-connection chain=prerouting new-connection-mark=nat-2 passthrough=yes per-connection-classifier=src-address:8/1 \ src-address=10.100.0.0/16 add action=mark-connection chain=prerouting new-connection-mark=nat-3 passthrough=yes per-connection-classifier=src-address:8/2 \ src-address=10.100.0.0/16 add action=mark-connection chain=prerouting new-connection-mark=nat-4 passthrough=yes per-connection-classifier=src-address:8/3 \ src-address=10.100.0.0/16 add action=mark-connection chain=prerouting new-connection-mark=nat-5 passthrough=yes per-connection-classifier=src-address:8/4 \ src-address=10.100.0.0/16 add action=mark-connection chain=prerouting new-connection-mark=nat-6 passthrough=yes per-connection-classifier=src-address:8/5 \ src-address=10.100.0.0/16 add action=mark-connection chain=prerouting new-connection-mark=nat-7 passthrough=yes per-connection-classifier=src-address:8/6 \ src-address=10.100.0.0/16 add action=mark-connection chain=prerouting new-connection-mark=nat-8 passthrough=yes per-connection-classifier=src-address:8/7 \ src-address=10.100.0.0/16 /ip firewall nat add action=src-nat chain=srcnat connection-mark=nat-1 out-interface=vlan452 to-addresses=194.44.166.xxx add action=src-nat chain=srcnat connection-mark=nat-2 out-interface=vlan452 to-addresses=194.44.166.xxx add action=src-nat chain=srcnat connection-mark=nat-3 out-interface=vlan452 to-addresses=194.44.166.xxx add action=src-nat chain=srcnat connection-mark=nat-4 out-interface=vlan452 to-addresses=194.44.166.xxx add action=src-nat chain=srcnat connection-mark=nat-5 out-interface=vlan452 to-addresses=194.44.166.xxx add action=src-nat chain=srcnat connection-mark=nat-6 out-interface=vlan452 to-addresses=194.44.166.xxx add action=src-nat chain=srcnat connection-mark=nat-7 out-interface=vlan452 to-addresses=194.44.166.xxx add action=src-nat chain=srcnat connection-mark=nat-8 out-interface=vlan452 to-addresses=194.44.166.xxx Есть вопрос - а как реализовать такой же рулсет с помощью iptables? Изменено 9 августа, 2014 пользователем mr.Scamp
KaYot Опубликовано: 9 августа, 2014 Опубликовано: 9 августа, 2014 В iptables такие костыли вообще не нужны, делайте обычный snat в диапазон адресов с ключиком persistent или как оно там.
twg Опубликовано: 9 августа, 2014 Опубликовано: 9 августа, 2014 $ipt -t nat -A POSTROUTING -s 172.16.0.128/26 -o vlanXXX -j SNAT --to-source Y.Y.Y.195 $ipt -t nat -A POSTROUTING -s 172.16.0.192/26 -o vlanXXX -j SNAT --to-source Y.Y.Y.196 $ipt -t nat -A POSTROUTING -s 172.16.1.0/26 -o vlanXXX -j SNAT --to-source Y.Y.Y.197 У меня так
mr.Scamp Опубликовано: 9 августа, 2014 Автор Опубликовано: 9 августа, 2014 SNAT в диапазон адресов не катит, соединения одного и того же юзера размываются по всему диапазону. Ключик --persistent добавляет хэширование src-dst ip при выборе внешнего адреса, но тоже не то немного, насколько я понимаю, один и тот же юзер будет иметь разные исходящие IP при посещении разных ресурсов. Пока что присматриваюсь к DNETMAP, штука интересная, но нужно много внешних адресов, по адресу на каждого активного клиента.
mr.Scamp Опубликовано: 9 августа, 2014 Автор Опубликовано: 9 августа, 2014 У меня так Тут недостаток в том, что пользователи получают неизменный внешний адрес, что не всегда есть желательно. Да и при большом количестве внутренних подсетей таким рулсетом неудобно управлять из-за его громоздкости. Мне вот нравиться решение задачи NAT-а в пул адресов с помощью pf на FreeBSD nat on vlan210 from 10.200.0.0/16 to any -> 193.106.147.zzz/28 source-hash
KaYot Опубликовано: 9 августа, 2014 Опубликовано: 9 августа, 2014 Ключик --persistent добавляет хэширование src-dst ip при выборе внешнего адреса, но тоже не то немного, насколько я понимаю, один и тот же юзер будет иметь разные исходящие IP при посещении разных ресурсов.А не факт что будут разные, проверьте. И даже если будут - что с того? Распределение равномерное работает как и требовалось.
twg Опубликовано: 9 августа, 2014 Опубликовано: 9 августа, 2014 Тут недостаток Ну не самый изящный способ. )) Но телега тянет, сети каждый день не добавляются. При большом количестве сетей на баше можно разребать.
mr.Scamp Опубликовано: 9 августа, 2014 Автор Опубликовано: 9 августа, 2014 А не факт что будут разные, проверьте. И даже если будут - что с того? Распределение равномерное работает как и требовалось. Могут быть проблемы с сайтами, где фронт и контент находятся за разными IP-адресами, они требуют, чтобы скачивание/стриминг контента было с того же адреса, откуда был загружен плеер. Обязательно проверю, кстати.
mort1k Опубликовано: 9 августа, 2014 Опубликовано: 9 августа, 2014 -A POSTROUTING -s 192.168.0.0/16 -o bond0 -j SNAT --to-source X.X.X.1-Y.Y.Y.128 --persistent
KaYot Опубликовано: 9 августа, 2014 Опубликовано: 9 августа, 2014 А не факт что будут разные, проверьте. И даже если будут - что с того? Распределение равномерное работает как и требовалось.Могут быть проблемы с сайтами, где фронт и контент находятся за разными IP-адресами, они требуют, чтобы скачивание/стриминг контента было с того же адреса, откуда был загружен плеер. Обязательно проверю, кстати. Насколько я помню при persistent как раз таки по src ip идет хеширование, и проблем не возникает.
mr.Scamp Опубликовано: 9 августа, 2014 Автор Опубликовано: 9 августа, 2014 Проверил, действительно хэшируется по src-ip, причем даже после ребута внешний адрес остается тем же. Как все просто оказалось на самом деле ;-) Спасибо всем за советы.
fet4 Опубликовано: 10 августа, 2014 Опубликовано: 10 августа, 2014 Кстати может кто знает, как в Debian реализовать Per Connection Classifier, а именно балансировку каналов по src адресу? Разбивать трафик по src допустим так - первый ip пошел через isp1, второй ip пошел через isp2, третий снова по isp1 и так далее.
rsst Опубликовано: 10 августа, 2014 Опубликовано: 10 августа, 2014 Кстати может кто знает, как в Debian реализовать Per Connection Classifier, а именно балансировку каналов по src адресу? Разбивать трафик по src допустим так - первый ip пошел через isp1, второй ip пошел через isp2, третий снова по isp1 и так далее. а два дефолта с одинаковым весом не работают?
fet4 Опубликовано: 10 августа, 2014 Опубликовано: 10 августа, 2014 (изменено) Кстати может кто знает, как в Debian реализовать Per Connection Classifier, а именно балансировку каналов по src адресу? Разбивать трафик по src допустим так - первый ip пошел через isp1, второй ip пошел через isp2, третий снова по isp1 и так далее. а два дефолта с одинаковым весом не работают? Не работают. И nexthop тоже не работает корректно. Пример - заходишь в вк, вроде зашло, а музыка не играет, потом во все авторизацию сбрасывает, все потому что последующее соединение идет через другой шлюз. Надо как-то маркировать и направлять в нужные таблицы. Вот если бы к этому привязать как-то src адрес, цены не было б. iptables -t mangle -N NEW_OUT_CONN iptables -t mangle -A NEW_OUT_CONN -j CONNMARK --set-mark 1 iptables -t mangle -A NEW_OUT_CONN -m statistic --mode random --probability 0.50 -j RETURN iptables -t mangle -A NEW_OUT_CONN -j CONNMARK --set-mark 2 Изменено 10 августа, 2014 пользователем fet4
mr.Scamp Опубликовано: 10 августа, 2014 Автор Опубликовано: 10 августа, 2014 нашел релевантную ссылку по теме http://serverfault.com/questions/237867/iptables-match-for-hashing-ip-addresses
fet4 Опубликовано: 10 августа, 2014 Опубликовано: 10 августа, 2014 (изменено) Так точно, но решение не найдено ( Изменено 10 августа, 2014 пользователем fet4
KaYot Опубликовано: 10 августа, 2014 Опубликовано: 10 августа, 2014 (изменено) Кстати может кто знает, как в Debian реализовать Per Connection Classifier, а именно балансировку каналов по src адресу? Разбивать трафик по src допустим так - первый ip пошел через isp1, второй ip пошел через isp2, третий снова по isp1 и так далее.[/size]Решение классическое, через ip rule. 1) создаете 2 таблицы маршрутизации (t1 и t2 к примеру). Как создавать искать лень, ищите. Добавить строчку в /etc/iproute/rt_tables или где-то рядом. 2) Делаете ip rule add from 192.168.1.0/24 table t1 ip rule add from 192.168.2.0/24 table t2 Классификаторов в rule много, можно задать любые условия. Например по меткам как вы выше делали, хоть это и не тру вей. 3) В таблицы добавляете нужные default GW ip route add deafult via xx.xx.xx.xx table t1 ip route add deafult via yy.xx.xx.xx table t2 Profit. Изменено 10 августа, 2014 пользователем KaYot
fet4 Опубликовано: 10 августа, 2014 Опубликовано: 10 августа, 2014 (изменено) Не вы не поняли. То что вы написали все есть и работает бомба. Нужно сбалансировать нагрузку от активных клиентов по двум таблицам допустим 50/50. И не просто сбалансировать, а по src адресу. Чтоб часть ip пошла через первую табличку, вторая часть во вторую. До окончания сесси Изменено 10 августа, 2014 пользователем fet4
KaYot Опубликовано: 11 августа, 2014 Опубликовано: 11 августа, 2014 Создайте 100шт ip rule по 10 адресов в каждом. Поиск там хешируемый, производительность не пострадает.
Abram Опубликовано: 11 августа, 2014 Опубликовано: 11 августа, 2014 KaYot, ему хочется динамически от нагрузки разбрасывать.
twg Опубликовано: 11 августа, 2014 Опубликовано: 11 августа, 2014 KaYot, ему хочется динамически от нагрузки разбрасывать. В таком случае нужно прикрутить скрипт к ip-up (pppoe) или к ДХЦП при выдаче ип маркировать или рулить. Но это опять же не динамически по нагрузке.
fet4 Опубликовано: 11 августа, 2014 Опубликовано: 11 августа, 2014 (изменено) KaYot, ему хочется динамически от нагрузки разбрасывать. Хотя бы по очереди пихать то в одну то в другую табличку. KaYot, ему хочется динамически от нагрузки разбрасывать. В таком случае нужно прикрутить скрипт к ip-up (pppoe) или к ДХЦП при выдаче ип маркировать или рулить. Но это опять же не динамически по нагрузке. Думаю так и придется, делать костыль. А как лучше реализовать на bash выборку ip, чтобы чередовать таблицы маршрут.? Изменено 11 августа, 2014 пользователем fet4
NiTr0 Опубликовано: 13 августа, 2014 Опубликовано: 13 августа, 2014 ip-down - удление правила из таблички, ip-up - добавление правила в ту табличку, где меньше всего записей...
twg Опубликовано: 13 августа, 2014 Опубликовано: 13 августа, 2014 ip-down - удление правила из таблички, ip-up - добавление правила в ту табличку, где меньше всего записей... Так лучше всего. Но, опять же, больше записей не означает бОльшую нагрузку на канал. ИМХО нормально эту задачу не решить. Если речь об аналоге микротиковских правил, то тут уже ответили. Если о динамически по нагрузке, то нормально никак. Нагрузка сама по себе динамическая.
Abram Опубликовано: 13 августа, 2014 Опубликовано: 13 августа, 2014 ИМХО нормально эту задачу не решить.Золотые слова.
Рекомендованные сообщения
Создайте аккаунт или войдите в него для комментирования
Вы должны быть пользователем, чтобы оставить комментарий
Создать аккаунт
Зарегистрируйтесь для получения аккаунта. Это просто!
Зарегистрировать аккаунтВойти
Уже зарегистрированы? Войдите здесь.
Войти сейчас