Jump to content
Калькуляторы

tc c хеш фильтрами использование хеш фильтров в одной подсети

Здравствуйте,

Решил оптимизировать свой шейпер и переписать правила для фильтров с использованием хеша. Трафик режется в пределах одной подсети, например 10.10.80.0/24.

И вместо 256 линейныйх правил (для каждого IP) хочу заменить хеш фильтрами. Прочитал что нашел про хеш фильтры и наткнулся на статью http://habrahabr.ru/blogs/sysadm/89002/ В ней меня заинтересовали правила для 13 хеш таблицы, вот одно из них:

 

/sbin/tc filter add dev eth1 parent 1:0 protocol ip prio 1 u32 ht 13:2: match ip dst 192.168.2.2/32 match ip protocol 1 0xff flowid 1:11

 

Скажите, пожалуйста, в принципе, зачем здесь ещё делать match для 192.168.2.2/32? Ведь по идее сюда (согласно ht 13:2) уже попадет пакет который имеет IP 192.168.2.2.

 

В этой статье http://ace-host.stuart.id.au/russell/files/tc/doc/cls_u32.txt как я понял, на похожий вопрос отвечают мол так: что это нужно если у тебя больше одной подсети и сюды может попасть из другой подсети.

Но не уверен что правильно понял. Просто конечная цель моя заменить это правило (match ip dst 192.168.2.2/32) другим – проверкой маркированного трафика в рамках этого IP. Т.е вместо match хочу сделать fw.

Share this post


Link to post
Share on other sites

Вот хороший пример по хэш-фильтрам: http://www.hazard.maks.net/blog/index.php?op=Default&Date=200802&blogId=1

 

/sbin/tc filter add dev eth1 parent 1:0 protocol ip prio 1 u32 ht 13:2: match ip dst 192.168.2.2/32 match ip protocol 1 0xff flowid 1:11

 

Скажите, пожалуйста, в принципе, зачем здесь ещё делать match для 192.168.2.2/32? Ведь по идее сюда (согласно ht 13:2) уже попадет пакет который имеет IP 192.168.2.2.

Затем, что там стоит flowid 1:11, это номер класса обслуживания (очереди), в которую попадает трафик для IP 192.168.2.2. В других фильтрах номер очереди не фигурирует.

 

В этой статье http://ace-host.stuart.id.au/russell/files/tc/doc/cls_u32.txt как я понял, на похожий вопрос отвечают мол так: что это нужно если у тебя больше одной подсети и сюды может попасть из другой подсети.

Но не уверен что правильно понял. Просто конечная цель моя заменить это правило (match ip dst 192.168.2.2/32) другим – проверкой маркированного трафика в рамках этого IP. Т.е вместо match хочу сделать fw.

Зачем что-то маркировать на шейпере?

Share this post


Link to post
Share on other sites

Вот хороший пример по хэш-фильтрам: http://www.hazard.maks.net/blog/index.php?op=Default&Date=200802&blogId=1

 

/sbin/tc filter add dev eth1 parent 1:0 protocol ip prio 1 u32 ht 13:2: match ip dst 192.168.2.2/32 match ip protocol 1 0xff flowid 1:11

 

Скажите, пожалуйста, в принципе, зачем здесь ещё делать match для 192.168.2.2/32? Ведь по идее сюда (согласно ht 13:2) уже попадет пакет который имеет IP 192.168.2.2.

Затем, что там стоит flowid 1:11, это номер класса обслуживания (очереди), в которую попадает трафик для IP 192.168.2.2. В других фильтрах номер очереди не фигурирует.

 

В этой статье http://ace-host.stuart.id.au/russell/files/tc/doc/cls_u32.txt как я понял, на похожий вопрос отвечают мол так: что это нужно если у тебя больше одной подсети и сюды может попасть из другой подсети.

Но не уверен что правильно понял. Просто конечная цель моя заменить это правило (match ip dst 192.168.2.2/32) другим – проверкой маркированного трафика в рамках этого IP. Т.е вместо match хочу сделать fw.

Зачем что-то маркировать на шейпере?

 

1) Ну в flowid можно направлять и не только по match (u32), а и по марке через fw. Вот например:

tc filter add dev eth0 parent 1:0 protocol ip prio 90 handle 7 fw classid 1:10

(flowid и classid - одно и тоже. Т.е и для u32 мы можем использовать classid вместо flowid).

 

2) Ничего не маркируется на шейпере (да он этого и не умеет). Трафик перед попаданием на шейпер маркается в iptables.

Просто существует определенный вид трафика в сети. Мы его отлавливаем, маркируем и подаем на шейпер. И в рамках родительского класса для каждого абонента он режется до определенной скорости. Т.е есть родительский класс для абонента и в нем два листовых (маркированный, и весь остальной). Это уже реализованно, но с использованием линейных правил, а теперь хочется переделать это через хеш.

Share this post


Link to post
Share on other sites

Протестировал, как оказалось, действительно правило match ip dst 192.168.2.2/32 не обязательно. Ставил вместо этого match ip dst 0.0.0.0/0 и трафик только для 192.168.2.2 идет именно сюда.

Для маркированных пакетов, вместо fw можно использовать u32 match mark.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this