LACP host FreeBSD - switch 3120-24SC

[WideAreaNetwork 222]

всем привет!

схема сети:  мир идет  в свитч 3120-24SC с него в сервер далее через вланы возвращается на этот же свич и потом на другие свичи

так как хост машина начинает захлебываться при трафике 750-800мбит+ нужно сделать агрегацию портов пока не приедет оборудование

 

и так на сервере сетевая 4*1Гб с ОС FreeBSD, далее идет свич D-link 3120-24SC, два порты в агрегации будут смотреть на мир , а другие два в локалку

сначала подгружаем модуль
 

#kldload if_lagg

и добавляем его в автозагрузку
 

echo 'if_lagg_load="YES"' >> /boot/loader.conf

в файле rc.conf создаем виртуальные интерфейсы для агрегации и вланов, потом для интерфейсов агрегации назначаем протокол LACP и указываем какие порты буду туда входить, первый указанный порт будет мастер портом, далее вланы навешиваем на интерфейсы для агрегации

  Цитата

 

cloned_interfaces="lagg0 lagg1 vlan501 vlan502 vlan503 vlan504 vlan505 vlan506 \
vlan507 vlan508"
ifconfig_bce0="up"
ifconfig_bce1="up"
ifconfig_bce2="up"
ifconfig_bce3="up"
ifconfig_lagg0="laggproto lacp laggport bce0 laggport bce1"
ifconfig_lagg1="laggproto lacp laggport bce2 laggport bce3"

ifconfig_vlan501="inet 10.10.10.10 netmask 255.255.255.0 vlan 501 vlandev lagg0"
ifconfig_vlan502="inet 10.10.20.10 netmask 255.255.255.0 vlan 502 vlandev lagg0"

 

ifconfig_vlan503="inet 10.10.30.10 netmask 255.255.255.0 vlan 503 vlandev lagg1"
ifconfig_vlan504="inet 10.10.40.10 netmask 255.255.255.0 vlan 504 vlandev lagg1"
ifconfig_vlan505="inet 10.10.50.10 netmask 255.255.255.0 vlan 505 vlandev lagg1"
ifconfig_vlan506="inet 10.10.60.10 netmask 255.255.255.0 vlan 506 vlandev lagg1"
ifconfig_vlan507="inet 10.10.70.10 netmask 255.255.255.0 vlan 507 vlandev lagg1"
ifconfig_vlan507_alias0="inet 10.10.71.10 netmask 255.255.255.0"
ifconfig_vlan508="inet 10.10.80.10 netmask 255.255.255.0 vlan 508 vlandev lagg1"

 

Expand  

 

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

create link_aggregation group_id 1 type lacp
create link_aggregation group_id 2 type lacp

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

config link_aggregation algorithm ip_destination или какой-то другой

потом указываем мастер порт и какие порты будут входить в агрегацию

config link_aggregation group_id 1 master_port 1 ports 1-2 state enable

config link_aggregation group_id 2 master_port 3 ports 3-4 state enable

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

config lacp_port 1-2 mode active или passive

config lacp_port 3-4 mode active или passive

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

Відредаговано 2020-02-07 20:34:43 WideAreaNetwork

[Baneff 161]

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

 

Во первых, зачем да лагга? Паралелить так паралелить - все четыре сетевухи в один лагг и максимально размазать исходящий трафик по физическим интерфейсам. Как-то так:

ifconfig_lagg0="laggproto lacp lagghash l2,l3,l4 laggport bce0 laggport bce1 laggport bce2 laggport bce3 up"

 

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

 

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

[nedoinet 441]

  В 07.02.2020 в 20:33, WideAreaNetwork сказав:

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

Expand  

Смотрите, алгоритмом lacp вы рулите исходящим трафиком. Балансировка входящего трафика обеспечивается противоположной стороной. На глинке включайте l4 port source dest не ошибетесь. Либо если у вас локалка раздает интернеты по дхцп - можно и ip source dest. За бондинг на фряхе думаю подскажут гуру. Может balance rr? 

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

Відредаговано 2020-02-07 22:02:13 nedoinet

[nedoinet 441]

Режим лацпа на 3120 выбирайте active во избежание проблем. 

[WideAreaNetwork 222]

  В 07.02.2020 в 21:52, Baneff сказав:

Во первых, зачем да лагга? Паралелить так паралелить - все четыре сетевухи в один лагг и максимально размазать исходящий трафик по физическим интерфейсам

Expand  

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

  В 07.02.2020 в 21:52, Baneff сказав:

lagghash l2,l3,l4

Expand  

это что дает?

  В 07.02.2020 в 21:52, Baneff сказав:

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

Expand  

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

  В 07.02.2020 в 21:52, Baneff сказав:

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

Expand  

4*1Г это и будет интеловская, я не помню как там называется интерфейс поэтому вписал который есть на встроенных, то-есть bce0

10 гигабитную заказал, пока агрегацией хочу решить временно проблему, пока не приедут

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

 

 

  В 07.02.2020 в 21:57, nedoinet сказав:

На глинке включайте l4 port source dest не ошибетесь. Либо если у вас локалка раздает интернеты по дхцп - можно и ip source dest.

Expand  

имеется ввиду algorithm ip_source-destination ? да авторизация по дхцп

  В 07.02.2020 в 21:57, nedoinet сказав:

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

Expand  

то-есть не нужна вначале на длинке прописать какие вланы на каких портах? ну все порты что будут входить в агрегированный интерфейс должны быть вроде одинаково настроены

 

  В 07.02.2020 в 22:02, nedoinet сказав:

Режим лацпа на 3120 выбирайте active во избежание проблем.

Expand  

понял

[nedoinet 441]

  В 07.02.2020 в 22:13, WideAreaNetwork сказав:

имеется ввиду algorithm ip_source-destination ?

Expand  

В Вашем случае подрйдет. А так в вебморде есть еще баланс по l4, как в консоли выглядит не подскажу.

  В 07.02.2020 в 22:13, WideAreaNetwork сказав:

то-есть не нужна вначале на длинке прописать какие вланы на каких портах?

Expand  

Проще сначала собрать лацп из ненастроеных портов, а потом чтоб несколько раз не писать одно и тоже закинуть потом все необходимое на мастер-порт. А если у вас уже куча настроек на портах, то перед сборкой в лацп привести все к одному виду... 

[Baneff 161]

  В 07.02.2020 в 22:13, WideAreaNetwork сказав:

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

это что дает?

Expand  

Ну лично мне кажется, что правильнее - один лагг. Тогда мы можем сильнее и равномернее нагрузить физические интерфейсы. Особенно выигрыш получается при ассиметричном трафике, когда в одну сторону летит больше, чем в обратную, как это обычно и бывает у метернет провайдеров. У нас в своё время работало так, возможно есть другие варианты, не знаю.

 

  В 07.02.2020 в 22:13, WideAreaNetwork сказав:

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

Expand  

Ну если там стояли две обычные сетевухи, то по любому больше чем где-то 850мбит/с они не прокачают ибо упрётся в физику самих карт. Если использовать именно гигабитные карты, то лагг - единственный выход. Если поставить правильную интеловскую гигабитную четырёхпортовку на правильном чипе (есть и неправильные), то получим на приём на каждый из четырёх физических интерфейсов по 8 буферов и соответственно по восемь прерываний, всего 32, если смотреть упрощённо, буфера и 32 прерывания. Процессор с двумя ядрами - маловато, хотя если очень быстрый, то потянет. У нас вроде 8 ядер было физических с выключенным гипертридингом, хорошо распаралеливалось, молотило прекрасно. А вообще это всё тут в соответствующее время широко обсуждалось, стоит поискать в архиве.

 

  В 07.02.2020 в 22:13, WideAreaNetwork сказав:

это что дает?

Expand  

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

lagghash l2,l3,l4

Этим мы задаём максимально возможное случайное равномрное распределение пакетов по интерфейсам, поскольку при хешировании учитыватся и MAC адреса (L2) и IP адреса (L3) и порты (L4). Возможно для каких то случаев оптимально будет по другому, не знаю. Но всё равно нужно учитывать, что одну сессию сос коростью больше 900мбит/с лагг не пропустит, поскольку всё полетит через один физический интерфейс. Такая байда хорошо работает, когда много сессий с относительно небольшими скоростями, как у мелкого провайдера, например. Чудес не бывает.

 

  В 07.02.2020 в 22:13, WideAreaNetwork сказав:

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

Expand  

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

Відредаговано 2020-02-08 08:17:28 Baneff

[KaYot 3 730]

Небольшие проблемы с терминологией.

Объединение портов в разных вселенных называется bonding, port channel, link aggregation group(LAGG). Последнее название наверное универсально.

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

Lacp протокол управления активным ЛАГГом.

 

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

Ну и режим балансировки зависит от трафика, для Вашего можно ставить любой, хоть L2 Mac src/dst, хоть L3 ip src/dst. Все это у длинка удобно конфигурится в морде.

И я бы делал 2 ЛАГГа, трафик один фиг к 2г не подойдёт в ближайшее время.

Відредаговано 2020-02-08 07:03:58 KaYot

[WideAreaNetwork 222]

  В 08.02.2020 в 05:18, Baneff сказав:

Само размажется, тем более два ядра, особо мазать нечего.

Expand  

сори не написал, стоит 2 проца по 4 ядра каждый, это встроенные забивают только 2 ядра

  В 08.02.2020 в 07:01, KaYot сказав:

И я бы делал 2 ЛАГГа, трафик один фиг к 2г не подойдёт в ближайшее время.

Expand  

не дойдет ибо поставится 10г карта, ждем ее    

 

с хост машиною все понятно по настройкам

на длинке я так понимаю при выборе алгоритма нет особой разницы какой ставить на свиче, там аж 9 видов, глаза разбежались )))

с режимом портов мнение разделилось, но наверное можно как активный так и пассивный

  В 08.02.2020 в 05:18, Baneff сказав:

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

Expand  

буду благодарен, искал по ключевым словам lacp и lagg , ничего нету

 

Відредаговано 2020-02-08 08:10:03 WideAreaNetwork

[WideAreaNetwork 222]

  В 08.02.2020 в 07:46, WideAreaNetwork сказав:

стоит 2 проца по 4 ядра каждый

Expand  

 

[KaYot 3 730]

  В 08.02.2020 в 07:46, WideAreaNetwork сказав:

искал по ключевым словам lacp и lagg , ничего нету

Expand  

Freebsd LAGG в Гугле - сразу выбивает кучу мануалов с примерами.

Там делов то на 2 строчки.

Ну а балансировку на длинке сразу ставь по L3 ip, потом можно менять онлайн без обрыва связи.

[Baneff 161]

  В 08.02.2020 в 07:46, WideAreaNetwork сказав:

сори не написал, стоит 2 проца по 4 ядра каждый, это встроенные забивают только 2 ядра

Expand  

Ну тогда если будет правильная интеловская четырёхпортовка или правильная 10-гиговая карта, то на 8 ядер нагрузка должна быть более-менее равномерная.

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

 

  В 08.02.2020 в 07:46, WideAreaNetwork сказав:

не дойдет ибо поставится 10г карта, ждем ее    

Expand  

Какую конкретно карту купили, тип, чип?

 

  В 08.02.2020 в 07:46, WideAreaNetwork сказав:

на длинке я так понимаю при выборе алгоритма нет особой разницы какой ставить на свиче, там аж 9 видов, глаза разбежались )))

Expand  

Осторожно! Разница есть! От выбора алгоритма зависит насколько равномерно будут распределятся по интерфейсам пакеты, передаваемые свичём в сторону компа. При неправильном выборе может выйти, что трафик пойдёт по интерфейсам несимметрично или, например, даже весь пойдёт через один интерфейс. Это зависит от окружающей сети и типа передаваемого трафика. Я бы включал на всякий случай все возможные алгоритмы ибо хуже от этого не будет точно, а польза может быть.

 

  В 08.02.2020 в 07:46, WideAreaNetwork сказав:

с режимом портов мнение разделилось, но наверное можно как активный так и пассивный

Expand  

Я не силён в терминологии длинка, но подозреваю, что активный - это именно то, что первоначально и называлось LACP. Каждая пара портов с двух сторон посылает служебную информацию для контроля работоспособности линии. Так что если уж вы ставите на фре laggproto lacp , то и с другой стороны нужно ставить аналогичный режим, то есть скорее всего активный. Иначе, как вам уже тут писали, будут проблемы.

 

  В 08.02.2020 в 07:46, WideAreaNetwork сказав:

буду благодарен, искал по ключевым словам lacp и lagg , ничего нету

Expand  

Обсуждение и тут и на nag.ru біло вроде под названием "Софт роутер" или как-то так.

А конфиги - ещё раз говорю, они железозависимые, скажите какую карту ставите, тип, чип?

[WideAreaNetwork 222]

  В 08.02.2020 в 09:11, Baneff сказав:

скажите какую карту ставите, тип, чип?

Expand  

настройки LAGG для карты HP NC365T - https://servak.com.ua/image/manual/Ethernet/Ethernet_4-Port_HP_NC365T_Gigabit_RJ-45_Hight_593743-001_Quick_Specs_Servak.PDF

она поддерживает msi-x, Network Controller Chipsets Intel 82580

 

а потом приедут 10Г HP 560SFP+ - https://servak.com.ua/image/manual/Ethernet/HPE_Ethernet_10Gb_2-port_560SFP+_Adapter__User_Guide_Servak.pdf

https://servak.com.ua/image/manual/Ethernet/HPE_Ethernet_10Gb_2-port_560SFP+_Adapter__Quick_Specs_Servak.pdf

контроллер на борту будет Intel 82599

[Baneff 161]

  В 08.02.2020 в 12:17, WideAreaNetwork сказав:

настройки LAGG для карты HP NC365T - https://servak.com.ua/image/manual/Ethernet/Ethernet_4-Port_HP_NC365T_Gigabit_RJ-45_Hight_593743-001_Quick_Specs_Servak.PDF

она поддерживает msi-x, Network Controller Chipsets Intel 82580

 

а потом приедут 10Г HP 560SFP+ - https://servak.com.ua/image/manual/Ethernet/HPE_Ethernet_10Gb_2-port_560SFP+_Adapter__User_Guide_Servak.pdf

https://servak.com.ua/image/manual/Ethernet/HPE_Ethernet_10Gb_2-port_560SFP+_Adapter__Quick_Specs_Servak.pdf

контроллер на борту будет Intel 82599

Expand  

Чипы правильные. По поводу карт HP ничего сказать не могу, мы всегда ставили только родные Intel. Молитесь, чтобы стандартные драйвера подошли и чтобы HP ничего там не добавили полезного с их точки зрения, типа совместимости только с родными модулями. А так - всё по идее должно получиться.

Далее. Какая версия фри? Конфиги зависят.

[WideAreaNetwork 222]

  В 08.02.2020 в 12:40, Baneff сказав:

Какая версия фри?

Expand  

сейчас

FreeBSD 11.3-RELEASE-p5

но ее по мере необходимости патчим и обновляем

[Baneff 161]

Это хорошо, что 11-я, в 12-й уже всё поменялось. Так что наш старый конфиг должен по идее лечь нормально.

Вот что откопал. Почему именно так - хз, я не помню уже. Возможно не до конца оптимально, но работало.

Ниже только то, что касается сетевой подсистемы.

 

> cat /sys/amd64/conf/AMD64

cpu             HAMMER
ident           AMD64

options         IPFIREWALL
options         IPFIREWALL_VERBOSE
options         IPFIREWALL_VERBOSE_LIMIT=10
options         IPFIREWALL_DEFAULT_TO_ACCEPT
options         DUMMYNET
options         IPDIVERT
options         IPFIREWALL_NAT
options         LIBALIAS

options         HZ=1000
device          lagg
device          netmap
options         TEKEN_UTF8              # UTF-8 output handling
options         TCP_RFC7413

# No Debugging support.
nooptions       INVARIANTS
nooptions       INVARIANT_SUPPORT
nooptions       WITNESS
nooptions       WITNESS_SKIPSPIN
nooptions       DEADLKRES

...

[slipped]

...

>

 

> cat /boot/loader.conf

machdep.hyperthreading_allowed=0
# https://calomel.org/network_performance.html
net.inet.tcp.syncache.hashsize=1024   # (def=512) syncache hash size
net.inet.tcp.syncache.bucketlimit=100 # (def=30)  syncache bucket limit
net.inet.tcp.tcbhashsize=4096         # (def=512) tcb hash size

# Number of transmit descriptors per queue:
hw.igb.txd=4096
# Number of receive descriptors per queue:
hw.igb.rxd=4096

# MSIX should be the default for best performance,
# but this allows it to be forced off for testing.
# Enable MSI-X interrupts:
# hw.igb.enable_msix: 1
hw.igb.enable_msix=1

# Tuneable Interrupt rate
# Maximum interrupts per second:
# hw.igb.max_interrupt_rate: 8000
hw.igb.max_interrupt_rate=32000

# Header split causes the packet header to be dma'd to a seperate mbuf from
# the payload. This can have memory alignment benefits. But another plus is
# that small packets often fit into the header and thus use no cluster. Its
# a very workload dependent type feature.
# Enable receive mbuf header split:
# hw.igb.header_split: 0
hw.igb.header_split=1

# This will autoconfigure based on the number of CPUs if left at 0.
# Number of queues to configure, 0 indicates autoconfigure:
# hw.igb.num_queues: 0
hw.igb.num_queues=8

# How many packets rxeof tries to clean at a time.
# Maximum number of received packets to process at a time, -1 means unlimited:
# hw.igb.rx_process_limit: 100
hw.igb.rx_process_limit=1000

# Allow the administrator to limit the number of threads (CPUs) to use for
# netisr.  We don't check netisr_maxthreads before creating the thread for
# CPU 0, so in practice we ignore values <= 1.  This must be set at boot.
# We will create at most one thread per CPU.
# Use at most this many CPUs for netisr processing.
#net.isr.maxthreads: 1
net.isr.maxthreads=7

# Bind netisr threads to CPUs.
#net.isr.bindthreads: 0
net.isr.bindthreads=0

# Limit per-workstream mbuf queue limits s to at most net.isr.maxqlimit,
# both for initial configuration and later modification using
# netisr_setqlimit().
# Maximum netisr per-protocol, per-CPU queue depth.
#net.isr.maxqlimit: 10240
net.isr.maxqlimit=16384

# The default per-workstream mbuf queue limit for protocols that don't
# initialize the nh_qlimit field of their struct netisr_handler.  If this is
# set above netisr_maxqlimit, we truncate it to the maximum during boot.
# Default netisr per-protocol, per-CPU queue limit if not set by protocol
#net.isr.defaultqlimit: 256
net.isr.defaultqlimit=4096

# Attention! When combining interfaces in lagg, consider the influence of net.link.ifqmaxlen !!!
# Outgoing interface queue length for lagg/bridge/tun/tap
net.link.ifqmaxlen=10240

>

 

 cat /etc/sysctl.conf
# AIM: Adaptive Interrupt Moderation which means that the interrupt rate
# is varied over time based on the traffic for that interrupt vector
# Enable adaptive interrupt moderation:
# hw.igb.enable_aim: 1
hw.igb.enable_aim=1

# These sysctls were used in previous versions to control and export
# dispatch policy state.  Now, we provide read-only export via them so that
# older netstat binaries work.  At some point they can be garbage collected.
#net.isr.direct
#net.isr.direct_force
# Three global direct dispatch policies are supported:
#net.isr.dispatch=deferred (old net.isr.direct=0 net.isr.direct_force=0)
# NETISR_DISPATCH_QUEUED: All work is deferred for a netisr, regardless of
# context (may be overriden by protocols).
#net.isr.dispatch=hybrid (old net.isr.direct=1 net.isr.direct_force=0)
# NETISR_DISPATCH_HYBRID: If the executing context allows direct dispatch,
# and we're running on the CPU the work would be performed on, then direct
# dispatch it if it wouldn't violate ordering constraints on the workstream.
#net.isr.dispatch=direct (old net.isr.direct=1 net.isr.direct_force=1)
# NETISR_DISPATCH_DIRECT: If the executing context allows direct dispatch,
# always direct dispatch.  (The default.)
#net.isr.dispatch=deferred
net.isr.dispatch=direct

# Фактически - размеры входящей и исходящей очередей.
# При большой нагрузке в режиме маршрутизации есть смысл увеличивать.
# Непоместившийся пакет выбрасывается. Это условно спасет при кратковременных
# перегрузках (часть покетов пролетит с большой задержкой) но
# совершенно не спасет при хроничеких.
net.route.netisr_maxqlen=8192

# Обрабатывать входящие пакеты непосредственно в момент приема
# (в т.ч. # прохождение ipfw на входе, до попадания в очередь netisr).
# Есть смысл включать, если количество ядер меньше или равно количеству
# сетевых карточек. Влияет на скорость ПРИЕМА пакетов.
# Обработка пакета происходит прямо в обработчике прерывания.
#net.inet.ip.fastforwarding=0
net.inet.ip.fastforwarding=1

# http://www.opennet.ru/docs/RUS/GigabitEthernet/
net.inet.ip.intr_queue_maxlen=10240
kern.ipc.maxsockbuf=8388608
net.inet.tcp.sendspace=3217968
net.inet.tcp.recvspace=3217968
#kern.ipc.nmbclusters=400000
kern.ipc.maxsockbuf=83886080

# http://download.intel.com/design/network/applnots/ap450.pdf
# http://serverfault.com/questions/64356/freebsd-performance-tuning-sysctls-loader-conf-kernel
# http://dadv.livejournal.com/139170.html

# Доп. настройка сетевух.
dev.igb.0.rx_processing_limit=4096
dev.igb.1.rx_processing_limit=4096
dev.igb.2.rx_processing_limit=4096
dev.igb.3.rx_processing_limit=4096
>

 

[WideAreaNetwork 222]

  В 08.02.2020 в 13:37, Baneff сказав:

Ниже только то, что касается сетевой подсистемы.

Expand  

дабы не компилить ядро большой проблемой будет подтягивать настройки с loader.conf

IPFW PF IPDIVERT DUMMYNET - все это и так с конфиг файла идет, думаю остальное также можно ним подгрузить, прошли времена недостатка памяти

 

спасибо за конфиги

  В 08.02.2020 в 13:37, Baneff сказав:

в 12-й уже всё поменялось.

Expand  

а что не так? названия параметров изменили?

[Baneff 161]

  В 08.02.2020 в 14:52, WideAreaNetwork сказав:

дабы не компилить ядро большой проблемой будет подтягивать настройки с loader.conf

IPFW PF IPDIVERT DUMMYNET - все это и так с конфиг файла идет, думаю остальное также можно ним подгрузить, прошли времена недостатка памяти

 

спасибо за конфиги

а что не так? названия параметров изменили?

Expand  

Да, конечно, то что можно грузить модулями можете грузить. Это я по привычке. Хотя ipfw, если вы его используете, насколько я помню, в виде подгружаемого модуля до сих пор неполнофункциональный. Я до сих пор по убираю все лишнее из ядра и мира, ибо это опять стало актуально на виртуальных хостингах, там за память и ядра платить надо, а я жадный

Да, системные переменные сильно изменены с 12-й версии и даже драйвера интеловских сетевух переименовали. igb уже там нету, пичалька.

[NaviNavi 86]

Много где встречал пишут при лаге на длинке ставить пассивный режим если на другой стороне стоит другой вендор или сервак. По поводу алгоритма всегда ставим ip-source-dest

[nedoinet 441]

  В 08.02.2020 в 19:39, NaviNavi сказав:

Много где встречал пишут при лаге на длинке ставить пассивный режим если на другой стороне стоит другой вендор или сервак. По поводу алгоритма всегда ставим ip-source-dest

Expand  

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

[muff 116]

Возможно пригодится.
Настройка LACP на некоторых железках.

[WideAreaNetwork 222]

  В 08.02.2020 в 21:53, muff сказав:

Возможно пригодится.
Настройка LACP на некоторых железках.

Expand  

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

[RockManX 9]

зачем городить LACP? если оно в одной стойке то достаточно статической агрегации laggproto loadbalance

 

а как распределена нагрузка по вланам? может проще без агрегации раскидать вланы по интерфейсам, если каждый из них не превышает ~800

[WideAreaNetwork 222]

  В 10.02.2020 в 07:02, RockManX сказав:

зачем городить LACP? если оно в одной стойке то достаточно статической агрегации laggproto loadbalance

 

а как распределена нагрузка по вланам? может проще без агрегации раскидать вланы по интерфейсам, если каждый из них не превышает ~800

Expand  

И как это поможет решить проблему интегрированных сетевых карт? Когда при 750мбит+ у всех скорость падает практически до нуля?

[WideAreaNetwork 222]

  В 08.02.2020 в 08:18, WideAreaNetwork сказав:

 

Expand  

пока так, трафик должен вечером почти в два раза вырасти

 

 

пока без тюнинга, предстоит еще изучить что можно/нужно крутить в sysctl.conf и loader.conf

Відредаговано 2020-02-10 12:34:36 WideAreaNetwork