Dalawang PE, isang prefix: bakit RD ang nagtatakda ng visibility

Dalawang edge router na nag-anunsyo ng parehong prefix ng customer ay naglalarawan ng isang destinasyong VPNv4 hanggang may maghiwalay sa kanila, at ang tagapaghiwalay ay ang route distinguisher. Sinusuri nito ang prefix; hindi nito pinagpapasyahan kung sino ang nag-import ng resulta, trabaho iyon ng route target. Maglaan ng RD mula sa set ng mga ruta na dapat manatiling makikilala sa bawat domain kung saan maaaring magkita ang mga anunsyong iyon, hindi mula sa layout ng file ng isang kahon. Ang numerong pipiliin mo ay isang pagkakakilanlang aasahan ng mga susunod na review, kaya dapat itong nasa isang imbentaryo bago pumasok sa isang configuration.

Isang RD at isang prefix, isang destinasyon

Isang RD at isang prefix na IPv4 ang bumubuo sa destinasyong VPNv4 na inihahambing ng control plane. Bigyan ang dalawang PE ng parehong prefix para sa magkaibang customer at, nang walang magkaibang RD, nag-anunsyo sila ng mga ruta patungo sa isang destinasyon. Wala sa screen ang magsasabi sa iyo na mali ang pagpapangkat na iyon, dahil ginagawa ng platform ang eksaktong sinasabi ng pagkakakilanlan. Palitan ang RD sa isa sa kanila at bawiin ang lumang anunsyo habang may lumilitaw na bago sa ilalim ng ibang pagkakakilanlan. Lahat ng nasa downstream na umaasa sa lumang pagkakakilanlan, mula sa pagpili ng ruta hanggang sa naka-save na filter ng operator, ay tumutukoy na ngayon sa isang bagay na wala na.

Maraming ruta kada destinasyon ay normal na pag-uugali ng BGP, hindi sintomas. Ang isang speaker ay maaaring maghawak ng maraming natanggap na ruta habang pumipili ng isang pinakamahusay para sa pagpapasa, at ang agwat sa pagitan ng natanggap at pinili ay kung saan nakatira ang mga tanong sa visibility. Kapag ang isang ruta ay tila nawala, tiyakin muna kung umiiral pa ang pagkakakilanlang kinabibilangan nito bago tingnan ang session.

Parehong RD, parehong destinasyon, magkaibang ruta

Magpadala ng isang RD at isang prefix mula sa dalawang router sa ngalan ng parehong serbisyo at parehong nag-aalok ng mga ruta patungo sa isang destinasyon, karaniwang may magkaibang susunod na hop. Alin sa mga ito ang ipapasa ng route reflector ay desisyon tungkol sa reflector: ang pagpili ng ruta, ang kakayahang mag-anunsyo at anumang patakarang nakapatong dito. Wala sa mga edge router ang kumokontrol sa pagpiling iyon. Bigyan ang dalawang anunsyo ng magkaibang RD at bawat isa ay nagiging sariling destinasyon, kaya pareho silang makakaligtas sa isang control plane na kung hindi ay nagdadala lamang ng piniling ruta para sa isang pagkakakilanlan.

Nagtatagpo ang visibility at multipath sa tumatanggap na VRF, ngunit hindi sila ang parehong desisyon, at ang reflector na nagdadala ng dalawang pagkakakilanlan ay hindi nag-configure ng pangalawang naka-install na ruta. Ini-install ng VRF ang pinapayagan ng patakaran nito sa pag-import at ang pinapayagan ng sarili nitong setting ng maximum na ruta. Suriin ang setting na iyon nang hiwalay kapag gusto mong gamitin ang pangalawang ruta at hindi lamang ito makita.

Ang tuntunin ng pagiging natatangi sa lugar ay hindi patakaran

Ang pagbibigay sa bawat PE at bawat instance ng routing ng sariling RD ay isang matinong kaugalian: pinapangalanan nito ang pinagmulan, pinipigilan ang mga walang kaugnayang serbisyo na magbanggaan sa isang pagkakakilanlan at binibigyan ang imbentaryo ng matatag na susi. Ang ilang platform ay nangangailangan lamang ng pagiging natatangi sa loob ng kahon at hayagang pinapayagan ang mga router na magbahagi ng isang RD para sa parehong instance ng VPN. Ang pahintulot na iyon ay hadlang sa implementasyon, hindi patakaran sa pagitan ng mga network na maaari mong ipaubaya sa isang vendor. Kung ang domain ay sumasaklaw sa mga team, isulat mo mismo ang patakaran sa paglalaan.

Ang pagiging miyembro ay hindi kailanman nagmumula sa mga digit. Ang pattern na tulad ng 65000:12 para sa isang PE at 65000:13 para sa isa pa ay kaugalian, samantalang ang magkatugmang target ng export at import na tulad ng 65000:112 ang naglalagay ng ruta sa isang VRF. Ituring ang RD bilang pagkakakilanlan ng isang ruta at ang route target bilang pahintulot na nagdadala nito sa isang VRF.

Patunayan ang pagbabago sa VRF, hindi sa screen

Bago hawakan ang isang RD, isulat ang apat na bagay: ano ang inaanunsyo ng PE ngayon, ano ang sinasalamin ng reflector, ano ang ini-import ng tumatanggap na VRF at aling ruta ang pinipili nito. Ang bagong RD ay nagbabawi ng isang anunsyo at nagpapasok ng iba, kaya lumilitaw ang pagbabago sa magkabilang panig ng session at madaling mabasa nang mali kung ang pinapanood mo lamang ay ang panig na nag-anunsyo. Ang pagtanggap ay dapat nakabatay sa nais na maabot, hindi sa dagdag na linya na lumilitaw sa isang listahan ng prefix. Pinipigilan ng talahanayan sa ibaba ang tatlong identifier na maghalo habang ginagawa ang review na iyon.

Magsimula sa PE na nag-anunsyo at ihambing ang dalawang pagkakakilanlan para sa parehong prefix bago mag-alis ng anuman. Ang mga utos ng IOS sa ibaba ay sumasagot sa tatlong tanong nang sunud-sunod: naroon pa ba ang lumang anunsyo, nakikita ba ng reflector ang bagong pagkakakilanlan at pinipili ba ng VRF ang prefix.

show bgp vpnv4 unicast rd 65000:12 203.0.113.0/24
show bgp vpnv4 unicast rd 65000:13 203.0.113.0/24
show ip route vrf CUSTOMER-A 203.0.113.0/24

Ipinapalabas ng ibang platform ang parehong impormasyon sa ibang sintaks at nananatili ang mga tanong pagkatapos ng pagbabagong iyon. Kung wala ang bagong pagkakakilanlan sa reflector habang inililista ito ng PE bilang inanunsyo, ang unang hinala ay ang patakaran o kakayahan sa pag-anunsyo ng reflector, hindi ang pagnunumero.

Itala ang PE, instance, RD, mga target ng export at import at pagmamay-ari ng prefix sa isang lugar, dahil ang susunod na paglalaan ay paghahanap at hindi haka-haka lamang kapag umiiral ang rekord na iyon. Panatilihin ang lumang RD hanggang makita ang bagong pagkakakilanlan sa tumatanggap na VRF, pagkatapos ay bawiin ito sa ikalawang hakbang upang manatiling maibabalik ang bawat yugto.