L3VPN átadás: privát útvonalak, alapértelmezett útvonal vagy teljes tábla?

Az áramkör üzemel, a VRF konfigurálva van, és a szolgáltató feltesz egy rövid kérdést, amely eldönti a tervezés többi részét: mit kell az ügyféloldali szélnek kapnia? Három válasz gyakori, és egyik sem abból következik, hogy létezik címkelaköteg. Ezek szolgáltatási döntések arról, hol hagyja el a forgalom a fióktelepet.

Az átadást sorrendben végigjárni a legolcsóbb módja annak, hogy ez helyesen sikerüljön. Abból indul ki, mi történik a semmivel sem egyező forgalommal, aztán leírja a privát előtagokat és hibaesetbeli viselkedésüket, és csak ezután beszél arról, mekkora hírtömeget hajlandó vinni.

Kezdje azzal a forgalommal, amelyre senki nem számított

Tegyen fel egy kérdést, mielőtt bármilyen előtaglista megjelenik: amikor egy csomag egyetlen privát útvonalhoz sem illeszkedik, hová kell mennie? A saját internetes áramkörrel rendelkező fióktelep általában helyi alapértelmezett útvonalat tart, így a szokásos webforgalom a helyi tűzfalon keresztül lép ki, és soha nem érinti a szolgáltatót. Ebben a tervben a VPN csak a távoli privát helyeket szállítja, és a választást a pontosabb előtagok végzik.

A központi kilépést használni hivatott fióktelep az ellenkező eset. Ott az alapértelmezett útvonal a szolgáltatásba mutat, és a szolgáltató vagy a központi hely felel a továbbításért, a visszaútvonalért és minden fordításért. Ha azt mondjuk, hogy „alapértelmezés a VPN felé”, ilyen felelős nélkül olyan fióktelep lesz, amely neveket old fel, de semmit nem ér el.

A két terv abban különbözik, hogyan néz ki egy útvonalhiba, és ezért drága a találgatás. Helyi alapértelmezett útvonal mellett egy elveszett privát útvonal az internetre küldi azt a forgalmat, ahol a tűzfal eldobja, vagy ami rosszabb, valami olyan válaszol, amire nem számított. Központi alapértelmezett útvonal mellett ugyanez a veszteség teljesen megszünteti az internetelérést, és a jegy így érkezik: „az egész fióktelep áll”. Egyik hiba sem rossz önmagában, de csak az egyik felel meg az eladott szolgáltatásnak, és egy BGP-konfiguráció önmagában nem mondja meg, melyiket építette.

Írja le a privát előtagokat a hibaesetükkel együtt

Sorolja fel az előtagokat, amelyeket a fióktelepnek el kell érnie, és jegyezze fel, melyek összevontak. Az egy bittel túl széles aggregátum ismeretlen célokat húz a VPN-be, ami csak akkor rendben van, ha a túlsó fél valóban birtokolja és továbbítja őket.

Ezután írja le a kívánt viselkedést, amikor a privát szolgáltatás meghibásodik. A megtartott eldobási útvonal távol tartja a forgalmat egy nem engedélyezett úttól, és tiszta, várt kiesést eredményez. A lebegő alapértelmezett útvonal fenntarthatja az elérhetőséget egy tartalék útra váltva, de csak akkor, ha a tartalék út jogosult ennek a forgalomnak a szállítására.

Tartsa külön az elérhetőséget és a megengedett visszaesést két követelményként az átadási dokumentumban. Az ezeket összemosó csapatok végül arról vitatkoznak, hogy a fióktelepnek meg kellett volna-e hibásodnia, ahelyett hogy ellenőriznék, megvalósult-e a megállapodott irányelv.

Ellenőrizze, mit telepített valóban a CE

A konfigurációs szándék és a továbbítási állapot elég gyakran eltér ahhoz, hogy az ellenőrzés az átadáshoz tartozzon, ne az incidens áttekintéséhez. Egy IOS-XE ügyféloldali szélen az alábbi három parancs három különböző kérdésre válaszol: mit ajánlottak fel, mit fogadtak el, és mit használnak valójában.

show ip bgp vpnv4 vrf BRANCH neighbors 192.0.2.1 received-routes
show ip bgp vpnv4 vrf BRANCH
show ip route vrf BRANCH 0.0.0.0

Futtassa mindhármat az átadás napján, ne egy hónappal később, amíg valaki még emlékszik a megállapodásra. Az első kimenet a soft-reconfiguration inbound beállítástól vagy egy tárolt útvonalfrissítéstől függ; egyik nélkül a CE nem tudja megmutatni, mit utasított el. A második az irányelv utáni elfogadott és legjobb útvonalakat mutatja. A harmadik megmondja, hová megy valójában az alapértelmezett útvonal, és ez a teljes átadás leghasznosabb sora.

Futtassa ugyanezeket az ellenőrzéseket egy második CE-n, ha a hely két kapcsolattal rendelkezik. A két szél közötti aszimmetrikus elfogadás gyakori oka annak, hogy „az egyik szerverről működik, a másikról nem”, és láthatatlan egy szimmetrikusnak tűnő konfigurációs különbségben.

Minősítse a nagyobb hírtömeget ahelyett hogy feltételezné

Néha az ügyfélnek valóban szüksége van internetes útvonalinformációra a VRF-en belül, irányelvalapú útválasztáshoz vagy olyan központi kilépéshez, amely előtag szerint irányít. Ez deklarálandó, körülhatárolt és árazandó követelmény, nem rejtett alapértelmezés. Memóriával jár a RIB és a FIB számára, processzorral a frissítésekhez, szűrőkarbantartással és a keletkező tábla felelősével.

A kapacitásérvek mindkét irányban hibásak. A teljes tábla nincs megtiltva egy VRF-en belül, és nem is ingyenes. Ugyanígy a mai költség nem vezethető le egy régi útvonalszámból, és a kisebb címkeosztás nem szünteti meg az útvonalak tárolásának költségét.

A BGP/MPLS IP VPN specifikáció több internetelérési elrendezést tárgyal a VPN-szolgáltatás mellett, és nem nyilvánítja kötelezővé a teljes táblát vagy az alapértelmezést minden ügyfél számára, és ez az a szakasz, amelyre érdemes hivatkozni, amikor felmerül a „szokásos gyakorlatra” vonatkozó állítás: RFC 4364.

Zárja le az átadást a hirdetett halmaz, a fogadott halmaz és a kiválasztott halmaz rögzítésével a megállapodott kilépési irányelv mellett, valamint egy privát cél, egy szándékolt nyilvános cél és egy útvonalvesztési eset tesztelésével. Az a három teszt aláírt jegyzőkönyve több vitát rendez, mint bármilyen kijelentés arról, mit tesz a legtöbb hálózat.