Linuxin aktiivi-varabondi all-active EVPN:ssä: mikä hajoaa

Laita palvelimelle aktiivi-varabondi ja fabriciin all-active Ethernet -segmentti, niin puolet paluuliikenteestä voi kadota yhdenkään virhelaskurin liikahtamatta. Kumpikaan kokoonpano ei ole itsessään väärin. Ongelma on niiden välisessä luovutuksessa, jossa toinen puoli valitsee yhden portin ja toinen olettaa, että jokainen kytketty lehti pystyy toimittamaan. Seuraa yhtä kehystä kumpaankin suuntaan, niin epäsuhta tulee ilmeiseksi.

Mitä aktiivi-varabondi tekee saapuvalle kehykselle

Bonding-tila 1 pitää lähetyspolussa täsmälleen yhtä slavea ja vaihtaa sen vain, kun nykyinen pettää. Tämä osa on hyvin tunnettu. Tässä ratkaisee vastaanottopuoli: ydin antaa kehyksen pinolle vain, jos se saapuu aktiiviselle slavelle, ja pudottaa kehykset, jotka ilmestyvät millekään muulle slavelle. Tämä all_slaves_active asetus on olemassa juuri tuon säännön löysäämiseksi, ja se on oletuksena pois päältä. ip -d link show bond0 tulostaa nykyisen arvon tilan vieressä.

/proc/net/bonding/bond0 nimeää aktiivisen slaven ja raportoi linkin tilan jokaiselle slavelle. Tämä tiedosto on ainoa rehellinen lähde sille, mikä portti kulloinkin kantaa liikennettä.

Tässä tilassa olevalla isännällä on kerrallaan yksi käyttökelpoinen vastaanottopolku, joka valitaan paikallisesti ilman tietoa fabricista. Jos kehys tälle isännälle saapuu toista kaapelia pitkin, kytkimen portti laskee sen vastaanotetuksi, isännän pino ei koskaan näe sitä, ja kaikki laskurit isännän omaa pudotuslaskuria lukuun ottamatta näyttävät täysin terveiltä.

Mitä all-active multihoming tekee etäiselle seuraavalle hypylle

EVPN multihoming kuvaa joukon lehtiä, jotka jakavat yhden Ethernet-segmentin, jonka ESI yksilöi, ja ilmoittaa tämän segmentin muulle fabricille. All-active-mallissa etäiset peerit asentavat segmentin osoitteille useamman kuin yhden seuraavan hypyn. Unicast palvelinta kohti voi silloin saapua kummalle tahansa lehdelle, ja fabric saa valita vapaasti virtaa kohden. Siinä on koko suunnittelun idea, ja se on myös oletus, jonka palvelimen bondin on täytettävä.

Tulviva liikenne noudattaa toista sääntöä. Lehdet valitsevat segmenttiä kohden nimetyn forwarderin, joten broadcast, tuntematon unicast ja multicast saapuvat tavallisesti yhden niistä kautta. Siksi unicast ja tulva tekevät kaksi erillistä päätöstä, ja vain toinen niistä näkyy isännän bondin tilassa.

Missä kaksi valintaa eroavat

Ydin valitsee aktiivisen slavensa linkin tilan ja oman käytäntönsä perusteella. Fabric valitsee seuraavat hypyt EVPN-reiteistä ja nimetyn forwarderin lehtien välisestä valinnasta. Kumpikaan prosessi ei kysy toiselta. Kun ne valitsevat eri lehdet, vika on suuntakohtainen: se, mitä palvelin lähettää, lähtee normaalisti, ja vastaukset katoavat.

Tarjolla on kaksi tuettua ulospääsyä, eivätkä ne ole keskenään vaihdettavissa. Anna isännälle bondi, jota fabric voi kohdella yhtenä loogisena liitoksena, mikä käytännössä tarkoittaa lehtien kanssa neuvoteltua LACP-bondia, ja molemmat linkit ovat todella aktiivisia yhdessä. Tai hyväksy myös single-active-toimitus fabricista, jolloin segmentti noudattaa samaa yksi-portti-kerrallaan-mallia kuin bondi. Se, mikä ei toimi, on all-active-segmentti sellaisen bondin edessä, joka kuuntelee vain yhdellä portilla, ellet tarkoituksella kytke vastaanottoa päälle passiivisilla slaveilla ja hyväksy siitä seuraavaa kaksinkertaista toimitusta.

Miksi varakaapeli näyttää jatkuvasti terveeltä

Kaapeli, joka ei kanna liikennettä, ilmoittaa silti linkin olevan ylhäällä, ja bondin varaslave on suunniteltu näyttämään valmiilta. Operaattorit lukevat sen redundanssiksi ja lakkaavat kysymästä.

Kysy sen sijaan, mitä fyysistä porttia paluukehys käytti. Isännällä laske vastaanotetut paketit slavea kohden, älä bondia kohden, koska bondin laskuri kätkee epäsymmetrian. Lehdellä katso sillan edelleenlähetysmerkintöjä palvelimen MAC-osoitteelle ja seuraavien hyppyjen joukkoa, jota EVPN-reitti kantaa. Jos merkintä osoittaa lehdelle, jonka isäntälinkki on varalla, suunnittelu toimittaa porttiin, jonka isäntä jättää huomiotta. Kyse on kokoonpanon epäsuhdasta eikä laiteviasta, eikä mikään määrä linkin tilan seurantaa tuo sitä esiin.

Testaa toimitusta molempiin suuntiin, älä linkin tilaa

Rakenna matriisi, jossa on yksi rivi jokaista vikaa ja yksi sarake jokaista suuntaa kohden, ja täytä se toimitetulla liikenteellä liitännän tilan sijaan. Rivi yksi on normaali toiminta, ja juuri siihen epäsuhta kätkeytyy, koska oire näyttää sovellusongelmalta.

Poista sitten isännän aktiivinen linkki, poista yksi lehti, poista kyseisen lehden uplinkit ja palauta kukin vuorollaan. Kirjaa jokaisen vaiheen jälkeen aktiivinen slave, EVPN-segmentin tila, etäinen edelleenlähetysmerkintä ja havaittu läpäisykyky molempiin suuntiin. Lehti, joka menettää fabric-polkunsa isäntälinkin pysyessä ylhäällä, on kiinnostava tapaus, koska liitos pysyy ilmoitettuna ja voi hiljaa muuttua umpikujaksi. Testaa tuoreilla unicast-virroilla ja tulvalla, josta sovellus riippuu, koska nämä kaksi käyttävät eri edelleenlähetyspäätöksiä.

Hyväksy suunnittelu vasta, kun matriisi näyttää kaksisuuntaisen toimituksen sitä polkua pitkin, jonka tarkoitit. Kaksi ylhäällä olevaa kaapelia ei ole se tulos.