Från VXLAN till MPLS IP VPN: en VNI är inte en MPLS-etikett

Båda teknikerna sätter en identifierare framför paketet, så slutsatsen verkar självklar: mappa VNI:n till en MPLS-etikett och låt de två näten smälta samman. Den mappningen finns inte som en stödd operation, eftersom identifierarna betyder olika saker och produceras av olika kontrollplan. En VNI identifierar ett VXLAN-segment inne i ett overlay; en MPLS-etikett identifierar en vidarebefordringsbehandling längs en etikettväxlad väg. Att förbinda domänerna är ett routingbeslut, inte en översättning av tal.

Myten: båda använder etiketter, så mappa dem

Den ytliga likheten är verklig och vilseledande. VXLAN bär en 24-bitars VNI i sin header, och MPLS bär en stapel etiketter, så det ser ut som om ett värde kan skrivas om till det andra på en gränsenhet.

Det som krossar idén är allt runt värdet. VNI:n löses upp av EVPN-kontrollplanet och tunneländpunkterna i underlagret. Etiketten tilldelas av MPLS-vidarebefordringsplanet längs en väg. Ingen av sidorna har en definierad procedur för att acceptera den andra sidans identifierare som sin egen.

Vad varje sida faktiskt vidarebefordrar

På fabric-sidan avslutar en gränsenhet VXLAN-tunneln, mappar VNI:n till en hyresgäst-VRF och routar paketet som vanlig IP. På leverantörssidan tar PE emot kundens rutt i en VRF, lägger på MPLS-etikettstacken och vidarebefordrar den över IP VPN.

Den överlämningen är den välförstådda modellen i RFC 4364: kundkanten utbyter IP-rutter med leverantörskanten, och varje domän äger sin egen inkapsling. VNI:n är borta när paketet når PE:n, och det är just därför modellen fungerar.

Varför kontrollplanen inte smälter samman

EVPN Type 5 bär IP-prefixrutter med overlay-nästa hopp, medan VPN-IPv4-annonser tillhör en annan adressfamilj. Identiskt lika ruttmål på båda sidor översätter inte den ena familjen till den andra och löser inte nästa hopp över gränsen.

En integrerad gateway kan bara utföra båda jobben när plattformen implementerar de nödvändiga inkapslingarna och samverkan mellan ruttfamiljerna. Den förmågan måste verifieras för den exakta hårdvaran och versionen, inte härledas från ett produktfamiljenamn.

Ytterligare två antaganden faller vid denna gräns. Ett MPLS IP VPN ger routad nåbarhet, inte ett Ethernet-segment, så att sträcka ut broadcast kräver i stället en stödd lager 2-tjänst. Och båda inkapslingarna förbrukar byte, så den effektiva MTU:n är mindre än vad något av underlagren antyder.

Välj routad överlämning eller integrerad gateway

Välj den routade överlämningen när hyresgästen behöver IP-nåbarhet och leverantören redan erbjuder en CE-vänd tjänst. Det håller ägandet rent: fabricen äger VXLAN och EVPN, leverantören äger MPLS och VPN:et, och gränsen äger mappningen från VRF till gränssnitt. Planera anslutningens omfattning, adressering och failover tillsammans med leverantören i stället för att anta att en enda länk räcker.

Välj en integrerad gateway bara när en plattform du driftar stöder båda rollerna och du kan testa samverkan. Besparingen i burkar är verklig, men det är även den driftmässiga risken att en enda enhet blir den enda platsen där två kontrollplan måste komma överens.

Vad som ska registreras per hyresgäst

Håll en hyresgästspecifik registrering med anslutningen, de accepterade och exporterade prefixen, metoden för att lösa nästa hopp och det förväntade beteendet efter ett fel på gränsen eller leverantörslänken. Ta med MTU-budgeten vid båda inkapslingsgränserna och returvägen, eftersom en fungerande riktning framåt bevisar mycket lite på egen hand.

Den registreringen är det som förbinder två administrativa domäner utan att låtsas att deras rutt- och inkapslingsantaganden är desamma. När någon senare frågar om VNI:n helt enkelt kan bli en etikett, svarar dokumentet med designen i stället för med en diskussion.