hfsc при 2гбит начинает блокировать весь трафик на том интерфейсе где он висит.

[NiTr0]

а в корневой не попадает? :) по tc -s q s посмотреть, сравнить с трафиком на линке...

[Стич]

а в корневой не попадает? :) по tc -s q s посмотреть, сравнить с трафиком на линке...

Нет не попадает.

На линке было 4.4ГБит/c. Корневом классе 2.7ГБит/c.

 

Вообще этот htb сплошная загадка, у меня до этого три года вообще работало без корневого и дефолтного класса.

Все классы пользователей были к корневой дисциплине привязаны.

Когда начались проблемы на 4ГБит/c решил сделать как надо и корневой и дефолтный классы,

эффекта ни какого.

Edited March 6, 2017 by Стич

[Igor Diakonov]

А чем вам ipt_ratelimit не подошёл? :)

[Стич]

Проект классный и респект разработчику.

Но

1. В нём только полисинг, а на низких тарифах юзерам это не нравиться и если мешать вместе с HTB то двойной анализ(класификация) пакетов выходит.

2. И главное боюсь что может быть заброшен разработчиком.

Планируется лм официально добавить модуль в ядро?

Edited March 6, 2017 by Стич

[Igor Diakonov]

Проект классный и респект разработчику.

Но

1. В нём только полисинг, а на низких тарифах юзерам это не нравиться и если мешать вместе с HTB то двойной анализ(класификация) пакетов выходит.

Имхо, на скоростях от пары мегабит - уже особой разницы нет.

 

2. И главное боюсь что может быть заброшен разработчиком.

Планируется лм официально добавить модуль в ядро?

Всё может быть. Тот же ipt_NETFLOW пока не забросил, надеюсь и ratelimit не забросит )

По-моему, "официальная" позиция ядрописателей примерно такая - "файрвол - файрволит, а классами трафика и прочими ограничениями скоростей занимается tc и нечего тёплое с мягким смешивать".

[haooss]

пожалуй присоеденюсь к просьбе,kayot. Позвольте полюбопытствовать Ваш подход, вернее реализацию.

 

Доброго времени.

Может кому-нибудь будет полезно.

Еще один вариант [рабочий] полисера на TC. Недостаток, нельзя выделить одно полосу для нескольких ip, как в HTB (Хотя может я и не разобрался до конца).

 

/sbin/tc qdisc add dev bond0.628 ingress

/sbin/tc f a dev bond0.628 parent ffff:0 prio 10 handle 3:  protocol ip  u32 divisor 256
/sbin/tc f a dev bond0.628 protocol ip parent ffff:0 prio 10 u32 ht 800:: match ip dst 192.168.64.0/18 hashkey mask 0x000000ff at 16 link 3:

/sbin/tc f a dev bond0.628 protocol ip parent ffff:0 prio 10 u32 ht 3:0x63: match ip dst 192.168.120.99 action police rate 5500Kbit burst 550K drop mtu 1500 flowid :12
/sbin/tc f a dev bond0.628 protocol ip parent ffff:0 prio 10 u32 ht 3:0x62: match ip dst 192.168.120.98 action police rate 5500Kbit burst 550K drop mtu 1500 flowid :13

[wtyd]

пожалуй присоеденюсь к просьбе,kayot. Позвольте полюбопытствовать Ваш подход, вернее реализацию.

 

Доброго времени.

Может кому-нибудь будет полезно.

Еще один вариант [рабочий] полисера на TC. Недостаток, нельзя выделить одно полосу для нескольких ip, как в HTB (Хотя может я и не разобрался до конца).

 

/sbin/tc qdisc add dev bond0.628 ingress

/sbin/tc f a dev bond0.628 parent ffff:0 prio 10 handle 3:  protocol ip  u32 divisor 256
/sbin/tc f a dev bond0.628 protocol ip parent ffff:0 prio 10 u32 ht 800:: match ip dst 192.168.64.0/18 hashkey mask 0x000000ff at 16 link 3:

/sbin/tc f a dev bond0.628 protocol ip parent ffff:0 prio 10 u32 ht 3:0x63: match ip dst 192.168.120.99 action police rate 5500Kbit burst 550K drop mtu 1500 flowid :12
/sbin/tc f a dev bond0.628 protocol ip parent ffff:0 prio 10 u32 ht 3:0x62: match ip dst 192.168.120.98 action police rate 5500Kbit burst 550K drop mtu 1500 flowid :13

 

Не совсем понял этот пример. последний октет адреса является ключом к хешу, т.е. ойпи 192.168.120.98 попадает в 3:0x62 (98 = 0x62), а зачем тогда ещё один матч делать ? Т.е. зачем нужна запись "match ip dst 192.168.120.98" ведь пакет и так уже попал в 3:0x62, может без матча будет работать ?

 

Если без этого матча будет работать, то ещё несколько процессорных тактов освободится. На самом деле я правда не знаю, я такое несколько лет назад на htb и затем на hfsc делал, но уже всё забыл.

[SABRE]

может без матча будет работать

А в любом стучае нужно указывать match. Т.ч. я думаю, не важно что именно матчить.

[haooss]

Не совсем понял этот пример. последний октет адреса является ключом к хешу, т.е. ойпи 192.168.120.98 попадает в 3:0x62 (98 = 0x62), а зачем тогда ещё один матч делать ? Т.е. зачем нужна запись "match ip dst 192.168.120.98" ведь пакет и так уже попал в 3:0x62, может без матча будет работать ?

 

 

К сожалению, не обладаю очень уж глубокими познаниями в TC, но предполагаю следующие.

 

sbin/tc f a dev bond0.628 protocol ip parent ffff:0 prio 10 u32 ht 3:0x63: match ip dst 192.168.120.99 action police rate 5500Kbit burst 550K drop mtu 1500 flowid :12
sbin/tc f a dev bond0.628 protocol ip parent ffff:0 prio 10 u32 ht 3:0x63: match ip dst 192.168.100.99 action police rate 5500Kbit burst 550K drop mtu 1500 flowid :13

1 - без "match ip dst" банально не работает

2 - ht 3:0x63: -- хешь для последнего октета в ip адресе, а третий определяется по match ip dst.

[Стич]

Не совсем понял этот пример. последний октет адреса является ключом к хешу, т.е. ойпи 192.168.120.98 попадает в 3:0x62 (98 = 0x62), а зачем тогда ещё один матч делать ? Т.е. зачем нужна запись "match ip dst 192.168.120.98" ведь пакет и так уже попал в 3:0x62, может без матча будет работать ?

 

 

К сожалению, не обладаю очень уж глубокими познаниями в TC, но предполагаю следующие.

 

sbin/tc f a dev bond0.628 protocol ip parent ffff:0 prio 10 u32 ht 3:0x63: match ip dst 192.168.120.99 action police rate 5500Kbit burst 550K drop mtu 1500 flowid :12
sbin/tc f a dev bond0.628 protocol ip parent ffff:0 prio 10 u32 ht 3:0x63: match ip dst 192.168.100.99 action police rate 5500Kbit burst 550K drop mtu 1500 flowid :13

1 - без "match ip dst" банально не работает

2 - ht 3:0x63: -- хешь для последнего октета в ip адресе, а третий определяется по match ip dst.

 

Уважаемые, хэш таблицы и фильтры прекрасно описаны там https://habrahabr.ru/post/138463/

Про хэш таблицы и tc filter action police уже было сказано до Вас, читайте тему перед тем как постить.

Edited March 7, 2017 by Стич