Routing ng sangay sa MPLS: ano ang natututuhan ng CE, at kanino

Ang isang host sa isang sangay ay nagbubukas ng koneksyon sa isang server sa ibang sangay, at ang dalawang site ay nasa likod ng parehong pinamamahalaang MPLS VPN sa layer 3. Ang host ay alam lamang ang sarili nitong default na gateway at wala nang iba, na tama. Ang mahalaga ay ibinibigay ng lokal na gilid ng customer ang packet sa gilid ng provider nito, at inihahatid ito ng routing state ng VPN ng provider sa sangay na nagmamay-ari ng prefix ng destinasyon.

Ang pagsubaybay sa isang packet sa buong landas ay ang pinakamabilis na paraan upang makita kung aling bahagi ang responsibilidad ng customer at aling bahagi ang kabilang sa serbisyo.

10.20.0.0/24 → CE-A → PE → provider core → PE → CE-B → 10.30.0.0/24

Saan nagtatapos ang trabaho ng bawat hop

Ang CE-A ay nangangailangan ng ruta patungo sa malayong LAN na nakaturo sa lokal nitong koneksyon sa provider, hindi sa WAN address ng malayong sangay. Pagkatapos ay dinadala ng provider ang packet sa sarili nitong core gamit ang routing state ng VPN, at inihahatid ito ng CE-B sa destinasyong LAN. Sa anumang punto ay hindi kailangang maunawaan ng host ang mga label, VRF o ang internet circuit ng kabilang panig.

Ang pagkakamaling paulit-ulit sa mga ticket ay ang pag-configure ng WAN address ng sangay B bilang susunod na hop sa sangay A. Pareho ang biniling serbisyo ng dalawang sangay, kaya parang dapat silang magkapitbahay. Hindi sila: ang susunod na hop ay dapat maabot sa pamamagitan ng routing design na talagang mayroon ka, at ang malayong CE ay karaniwang maraming hop ang layo sa likod ng kagamitang hindi mo pinamamahalaan. Ang static na ruta na binuo sa palagay na iyon ay lumalabas na aktibo at hindi nagreresolba sa anuman, na mas masahol pa sa nawawalang ruta dahil mukhang tama ito sa talahanayan.

Hinihiwalay ng RFC 4364 ang palitan sa pagitan ng gilid ng customer at gilid ng provider mula sa pamamahagi ng mga ruta ng VPN ng provider, at iyon ang eksaktong hangganan na tinatalakay ng gabay na ito. Ang trabaho ng customer ay sabihin sa gilid nito kung ano ang maaari nitong ihatid at tanggapin ang maabot na iniaalok pabalik ng serbisyo.

Ano ang dapat na pagkasunduan ng paghahatid

Piliin ang mekanismo kasama ng provider, hindi paligid nito. Ang mga static na ruta, BGP o kasunduan sa routing protocol sa pagitan ng CE at PE ay lahat lehitimo, at ang OSPF ay may tinukoy na modelong MPLS VPN para sa ganoong paghahatid. Wala sa mga ito ang dahilan upang bumuo ng OSPF adjacency sa pagitan ng dalawang malayong gilid ng customer sa isang hindi tinukoy na core ng provider, dahil ito ay disenyong hindi sinang-ayunan ng provider at hindi nito masusuportahan.

Bago magsimulang gumana ang bagong LAN, isulat ang apat na bagay: ang prefix, ang lokal na susunod na ruta sa CE, ang anunsyo na tatanggapin ng provider, at ang mga rutang ibabalik ng provider. Idagdag ang anumang pag-filter, limitasyon sa prefix o paghihigpit sa pagitan ng mga site na ipinapataw ng kontrata. Ang malusog na pagkakapitbahay ay isang daan para sa pagpapalitan ng impormasyon, at hindi ito patunay na natanggap ang isang partikular na prefix; maaaring nakaupo ang session habang ang bago mong subnet ay nasa loob ng filter.

Pagkatapos ay subaybayan ang tugon. Ang sangay B ay nangangailangan ng rutang pabalik sa pinagmulang LAN, at ang host sa tumatanggap na panig ay nangangailangan ng sarili nitong gateway at sarili nitong mga pahintulot sa serbisyo. Ang rutang lumalabas sa CE-A ay nagtatatag lamang ng kalahati ng paglalakbay, at ang kalahating iyon ang dahilan kung bakit mukhang malusog ang isang direksyon ng ping test habang nabibigo pa rin ang aplikasyon.

Tiyakin ang dalawang paghahatid bago tanggapin

Kolektahin ang routing state sa dalawang gilid ng customer, kumpirmahin sa provider na natanggap sa VPN ang mga nilalayong prefix ng LAN, pagkatapos ay subukan ang isang pinapayagang aplikasyon sa bawat direksyon. Ang mga talahanayan ng ruta lamang ay hindi nagpapatunay na gumagana ang aplikasyon, at ang pagsubok sa aplikasyon lamang ay hindi nagsasabi kung aling control plane ang nabigo kapag hindi ito gumana.

show ip route vrf BRANCH 10.30.0.0
show ip bgp vpnv4 vrf BRANCH
show ip cef vrf BRANCH 10.30.0.10

Basahin ang tatlong output nang magkasama. Sinasabi ng una kung ano ang pinaniniwalaan ng gilid, sinasabi ng ikalawa kung ano ang natutuhan at kanino, at sinasabi ng ikatlo kung ano talaga ang ipapasa nito. Ang pagkakaiba sa pagitan nila ay karaniwang isang isyu sa patakaran o recursion kaysa sa nawawalang anunsyo, at sulit itong ayusin bago hilingin sa provider na mag-imbestiga. Dalhin ang tatlong output na iyon sa pakikipag-usap sa operator, dahil sinasagot nila ang karamihan sa mga tanong na itatanong sana sa iyo ng support engineer.

Alamin kung ano ang hindi ibinibigay ng serbisyo

Ito ay routed na access sa layer 3. Hindi ito circuit sa layer 2 na nagpapalawak ng broadcast sa pagitan ng mga opisina, kaya ang mga discovery protocol, aplikasyong umaasa sa broadcast at palagay tungkol sa shared segment ay hindi sumasama. Ang pag-print, pag-browse ng pangalan at anumang umaasa sa lokal na segment ay nangangailangan ng sariling disenyo.

Ang paghihiwalay ng VPN ay hindi rin encryption. Ang label switching ay naghihiwalay sa mga customer sa loob ng network ng provider, at hindi nito ginagawang kumpidensyal ang payload kung hinihingi ng kontrata ang pagiging kumpidensyal. Kung saan mahalaga iyon, dapat itong ibigay ng aplikasyon o ng isang overlay.

Sa huli, itago ang modelo ng serbisyo na nakasulat sa tabi ng configuration ng routing ng site. Ang susunod na engineer na magdadagdag ng subnet ay dapat makabasa kung aling mga prefix ang inaanunsyo, sino ang tumatanggap sa mga ito at ano ang inaasahang rutang pabalik: ang espesipikasyon ng BGP/MPLS IP VPN ang sanggunian para sa modelong nasa likod ng lahat ng ito.