VXLAN til MPLS IP VPN: en VNI er ikke en MPLS-etikett

Begge teknologiene setter en identifikator foran pakken, så konklusjonen virker innlysende: koble VNI-en til en MPLS-etikett og la de to nettene smelte sammen. Denne koblingen finnes ikke som en støttet operasjon, fordi identifikatorene betyr ulike ting og produseres av ulike kontrollplan. En VNI identifiserer et VXLAN-segment inne i et overlay; en MPLS-etikett identifiserer en videresendingsbehandling langs en etikettbyttet sti. Å forbinde domenene er en ruteavgjørelse, ikke en oversettelse av tall.

Myten: begge bruker etiketter, så koble dem

Den overfladiske likheten er reell og misvisende. VXLAN bærer en 24-bits VNI i headeren, og MPLS bærer en stabel etiketter, så det ser ut som om én verdi kan skrives om til den andre på en grenseenhet.

Det som ødelegger ideen, er alt rundt verdien. VNI-en løses opp av EVPN-kontrollplanet og tunnelendepunktene i underlaget. Etiketten tildeles av MPLS-videresendingsplanet langs en sti. Ingen av sidene har en definert prosedyre for å godta den andre sidens identifikator som sin egen.

Hva hver side faktisk videresender

På fabric-siden avslutter en grenseenhet VXLAN-tunnelen, kobler VNI-en til en leietaker-VRF og ruter pakken som vanlig IP. På leverandørsiden godtar PE-en kundens rute i en VRF, legger på MPLS-etikettstabelen og videresender den over IP VPN-et.

Den overleveringen er den godt forståtte modellen i RFC 4364: kundekanten utveksler IP-ruter med leverandørkanten, og hvert domene eier sin egen innkapsling. VNI-en er borte når pakken når PE-en, og det er nettopp derfor modellen fungerer.

Hvorfor kontrollplanene ikke smelter sammen

EVPN Type 5 bærer IP-prefiksruter med overlay-neste hopp, mens VPN-IPv4-annonser tilhører en annen adressefamilie. Identisk utseende rute-mål på begge sider oversetter ikke den ene familien til den andre og løser ikke neste hopp over grensen.

En integrert gateway kan bare utføre begge jobbene når plattformen implementerer de nødvendige innkapslingene og samvirket mellom rutefamiliene. Denne evnen må verifiseres for den nøyaktige maskinvaren og versjonen, ikke utledes fra et produktfamilienavn.

To flere antakelser svikter ved denne grensen. Et MPLS IP VPN gir rutet tilgjengelighet, ikke et Ethernet-segment, så å strekke broadcast krever i stedet en støttet lag 2-tjeneste. Og begge innkapslingene bruker bytes, så den effektive MTU-en er mindre enn det noen av underlagene antyder.

Velg rutet overlevering eller integrert gateway

Velg den rutede overleveringen når leietakeren trenger IP-tilgjengelighet og leverandøren allerede tilbyr en CE-vendt tjeneste. Det holder eierskapet rent: fabricen eier VXLAN og EVPN, leverandøren eier MPLS og VPN-et, og grensen eier koblingen fra VRF til grensesnitt. Planlegg tilkoblingens omfang, adressering og failover sammen med leverandøren i stedet for å anta at én lenke er nok.

Velg en integrert gateway bare når en plattform du drifter støtter begge rollene og du kan teste samvirket. Besparelsen i bokser er reell, men det er den driftsmessige risikoen også, at én enhet blir det eneste stedet der to kontrollplan må bli enige.

Hva som skal registreres per leietaker

Hold en leietakerspesifikk registrering med tilkoblingen, de godtatte og eksporterte prefiksene, metoden for å løse neste hopp og forventet atferd etter en feil på grensen eller leverandørlenken. Ta med MTU-budsjettet ved begge innkapslingsgrensene og returveien, fordi en fungerende retning fremover beviser svært lite alene.

Den registreringen er det som forbinder to administrative domener uten å late som deres rute- og innkapslingsantakelser er de samme. Når noen senere spør om VNI-en rett og slett kan bli en etikett, svarer dokumentet med designet i stedet for en diskusjon.