Активно-резервен bond на Linux върху EVPN с режим all-active: какво се чупи

Сложете активно-резервен bond на сървъра и all-active Ethernet сегмент на фабриката — и половината от връщащия трафик може да изчезне, без нито един брояч на грешки да помръдне. Нито една от двете конфигурации не е грешна сама по себе си. Проблемът е в предаването между тях: едната страна избира един порт, а другата предполага, че всеки свързан leaf може да достави. Проследете един кадър в двете посоки и несъответствието става очевидно.

Какво прави активно-резервният режим с входящия кадър

Режимът на свързване 1 държи точно един slave в пътя за предаване и го сменя само когато текущият се повреди. Тази част е добре известна. Важна тук е приемащата страна: ядрото подава кадър на стека само ако той е пристигнал на активния slave, и изхвърля кадри, които се появят на друг slave. Тази all_slaves_active настройка съществува именно за да разхлаби това правило, и по подразбиране е изключена. ip -d link show bond0 отпечатва текущата стойност до режима.

/proc/net/bonding/bond0 именува активния slave и отчита състоянието на връзката за всеки slave. Този файл е единственият честен източник кой порт в момента носи трафик.

Хост в този режим има един използваем приемен път наведнъж, избран локално без знание за фабриката. Ако кадър за този хост пристигне по другия кабел, портът на комутатора го отчита като получен, стекът на хоста никога не го вижда и всички броячи освен собствения брояч на отхвърлените на хоста изглеждат напълно здрави.

Какво прави all-active multihoming с отдалечен следващ хоп

EVPN multihoming описва набор от leaf-ове, които споделят един Ethernet сегмент, идентифициран с ESI, и обявява този сегмент на останалата част от фабриката. В модела all-active отдалечените peer-и инсталират повече от един следващ хоп за адресите на сегмента. Unicast към сървъра може тогава да пристигне на който и да е leaf и фабриката е свободна да избира за всеки поток. Това е целият смисъл на дизайна и това е предположението, на което bond-ът на сървъра трябва да отговори.

Наводненият трафик следва друго правило. Leaf-овете избират определен forwarder за всеки сегмент, така че broadcast, неизвестният unicast и multicast обикновено влизат през един от тях. Затова unicast и наводняването вземат две отделни решения и само едно от тях се показва в състоянието на bond-а на хоста.

Къде двата избора се разминават

Ядрото избира активния си slave от състоянието на връзката и собствената си политика. Фабриката избира следващи хопове от EVPN маршрутите, а определен forwarder — от избор между leaf-овете. Нито един процес не се консултира с другия. Когато изберат различни leaf-ове, отказът зависи от посоката: това, което сървърът изпраща, излиза нормално, а отговорите изчезват.

Съществуват два поддържани изхода и те не са взаимозаменяеми. Дайте на хоста bond, който фабриката може да третира като едно логическо свързване, което на практика означава LACP bond, договорен с leaf-овете, и двете връзки наистина са активни заедно. Или приемете и доставка single-active от фабриката, така че сегментът да следва същия модел „един порт наведнъж“ като bond-а. Това, което не работи, е all-active сегмент пред bond, който слуша само на един порт, освен ако умишлено не включите приемане на неактивните slave-ове и не приемете двойната доставка, която следва.

Защо резервният кабел продължава да изглежда здрав

Кабел, който не носи трафик, пак отчита връзка нагоре, а резервният slave в bond-а е създаден да изглежда готов. Операторите четат това като резервиране и спират да задават въпроси.

Питайте вместо това кой физически порт е използвал връщащият кадър. На хоста броете получените пакети по slave, а не по bond, защото броячът на bond-а скрива асиметрията. На leaf-а погледнете записите за препращане в моста за MAC адреса на сървъра и набора от следващи хопове, който носи EVPN маршрутът. Ако записът сочи към leaf-а, чиято връзка към хоста е резервната, дизайнът доставя в порт, който хостът игнорира. Това е несъответствие в конфигурацията, а не хардуерна повреда, и никакво наблюдение на състоянието на връзката няма да го разкрие.

Тествайте доставката в двете посоки, а не състоянието на връзката

Изградете матрица с един ред за отказ и една колона за посока, после попълвайте доставения трафик, а не състоянието на интерфейса. Ред едно е нормална работа и точно там се крие несъответствието, защото симптомът изглежда като проблем на приложението.

След това премахнете активната връзка на хоста, премахнете един leaf, премахнете uplink-овете на този leaf и възстановете всяко поред. След всяка стъпка записвайте активния slave, състоянието на EVPN сегмента, отдалечения запис за препращане и наблюдаваната пропускателна способност в двете посоки. Leaf, който губи пътя си към фабриката, докато връзката му към хоста остава вдигната, е интересният случай, защото свързването остава обявено и може тихо да се превърне в задънена улица. Тествайте с нови unicast потоци и с наводнения трафик, от който зависи приложението, защото двете използват различни решения за препращане.

Приемете дизайна само когато матрицата показва двупосочна доставка по пътя, който сте предвидили. Два кабела с вдигната връзка не са този резултат.