Daniel Hartmeier, автор пакетного фильтра pf, созданного для OpenBSD, подробно поясняет (http://www.bsdforums.org/forums/showthread.php?t=36706), как работают системы лимитирования пропускной способности и почему ALTQ может гарантированно ограничивать и приоритезировать только отправляемый в заданный сетевой интерфейс трафик, и какие существуют решения для контроля входящего трафика (управление TCP потоком и шейпер на два интерфейса в системе).URL: http://www.bsdforums.org/forums/showthread.php?t=36706
Новость: http://www.opennet.me/opennews/art.shtml?num=6481
Это не ответ "почему ALTQ работает только с исходящим трафиком", это рассказ о том, что иногда фильтровать входящий трафик бессмысленно, и поэтому лень заморачиваться на написание такой фильтрации, хотя иногда она полезна.
Гы, а что мешает благородному Дону шейпить исходящий траффик на _внутреннем_ интф. ??? О чем в статье кстати и написано ?
>Гы, а что мешает благородному Дону шейпить исходящий траффик на _внутреннем_ интф.
>??? О чем в статье кстати и написано ?А если машина не шлюз, а сервер, т.е. конечная точка трафика ? Прикажите еще один сервер для шейпинга ставить ? В этом случае от простейшего UDP/ICMP/TCPSYN флуда никакой шейпер не спасет.
>А если машина не шлюз, а сервер, т.е. конечная точка трафика ? Прикажите >еще один сервер для шейпинга ставить ?
вот именно, для этой цели какой-нить 586 в любой организации всегда найдется.
>>А если машина не шлюз, а сервер, т.е. конечная точка трафика ? Прикажите >еще один сервер для шейпинга ставить ?
>вот именно, для этой цели какой-нить 586 в любой организации всегда найдется.Это если сам сервер для "каких-нибудь целей", т.е. простой не важен. Для серверов выполняющих конкретные задачи лишнее звено добавлять тразвомыслящий администратор не станет. Этот 586 сведет на нет надежность всей системы, займет драгоценное место в стойке, будет требовать дополнительных мощностей бесперебойников.
оборони меня создатель от так мыслящих админов. Аминь.
Что не так? Я тоже гавно всякое на трассы не согласен ставить.
Бррр, а причем здесь рваные голоши ???? грамотный флуд забъет тебе канал по любому.
Эт прости меня уже сетевой вандализм направленый на DoS и от него придется защищаться емного другими средствами, можно темже Snort&&snortsam
Народ не хочет понять, что ALTQ - это не шейпер, а менеджер очередей физических интерфейсов. На входящем трафике очередей нет, так как если трафик попадает в драйвер, то он уже принят. ALTQ сдесь ну ничего не может сделать, не той системы граната. Хочется полисинга входящего трафика - используйте dummynet.
Если Вам оно так надо (заморачиваться входящим трафиком), почему бы Вам не переписать ALTQ, а то видите ли, сами "мы" ничего не сделали, зато можем критиковать и обвинять выдающихся людей в лени....
опечатка - "переписать не ALTQ, а PF"
ALTQ - это часть проекта KAME и было портировано в PF
Про дропанье пакетов и DoS - это все понятно. Только шейпинг входящего траффика часто нужен для tcp клиента именно_на_этой_машине. Очередь для входящих пакетов совсем не сложно сделать, это действительно лень, причем совсем непонятная.А что касается `переписать ALTQ', умажаемый Ale - это идите на с такими заявлениями, ибо что делают другие люди для сообщества вы понятия не имеете, а переписывать ALTQ - дело DH, а не их.
>Про дропанье пакетов и DoS - это все понятно. Только шейпинг входящего >траффика часто нужен для tcp клиента именно_на_этой_машине. Очередь для >входящих пакетов совсем не сложно сделать, это действительно лень, причем >совсем непонятная.Эээээ, простите что за клиент может проживать на FW для которого надо шейпить тарафик ???
(примерный ответ я конечно знаю, но также знаю как это сделать по другому, не менее красиво :-Р )
> Только шейпинг входящего траффика часто нужен...
и причем тут шейпинг?> Очередь для входящих пакетов совсем не сложно сделать...
т.е. предыдущий роутер отсортировал и приоритизировал свой трафик, а ваш на входе переделает по-своему? А если каждый маршрутизатор будет очередь перелопачивать на входе по-своему, кому будет щастье?
>А что касается 'переписать ALTQ', умажаемый Ale - это идите на с такими >заявлениями, ибо что делают другие люди для сообщества вы понятия не >имеете, а переписывать ALTQ - дело DH, а не их.
To Storm
интернет дал таким как вы безграничные возможности послать безнаказанно человека, который, возможно, имеет ученую степень, старше вас по возрасту, и совершенно не знаком с вами.
продолжайте в том же духе...
Вам я, в свою очередь, разрешаю и далее разбрасываться такими заявлениями как `сами "мы" ничего не сделали'.
Народ. :) Ну что вы пургу все гоните?-)1. Шейпить входящий траффик невозможно. Запомните это раз и навсегда. Шейпинг -- управление загрузкой физического канала. И хоть ты удропайся входящие пакеты -- если тебе их с другой стороны шлют, канал всё равно будет на 100% загружен. :)
2. Если под фразой "входящий траффик" понимается, к примеру, траффик по входящему дейта-каналу FTP-сессии, так его вполне можно зашейпить.
Неужели никому не пришла в голову светлая мысль шейпить выход этого соединения? Или кто-то плохо помнит, что ALTQ вносит _задержки_ в прохождение пакетов, а TCP PUSH'и не будут ехать быстрее, чем в обратную сторону едут TCP ACK'и?-) TCP -- протокол с flow control'ем, слава КПСС.
И, кстати, именно из-за этого не имеет смысла делать спутниковые каналы более скоростными, чем 2 МБит/сек -- TCP через геостационарный спутник со скоростью, большей, чем 1 МБит/сек не работает.Можете посчитать сами -- скорость TCP-потока -- 1 окно в round-trip time линка. Высота геостационарной орбиты -- около 35 тысяч километров. Пренебрегая примерно в 15 раз меньшим основанием треугольника, с хорошей точностью можно считать, что свет проходит 70 тысяч километров при передаче пакета. Скорость света -- 300 тысяч км/сек. Итого -- получаем 230 миллисекунд в одну сторону. RTT - 460 миллисекунд. Грубо -- полсекунды (с учётом нашего приближения). При окне в 64 килобайта получаем скорость 128 килобайт в секунду -- примерно 1 мегабит/сек. :)
Что есть тыщщу раз проверено (спросите у своих друзей со спутниковыми каналами). А вы говорите, не зашейпится. ;)
>приближения). При окне в 64 килобайта получаем скорость 128 килобайт в
>секунду -- примерно 1 мегабит/сек. :)По 1 Мб на каждую TCP сессию. Запустил многопоточную качалку и доволен :-)
Ограничить число сессий по ИП
>Ограничить число сессий по ИП
за такое полагается канделябром :)
>>Ограничить число сессий по ИП
>за такое полагается канделябром :)
just try it!
Ежели пров черным по белому пишет что вот, держите анлим за ваши деньги, но шобы мне канал не сажали вот вам 15 TCP сессий и ешьте их как хотите.
Интересно кому канделябром в таком или похожем раскладе?
>>за такое полагается канделябром :)
>Ежели пров черным по белому пишет что вот, держите анлим за ваши
>деньги, но шобы мне канал не сажали вот вам 15 TCP
>сессий и ешьте их как хотите.
>Интересно кому канделябром в таком или похожем раскладе?Смотря какие деньги. Если так, как у меня - полная халява - то я закрою глаза и на лимит сессий, и на негарантированную полосу. А если кто сурьезные деньги плОтит, а ему на мегабит 100 сессий дают... И ведь я знаю таких! При этом купленный мегабит оборачивается в 700-800 кбит в пиках, и 200-300 кбит среднего в долгосрочке.
Тут не канделябром, тут топором надо. Меж рогов.
>И, кстати, именно из-за этого не имеет смысла делать спутниковые каналы более
>скоростными, чем 2 МБит/сек -- TCP через геостационарный спутник со скоростью,
>большей, чем 1 МБит/сек не работает.
>
>Можете посчитать сами -- скорость TCP-потока -- 1 окно в round-trip time
>линка. Высота геостационарной орбиты -- около 35 тысяч километров. Пренебрегая примерно
>в 15 раз меньшим основанием треугольника, с хорошей точностью можно считать,
>что свет проходит 70 тысяч километров при передаче пакета. Скорость света
>-- 300 тысяч км/сек. Итого -- получаем 230 миллисекунд в одну
>сторону. RTT - 460 миллисекунд. Грубо -- полсекунды (с учётом нашего
>приближения). При окне в 64 килобайта получаем скорость 128 килобайт в
>секунду -- примерно 1 мегабит/сек. :)
>
>Что есть тыщщу раз проверено (спросите у своих друзей со спутниковыми каналами).
>А вы говорите, не зашейпится. ;)
Существует вроде такой параметр масштабирования окна,
которыйможно передать в сегменте SYN.
Максимальный размер окна может быть 655334 * 2^14 байт.
(RFC 1323, Стивенс - глава 2.5)
>Можете посчитать сами -- скорость TCP-потока -- 1 окно в round-trip time
>линка. Высота геостационарной орбиты -- около 35 тысяч километров. Пренебрегая примерно
>в 15 раз меньшим основанием треугольника, с хорошей точностью можно считать,
>что свет проходит 70 тысяч километров при передаче пакета. Скорость света
>-- 300 тысяч км/сек. Итого -- получаем 230 миллисекунд в одну
>сторону. RTT - 460 миллисекунд. Грубо -- полсекунды (с учётом нашего
>приближения). При окне в 64 килобайта получаем скорость 128 килобайт в
>секунду -- примерно 1 мегабит/сек. :)Выставляю окно в 256K без проблем. И скорости соответствующие.
>Что есть тыщщу раз проверено (спросите у своих друзей со спутниковыми каналами).
Не надо друзей, сам сидел на таком канале. 2MBit/s получалось без напряга.
>А вы говорите, не зашейпится. ;)
Речь в теме немного не о том. Но в данном случае Вы несли полную чушь - и по скорости, и по количеству потоков ограничения совсем другие. И в пике потребления мы получали 38Mbit/s по спутнику - это на весь AS.
>Народ. :) Ну что вы пургу все гоните?-)
Взаимно?
>
>1. Шейпить входящий траффик невозможно. Запомните это раз и навсегда. Шейпинг --
>управление загрузкой физического канала. И хоть ты удропайся входящие пакеты --
>если тебе их с другой стороны шлют, канал всё равно будет
>на 100% загружен. :)Это в клиническом случае полного отсутствия flow control'а у передающего (грубо говоря, это есть флуд в чистом виде и за него полагается по голове). В случае если есть какое-то управление потоком - например, в TCP оно включено так что убрать не получится - то задержки и дропы входящего потока будут не сразу и не столь аккуратно, но регулировать потребление получится. Что точно не получится: грамотная приоритизация для интерактивного и особенно изохронного трафика. Например, выделить в отдельный класс голосовой трафик и давать пакетам такого трафика безусловный приоритет над веб-трафиком. Пример того что точно получится: ограничить потребление некоторой подсетью не более K% трафика; дать ей минимальный приоритет; сделать (с помощью некоторого дополнительного регулятора над полосами в pipe на основании данных счётчиков) ограничение вида "потреблять не более M% если канал загружен".
Основная проблема ALTQ, аналогичных линуксовых средств (tc) почему не подходит входящий поток, а также почему они напрямую не применимы на vlan'ах и прочих видах субпотоков - завязанность алгоритмов шейпинга на реальные текущие характеристики физического интерфейса: длину очереди, пропускную способность; прямой доступ к точке входа в физический интерфейс. При отсутствии знания о текущей очереди алгоритмы очередей вырождаются настолько, что перестают чем-то принципиально отличаться от dummynet'овских средств (ну разве что возможностями TBF по адаптивному занятию полосы в зависимости от загрузки канала...)
>Неужели никому не пришла в голову светлая мысль шейпить выход этого соединения?
>Или кто-то плохо помнит, что ALTQ вносит _задержки_ в прохождение пакетов,
>а TCP PUSH'и не будут ехать быстрее, чем в обратную сторону
>едут TCP ACK'и?-) TCP -- протокол с flow control'ем, слава КПСС.И что с того?
Ладно, пример того почему надо шейпить входящий трафик... Клуб, на каждый комп приходить должно не более 128кбит, pf+altq(cbq) ограничивает только исходящий, а мне нужно и то и другое, и желательно в синхроне, ибо трафик не резиновый (на 10Мбитах... по мегабайт-но)... Скажи те чем по вашему порезать канал для каждого ИПа в сети ?????Я НИКОГО НЕ ОБСУЖДАЮ, но если нет инструментария то и говорить не очем, просто так и напишите что АЛЬТКУ не способен резать входящий канал.... А НЕ РАЗВОДИТЕ ДЕМАГОГИЮ по поводу ПОЧЕМУ !!!!
В клуб порезать не проблема, причём на исходящих в локалку.
а вот на входящих в внешку реально плохо что неработает , иногда очент надо