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

[mentis]

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

 

/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 трафик от клиента мимо шейпера?

[nuclearcat]

/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

 

Типа такого

[photon]

Для начала, можно просто попробовать краевую дисциплину 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 June 16, 2009 by photon

[mentis]

Спасибо, буду изучать.

[RomanCh]

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

Напомню что при таком раскладе (исходящий ICMP без шейпера) участники ботнетов флудящих через ICMP получат нелимитированную скорость и будут:

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

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

[mentis]

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

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

[Max P]

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

[photon]

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

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

Edited June 28, 2009 by photon

[Max P]

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

[photon]

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

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

Edited June 28, 2009 by photon

[Max P]

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

[martin74]

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

[Max P]

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

[hiller]

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

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

[martin74]

http://abills.net.ua/wiki/doku.php/abills:...pppd_radattr:ru

[hiller]

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