Активно-резервен 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 текови и со поплавениот сообраќај од кој зависи апликацијата, бидејќи двете користат различни одлуки за проследување.

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