Nem pingel az MPLS L3VPN labor? Ellenőrizze ezt az öt ugrást

Két ügyfél-router, néhány provider edge eszköz és egy ping, amely hibaüzenet nélkül hal meg. Egy kis MPLS L3VPN laborban a hiba szinte mindig öt ellenőrzési pont valamelyikénél van, és mindegyikhez tartozik egy parancs, amely vagy azt mutatja, hogy a függőség működik, vagy azt, hogy hiányzik. A hiba az, hogy minden sikertelen ping után újraindítjuk a BGP-t ahelyett, hogy a függőségeket sorrendben tesztelnénk. Ha egyenesen a VRF konfigurációra ugrik, egy órát tölthet egy olyan problémával, amely két eszközzel odébb egy fel nem oldott következő ugrással kezdődött.

Alulról felfelé haladjon végig a listán. Egy teljesített ellenőrzési pont teljesített marad, és az első hiba az, amelyet érdemes hibakeresni.

Első ellenőrzési pont: a PE-k elérik egymást

Minden PE-nek szüksége van útvonalra a másik PE loopbackjére, és ezt az útvonalat valami valóságoson keresztül kell feloldani. Egy interior gateway protocol a szokásos út odáig, de egy statikus útvonal is működik, amíg a rekurzív keresés egy élő adjacency-n landol. Az IOS-szerű eszközökön a show ip route 10.0.0.2, majd a show ip cef 10.0.0.2 megmutatja, hogy létezik-e a prefix, és hogy van-e mögötte feloldott adjacency. Egy útvonal a táblában, mögötte adjacency nélkül, nem elérhetőség.

Ellenőrizze mindkét irányt. Az aszimmetrikus IGP-költségek, a rossz oldalon lévő passive interface vagy a loopbacket szűrő distribute list külön-külön csak egy irányt törnek meg, és egy irány elég a munkamenet megöléséhez. Ha a loopbackek pingelhetők, de a BGP munkamenet Active állapotban áll, nézze meg az update source-t, mielőtt bármi máshoz nyúlna.

Második ellenőrzési pont: létezik címkeútvonal

Egy IP-útvonal a távoli loopbackre nem bizonyítja, hogy a szállítás címkét fog feltenni. LDP-tervezésben erősítse meg, hogy a távoli loopbacknek van helyi és távoli kötése, és hogy a kimenő címke megjelenik a forwarding táblában. show mpls ldp bindings 10.0.0.2 32 a címkepárokat mutatja, és show mpls forwarding-table 10.0.0.2 azt, hogy a line card valójában mit fog feltenni. Ha a második parancs nem mutat címkét, vagy IP-re esik vissza, a szállítás nem úgy viszi a VPN-forgalmat, ahogy a tervezés feltételezi.

A különbség onnan jön, ahogy az MPLS elválasztja a forwarding state-et a célprefixektől, ez a modell, amelyet a RFC 3031 ír le. Ha a laborja LDP helyett RSVP-TE-t vagy BGP-melletti címkéket használ, ellenőrizze annak a mechanizmusnak a saját állapotát; azt feltételezni, hogy az LDP minden alréteg-címkét kioszt, gyakori módja a kísértethiba üldözésének. A megtört címkeútvonal később általában olyan VPN-útvonalként jelenik meg, amely létezik, de használhatatlan.

Harmadik ellenőrzési pont: a VPN-útvonal épen megérkezett

A pontos ügyfélprefix VPNv4 vagy VPNv6 útvonalát nézze, ne a munkamenet összegzését. A show bgp vpnv4 unicast all 10.10.1.0/24-nek mutatnia kell a route distinguishert, a távoli PE loopbackre állított next hopot és egy címkét. Ha a prefix hiányzik, az első gyanúsított a kiinduló PE export-szabályzata vagy a fogadó PE import-szabályzata, és a route targetek a szokásos bűnösök.

A route target ellenőrzést a BGP-vételtől külön olvassa. Egy útvonal megérkezhet a megfelelő next hop-pal, és mégsem kerül be a VRF-be, mert az importtarget nem egyezik. A fogadó PE-n a show ip route vrf CUSTOMER 10.10.1.0 az a teszt, amely számít; a BGP-tábla csak azt bizonyítja, hogy az útvonal átlépte a vezérsíkot.

Negyedik ellenőrzési pont: az interface a VRF-ben van

Egy VRF-definíció route distinguisherrel és route targetekkel nem tesz bele egyetlen interface-t sem. A CE felé néző interface-nek szüksége van a VRF-hozzárendelésre, és a show ip vrf interfaces vagy a show ip interface brief listázza azt a megfelelő példány alatt. Ez az az ellenőrzési pont, ahol a másolt konfiguráció leggyakrabban félresiklik, mert a VRF-blokk teljesnek látszik, miközben az interface még a globális táblában ül.

Ezután erősítse meg, hogy a PE megtanulta a helyi ügyfélprefixet abba a VRF-be, és hogy a CE-nek van visszaútvonala a csatlakozáson keresztül. Egy statikus default a CE-n a PE felé elég egy laborhoz, feltéve hogy a PE VRF-jében van útvonal a CE-LAN felé. Ha bármelyik fél hiányzik, a ping a címke felhelyezése előtt meghiúsul.

Ötödik ellenőrzési pont: a válasz hazatalál

Kövesse az előre menő csomagot, majd a visszatérő csomagot, mert különböző táblákat használnak. A belépő PE-n az ügyfél forrásának a VRF-en belül a távoli prefixre kell feloldódnia a távoli címkével. A kilépő PE-n a célnak ugyanazon VRF-en belül a CE felé néző interface-re kell feloldódnia. A PE-ből magából indított ping nem bizonyíték: kiléphet a globális táblán vagy más forrás címen keresztül, és ezért a ping vrf CUSTOMER 10.10.2.10 source 10.10.1.1 az a teszt, amelyet futtatni kell.

A gazdagépek tűzfalai, a reverse-path filtering és a CE access-listái továbbra is érvényesek. Ha az odaút működik és a válasz meghal, a probléma a visszaút egy útvonalában vagy szűrőjében van, nem az MPLS-szállításban.

Vezessen ellenőrzési pontonként egy sort, amely megnevezi az elsőként meghiúsult függőséget. Az a sor az ügyfél nem tud pingelni panaszát konkrét kérdéssé alakítja az elérhetőségről, a címke állapotáról, az útvonal-importról, az interface-tagságról vagy a visszaútról, és megakadályozza, hogy a következő hibakeresés ugyanazt az öt parancsot ugyanabban a sorrendben megismételje.