Configurare GRE Tunnel su apparati Cisco

Continuiamo con la nostra serie di articoli che, attraverso esempi pratici e semplificati, dimostrano l’applicazione di strumenti fondamentali nei rispettivi ambiti. Introduciamo la configurazione e alla verifica di un Tunnel GRE (Generic Routing Encapsulation) al fine di connettere delle reti remote utilizzando una terza rete differente di transito. Evidente la rete di “mezzo” espressa da R2 e R3 rappresenta la nostra rete Pubblica. Al termine del laboratorio, quando le interfacce virtuali GRE saranno UP, apprezzeremo la comunicazione fra le reti Remote 172.16.0.0/16.

Di seguito lo schema degli indirizzi che caratterizzano la topologia oggetto del laboratorio:

Tutti i router della topologia hanno una configurazione di base che comprende Hostname e Indirizzi IP. Su R2 e R3 è configurato il Protocollo EIGRP, mentre sui Router R1 e R4 sono presenti rotte statiche verso 10.0.0.0/8. Dopo la configurazione del Tunnel GRE sarà Implementato OSPF.

Il primo passo per l’esecuzione del laboratorio è quello di verificare la tabella di routing del Router R1. Apprezzeremo che il router R1 non esegue nessun protocollo di Routing. L’unica rotta aggiuntiva è quella statica verso la rete 10.0.0.0/8. Il router R4 è configurato allo stesso modo:

R1# show ip route
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
+ - replicated route, % - next hop override
Gateway of last resort is not set
10.0.0.0/8 is variably subnetted, 3 subnets, 3 masks
S 10.0.0.0/8 [1/0] via 10.10.1.2
C 10.10.1.0/24 is directly connected, Ethernet0/0
L 10.10.1.1/32 is directly connected, Ethernet0/0
172.16.0.0/16 is variably subnetted, 4 subnets, 2 masks
C 172.16.1.0/24 is directly connected, Ethernet0/1
L 172.16.1.1/32 is directly connected, Ethernet0/1
C 172.16.11.0/24 is directly connected, Loopback0
L 172.16.11.1/32 is directly connected, Loopback0

Verifichiamo se il router R1 può pingare il Router R4, la sua interfaccia E0/0 (10.10.3.2). Quindi concludiamo che i router R1 e R4 si raggiungono reciprocamente usando le rete 10.0.0.0/8 :

R1# ping 10.10.3.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.3.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms

Accediamo alla tabella di routing di R2. Questo router esegue EIGRP con R3. Quindi entrambi i router sono consapevoli dell’esistenza dell’intera rete 10.0.0.0/8. Non sono, invece, a conoscenza dell’esistenza della rete 172.16.0.0/16, e delle sue sottoreti nascoste dietro i router R1 e R4:

R2# show ip route
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
+ - replicated route, % - next hop override
Gateway of last resort is not set
10.0.0.0/8 is variably subnetted, 8 subnets, 2 masks
C 10.10.1.0/24 is directly connected, Ethernet0/0
L 10.10.1.2/32 is directly connected, Ethernet0/0
C 10.10.2.0/24 is directly connected, Ethernet0/1
L 10.10.2.1/32 is directly connected, Ethernet0/1
D 10.10.3.0/24 [90/307200] via 10.10.2.2, 21:40:41, Ethernet0/1
C 10.10.12.0/24 is directly connected, Loopback0
L 10.10.12.1/32 is directly connected, Loopback0
D 10.10.13.0/24 [90/409600] via 10.10.2.2, 21:40:41, Ethernet0/1

CORSI CORRELATI:

Consulta il nostro Catalogo Corsi per Tecnologia oppure fai una Ricerca per Vendor o ancora trova uno specifico corso attraverso il motore di ricerca interno: Ricerca Corsi. Contattaci ora al Numero Verde 800-177596, il nostro team saprà supportarti nella scelta del percorso formativo più adatto alla tue esigenze.

Procediamo ora alla configurazione del Tunnel GRE. Accedendo alla console di R1 definiamo l’interfaccia Tunnel0 assegnandole l’indirizzo 172.16.99.1/24. Impostiamo l’interfaccia E0/0 di R1 (10.10.1.1) come sorgente del tunnel e l’interfaccia E0/0 di R4 (10.10.3.2) come destinazione. L’interfaccia Tunnel0 sarà immediatamente UP dopo averla istanziata:

R1# conf t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)# interface tunnel0
R1(config-if)#
*Nov 3 14:14:43.002: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed
state to down
R1(config-if)# ip address 172.16.99.1 255.255.255.0
R1(config-if)# tunnel source 10.10.1.1
R1(config-if)# tunnel destination 10.10.3.2
R1(config-if)#
*Nov 3 14:15:12.555: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed
state to up
R1(config-if)# end
R1#

Accediamo al Router R4 eseguendo le stesse operazioni ma invertite rispetto a R1, attribuendo all’interfaccia Tunnel0 l’indirizzo 172.16.99.2/24. Anche in questo caso, l’interfaccia Tunnel0 cambia stato in UP:

R4# conf t
Enter configuration commands, one per line. End with CNTL/Z.
R4(config)# interface tunnel0
R4(config-if)#
*Nov 3 14:24:00.594: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed
state to down
R4(config-if)# ip address 172.16.99.2 255.255.255.0
R4(config-if)# tunnel source 10.10.3.2
R4(config-if)# tunnel destination 10.10.1.1
R4(config-if)#
*Nov 3 14:24:29.749: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed
state to up
R4(config-if)# end
R4#

Verifichiamo lo stato del Tunnel appena configurato, attraverso 2 comandi fondamentali. Apprezzeremo lo stato e le caratteristiche salienti del GRE Tunnel:

R1# show ip interface brief Tunnel 0
Interface IP-Address OK? Method Status Protocol
Tunnel0 172.16.99.1 YES manual up up

R4# show interface Tunnel 0
Tunnel0 is up, line protocol is up
Hardware is Tunnel
Internet address is 172.16.99.2/24
MTU 17916 bytes, BW 100 Kbit/sec, DLY 50000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation TUNNEL, loopback not set
Keepalive not set
Tunnel source 10.10.3.2, destination 10.10.1.1
Tunnel protocol/transport GRE/IP
<... output omitted ...>

Visualizziamo la tabella di routing di R1, rilevando che il traffico destinato alla rete 172.16.99.0/24 “entra” nel Tunnel GRE (Tunnel0):

R1# show ip route
<... output omitted ...>
10.0.0.0/8 is variably subnetted, 3 subnets, 3 masks
S 10.0.0.0/8 [1/0] via 10.10.1.2
C 10.10.1.0/24 is directly connected, Ethernet0/0
L 10.10.1.1/32 is directly connected, Ethernet0/0
172.16.0.0/16 is variably subnetted, 6 subnets, 2 masks
C 172.16.1.0/24 is directly connected, Ethernet0/1
L 172.16.1.1/32 is directly connected, Ethernet0/1
C 172.16.11.0/24 is directly connected, Loopback0
L 172.16.11.1/32 is directly connected, Loopback0
C 172.16.99.0/24 is directly connected, Tunnel0
L 172.16.99.1/32 is directly connected, Tunnel0

Procediamo a pingare dal Router R1, l’altra estremità del Tunnel che si attesta su R4 (172.16.99.2). Qui si esprime la funzionalità del Tunnel GRE, che incapsulerà il traffico attraverso il Tunnel in altri pacchetti IP aventi IP header propri della rete reale su cui il tunnel transita. All’estremità del Tunnel avverrà un processo inverso di Decapsulazione che eliminerà l’header aggiuntivo. R2 e R3, che si trovano nel mezzo, non avranno nessuna consapevolezza del processo di incapsulamento, trattando i pacchetti IP esattamente come gli altri:

R1# ping 172.16.99.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.99.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms

Stabilito il buon funzionamento del Tunnel, procediamo a configurare il Protocollo OSPF affinché R1 conosca le reti di R4 e viceversa. Il processo OSPF sfrutterà il Tunnel:

R4# conf t
Enter configuration commands, one per line. End with CNTL/Z.
R4(config)# router ospf 1
R4(config-router)# router-id 0.0.0.4
R4(config-router)# network 172.16.0.0 0.0.255.255 area 0
R4(config-router)# end
R4#

R1# conf t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)# router ospf 1
R1(config-router)# router-id 0.0.0.1
R1(config-router)# network 172.16.0.0 0.0.255.255 area 0
R1(config-router)#
*Nov 4 11:41:51.093: %OSPF-5-ADJCHG: Process 1, Nbr 0.0.0.4 on Tunnel0 from LOADING
to FULL, Loading Done
R1(config-router)# end

Le tabelle di routing di R1 e R4 si popolano delle rispettive reti remote grazie al Protocollo OSPF che sfrutta il Tunnel0. Abbiamo quindi utilizzato una rete di “mezzo” che può rappresentare la nostra rete pubblica al fine di mettere in comunicazione 2 reti remote che possono rappresentare 2 reti delle stessa azienda:

R1# show ip route
<... output omitted ...>
10.0.0.0/8 is variably subnetted, 3 subnets, 3 masks
S 10.0.0.0/8 [1/0] via 10.10.1.2
C 10.10.1.0/24 is directly connected, Ethernet0/0
L 10.10.1.1/32 is directly connected, Ethernet0/0
172.16.0.0/16 is variably subnetted, 8 subnets, 2 masks
C 172.16.1.0/24 is directly connected, Ethernet0/1
L 172.16.1.1/32 is directly connected, Ethernet0/1
O 172.16.4.0/24 [110/1010] via 172.16.99.2, 00:19:23, Tunnel0
C 172.16.11.0/24 is directly connected, Loopback0
L 172.16.11.1/32 is directly connected, Loopback0
O 172.16.14.1/32 [110/1001] via 172.16.99.2, 00:19:23, Tunnel0
C 172.16.99.0/24 is directly connected, Tunnel0
L 172.16.99.1/32 is directly connected, Tunnel0

R1# ping 172.16.4.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.4.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms

R1# show ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
0.0.0.4 0 FULL/ - 00:00:37 172.16.99.2 Tunnel0

Configurare GRE Tunnel su apparati Cisco

RICHIEDI ORA IL SUPPORTO DI UN NOSTRO SPECIALISTA