Nekto Опубликовано 30 сентября, 2016 · Жалоба В таком случае я могу через ipset загнать пачку адресов или субнетов в один сет и потом одним правилом iptables направить этот сет в определенный клас/марку. Собственно для определенного вида трафика я так и делаю. В моем случае речь идет об индивидуальной настройке для каждого адреса. Как я понимаю ipset прекрасно работает с адресами на уровне хэшей, а tc пережевывает вывод из правила напрямую. tc не сканирует весь пробегающий трафик, а лишь подбирает выборку ipseta. Если я ошибаюсь - поправьте. В любом случае на следующей неделе будут результаты. Единственные грабли коорые я могу предположить, это когда ipset прогоняет всю цепочку для каждого правила, но интуищия мне подсказывает, что у него выборка идет глобально и он сортирует пакеты по сетам используя свои внутренние метки. Во всяком случае такой сценарий мне кажется правдоподобным. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Pavel.M.A Опубликовано 2 октября, 2016 (изменено) · Жалоба Очень интересный подход с ipset -> tc (class) через iptables, решил попробовать: iptables -A POSTROUTING -t mangle -o eth1 -j SET --map-set SHAPE_IP4 dst --map-prio iptables -A POSTROUTING -t mangle -o ifb0 -j SET --map-set SHAPE_IP4 src --map-prio Но тут меня ждал нежданчик с UPLOAD шейпингом, если на сервере есть NAT то получается, что нужно делать псевдоинтерфейс с ifb0, но так как он отрабатывает до netfilter, правила такова вида (iptables -A POSTROUTING -t mangle -o ifb0 -j SET --map-set SHAPE_IP4 src --map-prio) - не работают... Вопрос, как кто шейпит upload через такую схему ? Есть ли рабочие решения ?) Изменено 2 октября, 2016 пользователем Pavel.M.A Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
taf_321 Опубликовано 2 октября, 2016 · Жалоба Как я понимаю ipset прекрасно работает с адресами на уровне хэшей, а tc пережевывает вывод из правила напрямую. tc не сканирует весь пробегающий трафик, а лишь подбирает выборку ipseta. Да, одним правилом iptables и одним сетом заменяется вся портянка tc filter для всех адресов и всех классов. И да, nethash нормально обрабатывает любой адрес от */0-32 (v6 0/128) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
taf_321 Опубликовано 3 октября, 2016 · Жалоба Вопрос, как кто шейпит upload через такую схему ? Есть ли рабочие решения ?) В свое время тоже было совмещение на одном тазике NAT и шейпера, но напрыгавшись с разными малоочевидными глюками такой схемы, разнесли их по разным железкам. Чего и вам желаю. Интересно, теряется ли при NAT уже присвоенное значение skbprio? Ведь если оно сохраняется, то правило iptables можно поставить в PREROUTING на внутренний интерфейс, а классы на интерфейс в сторону внешки. Тогда надобность в ifb вообще отпадает. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sirmax Опубликовано 3 октября, 2016 · Жалоба Вопрос, как кто шейпит upload через такую схему ? Есть ли рабочие решения ?) В свое время тоже было совмещение на одном тазике NAT и шейпера, но напрыгавшись с разными малоочевидными глюками такой схемы, разнесли их по разным железкам. Чего и вам желаю. Интересно, теряется ли при NAT уже присвоенное значение skbprio? Ведь если оно сохраняется, то правило iptables можно поставить в PREROUTING на внутренний интерфейс, а классы на интерфейс в сторону внешки. Тогда надобность в ifb вообще отпадает. Можно через неймспейсы через виртуальный роутер прогонять и там шейпить а натить потом. В лабе я это собирал - работает ip netns ... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SABRE Опубликовано 3 октября, 2016 · Жалоба /sbin/tc filter add dev eth0 protocol all parent 1:0 prio 200 u32 ht 2:0x05 match ip dst 192.168.0.5 flowid 1:11 А если tc filter add dev eth0 protocol all parent 1:0 prio 200 handle 2:5 u32 ht 2:5 match ip dst 192.168.0.5 flowid 1:11 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vop Опубликовано 3 октября, 2016 · Жалоба Очень интересный подход с ipset -> tc (class) через iptables, решил попробовать: iptables -A POSTROUTING -t mangle -o eth1 -j SET --map-set SHAPE_IP4 dst --map-prio iptables -A POSTROUTING -t mangle -o ifb0 -j SET --map-set SHAPE_IP4 src --map-prio Но тут меня ждал нежданчик с UPLOAD шейпингом, если на сервере есть NAT то получается, что нужно делать псевдоинтерфейс с ifb0, но так как он отрабатывает до netfilter, правила такова вида (iptables -A POSTROUTING -t mangle -o ifb0 -j SET --map-set SHAPE_IP4 src --map-prio) - не работают... Вопрос, как кто шейпит upload через такую схему ? Есть ли рабочие решения ?) Второе правило пишем: iptables -A PREROUTING -t mangle -i eth1 -j SET --map-set SHAPE_IP4 dst --map-prio В этом весь кайф класификации через iptables + set, не надо делать псевдоинтерфейсы, если есть NAT. Ну и желательно, отфильтровать внешний трафик, что бы локальный не шейпился. PS В принципе, там можно и в FORWARD вставить правило. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Nekto Опубликовано 3 октября, 2016 · Жалоба А если tc filter add dev eth0 protocol all parent 1:0 prio 200 handle 2:5 u32 ht 2:5 match ip dst 192.168.0.5 flowid 1:11 Я попробовал на ядре 3Х запустить правило без протокола all - работает с u32 без проблем. (Думаю поэтому и ipset срабатывает) Попробовал создать стандартное правило для хэшей - не работает. Все же в новых ядрах в плане vlan что-то поменяли. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Pavel.M.A Опубликовано 3 октября, 2016 (изменено) · Жалоба Вопрос, как кто шейпит upload через такую схему ? Есть ли рабочие решения ?) В свое время тоже было совмещение на одном тазике NAT и шейпера, но напрыгавшись с разными малоочевидными глюками такой схемы, разнесли их по разным железкам. Чего и вам желаю. Интересно, теряется ли при NAT уже присвоенное значение skbprio? Ведь если оно сохраняется, то правило iptables можно поставить в PREROUTING на внутренний интерфейс, а классы на интерфейс в сторону внешки. Тогда надобность в ifb вообще отпадает. Ахахахах!!!! работает, проверил, не теряет он skbprio ))) такая схема: сам ТС: qdisc add dev eth0 root handle 1: htb qdisc add dev eth1 root handle 1: htb class add dev $eth0 parent 1: classid 1:64 htb rate 10Mbit quantum 15140 class add dev $eth1 parent 1: classid 1:64 htb rate 10Mbit quantum 15140 ipset: IPSET create SHAPE_IP4 hash:net skbinfo IPSET -A SHAPE_IP4 192.168.0.0/24 iptables: iptables -A FORWARD -t mangle -i eth1 -j SET --map-set SHAPE_IP4 dst --map-prio iptables -A FORWARD -t mangle -o eth1 -j SET --map-set SHAPE_IP4 src --map-prio Шейпит и UPLOAD и DOWNLOAD без IFB c NAT.... Очень интересная схема )) P.S В PREROUTING не получится - "mapping of prio or/and queue is allowed onlyfrom OUTPUT/FORWARD/POSTROUTING chains" Изменено 3 октября, 2016 пользователем Pavel.M.A Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vop Опубликовано 3 октября, 2016 · Жалоба Ахахахах!!!! работает, проверил, не теряет он skbprio ))) такая схема: Я эту схему уже трем провайдерам сбагрил. Работает шустро достаточно. P.S В PREROUTING не получится - "mapping of prio or/and queue is allowed onlyfrom OUTPUT/FORWARD/POSTROUTING chains" Да, все верно, я потом посмотрел, у меня в FORWARD и вставлено чуток посложнее, т.к. там несколько клиентских интерфейсов. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Nekto Опубликовано 11 октября, 2016 (изменено) · Жалоба Наконец привязал новую схему шапера к биллингу. Особо не торопились, поскольку загрузка проца не превышала 50%. В итоге остановился на схеме, предложенной taf_321, с использованием skbinfo, за идею ему отдельное спасибо. В моем случае главной причиной была возможность использовать схему на любой версии ядра. Посчитал, что отказ от tc filter тоже скажится положительно. При использовании Vlan правило iptables приходится прописывать на интерфейс vlan. Зато правила htb работают на родительском интерфейсе eth0, eth1,ethX, что меня полностью устраивает. Боевой рутер на котором все крутится в строю уже ~7 лет. 4х ядерный Xeon X3330 @ 2.66GHz 2Gb ram. сетевуха Intel 82576. Без шапера загрузка cpu в пределах 10-15%. 2 полных таблицы BGP, DNS, DHCP, Squid (заворачивать блочные сайты) ната нет. Включаем неоптимизированный шапер - при 50 kpps загрузка cpu ~50% при 40 kpps загрузка ~40% при 30 kpps ~30%, прямо как под заказ :) Запустил оптимизированный вариант. Всего в ipset 4900 записей . ~2000 вида hash:ip где проставляется skbinfo, остальные hash:ip,port и где-то 500 hash:net,port. Правил htb ~ 2000 (их количество не менялось). Добавилось 13 правил iptables по количеству vlan. Результаты загрузки cpu: 60 kpps загрузка cpu 33% при 40 kpps загрузка cpu ~26% при 30 kpps загрузка cpu ~19% Думаю по результатам все понятно - инструкция в ветке. Да, для каждого ип мы маркируем трафик отдельной маркой, так сложилось исторически - отвязать от биллинга сложно. При работе с субнетами прирост может оказаться выше. ipset рулит! Только что посмотрел статистику 48kpps - 24% - с чем связано не знаю. Изменено 11 октября, 2016 пользователем Nekto Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pppoetest Опубликовано 11 октября, 2016 · Жалоба Результаты загрузки cpu: 60 kpps загрузка cpu 33% Ужос, слишкой большой % load cpu при таком ппс. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kayot Опубликовано 11 октября, 2016 · Жалоба Так там проц хлам, даже без шейпера 100к PPS предел. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pppoetest Опубликовано 11 октября, 2016 · Жалоба А, пардон, не посмотрел. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Nekto Опубликовано 11 октября, 2016 (изменено) · Жалоба Пока проц справляется с нагрузкой менять его смысла нет. 7 лет пашет без остановок. Я описывал загрузку, чтобы было наглядное представление о применении данной схемы шэйпера. Кстати, сколько pps тот же I7-6700 без проблем пережевывает? Изменено 11 октября, 2016 пользователем Nekto Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
taf_321 Опубликовано 12 октября, 2016 · Жалоба Добавилось 13 правил iptables по количеству vlan Если имена интерфейсов вланов типовые - vlan1, vlan2, vlanSUPER1, то 13 правил можно свести к одному, задав маску имени интерфейса vlan+ пример: # даем доступ -A FORWARD -o ppp+ -m set --match-set clients dst -j ACCEPT -A FORWARD -i ppp+ -m set --match-set clients src -j ACCEPT Правила применяются на все ppp-интерфейсы. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pppoetest Опубликовано 12 октября, 2016 · Жалоба На I7-4770 с развесистым шейпером ~120килострок, фаером на 50 строк, натом и бгп, на 130кппс загрузка в 50% каждого ядра. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Nekto Опубликовано 12 октября, 2016 (изменено) · Жалоба # даем доступ -A FORWARD -o ppp+ -m set --match-set clients dst -j ACCEPT -A FORWARD -i ppp+ -m set --match-set clients src -j ACCEPT Правила применяются на все ppp-интерфейсы. У меня нет ppp интерфейсов, но для каждого vlan пакеты направляются в свой сет, где собраны ip исходящие из этого интерфейса. Правила получаются слеюующие: -A POSTROUTING -o eth0.+ -m set --match-set in_vlan11 src -j ACCEPT -A POSTROUTING -o eth0.+ -m set --match-set in_vlan12 src -j ACCEPT Для каждого интерфейса задается свой сет. через + не получится так сделать. Изменено 12 октября, 2016 пользователем Nekto Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Pavel.M.A Опубликовано 12 октября, 2016 · Жалоба # даем доступ -A FORWARD -o ppp+ -m set --match-set clients dst -j ACCEPT -A FORWARD -i ppp+ -m set --match-set clients src -j ACCEPT Правила применяются на все ppp-интерфейсы. У меня нет ppp интерфейсов, но для каждого vlan пакеты направляются в свой сет, где собраны ip исходящие из этого интерфейса. Правила получаются слеюующие: -A POSTROUTING -o eth0.+ -m set --match-set in_vlan11 src -j ACCEPT -A POSTROUTING -o eth0.+ -m set --match-set in_vlan12 src -j ACCEPT Для каждого интерфейса задается свой сет. через + не получится так сделать. А смысл с такой схемы ? Мне кажется можно упростить, привязать IPtables к интерфейсу eth0 (со всеми вланами) и сделать 1 табличку, а не разбивать на кучу табличек по вланам. Я бы так сделал... ) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Nekto Опубликовано 12 октября, 2016 · Жалоба А смысл с такой схемы ? Мне кажется можно упростить, привязать IPtables к интерфейсу eth0 (со всеми вланами) и сделать 1 табличку, а не разбивать на кучу табличек по вланам. Я бы так сделал... ) Вы невнимательно читали ветку. По такой схеме не работает на 4.4.18 ядре. Если ставлю 3.18.ХХ то работает. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...