A GRE (General Routing Encapsulation, RFC 2784) protokoll segítségével nagyon egyszerűen tudunk két vagy több távoli forgalomirányító között alagutat létrehozni.
Tegyük fel, hogy cégünk két telephellyel rendelkezik, és ezek között szeretnénk olyan kapcsolatot létrehozni, amelyet az internet szolgáltatónk nem támogat. Például mindkét telephely hálózatban konfiguráltuk az OSPF protokollt, de értelemszerűen a határ forgalomirányítóink nem képesek szomszédsági kapcsolatot kiépíteni (hiszen közöttük számos, az ISP tulajdonában lévő más forgalomirányító található), így a két hálózat nem fog egyetlen OSPF irányítási területté válni. Ezt a problémát könnyedén megoldhatjuk a GRE alagúttal. Vizsgáljuk meg ezt közelebbről.
Valójában mi is egy alagút? Egy olyan virtuális pont-pont kapcsolat, mely fizikailag ugyan nem létezik, de (szoftveres, virtuális) interfészeket összekapcsolva, a forgalomirányítás számára egy létező útvonalat szolgáltat, vagyis a forgalomirányító képes olyan forgalomirányítási döntést hozni, hogy a csomagok az alagút által meghatározott útvonalon haladjanak. Természetesen hogy ezek a csomagok ténylegesen is célba jussanak, valahogyan a fizikai hálózaton is át kell haladjanak. Nézzük meg az alábbi ábrákat!
Az első a fenti példánknak megfelelően azt az elképzelt helyzetet ábrázolja, melyben a két telephelyet egyetlen pont-pont kapcsolattal kötjük össze virtuális interfészek segítségével. Ezeket a virtuális interfészek létrehozás szempontjából hasonlítanak a visszacsatoló (loopback) interfészekhez, vagyis nem fizikailag csatoljuk a forgalomirányítóhoz, hanem szoftveresen hozzuk létre az int paranccsal. A földgömb jelzi, hogy ez a virtuális kapcsolat tetszőlegesen átívelhet a földgolyón (maradjunk most a planétánkon). A második ábra már jelzi azt, hogy ténylegesen egy ISP-k (itt most egyetlen ISP) által meghatározott fizikai hálózathoz csatlakozik a két hálózat, melyen keresztül valahogyan át kell vezetni az alagútba küldött (tehát a Tunnel interfészek által meghatározott hálózatba küldött) csomagokat. (Ezt a külső hálózatot nevezzük közvetítő hálózatnak.) A GRE technika ezt úgy valósítja meg, hogy olyan új IP csomagba ágyazza be az alagútba küldött csomagot, mely már olyan cél- (és forrás) IP címekkel rendelkezik, mely a külső hálózatban irányíthatók és elfogadhatók.
A GRE (és más hasonló funkciójú) alagutak segítségével tehát olyan protokollok adatait tudjuk szállítani két forgalomirányító között, melyeket a közvetítő hálózat nem támogat. Ennek több oka lehet:
- A közvetítő hálózat nem támogatja például az IPv6-ot, míg a cég belső hálózata azt használja.
- A cég belső hálózatában IPv4-es privát címzést használunk, melyet a közvetítő hálózatba nem engedhetünk ki. (Ezt ugye a NAT-olással is meg lehetne oldani.)
- A közvetítő hálózat nem támogatja a forgalom típusát (például a szórásos vagy csoportcímek továbbítását).
Példánkban a cég belső hálózatából küldött forgalom protokollját passanger (utas) protokollnak, míg a közvetítő hálózatét transport (szállító) protokollnak nevezzük. A fentiek szerint a passanger és a transport protokollok nem kompatibilisek egymással. Ezért segítségül hívunk egy carrier (hordozó) protokollt, mely már kompatibilis a transport protokollal. A passanger protokollt a carrier protokollba, majd azt a transport protokollba ágyazzuk be. Egy ilyen carrier protokoll a GRE (General Routing Encapsulation). Ennek az egymásba ágyazásnak a folyamatát mutatja a következő ábra:
Vegyük észre, hogy az eddig egyetlen beágyazást (a szállítási rétegtő kapott PDU-t a belső hálózatban az utasprotokoll IPv4-es csomagba ágyazza be) most még 2 beágyazás egészíti ki. Egyrészt a hordozó protokoll (GRE) ad hozzá 4 byte fejlécet, másrészt a külső hálózat szállító protokollja ad hozzá ismét egy 20 byte-os IPv4-es fejlécet. Vagyis az eredeti MTU értéke már nem érvényes, hiszen az Ethernet keret 1500 byte-os MTU-ja helyett most még 24 byte megy el a fejlécekre, így az eredeti 1500-as MTU-t 1500-24=1476 byte-ra kell csökkenteni. (Az ehhez szükséges parancsot szerencsére a Cisco forgalomirányítók automatikusan elhelyezik a futási konfigurációban a Tunnel interfészhez rendelve.)
A GRE protokoll segítségével az IPv4-es és IPv6-os protokollokat is tudjuk hordozni. Lehetőség van IPv4-es hálózaton keresztül IPv4-es vagy IPv6-os protokollt szállítani, és fordítva, IPv6-os hálózaton keresztül IPv4-est vagy IPv6-ost. Ahogyan már a bevezetőben említettük, ha a két távoli hálózat között szükségünk van a csoportos üzenetek szállítására (például dinamikus forgalomirányító protokoll számára), akkor erre is nagyszerűen használható a GRE.
Valósítsuk meg most GNS3-ban a fenti hálózatunkat. (Azért nem Packet Tracer-ben dolgozunk, meg a Packet Tracer nem támogatja teljesen a GRE protokollt, így nem lehetne minden részletet tárgyalni.)
Induljunk ki az alábbi topológiából: (A telephelyek hálózatát most visszacsatoló interfésszel szimuláljuk.)
R1 és R2 a két telephelyi hálózatunk határ forgalomirányítói, és a közöttük lévő forgalmát kellene a GRE alagúton átvezetni. Ehhez létrehozunk egy olyan alagutat, melyet a 192.168.3.0/30 hálózat reprezentál. A forgalom fizikailag ugyan az ISP forgalomirányító felé fog haladni, de a határ forgalomirányítók az alagút miatt mégis úgy látják, mintha a 172.16.1.1./24 és a 172.16.2.1/24 hálózatokat a 192.168.3.0/30 alagút hálózat kötné össze.
Vegyük észre, hogy a GRE alagút használatakor gyakorlatilag 2 hálózatot konfigurálunk. Az egyik a belső, melyben az alagúton keresztül is halad a forgalom. Ezen a belső hálózaton a szokásos módon vagy statikus, vagy valamilyen dinamikus forgalomirányítás gondoskodik, hogy a csomagok a forrástól eljussanak a célig. Ezt konfigurálást úgy kell elvégeznünk, mintha a külső hálózat ott sem lenne. Az így az alagútba irányított csomagok természetesen önmagukban nem tudnak áthaladni ténylegesen az alagúton, hiszen az fizikailag nem létezik! Ezért lesznek ezek a csomagok először a GRE protokoll által becsomagolva (hordozó protokoll), majd egy újabb IP csomagba becsomagolva (transzport protokoll). (Azt, hogy ez IPv4 vagy IPv6 legyen, az alagút módjában adjuk meg.) A csomagok forráscíme az alagút konfigurációjában megadott forráscím lesz, míg a célcíme az alagút célja. (Vegyük észre, nem az eredeti forrás- és célcímek lesznek felülírva, hiszen azok megmaradtak a GRE által becsomagolt eredeti IP csomagban!) Ezek a címek viszont már a külső hálózatban értelmezhetők, így az ott konfigurált forgalomirányításnak megfelelően (ami most alapértelmezett átjáróval történik) lesznek továbbítva. Amikor megérkeznek ezek a csomagok a célba, ott kicsomagolják belőlük a GRE csomagot, abból a belső IP csomagot, és így már megint a belső hálózat forgalomirányításáé a feladat, hogy célba juttassa. (És itt megtörténhet, hogy a belső csomag cél IP címe az alagút másik (kiindulási) oldalán van, tehát a csomagot az előzőeknek megfelelően visszaküldik az alagút előző végére. Így működik a GRE ébrentartási üzenete, de erről majd később.)
Nézzük a hálózat konfigurálását! A forgalomirányítók interfészeinek konfigurálása a megszokott módon történhet. R1 és R2 alapértelmezett átjárója az ISP felé vezet.
R1(config)#int lo0
R1(config-if)#ip add 172.16.1.1 255.255.255.0
R1(config-if)#int fa0/0
R1(config-if)#ip add 201.100.10.1 255.255.255.252
R1(config-if)#no sh
R1(config)#ip route 0.0.0.0 0.0.0.0 201.100.10.2
R2(config)#int lo0
R2(config-if)#ip add 172.16.2.1 255.255.255.0
R2(config-if)#int fa0/0
R2(config-if)#ip add 201.100.20.1 255.255.255.252
R2(config-if)#no sh
R2(config)#ip route 0.0.0.0 0.0.0.0 201.100.20.2
ISP(config)#int fa0/0
ISP(config-if)#ip add 201.100.10.2 255.255.255.252
ISP(config-if)#no sh
ISP(config-if)#int fa0/1
ISP(config-if)#ip add 201.100.20.2 255.255.255.252
ISP(config-if)#no sh
Magának az alagútnak a létrehozása végtelen egyszerű: Mindkét forgalomirányítón létrehozzuk a Tunnel1 virtuális interfészt, majd megcímezzük azokat egy-egy 3. rétegbeli címmel. Alapértelmezetten a GRE az IPv4-et támogatja. (IPv6-hoz használjuk a tunnel mode gre ipv6 parancsot.) Ezután meg kell adnunk az alagút forrását (ez IP címmel is megadható), majd meg kell adni az alagút célját (értelemszerűen ezt interfésszel nem tudjuk megadni, hiszen R1 nem tudja, hogy R2 melyik interfészének mi az IP címe). Ez a cél IP cím a külső (itt az ISP) hálózaton keresztül elérhető tényleges, létező cím kell legyen! Fontos tisztán látni, hogy az alagút forrása nem azt jelenti, hogy honnan kell az adatokat az alagútba bevezetni, hanem azt a címet jelzi, amely címet forráscímként kell használni a szállító protokoll (tehát a külső hálózat) által előállított IP csomagban. Az alagút célja pedig ugyanilyen értelemben azt a címet jelenti, melyet ebben a külső IP csomagban célcímként kell használni. Az alagút forrás és célcímével ellátott csomag már a külső hálózatban irányítható. A konfigurációs parancsokat itt láthatjuk:
R1(config)#int Tunnel1
R1(config-if)#ip add 192.168.3.1 255.255.255.252
R1(config-if)#tunnel source fa0/0
R1(config-if)#tunnel destination 201.100.20.1
R2(config)#int Tunnel1
R2(config-if)#ip add 192.168.3.2 255.255.255.252
R2(config-if)#tunnel source fa0/0
R2(config-if)#tunnel destination 201.100.10.1
Jelenítsük meg az interfészek listáját. Jól látható benne az alagút interfésze:
R1#ping 192.168.3.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.3.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 56/60/80 ms
A lementett forgalomból látszik, hogyan lesz becsomagolva az eredeti forgalom az újba:
Vizsgáljuk meg a lementett forgalom első keretét. Jól látható, hogy a ping ICMP csomagja először egy olyan IPv4-es csomagba lett beágyazva, mely a 192.168.3.1 és 192.168.3.2 címek között halad, hiszen a ping parancsban a 192.168.3.2-t adtuk meg cél IP címnek, és az ehhez vezető útvonal kimenő interfészének IP címe a 192.168.3.1. Valós helyzetben ez a privát című csomag nem léphetne ki a globális hálózatba. Mivel NAT-ot most nem akarunk használni, beágyazzuk ezt egy GRE csomagba, majd ezt már a szállító (transport) hálózat csomagjába. Itt kap szerepet az alagút forrás és cél címe. Ennek a csomagnak a forrás címe lesz az alagút forrásának az IP címe (201.100.10.1), míg a célja az alagút céljának az IP címe (201.100.20.1). Ezek már globális címek, és az ilyen címmel ellátott csomagot fogja a szállító hálózat (vagyis az ISP hálózata) már az itt konfigurált forgalomirányító protokoll által kijelölt útvonalon eljuttatni a célig. A célban (201.100.20.1) a GRE protokoll kibontja a beágyazott privát IP című csomagot, és a telephelyi hálózatban, az itt konfigurált irányító protokoll által meghatározott útvonalon célba juttatja.A következő ábrán az IP címekkel együtt láthatjuk ezt a beágyazást:
Végiggondolva ezt a logikát, most már pontosabban láthatjuk a korábban már említett helyzetet: Mi van akkor, ha a GRE csomagba ágyazott csomag cél IP címe nem is ennek (a példánkban baloldali, R2-höz tartozó) hálózatba tartozó IP címet tartalmaz, hanem a jobboldali (R1-hez tartozó) hálózatba szólót? Akkor újra beindul a folyamat, és a csomag visszakerül R1-hez. Ilyen furcsán címzett csomagot tartalmaz a GRE ébrenléti (keepalive) üzenete, melyről a későbbiekben még szó lesz. (Természetesen ilyen csomagot mi nem tudunk készíteni mondjuk egy ping paranccsal, hiszen egy a bal oldali hálózatban kiadott bal oldali hálózatba szóló ping parancs nem kerül az alagútban átvitelre.)
Most konfiguráljuk a két forgalomirányító között a megszokott módon például az OSPF protokollt annak érdekében, hogy ne csak a forgalomirányítók, hanem a mögöttük lévő hálózatok is elérjék egymást. Mivel R1-et és R2-t már az alagút köti össze, így a hirdetendő hálózatok közé az alagút hálózatát kell felvenni. Vegyük észre! Ezen a szinten a szállító hálózat (tehát az ISP hálózata) mintha ott sem lenne. Úgy tudjuk R1 és R2 között a forgalomirányítást konfigurálni, mintha a két forgalomirányító közvetlen kapcsolatban lenne a Tunnel1 interfészeken keresztül. Ráadásul a GRE protokoll képes a csoportos címzésű csomagokat is továbbítani, így mind az útvonalfrissítési üzenetek, mind a szomszédsági üzenetek gond nélkül átjutnak az ISP hálózatán.
R1#conf t
R1(config)#router ospf 1
R1(config-router)#network 172.16.1.0 0.0.0.255 area 0
R1(config-router)#network 192.168.3.0 0.0.0.3 area 0
R2#conf t
R2(config)#router ospf 1
R2(config-router)#network 172.16.2.0 0.0.0.255 area 0
R2(config-router)#network 192.168.3.0 0.0.0.3 area 0
Jól mutatja, hogy a GRE alagúton keresztül a csoportos címzésű forgalom is továbbításra kerül az, hogy R1 és R2 között kialakul a teljes szomszédsági viszony, és a távoli hálózatok megjelennek az irányítótáblában:
R1#sh ip route ospf
172.16.0.0/16 is variably subnetted, 2 subnets, 2 masks
O 172.16.2.1/32 [110/11112] via 192.168.3.2, 00:00:28, Tunnel1
A GRE protokoll egyik gyengesége, hogy nem képes jelezni, ha az alagút valamelyik végén az interfész lekapcsolódik. Vagyis ha R1-en lekapcsoljuk a Tunnel1 interfészt (vagy a hozzá tartozó forrás fizikai interfészt), R2-n Tunnel1 állapota még up/up marad, és viszont. (És ugyanígy nem képes jelezni, ha az alagút mögött lévő hálózati infrastruktúrában hiba van.) Ennek viszont az is a következménye, hogy az irányítótáblából nem kerül ki a másik (hibás) hálózat felé vezető útvonal. Ennek szemléltetésére kapcsoljuk le R2-n az fa0/0 interfészt, és nézzük meg R1-en az interfészek állapotát. Azt tapasztaljuk, hogy az alagút interfész felkapcsolva maradt.
R2(config)#int fa0/0
R2(config-if)#sh
R1#sh ip int brief
Interface IP-Address OK? Method Status Protocol
FastEthernet0/0 201.100.10.1 YES NVRAM up up
Loopback0 172.16.1.1 YES NVRAM up up
Tunnel1 192.168.3.1 YES manual up up
Természetesen azon az oldalon, ahol lekapcsoljuk a fizikai interfészt, az alagút interfész is lekapcsolódik. Ha például R1-en lekapcsoljuk az fa0/0-t, akkor itt a Tunnel1 interfész is lekapcsolódik:
R1()#sh ip int brief
Interface IP-Address OK? Method Status Protocol
FastEthernet0/0 201.100.10.1 YES NVRAM administratively down down
Loopback0 172.16.1.1 YES NVRAM up up
Tunnel1 192.168.3.1 YES NVRAM up down
Az alagút működésének monitorzása viszont konfigurálható a keepalive paranccsal (keepalive [másodperc [ismétlés]]). A keepailve 10 3 R1-en kiadva például azt jelenti, hogy 10 másodpercenkét küld keepalive üzenetet R1 R2-nek, és ha 3x egymás után nem kap rá választ, az alagút interfészt lekapcsolja. A keepailve funkció alapértelmezetten le van tiltva a GRE protokoll esetében. (Érdekesség, hogy ha R1-en kiadjuk ezt a parancsot, akkor nem kötelező R2-n is kiadni, ugyanis R1 olyan GRE üzenetet ad fel, melyben egy olyan másik GRE üzenet van becsomagolva, melynek cél IP címe maga R1, így ha visszakapja R2-től, működik az alagút.)
IPv6-IPv4 alagút készítése
Tegyük fel, hogy a cégünk két távoli telephelyén IPv6-os címzést használunk, de az azokat összekötő hálózatban a szolgáltató csak IPv4-es protokollt támogat. Konfiguráljunk a két hálózat között alagutat a GRE protokoll segítségével. A topológiánk nagyon hasonlít az előzőhöz, csupán a címzés más:
Az interfészek konfigurációja a már megszokott módon történik. R1 és R2 között OSPFv3 forgalomirányító protokollal hirdetjük az útvonalakat. Mivel az OSPFv3-nak elegendő, ha az alagút interfészei csak link-local címekkel rendelkeznek, így azokon csupán engedélyezzük az IPv6-ot, hiszen az IPv6 engedélyezésekor az interfész automatikusan legyárt magának egy link-local címet.
R1(config)#int fa0/0
R1(config-if)#ip add 201.100.10.1 255.255.255.252
R1(config-if)#no sh
R1(config-if)#int lo0
R1(config-if)#ipv6 add 2001:AAAA::1/64
R1(config-if)#int tunnel1
R1(config-if)#ipv6 enable
R1(config-if)#tunnel source fa0/0
R1(config-if)#tunnel destination 201.100.10.1
R1(config-if)#exit
R1(config)#ip route 0.0.0.0 0.0.0.0 201.100.10.2
R2(config)#int fa0/0
R2(config-if)#ip add 201.100.20.1 255.255.255.252
R2(config-if)#no sh
R2(config-if)#int lo0
R2(config-if)#ipv6 add 2001:BBBB::1/64
R2(config-if)#int tunnel1
R2(config-if)#ipv6 enable
R2(config-if)#tunnel source fa0/0
R2(config-if)#tunnel destination 201.100.20.1
R2(config-if)#exit
R2(config)#ip route 0.0.0.0 0.0.0.0 201.100.20.2
ISP(config)#int fa0/0
ISP(config-if)#ip add 200.100.10.2 255.255.255.252
ISP(config-if)#no sh
ISP(config-if)#int fa0/1
ISP(config-if)#ip add 200.100.20.2 255.255.255.252
ISP(config-if)#no sh
Az OSPFv3 konfigurációja:
R1(config)#ipv6 unicast-routing
R1(config)#ipv6 router ospf 1
R1(config-rtr)#int tunnel1
R1(config-if)#ipv6 ospf 1 area 0
R1(config-if)#int lo0
R1(config-if)#ipv6 ospf 1 area 0
R2(config)#ipv6 unicast-routing
R2(config)#ipv6 router ospf 1
R2(config-rtr)#int tunnel1
R2(config-if)#ipv6 ospf 1 area 0
R2(config-if)#int lo0
R2(config-if)#ipv6 ospf 1 area 0
Ezek után ha R1-ről megpingetjük az R2 mögötti hálózatot, a lementett csomagokban szépen látszik, hogy az IPv6-os üzenetek IPv4-es csomagokban haladnak a hálózaton keresztül:
Természetesen fordítva is működik a dolog, tehát amikor a belső hálózatunk IPv4-es, és a transzport hálózat IPv6-os, csak ilyenkor ne felejtsük el a GRE alagút módját ipv6-ra állítani (tunnel mode gre ipv6).
IPv4-IPv6-os alagút kiépítése OSPF környezetben
Próbáljuk most az előző példában megvalósított alagutat úgy konfigurálni, hogy az IPv4-es hálózatban ne csak egy fizikai útvonalon haladhassanak becsomagolva az IPv6-os csomagjaink. Ehhez természetesen egy második útvonallal kell kiegészítenünk a külső hálózatot, és választanunk kell egy útvonalválasztó protokollt, amely meghatározza az aktuális útvonalat. Legyen ez a protokoll az OSPF. AZ IPv6-os hálózatban az EIGRP protokollt fogjuk alkalmazni. (Tehát a külső hálózatban OSPF protokoll működik, a telephelyeink között pedig az EIGRP.) A topológiánk így így néz ki:
Az egyes interfészek IPv4-es címei beállításának bemutatásától most eltekintünk, kizárólag az OSPF, az EIGRP és a GRE alagút konfigurációjára összpontosítunk. A topológián furcsállhatjuk, hogy R1-en és R2-n az IPv6-os LAN-okat szimuláló loopback1 interfészek mellett megjelent egy-egy IPv4 című loopback0 interfész is. Magyarázatuk a GRE alagút fenntartásában rejlik. (Ez a megoldás például az, ami a Packet Tracer 7.11-ben sajnos nem működik, noha a konfigurációs lépéseket a program elfogadja.)
R1 szemszögéből (és ugyanígy R2 szemszögéből is) most már 2 útvonal is vezet a GRE alagút forrása és célja között. Az egyik az fa1/0, a másik az fa1/1 interfészen keresztül. Melyiket konfiguráljuk az alagút forrásának? (És ugyanígy R2-n az fa1/0 vagy az fa1/1 interfésze legyen az alagút célja?) Egyik sem lenne jó megoldás. Ha például a forrásnak R1 fa1/0 interfészét választjuk, a célnak pedig R2 fa1/0 interfészét, akkor ha valamelyik oknál fogva ez az útvonal lebomlik (például R4 fa1/0 interfésze kiesik), akkor hiába választ a külső IPv4-es hálózatban az OSPF másik útvonalat (az R3-on keresztül haladót), a GRE alagút akkor is az eredeti (már nem élő) útvonalon próbálja a becsomagolt IPv6-os csomagokat küldeni. A megoldás ezért az, hogy az alagút forrását és célját a tényleges útvonaltól független interfészhez rendeljük, ezek lesznek az előbb említett loopback interfészek. Ezek soha nem kapcsolódnak le (ha az adminisztrátor le nem kapcsolja manuálisan), így az alagút mindig élni fog, és az adatok az OSPF által meghatározott útvonalon fognak haladni.
Nézzük az alagút konfigurációját. (A változatosság kedvéért, most az alagúthoz globális IPv6-os címeket rendelünk, és nem az automatikus link-local címeket használjuk.)
R1(config)#int tunnel1
R1(config-if)#ipv6 add 2003::1/64
R1(config-if)#tunnel source lo0
R1(config-if)#tunnel destination 192.168.2.1
R2(config)#int tunnel1
R2(config-if)#ipv6 add 2003::2/64
R2(config-if)#tunnel source lo0
R2(config-if)#tunnel destination 192.168.1.1
Konfiguráljuk az EIGRP-t az IPv6-os hálózat számára:
R1(config)#ipv6 router eigrp 10
R1(config)#int tunnel1
R1(config-if)#ipv6 eigrp 10
R2(config)#ipv6 router eigrp 10
R2(config)#int tunnel1
R2(config-if)#ipv6 eigrp 10
Konfiguráljuk az OSPF-et az IPv4-es hálózat számára:
R1(config)#router ospf 1
R1(config-router)#network 10.0.0.0 0.0.0.3 area 0
R1(config-router)#network 12.0.0.0 0.0.0.3 area 0
R1(config-router)#network 192.168.1.0 0.0.0.255 area 0
R2(config)#router ospf 1
R2(config-router)#network 11.0.0.0 0.0.0.3 area 0
R2(config-router)#network 13.0.0.0 0.0.0.3 area 0
R2(config-router)#network 192.168.2.0 0.0.0.255 area 0
R3(config)#router ospf 1
R3(config-router)#network 12.0.0.0 0.0.0.3 area 0
R3(config-router)#network 13.0.0.0 0.0.0.3 area 0
R3(config)#router ospf 1
R3(config-router)#network 10.0.0.0 0.0.0.3 area 0
R3(config-router)#network 11.0.0.0 0.0.0.3 area 0
Ha mindent jól csináltunk, megkapjuk a konzolon a szomszédsági viszonyok kialakulásáról szóló üzeneteket. Ha lekapcsoljuk például az R4-en keresztül haladó útvonalat, akkor az alagút ebből semmit nem vesz észre, minden működik tovább. Az eddigi példákban kialakított GRE alagutakat pont-pont típusúnak neveztük, hiszen egyetlen alagút csak egyetlen másik végpontba csatlakozott. Természetesen senki nem tiltja meg nekünk, hogy ugyanarról az interfészről egyszerre több alagút is kiinduljon. A következő példában azt láthatjuk, hogy egy forgalomirányító egy interfészéből 2 darab pont-pont típusú alagutat építünk ki.
Két darab pont-pont GRE alagút konfigurálása
Vegyük a következő topológiát. Az egyszerűség kedvéért, most nem egy harmadik forgalomirányítón keresztül alakítjuk ki az alagutakat, hanem közvetlenül a forgalomirányítók között. (Ez a feladat szempontjából nem lényegi különbség, csupán nem kell a külső hálózatban konfigurálnunk egy forgalomirányító protokollt, a tényleges problémával foglalkozhatunk.)
A korábban tárgyaltaknak megfelelően a konfigurálás teljesen egyértelmű. Most csak az alagutak létrehozásának utasításait írom fel, mert ezekkel dolgozunk tovább, a fizikai interfészek és az OSPF irányítóprotokoll konfigurációját nem. Az alagút forrása IP címmel lesz konfigurálva.
R1(config)#int Tunnel0
R1(config-if)#ip add 192.168.2.1 255.255.255.252
R1(config-if)#tunnel source 201.100.10.1
R1(config-if)#tunnel destination 201.100.10.2
R1(config)#int Tunnel1
R1(config-if)#ip add 192.168.3.1 255.255.255.252
R1(config-if)#tunnel source 201.100.10.1
R1(config-if)#tunnel destination 201.100.10.3
R2(config)#int Tunnel0
R2(config-if)#ip add 192.168.2.2 255.255.255.252
R2(config-if)#tunnel source 201.100.10.2
R2(config-if)#tunnel destination 201.100.10.1
R3(config)#int Tunnel0
R3(config-if)#ip add 192.168.3.2 255.255.255.252
R3(config-if)#tunnel source 201.100.10.3
R3(config-if)#tunnel destination 201.100.10.1
Mondhatjuk, hogy ebben semmi újdonság nincsen. Azonban ha elképzeljük, hogy R1 nem kettő, hanem sokkal több forgalomirányítóval tartja egy-egy alagúton keresztül a kapcsolatot, akkor már ez a fajta konfiguráció nem túl rugalmas, hiszen minden egyes alagút interfészhez külön hálózatot kell konfigurálnunk, amikor is a fizikai hálózatunkban már azonos hálózatban vannak a forgalomirányítók interfészei. Ismerjünk meg egy másik technikát, a multipont GRE alagutak használatát, amely lehetővé teszi, hogy az alagutak ugyanabban a hálózatban legyenek.
Multipont GRE (mGRE) alagút konfigurálása
A fenti topológia elnevezése hub and spoke (“kerékagy és küllő”), ahol R1 játssza el a hub szerepét, míg R2 és R3 a scope. A következő konfigurációban az R1 forgalomirányítón multipont GRE alagutat alakítunk ki, míg a többieken pont-pont típusút.
Mint láthatjuk, R1-ből csupán egyetlen GRE alagút indul ki, amely viszont több pontban végződik. (Ezért multipont.) Ez az egy alagút így egyetlen alhálózathoz tartozik. Tegyük fel, hogy R1-ről (192.168.2.1) R2-t (192.168.2.2) akarjuk elérni. Az R1-en az az alagút forrása egyértelműen a 201.100.10.1/24 cím, de honnan tudja R1, hogy R2-höz vezető cél a 210.100.10.2? (Pont-pont alagút esetén ezt ugye explicit módon megadtuk.)
Ennek a problémának a megoldásában lesz segítségünkre az NHRP (Next Hop Resulation Protocol). A protokoll működése egyszerű: Az egyik forgalomirányító lesz az NHRP szerver, a többi az NHRP kliens. A kliensek bejelentkeznek a szerverre, és elküldik neki a publikus IP címüket. Ezeket a publikus címeket a szerver eltárolja egy gyorstárban a hozzájuk tartozó alagút címmel együtt, és amikor egy alagutat akar kiépíteni bármelyik forgalomirányító felé, az alagúthoz tartozó publikus IP címet csak előveszi a gyorstárból. (A kliens forgalomirányítók is lekérdezhetik a szervertől ezeket a címeket.) A szerveren a címek nem csak dinamikusan gyűjthetők össze, hanem statikusan is konfigurálhatók. Mi ez utóbbi módon fogunk ebben a példában eljárni. (Nem sokat téved az, aki némi hasonlóságot vél felfedezni például a Frame Relay hálózatok esetén az inverz-ARP DLCI-IP cím összerendeléséhez, ott azt térképeztük fel, melyik IP címhez melyik DLCI vezet, itt azt, melyik IP címhez a GRE alagút melyik IP címe vezet. Az NHRP-t eredetileg ilyen NBMA hálózatokhoz tervezték még 1998-ban.)
Annak érdekében, hogy csak az alagút konfigurációjára összpontosítsunk, a belső hálózatban statikus útvonalválasztást konfigurálunk. (A külső hálózatban pedig minden forgalomirányító közvetlenül kapcsolódik, így ott nincsen szükség útvonalak definiálására.)
A statikus útvonalválasztásunk:
R1(config)#ip route 172.16.2.0 255.255.255.0 192.168.2.2
R1(config)#ip route 172.16.3.0 255.255.255.0 192.168.2.3
R2(config)#ip route 172.16.1.0 255.255.255.0 192.168.1.2
R2(config)#ip route 172.16.3.0 255.255.255.0 192.168.2.3
R3(config)#ip route 172.16.1.0 255.255.255.0 192.168.2.1
R3(config)#ip route 172.16.2.0 255.255.255.0 192.168.2.2
R2-n és R3-on a a GRE alagút konfigurálása a már megszokott módon történik, hiszen ezeken a forgalomirányítókon ismerjük a pont-pont GRE alagút forrását és célját is:
R2(config)#int Tunnel0
R2(config-if)#ip add 192.168.2.2 255.255.255.0
R2(config-if)#tunnel source 201.100.10.2
R2(config-if)#tunnel destination 201.100.10.1
R3(config)#int Tunnel0
R3(config-if)#ip add 192.168.2.3 255.255.255.0
R3(config-if)#tunnel source 201.100.10.3
R3(config-if)#tunnel destination 201.100.10.1
Az R1 forgalomirányítón konfiguráljuk a multipont GRE-t. A konfigurációs parancsok magukért beszélnek. Miután létrehozzuk az alagút interfészt, és hozzárendeljük az IP címét, összerendeljük a távoli forgalomirányítók belső hálózatban (vagyis az alagút másik végén) használt IP címét a publikus hálózat IP címével, majd megjelöljük, hogy pont-multipont módban működjön. Értelemszerűen itt csak az alagút forrását tudjuk megadni:
R1(config)#int Tunnel0
R1(config-if)#ip add 192.168.2.1 255.255.255.0
R1(config-if)#ip nhrp map 192.168.2.2 201.100.10.2
R1(config-if)#ip nhrp map 192.168.2.3 201.100.10.3
R1(config-if)#tunnel source 201.100.10.1
R1(config-if)#tunnel mode gre multipont
A GRE alagút használata egyszerű, de nagyon hatékony technika (kiemelkedő az a tulajdonsága, hogy a csoportos című üzeneteket is képes átvinni), viszont ne felejtsük el, hogy a forgalmat titkosítatlanul szállítja a szolgáltató hálózatán keresztül. Erre is van persze megoldás, de azt egy másik cikkben már.
