[snark]

tablearg - я так понимаю дополнительный способ оптимизации таблиц, почему создание простых pipe на каждого юзера работает , а с дополнительными очередями- нет ?!

читаем еще раз man ipfw

 

LOOKUP TABLES
     Lookup tables are useful to handle large sparse address sets, typically
     from a hundred to several thousands of entries.  There may be up to 128
     different lookup tables, numbered 0 to 127.

     Each entry is represented by an addr[/masklen] and will match all
     addresses with base addr (specified as an IP address or a hostname) and
     mask width of masklen bits.  If masklen is not specified, it defaults to
     32.  When looking up an IP address in a table, the most specific entry
     will match.  Associated with each entry is a 32-bit unsigned value, which
     can optionally be checked by a rule matching code.  When adding an entry,
     if value is not specified, it defaults to 0.

     An entry can be added to a table (add), removed from a table (delete), a
     table can be examined (list) or flushed (flush).

     Internally, each table is stored in a Radix tree, the same way as the
     routing table (see route(4)).

     Lookup tables currently support IPv4 addresses only.

     The tablearg feature provides the ability to use a value, looked up in
     the table, as the argument for a rule action, action parameter or rule
     option.  This can significantly reduce number of rules in some configura-
     tions.  The tablearg argument can be used with the following actions:
     pipe, queue, divert, tee, netgraph, ngtee, fwd action parameters: tag,
     untag, rule options: limit, tagged.

     When used with fwd it is possible to supply table entries with values
     that are in the form of IP addresses or hostnames.  See the EXAMPLES Sec-
     tion for example usage of tables and the tablearg keyword.

 

особенное внимание - на предпоследний абзац! читаем и понимаем что tablearg - это не способ оптимизации таблиц - это возможность использования опционального value указываемого в таблицах (та самая циферка после IP адреса - это и есть value) в качестве аргумента для того или иного действия ...

 

как все это работает?

создается труба (pipe) которая определяет ширину канала, в нее помещается очередь (queue) которая определяет как размещать пакеты в трубе, в очередь помещаются пакеты согласно значению (value) в таблице (table) которое используется как указатель номера очереди.

 

на практике это выглядит примерно так:

• помещаем IP адрес в таблицу (table) с номером 1 и даем ему значение (value) 1 (значение - это маркер, который позволяет обращаться к адресу в таблице):

   

  ipfw table 1 add 192.168.0.20 1

• создаем трубу (pipe) с номером 1 шириной в, допустим, 128k:

   

  ipfw pipe 1 config bw 128Kbit/s

• создаем очередь (queue) с номером 1 и помещаем ее в трубу с номером 1:

   

  ipfw queue 1 config pipe 1 mask dst-ip 0xffffffff

• помещаем в очередь с номером 1, IP адрес из таблицы с номером 1 используя значение 1 как указатель номера очереди:

   

  ipfw add queue tablearg all from any to "table(1)"

обратите внимание что цифры 1 часто повторяющиеся в примере - это цифры имеющие разное значение!

 

подождем ув. jab, посмотрим что он скажет, хотя я вроде я ничего не напутал ...

[Mechanic]

ok, спасибо за разъяснение использования tablearg .

Но еще раз обращу внимание на статью (http://www.nag.ru/2005/1106/1106.shtml) где

На практике для жесткого ограничения полосы пропускания (Bandwidth) используется pipe, а для распределения полосы пропускания (WFQ) – queue.

, в этой статье не указывается про использование tablearg. Причем реализовав эти правила на практике для 1го юзера, все "едет" отлично, но применяя это же правило на группу ip получаем задержки, вот и встает вопрос почему ?!

[snark]

еще раз обращу внимание на статью (http://www.nag.ru/2005/1106/1106.shtml)

да, статья хорошая, но я еще раз обращу внимание на ман

 

Причем реализовав эти правила на практике для 1го юзера, все "едет" отлично, но применяя это же правило на группу ip получаем задержки, вот и встает вопрос почему ?!

не получается ли у Вас "одна очередь на все адреса из таблицы" вместо "отдельная очередь на каждый отдельный адрес"? `ipfw pipe show` для нерабочего варианта Вы же не показали ...

так же вызывает некое смущение Ваши:

 

${IPFW} add 2520 allow all from "table(47)" to any in via ${VPN_IFACES}
${IPFW} add 2530 allow all from any to "table(47)" out via ${VPN_IFACES}

т.к.

 

pipe == allow || accept || pass || permit

в зависимости от net.inet.ip.fw.one_pass ... он у Вас в каком виде?

[Mechanic]

net.inet.ip.fw.one_pass=0, поэтому

${IPFW} add 2520 allow all from "table(47)" to any in via ${VPN_IFACES}

${IPFW} add 2530 allow all from any to "table(47)" out via ${VPN_IFACES}

ipfw pipe show - как раз для не рабочего варианта

[vpn0848]

Здраствуйте! Я хоть и не провайдер но

у меня сейчас точно такая же проблема как у Mechanic

прочита http://www.nag.ru/2005/1106/1106.shtml , переделал немного правила:

${IPFW} pipe 31 config bw ${BW_128}Kbit/s queue 10kbytes

${IPFW} queue 31 config pipe 31 mask src-ip 0xffffffff

${IPFW} add 3100 queue 31 all from "table(78)" to any in via ${VPN_IFACES}

 

${IPFW} pipe 32 config bw ${BW_128}Kbit/s queue 10kbytes

${IPFW} queue 32 config pipe 32 mask dst-ip 0xffffffff

${IPFW} add 3110 queue 32 all from any to "table(78)" out via ${VPN_IFACES}

 

${IPFW} add 3120 allow all from "table(78)" to any in via ${VPN_IFACES}

${IPFW} add 3130 allow all from any to "table(78)" out via ${VPN_IFACES}

вопрос какой размер очереди необходимо брать для анлима 128,256,512кбит ?

Если в таблице несколько юзеров, то получаем норм пинг и ограничение, если в табл несколько десятков юзеров, то пинг прыгает до 500-600 и нефига не едет, причина ?!

Как только в таблицах появляется несколько десятков IP , то канал полностью ложится . Не возможно даже ya.ru

открыть. При работе большое кол-во дропов, и нормально настроить ну не как не получается . Пробывал использовать GRED/RED , пока эффекта не принесло .

......
${ipfw} -f table 2 flush
........
${ipfw} table 2 add 192.168.1.1
${ipfw} table 2 add 192.168.1.2
...
${ipfw} table 2 add 192.168.1.21
........
${ipfw} pipe 2 config bw 64Kbit/s mask src-ip 0xffffffff gred 0.002/10/30/0.1
${ipfw} queue 2 config pipe 2 weight 40 queue 3Kbytes
${ipfw} add 533 queue 2 ip from table\(2\) to any out
.......
${ipfw} add 3200 divert 8668 ip from any to any in via ${inet}
.......
${ipfw} pipe 3 config bw 64Kbit/s mask dst-ip 0xffffffff gred 0.002/10/30/0.1
${ipfw} queue 3 config pipe 3 weight 40 queue 3Kbytes
${ipfw} add 3303 queue 3 ip from any to table\(2\) in
...................
переменная  net.inet.ip.fw.one_pass=0
..........

 

И собственно вопрос к snark. Нумерация значений (value) в таблицах долна идти по порядку?

к примеру

в table 2
${ipfw} table 2 add 192.168.1.1 2 
${ipfw} table 2 add 192.168.1.2 2 
${ipfw} table 2 add 192.168.1.21 2
в table 3
${ipfw} table 3 add 192.168.1.35 3
${ipfw} table 3 add 192.168.1.36 3

 

и корректна ли в моём случае будет такое правило;

 

${ipfw} add 533 queue 2 tablearg ip from table\(2\) to any out

${ipfw} add 3303 queue 3 tablearg ip from any to table\(2\) in

 

Да и ещё на просторах интернета встречал такое утверждение , что если канал становится меньше чем размер пайпов то dummynet перестаёт

вообще работать.Насколько это правда?

 

P.S Ув. snark так уж волею судьбы сложилось что мы с Вами из одного города.И даже

немного знакомы , думаю по логину догадаетесь. Сразу оговорюсь канал к сожалению не ваш,

тут и понятно уже чей.

 

 

[mikevlz]

правило некорреткно, утверждение про неработоспособность дамминет неверно.

[snark]

ipfw pipe show - как раз для не рабочего варианта

странный он у Вас какой то ...

 

Нумерация значений (value) в таблицах долна идти по порядку?

нумерация совершенно монопенисуальна ...

 

корректна ли в моём случае будет такое правило

еще раз преречитайте мой пост, пожалуйста, и посмотрите как там сделано ... в общем виде - Вам не хватает связки тех самых value с queue через tablearg

 

Да и ещё на просторах интернета встречал такое утверждение , что если канал становится меньше чем размер пайпов то dummynet перестаёт

он (dummynet) вообще ничего не знает о ширине канала и поэтому подобное утверждение не верно

 

Ув. snark так уж волею судьбы сложилось что мы с Вами из одного города. И даже немного знакомы, думаю по логину догадаетесь.

мде ... жизнь имеет форму чумадана - куда не ткни - угол ... зашли бы как нить в гости что ли, под пиво проще об фре говорить :)

[Mechanic]

оффтоп : Уважаемый vpn0848 не могли бы вы зайти к snark ? пиво попьете и заодно все узнаете про правильные настройки dummynet и нам потом расскажете

[Mechanic]

уж не знаю, создал такие правила :

#${IPFW} pipe 60 config bw ${BW_128}Kbit/s queue 10kbyte

${IPFW} queue 60 config pipe 60 mask src-ip 0xffffffff

${IPFW} add 3100 queue tablearg all from "table(60)" to any in via ${VPN_IFACES}

${IPFW} add 3110 allow all from "table(60)" to any in via ${VPN_IFACES}

 

${IPFW} pipe 61 config bw ${BW_128}Kbit/s queue 10kbyte

${IPFW} queue 61 config pipe 61 mask dst-ip 0xffffffff

${IPFW} add 3120 queue tablearg all from any to "table(61)" out via ${VPN_IFACES}

${IPFW} add 3130 allow all from any to "table(61)" out via ${VPN_IFACES}

абонентов запускаю через таблицы :

ipfw table 60 add 172.1.1.1 60

ipfw table 61 add 172.1.1.1 61

но все равно сумашедшие задержки, какбудто канал нарезается 128 на всех

может еще зависят параметры sysctl ?

 

[No_name]

уж не знаю, создал такие правила :

#${IPFW} pipe 60 config bw ${BW_128}Kbit/s queue 10kbyte

${IPFW} queue 60 config pipe 60 mask src-ip 0xffffffff

${IPFW} add 3100 queue tablearg all from "table(60)" to any in via ${VPN_IFACES}

${IPFW} add 3110 allow all from "table(60)" to any in via ${VPN_IFACES}

 

но все равно сумашедшие задержки, какбудто канал нарезается 128 на всех

может еще зависят параметры sysctl ?

Так и есть, у вас нарезается на всех 128.

Надо привести примерно к такому виду:

 

# ipfw pipe 10 config mask src-ip 0xffffffff bw 128Kbit/s queue 10Kbytes
# ipfw pipe 20 config mask dst-ip 0xffffffff bw 128Kbit/s queue 10Kbytes
# ipfw add 1000 add pipe 10 all from any to "table(60)" out via fxp0
# ipfw add 2000 add pipe 20 all from "table(60)" to any in via fxp0
# ipfw add allow all from "table(60)" to any
# ipfw add allow all from any to "table(60)"

[t0ly]

уж не знаю, создал такие правила :

#${IPFW} pipe 60 config bw ${BW_128}Kbit/s queue 10kbyte

${IPFW} queue 60 config pipe 60 mask src-ip 0xffffffff

${IPFW} add 3100 queue tablearg all from "table(60)" to any in via ${VPN_IFACES}

${IPFW} add 3110 allow all from "table(60)" to any in via ${VPN_IFACES}

 

но все равно сумашедшие задержки, какбудто канал нарезается 128 на всех

может еще зависят параметры sysctl ?

Так и есть, у вас нарезается на всех 128.

Надо привести примерно к такому виду:

 

# ipfw pipe 10 config mask src-ip 0xffffffff bw 128Kbit/s queue 10Kbytes
# ipfw pipe 20 config mask dst-ip 0xffffffff bw 128Kbit/s queue 10Kbytes
# ipfw add 1000 add pipe 10 all from any to "table(60)" out via fxp0
# ipfw add 2000 add pipe 20 all from "table(60)" to any in via fxp0
# ipfw add allow all from "table(60)" to any
# ipfw add allow all from any to "table(60)"

чесно говоря бредовато тут поличится либо асиметричный канал либо не добавится 2 раза один и тот же ip c разными tablearg