Ugyanaz a /24 két ügyfélnek? A VPNv4-nek RD kell és címke

Két bérlő ugyanazzal a 10.50.0.0/24-gyel számozza a telephelyét, és egy változtatás után az egyik bérlő útvonala eltűnik a szolgáltató pereméről, míg a másiké tovább működik. A jegy mögötti egyszerűsítés általában az útvonal-megkülönböztető (RD) elhagyása, mert „a címke úgyis azonosítja az ügyfelet”. Nem azonosítja. Az RD és a címke két különböző kérdésre válaszol, és a különbség csak akkor válik láthatóvá, amikor az átfedő címek erre kényszerítik.

Egy útvonal ott, ahol kettőnek kellene lennie

A hagyományos IPv4 unicast két utat hasonlít össze ugyanahhoz a prefixhez, és a jobbat telepíti. Az A bérlő 10.50.0.0/24 útvonala és a B bérlő 10.50.0.0/24 útvonala egyetlen kulcs, ezért az egyik nyer, a másik pedig csak tartalék útként marad meg. A protokoll azt tette, amit mondtak neki; a vezérlősíkot arra kérték, hogy két különböző útvonalat tároljon egyetlen azonosító alatt.

Az eredmény inkább hiányzó útvonalnak tűnik, mint hibának: a versenyt elvesztő PE továbbra is helyben továbbítja a saját bérlőjét, ezért a helyszínen belüli ping sikerül, a helyszínek közötti teszt pedig elbukik. Mielőtt bármilyen szabályzathoz hozzányúlna, számolja meg az adott prefix bejegyzéseit a VPNv4 táblában.

Az RD egy kulcsból kettőt csinál

Egy nyolc bájtos útvonal-megkülönböztető kerül az IPv4 prefix elé, és a BGP által szállított objektum IPv4 prefix helyett VPN-IPv4 címmé válik. Két bérlő tarthatja ugyanazt a 32 bitet, mert az előtte lévő 64 bit különbözik. Léteznek formátumtípusok AS-alapú RD-hez és cím-alapú RD-hez, és a választás a kiinduló PE-é. Az AS-alapú RD gyakori, ha a PE-k egy AS-t osztanak meg, a cím-alapú pedig, ha nem.

Ne olvassa az RD-t tagsági címkeként. Az útvonalcélok szabályozzák az importot és az exportot, és eldöntik, mely VRF-ek telepíthetik az útvonalat; az RD csak azt garantálja, hogy az útvonalnak saját identitása van. Minden VRF saját RD-je a bevett gyakorlat, mert ez a leképezést olvashatóvá teszi egy útvonalnézetben.

A címke helyi továbbítási utasítás

Minden hirdetmény MPLS-címkét is hordoz, és jelentése arra az útválasztóra korlátozódik, amely kiosztotta. Egy másik PE ugyanazt a számot adhatja ki egy független célra. Éppen ezért nem helyettesítheti a címke az ügyfél identitását: a szám csak a következő ugrás és az azt telepítő továbbítási állapot mellett helyes.

A kiosztás granularitása a megvalósítástól és a tervezéstől függ: egyes platformok VRF-enként egy címkét osztanak ki, mások prefixenként, és a címke továbbítási műveletet jelölhet ügyfél helyett. Két különböző címke, amely ugyanahhoz a célhoz ér, nem ellentmondás, és ugyanaz a címkeszám két PE-n sem az.

Miért nem helyettesítheti egyik a másikat

Egy hirdetmény olvasása négy dolog együttes vizsgálatát jelenti: az RD-vel minősített prefix, az útvonalcélok, a következő ugrás és a címke. Egy felhasználói csomag olvasása az ebből az információból telepített verem vizsgálatát jelenti. Egy egészséges tervezés mindkét oldalt egyezőnek mutatja, egy hibásban pedig általában az egyik oldal helyes, a másik elavult. Ez az összehasonlítás választja el az identitásproblémát a továbbítási problémától.

A vezérlősík és az adatsík közötti rendezett ellentét tanítási eszköz, nem a kódolás leírása. RFC 8277 a címkét a címkézett NLRI belsejébe teszi, így maga a hirdetmény hordozza a kötést; továbbításra használni a későbbi, külön lépés.

Ha egy bérlő útvonala hiányzik, ebben a sorrendben ellenőrizzen: két VPNv4 bejegyzés a prefixhez, a helyes útvonalcél mindegyiken, feloldható következő ugrás, és olyan címke, amelyhez a fogadó PE állapottal rendelkezik. Az identitás javítása továbbítási értékkel, vagy fordítva, átmegy az egyik ellenőrzésen és elbukik a következőn.