LINUX.ORG.RU
ФорумAdmin

Не работает бондинг, если к 3 свичам подключить 6 лан-проводов

 


0

1

Здравствуйте.

В сети 3 свича:
SW1 HP 1820-48G Switch J9981A
SW2 HP 1820-48G Switch J9981A
SW2 HPE OfficeConnect Switch 1820 24G J9980A

Между собой соединены так:
SW1 Trunk(Port 50, 51) -> SW2 Trunk(Port 50, 51)
SW2 Trunk(Port 46, 48) -> SW3 Trunk(Port 24, 25)

На каждом свиче порты 1 и 2 объединены в Trunk. В эти порты подключаю провода от сервера.

На сервере Debian 12 установлено 6 сетевых карт:
Встроеная в материнку: 2.5Gb какая-то
Intel <EXPI9301CT> Сетевая карта 1 Гбит/с (1 x 1 Гбит/с, PCI Express)
Intel <Ethernet Server Adapter I350-T4 (I350T4BLK)> Сетевая карта 1 Гбит/с (4 x 1 Гбит/с, PCI Express)

Сеть перестаёт работать (сервак не виден в сети), если в один свич подключено 2 провода от сервера.

Как это выглядит, все подключения в 1 порт:
В SW1 подключая 1 провод от сервера.
В SW2 подключая 1 провод от сервера.
В SW3 подключая 1 провод от сервера.
Всё работает.

Если подключаю в любой свич (во 2-й порт) ещё один провод от сервера, то сервер больше не в сети.

root@fserver:/etc/network# cat interfaces
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).
#       bond-slaves enp6s0 enp1s0f0 enp1s0f1

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

# Frontend bond interface
auto bond0
iface bond0 inet static
        address 192.168.0.3/24
        gateway 192.168.0.1
        bond-slaves enp4s0 enp5s0 enp1s0f0 enp1s0f1 enp1s0f2 enp1s0f3
        bond-mode 6
        bond-miimon 50
        bond-downdelay 200
        bond-updelay 500
        dns-nameservers 192.168.0.1
        mtu 9000
root@fserver:/etc/network# ifconfig
bond0: flags=5187<UP,BROADCAST,RUNNING,MASTER,MULTICAST>  mtu 9000
        inet 192.168.0.3  netmask 255.255.255.0  broadcast 192.168.0.255
        ether 04:7c:16:b7:d4:f1  txqueuelen 1000  (Ethernet)
        RX packets 12117215  bytes 26896418862 (25.0 GiB)
        RX errors 0  dropped 406  overruns 0  frame 0
        TX packets 14402119  bytes 90865712754 (84.6 GiB)
        TX errors 0  dropped 2 overruns 0  carrier 0  collisions 0

enp1s0f0: flags=6147<UP,BROADCAST,SLAVE,MULTICAST>  mtu 9000
        ether 00:e0:ed:43:47:18  txqueuelen 1000  (Ethernet)
        RX packets 543  bytes 262560 (256.4 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 132  bytes 21722 (21.2 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device memory 0x80900000-8091ffff

enp1s0f1: flags=6211<UP,BROADCAST,RUNNING,SLAVE,MULTICAST>  mtu 9000
        ether 00:e0:ed:43:47:1b  txqueuelen 1000  (Ethernet)
        RX packets 1921728  bytes 2020118627 (1.8 GiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 8386752  bytes 54815544928 (51.0 GiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device memory 0x80920000-8093ffff

enp1s0f2: flags=6147<UP,BROADCAST,SLAVE,MULTICAST>  mtu 9000
        ether 00:e0:ed:43:47:1a  txqueuelen 1000  (Ethernet)
        RX packets 4979457  bytes 2812109424 (2.6 GiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1815851  bytes 11126428569 (10.3 GiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device memory 0x80940000-8095ffff

enp1s0f3: flags=6211<UP,BROADCAST,RUNNING,SLAVE,MULTICAST>  mtu 9000
        ether 04:7c:16:b7:d4:f1  txqueuelen 1000  (Ethernet)
        RX packets 3087320  bytes 12120738963 (11.2 GiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1728184  bytes 10004123808 (9.3 GiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device memory 0x80960000-8097ffff

enp4s0: flags=6211<UP,BROADCAST,RUNNING,SLAVE,MULTICAST>  mtu 9000
        ether 00:e0:ed:43:47:19  txqueuelen 1000  (Ethernet)
        RX packets 2127514  bytes 12605476263 (11.7 GiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 2464813  bytes 14865868728 (13.8 GiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device memory 0x82000000-820fffff

enp5s0: flags=6147<UP,BROADCAST,SLAVE,MULTICAST>  mtu 9000
        ether 68:05:ca:aa:9b:7b  txqueuelen 1000  (Ethernet)
        RX packets 653  bytes 47331 (46.2 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 6387  bytes 53724999 (51.2 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 17  memory 0x823c0000-823e0000

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 16630  bytes 4049322 (3.8 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 16630  bytes 4049322 (3.8 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

root@fserver:/etc/network#


Последнее исправление: INDIGO (всего исправлений: 1)

Я правильно понимаю, что ты собрал bond из 6 портов и подключил по 2 кабеля в каждый из коммутаторов? Может я чего не знаю, но такое вообще не должно работать.

На сервере Debian 12 установлено 6 сетевых карт:
Встроеная в материнку: 2.5Gb какая-то
Intel <EXPI9301CT> Сетевая карта 1 Гбит/с (1 x 1 Гбит/с, PCI Express)
Intel <Ethernet Server Adapter I350-T4 (I350T4BLK)> Сетевая карта 1 Гбит/с (4 x 1 Гбит/с, PCI Express)

Для сборки LACP все интерфейсы должны быть одного типа, не прокатит объеденить 1G и 2.5G в bond

Kolins ★★★★★
()
Ответ на: комментарий от Kolins

LACP - свичи не поддерживают, поэтому, в настройках Trank - Static Mode: Enabled

Да, собрал bond0 из 6 карт. Прикол в том, что если не использовать Trunk - то всё работает, но мне думается, правильнее будет подключать так: 2 порта объединить в Trunk, и уже в эти порты втыкать провода от сервера. Но это не точно.

Работает на 1Gb

root@fserver:~# ethtool enp4s0
Settings for enp4s0:
        Supported ports: [ TP ]
        Supported link modes:   10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Full
                                2500baseT/Full
        Supported pause frame use: Symmetric
        Supports auto-negotiation: Yes
        Supported FEC modes: Not reported
        Advertised link modes:  10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Full
                                2500baseT/Full
        Advertised pause frame use: Symmetric
        Advertised auto-negotiation: Yes
        Advertised FEC modes: Not reported
        Speed: 1000Mb/s
        Duplex: Full
        Auto-negotiation: on
        Port: Twisted Pair
        PHYAD: 0
        Transceiver: internal
        MDI-X: off (auto)
        Supports Wake-on: pumbg
        Wake-on: g
        Current message level: 0x00000007 (7)
                               drv probe link
        Link detected: yes

INDIGO
() автор топика
Последнее исправление: INDIGO (всего исправлений: 1)

Это называется https://en.wikipedia.org/wiki/Multi-chassis_link_aggregation_group. Но твои коммутаторы его не поддерживают. Да и вообще идея агрегации линков с разных коммутаторов провальная.

Почему бы не бросить агрегацию линков, и не попробовать Multipath TCP?

iliyap ★★★★★
()
Ответ на: комментарий от INDIGO

Да, собрал bond0 из 6 карт. А задачу ты какую решаешь?

Bond это двухсторонняя тема, настройки на сервере и коммутаторе должны быть готовы друг к другу. Чтобы бондить порты с разных коммутаторов – они должны быть стэкируемыми (и это тогда всё равно будет одним коммутатором, просто из двух+ железок). Ну или это должны быть active-backup схема.

Изучай: https://www.kernel.org/doc/Documentation/networking/bonding.txt

Ctrl-F: «11.2 High Availability in a Multiple Switch Topology»

BOOBLIK ★★★★
()
Ответ на: комментарий от BOOBLIK

Задача такая: на сервере targetcli, iSCSI сервер.

На коммутаторах сидят клиенты (Windos), которые через iSCSI используют ресурсы сервера.

Надо максимально увеличить скорость сети на сервере при текущем оборудовании.

INDIGO
() автор топика
Ответ на: комментарий от INDIGO

при текущем оборудовании

Подними на сервере три сетевых карты (бондинг двух портов в каждый из коммутаторов), отдавай инициаторам IP сервера смотрящий в сторону их (клиентов) коммутатора. Получишь по 2 Gbit в сторону каждой из групп клиентов.

BOOBLIK ★★★★
()
Ответ на: комментарий от iliyap

Внезапно!

А может мои коммутаторы поддерживают LACP?

И достаточно на всех, в настройках Trank - Static Mode: Disable ?

Вычитал в доке по свичам, Trunk Configuration Fields:

Dynamic—Dynamic trunks use the Link Aggregation Control Protocol (LACP, IEEE standard 802.3ad). An LACP-enabled port automatically detects the presence of other aggregation-capable network devices in the system and exchanges Link Aggregation Control Protocol Data Units (LACPDUs) with links in the trunk. The PDUs contain information about each link and enable the trunk to maintain them.

INDIGO
() автор топика
Последнее исправление: INDIGO (всего исправлений: 2)
Ответ на: комментарий от INDIGO

Если iSCSI, то инициатор должен поддерживать SCSI multipath. Не нужно никакого бондинга. Просто каждый ethernet порт сервера должен иметь свой IP-адрес, и каждый ethernet порт рабочих станций должен иметь свой IP-адрес. На каждой рабочей станции устанавливаешь iSCSI пути от каждого ethernet порта рабочей станции до каждого ethernet порта сервера.

Да, путей будет много. Например, если на рабочей станции два порта, и на сервере шесть портов, то между этой станцией и сервером двенадцать путей.

Инициатор должен делить нагрузку между путями – т.е. выбирать путь для отправки очередного SCSI запроса. Например, в линуксовом dm-multipath можно выбрать один из трёх алгоритмов выбора: round-robin (следующий путь по кругу), queue-length (путь с наименьшим количеством инфлайтов), service-time (путь с наименьшим средним временем отклика).

iliyap ★★★★★
()
Ответ на: комментарий от iliyap

Возможно, это и рабочая система, но очень муторная.

Я хочу всё это реализовать средствами настройки сетевых карт и коммутаторов. IMHO, это будет более правильно.

INDIGO
() автор топика
Ответ на: комментарий от anonymous

Вы предлагаете купить 3 коммутатора на 48 портов, у которых есть SFP 10Gb?

Если да, то цена таких железок для нашей организации высока.

INDIGO
() автор топика
Последнее исправление: INDIGO (всего исправлений: 1)
Ответ на: комментарий от INDIGO

LACP не умеет управлять агрегацией портов разных коммутаторов. В https://en.wikipedia.org/wiki/Multi-chassis_link_aggregation_group написано, что задача непростая, вендоры решали её героически, каждый по своему, решили только в больших дорогих коммутаторах. По сути там требуется реализовать распределённый коммутатор, коммутирующий кадры по единой таблице коммутации.

iliyap ★★★★★
()
Ответ на: комментарий от INDIGO

Вы предлагаете купить 3 коммутатора на 48 портов, у которых есть SFP 10Gb?

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

anonymous
()
Ответ на: комментарий от INDIGO

С помощью Multipath TCP смогу сделать 6Gb на сервере?

По-моему один 10-гигабитный интерфейс эту задачу решит лучше чем странное нагромождение свитчей и сетевух. И он уже не заоблачно стоит как когда-то раньше.

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 1)
Ответ на: комментарий от firkax

Это было бы самым просты решением, если бы не одно но - надо 2 свича на 48 портов и свич на 24. И все должный быть с 10Gb портами.

Подскажите, если знаете, модели таких коммутаторов.

INDIGO
() автор топика
Последнее исправление: INDIGO (всего исправлений: 1)
Ответ на: комментарий от firkax

Задача такая: на сервере targetcli, iSCSI сервер.

На коммутаторах сидят клиенты (Windos), которые через iSCSI используют ресурсы сервера.

Надо максимально увеличить скорость сети на сервере при текущем оборудовании.

INDIGO
() автор топика
Ответ на: комментарий от INDIGO

Заменить коммутатор таким у которого есть 2 или 4 sfp+ порта 10gb дополнительно к 1gb. На перспективу это кстати разумно, потом его можно будет воткнуть аплинком в 10gb «ядро». Купить в сервер сетевую с sfp+ и 10gb. Купить пару оптических модулей sfp+ (одномод или многомод, на небольшие расстояния они вменяемых денег стоят), купить патчкорд (два патчкорда). Можно взять медные 10gb SFP+, но я бы сразу про оптику думал.

PS. Я тоже сначала бондинг для iSCSI городил. А потом выяснил что одна сессия — один поток, и бондинг уже не бондинг. Переделал на 10gb оптику, пока доволен.

PS2. Раз уж тебе внезапно потребовалось агрегирование каналов — это сигнал о том что пора заняться дизайном сети, текущая топология очевидно уже «не тянет». В это нужно вложиться, но зато появится простор для масштабирования.

Рекомендую начать с замены 1gb свичей на чуть чуть более «взрослые» модели, с дополнительными 10gb SFP+ портами. Они потом будут использоваться как аплинк к «ядру», а пока ты можешь к ним файловые серверы подключать и\или объединять коммутаторы напрямую.

Затем приобрети 8-16 портовый 10gb коммутатор полностью с sfp+ портами. Используй его для агрегирования других коммутаторов и подключения серверов.

Это можно всё на меди делать в принципе, на «медных» sfp+ модулях, но я бы рекомендовал сразу оптику. По цене одинаково, но масштабируется оптика лучше.

Jameson ★★★★★
()
Последнее исправление: Jameson (всего исправлений: 5)
Ответ на: комментарий от INDIGO

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

Jameson ★★★★★
()
Ответ на: комментарий от INDIGO

Поддержу варинты:

  1. Не работает бондинг, если к 3 свичам подключить 6 лан-проводов (комментарий) стекируемые коммутаторы
  2. Не работает бондинг, если к 3 свичам подключить 6 лан-проводов (комментарий) агрегация по 2 линка к каждому коммутатору. Надо настраивать 3 IP интерфейса на сервере.
  3. Агрегацию линков с сервера делать к одному коммутатору, а сами коммутаторы соединять между собой также агрегацией линков. Выгодно когда коммутаторы не в одной серверной.
anonymous
()
Ответ на: комментарий от Jameson

С бондингом ты ничего существенно не улучшишь

Улучшишь и существенно даже если все интерфейсы по 1Gb. Ещё на скорость работы клиентов сильно влияет количество оперативы на сервере. Если на сервере используется своп, надо добавить оперативы.

anonymous
()
Ответ на: комментарий от BOOBLIK

Это хороший вариант.

Как бы я сделал. Схема подключения клиентов к коммутаторам, все клиенты в одной сети 192.168.0.0/24:

SW1: клиенты PC01... PC40
SW2: клиенты PC41... PC80
SW3: клиенты PC81... PC100

На сервере, поднимаю 3 сетевые карты: bond1, bond2, bond3. У каждой карты свой ip, подключаю так:
bond1 -> SW1
bond2 -> SW2
bond3 -> SW3

В настройках bond поставлю mode 6 (ALB).

Но тут есть один момент: допустим, работают только клиенты PC01 ... PC40, активно используют подключение к серверу и в итоге получаем картину: сетевая карта bond1 забита на 100%, остальные bond2 и bond3 простаивают. Я правильно понимаю?

Но есть вариант настройки инициаторов iSCSI на винде. В свойствах подключения можно указать несколько iSCSI целей (серверов) и выбрать политику сеансов! Называется MCS

Как вам такой вариант?

INDIGO
() автор топика
Последнее исправление: INDIGO (всего исправлений: 2)
Ответ на: комментарий от INDIGO

MC/S (multiple connections per session) это фича iSCSI, аналогичная по функциональности SCSI мультипасу. И с тем и с другим бондинг перестаёт быть необходимым. MC/S работает с шестью адресами iSCSI сервера ничем не хуже, чем с тремя адресами.

iliyap ★★★★★
()