Bond aktiv-rezervë i Linux në EVPN all-active: çfarë thyhet

Vendosni një bond aktiv-rezervë në server dhe një segment Ethernet all-active në fabric, dhe gjysma e trafikut të kthimit mund të zhduket pa lëvizur as edhe një numërues gabimesh. Asnjëra nga dy konfigurimet nuk është e gabuar në vetvete. Problemi qëndron në dorëzimin mes tyre, ku njëra anë zgjedh një port të vetëm dhe tjetra supozon se çdo gjethe e lidhur mund të dorëzojë. Ndiqni një kornizë në secilin drejtim dhe mospërputhja bëhet e dukshme.

Çfarë bën aktiv-rezerva me një kornizë hyrëse

Mënyra e lidhjes 1 mban saktësisht një slave në rrugën e transmetimit dhe e ndërron vetëm kur ai aktuali dështon. Ajo pjesë është e njohur. Këtu rëndësi ka ana e marrjes: kernel-i e dorëzon kornizën te stack-u vetëm nëse ajo arrin në slave-in aktiv, dhe i hedh kornizat që shfaqen në çdo slave tjetër. Ky all_slaves_active konfigurim ekziston pikërisht për të lehtësuar atë rregull, dhe si parazgjedhje është i fikur. ip -d link show bond0 shtyp vlerën aktuale pranë mënyrës.

/proc/net/bonding/bond0 emërton slave-in aktiv dhe raporton gjendjen e lidhjes për çdo slave. Ai skedar është burimi i vetëm i ndershëm për atë se cili port po mbart trafikun në atë moment.

Një host në këtë mënyrë ka një rrugë marrjeje të përdorshme në një kohë, të zgjedhur lokalisht pa njohuri për fabric-in. Nëse një kornizë për atë host arrin në kabllon tjetër, porti i switch-it e numëron si të marrë, stack-u i hostit nuk e sheh kurrë, dhe të gjithë numëruesit përveç numëruesit të hedhjes të vetë hostit duken krejt të shëndetshëm.

Çfarë bën multihoming all-active me një hop tjetër të largët

Multihoming EVPN përshkruan një grup gjethesh që ndajnë një segment Ethernet, të identifikuar nga një ESI, dhe e shpall atë segment pjesës tjetër të fabric-it. Në modelin all-active, palët e largëta instalojnë më shumë se një hop tjetër për adresat e segmentit. Unicast-i drejt serverit mund të arrijë atëherë në çdo gjethe, dhe fabric-i është i lirë të zgjedhë për çdo rrjedhë. Ky është i gjithë qëllimi i projektimit, dhe është gjithashtu supozimi që bond-i i serverit duhet të përmbushë.

Trafiku i përmbytur ndjek një rregull tjetër. Gjethet zgjedhin një forwarder të caktuar për çdo segment, kështu që broadcast, unicast i panjohur dhe multicast zakonisht hyjnë përmes njërit prej tyre. Kështu unicast dhe përmbytja marrin dy vendime të ndara, dhe vetëm njëri prej tyre shfaqet në gjendjen e bond-it të hostit.

Ku dy zgjedhjet nuk pajtohen

Kernel-i zgjedh slave-in e tij aktiv nga gjendja e lidhjes dhe nga politika e tij. Fabric-i zgjedh hop-et e tjera nga rrugët EVPN, dhe një forwarder të caktuar nga një zgjedhje mes gjetheve. Asnjëri proces nuk konsultohet me tjetrin. Kur zgjedhin gjethe të ndryshme, dështimi varet nga drejtimi: ajo që dërgon serveri del normalisht, dhe përgjigjet zhduken.

Ekzistojnë dy rrugëdalje të mbështetura, dhe ato nuk janë të këmbyeshme. Jepini hostit një bond që fabric-i mund ta trajtojë si një lidhje të vetme logjike, që në praktikë do të thotë një bond LACP i negociuar me gjethet, dhe të dy lidhjet janë vërtet aktive së bashku. Ose pranoni gjithashtu dorëzimin single-active nga fabric-i, në mënyrë që segmenti të ndjekë të njëjtin model me një port në një kohë si bond-i. Ajo që nuk funksionon është një segment all-active përpara një bond-i që dëgjon vetëm në një port, përveç nëse aktivizoni qëllimisht marrjen në slave-at joaktivë dhe pranoni dorëzimin e dyfishtë që vjen më pas.

Pse kablloja rezervë vazhdon të duket e shëndetshme

Një kabllo që nuk mbart trafik raporton gjithsesi lidhje lart, dhe një slave në pritje në një bond është projektuar të duket gati. Operatorët e lexojnë atë si tepricë dhe nuk pyesin më.

Pyetni në vend të kësaj cilin port fizik përdori korniza e kthimit. Në host, numëroni paketat e marra për çdo slave e jo për bond, sepse numëruesi i bond-it fsheh asimetrinë. Në gjethe, shikoni regjistrimet e përcjelljes së urës për MAC-in e serverit dhe grupin e hop-eve të tjera që mbart rruga EVPN. Nëse regjistrimi tregon gjethen, lidhja e së cilës me hostin është rezervë, projektimi po dorëzon në një port që hosti e injoron. Ky është një mospërputhje konfigurimi dhe jo një defekt hardueri, dhe asnjë sasi monitorimi i gjendjes së lidhjes nuk do ta nxjerrë në pah.

Testoni dorëzimin në të dy drejtimet, jo gjendjen e lidhjes

Ndërtoni një matricë me një rresht për çdo dështim dhe një kolonë për çdo drejtim, pastaj plotësojeni me trafikun e dorëzuar dhe jo me gjendjen e ndërfaqes. Rreshti një është funksionimi normal, dhe pikërisht aty fshihet mospërputhja, sepse simptoma duket si problem i aplikacionit.

Më pas hiqni lidhjen aktive të hostit, hiqni një gjethe, hiqni uplink-et e asaj gjetheje, dhe rivendosni secilën me radhë. Pas çdo hapi, shënoni slave-in aktiv, gjendjen e segmentit EVPN, regjistrimin e përcjelljes së largët dhe xhiron e vëzhguar në të dy drejtimet. Një gjethe që humbet rrugën drejt fabric-it ndërsa lidhja e saj me hostin mbetet lart është rasti interesant, sepse lidhja mbetet e shpallur dhe mund të bëhet në heshtje një rrugë pa krye. Testoni me rrjedha unicast të reja dhe me trafikun e përmbytur nga i cili varet aplikacioni, sepse të dy përdorin vendime të ndryshme përcjelljeje.

Pranojeni projektimin vetëm kur matrica tregon dorëzim dykahësh përgjatë rrugës që kishit menduar. Dy kabllo me lidhje lart nuk janë ai rezultat.