Linux bonding balance-alb

[fet4 46]

Привет всем.

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

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

[Phsm 19]

Согласно 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 195]

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

[fet4 46]

Цитата

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

 

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

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

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

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

 

Цитата

 

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

 

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

 

Відредаговано 2018-03-06 21:45:57 fet4

[l1ght 377]

выкинуть 4612

говно же, ну

[fet4 46]

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

[l1ght 377]

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

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

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

Відредаговано 2018-03-06 23:22:47 l1ght

[Phsm 19]

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

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

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

[ttttt 195]

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

[KaYot 3 604]

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

[ttttt 195]

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

[KaYot 3 604]

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

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

 

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

[ttttt 195]

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

[fet4 46]

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

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

 

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

[ttttt 195]

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

Відредаговано 2018-03-07 19:58:02 ttttt