The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка  RSS
"Приоритезация средствами ipfw и dummynet. Это реально?"
Вариант для распечатки  
Пред. тема | След. тема 
Форумы Открытые системы на сервере (Квоты, ограничения, QoS / FreeBSD)
Изначальное сообщение [ Отслеживать ]

"Приоритезация средствами ipfw и dummynet. Это реально?"  +/
Сообщение от Lgo email(ok) on 08-Фев-10, 00:03 
Добрый день.

Задача – выделить пользователю внутренней сети гарантированный канал.
Другими словами – сделать его трафик приоритетным и ограничить верхний предел скорости.  
(поправьте меня, если я не прав)

Сейчас все пользователи получают необходимую скорость по такой схеме:

# Pipe config
##############
ipfw pipe 10 config mask dst-ip 0xffffffff bw 256Kbits/s  # in
ipfw pipe 110 config mask src-ip 0xffffffff bw 256Kbits/s

# IPFW rules for pipes
#######################
ipfw add 5001 pipe 10 ip from any to <iner ip> in via em0
ipfw add 5002 pipe 110 ip from <inner ip> to any out via em0

Каждый получает свой пайп с заданной скоростью.

У меня появилась идея решить задачу в лобовую. Перед  основными пайпами создать некий
суперпайп без ограничения скорости, в нем 2 очереди – для всех и для особого пользователя.
Примерно так:


# Superpipe
############
ipfw pipe 1 config bw 100Mbit/s

# Queues with prioritization
#############################
ipfw queue 1 config pipe 1 weight 10
ipfw queue 11 config pipe 1 weight 90


# Traffic for all users
#######################
ipfw add queue 1 ip from any to <inner ip>
ipfw add queue 1 ip from <inner ip> to any

# Traffic for surepuser
#######################
ipfw add queue 11 ip from <superuser> to any
ipfw add queue 11 ip from any to <superuser>


Обеспечит ли данная схема решение задачи? И вообще корректно ли так делать?

Высказать мнение | Ответить | Правка | Cообщить модератору

Оглавление

Сообщения по теме [Сортировка по времени | RSS]


1. "Приоритезация средствами ipfw и dummynet. Это реально?"  +/
Сообщение от Pahanivo email(ok) on 08-Фев-10, 08:47 
у меня реализовано через двойной пайпинг - первый пайп нарезает скорость индивидуально
(ну или по группам), второй слой - загоняет всех в один пайп.
Например канал 2Мбита, персональный пайп 128кбит, вторым слоем идет общий пайп скажем 1Мбит, те пользователи суммарно не могут занять канал шире 1Мб, второй мегабит остается свободным.
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

2. "Приоритезация средствами ipfw и dummynet. Это реально?"  +/
Сообщение от Lgo email(ok) on 08-Фев-10, 19:47 
>у меня реализовано через двойной пайпинг - первый пайп нарезает скорость индивидуально
>
>(ну или по группам), второй слой - загоняет всех в один пайп.
>
>Например канал 2Мбита, персональный пайп 128кбит, вторым слоем идет общий пайп скажем
>1Мбит, те пользователи суммарно не могут занять канал шире 1Мб, второй
>мегабит остается свободным.

Т.е. каскадировать пайпы реально, и система с ума не сходит?

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

4. "Приоритезация средствами ipfw и dummynet. Это реально?"  +/
Сообщение от Pahanivo email(ok) on 09-Фев-10, 16:37 
>>у меня реализовано через двойной пайпинг - первый пайп нарезает скорость индивидуально
>>
>>(ну или по группам), второй слой - загоняет всех в один пайп.
>>
>>Например канал 2Мбита, персональный пайп 128кбит, вторым слоем идет общий пайп скажем
>>1Мбит, те пользователи суммарно не могут занять канал шире 1Мб, второй
>>мегабит остается свободным.
>
>Т.е. каскадировать пайпы реально, и система с ума не сходит?

у меня полет нормальный

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

3. "Приоритезация средствами ipfw и dummynet. Это реально?"  +/
Сообщение от DeadLoco (ok) on 09-Фев-10, 00:58 
>Обеспечит ли данная схема решение задачи? И вообще корректно ли так делать?

Нет, неправильно. Но ход мысли абсолютно верный.

ipfw pipe 1 config bw 90Mbit/s
ipfw pipe 2 config bw 90Mbit/s

queue 1 config weight 90 queue 50 pipe 1 gred 0.002/5/15/0.1 mask dst-ip 0xffffffff
queue 2 config weight 10 queue 50 pipe 1 gred 0.002/5/15/0.1 mask dst-ip 0xffffffff
queue 3 config weight 90 queue 50 pipe 2 gred 0.002/5/15/0.1 mask src-ip 0xffffffff
queue 4 config weight 10 queue 50 pipe 2 gred 0.002/5/15/0.1 mask src-ip 0xffffffff

ipfw add 10001 queue 1 ip from any to <superuser>
ipfw add 10002 queue 2 ip from any to <inner ip>
ipfw add 10003 queue 3 ip from <superuser> to any
ipfw add 10004 queue 4 ip from <inner ip> to any

Разумеется, должен быть включен one-pass режим.

Пайпы шейпятся 90% полосы физики для того, чтобы корректно работал WF2Q+ и подстройка ТСР-окна. Лучше сделать натурные замеры и потом по месту отшейпить 90-95% от мах, а не то могут случиться "непредвиденные последствия" (с)

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

5. "Приоритезация средствами ipfw и dummynet. Это реально?"  +/
Сообщение от Lgo email(ok) on 09-Фев-10, 22:14 
>[оверквотинг удален]
>ipfw add 10002 queue 2 ip from any to <inner ip>
>ipfw add 10003 queue 3 ip from <superuser> to any
>ipfw add 10004 queue 4 ip from <inner ip> to any
>
>Разумеется, должен быть включен one-pass режим.
>
>Пайпы шейпятся 90% полосы физики для того, чтобы корректно работал WF2Q+ и
>подстройка ТСР-окна. Лучше сделать натурные замеры и потом по месту отшейпить
>90-95% от мах, а не то могут случиться "непредвиденные последствия" (с)
>

Спасибо большое.

Есть комментарий. Для чего пользователям создавать отдельные очереди,

queue 2 config weight 10 queue 50 pipe 1 gred 0.002/5/15/0.1 mask dst-ip 0xffffffff

если все можно запустить в одну?

queue 2 config weight 10 queue 50 pipe 1 gred 0.002/5/15/0.1


Еще 2 вопроса нарисовались:

1. Можно ли сделать big пайп вообще без шейпинга? Так как шейпинг все равно следует после.
   ipfw pipe 1

2. В каком порядке лучше ставить пайпы - приоритезация потом шейпинг или наоборот?

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

6. "Приоритезация средствами ipfw и dummynet. Это реально?"  +/
Сообщение от DeadLoco (ok) on 10-Фев-10, 02:23 
> Для чего пользователям создавать отдельные очереди,
> если все можно запустить в одну?

Вы неверно представляете себе механизм использования очередей.
Предположим, юзер А у нас "качальщик", а В и С - "серферы". У нас образуется три пары динамических очередей:

                   очереди
                /ААААААА---<
<---pipe-+-BВ--------<
                \C---------<


очереди
---------а>\
---------в>-+-pipe--->
---------->/

Раунд-робин-шедулер обегает все очереди по кругу и, если в текущей очереди есть пакет, готовый к пересылке, а во внутренней очереди соответствующего пайпа есть свободные слоты, сощелкивает его в общий пайп, и переходит к следующей динамической очереди. Во входящий пайп за первый раунд будут сощелкнуты пакеты (А, В и С) - во входящий пайп, и (а и в) - в исходящий.

Взамен отщелкнутого пакета из А будет положен следующий из ТСР-сессии, а отправителю уйдет АСК с предложением уменьшить скорость отправки. Чем меньше свободных слотов в очереди, тем чаще такой АСК будет уходить отправителю, до тех пор, пока скорость сощелкивания пакетов в пайп не сравняется со скоростью поступления пакетов от отправителя.

Обратите внимание, что регулируется скорость только одного клиента - того, очередь которого заполняется быстрее всего. Остальные клиенты, получают свои одинокие пакетики на максимально возможной скорости. При этом, если у нас есть пакеты для всех трех клиентов, то для каждого из них мгновенная скорость получения пакета будет одинакова. Они справедливо делят канал поровну. Т.е. в первый раунд они получат по одному пакету, во втором - А и В поделят канал поровну, а в третьем и последующих канал монопольно выжрет качальщик А. Но ровно до тех пор, пока не появятся очередные пакеты для В или С.

Если же мы всех наших клиентов посадим в одну общую очередь, то картина будет следующей:

ААААААВААААААСАААААА--<
-------------------ВСA>

При этом у нас ВСЕ отправители будут получать АСК с предложением снизить скорость, даже те, которые не торопясь шлют редкие пакеты серферам. Кроме того, возникнут лаги, вызванные тем, что В и С будут привязаны к темпу получения пакетов качальщиком А. Ну и вдобавок, длинные очереди в DUMMYNET сами по себе создают заметные задержки в доставке каждого пакета, тем большие, чем длиннее очередь.  А для обслуживания толстого траффика общую очередь придется делать ОЧЕНЬ длинной и, как следствие ОЧЕНЬ тормозной.


>1. Можно ли сделать big пайп вообще без шейпинга?

Можно, разумеется, синтаксис это дозволяет. Не дозволяет механизм согласования скоростей протокола ТЦП, реализация дамминета во фре и постановка задачи.

Для того, чтобы эффективно работала политика приоритетов пакетов WF2Q+ (man ipfw), необходимо создать небольшой искусственный затор, который приведет к заполнению очередей самых активных генераторов траффика. Только тогда очереди дамминета начнут посылать отправителям пакеты АСК с требованием уменьшить скорость отправки - в чем, собсно, и заключается глубокий сакральный смысл приоритезации траффика. Если же пайп будет во всю толщину физики, то очереди будут опорожняться с той же скоростью, что и наполняться. В результате вожделенные шейплящие АСК источнику пакетов не уйдут никогда.

Считайте, что 5-10% полосы - это плата за механизм приоритетов.


>2. В каком порядке лучше ставить пайпы - приоритезация потом шейпинг или наоборот?

Пайпы ipfw приоритезацию делать не умеют. Приоритезация по весам - только через очереди.
Если вы хотите пайпами нарезать фиксированные полосы, то уровень их "вложенности" ограничен максимальным количеством пайпов, который умеет создавать ipfw. Разумеется, при очень большом количестве пайпов, которые придется преодолевать пакету, накладные расходы на его доставку потребуют мощного проца.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

7. "Приоритезация средствами ipfw и dummynet. Это реально?"  +/
Сообщение от Lgo email(ok) on 11-Фев-10, 23:29 
>[оверквотинг удален]
>
>
>>2. В каком порядке лучше ставить пайпы - приоритезация потом шейпинг или наоборот?
>
>Пайпы ipfw приоритезацию делать не умеют. Приоритезация по весам - только через
>очереди.
>Если вы хотите пайпами нарезать фиксированные полосы, то уровень их "вложенности" ограничен
>максимальным количеством пайпов, который умеет создавать ipfw. Разумеется, при очень большом
>количестве пайпов, которые придется преодолевать пакету, накладные расходы на его доставку
>потребуют мощного проца.

Спасибо большое. Теперь из этого всего нужно сочинить "боевое" решение, чем и займусь.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

8. "Приоритезация средствами ipfw и dummynet. Это реально?"  +/
Сообщение от DeadLoco (ok) on 12-Фев-10, 08:30 
> Теперь из этого всего нужно сочинить "боевое" решение, чем и займусь.

Добрый совет: не увлекайтесь ограничениями траффика сверху, пайпами. Скорей всего, в результате у вас будет простаивать часть полосы, а народ будет тесниться в рамках жестких лимитов.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

9. "Приоритезация средствами ipfw и dummynet. Это реально?"  +/
Сообщение от Pahanivo email(ok) on 12-Фев-10, 13:29 
>> Теперь из этого всего нужно сочинить "боевое" решение, чем и займусь.
>
>Добрый совет: не увлекайтесь ограничениями траффика сверху, пайпами. Скорей всего, в результате
>у вас будет простаивать часть полосы, а народ будет тесниться в
>рамках жестких лимитов.

да ну бросте уважаемый - шейпинг дело полезное если правильно применять ...

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

11. "Приоритезация средствами ipfw и dummynet. Это реально?"  +/
Сообщение от DeadLoco (ok) on 15-Фев-10, 13:18 
> да ну бросте уважаемый - шейпинг дело полезное если правильно применять ...

Интересно было бы посмотреть на случай полезного применения шейпинга, если речь не идет о торговле полосой с оверселлом.

Мне пока известен лишь один такой случай - зажимание единым шейпером всего тяжелого траффика (ftp, http, p2p) в большой пайп, оставляющий зазор для мелкого, но очень нужного траффика (ssh, smtp, dns etc).

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

12. "Приоритезация средствами ipfw и dummynet. Это реально?"  +/
Сообщение от Pahanivo email(ok) on 15-Фев-10, 13:38 
>> да ну бросте уважаемый - шейпинг дело полезное если правильно применять ...
>
>Интересно было бы посмотреть на случай полезного применения шейпинга, если речь не
>идет о торговле полосой с оверселлом.
>
>Мне пока известен лишь один такой случай - зажимание единым шейпером всего
>тяжелого траффика (ftp, http, p2p) в большой пайп, оставляющий зазор для
>мелкого, но очень нужного траффика (ssh, smtp, dns etc).

нарезка внутри большой корпаративки

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

13. "Приоритезация средствами ipfw и dummynet. Это реально?"  +/
Сообщение от DeadLoco (ok) on 15-Фев-10, 15:40 
> нарезка внутри большой корпаративки

Зачем? Для чего нужна фиксированная нарезка? В чем смысл зажимания сабнету полосы до, скажем, 10мбит, если сегмент, скажем, 100мбит - и никем, кроме зажатых, не используется?

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

14. "Приоритезация средствами ipfw и dummynet. Это реально?"  +/
Сообщение от Pahanivo email(ok) on 15-Фев-10, 16:33 
>> нарезка внутри большой корпаративки
>
>Зачем? Для чего нужна фиксированная нарезка? В чем смысл зажимания сабнету полосы
>до, скажем, 10мбит, если сегмент, скажем, 100мбит - и никем, кроме
>зажатых, не используется?

не внутри корпаративки, а на выходах из нее в инет
что бы всякие абалдуи внутри сети не клали скажем наружный канал на 2-4 мехабита качанием порно в торренте

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

15. "Приоритезация средствами ipfw и dummynet. Это реально?"  +/
Сообщение от rr on 15-Фев-10, 16:49 
нуууу, такое наверное надо регламентировать не полосой пропускания канала?
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

17. "Приоритезация средствами ipfw и dummynet. Это реально?"  +/
Сообщение от Pahanivo email(ok) on 16-Фев-10, 08:09 
>нуууу, такое наверное надо регламентировать не полосой пропускания канала?

можно, а можно и подстраховаться

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

16. "Приоритезация средствами ipfw и dummynet. Это реально?"  +/
Сообщение от DeadLoco (ok) on 15-Фев-10, 19:36 
>не внутри корпаративки, а на выходах из нее в инет
>что бы всякие абалдуи внутри сети не клали скажем наружный канал на
>2-4 мехабита качанием порно в торренте

А как вы противодействуете торрент-трафику при помощи пайпов?

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

18. "Приоритезация средствами ipfw и dummynet. Это реально?"  +/
Сообщение от Pahanivo email(ok) on 16-Фев-10, 08:14 
>>не внутри корпаративки, а на выходах из нее в инет
>>что бы всякие абалдуи внутри сети не клали скажем наружный канал на
>>2-4 мехабита качанием порно в торренте
>
>А как вы противодействуете торрент-трафику при помощи пайпов?

вообще я не ставил задачи противодействию торент трафика, я чисто привел контр-пример ...
а вообще вы товарищь меня на интересную мысль натолкнули ...
делаем пайп на вход юзеру скажем килобайт 15-20 - на однокласниках поанонировать хватит и вообще в интернете полазить, а вот торент уже проблематично заливать - хотя можно, и тут делаем такую падлу - режем пайп на выход раз в десять меньше чем входной, те 1.5-2 килабайта. если юзер в инете будет лазить то незаметить, а вот рейтинг на торенте ему будет проблематично удержать )) от балавства торентом не спасет - он обеспечивает постоянные грабли для юзера ))

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

19. "Приоритезация средствами ipfw и dummynet. Это реально?"  +/
Сообщение от DeadLoco (ok) on 16-Фев-10, 13:31 
> он обеспечивает постоянные грабли для юзера ))

В принципе, я не против. Чем больше умельцев, практикующих подобную идеологию, тем выше спрос на админов.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

20. "Приоритезация средствами ipfw и dummynet. Это реально?"  +/
Сообщение от Pahanivo email(ok) on 16-Фев-10, 14:30 
>> он обеспечивает постоянные грабли для юзера ))
>
>В принципе, я не против. Чем больше умельцев, практикующих подобную идеологию, тем
>выше спрос на админов.

В принципе, я тут в принципе не вижу постановки задачи )) "Резать  иль не резать? Кто за? Кто против?" - вот конспект данного топа ...

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

21. "Приоритезация средствами ipfw и dummynet. Это реально?"  +/
Сообщение от DeadLoco (ok) on 16-Фев-10, 14:43 
>В принципе, я тут в принципе не вижу постановки задачи ))

Вот, несколькими комментами выше: "Интересно было бы посмотреть на случай полезного применения шейпинга, если речь не идет о торговле полосой с оверселлом"

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

22. "Приоритезация средствами ipfw и dummynet. Это реально?"  +/
Сообщение от rr on 16-Фев-10, 15:15 
>>В принципе, я тут в принципе не вижу постановки задачи ))
>
>Вот, несколькими комментами выше: "Интересно было бы посмотреть на случай полезного применения
>шейпинга, если речь не идет о торговле полосой с оверселлом"

что такое полоса с оверселлом ?

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

24. "Приоритезация средствами ipfw и dummynet. Это реально?"  +/
Сообщение от Pahanivo email(ok) on 16-Фев-10, 15:35 
>>>В принципе, я тут в принципе не вижу постановки задачи ))
>>
>>Вот, несколькими комментами выше: "Интересно было бы посмотреть на случай полезного применения
>>шейпинга, если речь не идет о торговле полосой с оверселлом"
>
>что такое полоса с оверселлом ?

как я понял это кагда продается полоса шире (в сумме) чем реально существующий аплинк (сумма аплинков)

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

23. "Приоритезация средствами ipfw и dummynet. Это реально?"  +/
Сообщение от Pahanivo email(ok) on 16-Фев-10, 15:16 
>Вот, несколькими комментами выше: "Интересно было бы посмотреть на случай полезного применения шейпинга, если речь не идет о торговле полосой с оверселлом"

эээ чето я заработался ... а торговля полосой без оверсела в шейпинге не нуждается?

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

10. "Приоритезация средствами ipfw и dummynet. Это реально?"  +/
Сообщение от Lgo email(ok) on 12-Фев-10, 23:57 
>> Теперь из этого всего нужно сочинить "боевое" решение, чем и займусь.
>
>Добрый совет: не увлекайтесь ограничениями траффика сверху, пайпами. Скорей всего, в результате
>у вас будет простаивать часть полосы, а народ будет тесниться в
>рамках жестких лимитов.

Ну пользователь платит за канал определенной ширины.
Вполне логично ему этот канал дать. И не дать больше, ведь он знает за что платит. Простой - не беда, это даже гут, меньше нагрузка, быстрее пакеты бегают.
Правда в последнее время канал под завязку по вечерам, но это уже совсем другая история.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

25. "Приоритезация средствами ipfw и dummynet. Это реально?"  +/
Сообщение от Lgo email(ok) on 22-Фев-10, 05:20 
Я тут собрал систему, павда не смог убедиться в работоспособности решения.
Я корректно сделал?

Листин:

# Pipe config
##############
ipfw pipe 10 config mask dst-ip 0xffffffff bw 256Kbits/s  # in
ipfw pipe 110 config mask src-ip 0xffffffff bw 256Kbits/s
ipfw pipe 11 config mask dst-ip 0xffffffff bw 1Mbits/s    # in
ipfw pipe 111 config mask src-ip 0xffffffff bw 512Kbits/s
ipfw pipe 12 config mask dst-ip 0xffffffff bw 5Mbits/s    # in
ipfw pipe 112 config mask src-ip 0xffffffff bw 1Mbits/s
ipfw pipe 13 config mask dst-ip 0xffffffff bw 10Mbits/s   # in
ipfw pipe 113 config mask src-ip 0xffffffff bw 2Mbits/s
ipfw pipe 14 config mask dst-ip 0xffffffff bw 5Mbits/s    # in
ipfw pipe 114 config mask src-ip 0xffffffff bw 5Mbits/s
ipfw pipe 40 config mask dst-ip 0xffffffff bw 20Mbits/s    # in
ipfw pipe 140 config mask src-ip 0xffffffff bw 5Mbits/s
ipfw pipe 41 config mask dst-ip 0xffffffff bw 50Mbits/s    # in
ipfw pipe 141 config mask src-ip 0xffffffff bw 10Mbits/s


# IPFW rules for pipes
#######################
ipfw add 5001 pipe 10 ip from any to "table(10)" in via em0
ipfw add 5002 pipe 110 ip from "table(10)" to any out via em0
ipfw add 5003 pipe 11 ip from any to "table(11)" in via em0
ipfw add 5004 pipe 111 ip from "table(11)" to any out via em0
ipfw add 5005 pipe 12 ip from any to "table(12)" in via em0
ipfw add 5006 pipe 112 ip from "table(12)" to any out via em0
ipfw add 5007 pipe 13 ip from any to "table(13)" in via em0
ipfw add 5008 pipe 113 ip from "table(13)" to any out via em0
ipfw add 5009 pipe 14 ip from any to "table(14)" in via em0
ipfw add 5010 pipe 114 ip from "table(14)" to any out via em0
ipfw add 5040 pipe 40 ip from any to "table(40)" in via em0
ipfw add 5041 pipe 140 ip from "table(40)" to any out via em0
ipfw add 5042 pipe 41 ip from any to "table(41)" in via em0
ipfw add 5043 pipe 141 ip from "table(41)" to any out via em0

####           ####
# Priority system #
####           ####


ipfw table 110 add 10.0.0.1

ipfw pipe 200 config bw 45Mbit/s # in
ipfw pipe 300 config bw 45Mbit/s

ipfw queue 10 config weight 90 queue 50 pipe 200 gred 0.002/5/15/0.1 mask dst-ip 0xffffffff  # in, high priority
ipfw queue 11 config weight 90 queue 50 pipe 300 gred 0.002/5/15/0.1 mask src-ip 0xffffffff  #     high priority
ipfw queue 20 config weight 10 queue 50 pipe 200 gred 0.002/5/15/0.1 mask dst-ip 0xffffffff  # in
ipfw queue 21 config weight 10 queue 50 pipe 300 gred 0.002/5/15/0.1 mask src-ip 0xffffffff

ipfw add 6001 queue 10 ip from any to "table(110)" in via em0          # high priority
ipfw add 6002 queue 11 ip from "table(110)" to any out via em0         # high priority
ipfw add 6003 queue 20 ip from any to not "table(110)" in via em0
ipfw add 6004 queue 21 ip from not "table(110)" to any out via em0


Сначала идут обычные пайпы нарезающие скорость. Таблици 10 - 41 для пользователей с соответствующей скоростью(например те кто в 10 таблице получают скорость 256К).

Далее таблица 110 для пользователей с приоритетом, по идее. IP 10.0.0.1 просто для примера.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

26. "Приоритезация средствами ipfw и dummynet. Это реально?"  +/
Сообщение от DeadLoco (ok) on 23-Фев-10, 02:08 
>Я тут собрал систему, павда не смог убедиться в работоспособности решения.
>Я корректно сделал?

Синтаксически все верно, кажется. Но я все равно не понимаю, зачем внутри организации делать фиксированные шейпы. Если б вы торговали полосой - это было бы понятно. Но зачем отдельного пользователя ужимать до 256Кбит вне зависимости от обстановки...

Попробуйте сделать вот так:

ipfw queue 10 config weight 90 queue 50 pipe 200 gred 0.002/5/15/0.1 mask dst-ip 0xffffffff  
ipfw queue 11 config weight 90 queue 50 pipe 300 gred 0.002/5/15/0.1 mask src-ip 0xffffffff  

ipfw queue 20 config weight 50 queue 50 pipe 200 gred 0.002/5/15/0.1 mask dst-ip 0xffffffff  
ipfw queue 21 config weight 50 queue 50 pipe 300 gred 0.002/5/15/0.1 mask src-ip 0xffffffff

ipfw queue 30 config weight 25 queue 50 pipe 200 gred 0.002/5/15/0.1 mask dst-ip 0xffffffff  
ipfw queue 31 config weight 25 queue 50 pipe 300 gred 0.002/5/15/0.1 mask src-ip 0xffffffff

ipfw queue 40 config weight 10 queue 50 pipe 200 gred 0.002/5/15/0.1 mask dst-ip 0xffffffff  
ipfw queue 41 config weight 10 queue 50 pipe 300 gred 0.002/5/15/0.1 mask src-ip 0xffffffff

ipfw queue 50 config weight 5 queue 50 pipe 200 gred 0.002/5/15/0.1 mask dst-ip 0xffffffff  
ipfw queue 51 config weight 5 queue 50 pipe 300 gred 0.002/5/15/0.1 mask src-ip 0xffffffff


ipfw add 6001 queue 10 ip from any to "table(1)" in via em0     #  Небожители
ipfw add 6002 queue 11 ip from "table(1)" to any out via em0

ipfw add 6003 queue 20 ip from any to "table(2)" in via em0
ipfw add 6004 queue 21 ip from "table(2)" to any out via em0

ipfw add 6005 queue 30 ip from any to "table(3)" in via em0     # Средний класс
ipfw add 6006 queue 31 ip from "table(3)" to any out via em0

ipfw add 6007 queue 40 ip from any to "table(4)" in via em0
ipfw add 6008 queue 41 ip from "table(4)" to any out via em0

ipfw add 6009 queue 50 ip from any to "table(5)" in via em0     # Пролетарии
ipfw add 6010 queue 51 ip from "table(5)" to any out via em0

Веса нужно рассчитывать исходя из количества машин в каждой таблице и средней их активности.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

27. "Приоритезация средствами ipfw и dummynet. Это реально?"  +/
Сообщение от Lgo email(ok) on 24-Фев-10, 23:45 

> Синтаксически все верно, кажется. Но я все равно не понимаю, зачем внутри
> организации делать фиксированные шейпы. Если б вы торговали полосой - это
> было бы понятно. Но зачем отдельного пользователя ужимать до 256Кбит вне
> зависимости от обстановки...

Ну так так же и есть :-) Люди платят за канал определенной ширины.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

30. "Приоритезация средствами ipfw и dummynet. Это реально?"  +/
Сообщение от DeadLoco (ok) on 25-Фев-10, 10:11 
>Ну так так же и есть :-) Люди платят за канал определенной ширины.

Тогда неправильно описывать этих людей, как "пользователей внутренней сети" (см пост №1)


Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

32. "Приоритезация средствами ipfw и dummynet. Это реально?"  +/
Сообщение от Lgo email(ok) on 01-Мрт-10, 06:24 
>>Ну так так же и есть :-) Люди платят за канал определенной ширины.
>
>Тогда неправильно описывать этих людей, как "пользователей внутренней сети" (см пост №1)
>

Ну форма выражения может и не совсем точная, но не сильно сказалась на сути проблемы. Это мое мение :-)

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

28. "Приоритезация средствами ipfw и dummynet. Это реально?"  +/
Сообщение от Lgo email(ok) on 25-Фев-10, 00:19 
Блин у нас наже на серверы распространяется минталитет. Ну не работают у нас вещи если их делать правильно.

После того как реализовал схему с очередями, интернет стал работать боком. Все жалуются на скорость и на длинный пинг.

Убрал очереди, забросил всех в 1 пайп, а особого юзера в другой поуже (Общий канал - 50, дал всем 45, суперюзеру 5), и все, никто не жалуется, у всех все работает.

Неправильно? Но работает лучше чем правильно, отак от.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

29. "Приоритезация средствами ipfw и dummynet. Это реально?"  +/
Сообщение от DeadLoco (ok) on 25-Фев-10, 10:10 
>После того как реализовал схему с очередями, интернет стал работать боком. Все
>жалуются на скорость и на длинный пинг.

Конфиг с очередями сохранился? Который тормозил? Хочется глянуть

>Убрал очереди, забросил всех в 1 пайп, а особого юзера в другой
>поуже (Общий канал - 50, дал всем 45, суперюзеру 5), и
>все, никто не жалуется, у всех все работает.

Не понимаю. У вас что, всего два пайпа получилось? А зачем тогда был вариант с кучей пайпов разной толщины?

Точно задача как формулируется?

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

31. "Приоритезация средствами ipfw и dummynet. Это реально?"  +/
Сообщение от Lgo email(ok) on 01-Мрт-10, 06:21 
>Точно задача как формулируется?

Извините за сумбур.

Задача такая: сделать 1 пользователя высокопроритетным, чтобы он получал свой гарантированный канал при любых раскладах. При этом надо сохранить старую систему нарезки трафика для всех остальных.

Ситему приоритетов я сделал ничего не меняя в системе пайпов для гораничения скорости для всех. И правила для проритето поставил после правил ограничителей скорости.

Вот та схема которая работала криво:

####################################################
# Variant 1 -  Guaranteed channel (priority users) #
# Temporary closed                                 #
####################################################

ipfw table 110 add <superuserip>

ipfw pipe 200 config bw 45Mbit/s # in
ipfw pipe 300 config bw 45Mbit/s

ipfw queue 10 config weight 90 queue 50 pipe 200 gred 0.002/5/15/0.1 mask dst-ip 0xffffffff  # in, high priority
ipfw queue 11 config weight 90 queue 50 pipe 300 gred 0.002/5/15/0.1 mask src-ip 0xffffffff  #     high priority
ipfw queue 20 config weight 10 queue 50 pipe 200 gred 0.002/5/15/0.1 mask dst-ip 0xffffffff  # in
ipfw queue 21 config weight 10 queue 50 pipe 300 gred 0.002/5/15/0.1 mask src-ip 0xffffffff

ipfw add 6001 queue 10 ip from any to "table(110)" in via em0          # high priority
ipfw add 6002 queue 11 ip from "table(110)" to any out via em0         # high priority
ipfw add 6003 queue 20 ip from any to not "table(110)" in via em0
ipfw add 6004 queue 21 ip from not "table(110)" to any out via em0

Это только приоритезация, первичные шейперы я из описания опустил.

Сейчас действует эта схема:

###########################
# Variant 2 - head attack #
###########################

ipfw pipe 210 config bw 45Mbit/s # in
ipfw pipe 220 config bw 45Mbit/s

ipfw pipe 310 config bw 5Mbit/s # in
ipfw pipe 320 config bw 5Mbit/s

ipfw add 6001 pipe 210 ip from any to not <superuserip> in via em0
ipfw add 6002 pipe 220 ip from not <superuserip> to any out via em0

ipfw add 6003 pipe 310 ip from any to <superuserip> in via em0
ipfw add 6004 pipe 320 ip from <superuserip> to any out via em0


Вот сами Старые добрые пайпы, их я не трогал.

# Pipe config
##############
ipfw pipe 10 config mask dst-ip 0xffffffff bw 256Kbits/s  # in
ipfw pipe 110 config mask src-ip 0xffffffff bw 256Kbits/s
ipfw pipe 11 config mask dst-ip 0xffffffff bw 1Mbits/s    # in
ipfw pipe 111 config mask src-ip 0xffffffff bw 512Kbits/s
ipfw pipe 12 config mask dst-ip 0xffffffff bw 5Mbits/s    # in
ipfw pipe 112 config mask src-ip 0xffffffff bw 1Mbits/s
ipfw pipe 13 config mask dst-ip 0xffffffff bw 10Mbits/s   # in
ipfw pipe 113 config mask src-ip 0xffffffff bw 2Mbits/s
ipfw pipe 14 config mask dst-ip 0xffffffff bw 5Mbits/s    # in
ipfw pipe 114 config mask src-ip 0xffffffff bw 5Mbits/s
ipfw pipe 40 config mask dst-ip 0xffffffff bw 20Mbits/s    # in
ipfw pipe 140 config mask src-ip 0xffffffff bw 5Mbits/s
ipfw pipe 41 config mask dst-ip 0xffffffff bw 50Mbits/s    # in
ipfw pipe 141 config mask src-ip 0xffffffff bw 10Mbits/s


# IPFW rules for pipes
#######################
ipfw add 5001 pipe 10 ip from any to "table(10)" in via em0
ipfw add 5002 pipe 110 ip from "table(10)" to any out via em0
ipfw add 5003 pipe 11 ip from any to "table(11)" in via em0
ipfw add 5004 pipe 111 ip from "table(11)" to any out via em0
ipfw add 5005 pipe 12 ip from any to "table(12)" in via em0
ipfw add 5006 pipe 112 ip from "table(12)" to any out via em0
ipfw add 5007 pipe 13 ip from any to "table(13)" in via em0
ipfw add 5008 pipe 113 ip from "table(13)" to any out via em0
ipfw add 5009 pipe 14 ip from any to "table(14)" in via em0
ipfw add 5010 pipe 114 ip from "table(14)" to any out via em0
ipfw add 5040 pipe 40 ip from any to "table(40)" in via em0
ipfw add 5041 pipe 140 ip from "table(40)" to any out via em0
ipfw add 5042 pipe 41 ip from any to "table(41)" in via em0
ipfw add 5043 pipe 141 ip from "table(41)" to any out via em0


Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру