[ex-transfer]

Добрый день, уважаемые!

Меня достала проблема с наглухо виснущем сервером. Происходит совершенно спонтанно, не зависит ни от пиков загрузки (~220 Mbitps/32kpps), ни от количества трансляций (max ~80k)! Сеть маленькая, на ~1000 хомяков. У всех влан-до-абонента.

Система

FreeBSD shaper.transfer.su 8.1-RELEASE FreeBSD 8.1-RELEASE

Три сетевухи - две одинаковые Intel em (pci-e)

dev.em.0.%desc: Intel(R) PRO/1000 Network Connection 6.9.14.Yandex[$Revision: 1.36.2.17.2.6 $]
dev.em.0.%driver: em

+ одна для управления bge.

 

Стоит pf и ipfw

Установил драйвера yandex, настроил sysctl , стал виснуть РЕЖЕ. (было каждый день, или через день), стало раз в неделю.

Нагрузка утром ничтожная:

shapper# top -SHPb
last pid: 34691;  load averages:  0.33,  0.41,  0.40  up 0+14:47:43    09:52:55
123 processes: 5 running, 93 sleeping, 25 waiting

Mem: 26M Active, 207M Inact, 330M Wired, 420K Cache, 213M Buf, 1412M Free
Swap: 4096M Total, 4096M Free

  PID USERNAME  PRI NICE   SIZE    RES STATE   C   TIME   WCPU COMMAND
   11 root      171 ki31     0K    64K CPU3    3 658:33 95.07% {idle: cpu3}
   11 root      171 ki31     0K    64K CPU2    2 657:18 94.78% {idle: cpu2}
   11 root      171 ki31     0K    64K CPU1    1 638:18 93.21% {idle: cpu1}
   11 root      171 ki31     0K    64K RUN     0 610:02 91.41% {idle: cpu0}
    0 root       46    0     0K   256K WAIT    1  95:37  5.08% {em1_rx_3}
  961 nobody     46    0  9048K  3684K select  0 106:44  4.98% softflowd
    0 root       47    0     0K   256K WAIT    2  95:28  4.88% {em1_rx_1}
    0 root       47    0     0K   256K WAIT    3  95:34  4.20% {em1_rx_2}
    0 root       47    0     0K   256K WAIT    3  95:53  4.05% {em1_rx_0}
    0 root       46    0     0K   256K WAIT    3  59:04  4.05% {em0_rx_2}
  959 nobody     46    0  9048K  3624K select  0  92:11  3.66% softflowd
    0 root       47    0     0K   256K WAIT    2  59:08  2.39% {em0_rx_0}
    0 root       47    0     0K   256K WAIT    0  59:21  2.00% {em0_rx_3}
    0 root       45    0     0K   256K WAIT    2  58:41  1.66% {em0_rx_1}
    0 root      -68    0     0K   256K -       1  30:25  1.12% {bge0 taskq}
   12 root      -32    -     0K   400K WAIT    0  15:52  0.39% {swi4: clock}
   20 root       44    -     0K    16K flowcl  3   3:16  0.34% flowcleaner
    0 root      -68    0     0K   256K -       1  82:21  0.00% {dummynet}

Параметры sysctl.conf

dev.em.0.rx_abs_int_delay=1500
dev.em.0.rx_int_delay=750
dev.em.0.rx_kthreads=4
dev.em.0.rx_processing_limit=1024
dev.em.0.tx_abs_int_delay=1500
dev.em.0.tx_int_delay=750
dev.em.1.rx_abs_int_delay=1500
dev.em.1.rx_int_delay=750
dev.em.1.rx_kthreads=4
dev.em.1.rx_processing_limit=1024
dev.em.1.tx_abs_int_delay=1500
dev.em.1.tx_int_delay=750
kern.ipc.maxsockbuf=2097152
kern.ipc.nmbclusters=65535 
kern.ipc.somaxconn=4096
net.inet.icmp.icmplim=500
net.inet.ip.dummynet.hash_size=1024
net.inet.ip.dummynet.io_fast=1
net.inet.ip.dummynet.io_fast=1
net.inet.ip.fastforwarding=1
net.inet.ip.fw.dyn_buckets=2048
net.inet.ip.fw.one_pass=1
net.inet.ip.intr_queue_maxlen=2048
net.inet.ip.redirect=0
net.inet.tcp.blackhole=0
net.inet.tcp.maxtcptw=40960
net.inet.udp.blackhole=0
net.isr.direct=1
net.isr.direct_force=1

 

Конфиг pf простейший:

set skip on lo0
set block-policy return
set optimization normal
set limit { states 300000, frags 600000 }
set limit table-entries 600000
nat on vlan250 inet from { 172.16.16.0/23, 172.16.18.0/23 } to any -> xx.xx.xx.xx/28 source-hash
...

 

Конфиг ipfw тоже простой:

ipfw pipe 65 config queue 12 bw 131072bit/s mask dst-ip 0xffffffff gred 0.002/3/6/0.1
ipfw pipe 66 config queue 24 bw 262144bit/s mask dst-ip 0xffffffff gred 0.002/6/12/0.1
# === 1 Mbit
ipfw add 13000 pipe tablearg ip from "table(68)" to any in recv vlan700
ipfw add 13000 pipe tablearg ip from any to "table(68)" out xmit vlan700
# === 2 Mbit
ipfw add 14000 pipe tablearg ip from "table(69)" to any in recv vlan700
ipfw add 14000 pipe tablearg ip from any to "table(69)" out xmit vlan700

ipfw add 20085 allow ip from any to "table(68)".
ipfw add 20090 allow ip from "table(68)" to any.
ipfw add 20100 allow ip from any to "table(69)".
ipfw add 20110 allow ip from "table(69)" to any.

 

Подскажите, ЧТО и где можно промониторить/поменять! Уже поломал мозг, не могу понять что ему нужно.

p.s. в messages перед зависанием ничего кроме

ov 16 17:47:17 shapper kernel: Limiting icmp unreach response from 510 to 500 packets/sec
Nov 16 17:47:19 shapper kernel: Limiting icmp unreach response from 513 to 500 packets/sec
Nov 16 17:47:24 shapper kernel: Limiting icmp unreach response from 519 to 500 packets/sec

 

 

[Giga-Byte]

я бы скопировал всю эту систему на другой диск, поставил второй сервер - разнёс задачи

(например PF вынести на другую машину)

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

 

ну и почитайте:

http://www.freebsd.org/doc/en_US.ISO8859-1...-deadlocks.html

http://www.freebsd.org/doc/en_US.ISO8859-1...ug-options.html

может, поможет

 

конечно приятно было бы видеть отчет, как отловили и получилось ли.

[Giga-Byte]

я думаю надо переделать:

# === 1 Mbit

ipfw add 13000 pipe tablearg ip from "table(68)" to any in recv vlan700

ipfw add 13000 pipe tablearg ip from any to "table(68)" out xmit vlan700

# === 2 Mbit

ipfw add 14000 pipe tablearg ip from "table(69)" to any in recv vlan700

ipfw add 14000 pipe tablearg ip from any to "table(69)" out xmit vlan700

на out xmit где там у вас абоненты

это поможет снизить нагрузку, возможно удастся убрать некоторые настройки dev.em.*

 

а также сомневаюсь в

dev.em.Х.rx_int_delay=750

посмотрите что написано в исходниках драйвера про это

 

зачем это:

kern.ipc.maxsockbuf=2097152

kern.ipc.nmbclusters=65535

kern.ipc.somaxconn=4096

 

где-то видел, что не рекомендуют завышать kern.ipc.nmbclusters более 42000 или 49000 без увеличения памяти ядра

а тут вы ещё и сокеты забубенили, может, вас сканируют...

поставьте отличное от нуля:

net.inet.tcp.blackhole=0

net.inet.udp.blackhole=0

[ex-transfer]

я бы скопировал всю эту систему на другой диск, поставил второй сервер - разнёс задачи

(например PF вынести на другую машину)

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

в недалеком будущем будет второй сервер, но пока, увы ... только этот.

по поводу дебуга ядра на предмет зависания - попробую, надо это прокурить внимательно! Спасибо за наводку!

 

а также сомневаюсь в

dev.em.Х.rx_int_delay=750

посмотрите что написано в исходниках драйвера про это

В исходниках яндексовских дрв? Где именно? Да, это стояло ещё при стандартных драйверах - перешло без изменений.

А по поводу

kern.ipc.maxsockbuf=2097152

kern.ipc.nmbclusters=65535

kern.ipc.somaxconn=4096

память ядра увеличена до 2Г

vm.kmem_size="2G"

а kern.ipc.somaxconn=4096 - я посчитал, что стандартных 128 мало. Сколько будет правильным?

net.inet.tcp.blackhole=0 
net.inet.udp.blackhole=0

да, это выставлю. На самом деле раньше и было по 1. Но в процессе поиска причины ребута убирал. ВЫставлю сейчас!

[ex-transfer]

# === 2 Mbit
ipfw add 14000 pipe tablearg ip from "table(69)" to any in recv vlan700
ipfw add 14000 pipe tablearg ip from any to "table(69)" out xmit vlan700
на out xmit где там у вас абоненты
это поможет снизить нагрузку, возможно удастся убрать некоторые настройки dev.em.*

у меня vlan700 смотрит какраз на абонентов.

[Giga-Byte]

# === 2 Mbit
ipfw add 14000 pipe tablearg ip from "table(69)" to any in recv vlan700
ipfw add 14000 pipe tablearg ip from any to "table(69)" out xmit vlan700
на out xmit где там у вас абоненты
это поможет снизить нагрузку, возможно удастся убрать некоторые настройки dev.em.*

у меня vlan700 смотрит какраз на абонентов.

простите запутался и запутал вас. надо внешний интерфейс указать, НО у вас же НАТ, поэтому никак.

[Giga-Byte]

а также сомневаюсь в

dev.em.Х.rx_int_delay=750

посмотрите что написано в исходниках драйвера про это

В исходниках яндексовских дрв? Где именно? Да, это стояло ещё при стандартных драйверах - перешло без изменений.

файл sys/dev/e1000/if_em.h

поиск по EM_RDTR

 

А по поводу

kern.ipc.maxsockbuf=2097152

kern.ipc.nmbclusters=65535

kern.ipc.somaxconn=4096

память ядра увеличена до 2Г

vm.kmem_size="2G"

как вы отдадите ядру 2Гб, если в системе всего 2Гб?

ядру можно отдать... (сомневаюсь, но где-то видел цифру 1.5Гб на 32-х битной системе)

вот некогда мне искать в исходниках эти формулы, так бы дискуссию продложил бы.

 

если у вас не высоконагруженый "комбайн" с биллингом на борту,

советую убрать этот тюнинг

с количеством памяти ядра, настройкой сокетов, буферов на сокеты,

а также nlbclusters вернуть на базу

 

что можно увеличить так это kern.maxusers до 512

 

а kern.ipc.somaxconn=4096 - я посчитал, что стандартных 128 мало. Сколько будет правильным?

зачем там такое количество сокетов? у вас на роутере высоконагруженый веб-сервер, ДНС-сервер?

как подсчитали?

 

 

[st_re]

Уберите FLOWTABLE из ядра... С ним были траблы.

 

set block-policy return замените на дроп, и, как выше написали

net.inet.tcp.blackhole=

net.inet.udp.blackhole=

больше 0

тогда уйдут

 

Nov 16 17:47:17 shapper kernel: Limiting icmp unreach response from 510 to 500 packets/sec

 

set limit table-entries 600000

куда столько ? Что там у Вас в таблицах ? Максимум список абонентов. тогда с 2-х кратным запасом 2000 будет.

 

Если в pf нет фаервола, то добавьте чтото вида

pass all no state

no scrub

 

дабы оно не пыталось фигней маяться...

 

ipfw pipe 65 config queue 12 bw 131072bit/s mask dst-ip 0xffffffff gred 0.002/3/6/0.1

ipfw pipe 66 config queue 24 bw 262144bit/s mask dst-ip 0xffffffff gred 0.002/6/12/0.1

# === 1 Mbit

ipfw add 13000 pipe tablearg ip from "table(68)" to any in recv vlan700

ipfw add 13000 pipe tablearg ip from any to "table(68)" out xmit vlan700

Я что то не понимаю тут, а ЧТО Вы шейпите ? Входящий трафик к каждому абоненту и отдельно исходящий к каждому ресурсу, не важно от кого? у Вас же маска dst ip?

 

Исходняк он разных абонентов на один IP попадет в 1 трубу и исходнятк от одного абонента к разным ресурсам попадет в разные...

 

Вы ipfw pipe 65 show посмотрите. Что там в трубы то напопадало.

 

По идее

ipfw pipe 65 config queue 12 bw 131072bit/s mask dst-ip 0xffffffff gred 0.002/3/6/0.1
ipfw pipe 1065 config queue 12 bw 131072bit/s mask src-ip 0xffffffff gred 0.002/3/6/0.1
ipfw pipe 66 config queue 24 bw 262144bit/s mask dst-ip 0xffffffff gred 0.002/6/12/0.1
ipfw pipe 1066 config queue 24 bw 262144bit/s mask src-ip 0xffffffff gred 0.002/6/12/0.1
# === 1 Mbit
ipfw add 13000 pipe tablearg ip from "table(78)" to any in recv vlan700
ipfw add 13000 pipe tablearg ip from any to "table(68)" out xmit vlan700

и в 78 таблице номера 10ХХ и в 68 ХХ

 

Тогда получится дуплексом 128к (для второго набора пайпов 256к) на вход и на выход каждому IP. Зачем таблица 69 вообще ? Все в одну пару таблиц (туда и оттуда).

 

И еще, мем тест какой не гоняли ? Ну так. Когда тупо виснет, иногда помогает узнать причину. Температура процессора в норме ?

 

 

[Giga-Byte]

И еще, мем тест какой не гоняли ? Ну так. Когда тупо виснет, иногда помогает узнать причину. Температура процессора в норме ?

а ещё блок питания, и вообще, сервер он сервер или дешевое десктопное железо...

[ex-transfer]

если у вас не высоконагруженый "комбайн" с биллингом на борту,

советую убрать этот тюнинг

с количеством памяти ядра, настройкой сокетов, буферов на сокеты,

а также nlbclusters вернуть на базу

спасибо, все вернул на Родину :)

количество пользователей увеличил

Уберите FLOWTABLE из ядра... С ним были траблы.

убрал. ночью пересоберу! спасибо.

set block-policy return замените на дроп

заменил, это осталось ещё от тех времён, когда работал только pf вместе со своим altq

и количество таблентрисов урезал. не помню, нафиг я так делал!

PF вообще занимается исключительно НАТом, больше в нем НИЧЕГО нет, т.к. когда-то заметил, что если закрыть им ssh снаружи, то в момент брутов сервер вешается. ipfw это дело закрывает стабильнее.

pass all no state

no scrub

попробую!

Я что то не понимаю тут, а ЧТО Вы шейпите ? Входящий трафик к каждому абоненту и отдельно исходящий к каждому ресурсу, не важно от кого? у Вас же маска dst ip?

Исходняк он разных абонентов на один IP попадет в 1 трубу и исходнятк от одного абонента к разным ресурсам попадет в разные...

Поясните, я недавно перешел на ipfw, не совсем понял.

Преследовалось, чтоб написать один пайп с маской /32 , сделать таблицу и зарезать все адреса таблицы этим пайпом в обе стороны.

Видимо, синтаксис неверен, объясните! Можно пример корректного написания?!

Вот кусок ipfw pipe 65 show:

00065: 131.072 Kbit/s    0 ms burst 0 
q131137  12 sl. 0 flows (1 buckets) sched 65601 weight 0 lmax 0 pri 0 
     GRED w_q 0.001999 min_th 3 max_th 6 max_p 0.099991
sched 65601 type FIFO flags 0x1 1024 buckets 92 active
    mask:  0x00 0x00000000/0x0000 -> 0xffffffff/0x0000
BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
  2 ip           0.0.0.0/0        78.31.244.61/0        3      144  0    0   0
  9 ip           0.0.0.0/0      93.186.231.124/0        1       40  0    0   0
16 ip           0.0.0.0/0        172.16.16.48/0       39    28794  0    0   0
19 ip           0.0.0.0/0       92.124.12.235/0        1       48  0    0   0
22 ip           0.0.0.0/0      212.77.140.141/0        2       82  0    0   0
25 ip           0.0.0.0/0       80.249.93.235/0        1       49  0    0   0
34 ip           0.0.0.0/0       178.66.56.166/0       43     2149  0    0   0
34 ip           0.0.0.0/0         86.19.124.4/0        5      707  0    0   0
64 ip           0.0.0.0/0       93.84.218.233/0        2      174  0    0   0
77 ip           0.0.0.0/0       93.186.235.56/0       98     4124  0    0   0
84 ip           0.0.0.0/0          82.46.16.8/0        3      137  0    0   0
86 ip           0.0.0.0/0      178.66.124.210/0        4      196  0    0   0
92 ip           0.0.0.0/0      109.168.223.13/0        3      144  0    0   0
98 ip           0.0.0.0/0        78.36.104.42/0        2       96  0    0   0
101 ip           0.0.0.0/0        78.61.232.30/0        1       48  0    0   0
103 ip           0.0.0.0/0        172.16.16.71/0     57129 52422452  7 4547 12361

И еще, мем тест какой не гоняли ? Ну так. Когда тупо виснет, иногда помогает узнать причину. Температура процессора в норме ?

нет, но хочу поставить на отдельный винт Win с SiSoftware Sandra и погонять на стресс-тестах!

Если есть варианты как на BSD это налету сделать, буду рад советам!

ещё блок питания, и вообще, сервер он сервер или дешевое десктопное железо...

Тоже была мысль. Пока резервного нет. Зато поменял и блок разеток, и даже кабель...

[ex-transfer]

Температура процессора в норме ?

собираю инфу coretemp'ом, и в кактус - всё в норме!

[Hawk128]

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

[Ivan_83]

Nov 16 17:47:19 shapper kernel: Limiting icmp unreach response from 513 to 500 packets/sec

Заменить на: set block-policy drop

 

 

зачем это:

kern.ipc.maxsockbuf=2097152

kern.ipc.nmbclusters=65535

kern.ipc.somaxconn=4096

Очевидно, из стенограммы выступления Сысоева несколько лет назад.

 

 

а kern.ipc.somaxconn=4096 - я посчитал, что стандартных 128 мало. Сколько будет правильным?

Это параметр для задания размера очереди желающих подключится к сокету.

Те вот есть ссш, который принимает соединения на 22 порту.

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

Это никак не максимальное количество соединений.

 

http://www.freebsd.org/doc/ru/books/handbo...nel-limits.html

11.13.1.2. kern.ipc.somaxconn

Переменная sysctl kern.ipc.somaxconn ограничивает размер очереди для приема новых TCP соединений. Значение по умолчанию 128 слишком мало для надежной обработки новых соединений для нагруженного web сервера. Для такого сервера рекомендуется увеличить это значение до 1024 или выше. Даемон сервиса может сам ограничивать очередь приема новых соединений (например, sendmail(8), или Apache), но обычно в файле настройки даемона есть директива для настройки длины очереди. Более длинная очередь также помогает избежать атак Denial of Service (DoS).

 

 

[ex-transfer]

Цитата(Giga-Byte @ 17.11.2010, 13:35)

зачем это:

kern.ipc.maxsockbuf=2097152

kern.ipc.nmbclusters=65535

kern.ipc.somaxconn=4096

Очевидно, из стенограммы выступления Сысоева несколько лет назад.

ТОЧНО!!!

Заменить на: set block-policy drop

заменил!

Проверяю, но пока никаких Limiting icmp unreach response from 513 to 500 packets/sec нет !

 

На данный момент ядро поправлено:

#options FLOWTABLE

# Kernel Debugging

options KDB

options KDB_TRACE

options DDB

options SOCKBUF_DEBUG

options DEBUG_VFS_LOCKS

завтра начну пересборку!

 

 

[st_re]

00065: 131.072 Kbit/s    0 ms burst 0 
q131137  12 sl. 0 flows (1 buckets) sched 65601 weight 0 lmax 0 pri 0 
     GRED w_q 0.001999 min_th 3 max_th 6 max_p 0.099991
sched 65601 type FIFO flags 0x1 1024 buckets 92 active
    mask:  0x00 0x00000000/0x0000 -> 0xffffffff/0x0000
BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
  2 ip           0.0.0.0/0        78.31.244.61/0        3      144  0    0   0
  9 ip           0.0.0.0/0      93.186.231.124/0        1       40  0    0   0
16 ip           0.0.0.0/0        172.16.16.48/0       39    28794  0    0   0
19 ip           0.0.0.0/0       92.124.12.235/0        1       48  0    0   0
22 ip           0.0.0.0/0      212.77.140.141/0        2       82  0    0   0
25 ip           0.0.0.0/0       80.249.93.235/0        1       49  0    0   0
34 ip           0.0.0.0/0       178.66.56.166/0       43     2149  0    0   0
34 ip           0.0.0.0/0         86.19.124.4/0        5      707  0    0   0
64 ip           0.0.0.0/0       93.84.218.233/0        2      174  0    0   0
77 ip           0.0.0.0/0       93.186.235.56/0       98     4124  0    0   0
84 ip           0.0.0.0/0          82.46.16.8/0        3      137  0    0   0
86 ip           0.0.0.0/0      178.66.124.210/0        4      196  0    0   0
92 ip           0.0.0.0/0      109.168.223.13/0        3      144  0    0   0
98 ip           0.0.0.0/0        78.36.104.42/0        2       96  0    0   0
101 ip           0.0.0.0/0        78.61.232.30/0        1       48  0    0   0
103 ip           0.0.0.0/0        172.16.16.71/0     57129 52422452  7 4547 12361

2 труба откуда угодно к 78.31.244.61 скорость 128к

9 труба откуда угодно к 93.186.231.124 скорость 128к

...

103 труба откуда угодно к 172.16.16.7 скорость 128к

 

Это то, что Вам надо ?

 

у Вас маска /32 на адресе ПОЛУЧАТЕЛЯ. на входящих пакетах это адрес Вашего клиента, и это, наверное, соответствует Вашим ожиданиям, а вот на исходящих это адрес удаленной стороны.

 

Если Вы запустите торрент, то входняк будет резаться к Вам на 128 к, а вот исходящий трафик от Вас к каждому Вашему пиру по 128к, что при количстве пиров 100 даст 12800к....

 

Если это не так, как Вам надо, то нужно делать по 2 трубы - труда туда и труба оттуда на каждую скорость, для входящего маска dst для исходящего src и делать 2 таблички, в перую номера пайпов для входящго трафика во вторую номера пайпов для исходящего.

 

 

[Giga-Byte]

На данный момент ядро поправлено:

#options FLOWTABLE

# Kernel Debugging

options KDB

options KDB_TRACE

options DDB

options SOCKBUF_DEBUG

options DEBUG_VFS_LOCKS

завтра начну пересборку!

боюсь не понадобится :))),

кроме как выкинуть из ядра FLOWTABLE (чего сам не проверял, до сих пор боевые серверы на 7.2 стоят, чуть больше года аптайма)

но попробовать стоит.

кстати - вы скрипт ddb посмотрите, чтобы ddb сам собрал нужные данные и увёл сервер в ребут, когда вы будите пить пиво далеко от серверной

 

[Ivan_83]

кстати - вы скрипт ddb посмотрите, чтобы ddb сам собрал нужные данные и увёл сервер в ребут, когда вы будите пить пиво далеко от серверной

Он не всегда это может сделать.

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

[ex-transfer]

2 труба откуда угодно к 78.31.244.61 скорость 128к

9 труба откуда угодно к 93.186.231.124 скорость 128к

...

103 труба откуда угодно к 172.16.16.7 скорость 128к

 

Это то, что Вам надо ?

 

у Вас маска /32 на адресе ПОЛУЧАТЕЛЯ. на входящих пакетах это адрес Вашего клиента, и это, наверное, соответствует Вашим ожиданиям, а вот на исходящих это адрес удаленной стороны.

 

Если Вы запустите торрент, то входняк будет резаться к Вам на 128 к, а вот исходящий трафик от Вас к каждому Вашему пиру по 128к, что при количстве пиров 100 даст 12800к....

 

Если это не так, как Вам надо, то нужно делать по 2 трубы - труда туда и труба оттуда на каждую скорость, для входящего маска dst для исходящего src и делать 2 таблички, в перую номера пайпов для входящго трафика во вторую номера пайпов для исходящего.

Это не то что надо :)

Спасибо за наведение на путь истинный! Поправил:

ipfw pipe 65 config queue 12 bw 131072bit/s mask dst-ip 0xffffffff gred 0.002/3/6/0.1

ipfw pipe 35 config queue 12 bw 131072bit/s mask src-ip 0xffffffff gred 0.002/3/6/0.1

 

# === 128 Kbit

ipfw add 11000 pipe tablearg ip from any to "table(65)" out xmit vlan700

ipfw add 11000 pipe tablearg ip from "table(35)" to any in recv vlan700