Jump to content
Local
WideAreaNetwork

LACP host FreeBSD - switch 3120-24SC

Recommended Posts

всем привет!

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

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

Edited by WideAreaNetwork

Share this post


Link to post
Share on other sites

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

 

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

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

 

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

 

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

  • Like 1

Share this post


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

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

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

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

Edited by nedoinet
  • Like 1

Share this post


Link to post
Share on other sites

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

  • Like 1

Share this post


Link to post
Share on other sites
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 во избежание проблем.

понял

Share this post


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

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

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

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

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

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

  • Thanks 1

Share this post


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

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

это что дает?

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

 

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

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

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

 

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

это что дает?

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

lagghash l2,l3,l4

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

 

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

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

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

Edited by Baneff
  • Thanks 1

Share this post


Link to post
Share on other sites

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

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

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

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

 

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

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

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

Edited by KaYot
  • Thanks 2

Share this post


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

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

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

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

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

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

 

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

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

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

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

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

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

 

Edited by WideAreaNetwork

Share this post


Link to post
Share on other sites
42 минуты назад, WideAreaNetwork сказал:

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

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

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

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

  • Thanks 1

Share this post


Link to post
Share on other sites
55 минут назад, WideAreaNetwork сказал:

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

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

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

 

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

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

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

 

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

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

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

 

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

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

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

 

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

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

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

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

  • Thanks 1

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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 ничего там не добавили полезного с их точки зрения, типа совместимости только с родными модулями. А так - всё по идее должно получиться.

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

  • Thanks 1

Share this post


Link to post
Share on other sites
18 минут назад, Baneff сказал:

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

сейчас

FreeBSD 11.3-RELEASE-p5

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

Share this post


Link to post
Share on other sites

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

 

  • Thanks 1

Share this post


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

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

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

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

 

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

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

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

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

Share this post


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

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

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

 

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

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

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

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

Share this post


Link to post
Share on other sites

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

Share this post


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

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

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

Share this post


Link to post
Share on other sites

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

 

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

Share this post


Link to post
Share on other sites
39 минут назад, RockManX сказал:

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

 

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

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

Share this post


Link to post
Share on other sites
В 08.02.2020 в 10:18, WideAreaNetwork сказал:

 

serv.png

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

 

lagg0.png

 

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

Edited by WideAreaNetwork

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

  • Recently Browsing   0 members

    No registered users viewing this page.

  • Similar Content

    • By NaviNavi
      Привет всем. Есть 2 коммутатора d-link (3200-28 и 3200-18), создал группу портов на 1 коммутаторе в лацп 2,4,6,8 (2 порт мастер), на втором лацп 1,3,5,7 (7 порт мастер). Соединил 2 с 1, 4 с 3, 6 с 5, 8 с 7, вопрос что будет с лацп если оба мастер порта будут в down? Соберется ли лацп без мастер порта, какие могут быть последствия если мастер порт на ведущем SW постоянно в статусе up/down? 
    • By melvin
      А кто подскажет как собрать агрегацию, но при условии следующего конфига:
      Конфиг uplink порта:
       
       
      interface GigaEthernet0/6  switchport trunk vlan-allowed 10  switchport mode trunk switchport pvid 10 dhcp snooping trust   Пробывал вот такой вариант:   interface Port-aggregator1  switchport trunk vlan-allowed 10  switchport mode trunk  switchport pvid 10  dhcp snooping trust ! interface GigaEthernet0/6  switchport trunk vlan-allowed 10  switchport mode trunk  switchport pvid 10  dhcp snooping trust  aggregator-group 1 mode lacp !          interface GigaEthernet0/7  switchport trunk vlan-allowed 10  switchport mode trunk  switchport pvid 10  dhcp snooping trust  aggregator-group 1 mode lacp   Не прокатывает. Трафик не бегает. с uplink портов даже не летят маки. Может быть дело в том, что нужно добавлять в vlan-allowed 1 vlan ?  
    • By BALTAR
      Построен в данный момент транк между Mikrotik CCR 1036 и Extreme x450-24x в режиме 802.3ad двумя sfp 1g портами, но к сожалению по неизвестным причинах больше 1g не пролазит через данный бондинг!
      CCR поддерживает round-robin balance, но к сожалению Extreme нет, советчики говорят что затык именно в моде 802.3ad, а проверить нечем, noc прова говорит что проблема на нашей стороне, хотя мы не упираемся по загрузке процессора и шины.
      Исходя из этого, какие маршрутизаторы не Mikrotik поддерживают и round-robin и 802.3ad?
      Или как еще попытаться выйти с этой ситуации, где noc уверен что трабл у нас?
    • By morfey
      Есть сервер с дебианом bonding 802.3ad. Двумя портами смотрит в микротик, и еще двумя в DGS-3120. К 3120 подключены клиентские свичи доступа.
      Но никаким алгоритмом балансировки на 3120 не могу повлиять на входящий траффик. И в итоге получается, что на одной карте полка и начинаются потери, а другая даже на 50% не загружена.
       
      На линуксе пробовал  разные Transmit Hash Policy. Не помогло.
      Стык с микротиком работает ровно.
      Настройка DGS-3120
      #show link_aggregation Command: show link_aggregation Link Aggregation Algorithm = IP-Source-Dest Group ID : 1 Type : LACP Master Port : 1:1 Member Port : 1:1-1:2 Active Port : 1:1-1:2 Status : Enabled Flooding Port : 1:1 Trap : Disabled #show lacp_port 1,2 Command: show lacp_port 1:1-1:2 Port Activity ----- -------- 1:1 Active 1:2 Active # cat /proc/net/bonding/bond0 Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011) Bonding Mode: IEEE 802.3ad Dynamic link aggregation Transmit Hash Policy: layer3+4 (1) MII Status: up MII Polling Interval (ms): 0 Up Delay (ms): 0 Down Delay (ms): 0 802.3ad info LACP rate: slow Min links: 0 Aggregator selection policy (ad_select): stable Active Aggregator Info: Aggregator ID: 1 Number of ports: 2 Actor Key: 17 Partner Key: 1 Partner Mac Address: ec:22:80:3c:31:e0 Slave Interface: eth0 MII Status: up Speed: 1000 Mbps Duplex: full Link Failure Count: 0 Permanent HW addr: 00:26:55:51:15:9a Aggregator ID: 1 Slave queue ID: 0 Slave Interface: eth1 MII Status: up Speed: 1000 Mbps Duplex: full Link Failure Count: 0 Permanent HW addr: 00:26:55:51:15:9c Aggregator ID: 1 Slave queue ID: 0
    • By DenimMark
      Добрый день.
       
      Есть два канала по ~500М интернет. Заходят оптикой 1G на порты DGS-3120-24TC. К этому же комутатору подключен роутер на FreeBSD одной карточкой на 1G. Хочется принять с каждого канала по 600-700М. Для этого предлагается подключить еще одну карточку 1G с роутера на комутатор. Создать на роутере lagg на комутаторе построить port trunking группу. Спрашивается у кого работает реально такая схема ? В теории вроде как должно работать. Подводные камни ? Увеличится ли загрузка комутатора ? Еще что то такое вылезет. Уже надо бы смотреть на 10G, но хотелось бы еще протянуть чуть чуть, учитывая сколько сегодня 24х10G стоит.
       
       
       
×