[olloviel]

@orca аналогичная проблема, на двухпроцессорном сервере не могу загрузить второй проц, kernel{if_io_tqg} работают только для первого:

last pid: 10429;  load averages:  2.02,  2.48,  2.61                                                                 up 181+05:36:00 10:46:22
404 threads:   26 running, 311 sleeping, 1 zombie, 66 waiting
CPU 0:   0.0% user,  0.0% nice, 12.5% system,  0.0% interrupt, 87.5% idle
CPU 1:   0.4% user,  0.0% nice, 24.3% system,  0.0% interrupt, 75.3% idle
CPU 2:   0.0% user,  0.0% nice, 19.6% system,  0.0% interrupt, 80.4% idle
CPU 3:   0.0% user,  0.0% nice, 20.4% system,  0.0% interrupt, 79.6% idle
CPU 4:   0.0% user,  0.0% nice, 18.0% system,  0.0% interrupt, 82.0% idle
CPU 5:   0.0% user,  0.0% nice, 27.5% system,  0.0% interrupt, 72.5% idle
CPU 6:   0.0% user,  0.0% nice, 30.2% system,  0.0% interrupt, 69.8% idle
CPU 7:   0.0% user,  0.0% nice, 23.1% system,  0.0% interrupt, 76.9% idle
CPU 8:   0.0% user,  0.0% nice, 22.0% system,  0.0% interrupt, 78.0% idle
CPU 9:   0.0% user,  0.0% nice, 20.8% system,  0.0% interrupt, 79.2% idle
CPU 10:  0.0% user,  0.0% nice,  1.2% system,  0.0% interrupt, 98.8% idle
CPU 11:  0.4% user,  0.0% nice,  0.0% system,  0.0% interrupt, 99.6% idle
CPU 12:  1.5% user,  0.0% nice,  0.4% system,  0.0% interrupt, 98.1% idle
CPU 13:  3.1% user,  0.0% nice,  0.4% system,  0.0% interrupt, 96.5% idle
CPU 14:  4.2% user,  0.0% nice,  0.4% system,  0.0% interrupt, 95.4% idle
CPU 15:  0.4% user,  0.0% nice,  0.0% system,  0.0% interrupt, 99.6% idle
CPU 16:  0.8% user,  0.0% nice,  0.4% system,  0.0% interrupt, 98.8% idle
CPU 17:  6.5% user,  0.0% nice,  1.5% system,  0.0% interrupt, 92.0% idle
CPU 18:  0.8% user,  0.0% nice,  1.5% system,  0.0% interrupt, 97.7% idle
CPU 19:  0.4% user,  0.0% nice,  0.4% system,  0.0% interrupt, 99.2% idle
Mem: 221M Active, 3733M Inact, 138M Laundry, 2621M Wired, 1234M Buf, 9618M Free
Swap: 4096M Total, 181M Used, 3915M Free, 4% Inuse

  PID USERNAME    PRI NICE   SIZE    RES STATE    C   TIME    WCPU COMMAND
   11 root        155 ki31     0B   320K CPU11   11 4261.6 100.00% idle{idle: cpu11}
   11 root        155 ki31     0B   320K CPU18   18 4251.6 100.00% idle{idle: cpu18}
   11 root        155 ki31     0B   320K CPU10   10 4263.3  99.65% idle{idle: cpu10}
   11 root        155 ki31     0B   320K CPU12   12 4260.0  99.44% idle{idle: cpu12}
   11 root        155 ki31     0B   320K RUN     15 4256.1  99.40% idle{idle: cpu15}
   11 root        155 ki31     0B   320K CPU16   16 4254.6  99.38% idle{idle: cpu16}
   11 root        155 ki31     0B   320K CPU19   19 4250.3  99.03% idle{idle: cpu19}
   11 root        155 ki31     0B   320K CPU14   14 4257.5  97.64% idle{idle: cpu14}
   11 root        155 ki31     0B   320K RUN     13 4258.8  96.23% idle{idle: cpu13}
   11 root        155 ki31     0B   320K CPU17   17 4253.5  94.76% idle{idle: cpu17}
   11 root        155 ki31     0B   320K CPU0     0 3347.7  86.14% idle{idle: cpu0}
   11 root        155 ki31     0B   320K CPU2     2 3391.5  83.33% idle{idle: cpu2}
   11 root        155 ki31     0B   320K CPU3     3 3336.5  82.17% idle{idle: cpu3}
   11 root        155 ki31     0B   320K CPU4     4 3335.6  79.46% idle{idle: cpu4}
   11 root        155 ki31     0B   320K CPU8     8 3285.0  78.04% idle{idle: cpu8}
   11 root        155 ki31     0B   320K RUN      1 3363.6  77.26% idle{idle: cpu1}
   11 root        155 ki31     0B   320K RUN      7 3389.8  76.11% idle{idle: cpu7}
   11 root        155 ki31     0B   320K RUN      9 3234.2  75.77% idle{idle: cpu9}
   11 root        155 ki31     0B   320K CPU5     5 3199.1  71.87% idle{idle: cpu5}
   11 root        155 ki31     0B   320K RUN      6 3335.0  69.75% idle{idle: cpu6}
    0 root        -76    -     0B  1168K CPU6     6 1001.0  30.14% kernel{if_io_tqg_6}
    0 root        -76    -     0B  1168K CPU5     5 1127.2  27.65% kernel{if_io_tqg_5}
    0 root        -76    -     0B  1168K -        9 1102.2  24.06% kernel{if_io_tqg_9}
    0 root        -76    -     0B  1168K -        7 945.5H  23.72% kernel{if_io_tqg_7}
    0 root        -76    -     0B  1168K -        1 972.1H  22.58% kernel{if_io_tqg_1}
    0 root        -76    -     0B  1168K -        8 1050.8  21.81% kernel{if_io_tqg_8}
    0 root        -76    -     0B  1168K -        4 1000.1  20.33% kernel{if_io_tqg_4}
    0 root        -76    -     0B  1168K -        3 999.7H  17.60% kernel{if_io_tqg_3}
    0 root        -76    -     0B  1168K CPU2     2 944.1H  16.46% kernel{if_io_tqg_2}
    0 root        -76    -     0B  1168K -        0 987.5H  13.63% kernel{if_io_tqg_0}
95679 djbdns       22    0  1041M   958M select  14  42.1H   6.57% dnscache
10364 postgres     21    0   173M    83M select  17   0:01   6.41% postgres
10382 postgres     21    0   173M    87M select  17   0:01   4.76% postgres

Что обидно, в гугле про эту проблему буквально две темы на форумах. Такое ощущение, что никто трафик на freebsd не роутит/натит. Была надежда на freebsd 13, но судя по Вашему посту надо думать что-то еще. Не появилось у Вас новой информации? Как сами будете решать проблему?

[AlKov]

1 час назад, olloviel сказал:

Такое ощущение, что никто трафик на freebsd не роутит/натит.

Не знаю насчет "никто", но я от этого ушел совсем почти лет 10 тому назад.

Особенно задалбливал NAT. Сервер стабильно уходил в полный ступор раз, а то и два в месяц.

Плюнул (слюной, как рекомендовал тов. Бендер :-) )  и отправил эти "процедуры" на CentOS.

С тех пор про этот страшный сон не вспоминаю.

[Ivan_83]

17 часов назад, olloviel сказал:

на двухпроцессорном сервере не могу загрузить второй проц, kernel{if_io_tqg} работают только для первого

А делали то что?

net.isr крутили?

В рассылке спрашивали?

Маны читали?

 

16 часов назад, AlKov сказал:

Не знаю насчет "никто", но я от этого ушел совсем почти лет 10 тому назад.

Особенно задалбливал NAT. Сервер стабильно уходил в полный ступор раз, а то и два в месяц.

Плюнул (слюной, как рекомендовал тов. Бендер :-) )  и отправил эти "процедуры" на CentOS.

Анонимный страдалец :)

Нет чтобы в багтрекер и рассылку долбить, так лучше сидеть и ждать чуда, а потом свалить туда где уже другие всё сделали.

[AlKov]

4 часа назад, Ivan_83 сказал:

Нет чтобы в багтрекер и рассылку долбить, так лучше сидеть и ждать чуда, а потом свалить туда где уже другие всё сделали.

Что поделать, остались еще чудаки, предпочитающие "ехать" вместо "шашечек". ;-)

 

P.S. Ну а для гурманов немного перефразирую А. Иванова

Ты пиши, пиши, пиши,

Сочиняй весь век,

Потому что пародистпрограммист -

Тоже человек.

Он не хочет затянуть

Туже поясок.

Для него твои стихи -

Хлебушка кусок.

Ты пиши и мой призыв

Не сочти за лесть,

Потому что пародистпрограммист

Тоже хочет есть!

[olloviel]

 

5 hours ago, Ivan_83 said:

А делали то что?

нагуглил эту тему, спросил что делают другие :)

 

 

On 9/21/2020 at 11:57 PM, Ivan_83 said:

В сисцтл (меняется без ребута):

net.isr.dispatch=deferred        # direct / hybrid / deffered // Interrupt handling via multiple CPU, but with context switch.

было net.isr.dispatch=direct, изменил на deferred. Если не ошибаюсь, раньше были проблемы со стабильностью при deffered, посмотрю что будет сейчас. Нагрузка развалилась на ядра, перешла из system в interrupt:

 

Spoiler

last pid: 75402;  load averages:  2.33,  2.78,  2.67                           up 182+04:18:27 09:28:53
401 threads:   25 running, 312 sleeping, 1 zombie, 63 waiting
CPU 0:   1.2% user,  0.0% nice,  3.1% system,  4.3% interrupt, 91.3% idle
CPU 1:   0.8% user,  0.0% nice,  5.9% system,  8.3% interrupt, 85.0% idle
CPU 2:   0.0% user,  0.0% nice,  7.1% system,  3.9% interrupt, 89.0% idle
CPU 3:   0.4% user,  0.0% nice,  7.9% system,  6.7% interrupt, 85.0% idle
CPU 4:   1.6% user,  0.0% nice,  7.5% system,  7.9% interrupt, 83.1% idle
CPU 5:   0.8% user,  0.0% nice,  7.9% system,  5.5% interrupt, 85.8% idle
CPU 6:   0.8% user,  0.0% nice,  9.4% system,  4.3% interrupt, 85.4% idle
CPU 7:   0.8% user,  0.0% nice,  4.7% system, 10.6% interrupt, 83.9% idle
CPU 8:   0.0% user,  0.0% nice,  2.8% system,  7.5% interrupt, 89.8% idle
CPU 9:   0.0% user,  0.0% nice,  7.1% system,  9.1% interrupt, 83.9% idle
CPU 10:  0.0% user,  0.0% nice,  0.4% system,  7.9% interrupt, 91.7% idle
CPU 11:  0.0% user,  0.0% nice,  0.0% system,  9.8% interrupt, 90.2% idle
CPU 12:  0.8% user,  0.0% nice,  0.8% system,  5.9% interrupt, 92.5% idle
CPU 13:  0.4% user,  0.0% nice,  0.0% system,  8.3% interrupt, 91.3% idle
CPU 14:  0.0% user,  0.0% nice,  0.4% system,  8.7% interrupt, 90.9% idle
CPU 15:  0.4% user,  0.0% nice,  0.4% system, 11.0% interrupt, 88.2% idle
CPU 16:  0.4% user,  0.0% nice,  0.8% system, 22.8% interrupt, 76.0% idle
CPU 17:  0.8% user,  0.0% nice,  0.0% system,  5.1% interrupt, 94.1% idle
CPU 18:  0.8% user,  0.0% nice,  1.6% system, 10.6% interrupt, 87.0% idle
CPU 19:  0.4% user,  0.0% nice,  0.4% system, 12.2% interrupt, 87.0% idle
Mem: 218M Active, 4232M Inact, 138M Laundry, 2810M Wired, 1423M Buf, 9595M Free
Swap: 4096M Total, 181M Used, 3915M Free, 4% Inuse

  PID USERNAME    PRI NICE   SIZE    RES STATE    C   TIME    WCPU COMMAND
   11 root        155 ki31     0B   320K CPU12   12 4282.2  93.28% idle{idle: cpu12}
   11 root        155 ki31     0B   320K CPU17   17 4275.6  92.29% idle{idle: cpu17}
   11 root        155 ki31     0B   320K CPU10   10 4285.4  91.24% idle{idle: cpu10}
   11 root        155 ki31     0B   320K CPU11   11 4283.8  91.00% idle{idle: cpu11}
   11 root        155 ki31     0B   320K CPU13   13 4280.9  90.14% idle{idle: cpu13}
   11 root        155 ki31     0B   320K CPU14   14 4279.7  89.84% idle{idle: cpu14}
   11 root        155 ki31     0B   320K CPU0     0 3366.4  89.63% idle{idle: cpu0}
   11 root        155 ki31     0B   320K CPU2     2 3409.8  89.04% idle{idle: cpu2}
   11 root        155 ki31     0B   320K CPU15   15 4278.3  88.99% idle{idle: cpu15}
   11 root        155 ki31     0B   320K CPU18   18 4273.7  88.27% idle{idle: cpu18}
   11 root        155 ki31     0B   320K CPU7     7 3407.7  87.33% idle{idle: cpu7}
   11 root        155 ki31     0B   320K CPU3     3 3354.8  87.27% idle{idle: cpu3}
   11 root        155 ki31     0B   320K CPU8     8 3303.3  86.99% idle{idle: cpu8}
   11 root        155 ki31     0B   320K CPU1     1 3381.9  86.91% idle{idle: cpu1}
   11 root        155 ki31     0B   320K CPU5     5 3215.4  86.59% idle{idle: cpu5}
   11 root        155 ki31     0B   320K CPU6     6 3352.4  86.52% idle{idle: cpu6}
   11 root        155 ki31     0B   320K CPU4     4 3353.4  84.22% idle{idle: cpu4}
   11 root        155 ki31     0B   320K CPU19   19 4272.4  83.74% idle{idle: cpu19}
   11 root        155 ki31     0B   320K CPU9     9 3251.8  82.59% idle{idle: cpu9}
   11 root        155 ki31     0B   320K CPU16   16 4276.7  75.28% idle{idle: cpu16}
   12 root        -72    -     0B  1072K CPU16   16   7:28  24.12% intr{swi1: netisr 16}
   12 root        -72    -     0B  1072K CPU19   19   5:43  15.38% intr{swi1: netisr 19}
   12 root        -72    -     0B  1072K WAIT     9   5:26  12.43% intr{swi1: netisr 9}
   12 root        -72    -     0B  1072K WAIT    18   4:41  10.72% intr{swi1: netisr 18}
   12 root        -72    -     0B  1072K WAIT    15   4:59   9.96% intr{swi1: netisr 15}
   12 root        -72    -     0B  1072K WAIT     4   3:08   9.79% intr{swi1: netisr 4}
   12 root        -72    -     0B  1072K WAIT    14   3:41   9.10% intr{swi1: netisr 14}
95679 djbdns       24    0  1041M   958M select  16  43.6H   8.86% dnscache
   12 root        -72    -     0B  1072K WAIT    13   3:47   8.83% intr{swi1: netisr 13}
   12 root        -72    -     0B  1072K WAIT    11   5:47   8.39% intr{swi1: netisr 11}
   12 root        -72    -     0B  1072K WAIT     1   3:24   7.82% intr{swi1: netisr 1}
   12 root        -72    -     0B  1072K WAIT    10   4:16   7.72% intr{swi1: netisr 10}
   12 root        -72    -     0B  1072K WAIT     7   3:10   7.28% intr{swi1: netisr 7}
   12 root        -72    -     0B  1072K WAIT     6   2:25   6.86% intr{swi1: netisr 6}
   12 root        -72    -     0B  1072K WAIT     8   2:56   6.79% intr{swi1: netisr 8}
    0 root        -76    -     0B  1168K -        3 1004.0   6.59% kernel{if_io_tqg_3}

 

Если я правильно понимаю, вместо прямой обработки в контексте прерывания пакеты буферизируются и дальше через софтовые прерывая обрабатываются ядрами? Не могу найти описание работы net.isr.dispatch=hybrid, можете в двух словах объяснить?

 

[Ivan_83]

В 22.07.2021 в 09:15, AlKov сказал:

Что поделать, остались еще чудаки, предпочитающие "ехать" вместо "шашечек". ;-)

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

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

 

 

В 22.07.2021 в 09:42, olloviel сказал:

Нагрузка развалилась на ядра, перешла из system в interrupt

Это не прерывания.

 

В 22.07.2021 в 09:42, olloviel сказал:

Если я правильно понимаю, вместо прямой обработки в контексте прерывания пакеты буферизируются и дальше через софтовые прерывая обрабатываются ядрами?

Не совсем.

Директ это когда пакеты обрабатываются прямо в контексте прерывания. Благодаря всяким msi-x оно аппаратно размазывается на столько ядер сколько может железка или как то ещё запрогано. Можно поискать крутилки драйвера или iflib, вдруг там есть количество msi-x прерываний.

Диспатч - это когда прерывание спихивает все пакеты в очередь ISR подсистемы и возвращается к обслуживанию своей железки. А ISR там уже внутри пакеты размазывает по обработчикам. Минус тут на мой взгляд только один и для меня он вообще не существенный - увеличивается время на обработку пакета, на какие то мизерные доли секунды, но для геймеров и высокочастотных трейдеров это может быть критическим недостатком. Раньше ещё были отдельно нетграф потоки обработчики, но как я понял или в 12 или 13 их выкинули и переделали на ISR, чтобы не плодить одинаковые сущности.

Гибрид - не знаю, вернее забыл. Попробуйте найти в рассылках или документации.

 

 

[jffulcrum]

hybrid режим влияет на ровно один момент: если пакет прилетел с того же ядра, на котором уже ожидает обработчик протокола - пакет отправляется обработчику напрямую, иначе улетает в общую очередь, как в deferred

[AlKov]

В 24.07.2021 в 00:03, Ivan_83 сказал:

Это не инженерный подход..

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

Все остальное, уж извините, ваши досужие домыслы..

 

Соглашусь - немного подправив - с ..

В 24.07.2021 в 00:03, Ivan_83 сказал:

дальше вамвсем, использующим *nix сетевые решения, предстоит уйти с линукса на готовые железки и венду

В "линуксах" эта тенденция, IMHO, тоже уже очень жирно просматривается.. 

Для себя лично надеюсь всех этих прелестей не застать.

 

P.S. Предлагаю закончить дискуссию в этом направлении, т.к. она совсем не в тему.

 

[WideAreaNetwork]

есть проблема с брасом, проц по каким-то причинам грузится в полку

начинаются расти пинги, а потом идут потери

 

FreeBSD 12.2-RELEASE-p12 GENERIC  amd64

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

до проблемы никакого тюнинга в loader.conf и sysctl.conf не было, внес некоторые изменения но проблема все равно один раз вчера появилась, оно как-то рандомно, то  ночью в 3 часа, то утром часов в 10, то вечером в любой время, пока-что после обновления безопасности не было такого, но не факт что не повториться

 

loader.conf

geom_mirror_load="YES"
pf_load="YES"
ipfw_load="YES"
ipdivert_load="YES"
dummynet_load="YES"
autoboot_delay=2
loader_logo="beastie"


##### tuning #####

hw.ix.unsupported_sfp="1"	# 0
hw.ix.flow_control=0	# 3
net.link.ifqmaxlen="16384"  # (default 50)
net.isr.defaultqlimit="4096" # (default 256)
kern.ipc.nmbclusters="5242880"	# 1010028
kern.ipc.nmbjumbop="2621440"	# 505013
net.inet.tcp.syncache.hashsize="1024"	# 512
net.inet.tcp.syncache.bucketlimit="100"	# 30
net.isr.maxqlimit="1000000"	# 10240
dev.ix.0.iflib.core_offset=1	# 0
dev.ix.0.iflib.override_nrxqs=7	# 0
dev.ix.0.iflib.override_ntxqs=7	# 0
hw.em.rx_process_limit="-1"

sysctl.conf

# $FreeBSD: releng/12.2/sbin/sysctl/sysctl.conf 337624 2018-08-11 13:28:03Z brd $
#
#  This file is read when going to multi-user and its contents piped thru
#  ``sysctl'' to adjust kernel values.  ``man 5 sysctl.conf'' for details.
#

# Uncomment this to prevent users from seeing information about processes that
# are being run under another UID.

net.inet.ip.dummynet.expire=0                   #1
net.inet.ip.dummynet.hash_size=2048             #64 up to 65535
net.inet.ip.dummynet.pipe_slot_limit=1000       #100 up to 2048 or 4096
net.inet.ip.dummynet.io_fast=1                  #0 uskoryaet sheyper



##### tuning pautina ######

net.inet.ip.intr_queue_maxlen=10240	#256
net.inet.ip.fw.dyn_max=65535	#16384
kern.ipc.maxsockbuf=16777216    # (wscale  9)	# 2097152
net.inet.tcp.recvbuf_inc=65536    # (default 16384)
net.inet.tcp.recvbuf_max=4194304  # (default 2097152)
net.inet.tcp.recvspace=65536      # (default 65536)
net.inet.tcp.sendbuf_inc=65536    # (default 8192)
net.inet.tcp.sendbuf_max=4194304  # (default 2097152)
net.inet.tcp.sendspace=65536      # (default 32768)
net.inet.tcp.mssdflt=1460   # Option 1 (default 536)
net.inet.tcp.minmss=536  # (default 216)
net.inet.tcp.abc_l_var=44   # (default 2) if net.inet.tcp.mssdflt = 1460
net.inet.tcp.initcwnd_segments=44            # (default 10 for FreeBSD 11.2) if net.inet.tcp.mssdflt = 1460
net.inet.tcp.rfc6675_pipe=1  # (default 0)
net.inet.tcp.syncache.rexmtlimit=0  # (default 3)
net.inet.ip.maxfragpackets=0     # (default 31595)
net.inet.ip.maxfragsperpacket=0  # (default 16)
net.inet.tcp.syncookies=0  # (default 1)
net.inet.tcp.isn_reseed_interval=4500  # (default 0, disabled)
net.inet.tcp.tso=0  # (default 1)
dev.ix.0.fc=0  # (default 3)
dev.ix.0.iflib.rx_budget=65535  # (default 0, which is 16 frames)
kern.random.fortuna.minpoolsize=128  # (default 64)
kern.random.harvest.mask=65887  # (default 66047, FreeBSD 12 with Intel Secure Key RNG)
net.inet.raw.maxdgram=16384       # (default 9216)
net.inet.raw.recvspace=16384      # (default 9216)
net.local.stream.sendspace=16384  # (default 8192)
net.local.stream.recvspace=16384  # (default 8192)
net.route.netisr_maxqlen=2048       # (default 256)
hw.intr_storm_threshold=9000	# 1000
net.inet.icmp.reply_from_interface=1

net.bpf.optimize_writers=1           # bpf are write-only unless program explicitly specifies the read filter (default 0)
net.inet.ip.check_interface=1         # verify packet arrives on correct interface (default 0)
net.inet.ip.process_options=0         # ignore IP options in the incoming packets (default 1)
net.inet.ip.random_id=1               # assign a random IP_ID to each packet leaving the system (default 0)
net.inet.ip.redirect=0                # do not send IP redirects (default 1)
net.inet.icmp.drop_redirect=1         # no redirected ICMP packets (default 0)
net.inet.tcp.always_keepalive=0       # disable tcp keep alive detection for dead peers, keepalive can be spoofed (default 1)
net.inet.tcp.drop_synfin=1            # SYN/FIN packets get dropped on initial connection (default 0)
net.inet.tcp.fast_finwait2_recycle=1  # recycle FIN/WAIT states quickly (helps against DoS, but may cause false RST) (default 0)
net.inet.tcp.icmp_may_rst=0           # icmp may not send RST to avoid spoofed icmp/udp floods (default 1)
net.inet.tcp.msl=5000                 # Maximum Segment Lifetime is the time a TCP segment can exist on the network and is
                                      # used to determine the TIME_WAIT interval, 2*MSL (default 30000 which is 60 seconds)
net.inet.tcp.path_mtu_discovery=0     # disable MTU discovery since many hosts drop ICMP type 3 packets (default 1)
net.inet.udp.blackhole=1              # drop udp packets destined for closed sockets (default 0)
net.inet.tcp.blackhole=2              # drop tcp packets destined for closed ports (default 0)

 

ix0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=c538b8<VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,WOL_UCAST,WOL_MCAST,WOL_MAGIC,VLAN_HWFILTER,VLAN_HWTSO,TXCSUM_IPV6>
        ether 0c:c4:7a:4f:40:3e
        media: Ethernet autoselect (10Gbase-Twinax <full-duplex>)
        status: active
        nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>

 

rc.conf

ifconfig_ix0="up -rxcsum -txcsum -tso -lro"

на скринах проседание трафика в момент проблемы 19:30-19:35, и длится не долго 1-2мин максмимум, чаще всего до минуты

 

Изменено 17 января, 2022 пользователем WideAreaNetwork

[Ivan_83]

Параметры net.inet.ip, net.inet.tcp, net.inet.udp - они для трафика который предназначен этому хосту и на транзинтный не влияют. (кроме димминета)

 

В 17.01.2022 в 10:47, WideAreaNetwork сказал:

pf_load="YES"
ipfw_load="YES"
ipdivert_load="YES"

Оно точно надо?

Диверт вообще проц жрёт при работе через него.

 

 

В 17.01.2022 в 10:47, WideAreaNetwork сказал:

kern.random.harvest.mask=65887

Тут надо уточнять чтобы прерывания с сетевухи не захватывались, и вообще для роутера энтропия в рандоме не очень то и нужна.

 

А штормов/петель у вас в сети нет?

[WideAreaNetwork]

В 19.01.2022 в 06:16, Ivan_83 сказал:

Оно точно надо?

Диверт вообще проц жрёт при работе через него.

PF для ната

IPFW им управляет биллинг, дает/закрывает доступ во внешнюю сеть

IPDIVERT для заглушки

В 19.01.2022 в 06:16, Ivan_83 сказал:

А штормов/петель у вас в сети нет?

не должно быть (ловили такое ранее там поведение совсем другое), но проверим, спс

 

пока после обновлении безопасности и последующего ребута браса проблема не наблюдалась