Null route sa NX-OS EVPN: panatilihin ang pagtatapon sa loob ng isang tenant

Dumarating ang kahilingan bilang pagbabago ng isang linya: i-blackhole ang isang address. Magdaragdag ka ng host route patungong Null0 sa loob ng konteksto ng tenant, mawawala ang prefix sa lokal na talahanayan gaya ng inaasahan, at pagkatapos ay magsisimula ang mga tanong. Umalis ba ang ruta sa kagamitan? Nagtapon ba ang malalayong VTEP, o nawalan lang sila ng maabot? May naaapektuhan na bang pangalawang tenant?

Ang tamang lokal na static na ruta ay sumasagot lamang sa una sa mga tanong na iyon, kaya’t ang pagbabagong blackhole ay talagang tatlong sinuring resulta at hindi isang utos.

Ano ang dapat talagang gawin ng pagbabago

Magsimula sa pagsulat ng tatlong resulta. Dapat itapon ng target na tenant ang destinasyon nang lokal. Tanging ang awtorisadong ruta ang maaaring i-export, at wala nang ibang sasama. Bawat tumatanggap na VTEP ay dapat pumili ng nilalayong aksyon ng pagtatapon at hindi ng ibang landas.

Bawat resulta ay may sariling ebidensya, at wala sa mga ito ang nagpapahiwatig ng iba. Ang lokal na Null0 na ruta ay gumagawa ng lokal na pagtatapon at, nang walang muling pamamahagi, wala talagang ini-export. Ang ruta na muling ipinamahagi nang walang napagkasunduang community ay dumarating bilang ordinaryong prefix at ipinapasa. Ang community na walang patakaran sa pagtanggap ay maaaring lubusang balewalain.

Ang pagsulat muna ng mga resulta ay nagpoprotekta rin sa iyo mula sa karaniwang pagkabigo: isang pagbabagong mukhang gumagana dahil hindi na maabot ang destinasyon sa hindi kaugnay na dahilan. Kung hindi mo maipaliwanag kung paano mo sila makikilala, hindi pa disenyo ang pagsubok sa pagtanggap.

Ang lokal na pahayag ay gumagawa lamang ng unang bahagi

Para sa NX-OS sa seryeng 10.4(x), ang null route ay nasa konteksto ng VRF ng tenant at hindi sa isang utos na nagpapangalan sa VRF. Maikli ang fragment, at talagang hindi ito kumpletong konfigurasyon ng EVPN.

vrf context TENANT_A
  ip route 192.0.2.10/32 Null0

Ang address ay prefix ng dokumentasyon, hindi target. Pansinin ang pagkakaiba sa sintaks mula sa IOS, kung saan lumilitaw ang pangalan ng VRF sa loob mismo ng utos ng ruta, at kumpirmahin ang sinusuportahang anyo para sa release na aktwal mong pinapatakbo bago mag-paste ng anuman.

Mag-isa, itinatapon ng linyang ito ang trapiko para sa host na iyon sa loob ng TENANT_A at wala nang ibang ginagawa. Hindi nito tinatag ang ruta, hindi ito pinipili para sa BGP at hindi nagtatakda ng community. Ito ay magkahiwalay na desisyon sa konfigurasyon, at bawat isa ay lugar kung saan ang pagbabago ay maaaring masyadong makitid para gumana o masyadong malawak para maging ligtas.

Ang lokal na pagtatapon ay nakakaapekto rin sa lehitimong trapiko patungo sa parehong destinasyon. Kung ang layunin ay pigilan ang isang pinagmumulang umaabuso habang kailangan pa ng tunay na mga gumagamit ang address, ang null route ay maling kasangkapan at matututuhan mo iyon sa unang tawag sa suporta.

Ang pag-export at pag-import ay magkahiwalay na kasunduan

Ang muling pamamahagi ang lugar kung saan napagpasyahan ang saklaw. Limitahan ang mga karapat-dapat na prefix sa aprubadong pagpapagaan, panatilihin ito sa loob ng tenant, at limitahan ang mga source peer sa mga nasa disenyo. Ang muling pamamahagi ng bawat static na ruta dahil kailangang maglakbay ng isang tinag na host route ay ang paraan kung paano nagiging insidente sa routing ang isang pagbabago sa maintenance.

Ang community na BLACKHOLE ay kasunduan tungkol sa isang kilalang halaga, hindi pahintulot para sa sinumang kapitbahay na itapon ang anumang address. Inilalarawan ito ng RFC 7999 sa mga terminong iyon, at ang hangganan ng tiwala kung sino ang maaaring mag-anunsyo nito ay bahagi ng disenyo at hindi detalye ng implementasyon.

Ang tumatanggap na panig ay nangangailangan ng sariling konfigurasyon. Sa NX-OS, ang mga null route na uri 5 ay nangangailangan ng pagproseso ng route-map sa VTEP upang piliin ang pag-uugali ng pagtatapon, na nakadokumento kasama ng mga hakbang sa pag-export. Ang kagamitang nagpapadala na nagtatag nang tama at ang tumatanggap na bumabalewala sa tag ay gumagawa ng pagbabagong mukhang inilapat at ipinapasa pa rin ang trapiko.

Suriin ang route-map para sa mga side effect habang nandoon ka. Ang bagong mahigpit na patakaran ay maaaring pigilan ang lehitimong maabot ng mga hindi kaugnay na prefix, at ang pinsalang iyon ay lumilitaw nang mas huli kaysa sa blackhole at mas mahirap iugnay dito.

Isulat ang pag-withdraw bago ang pagpasok

Itala ang may-ari ng destinasyon, ang dahilan, ang nag-apruba at isang petsa ng pag-expire bago i-configure ang anuman. Ang pagtatapon na walang pag-expire ay nagiging permanenteng entry na wala nang nakakaalala sa pinagmulan, at ang susunod na magde-debug ng address ay ituturing itong normal na bahagi ng network.

Panatilihin ang isang independiyenteng landas ng pamamahala na hindi umaasa sa rutang binabago mo. Kung sakop ng pagpapagaan ang isang address na ginagamit mo upang maabot ang kagamitan, gumawa ka ng lockout na may dagdag na hakbang.

Pangalanan ang eksaktong kontrol na nag-aalis ng pagpapagaan, at subukan ang pag-aalis na iyon sa laboratoryo o sa isang window na kaya mo. Ang pag-withdraw na walang sinumang nag-ensayo ay plano at hindi pamamaraan.

Tanggapin nang may ebidensya, hindi ng output ng utos

Suriin ang napiling estado ng routing at estado ng forwarding sa mga nilalayong VTEP, at suriin ang kalapit na destinasyon na dapat manatiling hindi apektado. Kumpirmahin na walang ibang tenant ang nag-import ng prefix, dahil ang pagtagas sa pagitan ng mga tenant ang mode ng pagkabigo na nagiging insidente ang isang aksyon sa maintenance.

Pagkatapos ay i-withdraw at i-verify na bumabalik ang normal na ruta at serbisyo. Ang gabay ng NX-OS EVPN sa mga null route para sa release na 10.4(x) ay nagdodokumento ng pag-tag, muling pamamahagi at patakaran sa pagtanggap na inilarawan dito, at ito ang reperensyang ihahambing sa sarili mong release.