Я не очень хорошо знаком с коммутаторами Juniper, но вам не нужно настраивать на них LACP; что - это точка LACP. Если это не так, значит, что-то не так с конфигурацией вашего коммутатора.
LACP указывает только протокол для динамического агрегирования портов. Он не определяет политику планирования портов (куда отправляется и принимается трафик). Эта политика устанавливается отдельно. Я не помню процесс в Linux, но я знаю, что Linux поддерживает указание нескольких разных политик, вероятно, похожих на balance-alb.
Баланс-alb имеет определенные недостатки. В основном то, что он полуинтеллектуально выбирает исходящий порт для новых подключений, и они привязаны к этому порту на весь срок существования соединения (на самом деле это делается с помощью MAC, а не порта, если порт выходит из строя, MAC назначается другому порту, что позволяет продолжить соединение).
Однако это не совсем «агрегация» портов, поскольку соединения не смогут использовать более одного порта. Таким образом, если у вас есть 2 порта 1GbE, одно соединение по-прежнему ограничено 1GbE. LACP обычно решает эту проблему, хотя это зависит от вашей политики планирования и количества активных портов, поддерживаемых на каждом конце.
Если вы настроили LACP на портах, к которым подключаются ваши боксы, для использования LACP, единственная «правильная» настройка на стороне хоста - использовать LACP. EX будет балансировать в соответствии с MAC-адресами источника и назначения Ethernet для трафика Ethernet и будет учитывать IP-адрес источника / назначения / порта для IP-трафика, если в ваших кадрах есть IP-пакеты. Пожалуйста, прочтите статью Juniper KB22943 для получения подробной информации об алгоритмах хеширования. Если ваш коммутатор поддерживает межстековый LACP (что имеет место для 4XXX EX), используйте LACP, если у вас есть стек. Также может быть проще отладить, если у вас более сложная топология L2 с петлями для каждой VLAN и т. Д.
В balance-alb и отправляющие, и принимающие кадры балансируются по нагрузке с использованием уловки изменения MAC-адреса. Это может вызвать проблемы на уровне приложений. Не все приложения подходят для этого режима.
Для решения вашей исходной проблемы. Вот что я делал раньше.
Чакри -
LACP отлично работает и обеспечивает практически в два раза большую производительность по сравнению с одной сетевой картой. Если у вас есть только небольшое количество машин с подключенными сетевыми картами, то вперед.
Но один из недостатков - если у вас небольшой бюджет, и поэтому при использовании нижних конечных коммутаторов, как правило, не хватает LACP-групп и нет функций MLAG или SMLT. Как минимум, большинство коммутаторов от HP и т.п., кажется, предлагают только столько же групп связи, сколько и портов в два раза меньше. Некоторые предлагают еще меньше. Супермикропереключатель 2k, который мы использовали в одной точке, имел только 8 групп LACP, несмотря на то, что имел 52 порта. Полагаю, что это число относительно произвольно. Никто не думал, что вам понадобится больше, чем 1/2 количества портов коммутатора. Вероятно, это просто жестко закодированное число в прошивке и, вероятно, занимает немного больше памяти.
Но, на самом деле, это огромное ограничение, если вы используете SR-IOV, связку и виртуальные машины.
Если вы провайдер, который хочет разместить, может быть, сотни или тысячи машин в стойке, вы не обязательно захотите тратить десятки тысяч долларов на высокопроизводительный коммутатор, что важно, но неоправданно дорого, просто чтобы обеспечить избыточность и производительность для одной стойки машин. Я понимаю, почему такие компании, как facebook, хотят создавать свои собственные коммутаторы.
Так что в этом типе сценариев я бы выбрал другой режим, возможно, баланс-альбом.
.