Поделитесь, кто знает:
Надо нарезать траффик, и тем самым ограничить юзеров. Но при этом есть такие юзеры, у которых должен быть повышенный приоритет и более толстый канал... Так вот, надо чтобы если эти крутые юзеры ничего не качают, то траффик для всех нарезался обычным способом, а если кто-то из них лезет в инет - то ужать остальных... Сиcтема FreeBSD 4.5
Если у кого есть идеи - шепните, плз!!!
>Поделитесь, кто знает:
>Надо нарезать траффик, и тем самым
>ограничить юзеров. Но при этом
>есть такие юзеры, у которых
>должен быть повышенный приоритет и
>более толстый канал... Так вот,
>надо чтобы если эти крутые
>юзеры ничего не качают, то
>траффик для всех нарезался обычным
>способом, а если кто-то из
>них лезет в инет -
>то ужать остальных... Сиcтема FreeBSD
>4.5
>Если у кого есть идеи -
>шепните, плз!!!
man ipfw
>man ipfw
В том то и дело, что либо я чего-то там не поняла, либо там pipe статичные получаются - мне надо, чтобы динамически менялся размер канала в зависимости от того есть ли пакеты от таких-то ip...
конечно статические
pipe <номер>
SQUID не подойдет?
>SQUID не подойдет?Если речь идеть об о всем трафике то сквид не подойдет
ipfw dummynet + набор скриптов
можно посмотреть еще и в сторону ipa
http://www.simon.org.ua/ipa/
>конечно статические
>pipe <номер>
И с чего ты взяла что они статичные...
в том то и дело что скриптом от рута можно их модифицировать т.е удалять добавлять...
>>конечно статические
>>pipe <номер>
>И с чего ты взяла что
>они статичные...
>в том то и дело что
>скриптом от рута можно их
>модифицировать т.е удалять добавлять...Так а как заставить этот скрипт от рута выполняться каждый раз когда пришел пакет с определенного адреса??? В ipfw я такого не видела
>Поделитесь, кто знает:
>Надо нарезать траффик, и тем самым
>ограничить юзеров. Но при этом
>есть такие юзеры, у которых
>должен быть повышенный приоритет и
>более толстый канал... Так вот,
>надо чтобы если эти крутые
>юзеры ничего не качают, то
>траффик для всех нарезался обычным
>способом, а если кто-то из
>них лезет в инет -
>то ужать остальных... Сиcтема FreeBSD
>4.5
>Если у кого есть идеи -
>шепните, плз!!!altq
bwman -однозначно... правда придётся по геморроится с gated , если честно так и не победил... и остановился на старом добром ipfw pipe
в ipfw есть слова queue, red, ...
так вроде с помощью тех волшебных слов задуманное можно сделать.
сам интересовался динамическим приоритетным шейпингом (сей проблемой), но man ipfw преодолеть до конца так и не смог, а здесь аналогичный вопрос задавал, так никто конкретно так и не помог :((
>в ipfw есть слова queue, red,
>...
>так вроде с помощью тех волшебных
>слов задуманное можно сделать.
>сам интересовался динамическим приоритетным шейпингом (сей
>проблемой), но man ipfw преодолеть
>до конца так и не
>смог, а здесь аналогичный вопрос
>задавал, так никто конкретно так
>и не помог :((Короче, если кому интересно: с ipa это работает точно, bwman и altq попробую.
немножко поподробнее можешь объяснить как выкрутилась ?спасибо
>немножко поподробнее можешь объяснить как выкрутилась
>?
>
>спасибоНу вообще-то тут все просто как обычно оказалось
Мне надо было, чтобы траффик ssh передавался без задержек (а то сидеть в mc и жать по клавише в минуту - скучно :)). Отдельный канал для него жалко... В итоге выкрутилась сначала так:У ipa в конфиге в секции rule {} есть секция limit {}, в которой можно прописать, что по истечении такого-то лимита (в байтах) выполнить то-то и се-то... То есть я туда просто прописала удаление старых pipe's и добавление новых. Но это не лучший способ, удалять на ходу...
Потом я поразбиралась с магическим словом queue в ipwf и в итоге все более-менее работает (на рабочей системе последний вариант еще не проверяла - юзеров жалко :)), но на локальном компе с ужатым траффиком все пашет.
Примерно написала следующее:
..................
# ужимаем FTP
ipfw add queue 10 tcp from any 20,21 to any 1024-65535 in via fxp0
ipfw add queue 20 tcp from any 1024-65535 to any 20,21 out via fxp0
ipfw add queue 10 tcp from any 1024-65535 to any 1024-65535 in via fxp0
ipfw add queue 20 tcp from any 1024-65535 to any 1024-65535 out via fxp0
ipfw queue 10 config weight 1 pipe 10
ipfw queue 20 config weight 1 pipe 20# И даем ssh полную свободу
ipfw add queue 50 tcp from any 22 to any 1024-65535 in via fxp0
ipfw add queue 60 tcp from any 1024-65535 to any 22 out via fxp0
ipfw queue 50 config pipe 10 weight 100
ipfw queue 60 config pipe 20 weight 100..................
# И сами пайпы
ipfw add pipe 10 tcp from any to any in via fxp0
ipfw pipe 10 config
ipfw add pipe 20 tcp from any to any out via fxp0
ipfw pipe 20 config
Ну и плюс остальной траффик прописала, кому какой приоритет.сэту :))
>>немножко поподробнее можешь объяснить как выкрутилась
>>?
>>
>>спасибо
>
>Ну вообще-то тут все просто как обычно оказалось
>Мне надо было, чтобы траффик ssh передавался без задержек (а то сидеть
>в mc и жать по клавише в минуту - скучно :)).
>Отдельный канал для него жалко... В итоге выкрутилась сначала так:
>
>У ipa в конфиге в секции rule {} есть секция limit {},
>в которой можно прописать, что по истечении такого-то лимита (в байтах)
>выполнить то-то и се-то... То есть я туда просто прописала удаление
>старых pipe's и добавление новых. Но это не лучший способ, удалять
>на ходу...
>
>Потом я поразбиралась с магическим словом queue в ipwf и в итоге
>все более-менее работает (на рабочей системе последний вариант еще не проверяла
>- юзеров жалко :)), но на локальном компе с ужатым траффиком
>все пашет.
>
>Примерно написала следующее:
>
>..................
>
># ужимаем FTP
>
>ipfw add queue 10 tcp from any 20,21 to any 1024-65535 in
>via fxp0
>ipfw add queue 20 tcp from any 1024-65535 to any 20,21 out
>via fxp0
>ipfw add queue 10 tcp from any 1024-65535 to any 1024-65535 in
>via fxp0
>ipfw add queue 20 tcp from any 1024-65535 to any 1024-65535 out
>via fxp0
>ipfw queue 10 config weight 1 pipe 10
>ipfw queue 20 config weight 1 pipe 20
>
># И даем ssh полную свободу
>
>ipfw add queue 50 tcp from any 22 to any 1024-65535 in
>via fxp0
>ipfw add queue 60 tcp from any 1024-65535 to any 22 out
>via fxp0
>ipfw queue 50 config pipe 10 weight 100
>ipfw queue 60 config pipe 20 weight 100
>
>..................
>
># И сами пайпы
>ipfw add pipe 10 tcp from any to any in via fxp0
>
>ipfw pipe 10 config
>ipfw add pipe 20 tcp from any to any out via fxp0
>
>ipfw pipe 20 config
>
>
>Ну и плюс остальной траффик прописала, кому какой приоритет.
>
>сэту :))Делал я так когдато.
Скажем не очень помогает.
Пользователи заваливают канал даже не напрягаясь.
Насколько я понимаю, это происходит из-за асиметрии входящего и выходящего трафика.
Приходилось непропорционально зарезать выходящий трафик.
Только в таком случае помогало.
Было бы интересно найти shaper который бы учитывал tcp окно.Если кто знает где есть документация что это за очереди такие RED, GRED и как они работают, кинти ссылку плиз.
>Приходилось непропорционально зарезать выходящий трафик.
>Только в таком случае помогало.
>Было бы интересно найти shaper который бы учитывал tcp окно.
>
>Если кто знает где есть документация что это за очереди такие
>RED, GRED и как они работают, кинти ссылку плиз.Да, похоже, так и придется...
А RED и GRED - это не очереди... Это как очередь пакеты отбрасывать будет
>>Приходилось непропорционально зарезать выходящий трафик.
>>Только в таком случае помогало.
>>Было бы интересно найти shaper который бы учитывал tcp окно.
>>
>>Если кто знает где есть документация что это за очереди такие
>>RED, GRED и как они работают, кинти ссылку плиз.
>
>Да, похоже, так и придется...
>А RED и GRED - это не очереди... Это как очередь пакеты
>отбрасывать будет
potom, IMHO, wazno naskolko velik kanal, esli on malenkij, to i delit nechego.
I kak organizovan kanal kotoryj nado delit.U menja bylo soedinenie cherez ethernet kotoryj rubilsa u provajdera temze ipfw. ja vot i pytalsa porubit sebja tak chtob i sebja ne ograbit i chtob ono chtoto ogranichivalo. no vseobshego schastja tak i ne dobilsa.
>>>Приходилось непропорционально зарезать выходящий трафик.
>>>Только в таком случае помогало.
>>>Было бы интересно найти shaper который бы учитывал tcp окно.
>>>
>>>Если кто знает где есть документация что это за очереди такие
>>>RED, GRED и как они работают, кинти ссылку плиз.
>>
>>Да, похоже, так и придется...
>>А RED и GRED - это не очереди... Это как очередь пакеты
>>отбрасывать будет
>
>
>potom, IMHO, wazno naskolko velik kanal, esli on malenkij, to i delit
>nechego.
>I kak organizovan kanal kotoryj nado delit.
>
>U menja bylo soedinenie cherez ethernet kotoryj rubilsa u provajdera temze ipfw.
>ja vot i pytalsa porubit sebja tak chtob i sebja ne
>ograbit i chtob ono chtoto ogranichivalo. no vseobshego schastja tak i
>ne dobilsa.Насчет асимметрии канала - это верно. Я нарезаю оба трафика - и входящий, и выходящий. Так как при желании и намерении юзеры могут завалить канал, скачивая в пустоту все что угодно. Потом есть резон, когда у юзера вэб сервер стоит, например. К нему идет 1-2 кб/с, а обратно - как со спутника...И все в выделенку. А потом ищешь, где же течет... Правда правил становится в 2 раза больше, но зато эффект есть...
Люди! Ну это уже мистика какая-то!
Нарезала и входящий и исходящий траффик. Входящему 90%, исходящему - остальное. И в ту и в другую сторону очереди с приоритетами. SSH везде имеет высший приоритет. Остальное - низший. И все равно ssh безбожно тормозит :(((
Мало того, для эксперимента отдала лично ssh'у 64К!!! И не чирикает. По счетчикам ssh траффика - кот наплакал...
Есть у кого-нибудь еще мысли, как это все же вылечить? И чем он такой особенный, этот ssh?
>Люди! Ну это уже мистика какая-то!
>Нарезала и входящий и исходящий траффик. Входящему 90%, исходящему - остальное. И
>в ту и в другую сторону очереди с приоритетами. SSH везде
>имеет высший приоритет. Остальное - низший. И все равно ssh безбожно
>тормозит :(((
>Мало того, для эксперимента отдала лично ssh'у 64К!!! И не чирикает. По
>счетчикам ssh траффика - кот наплакал...
>Есть у кого-нибудь еще мысли, как это все же вылечить? И чем
>он такой особенный, этот ssh?man ipfw
>>Люди! Ну это уже мистика какая-то!
>>Нарезала и входящий и исходящий траффик. Входящему 90%, исходящему - остальное. И
>>в ту и в другую сторону очереди с приоритетами. SSH везде
>>имеет высший приоритет. Остальное - низший. И все равно ssh безбожно
>>тормозит :(((
>>Мало того, для эксперимента отдала лично ssh'у 64К!!! И не чирикает. По
>>счетчикам ssh траффика - кот наплакал...
>>Есть у кого-нибудь еще мысли, как это все же вылечить? И чем
>>он такой особенный, этот ssh?
>
>man ipfwА мне кажется, что дело здесь не в ipfw. SSH тормозит часто сам по себе. У меня Фря 4.3 в локалке стоит. Так иногда бегат как часы, а иногда приглашения на пароль почти минуту ждешь. Ему что же - 100 Мбит не хватает? Здесь что-то в самой машине тормозит, хотя загрузки никакой - даже на процент не набирается...
>>>Люди! Ну это уже мистика какая-то!
>>>Нарезала и входящий и исходящий траффик. Входящему 90%, исходящему - остальное. И
>>>в ту и в другую сторону очереди с приоритетами. SSH везде
>>>имеет высший приоритет. Остальное - низший. И все равно ssh безбожно
>>>тормозит :(((
>>>Мало того, для эксперимента отдала лично ssh'у 64К!!! И не чирикает. По
>>>счетчикам ssh траффика - кот наплакал...
>>>Есть у кого-нибудь еще мысли, как это все же вылечить? И чем
>>>он такой особенный, этот ssh?
>>
>>man ipfwесли еще не поняла, в чем дело, я скажу откровенней --
man ipfw:"...
net.inet.ip.fw.one_pass: 1
When set, the packet exiting from the dummynet(4) pipe is not
passed though the firewall again. Otherwise, after a pipe
action, the packet is reinjected into the firewall at the next
rule.
..."и еще раз -- читайте маны, ибо их не от балды пишут.
>А мне кажется, что дело здесь не в ipfw. SSH тормозит часто
>сам по себе. У меня Фря 4.3 в локалке стоит. Так
>иногда бегат как часы, а иногда приглашения на пароль почти минуту
>ждешь. Ему что же - 100 Мбит не хватает? Здесь что-то
>в самой машине тормозит, хотя загрузки никакой - даже на процент
>не набирается...4.6 на дворе...
>если еще не поняла, в чем дело, я скажу откровенней --
>man ipfw:
>
>"...
> net.inet.ip.fw.one_pass: 1
> When set, the packet exiting from
>the dummynet(4) pipe is not
> passed though the firewall again. Otherwise,
>after a pipe
> action, the packet is reinjected into
>the firewall at the next
> rule.
>..."
>
>и еще раз -- читайте маны, ибо их не от балды пишут.
>
>
>>А мне кажется, что дело здесь не в ipfw. SSH тормозит часто
>>сам по себе. У меня Фря 4.3 в локалке стоит. Так
>>иногда бегат как часы, а иногда приглашения на пароль почти минуту
>>ждешь. Ему что же - 100 Мбит не хватает? Здесь что-то
>>в самой машине тормозит, хотя загрузки никакой - даже на процент
>>не набирается...
>
>4.6 на дворе...А дело не в этом, ибо маны я читаю и net.inet.ip.fw.one_pass: 1 установлено было через 10 секунд после прочтения об этом %)))
И уж если зашел об этом разговор - то ман у ipfw (по крайней мере та часть, которая описывает непосредственно желаемое) явно не рассчитаны на понимание их после прочтения %). Поэтому кроме манов пришлось еще и инет "полистать" и препода по сетям замучить на предмет очередей и иже с ними %)
И еще кстати - net.inet.ip.fw.one_pass=1, насколько я помню (сейчас в линухе, фри рядом нет) по умолчанию такое значение имеет. %)
>>если еще не поняла, в чем дело, я скажу откровенней --
>>man ipfw:
>>
>>"...
>> net.inet.ip.fw.one_pass: 1
>> When set, the packet exiting from
>>the dummynet(4) pipe is not
>> passed though the firewall again. Otherwise,
>>after a pipe
>> action, the packet is reinjected into
>>the firewall at the next
>> rule.
>>..."
>>
>>и еще раз -- читайте маны, ибо их не от балды пишут.
[snip]>А дело не в этом, ибо маны я читаю и net.inet.ip.fw.one_pass: 1
>установлено было через 10 секунд после прочтения об этом %)))без знаний английского в UN*X лучше не лезть...
значение, которое нужно было использовать в твоем случае, никак не 1,
а наоборот -- 0. Только в этом случае, следующие правила в списке firewall'а имеют шанс быть выполнены.
>И уж если зашел об этом разговор - то ман у ipfw
>(по крайней мере та часть, которая описывает непосредственно желаемое) явно не
>рассчитаны на понимание их после прочтения %). Поэтому кроме манов пришлось
>еще и инет "полистать" и препода по сетям замучить на предмет
>очередей и иже с ними %)вероятно, стоить замучить препода по english?...
>вероятно, стоить замучить препода по english?...В моей ситуации было необходимо установить net.inet.ip.fw.one_pass в 1, ибо кроме ipfw pipe и ipfw queue никаких более правил не использовалось.
Поэтому мне на фиг не надо было, чтобы после dummynet пакеты продолжали проверяться ipfw непосредственно... И вообще эта проблема уже не актуальна, как и Ваши агрессивные высказывания по поводу нее, так как сама проблема успешно решена, а женоненавистников мне и на работе хватает. Ничего личного.
>Поэтому мне на фиг не надо было, чтобы после dummynet пакеты продолжали
>проверяться ipfw непосредственно... И вообще эта проблема уже не актуальна, как
>и Ваши агрессивные высказывания по поводу нее, так как сама проблема
>успешно решена, а женоненавистников мне и на работе хватает. Ничего личного.
>sorry, не хотел разбудить в вас такие чувства. отлично, что проблема успешно решена. :-)
>... И вообще эта проблема уже не >актуальна, как сама проблема
> успешно решенане могли бы вы поделиться секретом как вам удалось упешно нарезать трафик ?
Спасибо
>Поделитесь, кто знает:
>Надо нарезать траффик, и тем самым ограничить юзеров. Но при этом есть
>такие юзеры, у которых должен быть повышенный приоритет и более толстый
>канал... Так вот, надо чтобы если эти крутые юзеры ничего не
>качают, то траффик для всех нарезался обычным способом, а если кто-то
>из них лезет в инет - то ужать остальных... Сиcтема FreeBSD
>4.5
>Если у кого есть идеи - шепните, плз!!!
А ты золотка в /etc/hosts вписала хосты с которых ходить будешь если это в локалке?...
>А ты золотка в /etc/hosts вписала хосты с которых ходить будешь если
>это в локалке?...Это не в локалке... В локалке оно не тормозит...
И потом, даже если пропишу, быстрее то с чего ему быть?Короче, тут в книге "Брандмауэры в Линукс" такое вычитала (цитирую):
"... Соединение устанавливается по инициативе клиента; клиент использует непривилегированный порт и обращается к серверу через порт 22. Сервер порождает новый процесс для поддержки текущего соединения, а клиент изменяет используемый порт на порт, номер которого лежит в диапазоне 513-1023..."
Но это вроде в настройках указывается ssh клиента, и по умолчанию там UsePrivilegedPort=no ...
>>А ты золотка в /etc/hosts вписала хосты с которых ходить будешь если
>>это в локалке?...
>
>Это не в локалке... В локалке оно не тормозит...
>И потом, даже если пропишу, быстрее то с чего ему быть?
>
>Короче, тут в книге "Брандмауэры в Линукс" такое вычитала (цитирую):
>
>"... Соединение устанавливается по инициативе клиента; клиент использует непривилегированный порт и обращается
>к серверу через порт 22. Сервер порождает новый процесс для поддержки
>текущего соединения, а клиент изменяет используемый порт на порт, номер которого
>лежит в диапазоне 513-1023..."
>
>Но это вроде в настройках указывается ssh клиента, и по умолчанию там
>UsePrivilegedPort=no ...man netstat
>Поделитесь, кто знает:
>Надо нарезать траффик, и тем самым ограничить юзеров. Но при этом есть
>такие юзеры, у которых должен быть повышенный приоритет и более толстый
>канал... Так вот, надо чтобы если эти крутые юзеры ничего не
>качают, то траффик для всех нарезался обычным способом, а если кто-то
>из них лезет в инет - то ужать остальных... Сиcтема FreeBSD
>4.5
>Если у кого есть идеи - шепните, плз!!!
ATM :-)
>>Поделитесь, кто знает:
>>Надо нарезать траффик, и тем самым ограничить юзеров. Но при этом есть
>>такие юзеры, у которых должен быть повышенный приоритет и более толстый
>>канал... Так вот, надо чтобы если эти крутые юзеры ничего не
>>качают, то траффик для всех нарезался обычным способом, а если кто-то
>>из них лезет в инет - то ужать остальных... Сиcтема FreeBSD
>>4.5
>>Если у кого есть идеи - шепните, плз!!!
>
>http://www.csl.sony.co.jp/person/kjc/software.html
Ну а уж CBQ нстраивается нормально :)
для динамики (bounded | isolated)