Kailangan ba ng VPNv4 ang MPLS sa core? Hindi kinakailangan

Ang pag-on ng pamilya ng address na VPNv4 sa pagitan ng dalawang router ay lumilikha lamang ng konteksto ng pamamahagi ng ruta at wala nang iba. Hindi ito naglalagay ng daanan ng pagpapasa at hindi nagsasabi kung aling encapsulation ang magdadala ng packet ng kliyente sa malayong endpoint. Kapag ang dalawang katotohanang ito ay pinaghiwalay, ang tanong na «kailangan ba nito ng MPLS sa core» ay nagiging mas makitid at masasagot na tanong tungkol sa data plane na sinusuportahan ng platform.

Ano ba talaga ang pinag-uusapan ng pamilya ng address

Ang multiprotocol BGP ay nagdadala ng impormasyon ng reachability ng VPNv4 network layer sa ilalim ng AFI 1 at SAFI 128, at ang bawat entry ay nagpapares ng route distinguisher sa isang prefix at isang label. Ang session ay nakikipag-usap na ang dalawang panig ay makakapag-encode at makakapag-decode ng impormasyong iyon. Ang hindi nito pinag-uusapan ay isang data plane. Lahat ng pagkatapos ng talatang ito ay tungkol sa pagpapasa, at wala sa mga ito ang napagpasyahan ng pag-angat ng session.

Kaya ang isang matagumpay na session ay patunay ng kakayahan ng control plane, hindi ng pagpapasa. Maaaring maghawak ang router ng libu-libong VPNv4 entry at itapon pa rin ang bawat packet ng kliyente, at iyon ang dahilan kung bakit ang dalawang klase ng pagkabigo ay napagkakamalan sa simula.

Pansinin ang label sa NLRI. Ito ay label ng serbisyo, nakatali sa isang prefix sa loob ng VRF, at may papel ito sa pagpapasa kapag ang packet ay umabot sa exit endpoint. Kung binabasa ito ng anumang transit device ay hiwalay na desisyon sa disenyo.

Ang pagtanggap, import at pagpapasa ay tatlong hakbang

Ang pagtanggap ng ruta, ang pagpapahintulot na gamitin ito at ang kakayahang ipasa ito ay ginagawa ng iba't ibang bahagi ng device. Iniimbak ng BGP ang naririnig nito; ang patakaran sa import at pagtutugma ng target ng ruta ang nagpapasya kung aling VRF ang maaaring isaalang-alang ito; pagkatapos ay dapat i-resolve ng forwarding plane ang inihayag na susunod na hop sa isang bagay na talagang maitutulak nito sa wire.

Sa gitnang hakbang na ito nakatira ang pinaka-nakakagulat na mga pagkabigo. Ang isang ruta ay maaaring naroroon sa BGP table, valid at maging pinakamahusay, habang ang VRF route table ay nananatiling walang laman dahil walang target ng ruta ang tumugma sa import list. Walang nagtatala ng error ng protocol, dahil walang error ng protocol na nangyari.

Ang huling hakbang ay kung saan lumilitaw ang suporta ng platform. Ang susunod na hop na maabot sa underlay ay hindi awtomatikong nare-resolve bilang transport ng serbisyo ng VPN, at ang device ay maaaring mangailangan ng partikular na uri ng tunnel, partikular na operasyon ng label o pareho. Ang pagbasa ng status ng resolution ay mas nagbibigay-kaalaman kaysa sa pagbasa ng bilang ng ruta.

Ang isang IP core ay maaaring magdala ng stack na hindi nito kailanman ini-switch

Ang pagkakaiba na sulit panatilihin ay sa pagitan ng «hindi nagpapatakbo ng MPLS ang core» at «walang label saanman sa serbisyo». Ito ay magkaibang mga pahayag, at ang una lamang ang tungkol sa mga transit device. Tinutukoy ng RFC 4023 ang pagdadala ng MPLS sa pamamagitan ng IP o GRE tunnel, at iyon ang mekanismong nagpapaging-posible sa ikalawang pahayag sa isang core na puro IP.

customer packet + service label
  encapsulated in GRE, addressed to the egress tunnel endpoint
  forwarded by ordinary IP routers on the outer header
  decapsulated at the endpoint, label still meaningful

Ang mga transit router ay nagpapasa batay sa panlabas na destinasyon ng IP at hindi kailangan ang mga prefix ng kliyente o ang native na paglilipat ng label. Sa malayong dulo, tinatanggal ang panlabas na tunnel at ipinagpapatuloy ng label ng serbisyo ang trabaho nito. Naglipat ang core ng isang opaque na payload, at iyon mismo ang magaling sa isang IP network.

Ang hindi ibinibigay sa iyo ng disenyong ito ay isang pangkalahatang garantiya. Hindi ito patunay na nire-resolve ng bawat router ang bawat susunod na hop ng VPNv4 sa anumang GRE interface, at hindi ito dahilan upang burahin ang isang gumaganang native na MPLS configuration. Ito ay kontrahalimbawa sa pangkalahatang pahayag, at ang praktikal na tanong ay nananatiling lokal sa platform. Itala ang tanong na iyon bilang limitasyon ng platform at hindi bilang tuntunin ng protocol.

Lakarin ang chain sa kahon hanggang sa ito ay masira

Magsimula sa natanggap na ruta at huminto sa unang hakbang na nabibigo, dahil ang mga susunod na hakbang ay hindi maaaring ma-diagnose habang ang nauna ay sira. Apat na command ang sumasaklaw sa karamihan nito sa isang tipikal na implementasyon.

show bgp vpnv4 unicast all summary
show bgp vrf CUSTOMER_A ip route 198.51.100.0/24
show ip route vrf CUSTOMER_A 198.51.100.0
show mpls forwarding-table vrf CUSTOMER_A

Basahin ang mga ito bilang isang pagkakasunod-sunod at hindi bilang apat na independiyenteng pagsusuri. Ang una ay nagpapatunay na ang pamilya ay aktibo at ang peer ay nagpapalitan ng ruta; ang pangalawa ay nagpapakita kung ang prefix ay dumating na may magagamit na susunod na hop; ang pangatlo ay nagpapatunay ng pagiging karapat-dapat sa import; ang pang-apat ay nagpapakita kung ang forwarding plane ay nagbigkis ng label o tunnel dito.

Pagkatapos ay subukan ang daanan ng workload sa parehong direksyon, gamit ang MTU na nakakayanan ang encapsulation. Ang GRE ay nagdaragdag ng header bytes, at ang isang daanan na pumasa sa maliliit na probe ay maaaring mabigo sa full-size na packet sa isang direksyon lamang, na mukhang sira ng application at hindi ng transport.

Dalawang operational note ang nagsasara ng loop. Ang GRE ay encapsulation, hindi confidentiality, kaya ang hindi pinagkakatiwalaang transit network ay nangangailangan ng suportadong security arrangement sa itaas nito at hindi ng isang palagay. At itala kung aling encapsulation ang aktwal na sinusuportahan ng platform bago ang design review, dahil ang nag-iisang sagot na iyon ang nagpapasya kung ang isang only-IP core ay isang wastong pagpipilian o isang planong hindi makapagpasa.