Szükség van MPLS-re a magban a VPNv4-hez? Nem feltétlenül

A BGP VPNv4 útvonal-terjesztési kontextust tárgyal, nem továbbítási útvonalat. Válassza külön az importot, a következő ugrás feloldását és az általa futtatható beágyazást.

A VPNv4 címcsalád bekapcsolása két router között csak egy útvonal-terjesztési kontextust hoz létre, semmi többet. Nem telepít továbbítási útvonalat, és nem mondja meg, melyik beágyazás viszi majd az ügyfélcsomagot a távoli végpontra. Ha ezt a két tényt szétválasztjuk, a «szükség van-e ehhez MPLS-re a magban» kérdés szűkebb és megválaszolható kérdéssé válik a platform által támogatott adatsíkról.

Mit tárgyal valójában a címcsalád

A többprotokollos BGP az AFI 1 és SAFI 128 alatt szállítja a VPNv4 hálózati réteg elérhetőségi információit, és minden bejegyzés egy útvonal-megkülönböztetőt párosít előtaggal és címkével. A munkamenet azt tárgyalja, hogy mindkét fél képes ezt az információt kódolni és dekódolni. Amit nem tárgyal, az az adatsík. Minden, ami e bekezdés után következik, a továbbításról szól, és ebből semmit nem dönt el a munkamenet felállása.

Tehát egy sikeres munkamenet a vezérsík képességének bizonyítéka, nem a továbbításé. Egy router ezer VPNv4 bejegyzést is tarthat, és mégis eldobhat minden ügyfélcsomagot, és éppen ezért keveredik össze a két hibaosztály eleve.

Figyelje meg a címkét az NLRI-ben. Ez szolgáltatáscímke, amely egy VRF-en belüli előtaghoz kötődik, és továbbítási szerepe van, amikor a csomag eléri a kimenő végpontot. Hogy bármely átmeneti eszköz olvassa-e, külön tervezési döntés.

Fogadás, import és továbbítás három lépés

Az útvonal fogadását, használatának engedélyezését és a vele való továbbítás képességét az eszköz különböző részei végzik. A BGP tárolja, amit hall; az importszabályzat és az útvonalcél egyezése dönti el, melyik VRF veheti figyelembe; majd a továbbítási síknak fel kell oldania a hirdetett következő ugrást valamivé, amit valóban ki tud tolni egy vezetékre.

Step in the chainWhat has to be trueHow it fails quietly
NLRI exchangeBoth speakers negotiate the VPNv4 capabilitySession stays up while the family is never activated
Import eligibilityA route target on the received route matches the VRF import policyThe route exists in the table but never enters the VRF
Next-hop resolutionThe advertised next hop resolves to a usable tunnel or label pathBest path is selected, then marked unreachable or unusable
EncapsulationThe egress endpoint can decapsulate what the ingress producedPackets arrive and are discarded for a format mismatch

Ebben a középső lépésben él a legtöbb meglepő hiba. Egy útvonal jelen lehet a BGP-táblában, érvényes és akár a legjobb, miközben a VRF útvonaltáblája üres marad, mert egyetlen útvonalcél sem egyezett az importlistával. Semmi sem naplóz protokollhibát, mert nem történt protokollhiba.

Az utolsó lépés az, ahol a platform támogatása megmutatkozik. Az alsó rétegben elérhető következő ugrás nem oldódik fel automatikusan VPN-szolgáltatás-továbbításként, és az eszköz megkövetelhet egy adott alagúttípust, egy adott címkeműveletet vagy mindkettőt. A feloldási állapot olvasása többet mond, mint az útvonalak számának olvasása.

Egy IP-mag olyan vermet szállíthat, amelyet soha nem kapcsol

A megtartásra érdemes különbség a «a mag nem futtat MPLS-t» és a «a szolgáltatásban sehol nincs címke» között van. Ezek külön állítások, és csak az első szól az átmeneti eszközökről. Az RFC 4023 meghatározza az MPLS IP- vagy GRE-alagutakon való szállítását, és ez az a mechanizmus, amely a második állítást lehetővé teszi egy tisztán IP-alapú magon.

customer packet + service label
  encapsulated in GRE, addressed to the egress tunnel endpoint
  forwarded by ordinary IP routers on the outer header
  decapsulated at the endpoint, label still meaningful

Az átmeneti routerek a külső IP-cél szerint továbbítanak, és nem igénylik sem az ügyfél-előtagokat, sem a natív címkekapcsolást. A távoli végén a külső alagút eltávolítódik, és a szolgáltatáscímke folytatja a munkáját. A mag átlátszatlan hasznos terhet mozgatott, és pontosan erre jó egy IP-hálózat.

Amit ez a tervezés nem ad meg, az az egyetemes garancia. Ez nem bizonyíték arra, hogy minden router minden VPNv4 következő ugrást felold bármely GRE-interfészen, és nem ok egy működő natív MPLS-konfiguráció törlésére. Ez egy ellenpélda az egyetemes állításra, és a gyakorlati kérdés a platformnál marad. Ezt a kérdést platformkorlátként rögzítse, ne protokollszabályként.

Járja végig a láncot a dobozon, amíg el nem törik

Kezdje a fogadott útvonalnál, és álljon meg az első lépésnél, amely meghiúsul, mert a későbbi lépések nem diagnosztizálhatók, amíg egy korábbi törött. Négy parancs lefedi ennek nagy részét egy tipikus megvalósításban.

show bgp vpnv4 unicast all summary
show bgp vrf CUSTOMER_A ip route 198.51.100.0/24
show ip route vrf CUSTOMER_A 198.51.100.0
show mpls forwarding-table vrf CUSTOMER_A

Sorozatként olvassa őket, ne négy független ellenőrzésként. Az első megerősíti, hogy a címcsalád aktív, és a partner útvonalakat cserél; a második megmutatja, hogy az előtag használható következő ugrással érkezett-e; a harmadik bizonyítja az importjogosultságot; a negyedik megmutatja, hogy a továbbítási sík címkét vagy alagutat kötött-e hozzá.

Ezután tesztelje a munkaterhelés útvonalát mindkét irányban, olyan MTU-val, amely túléli a beágyazást. A GRE fejlécbájtokat ad hozzá, és egy kis próbákon átmenő útvonal csak az egyik irányban hibázhat teljes méretű csomagokon, ami alkalmazáshibának tűnik, nem szállításinak.

Két üzemeltetési megjegyzés zárja a kört. A GRE beágyazás, nem bizalmasság, ezért egy nem megbízható átmeneti hálózatnak támogatott biztonsági megoldásra van szüksége fölötte, nem feltevésre. És a tervezési áttekintés előtt rögzítse, melyik beágyazást támogatja valójában a platform, mert ez az egyetlen válasz dönti el, hogy a csak IP-alapú mag érvényes választás-e, vagy olyan terv, amely nem tud továbbítani.

Kapcsolódó cikkek