Коллеги, доброго времени!Подскажите собственно как организовать сабж?
Насколько я представляю - bond-интерфейс, состоящий из пары bond-интерфейсов, только как это организовать?
> Коллеги, доброго времени!
> Подскажите собственно как организовать сабж?
> Насколько я представляю - bond-интерфейс, состоящий из пары bond-интерфейсов, только как
> это организовать?1. STP вроде именно для таких случаев придуман был.
2. что мешает собрать LACP из 4-х интерфейсов? LACP много всякого разного, в том числе и бекап интерфейсы.Ну и постановку решаемой проблемы не мешало бы,
> Коллеги, доброго времени!
> Подскажите собственно как организовать сабж?
> Насколько я представляю - bond-интерфейс, состоящий из пары bond-интерфейсов, только как
> это организовать?И кстати - LACP и bond вот совсем не одно и то же.
> Коллеги, доброго времени!
> Подскажите собственно как организовать сабж?
> Насколько я представляю - bond-интерфейс, состоящий из пары bond-интерфейсов, только как
> это организовать?Забудь про bond - используй team.
>> Насколько я представляю - bond-интерфейс, состоящий из пары bond-интерфейсов, только как
>> это организовать?
> Забудь про bond - используй team.И забудь про LACP в линухе для параллеливания трафика. Не работает, глюки.
Хочешь много проводов - используй другие протоколы. Сильно советую забираться L3+ уровни. Лучше всего на L7.
> И забудь про LACP в линухе для параллеливания трафика. Не работает, глюки.C bond - не работает, да и не должно, с team - вроде как работает... Коммутатор на той стороне какой?
>> И забудь про LACP в линухе для параллеливания трафика. Не работает, глюки.
> C bond - не работает, да и не должно,С чего вдруг??
xmit_hash_policy умеет 5 разных вариантов, в том числе layer3+4 , т.е. балансит на основе IP+Port (для TCP & UDP) и прекрасно работает.
https://github.com/jpirko/libteam/wiki/Bonding-vs.-Team-feat...load-balancing for LACP support NO для bound
> https://github.com/jpirko/libteam/wiki/Bonding-vs.-Team-feat...
> load-balancing for LACP support NO для boundПервоисточники говорят обратное
https://www.kernel.org/doc/Documentation/networking/bonding.txt
Практика кстати тоже....
>> https://github.com/jpirko/libteam/wiki/Bonding-vs.-Team-feat...
>> load-balancing for LACP support NO для bound
> Первоисточники говорят обратное
> https://www.kernel.org/doc/Documentation/networking/bonding.txt
> Практика кстати тоже....Ну так пожалуйста внимательно читайте первоисточники - LACP, он же - 802.3ad, он же - mode 4 и в ее описание нет НИ СЛОВА про load-balancing. Хотя в описаниях mode 0, 2, 5 и 6 - он явно упоминается. Но только они - ну ни разу не LACP и не являются с ними совместимыми.
А практика показывает что при mode 4 весь трафик прет через один интерфейс (коммутатор - настроен корретно если что) и единственное что обесточивает это fault tolerance, но не load balancing. При настройке team - работает и то и то.
>[оверквотинг удален]
>> Практика кстати тоже....
> Ну так пожалуйста внимательно читайте первоисточники - LACP, он же - 802.3ad,
> он же - mode 4 и в ее описание нет НИ
> СЛОВА про load-balancing. Хотя в описаниях mode 0, 2, 5 и
> 6 - он явно упоминается. Но только они - ну ни
> разу не LACP и не являются с ними совместимыми.
> А практика показывает что при mode 4 весь трафик прет через один
> интерфейс (коммутатор - настроен корретно если что) и единственное что обесточивает
> это fault tolerance, но не load balancing. При настройке team -
> работает и то и то.xmit_hash_policy
Selects the transmit hash policy to use for slave selection in
balance-xor, 802.3ad, and tlb modes.Специально вот только что посмотрел на 2-х серверах с bond-ингом по 802.3ad и xmit_hash_policy=layer3+4
BONDING_OPTS="downdelay=0 miimon=100 mode=4 updelay=0 lacp_rate=1 xmit_hash_policy=layer3+4"
и распределение трафика за сутки между 2-мя интерфейсами 50.6% на 49,4%
Это нельзя назвать "чистым" лоадбалансером.
это разделение трафика на 2 потока по определенным критериям, но выбор критериев обеспечивает почти равномерную загрузку по обоим интерфейсам.
Как-то так.
Ну соглашусь - накостылить некое подобие load balancing можно. Но именно тот load balancing, который предусмотрен в 802.3ad - не поддерживается.
> Ну соглашусь - накостылить некое подобие load balancing можно. Но именно тот
> load balancing, который предусмотрен в 802.3ad - не поддерживается.Ну для полноты картины -- с вас ссылка на описания "load balancing, который предусмотрен в 802.3ad" пожалуйста.
про 802.3ad:
Алгоритм распределения фреймов по каналам там жестко не задан и его реализация на совести вендора, например у juniper на некоторых EX-.... линейках он вообще "жестко зашит" (он есть такой, какой есть и иного не дано по определению), у дешёвых L2 железок основан исключительно на MAC адресах ну и т.д.Есть там еще фича в виде резервных линков, типа объединять можно до 16 интерфейсов, но активных не более 8, и если какой-то активный "падает" - один из запасных встает в строй, и можно указать "минимальный порог", допустим при указании 4 -- если осталось менее 4-х рабочих интерфейсов то весь агрегат переходит в down состояние, так сказать обеспечить нужное качество.
Жестко не задан не значит что не определены его варианты :)
https://howdoesinternetwork.com/2018/lacp-link-aggregation
> Коллеги, доброго времени!
> Подскажите собственно как организовать сабж?Непонятно, зачем именно "поверх 2х LACP".
Посмотрите секцию "2. Bonding Driver Options" в https://www.mjmwired.net/kernel/Documentation/networking/bon..., выбирайте на вкус.> Насколько я представляю - bond-интерфейс, состоящий из пары bond-интерфейсов, только как
> это организовать?"В лоб" пробовали?
Не думаю что это будет оптимально, но вы ничего не написали про конкретную задачу которыю вы пытаетесь решить.
> "В лоб" пробовали?
> Не думаю что это будет оптимально, но вы ничего не написали про
> конкретную задачу которыю вы пытаетесь решить.Действительно условие криво звучит, уточним..
Есть Linux-сервер с двумя оптическими и с двумя медными линками, необходимо
- на оптике собрать первый интерфейс LACP 802.3ad
- на меди собрать второй интерфейс LACP 802.3adИз этих двух интерфейсов собрать один Active-Backup (primary=LACP-оптика primary_reselect=always)
Т.е. в штатной ситуации сеть ездит по оптике, при швахе уходит на медь, при восстановлении возвращается.
Teaming/Bonding не суть, приоритет отказоустойчивость, не балансировка.
>[оверквотинг удален]
>> Не думаю что это будет оптимально, но вы ничего не написали про
>> конкретную задачу которыю вы пытаетесь решить.
> Действительно условие криво звучит, уточним..
> Есть Linux-сервер с двумя оптическими и с двумя медными линками, необходимо
> - на оптике собрать первый интерфейс LACP 802.3ad
> - на меди собрать второй интерфейс LACP 802.3ad
> Из этих двух интерфейсов собрать один Active-Backup (primary=LACP-оптика primary_reselect=always)
> Т.е. в штатной ситуации сеть ездит по оптике, при швахе уходит на
> медь, при восстановлении возвращается.
> Teaming/Bonding не суть, приоритет отказоустойчивость, не балансировка.ДЫК spanning-tree !!!
именно для сего случая и придуманный вроде как.И вы уверены в свиче на "той стороне" ???
>>[оверквотинг удален]
> ДЫК spanning-tree !!!
> именно для сего случая и придуманный вроде как.
> И вы уверены в свиче на "той стороне" ???Зачем здесь spanning-tree, зачем пытаться поменять задачу?
Организация описанной конфигурации на других серверных ОС вопросов не вызвала. Очень удивило, что столкнулся с этой проблемой на Linux'е, где решение в лоб, bond/team-интерфейс (active-backup) поверх двух других bond/team-интерфейсов(lacp 802.3ad), собрать не получилось, отсюда и возникла эта тема.
>>>[оверквотинг удален]
>> ДЫК spanning-tree !!!
>> именно для сего случая и придуманный вроде как.
>> И вы уверены в свиче на "той стороне" ???
> Зачем здесь spanning-tree, зачем пытаться поменять задачу?Если это меняет задачу, значит не хватает какого-то важного условия. Ожидаемый результат использования STP отвечает задаче которую вы описали. Что конкретно вас смущает?
Попробуйте собрать ваши интерфейсы попарно в два бонда, а их в бридж с включённым STP.> Организация описанной конфигурации на других серверных ОС вопросов не вызвала. Очень удивило,
> что столкнулся с этой проблемой на Linux'е, где решение в лоб,
> bond/team-интерфейс (active-backup) поверх двух других bond/team-интерфейсов(lacp
> 802.3ad), собрать не получилось, отсюда и возникла эта тема.На других серверных ОС от вас могут что-то прятать за толстым слоем абстракции и собственной терминологией.
>>>[оверквотинг удален]
>> ДЫК spanning-tree !!!
>> именно для сего случая и придуманный вроде как.
>> И вы уверены в свиче на "той стороне" ???
> Зачем здесь spanning-tree, зачем пытаться поменять задачу?
> Организация описанной конфигурации на других серверных ОС вопросов не вызвала. Очень удивило,
> что столкнулся с этой проблемой на Linux'е, где решение в лоб,
> bond/team-интерфейс (active-backup) поверх двух других bond/team-интерфейсов(lacp
> 802.3ad), собрать не получилось, отсюда и возникла эта тема.Второй "хвост" патчкорда куда воткнут?? если в свич -- вроде подавляющее большинство свичей "LACP over LACP" НЕ УМЕЮТ! чесно говоря не припоминю такого функционала ни на одном из девайсов.
(или я ошибаюсь??)как вариант можно использовать аналог цисковского "lacp min-bundle" и "lacp max-bundle"
т.е. объединены в агрегат все 4, но активны только 2.
> (или я ошибаюсь??)не ошибаешься, то, что просит автор есть бред. Одно дело собирать LACP на 4 линках а другое это собирать на двух уже LACP интерфейсах.
учитывая то, что LACP по сути ethernet-фреймы такое в принципе вне стандарта и подразумевает какой-то слой тунелирования
>> (или я ошибаюсь??)
> не ошибаешься, то, что просит автор есть бред. Одно дело собирать LACP
> на 4 линках а другое это собирать на двух уже LACP
> интерфейсах.
> учитывая то, что LACP по сути ethernet-фреймы такое в принципе вне стандарта
> и подразумевает какой-то слой тунелированияТуннелирования куда?? кто второй стороной тунеля будет??
"О прошлом разе" скорее всего реально было 2 LACP, объединенных в мост и STP им в помощь, как наиболее похожее, нормально поддерживаемое и реализуемое решение.