Ang tahimik na host ng EVPN ay hindi kailanman naresolba: sundan ang ARP hanggang sa bigkis

Nakakabit ang endpoint, aktibo ang port nito, at hindi pa rin ito maabot ng monitoring host. May magpapatakbo ng ping mula sa kabilang panig at magsisimula itong gumana, na nagpapamukhang paminsan-minsan ang problema at nagpapamukhang inosente ang fabric. Ang pattern na iyon ay ang pirma ng isang tahimik na host: bihira itong magpadala, kaya mas mahalaga ang pag-uugali ng pagtuklas at pag-refresh ng fabric kaysa sa kalagayan ng koneksyon nito. Magsimula sa isang nilalayong IP, MAC at bridge domain at sundan ang susunod na palitan ng resolusyon.

Sundan ang susunod na palitan ng ARP o ND

Para sa IPv4, panoorin ang palitan ng ARP ng humihiling na host; para sa IPv6, sundan ang Neighbor Solicitation at Advertisement. Tiyakin na ang kahilingan ay pumapasok sa nilalayong lokal na segment at sa nilalayong VNI, dahil ang kahilingang hindi kailanman umabot sa tamang bridge domain ay hindi masasagot ng anumang proxy.

Pagkatapos tingnan kung ano ang alam ng fabric tungkol sa target. Ang rutang MAC lamang ay makikilala ang isang destinasyon ng Layer 2 habang ang proxy ay wala pang bigkis na IP-to-MAC para dito. Magkahiwalay ang mga talaang ito, at ang pagsuri sa isa ay walang sinasabi tungkol sa isa.

Kung may valid na bigkis, makakasagot ang proxy ayon sa patakaran nito, ngunit ang MAC sa bigkis na iyon ay nangangailangan pa rin ng aktibong landas ng pagpapasa. Kung wala ang bigkis, kailangang maabot ng kahilingan ang koneksyon ng endpoint sa pamamagitan ng landas ng flooding o replikasyon bago may makapag-aral mula sa sagot.

Dalawang talaan na dapat magtugma

Sinasagot ng rutang MAC kung saan nakatira ang address ng Ethernet. Sinasagot ng talahanayan ng proxy kung aling IP ang nagma-map sa aling MAC. Ang host na hindi nag-salita kamakailan ay maaaring may perpektong rutang MAC at walang magamit na entry ng proxy, at iyon mismo ang kalagayang lumilikha ng kabiguan ng resolusyon sa isang malusog na koneksyon.

Sa malayong koneksyon, tiyakin kung talagang natatanggap at nasasagot ng endpoint ang palitan. Ang sagot nito ay nagre-refresh ng lokal na pagkatuto at ng kaukulang anunsyo ng EVPN, kaya lumilitaw na inaayos ng manu-manong ping ang mga bagay: ikaw ang gumawa ng trapikong hinihintay ng fabric. Ipinapaliwanag din nito kung bakit hindi tumatagal ang pagtatama: kapag naluma ang na-refresh na entry, tahimik na naman ang endpoint. Ang naka-iskedyul na ping ay tumitingin sa sintomas at itinatago ang puwang sa disenyo.

Pagkatapos ng sagot, sundan ang napiling ruta at ang naka-install na estado ng pagpapasa pabalik sa humihiling. Ang tagumpay ng resolusyon at ang tagumpay ng pagpapasa ay dalawang magkahiwalay na pangyayari, at ang tiket na pinagsasama ang mga ito ay nagpapadala sa iyo sa maling antas.

Ano ang aktwal na ipinapalagay ng pamantayan

RFC 9161 inilalarawan ang dinamikong pagkatuto ng proxy at ang default na flooding ng hindi kilalang mga kahilingan ng ARP at ND. Ang kumpletong pagsugpo sa flooding na iyon ay limitado sa mga deployment na ang mga palagay sa pagkatuto o pag-provision ay ginagawa itong ligtas, na isang mas makitid na kondisyon kaysa sa ipinahihiwatig ng karamihan sa mga gabay sa pagsasaayos.

Ang fabric na umaasa sa mga bagong tuklas na endpoint ay nangangailangan ng gumaganang landas para sa mga kahilingang iyon. Kung may nagpatay ng flooding ng hindi kilalang mga kahilingan upang bawasan ang trapikong BUM, ang mga tahimik na host ang populasyong nagbabayad para doon, at ang sintomas ay darating pagkalipas ng mga linggo bilang reklamo tungkol sa paminsan-minsang pag-abot.

Basahin ang setting ng pagsugpo bilang pahayag tungkol sa kung ano ang ipinangangako ng fabric na malaman. Kung walang nagpo-provision ng mga bigkis, hindi totoo ang pangako para sa bihirang nagpapadala. Ihambing ang naka-configure na pagsugpo sa sistemang nagpo-provision na dapat magpakain dito. Kapag hindi nagtugma ang dalawang iyon, ang fabric ay kumikilos nang eksakto ayon sa na-configure, at ang inaasahan ang kailangang ayusin.

Pag-refresh, pagtanda at ang static na alternatibo

Inilalarawan ng pamantayan ang mga suportadong probe ng pag-refresh bago tumanda ang mga dinamikong entry. Ang mga sagot ay nagre-refresh ng kaugnay na estado ng bridge at proxy; ang kawalan ng mga sagot ay lehitimong maaaring humantong sa pag-alis at pagbawi ng ruta. Hindi ito bug na dapat sugpuin sa pamamagitan ng pagbanat sa bawat timer.

Ang walang hanggang pagpapahaba ng mga timer ng pagtanda ay nagpapalit ng nakikitang kabiguan sa isang lipas na: patuloy na inaanunsyo ng fabric ang isang lokasyong iniwan ng host. Gamitin ang mga dokumentadong kontrol ng implementasyon at pumili ng haba ng buhay na tumutugma sa dalas ng maaasahang pag-salita ng endpoint.

Para sa mga kilala at pinamamahalaang endpoint, ang static o ibinigay ng controller na bigkis ay isang lehitimong ikalawang modelo. Nangangailangan ito ng may-ari na humahawak sa pagpapalit at paglipat, dahil ang ibinigay na talaan ay hindi nag-a-update sa sarili kapag lumipat ang host sa ibang port.

Ano ang itatala bago ang susunod na tiket

Itabi ang pinagmulan ng bigkis, oras ng huling pag-refresh, kasalukuyang lokasyon at anumang pangyayari ng pagbawi sa tabi ng rutang MAC. Sinasagot ng talaang iyon ang tanong na talagang itinatanong ng tiket: naghihintay ba ang aplikasyon sa pagtuklas, umaasa ba ito sa lipas na estado, o nabigo ba itong magpasa pagkatapos ng matagumpay na resolusyon?

Pagkatapos magpasya kung alin sa tatlo ang handa kang patakbuhin. Pagtuklas na may flooding, pag-refresh na may makatotohanang haba ng buhay, o pag-provision na may may-ari ay lahat mapagtatanggol. Ang fabric na naka-configure para sa isa at inaasahang kumilos na parang iba ay doon naglalaho ang mga tahimik na host.