Bond na aktibo-reserba ng Linux sa EVPN all-active: ano ang nasisira

Maglagay ng aktibo-reserbang bond sa server at segment ng Ethernet all-active sa fabric, at kalahati ng pabalik na trapiko ay maaaring mawala nang walang gumalaw kahit isang counter ng error. Wala sa dalawang configuration ang mali sa sarili nito. Nasa paglilipat sa pagitan nila ang problema, kung saan pinipili ng isang panig ang isang port at ipinapalagay ng kabila na lahat ng nakakabit na dahon ay makapaghahatid. Subaybayan ang isang frame sa bawat direksyon at magiging maliwanag ang pagkakaiba.

Ano ang ginagawa ng aktibo-reserba sa papasok na frame

Ang bonding mode 1 ay nag-iingat ng eksaktong isang slave sa daanan ng pagpapadala at pinapalitan lamang ito kapag nabigo ang kasalukuyan. Kilala na ang bahaging iyon. Ang mahalaga dito ay ang panig ng pagtanggap: ipinapasa lamang ng kernel ang frame sa stack kung dumating ito sa aktibong slave, at itinatapon ang mga frame na lumilitaw sa ibang slave. Ang all_slaves_active setting na ito ay umiiral para luwagan ang panuntunang iyon, at naka-off ito bilang default. ip -d link show bond0 ipinapakita ang kasalukuyang halaga sa tabi ng mode.

/proc/net/bonding/bond0 pinangalanan ang aktibong slave at iniuulat ang estado ng link ng bawat slave. Ang file na iyon ang tanging tapat na pinagmulan kung aling port ang nagdadala ng trapiko sa sandaling iyon.

Ang host sa mode na ito ay may isang magagamit na daanan ng pagtanggap sa isang pagkakataon, pinili nang lokal nang walang alam sa fabric. Kung ang frame para sa host na iyon ay dumating sa kabilang cable, binibilang ito ng port ng switch bilang natanggap, hindi ito nakikita ng stack ng host, at lahat ng counter maliban sa sariling drop counter ng host ay mukhang ganap na malusog.

Ano ang ginagawa ng all-active multihoming sa malayong susunod na hop

Inilalarawan ng EVPN multihoming ang isang set ng mga dahon na nagbabahagi ng isang segment ng Ethernet, na kinikilala ng ESI, at inaanunsyo ang segment na iyon sa natitirang bahagi ng fabric. Sa modelong all-active, ang malalayong peer ay nag-i-install ng higit sa isang susunod na hop para sa mga address ng segment. Ang unicast patungo sa server ay maaari nang makarating sa alinmang dahon, at malaya ang fabric na pumili bawat flow. Iyon ang buong layunin ng disenyo, at iyon din ang palagay na dapat tuparin ng bond ng server.

Ang bahang trapiko ay sumusunod sa ibang tuntunin. Pumipili ang mga dahon ng itinalagang forwarder bawat segment, kaya ang broadcast, hindi kilalang unicast at multicast ay karaniwang pumapasok sa isa sa kanila. Kaya ang unicast at pagbaha ay gumagawa ng dalawang magkahiwalay na desisyon, at isa lamang sa kanila ang lumilitaw sa estado ng bond ng host.

Kung saan hindi nagkakasundo ang dalawang pagpili

Pinipili ng kernel ang aktibong slave nito mula sa estado ng link at sa sariling patakaran. Pinipili ng fabric ang mga susunod na hop mula sa mga ruta ng EVPN, at ang itinalagang forwarder mula sa pagpili sa mga dahon. Wala sa dalawang proseso ang kumukonsulta sa isa. Kapag pumili sila ng magkaibang dahon, ang pagkabigo ay nakadepende sa direksyon: ang ipinapadala ng server ay lumalabas nang normal, at nawawala ang mga sagot.

May dalawang sinusuportahang paraan palabas, at hindi sila mapapalitan. Bigyan ang host ng bond na maaaring ituring ng fabric bilang isang lohikal na koneksyon, na sa pagsasagawa ay nangangahulugan ng bond na LACP na napagkasunduan sa mga dahon, at tunay na aktibo ang dalawang link nang sabay. O tanggapin din ang single-active na paghahatid mula sa fabric, upang sundin ng segment ang parehong modelong isang-port-sa-isang-panahon tulad ng bond. Ang hindi gumagana ay segment na all-active sa harap ng bond na nakikinig lamang sa isang port, maliban kung sadyang bubuksan mo ang pagtanggap sa mga hindi aktibong slave at tatanggapin ang dobleng paghahatid na kasunod.

Bakit patuloy na mukhang malusog ang reserbang cable

Ang cable na walang dalang trapiko ay nag-uulat pa rin ng link pataas, at ang standby na slave sa bond ay dinisenyo upang mukhang handa. Binabasa ito ng mga operator bilang redundancy at tumitigil sila sa pagtatanong.

Itanong sa halip kung aling pisikal na port ang ginamit ng pabalik na frame. Sa host, bilangin ang mga natanggap na packet kada slave at hindi kada bond, dahil itinatago ng counter ng bond ang asimetriya. Sa dahon, tingnan ang mga entry ng forwarding ng bridge para sa MAC ng server at ang set ng mga susunod na hop na dinadala ng ruta ng EVPN. Kung ang entry ay tumuturo sa dahon na ang link ng host ay reserba, naghahatid ang disenyo sa port na hindi pinapansin ng host. Ito ay pagkakaiba sa configuration at hindi sira ng hardware, at walang anumang monitoring ng estado ng link ang maglalantad nito.

Subukan ang paghahatid sa dalawang direksyon, hindi ang estado ng link

Bumuo ng matrix na may isang hilera bawat pagkabigo at isang haligi bawat direksyon, pagkatapos punan ng naihatid na trapiko at hindi ng estado ng interface. Ang unang hilera ay normal na operasyon, at doon mismo nagtatago ang pagkakaiba, dahil ang sintomas ay mukhang problema ng application.

Pagkatapos, alisin ang aktibong link ng host, alisin ang isang dahon, alisin ang mga uplink ng dahon na iyon, at ibalik ang bawat isa nang sunud-sunod. Pagkatapos ng bawat hakbang, itala ang aktibong slave, ang estado ng segment ng EVPN, ang malayong entry ng forwarding at ang naobserbahang throughput sa dalawang direksyon. Ang dahon na nawawalan ng landas patungo sa fabric habang nananatiling pataas ang link ng host ay ang kawili-wiling kaso, dahil nananatiling inaanunsyo ang koneksyon at maaaring tahimik na maging dead end. Subukan gamit ang mga bagong unicast flow at ang bahang trapikong umaasa rito ang application, dahil magkaiba ang desisyon sa forwarding ng dalawa.

Tanggapin ang disenyo lamang kapag ipinakita ng matrix ang paghahatid sa dalawang direksyon sa landas na nilalayon mo. Ang dalawang cable na pataas ang link ay hindi ang resultang iyon.