VXLAN-ból MPLS IP VPN-be: a VNI nem MPLS-címke

Mindkét technológia azonosítót tesz a csomag elé, ezért a következtetés kézenfekvőnek tűnik: képezze le a VNI-t MPLS-címkére, és hagyja, hogy a két hálózat egyesüljön. Ilyen leképezés támogatott műveletként nem létezik, mert az azonosítók különböző dolgokat jelentenek, és különböző vezérlősíkok állítják elő őket. A VNI egy VXLAN-szegmenst azonosít egy overlayen belül; az MPLS-címke egy továbbítási kezelést azonosít egy címke-kapcsolt útvonal mentén. A tartományok összekapcsolása útválasztási döntés, nem számok fordítása.

A mítosz: mindkettő címkét használ, tehát képezze le őket

A felszíni hasonlóság valós és félrevezető. A VXLAN 24 bites VNI-t hordoz a fejlécében, az MPLS pedig címkék veremét, ezért úgy tűnik, mintha az egyik értéket át lehetne írni a másikba egy határeszközön.

A gondolatot minden töri meg, ami az értéket körülveszi. A VNI-t az EVPN vezérlősík és az alaphálózati alagút végpontjai oldják fel. A címkét az MPLS továbbítási sík osztja ki egy útvonal mentén. Egyik oldalnak sincs meghatározott eljárása arra, hogy a másik oldal azonosítóját sajátjaként fogadja el.

Mit továbbít valójában az egyes oldalak

A fabric oldalon egy határeszköz lezárja a VXLAN-alagutat, a VNI-t bérlői VRF-re képezi le, és a csomagot közönséges IP-ként irányítja. A szolgáltató oldalon a PE fogadja az ügyfél útvonalát egy VRF-be, felhelyezi az MPLS-címke vermét, és továbbítja az IP VPN-en.

Ez az átadás a jól ismert modell a RFC 4364-ban: az ügyfél széle IP-útvonalakat cserél a szolgáltató szélével, és minden tartomány a saját beágyazását birtokolja. A VNI addigra eltűnik, mire a csomag eléri a PE-t, és pontosan ezért működik a modell.

Miért nem olvadnak össze a vezérlősíkok

Az EVPN Type 5 overlay következő ugrásokkal rendelkező IP-előtagútvonalakat hordoz, míg a VPN-IPv4 hirdetmények másik címcsaládba tartoznak. A két oldalon azonosnak látszó útvonalcélok nem fordítanak le egyik családot a másikba, és nem oldják fel a következő ugrásokat a határon át.

Egy integrált átjáró csak akkor tudja mindkét feladatot ellátni, ha a platform megvalósítja a szükséges beágyazásokat és az útvonalcsaládok együttműködését. Ezt a képességet a pontos hardverre és kiadásra kell ellenőrizni, nem termékcsalád-névből következtetni.

Két további feltevés bukik meg ezen a határon. Az MPLS IP VPN irányított elérhetőséget nyújt, nem Ethernet-szegmenst, ezért a broadcastok kiterjesztéséhez inkább támogatott 2-es rétegű szolgáltatás kell. És mindkét beágyazás bájtokat fogyaszt, ezért az effektív MTU kisebb, mint amit bármelyik alaphálózat sugall.

Válasszon irányított átadást vagy integrált átjárót

Akkor válassza az irányított átadást, ha a bérlőnek IP-elérhetőségre van szüksége, és a szolgáltató már kínál CE felé néző szolgáltatást. Ez tisztán tartja a tulajdonviszonyokat: a fabric a VXLAN-t és az EVPN-t birtokolja, a szolgáltató az MPLS-t és a VPN-t, a határ pedig a VRF és az interfész leképezését. Tervezze meg a csatlakozás méretét, a címzést és a hibára való átállást a szolgáltatóval, ahelyett hogy feltételezné, egyetlen kapcsolat elég.

Csak akkor válasszon integrált átjárót, ha az Ön által üzemeltetett platform mindkét szerepet támogatja, és tesztelni tudja az együttműködést. Az eszközökben elért megtakarítás valós, de az az üzemeltetési kockázat is valós, hogy egyetlen eszköz lesz az egyetlen hely, ahol két vezérlősíknak meg kell egyeznie.

Mit kell rögzíteni bérlőnként

Vezessen bérlőspecifikus nyilvántartást a csatlakozással, az elfogadott és exportált előtagokkal, a következő ugrás feloldási módjával és a határ vagy a szolgáltatói kapcsolat meghibásodása után várható viselkedéssel. Vegye bele az MTU-keretet mindkét beágyazási határon és a visszautat, mert egy működő előre irány önmagában nagyon keveset bizonyít.

Ez a nyilvántartás az, ami két igazgatási tartományt összeköt anélkül, hogy azt állítaná, útválasztási és beágyazási feltevéseik azonosak. Amikor később valaki azt kérdezi, hogy a VNI egyszerűen címkévé válhat-e, a dokumentum a tervezéssel válaszol, nem vitával.