Miért mutat címkét egy Junos L2VPN, miközben semmit nem továbbít

Ügyféljelentések érkeznek, miszerint az L2VPN-kapcsolat Up, a csatoló fel van, és egyetlen keret sem halad át. Az állapotlámpák őszinték; a keret olyan szolgáltatásba sorolódik, amelynek a távoli végén nincs használható továbbítási állapota. Egy BGP-vel jelzett pont-pont L2VPN esetében az első döntés a csatolóé, nem egy útvonalkeresésé. Az ügyfél kerete logikai interfészen érkezik, és ez az interfész nevezi meg a kapcsolatot, ezáltal a távoli helyet. Minden ezt követően címkékre épülő továbbítási állapot, amely abból épült fel, amit a partnerek hirdettek.

A keret soha nem végez útvonalkeresést

A jelzés előkészítette az állapotot; a csomagonkénti feldolgozás egy címkekeresés egy már kiválasztott kapcsolaton. Ezért a kérdés, hogy miért hiányzik egy útvonal, rossz kérdés, és elrejti a két fontos értéket: a csatoló kapcsolatát és az általa használt szolgáltatási címkét.

Ez magyarázza az erőfeszítés aszimmetriáját is. A konfiguráció áttekintése megmondja, mit kellett volna telepíteni, míg a kapcsolat nézete megmondja, mi származott ténylegesen, és csak az utóbbi éli túl a címkeblokk eltérését.

Két címke, két irány

Minden PE helyben oszt ki egy címkeblokkot, hirdeti annak bázisát és méretét, partnerei pedig eltolást adnak hozzá egy adott hely címkéjének kiszámításához. A kiosztások ezért helyben jelentősek: két PE különböző bázist és különböző blokkméretet használhat ugyanahhoz a szolgáltatáshoz. Olvassa el a kapcsolatot mindkét végéről, mielőtt bármit módosít. Egy címkével alulméretezett blokk pontosan úgy néz ki, mint egy kapcsolat, amely soha nem települ.

show l2vpn connections instance CUST-A extensive

Ebben a kimenetben a bejövő címke az, amelyet ez a PE kiosztott, és amelynek használatát a partnerének előírta, míg a kimenő címke a partner kiosztása, amelyet ez a PE betol. A kettő fordított olvasása a klasszikus hiba, és olyan érték keresésére küld, amelynek soha nem lett volna szabad ezen az oldalon megjelennie. A kapcsolati hivatkozás dokumentálja a címkék melletti mezőket, beleértve a helyet, az állapotot és a blokk információt.

Mit bizonyít a címkekeresés

Ha megvan a bejövő érték, a helyi keresés egyetlen parancs:

show route label 160042

Ennek a kimenetnek egy l2vpn bejegyzést kell mutatnia következő ugrással, és a címkeművelet megmondja, hogy a keret kilépés előtt betolódik, cserélődik vagy kikerül. Ha semmit nem mutat, a szolgáltatás állapota soha nem települt, pedig a kapcsolat Up-ot mutat, és az eltérés a jelzésben van, nem a szállításban.

Kövessen egy keretet

Egyetlen csomag, amelyet a csatolóba tolnak, többet dönt el, mint bármely konfigurációs áttekintés. A szolgáltatási címke útvonalának a távoli PE felé vezető szállítási LSP-re kell mutatnia, és a két címkének meg kell felelnie a partner által jelentett értékeknek. Ha a szállítás egészséges, a szolgáltatási címke pedig rossz, a keret eléri a megfelelő útválasztót, és ott eldobódik, ezért tűnnek a távoli vég számlálói üresnek, míg a közeli vég számlálói foglaltnak.

Ellenőrizze a csatoló beágyazását, a vezérlőszó beállítását és az MTU-t egyszerre, mert ezek tárgyalt tulajdonságok, nem ugrásonkénti viselkedés.

Tartsa külön a szolgáltatási modelleket

A VPLS MAC-címeket tanul, az EVPN végpontokat hirdet, míg a pont-pont L2VPN egyiket sem teszi, ezért a keretkiválasztási eljárásaik nem cserélhetők fel, pedig ugyanazon a BGP és MPLS infrastruktúrán utaznak. Egy hibaelhárítási lépés átemelése az egyik modellből a másikba magabiztos, de megalapozatlan következtetéseket ad.

Hiányzó útvonal esetén rögzítse mindkét partner kapcsolati állapotát, a csatolót, mindkét címkeirányt, a beágyazást, a vezérlőszó beállítását és az MTU-t. Ez a feljegyzés összeköti a hirdetettet azzal, amit a továbbítási sík ténylegesen tesz, ami az egyetlen számító láncszem, és ezt fogja kérni a következő mérnök is.