Всем доброго времени суток. Есть вопрос - будет ли работать маршрут через lo-интерфейс? На серваке стоит CBQ, который режет скорость на исходящем интерфейсе, т.е. так как нат на внешнем интерфейсе, я могу ограничить группе пользователей скорость закачки, и не могу ограничить исходящую скорость. Вот подумалось - возможно ли пропустить немаскарадный траффик через lo, чтобы порезать исходящую скорость каждому в отдельности?
*
Как правильно сделать маршрут - ведь схема получается как бы двухкаскадная?
>Всем доброго времени суток. Есть вопрос - будет ли работать маршрут через
>lo-интерфейс? На серваке стоит CBQ, который режет скорость на исходящем интерфейсе,
>т.е. так как нат на внешнем интерфейсе, я могу ограничить группе
>пользователей скорость закачки, и не могу ограничить исходящую скорость. Вот подумалось
>- возможно ли пропустить немаскарадный траффик через lo, чтобы порезать исходящую
>скорость каждому в отдельности?
>*
>Как правильно сделать маршрут - ведь схема получается как бы двухкаскадная?так можно на внутреннем интерфейсе скорость отрезать. к чему такие сложности ?
>так можно на внутреннем интерфейсе скорость отрезать. к чему такие сложности ?
>Я на внутренем и режу - входящую скорость пользователя. Мне бы исходящую от него порезать. Т.е. на закачку все ок, на отправку - у них у всех полная скорость всего канала(((
>
>>так можно на внутреннем интерфейсе скорость отрезать. к чему такие сложности ?
>>
>
>Я на внутренем и режу - входящую скорость пользователя. Мне бы исходящую
>от него порезать. Т.е. на закачку все ок, на отправку
>- у них у всех полная скорость всего канала(((есть несколько методик борьбы с этой бедой. в данном случае нужно отрезать трафик, поступающий на локальный ethernet интерфейс:
1. policing на входящий трафик на внутреннем интерфейсе. это по крайней мере работает
без патчей и на всех ядрах, начиная с 2.2,
2. существует идея промежуточной буферизации такого трафика (так как он все равно уже
принят) и последующим управлением оным так же как и исходящим - в виде диспетчеризации
очереди псевдоинтерфейса. данный патч к ядру и iptables называется imq,
3. почему-то imq в официальном ядре не прижился, но вместо него появился похожий способ
под названием ifb. он имеет место в ядре, кажется с версии 2.6.16.есть еще один путь - зацепиться за какие-нибудь метаданные (типа fwmark, dsmark, tcindex и пр.) пакета, которые сопровождают его на протяжении всей жизни в ядре, и
диспетчеризовать пакеты на исходящем интерфейсе, исходя из метаданных.
>[оверквотинг удален]
>очереди псевдоинтерфейса. данный патч к ядру и iptables называется imq,
>3. почему-то imq в официальном ядре не прижился, но вместо него появился
>похожий способ
>под названием ifb. он имеет место в ядре, кажется с версии 2.6.16.
>
>
>есть еще один путь - зацепиться за какие-нибудь метаданные (типа fwmark, dsmark,
>tcindex и пр.) пакета, которые сопровождают его на протяжении всей жизни
>в ядре, и
>диспетчеризовать пакеты на исходящем интерфейсе, исходя из метаданных.Спасибо! Но с imq/ifb наверное буду разбираться попозже. пока обошелся маркировкой исходящих пакетов в iptables, и настроил cbq соответственно. Все работает)))
>Спасибо! Но с imq/ifb наверное буду разбираться попозже. пока обошелся маркировкой исходящих
>пакетов в iptables, и настроил cbq соответственно. Все работает)))Бился с похожей проблемой остановился на ifb+htb. Ifb потому что ядро патчить не надо, и его возможности с лихвой удовлетворяли мои потребности. Htb вместо cbq...наверное больше название первого понравилось)), да и если не использовать инит-скрипты(cbq.init, htb.init), то ИМХО htb полегче чуть в освоении.