Jump to content
Калькуляторы

FreeBSD 11.2/12.0 в режиме bridge - пропадают пакеты в pipe

Так вы публикуйте полный лист правил IPFW.

65535 allow ip from any to any 


у вас отсутствует.

 

9 минут назад, Azamat сказал:

древний - не древний, а работает. Получить бы и здесь рабочий результат.   

Эта система неподдерживаемая с August 1, 2015

Share this post


Link to post
Share on other sites

ipfw show


00100  2328  195552 pipe 100 ip from any to 10.10.10.0/24 out via ix0
00110     0       0 allow ip from any to 10.10.10.0/24 out via ix0
65535 23404 2769011 allow ip from any to any
 

Share this post


Link to post
Share on other sites

Ну, почему вы не хотите предоставлять полную информацию о системе?
Почему каждый раз вы даете данные не полные, с оговорками?

Share this post


Link to post
Share on other sites

чтобы не засорять - так думалось. 

Если реально хотите помочь разобраться - сможете зайти удаленно ? Завтра могу навесить реальный адрес и подготовить логин/пароль в личку. 

Доступ к стенду готов дать любому вызвавшемуся добровльцем :) 

 

Но вообще, неужели ни у кого нет рабочего моста/шейпера на 11.2 / 12.0  ?

Share this post


Link to post
Share on other sites
3 часа назад, Azamat сказал:

ipfw pipe 100 config bw 15Mbit/s queue 465

А вы net.inet.ip.dummynet.pipe_slot_limit подкрутили? По дефолту там 100 слотов

Share this post


Link to post
Share on other sites

Конечно, до 2048

На всех мостах так, иначе gred нормально не настроить

Share this post


Link to post
Share on other sites

В общем похоже разобрался.

Причем, как и ожидалось - net.inet.ip.forwarding оказался не при делах, работает при 

net.inet.ip.forwarding: 0

 

Сейчас так режет полосы:

ipfw pipe 100 config bw 64Mbit/s queue 1800

[  3]  0.0-30.0 sec   220 MBytes  61.3 Mbits/sec

 

ipfw pipe 100 config bw 24Mbit/s queue 930

[  3]  0.0-30.0 sec  82.5 MBytes  23.0 Mbits/sec

 

ipfw pipe 100 config bw 15Mbit/s queue 465

[  3]  0.0-30.1 sec  51.8 MBytes  14.4 Mbits/sec
 

ipfw pipe 100 config bw 10Mbit/s queue 310

[  3]  0.0-30.1 sec  34.6 MBytes  9.64 Mbits/sec

 

Надо будет дать 4% сверху, чтобы выйти на более/менее точные полосы для абонентов.

 

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

 


 

 

 

 

 

 

 

Share this post


Link to post
Share on other sites

И в чем же было дело?

Share this post


Link to post
Share on other sites
1 час назад, vurd сказал:

И в чем же было дело?

После такого подхода к форуму, можно его спокойно добавлять в игнор-лист.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Понятно. Очередной товарищ перепутал форум с платной тех поддержкой. Ну и сколько вы хотите за публикацию пути решения проблемы? Или если я у себя хочу решить, то кидать логопас в личку и сделаете за так?

Share this post


Link to post
Share on other sites

 Кончайте меряться пиписьками :) Иногда и я в ступор встаю, и тут тупо вопрошаю. Но ищу не решение, а путь до него, лёгкий пинок в нужном направлении очень помогает.

не onepass ?

Share this post


Link to post
Share on other sites

Итого:

под нагрузкой мост на FB 12.0 оказался полной лажей :

на трафике меньше 1 Гбит/с (который мост на FB 8.4 даже не замечает):

 

CPU 0:  0.0% user,  0.0% nice, 77.6% system,  0.0% interrupt, 22.4% idle
CPU 1:  0.0% user,  0.0% nice, 77.6% system,  0.0% interrupt, 22.4% idle
CPU 2:  0.0% user,  0.0% nice, 74.8% system,  0.0% interrupt, 25.2% idle
CPU 3:  0.0% user,  0.0% nice, 83.7% system,  0.0% interrupt, 16.3% idle
Mem: 18M Active, 8680K Inact, 276M Wired, 90M Buf, 7479M Free
Swap: 8192M Total, 8192M Free

  PID USERNAME    PRI NICE   SIZE    RES STATE    C   TIME    WCPU COMMAND
    0 root        -76    -      0   400K CPU1     1  55:25  81.45% kernel{if_io_tqg_1}
    0 root        -76    -      0   400K -        3  57:22  80.68% kernel{if_io_tqg_3}
    0 root        -76    -      0   400K -        2  55:35  74.87% kernel{if_io_tqg_2}
    0 root        -76    -      0   400K CPU0     0  56:27  69.53% kernel{if_io_tqg_0}
   11 root        155 ki31      0    64K RUN      0  21:21  29.24% idle{idle: cpu0}
   11 root        155 ki31      0    64K CPU2     2  22:51  24.90% idle{idle: cpu2}
   11 root        155 ki31      0    64K RUN      3  21:06  19.16% idle{idle: cpu3}
   11 root        155 ki31      0    64K RUN      1  23:01  18.71% idle{idle: cpu1}
    0 root        -92    -      0   400K -        0   0:57   1.57% kernel{dummynet}

 

Почему то вся нагрузка на system, хотя net.isr в direct

net.inet.ip.dummynet.io_fast: 1

 

волшебной крутилки чтобы снизить нагрузку не нашел, возвращаемся на 8.4

Share this post


Link to post
Share on other sites
В 05.05.2019 в 00:00, Azamat сказал:

под нагрузкой мост на FB 12.0 оказался полной лажей

Хоть бы профилировщик запустил и посмотрел где горячие зоны.

 

В 05.05.2019 в 00:00, Azamat сказал:

Почему то вся нагрузка на system, хотя net.isr в direct

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

 

В 05.05.2019 в 00:00, Azamat сказал:

волшебной крутилки чтобы снизить нагрузку не нашел, возвращаемся на 8.4

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

Share this post


Link to post
Share on other sites

 

 

2 минуты назад, Azamat сказал:

Плз не разговаривайте с собственными голосами насчет фри в целом.  12.0 нормально работает в режиме роутера.

 

Если знаете - подскажите. Я выше предлагал удаленный доступ к серверу для умелых (я только ремесленник). Что то не нашлось желающих потратить время на сообщество.

А у меня времени не было чтобы разбираться, почему проц. на 100 проц на 700Мбит/с - а это глубокая ночь, а не на 12% как на 8.4 - ибо стали расти задержки и другие прелести типа запредельного джиттера.

По другому получить рабочую нагрузку мне негде, гонять несколько потоков iperf - не показательно. На людях экспериментировать - не вариант.

 

Попробовал только direct, hybrid, differed - одно и то же оказалось по факту.

Зато первое правило allow from any to any возвращает проц к 10% загрузки. Т.е. один и тот же набор правил ставит колом 12.0-stab и легко обрабатывается на 8.4

 

 

 

Edited by Azamat

Share this post


Link to post
Share on other sites

У ipfw где то был параметр one_pass или как то так.

Share this post


Link to post
Share on other sites

в самом первом посте было в общем контексте:

net.inet.ip.fw.one_pass: 0

 

То ли в 12.0 увели в штатном режиме обработку прерываний в system, то ли х.з. что еще.  

 

Вот роутер на 12.0-stab:

 

netstat -bdh -w1 -I ix0

      416k     0     0       515M       222k     0        46M     0     0
      544k     0     0       673M       289k     0        61M     0     0

 

 netstat -bdh -w1 -I ix1
            input            ix1           output
   packets  errs idrops      bytes    packets  errs      bytes colls drops
      229k     0     0        64M       408k     0       492M     0     0
      234k     0     0        65M       426k     0       517M     0     0
      255k     0     0        68M       447k     0       546M     0     0
      257k     0     0        71M       461k     0       562M     0     0
 

 

 top -PHS
last pid: 63873;  load averages:  2.04,  2.20,  2.16   up 30+04:29:51  22:20:40
191 threads:   8 running, 166 sleeping, 17 waiting
CPU 0:  0.4% user,  0.0% nice, 52.3% system,  0.4% interrupt, 46.9% idle
CPU 1:  0.0% user,  0.0% nice, 52.7% system,  0.0% interrupt, 47.3% idle
CPU 2:  0.0% user,  0.0% nice, 54.0% system,  0.0% interrupt, 46.0% idle
CPU 3:  0.0% user,  0.0% nice, 61.5% system,  0.0% interrupt, 38.5% idle
Mem: 26M Active, 1348M Inact, 1050M Wired, 493M Buf, 5596M Free
 

  PID USERNAME    PRI NICE   SIZE    RES STATE    C   TIME    WCPU COMMAND
    0 root        -76    -      0   384K CPU1     1 206.2H  53.17% kernel{if_io_tqg_1}
    0 root        -76    -      0   384K -        2 207.1H  49.33% kernel{if_io_tqg_2}
    0 root        -76    -      0   384K -        3 206.5H  48.67% kernel{if_io_tqg_3}
    0 root        -76    -      0   384K -        0 202.7H  48.41% kernel{if_io_tqg_0}
 

 

здесь тоже вся прерывания в system, хотя:

 

net.isr.numthreads: 4
net.isr.maxprot: 16
net.isr.defaultqlimit: 20480
net.isr.maxqlimit: 20480
net.isr.bindthreads: 1
net.isr.maxthreads: 4
net.isr.dispatch: direct
 

+ выпилен Fastforwarding (во всех предыдущих версиях облегчал жизнь),сейчас вместо сделали какой-то tryforward, как зафиксировать его влияние - хз.

 

до кучи:

interrupt                          total       rate
irq1: atkbd0                           2          0
cpu0:timer                    2934125667       1125
cpu1:timer                    2935059792       1125
cpu2:timer                    2933854332       1125
cpu3:timer                    2934959046       1125
irq264: ix0:rxq0             61858968128      23714
irq265: ix0:rxq1             75590459238      28978
irq266: ix0:rxq2             75312963992      28871
irq267: ix0:rxq3             75505104647      28945
irq268: ix0:aq                         7          0
irq269: ix1:rxq0             90200128638      34578
irq270: ix1:rxq1             97008771872      37188
irq271: ix1:rxq2             96822862993      37117
irq272: ix1:rxq3             96773135031      37098
irq273: ix1:aq                        18          0
irq275: ahci0                   36970587         14
irq278: em0:irq0               410569352        157
Total                       681257933342     261161
 

Работает как роутер не хуже, но и не лучше других версий, у меня на них базовая 10.3

 

 

 

Edited by Azamat

Share this post


Link to post
Share on other sites
6 часов назад, Azamat сказал:

То ли в 12.0 увели в штатном режиме обработку прерываний в system

 

6 часов назад, Azamat сказал:

net.isr.dispatch: direct

deferred нужно ставить чтобы обрабатывать в контексте isr потоков.

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

 

6 часов назад, Azamat сказал:

выпилен Fastforwarding (во всех предыдущих версиях облегчал жизнь),сейчас вместо сделали какой-то tryforward, как зафиксировать его влияние - хз.

Не выпилен а впилен окончательно и включён всегда.

 

6 часов назад, Azamat сказал:

net.inet.ip.fw.one_pass: 0

вот и попробуй 1.

Share this post


Link to post
Share on other sites
15 часов назад, Ivan_83 сказал:

Не выпилен а впилен окончательно и включён всегда.

точно? мои последние сведения о tryforward закончились на том, что чтобы он работал, нужно сделать net.inet.ip.redirect=0

вот где-то в этом месте https://svnweb.freebsd.org/base?view=revision&revision=337736

на текущий момент еще что-то перепилили?

Share this post


Link to post
Share on other sites

https://reviews.freebsd.org/D4042

https://svnweb.freebsd.org/base?view=revision&revision=r290383

 

13 часов назад, nixx сказал:

точно? мои последние сведения о tryforward закончились на том, что чтобы он работал, нужно сделать net.inet.ip.redirect=0

Мои закончились раньше :)

Вроде эта опция и так всегда выключена.

Share this post


Link to post
Share on other sites

"Ок, гугл" В порядке самообразования, где в правилах топикстатртера ключевое слово layer2 отсутствует.  Сколько раз пакет проходит через шейпер в его случае?

 

 

 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now