CE RIP útvonaltól a távoli VRF-ig: hol történik az exportálás

Egy RIPv2 frissítés megérkezik a szolgáltatói peremre, bekerül egy VRF útválasztási táblába, és ott is marad, hacsak valami kifejezetten nem exportálja. Három döntés történik egymás után, és mindegyik saját okból utasíthatja el a prefixet. Az, hogy egyetlen eseményként olvassuk őket, az oka annak, hogy az emberek a rossz eszközt kergetik, amikor egy távoli telephely nem ér el egy hálózatot, amelyet a CE egyértelműen hirdet. Kövesse az útvonalat a PE-n keresztül, és a sorrend nyilvánvalóvá válik.

Mit tesz a PE egy RIP frissítéssel

A PE a VRF interfészen fogadja a frissítést, ellenőrzi, hogy a forrás engedélyezett szomszéd-e, majd a hirdetésből származtatott ugrásszámmal beilleszti a prefixet a VRF útválasztási táblába. Ez a tábla normál útválasztási tábla saját adminisztratív távolságokkal és saját legjobb útvonal választással. Ha a CE ugyanazt a prefixet kétszer hirdeti eltérő metrikákkal, csak a jobb marad meg a táblában. Ebben a lépésben semmi sem érinti a szolgáltató gerinchálózatát.

A prefix most egyetlen ügyfél útválasztási környezetében létezik, ami nagyon messze van attól, hogy bárhol máshol elérhető legyen.

Az exportálás házirendi aktus, nem a protokoll következménye

Ahhoz, hogy elhagyja a VRF-et, az útvonalat újra kell terjeszteni a VPN útvonalakat szállító MP-BGP folyamatba, és szüksége van egy útvonalcél kiterjesztett közösségre, amely azonosítja, mely távoli VRF-ek importálhatják. A RFC 4364 szerinti architektúra pontosan ezért tartja ezeket a cseréket külön a CE-PE protokolltól. A RIP használata a peremen semmit sem mond arról, minek kell átkelnie a szolgáltatói hálózaton.

Írja le az exportálási szerződést, mielőtt bármit beállítana: azokat az ügyfélprefixeket, amelyeknek távolról elérhetőnek kell lenniük, azokat az útvonalakat, amelyeknek helyben kell maradniuk, és minden alapértelmezett, pontosabb vagy megosztott szolgáltatási kivételt. Hasonlítsa össze ezt a szerződést a tényleges VRF-fel, ne egy másik ügyfél hasonló nevű VRF-jével.

Az import oldal egy második házirend saját útvonalcélokkal, és a megfelelő export a nem megfelelő importtal olyan prefixet hoz létre, amely létezik a gerinchálózatban, és egyetlen távoli táblában sem jelenik meg.

Az újraelosztás és a kifejezett eredetkezelés eltérően viselkedik

Az újraelosztás a VRF táblában már meglévő útvonalakat veszi át, és egy útvonal-térkép szűrése után átmásolja őket a BGP-be. A térkép dönti el, mely prefixek jogosultak és milyen attribútumokat hordoznak, és a metrikát kifejezetten be kell állítani, mert a RIP ugrásszámnak nincs jelentése BGP metrikaként. Amit beállítatlanul hagy, az olyan módon öröklődik, amely általában meglepi azt, aki hat hónappal később olvassa a konfigurációt.

A kölcsönös újraelosztás az a hely, ahol a csendes kár történik. A BGP-be exportált prefix visszatérhet egy második újraelosztási ponton keresztül, és címkék vagy szűrők nélkül az útvonal oszcillál, miközben mindkét tábla bármely pillanatban hihetőnek tűnik. A peremen alkalmazott címkékre szűrjön, ahelyett hogy a topológiában bízna a visszaút megakadályozásában.

A kifejezett eredetkezelés rendezettebbnek tűnik, és nem feltétel nélküli. Egy hálózati utasítás általában megfelelő útvonalat igényel az útválasztási táblában, mielőtt a prefix létrejön, így a hirdetés abban a pillanatban eltűnik, amikor a CE abbahagyja a hirdetést. Ez gyakran a kívánt viselkedés, és nem ugyanaz, mint egy statikus útvonal, amely örökre beállítva marad. Ellenőrizze a platform tényleges szabályát ahelyett, hogy bármelyik viselkedést feltételezné.

Akárhogy is, minden prefixnél azt a kérdést kell feltenni, melyik aktív forrás teszi jogosulttá, és mi történik, amikor az a forrás eltűnik.

Négy helyen ellenőrizze a láncot

Nézze meg a CE hirdetést, a VRF útválasztási táblát, a VPN útvonaltáblát az útvonalcéljával, és a távoli VRF importját, ebben a sorrendben. IOS-en ez a CE szomszéd kimenetét jelenti, show ip route vrf CUSTOMER, show ip bgp vpnv4 vrf CUSTOMER, és ugyanezt a parancsot a távoli PE-n. IOS-XR-en az egyenértékű kimenet ez alatt található: show bgp vrf CUSTOMER ipv4 unicast. A parancsnevek eltérnek, a négy ellenőrzési pont nem.

Ellenőrizze az elutasítandó prefixet ugyanolyan gondosan, mint azt, amelynek át kell mennie, mert a mindent engedélyező házirend az első kivétel megérkezéséig ugyanúgy néz ki, mint egy helyes. Ezután figyelje meg a visszavonást: kapcsolja ki a CE interfészt, és erősítse meg, hogy a távoli bejegyzés a várt időzítőn belül eltűnik, nem pedig megmarad.

Jegyezze fel, ki birtokolja az egyes házirendeket. Amikor a szolgáltató üzemelteti a CE-t, a szállított viselkedés a szolgáltatási szerződés része, és a felügyelt eszközön egy másik protokoll vagy visszavonási házirend dokumentációs probléma, mielőtt útválasztási probléma lenne.