[purecopper]

Коллеги приветствую. Появилась необходимость объединить в Linux 3.2 две разных сетевых карты (e1000e и igb) в LACP bond layer2+3. В принципе понимаю, что никаких проблем возникнуть не должно, но вдруг есть какие-нибудь подводные камни.

[u234]

нормально работает

 

cat /proc/net/bonding/bond0
Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)

Bonding Mode: IEEE 802.3ad Dynamic link aggregation
Transmit Hash Policy: layer3+4 (1)
MII Status: up
MII Polling Interval (ms): 100
Up Delay (ms): 0
Down Delay (ms): 0

802.3ad info
LACP rate: slow
Min links: 0
Aggregator selection policy (ad_select): stable
Active Aggregator Info:
       Aggregator ID: 4
       Number of ports: 4
       Actor Key: 9
       Partner Key: 7
       Partner Mac Address: 

Slave Interface: p2p2
MII Status: up
Speed: 1000 Mbps
Duplex: full

Slave Interface: p2p1
MII Status: up
Speed: 1000 Mbps
Duplex: full

Slave Interface: em2
MII Status: up
Speed: 1000 Mbps
Duplex: full

Slave Interface: em1
MII Status: up
Speed: 1000 Mbps
Duplex: full

[big-town]

layer3+4

Вот так делать не надо, иначе получите косяк по торрентам. Закачки будут со скоростью не более 60% от тарифного плана. На одной агрегации может и не скажется, точнее скажется но не значительно у меня при схеме (свитч агрегации - софт роутер - нат) все через бондинг, была такая проблема. Весь мозг себе съел, а пользователи помогали :)

пока не переделал на Transmit Hash Policy: layer2+3.

[nuclearcat]

Слабо представляю, почему layer3+4 будет влиять на торренты. Есть какое-то техническое обоснование?

Я понимаю round-robin, где могут быть reordering, но это?

Мне ни одного логического не приходит в голову, а вот layer2+3 очень часто вызывает разбалансировку.

[big-town]

Слабо представляю, почему layer3+4 будет влиять на торренты. Есть какое-то техническое обоснование?

Я понимаю round-robin, где могут быть reordering, но это?

Мне ни одного логического не приходит в голову, а вот layer2+3 очень часто вызывает разбалансировку.

Я тоже не совсем понимаю почему так происходит, потому давольно долго искал причину. Ощущения такое что половина трафика просто дропается. Причем когда мерял iperf-ом тоже получал не более 70-80Мбит в один поток и не более 85Мбит при 5 потоках. При 100Мбит-ом интерфейсе. Причем по схеме (домашний Mikrotik)-(подъездный SNR свитч)-(магистральный свитч)-(магистральный свитч) -> бондинг layer3+4-> (Mikrotik агрегации) с микротика на микротик было 100Мбит. Первое падение было на участке (миротик)-(софт роутер), затем (софт роутер) - (нат). Но с цифрами не поспоришь :), при layer2+3 стало 100Мбит и при замерах и при скачке торретом, ни каких падений.

По поводу дисбаланса, да он есть но небольшой.

Вот трафик за неделю, layer2+3 с самого начала. В начале почти идеальная балансировка, затем 4 дня немного идет дизбаланс, но как видите все в пределах нормы.

[nuclearcat]

А, микротик - это вечный поиск подводных стуков. Там даже самые очевидные вещи реализованы через известное место.

У меня бондинга реально много, и проблем не возникало, и именно с layer3+4

[big-town]

А, микротик - это вечный поиск подводных стуков.

Зря вы его так :), в мелких галактиках очень даже ничего работает.

И как раз dlink LACP - mikrotik, на этом месте проблем не наблюдалось.

Правда в микротике было 3+4, но в длинке хоть и написано что lacp совместим с 3+4, ходят слухи что это не так.

Может потому скорее всего проблем и не было что по факту было 2+3.

[nuclearcat]

Как-то работает, но если глянуть под капот - то плохо становится. Но я не особо возражаю, конкуренты моих клиентов сидят на микротике, и пока все обстоит так - мне легко у них выигрывать по качеству инета и меньшими трудозатратами на отладку сети.

Даже kernel devs при запиливании новых сетевых фич частенько по граблям ходят, а в Микротике сторонними патчами все ядро испахано, сочетание которых во всяких сложных ситуациях ведут себя малопредсказуемо.

В особенности если сетевые драйвера микротик бекпортил из каких-то архаичных ядер от вендоров и держит вне mainline, то например offload фичи в свежих ядрах переиначивают постоянно, и тот же кривой драйвер в сочетании с новым gro/gso может создавать проблему как у вас.

[big-town]

Я же и говорил что только в масштабах маленьких галактик. Вы например можете предложить L3 решение с 1Гбитными портами ценником в 22000 деревянных?

Вот и вышло что соотношение цена/качество пало на 1100AHx2. Проект был под вопросом и больших денег ни кто не собирался вкладывать.

А если не секрет, откуда у вас такая информация по ядру микротика?

В джунипере например тоже все реализовано сторонними модулями, но как бы это не влияет отрицательно на их работу.

Мне реально интересно.

[nuclearcat]

Я не в РФ :) По цене, можно и дальше утрамбоватся, взяв бу свитчемыльниц, реалтековских сетевух, и б/у core i3 с заломанным микротиком. Только вот в провайдинге, если у вас есть конкуренты, и у вас "качество" хуже, т.к. вы выбрали железку чуть подешевле - означает в лучшем случае стагнацию. Естественно просто брать "дороже" без понимания того, что берете - тоже смысла мало.

По ядру - я пишу свой софт, под ядро тоже, и для развлечения портировал свежие ядра под микротиковскую железку, плюс несколько печальных попыток отладить крупные сети построенные на этом решении.

https://raw.githubusercontent.com/wsxarcher/routeros-linux-patch/master/linux-3.3.5.patch

В джунипере авторы разрабатывают все от А до Я, в модулях в т.ч. серьезно пилят железо, на весьма низком уровне, с кучей тестов и сертификациями. На микротике запросто могут выпустить версию, где у EoIP ломается byte order и судя по всему юнит-тестов у них нет.

Микротик берет у вендоров SDK с референс платой, впиливают свои блоки питания на плату, делают модификации для своих корпусов. Ну еще бывают такие любопытные вещи, как CPLD ради использования другой (возможно более дешевой) флеши. Но такого тесного взаимодействия по железу как у крупных типа джунипера - у них явно нет.

[rdc]

в длинке хоть и написано что lacp совместим с 3+4, ходят слухи что это не так

LACP - это протокол проверки связности на физике, он вообще не имеет никакого отношения к алгоритмам LAG.

Для соединения роутера и свича LACP вообще не нужен, надёжнее поставить static LAG.

И алгоритмы LAG с разных сторон могут быть разными. Например, у меня на длинках стоит 2+3, а на писюках RR, и всё прекрасно работает.

[nuclearcat]

Для соединения роутера и свича LACP вообще не нужен, надёжнее поставить static LAG.

 

Как раз нет - если один шнурок отвалится, LACP разрулит эту ситуацию. У меня еще помогало, когда один из портов падал в 100Мбит из-за плохого/старого шнурка.

[rdc]

Static LAG смотрит на состояние линка на порту - если линк погас, трафик разливается на оставшиеся порты.

[nuclearcat]

Иногда линк флапает или падает в сотку. Хотя в этом случае конечно не факт, что поможет.

А вот когда посередине линка релейка или медики - то порт вполне может и быть по прежнему поднят как минимум с одной стороны.

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