RD laban sa RT sa isang MPLS VPN: pagiging natatangi laban sa patakaran sa pag-angkat

Dalawang site ng customer ang maaaring mag-anunsyo ng 10.20.0.0/24 at pareho silang nananatiling wasto sa isang network ng provider. Pinananatiling hiwalay ng route distinguisher ang mga anunsyong iyon; ang route target ang nagpapasya kung aling VRF ng customer ang maaaring kumuha ng kopya. Magkatabi silang lumalabas sa configuration at gumagawa ng lubos na magkaibang gawain. Ang paghahalo sa dalawa ay humahantong sa mga pagbabagong mukhang makatwiran at walang inaayos.

Sundan ang isang ruta mula sa gilid ng customer hanggang sa malayong VRF at nagiging konkretong: ikinakabit ang pagkakakilanlan bago pumasok ang ruta sa BGP, at sinusuri ang patakaran sa pamamahagi kapag naabot ng ruta ang gilid ng provider na tumatanggap nito.

Ang rutang VPN-IPv4 ay isang RD at isang prefix na IPv4

Tinutukoy ng RFC 4364 ang pamilya ng address na VPN-IPv4 bilang isang route distinguisher na walong byte na sinusundan ng address na IPv4 na apat na byte. Inilalagay ang RD sa harap ng prefix ng customer, kaya ang dalawang magkaparehong prefix mula sa magkaibang site ay nagiging dalawang magkaibang rutang BGP.

Ang konstruksiyon na iyon ang buong mekanismo ng pagiging natatangi. Hindi kailangan ng provider na magkasundo ang mga customer sa espasyo ng address na hindi nagsasapawan, at ang ruta mula sa isang site ay hindi maaaring tahimik na palitan ang magkaparehong prefix mula sa ibang site.

Ang format ng RD mismo ay isang halagang pinipili ng administrator, karaniwang isang numero ng autonomous system at isang lokal na numero. Ang numerong hugis nito ay isang kaugalian, hindi senyales na ang dalawang field ay may ibinabahaging kahulugan sa isang route target na nagkataong gumagamit ng parehong mga digit.

Ginagawang makikilala ng RD ang mga prefix na nagsasapawan

Isaalang-alang ang dalawang anunsyo para sa parehong prefix. Ang site A ay may RD 65000:101 at ang site B ay may RD 65000:202, pareho para sa 10.20.0.0/24. Ngayon ang BGP ay may dalawang rutang VPN-IPv4 na maaaring ihambing, salain, at piliin nang magkahiwalay.

Hindi sinasabi ng RD kung aling VRF ang dapat tumanggap ng alinman sa mga rutang iyon, at hindi nito tinutukoy ang isang customer o serbisyo. Ito ay field ng pagkakakilanlan para sa ruta, hindi listahan ng pagiging miyembro. Ang sariling RD ng isang VRF ay hindi kailangang tumugma sa RD ng rutang iniangkat nito.

Kaya’t walang inaayos ang pagpapalit ng RD upang tumugma sa numero ng ibang site. Kung kulang ang ruta sa kabilang panig, ang pagtutugma ng mga digit ay lumilikha ng ibang suliranin sa pagkakakilanlan sa halip na ayusin ang desisyon sa pag-angkat.

Ang RT ay isang atributo ng BGP, hindi isang tag sa packet

Ang patakaran sa pag-export ay nagkakabit ng isa o higit pang route target sa ruta bilang mga pinalawak na atributo ng komunidad ng BGP. Inihahambing ng gilid ng provider na tumatanggap ang mga atributong iyon sa patakaran sa pag-angkat ng bawat VRF. Naglalakbay ang RT kasama ng ruta sa control plane. Ang paghahambing ay nangyayari nang buo sa patakaran sa routing, bago ipasa ang anumang packet ng customer.

Hindi dinadala ng mga packet ng data ng customer ang RT. Kapag na-install ang ruta sa isang VRF, ginagamit ng pagpapasa ang talahanayan ng VRF na iyon at ang stack ng label ng MPLS na itinatalaga ng arkitektura. Hindi binabasa ng gilid ng provider ang isang route target mula sa bawat packet ng customer.

Ang isang ruta ay maaaring magdala ng maraming RT, at ang isang VRF ay maaaring mag-angkat ng marami. Madalas na parang maikling bloke ang configuration:

vrf definition CUST-A
 rd 65000:101
 address-family ipv4
  route-target export 65000:500
  route-target import 65000:500

Basahin ang bloke na iyon bilang dalawang magkahiwalay na pahayag. Kinokontrol ng linyang pang-export kung ano ang ikinakabit sa mga rutang lumalabas sa VRF na ito; kinokontrol ng linyang pang-angkat kung ano ang handang isaalang-alang ng VRF na ito. Ang pagtutugma ng mga numero ay maginhawa, hindi kailangan.

Ang pagiging karapat-dapat sa pag-angkat ay hindi pag-install

Ang isang ruta ay maaaring karapat-dapat para sa isang VRF at gayunman ay hindi lumabas sa talahanayan ng pagpapasa nito. Ang pagiging karapat-dapat ay isang filter; pagkatapos ay inihahambing ng normal na proseso ng desisyon ng BGP ang mga karapat-dapat na ruta at pumipili ng isa. Ang mas lumang o hindi gaanong ginustong ruta ay maaaring matalo sa isa pang karapat-dapat na landas.

Suriin ang piniling ruta, hindi lamang ang patakaran sa pag-angkat. Ang isang VRF na nag-aangkat ng RT 65000:500 at walang ipinapakitang ruta para sa 10.20.0.0/24 ay maaaring natanggap ang ruta at tinanggihan ito sa pagpili, o maaaring hindi ito natanggap kailanman.

Mahalaga rin ang pagkakaibang ito kapag lumitaw ang isang hindi inaasahang prefix. Ang masyadong malawak na patakaran sa pag-angkat ay maaaring humila ng mga rutang hindi nilayon ng site na gamitin, at walang ginagawa ang pagiging natatangi ng RD upang pigilan iyon. Ang saklaw ng pamamahagi ay isang tanong ng patakaran sa RT.

Tuklasin ang kulang na ruta sa ayos ng control plane

Magsimula sa anunsyo: iniluluwas ba ng source VRF ang inilaan na RT, at umiiral ba ang ruta bilang rutang VPN-IPv4 sa route reflector o sa PE na tumatanggap? Pagkatapos ay suriin ang atributo ayon sa natanggap, hindi ayon sa naka-configure sa nagpadala.

Susunod, ihambing ang listahan ng pag-angkat ng VRF na tumatanggap sa aktwal na mga halaga ng RT ng ruta. Panghuli, siyasatin ang piniling ruta sa VRF na iyon at ang pagbibigkis ng label. Bawat hakbang ay sumasagot sa ibang tanong, at ang paglukso sa RD ay karaniwang lumalampas sa hakbang na mali.

Itala ang RD, ang iniluwas na RT, ang iniangkat na RT at ang piniling susunod na hop para sa site na gumagana at sa site na nabibigo. Apat na halagang magkatabi ang nagpapalit ng malabong “hindi nagpapasa ng ruta ang VPN” tungo sa eksaktong hakbang ng control plane na naiiba.