MPLS-VPN-ek a gyakorlatban

Győri Gábor <gyorig@lnx.hu>

LIAS-NETWORX Hálózatintegrációs Kft.

1. Bevezetés

A Multiprotocol Label Switching (MPLS) kialakításában az IP hordozhatóságát, egyszerűségét, kívánták összekovácsolni az ATM skálázhatóságával és QoS (Quality of Service) tulajdonságaival. Mindeközben cél volt az egyszerű konfiguráció, és a mindenkoron optimális adatátvitel. A technológia ekkor még csak a nagy forgalmú Internet gerinc üzemeltetői számára jelentett megoldást. A szélesebb körben való alkalmazhatóságot az MPLS VPN megoldás kialakítása hozta meg. Ennek segítségével változó Layer2 fölött (Ethernet, PPP, ATM, stb.), hozhatunk létre egységesen kezelhető virtuális privát hálózatokat. Ezek a LAN technológiákban megszokott VLAN-ok flexibilitásán és a kiterjeszthetőségen túl a közös erőforrások elérését, valamint egységesen kezelt QoS-t is tud (majd) biztosítani. A fenti tulajdonságok alkalmassá teszik az MPLS-t és a ráépülő MPLS VPN-t flexibilis multiservice hálózatok kialakítására, melynek előnyeit már kisebb hálózatokon is érzékelhetjük.

1. Az MPLS technológia

A mai IP hálózatokban is igen sok féle lehetőség van arra, hogy nagy multiservice hálózatokat építsünk, hiszen vannak gyors konvergenciájú routing protokolok, és számtalan QoS lehetőség (queuing, traffic-shaping, packet interleaving technikák. Ezek alkalmazása azonban, igen nagy körültekintést igényel, és nagy processzorterheléssel jár együtt, hiszen az adatút során minden egyes router minden egyes csomagra:

1. Fogadja a bejövő csomagot, és esetleg előfeldolgozást (pl. IP precedencia átállítás, policy routing), végez.

2. Meghozza a routing döntést

3. Elvégzi a klasszifikációt, azaz a megfelelő forgalmi osztályokba sorolja a beérkező csomagot. Ennek során a cél címen kívül a forrás címet, az IP-be ágyazott protokoll típusát (TCP/UDP/RTP), annak protokoll portjait vizsgálja. Ez egy elég komplex feladat, hardware-rel nem támogatható.

4. Elvégzi a kimenő interface-en a megfelelő sorbaállítást, esetleg interleaving-et, a kívánt QoS megvalósítása érdekében.

Egy nagyobb hálózatnál már könnyen kerülhetünk abba a helyzetbe, hogy nem tudunk a központba akkora router vásárolni (anyagi okok miatt, vagy mert nem is létezik olyan), ami ezt a terhelést kibírja.

Ezen probléma kiküszöbölése céljából, azaz a skálázhatóság megteremtése végett hozta létre a Cisco a tag switching-et, amely mára MPLS néven szabványos protokollá vált. Az MPLS kialakítás céljai:

• Egy nagy kiterjedésű, sok kapcsolattal rendelkező IP gerinchálózatban ne kelljen nagy routing táblák alapján továbbítani a csomagokat, mivel ez nagy CPU igénybevétellel jár.

• Gyors rerouting hiba esetén

• Egyszerű konfiguráció

• Minél többfajta hordozó hálózaton működjön

• VPN lehetőségek

A kialakítás lényege az, hogy a hálózatunkat alkotó, immáron label switch routernek (LSR-nek) nevezett eszközöket két csoportba soroljuk:

• a hálózat szélén elhelyezkedő edge LSR-ek végzik a klasszifikációt,

• a hálózat belsejében lévő core LSR-ek pedig már csak a csomagok továbbítását végzik

Ahhoz, hogy az core LSR tudja, hogy a csomag milyen QoS osztályba tartozik, és hova kell továbbítani, az edge LSR címkét tesz rá. A címke egy fix hosszú szám, amelyet a csomagban az IP-t hordozó közeg header-e után, vagy (ATM esetén) abban helyezünk el. A core LSR már kizárólag ezen címke alapján hozza meg a csomagtovábbítási döntését. Az LSP-t a teljes útján egy címke írja le, ami így jellemzi is azt. A címkék kiosztásáért, az egyediség biztosításáért a Label Distribution Protocol (LDP) a felelős.

Jól megfigyelhető az ATM-mel való hasonlóság:

• Az MPLS is virtuális csatornát épít ki a csomag továbbítására, amit Label Switch Path-nak (LSP-nek) nevezünk, az ábrán zöld görbe vonallal jelöltünk. Ezen LSP-k a label switch routerek forwarding tábláinak bejegyzéseiből állnak össze. Fontos látni, hogy a label switch path az egyik (ingress) edge LSR natív IP csomagokat fogadó interface-étől a másik (egress) edge LSR natív IP csomagokat fogadó interface-éig tart.

• A csomag továbbítás az MPLS-nél is a felépített csomagtovábbítási tábla (label switch table) alapján történik, ahogy az ATM esetén is. A tábla csak az input és output interface-t és címkét tartalmazza (az ATM-mel ellentétben azonban a címkének itt nem csak lokális jelentősége van).

A fenti ábrán háromfajta eszközt látunk:

• router alapú edge LSR-t

• router alapú core LSR-t

• ATM switch alapú core LSR-t. Az utóbbiban a kapcsolást a tag switch controller végzi (az ábrán a switch tetején piros doboz jelöli), amely az általános vezérlőmodulon, vagy külön egységben kap helyet.

Igen lényeges, hogy mindhárom eszközben a label switching tábla alapján történik a csomag továbbítása, így azon keresztül halad a label switch path.

Az MPLS ATM hálózat felett a label-t a cella VPI és VCI azonosítójába írja bele, más hordozó protokolloknál a hordozó közeg header-e és az IP header közé kerül a label.

1. A VPN kialakítás

A virtuális privát hálózat egy olyan, logikailag egy egységet alkotó, egységesen menedzselt hálózat, mely telephelyeinek összekötését egy általános célú csomagorientált átviteli hálózaton valósítja meg. Ez utóbbi lehet ATM vagy Frame Relay, ahol PVC-k segítségével alakítjuk ki, illetve lehet IP, ahol GRE tunneleket használhatunk. Ezeket egységesen tunnel-ként kezeljük a továbbiakban. Sokszor a definícióba beleértik a tunnelek feletti titkosítást is, ezzel azonban a továbbiakban nem foglalkozunk.

Az előbbiek közös tulajdonsága, hogy pont-pont alapúak (kivéve a pont-multipont GRE tunnelt, ahol viszont NHRP-zni kell), egy fix topológiát kell kialakítanunk. Így a leggondosabb tervezés mellett is előfordulhat, hogy egy fizikai linket kétszer jár meg az adatcsomag, míg feladójától céljáig eljut.

1. Az MPLS VPN

Az MPLS VPN lényege, hogy úgy alakítunk ki VPN-eket, ahogy Ethernet VLAN-okat: csak a VPN tagokat jelöljük ki, a köztük lévő kapcsolatokat nem.

Ezt is a VLAN-oknál megszokott módon tesszük meg: az edge LSR-ek interface-eit jelöljük ki az egyes VPN-ek tagjaivá. A core LSR-ek a VPN kialakításról nem is tudnak, csak az első label alapján végzik a kapcsolást. A VLAN kialakításhoz hasonlóan egy router több VPN-nek is tagja lesz. Hogyan lehet ezt megoldani, és egyáltalán, mi lesz a routing táblában? Hogy lesz az, hogy ezek a VPN-ek ne lássák egymást, ahogy a bevezetésben ígértük?

A megoldás ismét a VLAN-os megoldásnak megfelelő: egy routeren belül több virtuális routert hozunk létre, a virtuális routereknek külön routing táblájuk van, amit VRF-nek nevezünk. Egy VRF csak az adott VPN-en belüli routing tábla bejegyzéseket tartalmazza (alapértelmezésben). Az edge routerekben az interface-eket egyenként rendelhetjük a kívánt VRF-hez, ahogy VLAN-oknál is tesszük a switch-eken. A csomagokba egy második label kerül, ami a VPN azonosító.

Az alábbi ábra egy két core LSR-ből és három edge LSR-ből álló MPLS hálózat fizikai képét mutatja, amely egy két telephelyes és egy három telephelyes VPN-t kapcsol össze.

Az itt látható VPN-eken belül tetszőleges, akár átfedő címtartományok is lehetnek. Ahhoz hogy ez működni tudjon, és a két VPN azonos címét meg lehessen egymástól különböztetni, bevezették a route distinguisher-t, amely a VPN-ek egyedi azonosítására szolgáló egy 64 bites szám. Ennek, és az eredeti 32 bites IPv4 címnek az egymás után fűzésével alakul ki a VPNIPv4 címzés, aminek segítségével az MPLS VPN backbone már egyértelműen azonosítja a hálózatokat. Az MPLS VPN hálózat tagjai között multiprotokoll BGP viszi át a különböző VRF-ek információit, egymással párhuzamosan. Az MPLS backbone-on belüli routing-hoz tetszőleges belső routing protokoll felhasználható. A későbbi fejlesztésekhez (Routing with Resource Reservation) való illeszkedés végett a Cisco a link-state protokollokat (OSPF, IS-IS) ajánlja.

Az alábbi ábra mutatja a hálózat logikai felépítését, a VPN-ek szemszögéből.

A VPN tagjai számára tehát úgy tűnik, mintha az összes, esetleg különböző földrészeken lévő telephely kis routere egyetlen routerre csatlakozna, és egyik telephelytől a másik két IP hop-ra lenne. Ez úgy lehetséges, hogy az egész MPLS hálózat egy központi virtuális routerként látszik a telephelyek számára. A csomagok az egyik VPN edge router VPN tag interface-étől a másik VPN edge router VPN tag interface-éig IP routing nélkül, a label switch path-on jutnak el. A VPN tagok számára ez úgy látszik, mintha a csomag egy routeren belül mozgott volna.

1. Közös erőforrások kezelése MPLS VPN-nel

Az MPLS VPN-ek egy kedvező tulajdonsága, hogy a szabályozott módon lehetséges a VPN-eket reprezentáló VRF-ek (virtuális routing táblák) közötti routing információ csere. Ennek segítségével megoldható az, hogy egy vagy több közös erőforrást több VPN-ből is elérhessenek, ugyanakkor a VPN-ek egymást ne láthassák. Ezt úgy oldjuk meg, hogy a központi erőforrás útját annak VRF-jéből importáljuk a megfelelő VRF-be, és viszont. Így a közös erőforrás a megfelelő VPN részévé, így abból elérhetővé válik. Az alábbi ábra egy ilyen kialakításra mutat példát: egy nagyobb vállalat esetében a bal oldali szervert csak a VPN_A-ból, a középső csak a VPN_B-ből, míg a jobb oldali mindkettőből elérhető. VPN_A és VPN_B továbbra sem érik egymást. Az összes szerverben egy interface van, és azon csak egyetlen cím.

1. Az MPLS VPN felhasználási területei

Privát cég, szervezet

• Adatbiztonsági igények

• Különböző részlegek forgalmának elkülönítése

• Különböző forgalmi típusok kezelése (belső, Internet, VoIP)

• Cégek összeolvadása

Szolgáltató

• VPN szolgáltatás biztosítása IP alapon

• VPN szolgáltatás egyszerűsítése

• Plusz funkcionalitás

1. MPLS-t támogató Cisco eszközök