Þarf VPNv4 MPLS í kjarnanum? Ekki endilega
BGP VPNv4 semur um dreifingarsamhengi leiða, ekki áframsendingarleið. Aðskiljið innflutning, leysingu næstu hopps og þá innvafningu sem þið getið keyrt.
Að kveikja á VPNv4-vistfangafjölskyldunni milli tveggja beina skapar aðeins dreifingarsamhengi leiða og ekkert meira. Það setur ekki upp áframsendingarleið og segir ekki hvaða innvafning muni bera viðskiptavinapakka til fjarlæga endapunktsins. Þegar þessum tveimur staðreyndum er skilið að, verður spurningin „þarf þetta MPLS í kjarnanum“ þrengri og svaranleg spurning um gagnasléttuna sem kerfið styður.
Hvað semur vistfangafjölskyldan í raun um
Fjölsiða BGP ber aðgengileikaupplýsingar VPNv4-netlagsins undir AFI 1 og SAFI 128, og hver færsla parar leiðaraðgreini við forskeyti og merkingu. Lotan semur um að báðir aðilar geti kóðað og afkóðað þær upplýsingar. Það sem hún semur ekki um er gagnaslétta. Allt sem kemur eftir þessa málsgrein snýst um áframsendingu, og ekkert af því ræðst af því að lotan rís.
Þannig er árangursrík lota sönnun um getu stjórnsléttunnar, ekki áframsendingar. Beinn getur haldið þúsundum VPNv4-færslna og samt sleppt hverjum viðskiptavinapakka, og þess vegna ruglast þessir tveir bilunarklassar í upphafi.
Takið eftir merkingunni í NLRI. Hún er þjónustumerking, bundin forskeyti innan VRF, og hefur áframsendingarhlutverk þegar pakkinn nær útgangsenda. Hvort einhver gegnumstreymistæki les hana er sérstök hönnunarákvörðun.
Móttaka, innflutningur og áframsending eru þrjú skref
Að taka við leið, hafa leyfi til að nota hana og geta framsent með henni er unnið af mismunandi hlutum tækisins. BGP geymir það sem það heyrir; innflutningsstefna og samsvörun leiðarmarks ákvarða hvaða VRF má taka hana til greina; síðan verður áframsendingarsléttan að leysa tilkynntu næstu hopp í eitthvað sem hún getur raunverulega ýtt út á vír.
| Step in the chain | What has to be true | How it fails quietly |
|---|---|---|
| NLRI exchange | Both speakers negotiate the VPNv4 capability | Session stays up while the family is never activated |
| Import eligibility | A route target on the received route matches the VRF import policy | The route exists in the table but never enters the VRF |
| Next-hop resolution | The advertised next hop resolves to a usable tunnel or label path | Best path is selected, then marked unreachable or unusable |
| Encapsulation | The egress endpoint can decapsulate what the ingress produced | Packets arrive and are discarded for a format mismatch |
Það er í þessu miðskrefi sem mestu óvæntu bilanirnar búa. Leið getur verið til staðar í BGP-töflunni, gild og jafnvel sú besta, á meðan VRF-leiðatöflan er tóm því engin leiðarmark samsvaraði innflutningslistanum. Ekkert skráir prótókollsvillu, því engin prótókollsvilla átti sér stað.
Síðasta skrefið er þar sem stuðningur kerfisins kemur í ljós. Næsta hopp sem er aðgengilegt í undirlaginu er ekki sjálfkrafa leysanlegt sem flutningur VPN-þjónustu, og tækið getur krafist ákveðinnar tegundar göngu, ákveðinnar merkingaraðgerðar eða beggja. Að lesa leysingarstöðuna er upplýsandi en að lesa fjölda leiða.
IP-kjarni getur borið stafla sem hann skiptir aldrei
Það aðgreining sem vert er að halda er milli „kjarninn keyrir ekki MPLS“ og „enga merkingu er að finna hvar sem er í þjónustunni“. Þetta eru mismunandi fullyrðingar, og aðeins sú fyrri fjallar um gegnumstreymistæki. RFC 4023 skilgreinir að bera MPLS í gegnum IP- eða GRE-göng, og það er aðferðin sem gerir seinni fullyrðinguna mögulega á eingöngu IP-kjarna.
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 meaningfulGegnumstreymisbeinar framsenda eftir ytri IP-áfangastað og þurfa hvorki viðskiptavinaforskoyti né innfædda merkingu. Á fjarlæga endanum er ytra göngunni eytt og þjónustumerkingin heldur áfram starfi sínu. Kjarninn flutti ógagnsæja hleðslu, og það er einmitt það sem IP-net er gott í.
Það sem þessi hönnun gefur þér ekki er alhliða trygging. Hún er ekki sönnun þess að hver beinn leysi hvert VPNv4-næsta hopp yfir hvaða GRE-viðmót sem er, og hún er ekki ástæða til að eyða virkri innfæddri MPLS-stillingu. Hún er gagndæmi við alhliða fullyrðinguna, og hagnýta spurningin er áfram staðbundin við kerfið. Skráið þá spurningu sem takmörkun kerfisins en ekki prótókollsreglu.
Gangið keðjuna á kassanum þar til hún brotnar
Byrjið á mótteknu leiðinni og stöðvið á fyrsta skrefinu sem mistekst, því ekki er hægt að greina seinni skrefin meðan fyrra er brotið. Fjórar skipanir ná yfir mest af þessu í dæmigerðri útfærslu.
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_ALesið þær sem röð en ekki fjórar óháðar athuganir. Fyrsta staðfestir að fjölskyldan sé virk og að jafninginn skiptist á leiðum; önnur sýnir hvort forskeytið kom með nothæfu næsta hoppi; þriðja sannar innflutningshæfi; fjórða sýnir hvort áframsendingarsléttan batt merkingu eða göng við það.
Prófið síðan vinnuálagsleiðina í báðar áttir, með MTU sem lifir innvafninguna. GRE bætir við hausbætum, og leið sem stenst litlar prófanir getur mistekist á fullstórum pakkum í aðeins eina átt, sem lítur út eins og forritabilun frekar en flutningsbilun.
Tvær rekstrarlegar athugasemdir loka hringnum. GRE er innvafning, ekki trúnaður, svo ótraust gegnumstreymisnet þarf studda öryggisráðstöfun ofan á frekar en forsenda. Og skráið hvaða innvafningu kerfið styður í raun fyrir hönnunarýfirferðina, því það eina svar ræður því hvort eingöngu IP-kjarni sé gildur valkostur eða áætlun sem getur ekki framsent.