Добрый день.Задача – выделить пользователю внутренней сети гарантированный канал.
Другими словами – сделать его трафик приоритетным и ограничить верхний предел скорости.
(поправьте меня, если я не прав)Сейчас все пользователи получают необходимую скорость по такой схеме:
# 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>
Обеспечит ли данная схема решение задачи? И вообще корректно ли так делать?
у меня реализовано через двойной пайпинг - первый пайп нарезает скорость индивидуально
(ну или по группам), второй слой - загоняет всех в один пайп.
Например канал 2Мбита, персональный пайп 128кбит, вторым слоем идет общий пайп скажем 1Мбит, те пользователи суммарно не могут занять канал шире 1Мб, второй мегабит остается свободным.
>у меня реализовано через двойной пайпинг - первый пайп нарезает скорость индивидуально
>
>(ну или по группам), второй слой - загоняет всех в один пайп.
>
>Например канал 2Мбита, персональный пайп 128кбит, вторым слоем идет общий пайп скажем
>1Мбит, те пользователи суммарно не могут занять канал шире 1Мб, второй
>мегабит остается свободным.Т.е. каскадировать пайпы реально, и система с ума не сходит?
>>у меня реализовано через двойной пайпинг - первый пайп нарезает скорость индивидуально
>>
>>(ну или по группам), второй слой - загоняет всех в один пайп.
>>
>>Например канал 2Мбита, персональный пайп 128кбит, вторым слоем идет общий пайп скажем
>>1Мбит, те пользователи суммарно не могут занять канал шире 1Мб, второй
>>мегабит остается свободным.
>
>Т.е. каскадировать пайпы реально, и система с ума не сходит?у меня полет нормальный
>Обеспечит ли данная схема решение задачи? И вообще корректно ли так делать?Нет, неправильно. Но ход мысли абсолютно верный.
ipfw pipe 1 config bw 90Mbit/s
ipfw pipe 2 config bw 90Mbit/squeue 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 0xffffffffipfw 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% от мах, а не то могут случиться "непредвиденные последствия" (с)
>[оверквотинг удален]
>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 12. В каком порядке лучше ставить пайпы - приоритезация потом шейпинг или наоборот?
> Для чего пользователям создавать отдельные очереди,
> если все можно запустить в одну?Вы неверно представляете себе механизм использования очередей.
Предположим, юзер А у нас "качальщик", а В и С - "серферы". У нас образуется три пары динамических очередей:очереди
/ААААААА---<
<---pipe-+-BВ--------<
\C---------<
очереди
---------а>\
---------в>-+-pipe--->
---------->/Раунд-робин-шедулер обегает все очереди по кругу и, если в текущей очереди есть пакет, готовый к пересылке, а во внутренней очереди соответствующего пайпа есть свободные слоты, сощелкивает его в общий пайп, и переходит к следующей динамической очереди. Во входящий пайп за первый раунд будут сощелкнуты пакеты (А, В и С) - во входящий пайп, и (а и в) - в исходящий.
Взамен отщелкнутого пакета из А будет положен следующий из ТСР-сессии, а отправителю уйдет АСК с предложением уменьшить скорость отправки. Чем меньше свободных слотов в очереди, тем чаще такой АСК будет уходить отправителю, до тех пор, пока скорость сощелкивания пакетов в пайп не сравняется со скоростью поступления пакетов от отправителя.
Обратите внимание, что регулируется скорость только одного клиента - того, очередь которого заполняется быстрее всего. Остальные клиенты, получают свои одинокие пакетики на максимально возможной скорости. При этом, если у нас есть пакеты для всех трех клиентов, то для каждого из них мгновенная скорость получения пакета будет одинакова. Они справедливо делят канал поровну. Т.е. в первый раунд они получат по одному пакету, во втором - А и В поделят канал поровну, а в третьем и последующих канал монопольно выжрет качальщик А. Но ровно до тех пор, пока не появятся очередные пакеты для В или С.
Если же мы всех наших клиентов посадим в одну общую очередь, то картина будет следующей:
ААААААВААААААСАААААА--<
-------------------ВСA>При этом у нас ВСЕ отправители будут получать АСК с предложением снизить скорость, даже те, которые не торопясь шлют редкие пакеты серферам. Кроме того, возникнут лаги, вызванные тем, что В и С будут привязаны к темпу получения пакетов качальщиком А. Ну и вдобавок, длинные очереди в DUMMYNET сами по себе создают заметные задержки в доставке каждого пакета, тем большие, чем длиннее очередь. А для обслуживания толстого траффика общую очередь придется делать ОЧЕНЬ длинной и, как следствие ОЧЕНЬ тормозной.
>1. Можно ли сделать big пайп вообще без шейпинга?Можно, разумеется, синтаксис это дозволяет. Не дозволяет механизм согласования скоростей протокола ТЦП, реализация дамминета во фре и постановка задачи.
Для того, чтобы эффективно работала политика приоритетов пакетов WF2Q+ (man ipfw), необходимо создать небольшой искусственный затор, который приведет к заполнению очередей самых активных генераторов траффика. Только тогда очереди дамминета начнут посылать отправителям пакеты АСК с требованием уменьшить скорость отправки - в чем, собсно, и заключается глубокий сакральный смысл приоритезации траффика. Если же пайп будет во всю толщину физики, то очереди будут опорожняться с той же скоростью, что и наполняться. В результате вожделенные шейплящие АСК источнику пакетов не уйдут никогда.
Считайте, что 5-10% полосы - это плата за механизм приоритетов.
>2. В каком порядке лучше ставить пайпы - приоритезация потом шейпинг или наоборот?Пайпы ipfw приоритезацию делать не умеют. Приоритезация по весам - только через очереди.
Если вы хотите пайпами нарезать фиксированные полосы, то уровень их "вложенности" ограничен максимальным количеством пайпов, который умеет создавать ipfw. Разумеется, при очень большом количестве пайпов, которые придется преодолевать пакету, накладные расходы на его доставку потребуют мощного проца.
>[оверквотинг удален]
>
>
>>2. В каком порядке лучше ставить пайпы - приоритезация потом шейпинг или наоборот?
>
>Пайпы ipfw приоритезацию делать не умеют. Приоритезация по весам - только через
>очереди.
>Если вы хотите пайпами нарезать фиксированные полосы, то уровень их "вложенности" ограничен
>максимальным количеством пайпов, который умеет создавать ipfw. Разумеется, при очень большом
>количестве пайпов, которые придется преодолевать пакету, накладные расходы на его доставку
>потребуют мощного проца.Спасибо большое. Теперь из этого всего нужно сочинить "боевое" решение, чем и займусь.
> Теперь из этого всего нужно сочинить "боевое" решение, чем и займусь.Добрый совет: не увлекайтесь ограничениями траффика сверху, пайпами. Скорей всего, в результате у вас будет простаивать часть полосы, а народ будет тесниться в рамках жестких лимитов.
>> Теперь из этого всего нужно сочинить "боевое" решение, чем и займусь.
>
>Добрый совет: не увлекайтесь ограничениями траффика сверху, пайпами. Скорей всего, в результате
>у вас будет простаивать часть полосы, а народ будет тесниться в
>рамках жестких лимитов.да ну бросте уважаемый - шейпинг дело полезное если правильно применять ...
> да ну бросте уважаемый - шейпинг дело полезное если правильно применять ...Интересно было бы посмотреть на случай полезного применения шейпинга, если речь не идет о торговле полосой с оверселлом.
Мне пока известен лишь один такой случай - зажимание единым шейпером всего тяжелого траффика (ftp, http, p2p) в большой пайп, оставляющий зазор для мелкого, но очень нужного траффика (ssh, smtp, dns etc).
>> да ну бросте уважаемый - шейпинг дело полезное если правильно применять ...
>
>Интересно было бы посмотреть на случай полезного применения шейпинга, если речь не
>идет о торговле полосой с оверселлом.
>
>Мне пока известен лишь один такой случай - зажимание единым шейпером всего
>тяжелого траффика (ftp, http, p2p) в большой пайп, оставляющий зазор для
>мелкого, но очень нужного траффика (ssh, smtp, dns etc).нарезка внутри большой корпаративки
> нарезка внутри большой корпаративкиЗачем? Для чего нужна фиксированная нарезка? В чем смысл зажимания сабнету полосы до, скажем, 10мбит, если сегмент, скажем, 100мбит - и никем, кроме зажатых, не используется?
>> нарезка внутри большой корпаративки
>
>Зачем? Для чего нужна фиксированная нарезка? В чем смысл зажимания сабнету полосы
>до, скажем, 10мбит, если сегмент, скажем, 100мбит - и никем, кроме
>зажатых, не используется?не внутри корпаративки, а на выходах из нее в инет
что бы всякие абалдуи внутри сети не клали скажем наружный канал на 2-4 мехабита качанием порно в торренте
нуууу, такое наверное надо регламентировать не полосой пропускания канала?
>нуууу, такое наверное надо регламентировать не полосой пропускания канала?можно, а можно и подстраховаться
>не внутри корпаративки, а на выходах из нее в инет
>что бы всякие абалдуи внутри сети не клали скажем наружный канал на
>2-4 мехабита качанием порно в торрентеА как вы противодействуете торрент-трафику при помощи пайпов?
>>не внутри корпаративки, а на выходах из нее в инет
>>что бы всякие абалдуи внутри сети не клали скажем наружный канал на
>>2-4 мехабита качанием порно в торренте
>
>А как вы противодействуете торрент-трафику при помощи пайпов?вообще я не ставил задачи противодействию торент трафика, я чисто привел контр-пример ...
а вообще вы товарищь меня на интересную мысль натолкнули ...
делаем пайп на вход юзеру скажем килобайт 15-20 - на однокласниках поанонировать хватит и вообще в интернете полазить, а вот торент уже проблематично заливать - хотя можно, и тут делаем такую падлу - режем пайп на выход раз в десять меньше чем входной, те 1.5-2 килабайта. если юзер в инете будет лазить то незаметить, а вот рейтинг на торенте ему будет проблематично удержать )) от балавства торентом не спасет - он обеспечивает постоянные грабли для юзера ))
> он обеспечивает постоянные грабли для юзера ))В принципе, я не против. Чем больше умельцев, практикующих подобную идеологию, тем выше спрос на админов.
>> он обеспечивает постоянные грабли для юзера ))
>
>В принципе, я не против. Чем больше умельцев, практикующих подобную идеологию, тем
>выше спрос на админов.В принципе, я тут в принципе не вижу постановки задачи )) "Резать иль не резать? Кто за? Кто против?" - вот конспект данного топа ...
>В принципе, я тут в принципе не вижу постановки задачи ))Вот, несколькими комментами выше: "Интересно было бы посмотреть на случай полезного применения шейпинга, если речь не идет о торговле полосой с оверселлом"
>>В принципе, я тут в принципе не вижу постановки задачи ))
>
>Вот, несколькими комментами выше: "Интересно было бы посмотреть на случай полезного применения
>шейпинга, если речь не идет о торговле полосой с оверселлом"что такое полоса с оверселлом ?
>>>В принципе, я тут в принципе не вижу постановки задачи ))
>>
>>Вот, несколькими комментами выше: "Интересно было бы посмотреть на случай полезного применения
>>шейпинга, если речь не идет о торговле полосой с оверселлом"
>
>что такое полоса с оверселлом ?как я понял это кагда продается полоса шире (в сумме) чем реально существующий аплинк (сумма аплинков)
>Вот, несколькими комментами выше: "Интересно было бы посмотреть на случай полезного применения шейпинга, если речь не идет о торговле полосой с оверселлом"эээ чето я заработался ... а торговля полосой без оверсела в шейпинге не нуждается?
>> Теперь из этого всего нужно сочинить "боевое" решение, чем и займусь.
>
>Добрый совет: не увлекайтесь ограничениями траффика сверху, пайпами. Скорей всего, в результате
>у вас будет простаивать часть полосы, а народ будет тесниться в
>рамках жестких лимитов.Ну пользователь платит за канал определенной ширины.
Вполне логично ему этот канал дать. И не дать больше, ведь он знает за что платит. Простой - не беда, это даже гут, меньше нагрузка, быстрее пакеты бегают.
Правда в последнее время канал под завязку по вечерам, но это уже совсем другая история.
Я тут собрал систему, павда не смог убедиться в работоспособности решения.
Я корректно сделал?Листин:
# 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.1ipfw pipe 200 config bw 45Mbit/s # in
ipfw pipe 300 config bw 45Mbit/sipfw 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 0xffffffffipfw 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 просто для примера.
>Я тут собрал систему, павда не смог убедиться в работоспособности решения.
>Я корректно сделал?Синтаксически все верно, кажется. Но я все равно не понимаю, зачем внутри организации делать фиксированные шейпы. Если б вы торговали полосой - это было бы понятно. Но зачем отдельного пользователя ужимать до 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 0xffffffffipfw 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 0xffffffffipfw 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 0xffffffffipfw 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 0xffffffffipfw 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 em0ipfw 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 em0ipfw 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 em0ipfw 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 em0ipfw 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Веса нужно рассчитывать исходя из количества машин в каждой таблице и средней их активности.
> Синтаксически все верно, кажется. Но я все равно не понимаю, зачем внутри
> организации делать фиксированные шейпы. Если б вы торговали полосой - это
> было бы понятно. Но зачем отдельного пользователя ужимать до 256Кбит вне
> зависимости от обстановки...Ну так так же и есть :-) Люди платят за канал определенной ширины.
>Ну так так же и есть :-) Люди платят за канал определенной ширины.Тогда неправильно описывать этих людей, как "пользователей внутренней сети" (см пост №1)
>>Ну так так же и есть :-) Люди платят за канал определенной ширины.
>
>Тогда неправильно описывать этих людей, как "пользователей внутренней сети" (см пост №1)
>Ну форма выражения может и не совсем точная, но не сильно сказалась на сути проблемы. Это мое мение :-)
Блин у нас наже на серверы распространяется минталитет. Ну не работают у нас вещи если их делать правильно.После того как реализовал схему с очередями, интернет стал работать боком. Все жалуются на скорость и на длинный пинг.
Убрал очереди, забросил всех в 1 пайп, а особого юзера в другой поуже (Общий канал - 50, дал всем 45, суперюзеру 5), и все, никто не жалуется, у всех все работает.
Неправильно? Но работает лучше чем правильно, отак от.
>После того как реализовал схему с очередями, интернет стал работать боком. Все
>жалуются на скорость и на длинный пинг.Конфиг с очередями сохранился? Который тормозил? Хочется глянуть
>Убрал очереди, забросил всех в 1 пайп, а особого юзера в другой
>поуже (Общий канал - 50, дал всем 45, суперюзеру 5), и
>все, никто не жалуется, у всех все работает.Не понимаю. У вас что, всего два пайпа получилось? А зачем тогда был вариант с кучей пайпов разной толщины?
Точно задача как формулируется?
>Точно задача как формулируется?Извините за сумбур.
Задача такая: сделать 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/sipfw 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 0xffffffffipfw 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/sipfw pipe 310 config bw 5Mbit/s # in
ipfw pipe 320 config bw 5Mbit/sipfw 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 em0ipfw 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