VXLAN til MPLS IP VPN: Et VNI er ikke en MPLS-label

Begge teknologier sætter en identifikator foran pakken, så konklusionen virker indlysende: knyt VNI'en til en MPLS-label, og lad de to netværk smelte sammen. Denne kobling findes ikke som understøttet handling, fordi identifikatorerne betyder forskellige ting og produceres af forskellige kontrolplan. Et VNI identificerer et VXLAN-segment inde i et overlay; en MPLS-label identificerer en videresendelsesbehandling langs en label-switchtet sti. At forbinde domænerne er en routingbeslutning, ikke en oversættelse af tal.

Myten: begge bruger etiketter, så knyt dem sammen

Den overfladiske lighed er reel og vildledende. VXLAN bærer et 24-bit VNI i sit headere, og MPLS bærer en stak etiketter, så det ser ud, som om én værdi kan skrives om til den anden på en grænseenhed.

Det, der ødelægger ideen, er alt omkring værdien. VNI'en opløses af EVPN-kontrolplanet og tunnelendepunkterne i underlaget. Etiketten tildeles af MPLS-videresendelsesplanet langs en sti. Ingen af siderne har en defineret procedure til at acceptere den anden sides identifikator som sin egen.

Hvad hver side faktisk videresender

På fabric-siden afslutter en grænseenhed VXLAN-tunnelen, knytter VNI'en til en lejer-VRF og router pakken som almindelig IP. På udbyderens side accepterer PE'en kundens rute i en VRF, påfører MPLS-labelstakken og videresender den over IP VPN'en.

Den overdragelse er den velkendte model i RFC 4364: kundekanten udveksler IP-ruter med udbyderkanten, og hvert domæne ejer sin egen indkapsling. VNI'en er væk, når pakken når PE'en, og det er præcis derfor, modellen virker.

Hvorfor kontrolplanerne ikke smelter sammen

EVPN Type 5 bærer IP-præfiksruter med overlay-next hop, mens VPN-IPv4-meddelelser hører til en anden adressefamilie. Identisk udseende route targets på begge sider oversætter ikke den ene familie til den anden og opløser ikke next hop over grænsen.

En integreret gateway kan kun udføre begge opgaver, når platformen implementerer de krævede indkapslinger og rutefamilie-samspillet. Denne evne skal verificeres for det præcise hardware og den præcise release, ikke udledes af et produktfamilienavn.

Yderligere to antagelser fejler ved denne grænse. En MPLS IP VPN leverer rutet reachability, ikke et Ethernet-segment, så udstrækning af broadcast kræver i stedet en understøttet lag 2-tjeneste. Og begge indkapslinger bruger bytes, så den effektive MTU er mindre, end noget af underlagene antyder.

Vælg rutet overdragelse eller integreret gateway

Vælg den rutede overdragelse, når lejeren har brug for IP-reachability, og udbyderen allerede tilbyder en CE-vendt tjeneste. Det holder ejerskabet rent: fabric'et ejer VXLAN og EVPN, udbyderen ejer MPLS og VPN'en, og grænsen ejer VRF-til-interface-koblingen. Planlæg tilslutningens skala, adressering og failover sammen med udbyderen i stedet for at antage, at ét link er nok.

Vælg kun en integreret gateway, når en platform, du driver, understøtter begge roller, og du kan teste samspillet. Besparelsen i bokse er reel, men det er den driftsmæssige risiko også, at én enhed bliver det eneste sted, hvor to kontrolplan skal blive enige.

Hvad der skal registreres per lejer

Hold en lejerspecifik registrering med tilslutningen, de accepterede og eksporterede præfikser, metoden til at opløse next hop og den forventede adfærd efter en fejl på grænsen eller udbyderlinket. Medtag MTU-budgettet ved begge indkapslingsgrænser og returvejen, fordi en fungerende fremadgående retning beviser meget lidt i sig selv.

Den registrering er det, der forbinder to administrative domæner uden at lade som om deres routing- og indkapslingsantagelser er de samme. Når nogen senere spørger, om VNI'en blot kan blive en label, svarer dokumentet med designet i stedet for en diskussion.