VRRP сквозь bond интерфейс

На мой взгляд, лучше использовать классическое сочетание bridge+STP, или подключать хост с помощью динамических протоколов маршрутизации. Обеспечить подключение к сети с помощью сочетания vrrp+bond можно, но схема подключения будет сложнее для настройки и траблшутинга.

На данном этапе топология без петель и отсутствие STP меня радуют настолько, что менять это на классические сочетания совсем не хочется.
В принципе я даже могу второй линк сделать между свичами без возникновения петли, но лень шепчет мне «зачеееем, а вдруг пакеты можно прозрачно пропустить через хост, ну а вдруг»

я так понял, что vrrp-шный адрес обслуживают 2 машины подключенные к разным коммутаторам?

гм. Есть подозрение, что ничего плохого при этом не произойдет.

bonding в обычных режимах (исключая mode=3 broadcast) не дублирует пакеты. Если не использовать mode=0 (balance-rr), то все пакеты одного потока всегда будут ходить по одному пути.

Сам по себе модуль ядра bonding конечно ничего не бриджует. Но если хост будет бриджевать кадры, то у тебя как раз получится второй линк между коммутаторами. И петля в коммутации.

Да, разные коммутаторы.
Суть в том что есть граничный экзотический сценарий, специфичный для сети, при котором разрыв перемычки приводит к некорректной работе.

Как я понимаю, надо покурить документацию в части возможности форварда мультикаста между интерфейсами?

Если вместо bonding поставить мост со включенным stp, то проблема возможно решиться.

Но хорошо бы понять причину приводящую к некорректной работе.

Бондинг через разные коммутаторы - это не совсем стандартное решение. Возможно здесь нужно искать варианты.

пакеты сквозь bond(режим Fault tolerance)

Нет, бонд это не бридж. Да и зачем лишний хоп в сети, если можно понаделать побольше линков между свичами?

Хотя, что интересно, у цыски есть такой механизм для свичей вроде 4500-Х - PgAP Dual Primary Detection, когда есть два свича в кластере и подключенный по PgAP третий, который используется для разрешения конфликтов.

А вообще попробуй заменить бонд на HSR-интерфейс, правда для этого по-хорошему нужно ядро поновее (3.19+)

заменить бонд на HSR-интерфейс

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

https://en.wikipedia.org/wiki/High-availability_Seamless_Redundancy

https://lwn.net/Articles/488836/

https://github.com/torvalds/linux/tree/master/net/hsr

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

да, штука интересная, но слишком уж свежая - в тот же iproute2 поддержку только в том году добавили, поэтому её время ещё не пришло

Да, сыровато ещё. Если свичи цыско, то можно посмотреть в сторону их аналога Resilient Ethernet Protocol, хотя не уверен что в твоей схеме он подойдёт...

Сомнительная идея сделать бондинг к двум независимым свичам.

Если бондинг использует один MAC, то он наверняка скачет между портами в CAM table, создавая возможности для потери пакетов, флуда и high CPU на свиче.

Допустим, ты найдёшь способ пробрасывать VRRP через хост. Если будешь пробрасывать только VRRP, то куда денется трафик прилетевший не на мастер при пропадании основного линка между свичами?
А если начать пробрасывать всё, то получишь STP loop.

Dual-active detection — это для VSS.

REP — нет смысла.

А тебе не MLAG нужен?

Сомнительная идея сделать бондинг к двум независимым свичам

Ну почему же сомнительная...это стандартное решение, хорошо зарекомендовавшее себя в течение нескольких лет
На самом деле это не просто сервер, а блейд-сервер, а в корзине есть свои внутренние чисто L2 свичи.

А тебе не MLAG нужен?

Я на самом деле не знаю точно, что именно нужно, пока по сути просто изучаю предметную область.
Спасибо за наводку на MLAG

Объяснил выше почему сомнительная.

На твоей схеме наличие L2-свича между хостом и Switch1/2 не наблюдается.

Если он там есть и ты делаешь бондинг к этому свичу, то ситуация существенно отличается от нарисованной. В этом случае ты можешь поднять EtherChannel на блэйдовом свиче в сторону хоста. А на аплинках запустить RSTP.
Sw1/2 надо задрать STP priority, и поднять между ними EtherChannel вместо одинокого линка.

А если ты хочешь бондинг к Sw1/Sw2, то тебе надо что-либо из VSS/VPC/stack/cluster в зависимости от того что имеется в наличии и как оно на этом чём-то называется.

А на аплинках запустить RSTP. Sw1/2 надо задрать STP priority, и поднять между ними EtherChannel вместо одинокого линка.

Он хочет loop-free топологию и я его, в принципе, понимаю :) Сам STP с низкими таймерами юзаю только при связи с провайдером чтобы переживать перезагрузку его конечного оборудования, сходится за 6 секунд, это минимум чего можно добиться в обычном STP.

А если ты хочешь бондинг к Sw1/Sw2, то тебе надо что-либо из VSS/VPC/stack/cluster

Ну, я бы не был так категоричен. По сути, из всех режимов бондинга в линуксе поддержки со стороны свича требует только 802.ad LACP. Остальные с теми или иными ограничениями будут работать вообще без поддержки со стороны свича, особенно тупой режим active/standby который при падении одного свича переключит линк на другой (с опциональным арп-мониторингом). Что у аффтора и реализовано, судя по всему.

В обычном STP 6 секунд получится только с UplinkFast. В RSTP для трёх свичей так долго будет сходиться только если сбой обнаружит по потере hello.

Хочешь «настоящий» loop-free — убирай резервные линки, вычёркивай отказоустойчивость.

Свич внутри блэйдового шасси почти наверняка не линуксовый, а значит умеет только LACP/PAgP.

Хочешь «настоящий» loop-free — убирай резервные линки, вычёркивай отказоустойчивость.

Да у него и так, в принципе, луп фри, только он хочет резервный vrrp heartbeat линк через сервера зачем-то, вместо того чтобы забубенить etherchannel между свичами.

Свич внутри блэйдового шасси почти наверняка не линуксовый, а значит умеет только LACP/PAgP.

Да не надо свичу уметь ничего для поддержки бондинга со стороны линукса. Обычный акцесс-порт сойдёт. В некоторых случаях - static etherchannel можно заюзать.

вместо того чтобы забубенить etherchannel между свичами

спакуха, там и так уже транк из 8 линков, обмазанные LACP
Так что на уровне физики это не так всё плохо

Сурово, там такой траффик мощный? У меня восемь линков в ядро идут от стека из 4ёх каталистов 2960s по 48 портов гигабитных каждый, и то не забиваются :)

yep, 8х10Gbps

Да не надо свичу уметь ничего для поддержки бондинга со стороны линукса. Обычный акцесс-порт сойдёт. В некоторых случаях - static etherchannel можно заюзать.

«Хирург должен быть небрезгливым И ВНИМАТЕЛЬНЫМ!» =)

Линки между блэйдовым свичом и Sw1/Sw2.

Мил человек... и зачем же тебе в эту кашу топор совать?

Чисто ради расширения кругозора хочу понять

Ну так прикинь что будет, если ты так и сделаешь, а твой 8x10GE хряпнется.

прикинь что будет

не знаю, тестировать надо...

Прежде чем тестировать, имеет смысл провести мысленный эксперимент и выдвинуть какие-нибудь гипотезы. А уж затем подтвердить их или опровергнуть путём тестирования.
Заодно будет понятнее что конкретно надо тестировать и на что обращать внимание.

Предположим, что у тебя больше одного хоста (настройки одинаковые), всё в одном VLAN-е и Sw1 — VRRP Master.
Допустим, ты справился пропускать через хост только VRRP.
EC между свичами почему-то сдох. «Сдох» понятие растяжимое, но даже в самом удачном (все линки легли и обе стороны об этом узнали) трафик прилетающий не на мастер — это Unknown UCast. То что прилетело с первого хоста будет улетать на второй и там дропаться (пропускаем насквозь только VRRP), симметрично со второго.

Что будет если начать пропускать всё? STP заблокирует по одному интерфейсу на каждом хосте (если все хосты настроены одинаково) или на том/тех где пропускаешь трафик. При подыхании EC один из таких интерфейсов будет разблокирован и весь межсвичовый трафик попрётся через хост. С хорошими шансами на то, что BPDU не проскочит и начнётся очередной раунд свистопляски.

Предположим, что у тебя больше одного хоста

Пропускающих VRRP или вообще?

То что прилетело с первого хоста будет улетать на второй и там дропаться

это про хосты или свичи речь?

Что будет если начать пропускать всё?

Как я понимаю, всё пропускать без моста не выйдет, поэтому этот сценарий неприменим к моей схеме.

В идеале всё должно работать так:
есть прямая перемычка и есть второй путь для пропуска VRRP.
Падает транк между свичами - VRRP хартбиты продолжают ходить через бонд и никакого split-brain мы не получаем, красота же

Предположим, что у тебя больше одного хоста

Пропускающих VRRP или вообще?

Вообще. При этом возможны варианты сколько из них пропускают VRRP, но на итог это влияет мало — если больше одного, то STP придётся выбирать какой именно из интерфейсов поднять.

это про хосты или свичи речь?

хост1 -> Sw2 -> хост2

Как я понимаю, всё пропускать без моста не выйдет, поэтому этот сценарий неприменим к моей схеме.

В твоей схеме спрятался блэйдовый свич ещё.

есть прямая перемычка и есть второй путь для пропуска VRRP.

Чем второй путь отличается от второй «прямой перемычки»?
Логически — ничем.

Для того чтобы работало, тебе недостаточно обеспечить прохождение VRRP в случае падения линка между свичами. Надо чтобы весь межсвичовый трафик мог ходить тоже.

Если твой EC между свичами собран из портов в разных модулях, то для того чтобы он упал, а остальное продолжило работать понадобится что-то особенное. Например, шаловливые ручки. Ну или свихнувшийся свич с одной из сторон.
В данной ситуации попытка «добавить отказоустойчивости» сделает только хуже.

В твоей схеме спрятался блэйдовый свич ещё.

Петель нет, даже с учётом внутренних свичей, это так называемая U-образная схема, поэтому STP тут нет в принципе.

В данной ситуации попытка «добавить отказоустойчивости» сделает только хуже.

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