Linux bonding balance-alb

[fet4]

Привет всем.

Кто-то использовал бондинг в режиме balance-alb?

Если да, расскажите конфигурацию? На свитче нужно настраивать агрегацию? 

[Phsm]

Согласно https://www.kernel.org/doc/Documentation/networking/bonding.txt это очень костыльная вещь в плане балансировки получаемого трафика:

"This is handled by sending updates (ARP Replies) to all the peers with their individually assigned hardware address such that the traffic is redistributed."

Похоже что оно шлёт каждому соседу по сети arp reply с маком того или иного "плеча", чтобы балансировать входящий трафик по ним.

Лучше LACP или статическую агрегацию поднять, сейчас все свитчи ее умеют.

[ttttt]

А чем это костыльно? Наоборот же, эффективный и дубовый способ достичь распределения трафика.

[fet4]

Цитата

Лучше LACP или статическую агрегацию поднять, сейчас все свитчи ее умеют.

 

Дело в том что сейчас так и работает, но работает не так как нужно мне.

Мой edge core 4612 не позволяет менять тип хеширования и он равен EtherChannel, на основе хэш-функции над MAC-адресом, IP-адресом или TCP и UDP портом источника или получателя.

В итоге если сравнить два графика, двух портов с этого ЛАГ, то исход с маршрутизатора равномерно балансируется, а вот вход на него идет с большим перекосом. Маршрутизатор выполняет роль браса, там Л2 (pppoe,ipoe) и по идее нужно использовать хэш-функцию только над MAC-адресом, а не IP.

Кстати есть еще бордер на этом же свиче там уже Л3 и на нем все в порядке что и подтверждает что для Л2 трафика неправильный хэш.

 

Цитата

 

А чем это костыльно? Наоборот же, эффективный и дубовый способ достичь распределения трафика.

 

Вы пробовали?

 

Відредаговано March 6, 2018 at 21:45 fet4

[l1ght]

выкинуть 4612

говно же, ну

[fet4]

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

[l1ght]

длинк 3612г прости господи

я ж правильно понимаю, что вам надо балансить абонентский исход?

если да - меняйте свитч

Відредаговано March 6, 2018 at 23:22 l1ght

[Phsm]

8 часов назад, ttttt сказал:

А чем это костыльно? Наоборот же, эффективный и дубовый способ достичь распределения трафика.

Костыльно, потому что это не рекомендуемый и не лучший способ решения задачи балансировки трафика по линкам. Это как строить сеть на тупых свичах: выполняют ли они задачу коммутации трафика? Выполняют, всё работает же. Но чуть что - куча нерешаемых проблем.

[ttttt]

Кем не рекомендуемый? Если проблему можно решить на уровне ARP - это очень хорошее решение, т.к. не затрагивает data plane вообще.

[KaYot]

Если проблему можно решить заменой древного свича ценой аж 100$ - так и нужно сделать, а не лепить костыли.

[ttttt]

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

[KaYot]

Судя по описанию этот новый режим balance-alb довольно сложен в реализации, кроме хитрых ARP ответов в разные шнурки там еще и подмена маков на лету идет.

Требуется поддержка со стороны драйверов сетевого адаптера и "возможны проблемы с тегированым трафиком".

 

IMHO это вариант для организации бондинга в тупой свич к примеру, для него вообще ничего со стороны свича не нужно.

[ttttt]

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

[fet4]

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

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

 

Так вы пробовали данный вариант?

[ttttt]

Именно вот этим линуксовым - нет, но я пользуюсь много лет разными решениями балансировки и фейловера на базе ARP, всегда нормально работают и легко отлаживаются, если где ошибся, просто заглянув tcpdumpом.

Відредаговано March 7, 2018 at 19:58 ttttt