Jump to content
Калькуляторы

Linux bonding + cisco 3750G балансировка

Добрый день.

Не могу добиться балансировки трафика на bond1 в Linux. Стоит accel в качестве pppoe сервера. bond1 соединен с 3750G смотрит в сеть с абонентами pppoe (около 300 вланов). На 3750 балансировка стоит src-dst-mac bond0 (wan) соединен также с 3750g на ней стоит балансировка src-dst-ip На bond0 трафик прекрасно балансируется

Настройки

bond1

auto bond1
iface bond1 inet manual
   slaves eth2 eth3
   bond-mode 802.3ad
   bond-lacp-rate 1
   bond-miimon 100
   bond-xmit_hash_policy layer2

 

# ifconfig eth3
eth3      Link encap:Ethernet  HWaddr 
         UP BROADCAST RUNNING SLAVE MULTICAST  MTU:1500  Metric:1
         RX packets:1654044 errors:0 dropped:0 overruns:0 frame:0
         TX packets:1404397 errors:0 dropped:0 overruns:0 carrier:0
         collisions:0 txqueuelen:10000
         RX bytes:226694536 (216.1 MiB)  TX bytes:1818460401 (1.6 GiB)

# ifconfig eth2
eth2      Link encap:Ethernet  HWaddr 
         UP BROADCAST RUNNING SLAVE MULTICAST  MTU:1500  Metric:1
         RX packets:1563000 errors:0 dropped:0 overruns:0 frame:0
         TX packets:3098883 errors:0 dropped:0 overruns:0 carrier:0
         collisions:0 txqueuelen:10000
         RX bytes:153674748 (146.5 MiB)  TX bytes:3945342036 (3.6 GiB)

Трафик распределяется примерно 75 на 25 %

То же самое и на графиках.

Пробовал bond-xmit_hash_policy layer2+3 bond-xmit_hash_policy layer3+4

На 3750 пробовал разные варианты балансировки - неудачно

Логически понимаю, что нужно балансировать по макам, но почему то не работает.

Share this post


Link to post
Share on other sites

А почему по макам то??? Я так понимаю циска в качестве L3??? Тогда по src-dst ip делайте

Share this post


Link to post
Share on other sites

А разве алгоритм не должен быть одинаковый на обоих концах?

Share this post


Link to post
Share on other sites

алгоритм балансировки не обязательно должен совпадать.

Share this post


Link to post
Share on other sites

Трафик распределяется примерно 75 на 25 %

А в какую сторону? к BRAS или от BRAS?

 

Пробовал bond-xmit_hash_policy layer2+3 bond-xmit_hash_policy layer3+4

для не IP трафика это не работает. Попробуйте разве что encap2+3

 

А почему по макам то??? Я так понимаю циска в качестве L3??? Тогда по src-dst ip делайте

дык у него pppoe

Share this post


Link to post
Share on other sites

А разве алгоритм не должен быть одинаковый на обоих концах?

По идее сейчас и стоит одинаковый. В бонде Л2. На циске src-dst-mac

А в какую сторону? к BRAS или от BRAS?

В обе стороны. Просто по одной сетевой проходит 75% трафика. по другой 25%

Вчера например полностью в сторону Браса забилась одна сетевая и траф, не влезший в нее полез во вторую сетевую.. При этом дропов, потерь и т.п. не наблюдалось.

Чтобы было понятнее прикладываю графики. eth0 и eth1 - это bond0 смотрит в бордер - там балансировка по IP и все нормально.

eth2 2th3 это bond1 балансировка по макам.

post-91610-052685800 1457058346_thumb.png

Edited by Sacrament

Share this post


Link to post
Share on other sites

В обе стороны. Просто по одной сетевой проходит 75% трафика. по другой 25%

 

нет, на графике хорошо видно, что перекос только _от_ BRAS, к BRAS трафик в пике одинаковый - 200М. Т.е. cisco отрабатывает корректно, проблема только с linux'ом.

Попробуй сделать hash_policy encap2+3, если не поможет, то тогда пожалуй только round-robin.

 

PS: Еще посмотри на выборку клиентских маков, может они чет/нечет как раз как 25/75 распределяются, тогда все логично.

Share this post


Link to post
Share on other sites
Попробуй сделать hash_policy encap2+3

Пробовал - не помогло.

если не поможет, то тогда пожалуй только round-robin.

Если подразумевается режим bond - то с ним не поднимается lacp на циске.

PS: Еще посмотри на выборку клиентских маков, может они чет/нечет как раз как 25/75 распределяются, тогда все логично.

Это у меня тестовый Брас. До этого стоял на Freebsd. Там lagg все балансировало хорошо, да и другие БРАСы сейчас на Freebsd отлично себя чувствуют в плане балансировки трафика.

Share this post


Link to post
Share on other sites

bond-xmit_hash_policy layer2

Для L2 алгоритм самый простой, балансировка по src+dst MAC

Как вариант, попробовать для теста поменять MAC-адрес на половине вланов

 

Это у меня тестовый Брас. До этого стоял на Freebsd

А чем freebsd не устраивает, если там все работает?

Share this post


Link to post
Share on other sites

А чем freebsd не устраивает, если там все работает?

По предварительным тестам на линуксе абонентов на 1 Брас вытягивает больше, но эта фишка с балансировкой пока удручает.

 

P.S. Попробовал установить драйвера на карту предыдущей версии и пересобрать порт-ченел. Картина не изменилась.

Edited by Sacrament

Share this post


Link to post
Share on other sites

Пробовал менять. Авторизация не проходит. Да и что-то такие костыли не очень нравятся. В разных вланах может быть разное кол-во юзеров. Так я могу и на свиче просто линками маки поделить и без бондинга

Share this post


Link to post
Share on other sites

cat /sys/class/net/bondX/bonding/xmit_hash_policy - что на обеих ифейсах показывает? layer2+3 тут будет в самый раз.

Share this post


Link to post
Share on other sites
cat /sys/class/net/bondX/bonding/xmit_hash_policy - что на обеих ифейсах показывает? layer2+3 тут будет в самый раз.

Пробовал все варианты. Если тему почитаете - то увидите. В данный момент стоит layer2

При смене на layer2+3 не меняется ничего

Share this post


Link to post
Share on other sites

Может половину всего трафика получает какой-то один MAC (и соотв. это всё попадает только на один из интерфейсов)?

Вообще можно посмотреть дампы трафика на интерфейсах и сравнить на предмет каких-то особенностей.

Share this post


Link to post
Share on other sites

Пробовал все варианты. Если тему почитаете - то увидите.

меняли как? параметром модуля ядра, или записью в /sys/class/...? убедились, что для проблемного бондинга изменился?

 

Может половину всего трафика получает какой-то один MAC

 

для l2+l3 это не играет роли.

Share this post


Link to post
Share on other sites

 

Может половину всего трафика получает какой-то один MAC

 

для l2+l3 это не играет роли.

 

До L3 балансер не доходит, так как он внутри pppoe

Share this post


Link to post
Share on other sites
меняли как? параметром модуля ядра, или записью в /sys/class/...? убедились, что для проблемного бондинга изменился?

Менял и на лету записью в /sys/class

Когда это не помогло менял параметрами в модуле и перезагружал машину. Соответсвенно в /sys/class/... параметр менялся что на лету, что после ребута. Факт в том что не помогал ни один из способов.

Вообще можно посмотреть дампы трафика на интерфейсах и сравнить на предмет каких-то особенностей.

Попробую завтра глянуть что там такого интересного.

Share this post


Link to post
Share on other sites
В 08.03.2016 в 06:44, Sacrament сказал:

Коллеги, такая же проблема. Думаю использовать, режим mode=0 или 2. Может кто подскажет? Автор так и ничего не сказал. Точнее не отписался, чем все решилось. У меня проблема точь точь идентичная.

 

Share this post


Link to post
Share on other sites

Со стороны брас надо делать dst-mac.

Никакой L3 не поможет если у вас PPPoE

Share this post


Link to post
Share on other sites

Да ничем так и не  закончилось. Надобность в том БРАСе отпала, но проблему так и не решил. Сейчас та машина НАТит почти 2 гига трафика тоже с бондингом и там все балансируется замечательно с той же циской.

Share this post


Link to post
Share on other sites

Потому что уже не PPPoE трафик там бегает, а чистый IP.

Раз балансировка кривая, нужно было просто разные вланы на разные порты прокинуть и балансироваться. Если уж lagg на round-robin не подымается.

Конечно static lagg не так изящно как lacp, зато 100% получилось бы разбалансировать :)

Share this post


Link to post
Share on other sites
В 03.11.2017 в 13:21, Sacrament сказал:

Да ничем так и не  закончилось. Надобность в том БРАСе отпала, но проблему так и не решил. Сейчас та машина НАТит почти 2 гига трафика тоже с бондингом и там все балансируется замечательно с той же циской.

У меня получилось, все равно точь в точь как у вас в задаче. mode 0 = round robin Именно на интерфейсах где pppoe, балансируется 50/50 тютелька в тюльку.  Mode 4 балансировался 70:30. Как я понимаю, минус mode 0, в том что если откажет линк. Будет что-то не то.... 

Share this post


Link to post
Share on other sites
18 часов назад, zlolotus сказал:

У меня получилось, все равно точь в точь как у вас в задаче. mode 0 = round robin Именно на интерфейсах где pppoe, балансируется 50/50 тютелька в тюльку.  Mode 4 балансировался 70:30. Как я понимаю, минус mode 0, в том что если откажет линк. Будет что-то не то.... 

Скорее всего да. Будет оказия - попробую ваш способ. Ну по факту отказ линка в данном случае маловероятен т.к. это просто патчкорд от Сервера к коммутатору, но все равно малая вероятность такого всегда есть. 

Share this post


Link to post
Share on other sites

Понимаю, что жуткий некропостинг, но сам столкнулся с той же проблемой - криво балансировался трафик на PPPoE сервере, где интерфейс к абонентам - 4*1GE bonding. 

Вопрос можно решить c сохранением lacp, нужно поставить параметр xmit_hash_policy encap2+3

У меня заработало на Debian 8, kernel 3.16

pppoe_bonding_encap2+3.png

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now