VXLAN til MPLS IP VPN: ein VNI er ikkje ein MPLS-etikett
Begge innkapslingane ber etikettar, så team prøver å kople ein VNI til ein MPLS-etikett. Bruk i staden ei ruta overlevering eller ein støtta gateway.
Begge teknologiane set ein identifikator framfor pakken, så konklusjonen verkar innlysande: kople VNI-en til ein MPLS-etikett og la dei to netta smelte saman. Denne koplinga finst ikkje som ein støtta operasjon, fordi identifikatorane tyder ulike ting og blir produserte av ulike kontrollplan. Ein VNI identifiserer eit VXLAN-segment inne i eit overlay; eit MPLS-etikett identifiserer ei vidaresendingshandsaming langs ein etikettbytt sti. Å binde saman domena er eit rutevedtak, ikkje ei omsetjing av tal.
Myten: begge brukar etikettar, så kople dei
Den overflatiske likskapen er reell og misvisande. VXLAN ber ein 24-bits VNI i headeren, og MPLS ber ein stabel etikettar, så det ser ut som om ein verdi kan skrivast om til den andre på ei grenseeining.
Det som øydelegg ideen, er alt rundt verdien. VNI-en blir løyst opp av EVPN-kontrollplanet og tunnelendepunkta i underlaget. Etiketten blir tildelt av MPLS-vidaresendingsplanet langs ein sti. Ingen av sidene har ein definert prosedyre for å godta identifikatoren til den andre sida som sin eigen.
Kva kvar side faktisk vidaresender
På fabric-sida avsluttar ei grenseeining VXLAN-tunnelen, koplar VNI-en til ein leigetakar-VRF og rutar pakken som vanleg IP. På leverandørsida tek PE-en imot kunderuta i ein VRF, legg på MPLS-etikettstabelen og vidaresender han over IP VPN-et.
Den overleveringa er den godt forståtte modellen i RFC 4364: kundekanten byter IP-ruter med leverandørkanten, og kvart domene eig si eiga innkapsling. VNI-en er borte når pakken når PE-en, og det er nettopp derfor modellen fungerer.
Kvifor kontrollplana ikkje smeltar saman
EVPN Type 5 ber IP-prefiksruter med overlay-neste hopp, medan VPN-IPv4-annonsar høyrer til ein annan adressefamilie. Rute-mål som ser like ut på begge sider omset ikkje den eine familien til den andre og løyser ikkje neste hopp over grensa.
Ein integrert gateway kan berre utføre begge jobbane når plattformen implementerer dei nødvendige innkapslingane og samspelet mellom rutefamiliane. Denne evna må verifiserast for den nøyaktige maskinvara og versjonen, ikkje utleiast frå eit produktfamilienamn.
To fleire føresetnader sviktar ved denne grensa. Eit MPLS IP VPN gir ruta tilgjenge, ikkje eit Ethernet-segment, så å strekkje broadcast krev i staden ei støtta lag 2-teneste. Og begge innkapslingane brukar byte, så den effektive MTU-en er mindre enn det noko av underlaga antydar.
Vel ruta overlevering eller integrert gateway
Vel den ruta overleveringa når leigetakaren treng IP-tilgjenge og leverandøren allereie tilbyr ei CE-vend teneste. Det held eigarskapet reint: fabricen eig VXLAN og EVPN, leverandøren eig MPLS og VPN-et, og grensa eig koplinga frå VRF til grensesnitt. Planlegg omfanget av tilkoplinga, adresseringa og failover saman med leverandøren i staden for å anta at éi lenkje er nok.
Vel ein integrert gateway berre når ein plattform du driftar støttar begge rollene og du kan teste samspelet. Sparinga i boksar er reell, men det er den driftsmessige risikoen òg, at éi eining blir den einaste staden der to kontrollplan må bli samde.
Kva som skal registrerast per leigetakar
Hald ei leigetakarspecifikk registrering med tilkoplinga, prefiksa som er godtekne og eksporterte, metoden for å løyse neste hopp og forventa åtferd etter ein feil på grensa eller leverandørlenkja. Ta med MTU-budsjettet ved begge innkapslingsgrensene og returvegen, fordi ei fungerande retning framover beviser svært lite åleine.
Den registreringa er det som bind saman to administrative domene utan å late som om rute- og innkapslingsføresetnadene deira er dei same. Når nokon seinare spør om VNI-en rett og slett kan bli ein etikett, svarar dokumentet med designet i staden for ein diskusjon.