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

Убрать задержку ICMP при шейпинге на Linux

В данный момент реализовал шейпинг следующим образом:

 

/sbin/tc qdisc add dev eth0 root handle 1: htb default ffff r2q 1

/sbin/tc class add dev eth0 parent 1:0 classid 1:3 htb rate 256kbit burst 4k prio 1

/sbin/tc qdisc add dev eth0 parent 1:3 handle 3: sfq perturb 10 quantum 1500

/sbin/tc filter add dev eth0 parent 1:0 protocol ip prio 3 u32 match ip dst 172.30.82.114 flowid 1:3

#default

/sbin/tc class add dev eth0 parent 1:0 classid 1:ffff htb rate 100mbit burst 4k prio 3

/sbin/tc qdisc add dev eth0 parent 1:ffff handle ffff: sfq perturb 10 quantum 1500

 

Входящий трафик ограничивается как нужно, но есть проблема, когда клиент качает что нибудь задержки пинга вырастают с 60 до 600мс

каким правилом можно пустить ICMP трафик от клиента мимо шейпера?

Share this post


Link to post
Share on other sites

/sbin/tc filter add dev eth0 parent 1:0 protocol ip prio 2 u32 match ip dst 172.30.82.114 match protocol 1 0xff flowid 1:ffff

 

Типа такого

Share this post


Link to post
Share on other sites

Для начала, можно просто попробовать краевую дисциплину prio вместо sfq. Можно посоздавать деревья из классов HTB, как описано здесь http://luxik.cdi.cz/~devik/qos/htb/manual/userg.htm , но это сильно усложнит правила.

 

Также можно перенаправить ICMP в какой-то класс с более толстой полосой. Вот пример для перенаправления ICMP в класс ffff.

tc filter add dev eth0 parent 1:0 protocol ip prio 1 u32 match ip protocol 1 0xff flowid 1:ffff

и такое же правило на другом интерфейсе. У этого фильтра prio должен быть меньше, чем у тех, что классифицируют по IP.

Edited by photon

Share this post


Link to post
Share on other sites
пустить ICMP трафик от клиента мимо шейпера?
Напомню что при таком раскладе (исходящий ICMP без шейпера) участники ботнетов флудящих через ICMP получат нелимитированную скорость и будут:

а) сильно загружать ваш канал в инет.

б) сильно загружать канал к атакуемому хосту.

Share this post


Link to post
Share on other sites
Напомню что при таком раскладе (исходящий ICMP без шейпера) участники ботнетов флудящих через ICMP

С этим до введения шейпера справлялся snort.

Share this post


Link to post
Share on other sites

А кто какой краевой qdisc использует в нарезке каналов клиентам? Задача: при качающем у клиента торренте сделать более-менее юзабельным веб. Сейчас у меня sfq, но не устраивает как оно торрент+веб раскидывает: качающий в полку торрент убивает весь трафик, веб еле шевелится. Пробовал prio - с торрентом ицмп бегает замечательно, а вот веб просто умирает так, что достучаться до сайтов просто невозможно. Сейчас еще red тестирую: веб с торрентом уживаются заметно лучше чем с sfq, но ицмп просто дропается периодически, судя по всему так же будет вести себя и udp-трафик. Вот теперь стою перед выбором - ставить red или оставлять sfq

Share this post


Link to post
Share on other sites

А кто какой краевой qdisc использует в нарезке каналов клиентам?

На шейпере нужно использовать то, что создает наименьшую нагрузку, например pfifo или red при включенном ECN. Если есть желание, то приоритезацию некоторых типов трафика (VoIP, HTTP), можно делать уже после шейпера на border gateway. Трафик, которым пользователь забивает свою полосу пропускания -- это его дело, он сам и должен думать о приоритезации и ограничениях. Кроме того, все вменяемые программы для скачивания файлов и torrent-клиенты имеют возможность ограничивать скорость. Незачем морочить себе голову, если вопрос всего лишь в настройке со стороны пользователя.

Edited by photon

Share this post


Link to post
Share on other sites

ну это само собой, просто хотелось бы немного уменьшить число звонков типа "а чего у меня так медленно интернет открывается, я тут всего лишь торрент качаю" :) то есть использовать red имеет смысл? ecn это что?

Share this post


Link to post
Share on other sites

ну это само собой, просто хотелось бы немного уменьшить число звонков типа "а чего у меня так медленно интернет открывается, я тут всего лишь торрент качаю" :) то есть использовать red имеет смысл? ecn это что?

Вопрос, на самом деле, в технической грамотности абонента. Надо составить FAQ, где популярно объяснить, что де канал не резиновый и нужно ограничивать полосу пропускания в торрент-клиентах до величины минимум 90% от номинальной в обе стороны. Кстати, TCP ACK-пакеты тоже нужно с повышенным приоритетом пускать. ECN (explicit congestion notification) -- это уведомление о перегрузке, которое заставляет отправителя уменьшать окно отправки TCP-пакетов. В параметрах qdisc red есть опция для этих дел: http://linux.die.net/man/8/tc-red. В теории это хорошо, но проблема в том, что в Windows ECN по умолчанию выключен.

Edited by photon

Share this post


Link to post
Share on other sites

хм... потестировал red, лимит 500 кбит, торрент качает в полку, веб гораздо живее на глаз, нежели с sfq, да и спидтест пошустрее показывает, где то в районе 70

Share this post


Link to post
Share on other sites

использую sfq, на абонента - два класса - в одном пинги и ack, в втором остальной траффик... Абоненты не жалуются, закачки никому не мешают... Идею шейпера взял в скриптах асмодеуса

Share this post


Link to post
Share on other sites

martin74, впн? на ppp девайсах шейпер вешаешь? у меня то один шейпер, без впна

Share this post


Link to post
Share on other sites
использую sfq, на абонента - два класса - в одном пинги и ack, в втором остальной траффик... Абоненты не жалуются, закачки никому не мешают... Идею шейпера взял в скриптах асмодеуса

А можно примерчик, если не сложно?

Share this post


Link to post
Share on other sites

Спасибо! Переделал под себя. Раньше у меня была приоретизация только RDP и SIP, сейчас добавил ack, буду тестировать.

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