Buuin ang hangganan ng EVPN sa palibot ng patakaran sa pagluwas, hindi ng mga attachment

Ang karaniwang palagay ay ang modelo ng attachment na Layer 2 sa hangganan ang nagtatakda ng lahat sa itaas nito, kaya nagsisimula ang disenyo sa isang pares na vPC at umaakyat. Madalas itong nagtatapos sa mga desisyon sa routing na nagawa nang aksidente. Ang hangganan ng EVPN ay una sa lahat isang hangganan ng routing: ang konteksto ng routing ng nangungupahan ay sumasalubong sa isang panlabas na domain ng routing, at ang tumatawid sa linyang iyon ay isang pahayag ng patakaran. Piliin ang mga ruta, ang ugnayang ASN at ang mga landas ng pagpalya bago pa may makipagtalo tungkol sa port-channels. Ang modelo ng attachment ay sumusunod pagkatapos mula sa isang pangangailangan sa halip na magtakda nito.

Magsimula sa kung ano ang tumatawid sa hangganan

Isulat ang mga rutang dapat makita sa bawat panig, ang direksyong tinatahak nila at kung sino ang nagpapatibay ng pagbabago sa listahang iyon. Ang hangganang tumatanggap ng lahat at nagpapahayag ng lahat ay walang patakaran, may kable lamang.

Pagkatapos pangalanan ang pagpalya na balak mong patakbuhin: isang uplink na down, isang border leaf na down, o ang buong panlabas na domain na hindi maabot. Binabago ng bawat sagot kung kailangan mo ng dalawang malayang kapitbahay, isang pinagsasaluhang attachment na Layer 2, o pareho.

Pagkatapos lamang na umiral ang dalawang listahang iyon nagiging masasagot ang tanong tungkol sa attachment. Bago iyon, lahat ng mekanismo ay mukhang pantay na wasto. Pagkatapos, ang karamihan sa kanila ay nag-aalis sa sarili. Iyon ang buong argumento para unahin ang gawain sa routing.

Itakda ang hangganan ng ASN at peering

Ang fabric na may pribadong AS ay karaniwang nakikipag-peering sa pampublikong domain ng hangganan sa pamamagitan ng eBGP, at ang kawili-wiling bahagi ay ang patakaran sa magkabilang panig. Magpasya kung aling mga prefix ang tinatanggap, alin ang ipinapahayag, at anong AS path ang dapat matanggap ng upstream.

Inilalaan ng RFC 6996 ang isang saklaw ng ASN para sa pribadong paggamit, at ang mga ASN na iyon ay hindi dapat lumitaw sa mga pandaigdigang anunsyo. Ilapat ang sinusuportahang patakaran ng pag-alis o pag-filter ng plataporma at i-verify ang resultang anunsyo sa halip na ipagpalagay na ginawa ito ng device. Ang hakbang na iyon ay hindi rin nagbibigay sa iyo ng awtoridad na magpahayag ng di-makatwirang pampublikong prefix, na isang hiwalay na usapan sa may-ari ng address.

Ang isang kompederasyon o tampok na local-AS ay isang pagpipilian sa disenyo para sa isang partikular na topolohiya. Wala sa kanila ang sapilitan dahil lamang gumagamit ang fabric at upstream ng magkaibang mga papel na ASN, at ang pagpili ng isa nang walang pangangailangan ay nagdaragdag ng gumagalaw na bahagi sa bawat hinaharap na pagbabago.

Ang mga uplink na Layer 3 ay hindi nangangailangan ng multichassis LAG

Ang mga malayang routed interface na may sariling kapitbahay na BGP ay nagbibigay ng dalawang malinaw na landas at dalawang malinaw na domain ng pagpalya. Ang vPC o ibang multichassis LAG ay naglilingkod sa isang pangangailangan ng attachment na Layer 2, at ito ang tamang kasangkapan kapag umiiral ang pangangailangang iyon.

Ang pangkalahatang tuntunin na bawat pares ng hangganan ay dapat gumamit ng vPC, o dapat itong iwasan, ay nagtatago ng mga kondisyong tunay na nagpapasya sa usapin. Itanong kung ano ang dapat dalhin ng attachment, pagkatapos piliin ang mekanismong nagdadala nito nang may pinakakaunting pinagsasaluhang mode ng pagpalya.

Ang patakaran sa routing na una mong isinulat ay hindi nagbabago kapag nagbago ang mekanismo ng attachment, na isang magandang tanda na tama ang pagkakasunod-sunod.

Iluwas lamang ang kailangan ng nangungupahan

Maaaring kailanganin ng nangungupahan ang isang default na ruta, isang set ng mga piling panlabas na prefix, o isang mas malaking talahanayan. Piliin ang saklaw na iyon laban sa tunay na kapasidad ng pagpapasa at ng control plane, hindi laban sa lumang bilang ng mga rutang internet na wala nang muling nagsukat.

Ang rutang EVPN IP Prefix, karaniwang tinatawag na Type 5 at tinukoy sa RFC 9136ay nagdadala ng impormasyon ng prefix sa overlay. Kailangan pa rin ng implementasyon ang tugmang patakaran sa pagluwas at pag-angkat kasama ang paglutas ng next-hop, kaya ang pagtanggap ng panlabas na rutang BGP sa hangganan ay hindi nangangahulugang inaangkat ito ng bawat VRF ng nangungupahan.

Hindi kailangan ng bawat leaf ang kumpletong talahanayan dahil lamang hinahawakan ito ng hangganan. Ipamahagi ang kailangan ng trapiko ng nangungupahan, at hayaang ang hangganan ang magmay-ari ng natitira.

I-verify ang isang prefix mula simula hanggang wakas

Pumili ng isang kinatawang panlabas na prefix at sundan ito sa nilalayong VRF ng hangganan, sa patakaran sa pagluwas, sa konteksto ng pagpapasa ng tumatanggap na leaf at sa landas pabalik sa isang pinagmulan ng nangungupahan. Ang prefix na lumilitaw sa isang lugar at hindi sa susunod ay agad na natutukoy ang pagkakamali.

Kumpirmahin kung paano nalulutas ang next hop sa pamamagitan ng overlay, dahil ang rutang naroon na may hindi nalutas na next hop ay walang ipinapasa. Pagkatapos ulitin ang pagsusuri pagkatapos ng pagbabago sa uplink, dahil doon madalas magkaiba ang patakaran at ang paglutas ng next-hop.

Pagkakasunod-sunod ng gawain: ilista ang mga rutang tumatawid, magkasundo sa patakaran ng ASN, piliin ang attachment para sa tunay nitong gawain, saklawan ang pagluwas bawat nangungupahan, pagkatapos i-verify ang isang prefix at ang landas pabalik nito.