Mula sa RIP route sa CE patungo sa malayong VRF: saan nangyayari ang export

Dumarating ang isang RIPv2 update sa provider edge, pumapasok sa isang VRF routing table at doon humihinto maliban kung may tahasang nag-export nito. Tatlong desisyon ang magkakasunod, at bawat isa ay maaaring tumanggi sa prefix sa sarili nitong dahilan. Ang pagbasa sa kanila bilang isang pangyayari lamang ang dahilan kung bakit naghahanap ang mga tao sa maling aparato kapag hindi maabot ng malayong site ang network na malinaw na inaanunsyo ng CE. Sundan ang ruta sa pamamagitan ng PE at magiging malinaw ang pagkakasunod-sunod.

Ano ang ginagawa ng PE sa isang RIP update

Tinatanggap ng PE ang update sa VRF interface, tinitingnan na ang pinagmulan ay isang pinapayagang kapitbahay, at inilalagay ang prefix sa VRF routing table na may hop count na nagmula sa anunsyo. Ang table na iyon ay ordinaryong routing table na may sariling administrative distances at sariling pagpili ng pinakamahusay na landas. Kung inaanunsyo ng CE ang parehong prefix nang dalawang beses na may magkaibang metric, ang mas mahusay lamang ang mananatili sa table. Wala sa hakbang na ito ang may kinalaman sa backbone ng provider.

Umiiral na ngayon ang prefix sa loob ng routing context ng isang customer, na malayo sa pagiging maabot saanman.

Ang export ay kilos ng patakaran, hindi bunga ng protocol

Upang umalis sa VRF, kailangang i-redistribute ang isang ruta sa MP-BGP process na nagdadala ng mga VPN route, at kailangan nito ng route target extended community na tumutukoy kung aling malalayong VRF ang maaaring mag-import nito. Ang arkitektura sa RFC 4364 ay naghihiwalay sa mga palitan na iyon mula sa CE-PE protocol sa eksaktong dahilang ito. Ang paggamit ng RIP sa gilid ay walang sinasabi tungkol sa dapat tumawid sa network ng provider.

Isulat ang export contract bago mag-configure ng anuman: ang mga customer prefix na dapat maabot mula sa malayo, ang mga rutang dapat manatiling lokal, at anumang default, mas tiyak na ruta o eksepsiyon sa shared service. Itugma ang kontratang iyon sa aktwal na VRF, hindi sa isang may katulad na pangalan na pag-aari ng ibang customer.

Ang panig ng import ay pangalawang patakaran na may sariling route targets, at ang tugmang export na may di-tugmang import ay gumagawa ng prefix na umiiral sa backbone at hindi lumilitaw sa anumang malayong table.

Magkaiba ang inaasal ng redistribution at explicit origination

Kinukuha ng redistribution ang mga rutang umiiral na sa VRF table at kino-copy ang mga ito sa BGP, na sinasala ng route map. Nagpapasya ang map kung aling prefix ang karapat-dapat at anong attribute ang dala nila, at kailangang tahasang itakda ang metric dahil walang kahulugan ang RIP hop count bilang BGP metric. Anumang iniwan mong hindi nakatakda ay namamana sa paraang karaniwang nagugulat sa taong nagbabasa ng config makalipas ang anim na buwan.

Ang mutual redistribution ang lugar kung saan nangyayari ang tahimik na pinsala. Ang isang prefix na na-export sa BGP ay maaaring bumalik sa pamamagitan ng pangalawang redistribution point, at kung walang tag o filter ay umiindayog ang ruta habang ang dalawang table ay mukhang makatwiran sa anumang sandali. Mag-filter sa mga tag na inilalapat sa gilid sa halip na umasa sa topology upang pigilan ang pabalik na landas.

Ang explicit origination ay mukhang mas maayos at hindi walang kondisyon. Ang network statement ay karaniwang nangangailangan ng tugmang ruta sa routing table bago i-originate ang prefix, kaya nawawala ang anunsyo sa sandaling itigil ng CE ang pag-aanunsyo nito. Madalas iyon ang inaasam mong pag-uugali, at hindi ito katulad ng static route na nananatiling naka-configure magpakailanman. Suriin ang aktwal na tuntunin ng platform sa halip na ipalagay ang alinman sa dalawang pag-uugali.

Sa alinmang paraan, ang tanong para sa bawat prefix ay aling aktibong pinagmulan ang nagpapakarapat-dapat dito at ano ang nangyayari kapag nawala ang pinagmulang iyon.

Beripikahin ang kadena sa apat na lugar

Tingnan ang anunsyo ng CE, ang VRF routing table, ang VPN route table kasama ang route target nito, at ang import sa malayong VRF, sa ganoong pagkakasunod-sunod. Sa IOS ibig sabihin nito ang output ng kapitbahay ng CE, show ip route vrf CUSTOMER, show ip bgp vpnv4 vrf CUSTOMER, at ang parehong command sa malayong PE. Sa IOS-XR ang katumbas na output ay nasa ilalim ng show bgp vrf CUSTOMER ipv4 unicast. Nagkakaiba ang mga pangalan ng command, ang apat na checkpoint ay hindi.

Suriin ang isang prefix na dapat tanggihan nang kasing-ingat ng isang dapat pumasa, dahil ang patakarang pumapayag sa lahat ay mukhang kapareho ng tama hanggang sa dumating ang unang eksepsiyon. Pagkatapos ay panoorin ang isang withdrawal: isara ang CE interface at tiyakin na nawawala ang malayong entry sa loob ng inaasahang timer sa halip na manatili.

Itala kung sino ang may-ari ng bawat patakaran. Kapag ang provider ang nagpapatakbo ng CE, ang inihatid na pag-uugali ay bahagi ng kontrata ng serbisyo, at ang ibang protocol o patakaran sa withdrawal sa pinamamahalaang aparato ay problema sa dokumentasyon muna bago problema sa routing.