Активно-резервни bond Linux-а на all-active EVPN: шта се ломи

Поставите активно-резервни bond на сервер и all-active Ethernet сегмент на fabric, и половина повратног саобраћаја може да нестане без да се помери иједан бројач грешака. Ниједна од те две конфигурације није сама по себи погрешна. Проблем је у предаји између њих, где једна страна бира један порт, а друга претпоставља да сваки повезани лист може да достави. Пратите један оквир у сваком смеру и неслагање постаје очигледно.

Шта активно-резервни режим ради са долазним оквиром

Режим повезивања 1 држи тачно један slave у путу за слање и мења га само када тренутни откаже. Тај део је добро познат. Овде је важна страна пријема: језгро предаје оквир стеку само ако је стигао на активни slave, а оквире који се појаве на било ком другом slave одбацује. Ово all_slaves_active подешавање постоји управо да би ублажило то правило и подразумевано је искључено. ip -d link show bond0 исписује тренутну вредност поред режима.

/proc/net/bonding/bond0 именује активни slave и извештава о стању везе за сваки slave. Та датотека је једини поштен извор о томе који порт тренутно носи саобраћај.

Домаћин у овом режиму има једну употребљиву путању пријема истовремено, изабрану локално без знања о fabric-у. Ако оквир за тог домаћина стигне на други кабл, порт свича га рачуна као примљен, стек домаћина га никада не види, и сви бројачи осим сопственог бројача одбацивања на домаћину изгледају потпуно здраво.

Шта all-active multihoming ради са удаљеним следећим скоком

EVPN multihoming описује скуп листова који деле један Ethernet сегмент, означен ESI-јем, и оглашава тај сегмент остатку fabric-а. У all-active моделу удаљени peer-ови инсталирају више од једног следећег скока за адресе сегмента. Unicast ка серверу тада може да стигне на било који лист, а fabric слободно бира по току. То је цела сврха дизајна и уједно претпоставка коју bond сервера мора да испуни.

Поплављени саобраћај следи друго правило. Листови бирају одређени forwarder по сегменту, па broadcast, непознати unicast и multicast обично улазе кроз један од њих. Зато unicast и поплава доносе две одвојене одлуке, а само једна од њих се види у стању bond-а домаћинства.

Где се два избора разилазе

Језгро бира свој активни slave према стању везе и сопственој политици. Fabric бира следеће скокове према EVPN рутама, а одређени forwarder према избору међу листовима. Ниједан процес не пита други. Када изаберу различите листове, отказ зависи од смера: оно што сервер пошаље изађе нормално, а одговори нестану.

Постоје два подржана излаза и нису заменљиви. Дајте домаћину bond који fabric може да третира као једно логичко повезивање, што у пракси значи LACP bond договорен са листовима, и обе везе су заиста активне заједно. Или прихватите и single-active доставу из fabric-а, тако да сегмент прати исти модел један-порт-у-једном-тренутку као bond. Оно што не ради јесте all-active сегмент испред bond-а који слуша само на једном порту, осим ако намерно не укључите пријем на неактивним slave-овима и не прихватите двоструку доставу која следи.

Зашто резервни кабл и даље изгледа здрав

Кабл који не носи саобраћај и даље пријављује везу горе, а резервни slave у bond-у је направљен да изгледа спреман. Оператери то читају као резерву и престају да постављају питања.

Питајте уместо тога који је физички порт користио повратни оквир. На домаћину бројите примљене пакете по slave-у, а не по bond-у, јер бројач bond-а крије асиметрију. На листу погледајте записе прослеђивања моста за MAC сервера и скуп следећих скокова који носи EVPN рута. Ако запис показује на лист чија је веза са домаћином резервна, дизајн доставља у порт који домаћин игнорише. То је неслагање конфигурације, а не квар хардвера, и никакво праћење стања везе то неће открити.

Тестирајте доставу у оба смера, не стање везе

Направите матрицу са једним редом по отказу и једном колоном по смеру, па је попуните достављеним саобраћајем, а не стањем интерфејса. Ред један је нормалан рад и управо се ту неслагање крије, јер симптом изгледа као проблем апликације.

Затим уклоните активну везу домаћина, уклоните један лист, уклоните uplink-ове тог листа и вратите сваки редом. После сваког корака запишите активни slave, стање EVPN сегмента, удаљени запис прослеђивања и измерени проток у оба смера. Лист који изгуби пут ка fabric-у док његова веза са домаћином остаје горе је занимљив случај, јер повезивање остаје оглашено и може тихо да постане ћорсокак. Тестирајте свежим unicast токовима и поплављеним саобраћајем од ког апликација зависи, јер обоје користе различите одлуке прослеђивања.

Прихватите дизајн само када матрица покаже двосмерну доставу путањом коју сте наменили. Два кабла са везом горе нису тај резултат.