Активно-резервний bond Linux на all-active EVPN: що ламається

Поставте активно-резервний bond на сервер, а сегмент all-active Ethernet — на фабрику, і половина зворотного трафіку може зникнути, не зрушивши жодного лічильника помилок. Жодна з конфігурацій сама по собі не помилкова. Проблема в передачі між ними: одна сторона обирає один порт, а друга припускає, що кожен підключений лист уміє доставляти. Простежте один кадр у кожному напрямку, і невідповідність стане очевидною.

Що активно-резервний режим робить із вхідним кадром

Режим bonding 1 тримає рівно один slave у шляху передавання і змінює його лише тоді, коли поточний відмовляє. Ця частина добре відома. Тут важлива сторона приймання: ядро віддає кадр стекові лише тоді, коли він надійшов на активний slave, а кадри, що з'являються на будь-якому іншому slave, відкидає. Це all_slaves_active налаштування існує саме для того, щоб послабити це правило, і типово воно вимкнене. ip -d link show bond0 друкує поточне значення поряд із режимом.

/proc/net/bonding/bond0 називає активний slave і повідомляє стан зв'язку для кожного slave. Цей файл — єдине чесне джерело того, який порт зараз несе трафік.

У хоста в цьому режимі водночас є один придатний шлях приймання, вибраний локально без знання про фабрику. Якщо кадр для цього хоста надійде іншим кабелем, порт комутатора порахує його як отриманий, стек хоста його ніколи не побачить, і всі лічильники, крім власного лічильника відкидання хоста, виглядають цілком здоровими.

Що all-active multihoming робить з віддаленим наступним хопом

EVPN multihoming описує набір листів, які поділяють один сегмент Ethernet, ідентифікований через ESI, і анонсує цей сегмент решті фабрики. У моделі all-active віддалені peer встановлюють більше ніж один наступний хоп для адрес сегмента. Unicast до сервера тоді може надійти на будь-який лист, і фабрика вільна обирати за потоком. У цьому весь сенс дизайну, і це ж те припущення, якому має відповідати bond сервера.

Затоплений трафік підкоряється іншому правилу. Листи обирають призначений forwarder на сегмент, тому broadcast, невідомий unicast і multicast зазвичай входять через один із них. Так unicast і затоплення ухвалюють два окремі рішення, і лише одне з них видно в стані bond хоста.

Де два вибори розходяться

Ядро обирає свій активний slave за станом зв'язку та власною політикою. Фабрика обирає наступні хопи за маршрутами EVPN, а призначений forwarder — за виборами серед листів. Жоден процес не радиться з іншим. Коли вони обирають різні листи, відмова залежить від напрямку: те, що сервер надсилає, виходить нормально, а відповіді зникають.

Є два підтримувані виходи, і вони не взаємозамінні. Дайте хосту bond, який фабрика може розглядати як одне логічне підключення, що на практиці означає bond LACP, узгоджений із листами, і обидві ланки справді активні разом. Або прийміть і доставку single-active від фабрики, щоб сегмент ішов за тією самою моделлю «один порт за раз», що й bond. Що не працює — сегмент all-active перед bond, який слухає лише один порт, якщо тільки ви навмисно не ввімкнете приймання на неактивних slave і не приймете наступну за цим подвійну доставку.

Чому резервний кабель продовжує виглядати здоровим

Кабель, що не несе трафіку, усе одно повідомляє про піднятий зв'язок, а резервний slave у bond створений виглядати готовим. Оператори читають це як резервування і перестають ставити запитання.

Запитайте натомість, який фізичний порт використав зворотний кадр. На хості рахуйте отримані пакети за slave, а не за bond, бо лічильник bond приховує асиметрію. На листі подивіться на записи просування моста для MAC сервера і на набір наступних хопів, який несе маршрут EVPN. Якщо запис указує на лист, чий зв'язок із хостом резервний, дизайн доставляє в порт, який хост ігнорує. Це невідповідність конфігурації, а не апаратна несправність, і жоден моніторинг стану зв'язку її не виявить.

Тестуйте доставку в обидва напрямки, а не стан зв'язку

Побудуйте матрицю з одним рядком на відмову і одним стовпцем на напрямок, а потім заповнюйте її доставленим трафіком, а не станом інтерфейсу. Рядок один — нормальна робота, і саме там ховається невідповідність, бо симптом виглядає як проблема застосунку.

Потім приберіть активну ланку хоста, приберіть один лист, приберіть uplink цього листа і відновіть кожне по черзі. Після кожного кроку записуйте активний slave, стан сегмента EVPN, віддалений запис просування і спостережувану пропускну здатність в обох напрямках. Лист, який втрачає шлях до фабрики, поки його ланка з хостом залишається піднятою, — цікавий випадок, бо підключення залишається анонсованим і може тихо стати глухим кутом. Тестуйте свіжими unicast-потоками і затопленим трафіком, від якого залежить застосунок, бо вони використовують різні рішення про просування.

Приймайте дизайн лише тоді, коли матриця показує двосторонню доставку задуманим шляхом. Два кабелі з піднятим зв'язком — це не той результат.