mentis Опубликовано 16 июня, 2009 · Жалоба В данный момент реализовал шейпинг следующим образом: /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 трафик от клиента мимо шейпера? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nuclearcat Опубликовано 16 июня, 2009 · Жалоба /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 Типа такого Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
photon Опубликовано 16 июня, 2009 (изменено) · Жалоба Для начала, можно просто попробовать краевую дисциплину 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. Изменено 16 июня, 2009 пользователем photon Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
mentis Опубликовано 16 июня, 2009 · Жалоба Спасибо, буду изучать. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
RomanCh Опубликовано 16 июня, 2009 · Жалоба пустить ICMP трафик от клиента мимо шейпера?Напомню что при таком раскладе (исходящий ICMP без шейпера) участники ботнетов флудящих через ICMP получат нелимитированную скорость и будут: а) сильно загружать ваш канал в инет. б) сильно загружать канал к атакуемому хосту. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
mentis Опубликовано 16 июня, 2009 · Жалоба Напомню что при таком раскладе (исходящий ICMP без шейпера) участники ботнетов флудящих через ICMP С этим до введения шейпера справлялся snort. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Max P Опубликовано 28 июня, 2009 · Жалоба А кто какой краевой qdisc использует в нарезке каналов клиентам? Задача: при качающем у клиента торренте сделать более-менее юзабельным веб. Сейчас у меня sfq, но не устраивает как оно торрент+веб раскидывает: качающий в полку торрент убивает весь трафик, веб еле шевелится. Пробовал prio - с торрентом ицмп бегает замечательно, а вот веб просто умирает так, что достучаться до сайтов просто невозможно. Сейчас еще red тестирую: веб с торрентом уживаются заметно лучше чем с sfq, но ицмп просто дропается периодически, судя по всему так же будет вести себя и udp-трафик. Вот теперь стою перед выбором - ставить red или оставлять sfq Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
photon Опубликовано 28 июня, 2009 (изменено) · Жалоба А кто какой краевой qdisc использует в нарезке каналов клиентам? На шейпере нужно использовать то, что создает наименьшую нагрузку, например pfifo или red при включенном ECN. Если есть желание, то приоритезацию некоторых типов трафика (VoIP, HTTP), можно делать уже после шейпера на border gateway. Трафик, которым пользователь забивает свою полосу пропускания -- это его дело, он сам и должен думать о приоритезации и ограничениях. Кроме того, все вменяемые программы для скачивания файлов и torrent-клиенты имеют возможность ограничивать скорость. Незачем морочить себе голову, если вопрос всего лишь в настройке со стороны пользователя. Изменено 28 июня, 2009 пользователем photon Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Max P Опубликовано 28 июня, 2009 · Жалоба ну это само собой, просто хотелось бы немного уменьшить число звонков типа "а чего у меня так медленно интернет открывается, я тут всего лишь торрент качаю" :) то есть использовать red имеет смысл? ecn это что? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
photon Опубликовано 28 июня, 2009 (изменено) · Жалоба ну это само собой, просто хотелось бы немного уменьшить число звонков типа "а чего у меня так медленно интернет открывается, я тут всего лишь торрент качаю" :) то есть использовать red имеет смысл? ecn это что? Вопрос, на самом деле, в технической грамотности абонента. Надо составить FAQ, где популярно объяснить, что де канал не резиновый и нужно ограничивать полосу пропускания в торрент-клиентах до величины минимум 90% от номинальной в обе стороны. Кстати, TCP ACK-пакеты тоже нужно с повышенным приоритетом пускать. ECN (explicit congestion notification) -- это уведомление о перегрузке, которое заставляет отправителя уменьшать окно отправки TCP-пакетов. В параметрах qdisc red есть опция для этих дел: http://linux.die.net/man/8/tc-red. В теории это хорошо, но проблема в том, что в Windows ECN по умолчанию выключен. Изменено 28 июня, 2009 пользователем photon Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Max P Опубликовано 29 июня, 2009 · Жалоба хм... потестировал red, лимит 500 кбит, торрент качает в полку, веб гораздо живее на глаз, нежели с sfq, да и спидтест пошустрее показывает, где то в районе 70 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
martin74 Опубликовано 29 июня, 2009 · Жалоба использую sfq, на абонента - два класса - в одном пинги и ack, в втором остальной траффик... Абоненты не жалуются, закачки никому не мешают... Идею шейпера взял в скриптах асмодеуса Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Max P Опубликовано 29 июня, 2009 · Жалоба martin74, впн? на ppp девайсах шейпер вешаешь? у меня то один шейпер, без впна Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
hiller Опубликовано 30 июня, 2009 · Жалоба использую sfq, на абонента - два класса - в одном пинги и ack, в втором остальной траффик... Абоненты не жалуются, закачки никому не мешают... Идею шейпера взял в скриптах асмодеуса А можно примерчик, если не сложно? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
martin74 Опубликовано 30 июня, 2009 · Жалоба http://abills.net.ua/wiki/doku.php/abills:...pppd_radattr:ru Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
hiller Опубликовано 30 июня, 2009 · Жалоба Спасибо! Переделал под себя. Раньше у меня была приоретизация только RDP и SIP, сейчас добавил ack, буду тестировать. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...