RD és RT az MPLS VPN-ben: egyediség és importszabály

Két ügyféltelephely hirdetheti a 10.20.0.0/24-et, és mindkettő érvényes marad egyetlen szolgáltatós hálózaton belül. Az útvonal-megkülönböztető külön tartja ezeket a hirdetéseket; az útvonal-cél dönti el, melyik ügyfél-VRF vehet át másolatot. A konfigurációban egymás mellett szerepelnek, és teljesen más feladatot látnak el. A kettő összekeverése olyan változtatásokhoz vezet, amelyek ésszerűnek tűnnek, és semmit nem javítanak.

Kövessen egy útvonalat az ügyfél peremétől egy távoli VRF-ig és a felosztás kézzelfoghatóvá válik: az identitás azelőtt kerül hozzáfűzésre, hogy az útvonal belépne a BGP-be, az elosztási szabály pedig akkor értékelődik ki, amikor az útvonal eléri a fogadó szolgáltatói peremet.

A VPN-IPv4 útvonal egy RD plusz egy IPv4 előtag

Az RFC 4364 a VPN-IPv4 címcsaládot nyolcbájtos útvonal-megkülönböztetőként határozza meg, amelyet négybájtos IPv4-cím követ. Az RD az ügyfél előtagja elé kerül, így két azonos előtag különböző telephelyekről két különböző BGP-útvonallá válik.

Ez a felépítés maga a teljes egyediségi mechanizmus. A szolgáltatónak nem kell elérnie, hogy az ügyfelek megállapodjanak egy nem átfedő címtérben, és az egyik telephely útvonala nem tudja csendben lecserélni egy másik telephely azonos előtagját.

Maga az RD-formátum a rendszergazda által választott érték, általában autonómrendszer-szám és helyi szám. Numerikus formája konvenció, nem annak jele, hogy a két mező jelentést osztana egy olyan útvonal-céllal, amely véletlenül ugyanazokat a számjegyeket használja.

Az RD megkülönböztethetővé teszi az átfedő előtagokat

Tekintsünk két hirdetést ugyanarra az előtagra. Az A telephely RD-je 65000:101, a B telephelyé 65000:202, mindkettő a 10.20.0.0/24-hez. A BGP-ben most két VPN-IPv4 útvonal van, amelyek egymástól függetlenül összehasonlíthatók, szűrhetők és kiválaszthatók.

Az RD nem mondja meg, melyik VRF kapja bármelyik útvonalat, és nem azonosít ügyfelet vagy szolgáltatást. Ez az útvonal identitásmezője, nem tagsági lista. Egy VRF saját RD-jének nem kell megegyeznie az általa importált útvonal RD-jével.

Ezért nem javít semmit, ha egy RD-t egy másik telephely számához igazítunk. Ha az útvonal hiányzik a túloldalon, a számjegyek egyeztetése másfajta identitásproblémát teremt az importdöntés javítása helyett.

Az RT BGP-attribútum, nem csomagcímke

Az exportszabály egy vagy több útvonal-célt csatol az útvonalhoz BGP kiterjesztett közösségi attribútumként. A fogadó szolgáltatói perem ezeket az attribútumokat minden VRF importszabályával összeveti. Az RT az irányítási síkon keresztül utazik az útvonallal. Az összevetés teljes egészében az útválasztási szabályban történik, mielőtt bármely ügyfélcsomag továbbításra kerülne.

Az ügyfél adatcsomagjai nem hordozzák az RT-t. Miután egy útvonal telepítésre került egy VRF-be, a továbbítás az adott VRF tábláját és az architektúra által kiosztott MPLS-címkevermet használja. A szolgáltatói perem nem olvas útvonal-célt minden ügyfélcsomagból.

Egy útvonal több RT-t is hordozhat, és egy VRF többet is importálhat. A konfiguráció gyakran rövid blokknak tűnik:

vrf definition CUST-A
 rd 65000:101
 address-family ipv4
  route-target export 65000:500
  route-target import 65000:500

Ezt a blokkot két külön állításként olvassa. Az export sor szabályozza, mi kerül az ezt a VRF-et elhagyó útvonalakra; az import sor szabályozza, mit hajlandó figyelembe venni ez a VRF. Az egyező számok kényelmesek, de nem kötelezőek.

Az importjogosultság nem telepítés

Egy útvonal lehet jogosult egy VRF számára, és mégsem jelenik meg annak továbbítási táblájában. A jogosultság szűrő; utána a szokásos BGP-döntési folyamat összeveti a jogosult útvonalakat, és kiválaszt egyet. Egy régebbi vagy kevésbé előnyben részesített útvonal veszíthet egy másik jogosult úttal szemben.

A kiválasztott útvonalat ellenőrizze, ne csak az importszabályt. Egy VRF, amely importálja az RT 65000:500-at, és nem mutat útvonalat a 10.20.0.0/24-hez, talán megkapta az útvonalat és elutasította a kiválasztás során, vagy talán soha nem kapta meg.

Ez a megkülönböztetés akkor is számít, amikor váratlan előtag jelenik meg. A túl széles importszabály olyan útvonalakat is behúzhat, amelyeket a telephely nem szándékozott használni, és az RD egyedisége ezt egyáltalán nem akadályozza. Az elosztás kiterjedése RT-szabály kérdése.

Hibakeresse a hiányzó útvonalat az irányítási sík sorrendjében

Kezdje a hirdetéssel: exportálja-e a forrás-VRF a szándékolt RT-t, és létezik-e az útvonal VPN-IPv4 útvonalként az útvonal-reflektoron vagy a fogadó PE-n? Utána ellenőrizze az attribútumot úgy, ahogy megérkezett, nem úgy, ahogy a küldőnél be van állítva.

Ezután hasonlítsa össze a fogadó VRF importlistáját az útvonal tényleges RT-értékeivel. Végül vizsgálja meg a kiválasztott útvonalat abban a VRF-ben és a címkehozzárendelést. Minden lépés más kérdésre válaszol, és az RD-hez ugrás általában éppen a hibás lépést hagyja ki.

Jegyezze fel az RD-t, az exportált RT-t, az importált RT-t és a kiválasztott következő ugrást a működő és a hibás telephelyhez. Négy érték egymás mellett egy homályos “a VPN nem továbbít útvonalakat” mondatot az irányítási sík azon pontos lépésévé alakít, amely eltér.