LACP host FreeBSD - switch 3120-24SC

[WideAreaNetwork]

всем привет!

схема сети:  мир идет  в свитч 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"

 

 

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

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

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

Изменено February 7, 2020 at 20:34 пользователем WideAreaNetwork

[Baneff]

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

 

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

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

 

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

 

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

[nedoinet]

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

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

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

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

Изменено February 7, 2020 at 22:02 пользователем nedoinet

[nedoinet]

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

[WideAreaNetwork]

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

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

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

10 минут назад, Baneff сказал:

lagghash l2,l3,l4

это что дает?

11 минут назад, Baneff сказал:

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

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

13 минут назад, Baneff сказал:

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

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

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

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

 

 

12 минут назад, nedoinet сказал:

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

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

14 минут назад, nedoinet сказал:

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

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

 

10 минут назад, nedoinet сказал:

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

понял

[nedoinet]

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

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

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

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

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

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

[Baneff]

10 часов назад, WideAreaNetwork сказал:

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

это что дает?

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

 

10 часов назад, WideAreaNetwork сказал:

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

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

 

10 часов назад, WideAreaNetwork сказал:

это что дает?

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

lagghash l2,l3,l4

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

 

10 часов назад, WideAreaNetwork сказал:

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

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

Изменено February 8, 2020 at 08:17 пользователем Baneff

[KaYot]

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

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

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

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

 

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

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

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

Изменено February 8, 2020 at 07:03 пользователем KaYot

[WideAreaNetwork]

2 часа назад, Baneff сказал:

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

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

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

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

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

 

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

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

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

2 часа назад, Baneff сказал:

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

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

 

Изменено February 8, 2020 at 08:10 пользователем WideAreaNetwork

[WideAreaNetwork]

31 минуту назад, WideAreaNetwork сказал:

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

 

[KaYot]

42 минуты назад, WideAreaNetwork сказал:

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

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

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

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

[Baneff]

55 минут назад, WideAreaNetwork сказал:

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

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

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

 

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

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

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

 

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

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

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

 

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

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

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

 

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

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

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

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

[WideAreaNetwork]

2 часа назад, Baneff сказал:

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

настройки 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]

18 минут назад, 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

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

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

[WideAreaNetwork]

18 минут назад, Baneff сказал:

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

сейчас

FreeBSD 11.3-RELEASE-p5

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

[Baneff]

Это хорошо, что 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]

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

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

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

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

 

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

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

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

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

[Baneff]

2 часа назад, WideAreaNetwork сказал:

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

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

 

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

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

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

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

[NaviNavi]

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

[nedoinet]

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

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

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

[muff]

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

[WideAreaNetwork]

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

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

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

[RockManX]

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

 

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

[WideAreaNetwork]

39 минут назад, RockManX сказал:

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

 

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

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

[WideAreaNetwork]

В 08.02.2020 в 10:18, WideAreaNetwork сказал:

 

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

 

 

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

Изменено February 10, 2020 at 12:34 пользователем WideAreaNetwork