[Nekto]

В таком случае я могу через ipset загнать пачку адресов или субнетов в один сет и потом одним правилом iptables

направить этот сет в определенный клас/марку. Собственно для определенного вида трафика я так и делаю.

В моем случае речь идет об индивидуальной настройке для каждого адреса. Как я понимаю ipset прекрасно работает с адресами на уровне хэшей, а tc пережевывает вывод из правила напрямую. tc не сканирует весь пробегающий трафик, а лишь подбирает выборку ipseta. Если я ошибаюсь - поправьте. В любом случае на следующей неделе будут результаты. Единственные грабли коорые я могу предположить, это когда ipset прогоняет всю цепочку для каждого правила, но интуищия мне подсказывает, что у него выборка идет глобально и он сортирует пакеты по сетам используя свои внутренние метки. Во всяком случае такой сценарий мне кажется правдоподобным.

[Pavel.M.A]

Очень интересный подход с 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

[taf_321]

Как я понимаю ipset прекрасно работает с адресами на уровне хэшей, а tc пережевывает вывод из правила напрямую. tc не сканирует весь пробегающий трафик, а лишь подбирает выборку ipseta.

 

Да, одним правилом iptables и одним сетом заменяется вся портянка tc filter для всех адресов и всех классов. И да, nethash нормально обрабатывает любой адрес от */0-32 (v6 0/128)

[taf_321]

Вопрос, как кто шейпит upload через такую схему ? Есть ли рабочие решения ?)

В свое время тоже было совмещение на одном тазике NAT и шейпера, но напрыгавшись с разными малоочевидными глюками такой схемы, разнесли их по разным железкам. Чего и вам желаю.

 

Интересно, теряется ли при NAT уже присвоенное значение skbprio? Ведь если оно сохраняется, то правило iptables можно поставить в PREROUTING на внутренний интерфейс, а классы на интерфейс в сторону внешки. Тогда надобность в ifb вообще отпадает.

[sirmax]

Вопрос, как кто шейпит upload через такую схему ? Есть ли рабочие решения ?)

В свое время тоже было совмещение на одном тазике NAT и шейпера, но напрыгавшись с разными малоочевидными глюками такой схемы, разнесли их по разным железкам. Чего и вам желаю.

 

Интересно, теряется ли при NAT уже присвоенное значение skbprio? Ведь если оно сохраняется, то правило iptables можно поставить в PREROUTING на внутренний интерфейс, а классы на интерфейс в сторону внешки. Тогда надобность в ifb вообще отпадает.

 

Можно через неймспейсы через виртуальный роутер прогонять и там шейпить а натить потом.

В лабе я это собирал - работает

 

ip netns  ... 

[SABRE]

/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

[vop]

Очень интересный подход с 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 вставить правило.

[Nekto]

А если

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 что-то поменяли.

[Pavel.M.A]

Вопрос, как кто шейпит 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

[vop]

Ахахахах!!!! работает, проверил, не теряет он skbprio ))) такая схема:

 

Я эту схему уже трем провайдерам сбагрил. Работает шустро достаточно.

 

P.S В PREROUTING не получится - "mapping of prio or/and queue is allowed onlyfrom OUTPUT/FORWARD/POSTROUTING chains"

 

Да, все верно, я потом посмотрел, у меня в FORWARD и вставлено чуток посложнее, т.к. там несколько клиентских интерфейсов.

[Nekto]

Наконец привязал новую схему шапера к биллингу. Особо не торопились, поскольку загрузка проца не превышала 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

[pppoetest]

Результаты загрузки cpu: 60 kpps загрузка cpu 33%

Ужос, слишкой большой % load cpu при таком ппс.

[kayot]

Так там проц хлам, даже без шейпера 100к PPS предел.

[pppoetest]

А, пардон, не посмотрел.

[Nekto]

Пока проц справляется с нагрузкой менять его смысла нет. 7 лет пашет без остановок. Я описывал загрузку, чтобы было наглядное представление о применении данной схемы шэйпера.

Кстати, сколько pps тот же I7-6700 без проблем пережевывает?

Изменено 11 октября, 2016 пользователем Nekto

[taf_321]

Добавилось 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-интерфейсы.

[pppoetest]

На I7-4770 с развесистым шейпером ~120килострок, фаером на 50 строк, натом и бгп, на 130кппс загрузка в 50% каждого ядра.

[Nekto]

 

# даем доступ
-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

[Pavel.M.A]

 

# даем доступ
-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 табличку, а не разбивать на кучу табличек по вланам.

 

Я бы так сделал... )

[Nekto]

 

А смысл с такой схемы ?

Мне кажется можно упростить, привязать IPtables к интерфейсу eth0 (со всеми вланами) и сделать 1 табличку, а не разбивать на кучу табличек по вланам.

 

Я бы так сделал... )

Вы невнимательно читали ветку. По такой схеме не работает на 4.4.18 ядре. Если ставлю 3.18.ХХ то работает.