Néhány L2VPN-útvonal eltűnik, miután útvonal-tükrözőket ad hozzá

A munkamenetek fennmaradnak, az IGP stabil, és mégis néhány L2VPN-útvonal soha nem jelenik meg a szolgáltató négy pereme közül kettőn. Ez a minta tükrözési, nem pedig átviteli problémához tartozik, mert a megszakadt munkamenet teljesen elbukik, míg az újrahasznált tükrözési határ szelektíven bukik el. A fizikai gyűrűhöz semmi köze; a logikai elosztási gráf az a hely, ahol ezek az útvonalak megálltak. Ennek a pontnak a megtalálása nem igényli a vezérsík újjáépítését.

A veszteség szelektív, ami szűkíti a keresést

Egy fizikai gyűrűn négy szolgáltatói peremnek hat logikai munkamenet kell a teljes hálóhoz, mert minden útválasztó a másik hárommal párosul. Ezek a munkamenetek a routolt átvitelen haladnak, így a kábelezés semmit nem mond arról, hány szomszédság létezik, vagy melyikük tükröz. Amikor két perem kihagy egy adott prefixkészletet, miközben minden más konvergál, a kábel nem gyanús.

A szelektív veszteség a hurokvédelemre, a házirendre vagy a kapcsolat irányára utal, ahol egyes útvonalak átlépnek egy határt, mások pedig útközben eldobódnak. A teljes veszteség a munkamenetre vagy a címcsaládra utal. Eldönteni, melyiket látja a kettő közül, az első hasznos lépés, és egyetlen parancsba kerül.

Mit változtat valójában a tükrözés

Az útvonalak tükrözése lazítja azt a szabályt, hogy egy iBGP-beszélő nem hirdetheti újra a másik iBGP-beszélőtől tanult útvonalat. RFC 4456 a kivételt a beszélő és az útvonal forrása közötti kapcsolaton keresztül fejezi ki, és ennek a kapcsolatnak az iránya fontosabb, mint a legtöbb összefoglaló sugallja. Az ügyféltől tanult útvonal tükrözhető más ügyfelek és nem ügyfelek felé, míg a nem ügyféltől tanult útvonal csak ügyfelek felé tükrözhető. Olvassa el kétszer az aszimmetriát, mert megmagyarázza, hogyan rejthet el egy ügyfélkapcsolat hozzáadása egy tervezési hibát: olyan utat nyit, amelyet a topológia soha nem szánt.

A CLUSTER_LIST attribútum rögzíti a tükrözési előzményeket, és a tükrözőnek, amely saját klaszterazonosítóját megtalálja ebben a listában, figyelmen kívül kell hagynia a hirdetményt. Ez a hurokvédelem, és ez az a mechanizmus is, amely törli az útvonalakat, amikor az azonosítókat véletlenül újrahasználják. Az ORIGINATOR_ID rokon szerepet játszik azzal, hogy megnevezi azt az útválasztót, amely először hirdette az útvonalat.

Az újrahasznált klaszterazonosítók azok, amelyektől az útvonalak eltűnnek

Egy kis hálózat rövidítésre csábít: adjon minden útválasztónak a loopbackjével egyenlő klaszterazonosítót, később adjon hozzá még egy tükrözőt, és használjon újra egy meglévő loopbacket, mert kényelmesen kéznél van. Ha ez az azonosító most két független tükrözési szakaszban jelenik meg, a második szakasz saját azonosítóját látja a CLUSTER_LISTben, és eldobja az útvonalat. Semmi nem naplóz hibát, mert az eldobás a helyes válasz egy hurokra.

Egy klasztert kiszolgáló redundáns tükrözők a jogszerű kivétel: szándékosan osztoznak egy azonosítón, hogy bármelyikük kiszolgálhassa ugyanazokat az ügyfeleket. Az azonosítónak a tükrözési tervezéshez kell illeszkednie, nem pedig a házak neveit megkülönböztetnie.

Rajzolja fel a szándékolt gráfot, mielőtt bármilyen konfigurációhoz hozzányúlna: ki származtatja a prefixet, melyik ügyfélkapcsolat engedélyezi az első tükrözést, melyik tükröző viszi a következő szakaszba, és hol ül az utolsó ügyfél. A gráf minden ugrása olyan hely, ahol egy újrahasznált azonosító, egy hiányzó ügyfélkapcsolat vagy egy házirend-szűrő megállíthatja az útvonalat. Ha a gráf fel van rajzolva, a hiányzó útvonalnak helye van rejtély helyett.

Álljon ellen annak, hogy minden szomszéd ügyfél legyen

A hiányzó útvonal gyors javítása az, hogy minden szomszédot minden tükröző ügyfélévé teszünk. A terjedés visszatér, és a tervezés semmit nem mond többé: megsokszorozza azokat az útvonalakat, amelyeket az egyes beszélők hordoznak, miközben elrejti, melyik kapcsolatnak kellett volna elvégeznie a munkát.

Egy kis hálózatnak általában két forma egyikére van szüksége. A teljes iBGP-háló hat munkamenet négy útválasztóhoz, mindenféle tükrözés nélkül, és a fennmaradó peremeket kiszolgáló kijelölt tükrözőpár a másik. Mindkettőről könnyebb gondolkodni, mint egy részleges hálóról, amelyben minden útválasztó egy kicsit tükröz. A formát a méret és a hibaviselkedés alapján válassza, ne a kábelezési ábra alapján.

Ellenőrizze a címcsaládot, mielőtt a tükrözést hibáztatja

Egy TCP-munkamenet a 179-es porton bizonyítja, hogy a két beszélő tud egymással beszélni, és semmit nem mond arról, hogy a VPN címcsaládja váltott-e egyetlen útvonalat. Állapítsa meg a munkamenet állapotát, aztán a családot, aztán az egyedi prefixet.

vtysh -c "show bgp summary"
vtysh -c "show bgp l2vpn evpn summary"
vtysh -c "show bgp l2vpn evpn"

Ez a három kimenet elválasztja a szomszédsági problémát a csereproblémától és a hiányzó prefix problémájától. Ha a család egyáltalán nem mutat prefixeket, vizsgálja meg a szomszéd aktiválási állapotát és exportszabályát, mielőtt a tükrözésre nézne. Ha a prefixek az egyik peremen megjelennek, a másikon nem, hasonlítsa össze a klaszterlistát és az originátort a fogadó oldalon, majd járja végig az előző szakasz gráfját.

Tartsa a következő ugrás elérhetőségét és a továbbítási állapotot ezen ellenőrzésen kívül. Egy tükrözött útvonal elérhetetlen következő ugrással jelen van és használhatatlan, ami tükrözési hibának látszik, amíg meg nem nézi a következő ugrás oszlopát. Oldja fel a következő ugrást, erősítse meg a továbbítási bejegyzést, és csak ezután döntse el, hogy az elosztási gráfnak szüksége van-e még egy tükrözőre.