Izo_lda Опубликовано 8 июня, 2017 · Жалоба использую tc для шейпинга и пытаюсь настроить через хэш таблицы download поток нормально загоняется для каждого адреса в свою таблицу а upload все равно продолжает идти через таблицу по умолчанию 800:: если upload резать через таблицу по умолчанию 800:: при достижении ~ более 500 отдельных сетевых адресов начинаются затыки в сети если upload при большом количестве отдельных сетевых адресов отключить то затыков в сети не наблюдается пример рабочего кода с ограничением при upload через таблицу по умолчанию 800:: rmmod ifb modprobe ifb numifbs=1 tc qdisc del dev eth0 root tc qdisc add dev eth0 root handle 1: htb default 9 tc class add dev eth0 parent 1: classid 1:1 htb rate 1000MBit ceil 1000MBit tc class add dev eth0 parent 1:1 classid 1:9 htb rate 1000MBit ceil 1000MBit tc qdisc add dev eth0 parent 1:9 handle 9: sfq perturb 10 ip link set dev ifb0 up tc qdisc del dev ifb0 root tc qdisc del dev ifb0 ingress tc qdisc add dev eth0 ingress tc filter add dev eth0 parent ffff: protocol ip u32 match u32 0 0 action mirred egress redirect dev ifb0 tc qdisc add dev ifb0 root handle 1: htb default 9 tc class add dev ifb0 parent 1: classid 1:1 htb rate 1000MBit ceil 1000MBit tc class add dev ifb0 parent 1:1 classid 1:9 htb rate 1000MBit ceil 1000MBit tc qdisc add dev ifb0 parent 1:9 handle 9: sfq perturb 10 tc filter add dev eth0 parent 1:0 handle 20: protocol ip u32 divisor 256 tc filter add dev eth0 parent 1:0 protocol ip u32 ht 800:: match ip dst 192.168.0.0/24 hashkey mask 0x000000ff at 16 link 20: tc filter add dev ifb0 parent 1:0 handle 20: protocol ip u32 divisor 256 tc filter add dev ifb0 parent 1:0 protocol ip u32 ht 800:: match ip src 192.168.0.0/24 hashkey mask 0x000000ff at 16 link 20: tc class add dev eth0 parent 1:1 classid 1:10 htb rate 10Mbit ceil 10Mbit tc qdisc add dev eth0 parent 1:10 handle 10: sfq perturb 10 tc filter add dev eth0 parent 1:0 protocol ip prio 1 u32 ht 20:15: match ip dst 192.168.0.21/32 flowid 1:10 tc class add dev ifb0 parent 1:1 classid 1:10 htb rate 10Mbit ceil 10Mbit tc qdisc add dev ifb0 parent 1:10 handle 10: sfq perturb 10 tc filter add dev ifb0 parent 1:0 protocol ip prio 1 u32 ht 800:: match ip src 192.168.0.21/32 flowid 1:10 при upload через отдельную таблицу все равно поток идет через таблицу по умолчанию 800:: ... tc filter add dev ifb0 parent 1:0 protocol ip prio 1 u32 ht 20:15: match ip src 192.168.0.21/32 flowid 1:10 возможно я что то не так формирую в хэш таблицу или оно просто и не должно работать в ifb через хэш таблицы? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
taf_321 Опубликовано 8 июня, 2017 · Жалоба Хэшам интерфейсы безразличны. https://www.altlinux.org/%D0%A8%D0%B5%D0%B9%D0%BF%D0%B5%D1%80%D0%94%D0%BB%D1%8F%D0%91%D0%BE%D0%BB%D1%8C%D1%88%D0%B8%D1%85%D0%A1%D0%B5%D1%82%D0%B5%D0%B9 и про дружбомагию хэшей можно забыть. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
photon Опубликовано 8 июня, 2017 (изменено) · Жалоба Я реализовал это дело без псевдоустройств, с помощью полисинга входящего трафика и шейпинга исходящего: https://sourceforge.net/projects/sc-tool . Если используются только IPv4-адреса, то ipset и iptables из ссылки в предыдущем посте не нужны, все делается правилами tc и поэтому работает быстрее. Да и IPv6 вообще говоря можно точно так же побайтово хэшировать, просто это никому не надо. Изменено 8 июня, 2017 пользователем photon Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
bomberman Опубликовано 9 июня, 2017 · Жалоба А ещё есть ipt_ratelimit, с CIDR и ipv6. Но правда это полисинг. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Izo_lda Опубликовано 9 июня, 2017 · Жалоба Хэшам интерфейсы безразличны. https://www.altlinux.org/%D0%A8%D0%B5%D0%B9%D0%BF%D0%B5%D1%80%D0%94%D0%BB%D1%8F%D0%91%D0%BE%D0%BB%D1%8C%D1%88%D0%B8%D1%85%D0%A1%D0%B5%D1%82%D0%B5%D0%B9 и про дружбомагию хэшей можно забыть. спасибо, попробую такой вариант Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vop Опубликовано 9 июня, 2017 · Жалоба Хэшам интерфейсы безразличны. https://www.altlinux.org/%D0%A8%D0%B5%D0%B9%D0%BF%D0%B5%D1%80%D0%94%D0%BB%D1%8F%D0%91%D0%BE%D0%BB%D1%8C%D1%88%D0%B8%D1%85%D0%A1%D0%B5%D1%82%D0%B5%D0%B9 и про дружбомагию хэшей можно забыть. спасибо, попробую такой вариант Пока это самый удобный вариант, как по мне. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
fet4 Опубликовано 16 января, 2018 · Жалоба В 08.06.2017 в 17:17, taf_321 сказал: https://www.altlinux.org/ШейперДляБольшихСетей В данном способе в ipset заносятся ip адреса с одинаковым классом add shaper4 172.16.1.10/32 skbprio 1:d add shaper4 172.16.1.12/32 skbprio 1:d add shaper4 172.16.1.14/32 skbprio 1:d add shaper4 172.16.1.31/32 skbprio 1:d Разве эти Ip не будут делить скорость между собой в пределах одного класса? Насколько я понял это классы тарифов class add dev bondINT parent 1: classid 1:d est 1sec 8sec hfsc sc umax 1500b dmax 5ms rate 20480kbit ul rate 20480kbit qdisc add dev bondINT parent 1:d handle d: pfifo limit 200 class add dev bondEXT parent 1: classid 1:d est 1sec 8sec hfsc sc umax 1500b dmax 5ms rate 20480kbit ul rate 20480kbit qdisc add dev bondEXT parent 1:d handle d: pfifo limit 200 Или я ошибаюсь? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vop Опубликовано 16 января, 2018 · Жалоба Да, будут делить. Я так понимаю, что эти адреса принадлежат одному "клиенту". Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
fet4 Опубликовано 16 января, 2018 (изменено) · Жалоба Еще такой вопрос. Если есть два одинаковых класса 1:d на двух разных интерфейсах. add shaper4 172.16.1.10/32 skbprio 1:d Классифицируя на этих интерфейсах -o bondEXT -j SET --map-set shaper4 src --map-prio -o bondINT -j SET --map-set shaper4 dst --map-prio Он попадет в класс 1:d на двух интерфейсах и первом и втором? Или нужно разделять нумерацию классов для входящего и исходящего трафика? Изменено 16 января, 2018 пользователем fet4 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
taf_321 Опубликовано 17 января, 2018 · Жалоба 19 часов назад, fet4 сказал: Разве эти Ip не будут делить скорость между собой в пределах одного класса? Да, будут делить, ибо так и задумано (как правильно сказали выше, эти адреса принадлежат одному и тому же клиенту) 19 часов назад, fet4 сказал: Насколько я понял это классы тарифов Да, это мы уже конкретно прописываем классы и скорости на конкретных интерфейсах. То, что прописывается два раза на разных интерфейсах это просто для задания скорости на входящий и исходящий трафик. 9 часов назад, fet4 сказал: Он попадет в класс 1:d на двух интерфейсах и первом и втором? Или нужно разделять нумерацию классов для входящего и исходящего трафика? Разделять не обязательно. 1:d на bondINT это не то же самое что 1:d на bondEXT и им даже можно назначать разные скорости. Просто для справки, в примере интерфейс bondINT смотрит в сторону клиентов, и на этом интерфейсе мы задаем скорости в сторону клиента трафика (мы ведь помним, что нормально шейпить можно только исходящий с интерфейса трафик? Именно по этой причине в правилах iptables указаны опции -o), для задания скорости исходящего от клиентов в мир трафика мы прописываем классы на смотрящем в мир интерфейсе bondEXT. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
fet4 Опубликовано 17 января, 2018 · Жалоба Цитата Разделять не обязательно. 1:d на bondINT это не то же самое что 1:d на bondEXT и им даже можно назначать разные скорости. Или проще сказать - классов с одинаковыми дескрипторами на разных интерфейсах может быть сколько угодно и трафик попадет в эти классы если он классифицирован? Цитата (мы ведь помним, что нормально шейпить можно только исходящий с интерфейса трафик? Именно по этой причине в правилах iptables указаны опции -o) Это да помним! По этой причине я использую ifb для редиректа на него входящего в интерфейс трафика, по этой причине я не смогу классифицировать в iptables этот трафик(входящий) с помощью -o т.к. это происходит до iptables? Придется использовать tc filter? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
taf_321 Опубликовано 17 января, 2018 · Жалоба 1 час назад, fet4 сказал: Или проще сказать - классов с одинаковыми дескрипторами на разных интерфейсах может быть сколько угодно и трафик попадет в эти классы если он классифицирован? Коряво, но можно и так сказать. 1 час назад, fet4 сказал: Это да помним! По этой причине я использую ifb для редиректа на него входящего в интерфейс трафика, по этой причине я не смогу классифицировать в iptables этот трафик(входящий) с помощью -o т.к. это происходит до iptables? Придется использовать tc filter? Вот, кстати, с -o я чуток соврал. кусок дампа с рабочего браса, параметр -o не обязателен: -A POSTROUTING -m set ! --match-set localnet4 src -j SET --map-set shaper4 dst --map-prio -A POSTROUTING -m set ! --match-set localnet4 dst -j SET --map-set shaper4 src --map-prio -A POSTROUTING -m set --match-set localnet4 src -j SET --map-set local-skb4 dst --map-prio -A POSTROUTING -m set --match-set localnet4 dst -j SET --map-set local-skb4 src --map-prio Танцы с localnet4 в первых двух правилах созданы чтобы классифицировался только внешний трафик, в других двух правилах это уже классификация локального трафика и пиров. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vop Опубликовано 17 января, 2018 · Жалоба 4 часа назад, fet4 сказал: Это да помним! По этой причине я использую ifb для редиректа на него входящего в интерфейс трафика, по этой причине я не смогу классифицировать в iptables этот трафик(входящий) с помощью -o т.к. это происходит до iptables? Придется использовать tc filter? Этого делать не надо (ifb). Трафик нормально классифицируется при входе (с внутреннего интерфейса), а шейпится на выходе. Я классифицирую в цепочках: -t mangle -A FORWARD -i int ... -t mangle -A FORWARD -o int ... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
fet4 Опубликовано 17 января, 2018 · Жалоба 2 часа назад, vop сказал: Этого делать не надо (ifb). Трафик нормально классифицируется при входе (с внутреннего интерфейса), а шейпится на выходе. Я классифицирую в цепочках: А если этих внутренних интерфейсов тьма, а нужно построить единое дерево классов? По идее все манипуляции нужно проводит с аплинк интерфейсом у которого исходящий трафик шейпится, а вход заворачивается на ifb или полисится. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vop Опубликовано 17 января, 2018 · Жалоба 3 часа назад, fet4 сказал: А если этих внутренних интерфейсов тьма, а нужно построить единое дерево классов? По идее все манипуляции нужно проводит с аплинк интерфейсом у которого исходящий трафик шейпится, а вход заворачивается на ifb или полисится. А, ну да, если надо один корень для всех интерфейсов, а это надо, если используется ceil правило, то да, тогда можно и ifb поставить. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
taf_321 Опубликовано 18 января, 2018 · Жалоба 11 часов назад, fet4 сказал: А если этих внутренних интерфейсов тьма, а нужно построить единое дерево классов? По идее все манипуляции нужно проводит с аплинк интерфейсом у которого исходящий трафик шейпится, а вход заворачивается на ifb или полисится. Не обязательно. Если проклассифицировать трафик через iptables, то потом можно просто вешать классы на физические интерфейсы, и трафик будет шейпиться, если он даже проходит внутри ppp-соединения или vlan'а. Пример с боевого браса: class add dev bondDOWN parent 1: classid 1:e est 1sec 8sec hfsc sc umax 1500b dmax 10ms rate 60000kbit ul rate 60000kbit qdisc add dev bondDOWN parent 1:e handle e: pfifo limit 100 class add dev bondUP parent 1: classid 1:e est 1sec 8sec hfsc sc umax 1500b dmax 10ms rate 60000kbit ul rate 60000kbit qdisc add dev bondUP parent 1:e handle e: pfifo limit 100 bondUP смотрит в сторону пограничника, bondDOWN смотрит в сторону клиентов, клиенты висят на pppoe. При этом на bondDOWN создано почти пять сотен vlan-интерфейсов, уже на которые производится подключение клиентов по pppoe. Но для всех клиентов классы навешиваются всего на два интерфейса, и мне ортогонально какой у клиента сейчас и потом будет ppp-интерфейс и через какой vlan он подключился. 7 часов назад, vop сказал: А, ну да, если надо один корень для всех интерфейсов, а это надо, если используется ceil правило, то да, тогда можно и ifb поставить. Это нужно только в одном случае, если скорость на входящий-исходящий суммируется, а не отдельная на каждое направление. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
fet4 Опубликовано 18 января, 2018 (изменено) · Жалоба Это прям магия какая-то :) Впервые слышу что можно классифицировать трафик на физическом интерфейсе который пришел с другого или в iptables там уже это опускается. Если так и есть то это было супер и упростило бы жизнь мне. Вы все классифицируете в iptables? А можно Ваши tc -s -d -g class show dev bondDOWN tc -s -d -g class show dev bondUP tc -s -d -g qdisc show dev bondDOWN tc -s -d -g qdisc show dev bondUP iptables-save ipset list Для понимания картины в целом. Заранее спасибо. Изменено 18 января, 2018 пользователем fet4 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kayot Опубликовано 18 января, 2018 · Жалоба @fet4 А почему нет? Это не будет работать только для pptp, а для влан-интерфейсов и даже pppoe работает, трафик же в сыром виде на родительском интерфейсе бегает. Я так шейплю на IPOE-БРАСе с кучей qinq вланов. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
fet4 Опубликовано 18 января, 2018 · Жалоба А в случае если родительский/физический инт. один, входящий трафик все равно придется заворачивать на ifb для шейпинга? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
taf_321 Опубликовано 19 января, 2018 · Жалоба 11 часов назад, kayot сказал: А почему нет? Это не будет работать только для pptp, Чем интерфейс ppp у pptp туннеля отличается от такого же интерфейса у pppoe? Все дело в том, что при классификации через iptables + ipset заполняется skb->prio у пакета, шедулер заглядывает в это поле у каждого отправляемого через интерфейс пакета. "tc filter" делает то же самое, но своими методами. 10 часов назад, fet4 сказал: А в случае если родительский/физический инт. один, входящий трафик все равно придется заворачивать на ifb для шейпинга? Для этого случая, скорее всего да, через ifb. Разве что если vlan-интерфейсов всего два (один аплинк, второй клиенты), то классы можно повесить на эти vlan-интерфейсы. И по хорошему их все же надо разнести по разным физическим портам. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dendj Опубликовано 26 марта, 2018 · Жалоба здравствуйте, помогите с ifb при заворачивании трафика, iptables не маркирует пакеты iptables -t mangle -A POSTROUTING -o ifb1 -j SET --map-set shaper4 src --map-prio ps источник вдохновения https://www.altlinux.org/ШейперДляБольшихСетей Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
x86 Опубликовано 29 марта, 2018 · Жалоба iptables не работает с ifb. Используйте tc. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ne-vlezay80 Опубликовано 20 апреля, 2018 · Жалоба В 3/29/2018 в 16:09, x86 сказал: iptables не работает с ifb. Используйте tc. А как через tc анализировать трафик на 7-мом уровне модели OSI? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 21 апреля, 2018 · Жалоба 23 часа назад, ne-vlezay80 сказал: А как через tc анализировать трафик на 7-мом уровне модели OSI? Модель OSI - это фантазия телефонистов, в мире есть tcp/ip. OSI ложится на это своими уровнями с 1 по 4, дальше всё ломается к чертям как минимум в половине случаев. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
x86 Опубликовано 24 апреля, 2018 · Жалоба В 21.04.2018 в 02:17, ne-vlezay80 сказал: А как через tc анализировать трафик на 7-мом уровне модели OSI? Простой ответ - никак. Сложный - используйте u32, но это все-равно не даст всех возможностей iptables. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...