Linux-bond yn aktive reserve op in all-active EVPN: wat der brekt

Set in bond yn aktive reserve op 'e server en in all-active Ethernet-segment op it fabric, en de helte fan it weromkommende ferkear kin ferdwine sûnder dat ien flaterteller beweecht. Gjin fan beide konfiguraasjes is op himsels ferkeard. It probleem sit yn 'e oerdracht tusken har, dêr't de iene kant ien poarte kiest en de oare oannimt dat elk oansletten blêd leverje kin. Folgje ien frame yn elke rjochting en de misferhâlding wurdt dúdlik.

Wat aktive reserve mei in ynkommend frame docht

Bondmodus 1 hâldt krekt ien slave yn it stjoerpaad en wikselet dy allinnich as de hjoeddeiske falt. Dat part is goed bekend. Wat hjir ta docht is de ûntfangstkant: de kernel jout in frame allinnich oan de stapel as it op 'e aktive slave oankomt, en smyt frames weilitten dy't op in oare slave ferskine. Dizze all_slaves_active ynstelling bestiet krekt om dy regel te fersêftsjen, en is by deflt út. ip -d link show bond0 printet de hjoeddeiske wearde njonken de modus.

/proc/net/bonding/bond0 neamt de aktive slave en rapportearret de linkstatus foar elke slave. Dat bestân is de iennichste earlike boarne foar hokker poarte op dit stuit ferkear draacht.

In host yn dizze modus hat tagelyk ien brûkbere ûntfangstpaad, pleatslik keazen sûnder kennis fan it fabric. As in frame foar dy host oer de oare kabel oankomt, telt de switchpoarte it as ûntfongen, de hoststapel sjocht it nea, en alle tellers útsein de eigen drop-teller fan 'e host sjogge der folslein sûn út.

Wat all-active multihoming mei in folgjende hop fier fuort docht

EVPN-multihoming beskriuwt in set blêden dy't ien Ethernet-segment diele, identifisearre troch in ESI, en advertearret dat segment oan 'e rest fan it fabric. Yn it all-active-model ynstallearje fiere peers mear as ien folgjende hop foar de adressen fan it segment. Unicast nei de server kin dan by elk blêd oankomme, en it fabric is frij om per flow te kiezen. Dat is it hiele doel fan it ûntwerp, en it is ek de oanname dêr't de bond fan 'e server oan foldwaan moat.

Oerstreamd ferkear folget in oare regel. De blêden kieze in oanwiisde forwarder per segment, sadat broadcast, ûnbekend unicast en multicast normaal troch ien fan har ynkomme. Unicast en oerstreaming nimme dus twa aparte besluten, en mar ien dêrfan is yn 'e bondstatus fan in host te sjen.

Dêr't de twa keuzes faninoar skille

De kernel kiest syn aktive slave út linkstatus en syn eigen belied. It fabric kiest folgjende hops út EVPN-rûtes, en in oanwiisde forwarder út in kar ûnder de blêden. Gjin fan beide prosessen oerleit mei de oare. As se ferskillende blêden kieze, is de flater rjochtingbûn: wat de server stjoert giet normaal fuort, en de antwurden ferdwine.

Der binne twa stipe útgongen, en se binne net útwikselber. Jou de host in bond dy't it fabric behannelje kin as ien logyske oansluting, wat yn 'e praktyk in LACP-bond betsjut dy't mei de blêden ûnderhannele is, en beide links binne echt tegearre aktyf. Of akseptearje ek single-active levering fan it fabric, sadat it segment itselde model fan ien poarte tagelyk folget as de bond. Wat net wurket is in all-active segment foar in bond oer dy't mar op ien poarte harket, útsein as jo mei opsetsin ûntfangst op 'e net-aktive slaves oansette en de dûbele levering dy't dêrop folget akseptearje.

Wêrom't de reservekabel sûn bliuwt te lykjen

In kabel dy't gjin ferkear draacht rapportearret noch altyd link omheech, en in standby-slave yn in bond is ûntwurpen om ree te lykjen. Operators lêze dat as oerstalligens en hâlde op mei freegjen.

Freegje ynstee hokker fysike poarte it weromframe brûkte. Op 'e host, tel ûntfongen pakketten per slave ynstee fan per bond, want de bondteller ferberget de asymmetry. Op it blêd, sjoch nei de forwarding-ynskriuwings fan 'e brêge foar de MAC fan 'e server en de folgjende-hop-set dy't de EVPN-rûte draacht. As de ynskriuwing nei it blêd wiist dêr't de hostlink fan reserve is, levere it ûntwerp yn in poarte dy't de host negearret. Dat is in konfiguraasjemisferhâlding en gjin hardwareflater, en gjin inkelde hoemannichte linkstatusmonitoring sil it oan it ljocht bringe.

Test levering yn beide rjochtingen, net linkstatus

Bou in matriks mei ien rige per flater en ien kolom per rjochting, en folje dan levere ferkear yn ynstee fan ynterfacestatus. Rige ien is normale operaasje, en dat is krekt dêr't de misferhâlding him ferberget, want it symptoom liket op in applikaasjeprobleem.

Ferwiderje dan de aktive hostlink, ferwiderje ien blêd, ferwiderje de uplinks fan dat blêd, en restaurearje elk op syn bar. Skriuw nei elke stap de aktive slave, de status fan it EVPN-segment, de fiere forwarding-ynskriuwing en de waarnommen trochfier yn beide rjochtingen op. In blêd dat syn fabricpaad ferliest wylst syn hostlink omheech bliuwt, is it nijsgjirrige gefal, want de oansluting bliuwt advertearre en kin stil in dea ein wurde. Test mei nije unicast-flows en mei it oerstreamde ferkear dêr't de applikaasje fan ôfhinklik is, want de twa brûke ferskillende forwarding-besluten.

Akseptearje it ûntwerp allinnich as de matriks twarjochting-levering troch it paad sjen lit dat jo bedoelden. Twa kabels mei link omheech is net dat resultaat.