Hiányzó útvonal a VRF-ben: helyi, VPNv4 vagy továbbítási tábla?

Egy ügyfél azt mondja, hogy egy előtag eltűnt egy útvonalcél módosítása után, és az első képernyőkép, amit küldenek, általában a rossz tábla. Három különböző tábla három különböző kérdésre válaszol: létezik-e az előtag a VRF-en belül, meghirdették-e és importálták-e VPNv4 útvonalként, és valóban telepítettek-e továbbítási bejegyzést. Rossz sorrendben olvasva magabiztos és téves következtetéseket ad. Ez az útmutató egy helyi és egy távoli előtagot vezet végig mindhárom táblán sorrendben, és azzal az RT-módosítással kapcsolatos visszaállítási tervvel zárul, amely elindította.

Nevezze meg az előtagot és a táblát, amelybe tartozik

Írjon fel két előtagot, mielőtt bármit begépel. Az egyik helyi az ügyfél telephelyén, kapcsolt interfészről vagy CE-hirdetésből tanult. A másik távoli, és a szolgáltató gerincén át kell megérkeznie. Különböző úton jutnak ugyanabba a VRF-be, és az egyik hibája semmit sem mond a másikról.

Tartsa tisztán a két azonosító közötti különbséget, mert ezekben a jegyekben a zavar nagy része innen ered. Az útvonal-megkülönböztető a VPNv4 NLRI része, és azért létezik, hogy az egyébként azonos ügyfél-előtagok egyediek legyenek a gerincen. Az útvonalcél egy attribútumként hordozott kiterjesztett közösség, és ehhez illeszti az import- és exportszabályzatot. Nem a megkülönböztető második neve, és nem hordozzák az ügyfél csomagjaiban.

1. lépés: bizonyítsa, hogy az előtag a VRF-ben van

Kezdje a helyi nézettel, majd az importot szabályozó RT-kkel. Ha a helyi előtag itt hiányzik, semmi feljebb nem lehet a hibás:

show ip route vrf CUST-A 172.21.4.0 255.255.255.0
show ip route vrf CUST-A | include 172.21.4.0
show ip vrf CUST-A

Az előtag, amely kapcsoltként vagy statikusként jelenik meg, helyben tanult, és jelenléte semmit sem mond arról, hogy exportálták-e. Ez a leggyakoribb félreolvasás ebben a munkafolyamatban: egy egészséges VRF-tábla csak a helyi tanulás bizonyítéka. Az export oldala külön kérdés, amelyre a szomszédnézet és a hozzákapcsolt exportcél válaszol.

Ellenőrizze a VRF RT-listáit, amíg itt van. Ha a szándékolt importcél nincs a listán, minden lejjebb irreleváns. Ha ott van, de eltér attól, amit a távoli PE exportál, megtalálta a hibát anélkül, hogy egyetlen csomagrögzítést megnyitna.

2. lépés: olvassa el a VPNv4 táblát és céljait

A VPNv4 tábla megmutatja, mit cserélt valójában a vezérlősík. Keresse a távoli előtagot a megfelelő megkülönböztető alatt, majd nézze meg a hozzá kapcsolt közösségeket:

show ip bgp vpnv4 all 10.60.9.0/24
show ip bgp vpnv4 all | include 10.60.9.0
show ip bgp vpnv4 vrf CUST-A neighbors 192.0.2.17 advertised-routes

A helyes útvonalcéllal rendelkező, de helyi telepítés nélküli bejegyzés az importszabályzatra vagy az útvonalválasztásra mutat, nem az elérhetőségre. A VPNv4 táblában egyáltalán meg nem jelenő bejegyzés felfelé mutat: lehet, hogy a forrás PE nem exportálta, vagy a munkamenet nem hordozza a címcsaládot.

Van egy harmadik eset is, amely összezavarja az embereket a változtatások alatt. Egyes platformok útvonalcél-tagsági információval korlátozzák, mely VPN-útvonalakat kérik vagy tartják meg, ezért egy szűrt nézetben hiányzó távoli NLRI nem bizonyítja, hogy a hirdetés sehol nem létezik. Ellenőrizze a szűretlen táblát és a szomszéd hirdetett útvonalait, mielőtt arra következtetne, hogy egy útvonalat globálisan visszavontak.

3. lépés: erősítse meg, hogy valami telepítve és címkézve lett

A BGP-bejegyzés döntés, nem útvonal. A továbbítási táblák megmondják, van-e hová menniük a csomagoknak:

show ip cef vrf CUST-A 10.60.9.0/24
show mpls forwarding-table vrf CUST-A | include 10.60.9.0
show ip bgp vpnv4 vrf CUST-A

A feloldott szomszédsággal és kimenő címkével rendelkező CEF-bejegyzés azt jelenti, hogy az adatsík forgalmának működnie kell, és minden maradék tünet az alkalmazáshoz vagy a VRF-en belüli szűréshez tartozik. A feloldatlan következő ugrást mutató CEF-bejegyzés azt jelenti, hogy a címkeút hiányos, pedig a BGP egészségesnek látszik, és pontosan ez az eset, amikor a BGP-tábla képernyőképe félrevezetett egy változtatási ellenőrzést.

Hasonlítsa össze a helyi PE által kényszerített címkét azzal, amelyet a távoli PE fogadni vár. A két nézet közötti eltérés címkeosztási vagy munkamenet-probléma, és nem javítja meg az útvonalcélok szerkesztése, bármennyiszer is teszi.

Állítsa vissza az RT-módosítást megadott hatókörrel

Ha a hiba egy útvonalcél szerkesztésével kezdődött, vonja vissza egyetlen szándékos lépésként, és mondja meg, melyik hatókört változtatja. Az importcél eltávolítása visszavonja a jogosultságot azon a VRF-en belül. Nem törli a VPNv4 hirdetést a gerincről, és egyes platformokon az útvonal megtartva marad a táblában. Ezek különböző eredmények, és a felhasználó számára látható hatás attól függ, melyikre gondol.

configure terminal
vrf definition CUST-A
 address-family ipv4
  no route-target import 65000:410
 end
clear ip bgp vpnv4 vrf CUST-A soft in

Enyhe bemenő újrakonfigurálás elegendő, ha a munkamenet már tárolja az előtagokat; egy szolgáltató felé néző munkamenet kemény újraindítása munkaidőben olyan döntés, amelyet másvalakinek kell meghoznia. A Junoson az egyenértékű ellenőrzések közvetlenül olvassák a VRF-enkénti táblát és a VPN-táblát, és a visszaállítás commit idején történő visszatérés, nem parancsonkénti visszavonás, ezért rögzítse a konfigurációs eltérést, mielőtt elkezdi.

Ugyanazzal a három paranccsal fejezze be, amelyekkel elkezdte, ugyanabban a sorrendben, és rögzítse a kimenetüket időbélyeggel. Egy jegy, amely azt mondja, hogy az RT hibás volt és most helyes, nem használható újra; az, amely megmutatja az előtagot a VRF-ben, a VPNv4-ben és a CEF-be telepítve, bizonyíték, amelyhez a következő ember hasonlíthat. Ha csak az első kettő változott, nem fejezte be a változtatást.