Mostrando entradas con la etiqueta mGRE. Mostrar todas las entradas
Mostrando entradas con la etiqueta mGRE. Mostrar todas las entradas

lunes, 23 de septiembre de 2013

Tuneles GRE


Este artículo forma parte de una serie de varios artículos que tratan los distintos tipos de routing en IPV4 e IPV6 para CCNA R&S, para ir al índice del curso tienes este link:

Tuneles GRE:

Hace ya mas de un año que puliqué varios artículos sobre tuneles GRE, pero en estaocasión voy a tomar como base mi primer artículo sobre tuneles GRE, y adaptarlo un poco.

Tuneles GRE BASICO
Tuneles GRE multipunto (AVANZADO)
Tuneles GRE multipunto ejemplo(AVANZADO)
Recursividad en tuneles GRE


Los túneles GRE son una herramienta todoterreno que te puede echar una mano para prácticamente todo, permitiendote saltarte limitaciones de protocolos y tecnologías múltiples y diversas.

El hecho de ser una herramienta tan flexible, que te saca de tantos apuros, hace que el 95% de las veces se hagan "chapuzas" con ellos. Antes de explicar un poco los túneles GRE mi recomendación es, que salvo para circunstancias muy excepcionales intentes evitar los túneles GRE ya que prácticamente siempre va a haber una alternativa mejor diseñada, mas limpia, mejor optimizada, y con un troubleshooting mas sencillo.

¿Que es un tunel GRE?


GRE significa Generic Routing Encapsulation, es una encapsulación para tuneles, por defecto no lleva encriptación, es facil de implementar, funciona bajo IPV4 pero se puede usar direccionamiento de IPV4 e IPV6, y lo mas importante que permite establecer routing dinámico a traves del tunel.

En el fondo resumiendo un poco, lo que hace un tunel GRE es simplemente crear una interfaz virtual entre los dos extremos del tunel, cuando se envían paquetes hacia el otro lado del tunel estos paquetes dentro del tunel tendrán como destino la dirección ip que corresponda, pero para llegar al otro extremo se tendrán que enviar paquetes con destino el otro extremo del tunel. Esto en realidad es tunelizar el tráfico ya que da cara a la red es algo transparente.

¿Como se configura?


router(config)#interface tunnel X
router(config-if)# tunnel source ( ip | interface )
router(config-if)# tunnel destination ( destination_ip )
router(config-if)#ip address x.x.x.x y.y.y.y
router(config-if)# ipv6 address ( ipv6_address ) ( ipv6_mask )

¿ Como funcionan ?


Es un protocolo que funciona a nivel 4 y admite una MTU máxima de 1475 bytes, por tanto si prevees que sobre el tunel tiene que fluir tráfico que no admita fragmentación, y que tenga mas de 1475 bytes lo mejor es ir olvidandose. El que avisa no es traidor.

Ejemplo con routing dinámico:



R4:
interface Loopback1
ip address 4.4.4.4 255.255.255.255
!
interface Loopback2
ip address 1.2.3.4 255.255.255.255
!
interface Tunnel1
ip address 10.0.0.1 255.255.255.252
tunnel source Loopback1
tunnel destination 6.6.6.6
!
interface Ethernet0/0
ip address 192.168.1.1 255.255.255.0
half-duplex
!
router eigrp 100
network 1.2.3.4 0.0.0.0
network 10.0.0.1 0.0.0.0
auto-summary
!
router rip
version 2
network 4.0.0.0
network 192.168.1.0
!
R5:

interface Ethernet0/0
ip address 192.168.1.2 255.255.255.0
half-duplex
!
interface Ethernet0/1
ip address 192.168.2.1 255.255.255.0
half-duplex

router rip
version 2
network 192.168.1.0
network 192.168.2.0
R6:


interface Ethernet0/1
ip address 192.168.2.2 255.255.255.0
half-duplex

interface Loopback1
ip address 6.6.6.6 255.255.255.255
!
interface Loopback2
ip address 4.3.2.1 255.255.255.255
!
interface Tunnel1
ip address 10.0.0.2 255.255.255.252
tunnel source Loopback1
tunnel destination 4.4.4.4


router eigrp 100
network 4.3.2.1 0.0.0.0
network 10.0.0.2 0.0.0.0
no auto-summary
!
router rip
version 2
network 6.0.0.0
network 192.168.2.0
En este mismo ejemplo si se enviase un tracert desde la loopback 1 a la loopback 1 del otro extremo veríamos que hay un solo salto, ya que el router intermedio no está viendo pasar el tráfico de loopback a loopbak, el router intermedio solo ve pasar tráfico perteneciente a un tunel, y lo que haya dentro del tunel no le interesa.

martes, 14 de agosto de 2012

GRE: Tirando un tunel GRE por recursividad

En artículos anteriores hemos visto los túneles GRE, hoy vamos a ver el routing recursivo, una pifia habituál a la hora de trabajar con túneles GRE.

Un tunel GRE permite conectar dos extremos que tienen conectividad y por tanto routing, haciendo que cuando los paquetes atraviesen el tunel parezca que se trata de un único salto, pero en realidad los paquetes del tunel atraviesan una red enruta.

Los túneles se basan en una comunicación TCP entre una IP de origen y una IP de destino.El problema viene cuando hablamos también routing dinámico dentro del tunel, y para alcanzar la ip del otro lado del tunel el camino mas corto es a través del propio tunel.

Esto lo que hace es que para seguir con la comunicación TCP del propio tunel se envíen los paquetes por dentro del tunel, y claro la conexión se cae :-) . Solución, no permitas que las ip que forman el tunel GRE sean alcanzables por routing dentro del tunel GRE.

A continuación pongo un ejemplo, basado en el ejemplo del primer artículo sobre túneles GRE de este mismo blog.

Ejemplo con routing dinámico:



R4:
interface Loopback1
 ip address 4.4.4.4 255.255.255.255
!
interface Loopback2
 ip address 1.2.3.4 255.255.255.255
!
interface Tunnel1
 ip address 10.0.0.1 255.255.255.252
 tunnel source Loopback1
 tunnel destination 6.6.6.6
!
interface Ethernet0/0
 ip address 192.168.1.1 255.255.255.0
 half-duplex
!
router eigrp 100
 network 1.2.3.4 0.0.0.0
 network 10.0.0.1 0.0.0.0
 auto-summary
!
router rip
 version 2
 network 4.0.0.0
 network 192.168.1.0
!
R5:

interface Ethernet0/0
 ip address 192.168.1.2 255.255.255.0
 half-duplex
!
interface Ethernet0/1
 ip address 192.168.2.1 255.255.255.0
 half-duplex

 router rip
 version 2
 network 192.168.1.0
 network 192.168.2.0
 R6: 
 interface Ethernet0/1
 ip address 192.168.2.2 255.255.255.0
 half-duplex

 interface Loopback1
 ip address 6.6.6.6 255.255.255.255
!
interface Loopback2
 ip address 4.3.2.1 255.255.255.255
!
interface Tunnel1
 ip address 10.0.0.2 255.255.255.252
 tunnel source Loopback1
 tunnel destination 4.4.4.4


router eigrp 100
 network 4.3.2.1 0.0.0.0
 network 10.0.0.2 0.0.0.0
 no auto-summary
!
router rip
 version 2
 network 6.0.0.0
 network 192.168.2.0
Creando el bucle:
R6:

 router eigrp 100
 network 6.6.6.6 0.0.0.0

Output:
R6(config-router)#network 6.6.6.6 0.0.0.0
R6(config-router)#^Z
R6#do show
*Mar  1 00:23:37.527: %SYS-5-CONFIG_I: Configured from console by console
R6#
*Mar  1 00:23:48.539: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 10.0.0.1 (Tunnel1) is down: holding time expired
R6#
Lo que se ve en el otro lado es:

 *Mar  1 00:24:34.223: %TUN-5-RECURDOWN: Tunnel1 temporarily disabled due to recursive routing
*Mar  1 00:24:35.223: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1, changed state to down
*Mar  1 00:24:35.291: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 10.0.0.2 (Tunnel1) is down: interface down
R4#
http://networkkings-es.blogspot.com/2012/06/tuneles-gre-la-navaja-suiza-del.html
http://networkkings-es.blogspot.com/2012/06/mgre-tuneles-gre-multipunto.html
http://networkkings-es.blogspot.com/2012/06/mgre-configuracion-de-tuneles-gre.html

lunes, 19 de marzo de 2012

mGRE: Tuneles GRE Multipunto

En un artículo anterior estuvimos tratando como se configuran los túneles GRE punto a punto, que son una herramienta realmente fácil de utilizar, y con una excesiva tendencia a hacer chapucillas con ella. Pese a todo, los túneles GRE llevan muchísimo tiempo funcionando, y a todos nos han salvado muchas veces de alguna limitación en un proyecto que no estaba contemplada al comienzo.

Los túneles GRE multipunto son una tecnología poco conocida, con el mismo potencial que un túnel GRE, pero con el añadido de poder crear un segmento de red punto multipunto, emulando lo que por ejemplo podría ser una conexión de frame-relay punto multipunto. Honestamente debo decir que nunca en el mundo real me he encontrado ningún engendro de este tipo funcionando en una red real, pero en un entorno en el que tengas que montar muchos túneles GRE contra un site central, pero queriendo tener conectividad entre las oficinas remotas, si el número de sedes es muy elevado, puede llegar a ser una opción.

A la hora de configurar túneles GRE multipunto tenemos que tener en cuenta que estamos configurando un tunel GRE con sus propiedades y limitaciones, pero ademas hay que añadirle las propiedades y limitaciones de una red punto multipunto, como Frame relay, esto supone que tendrá que existir un punto que hará la función de hub, donde se concentraran todas la conexiones, y varios spokes, que serán sitios remotos que solo tendrán conexión con el hub, y si quieren llegar al resto de spokes deberán hacerlo a través de hub.

La  característica común entre un mGRE, y frame relay, es que ambos tienen un mecanismo para la resolución de direcciones, donde en frame relay se usa inverse ARP para resolver que numero de DLCI  se corresponde a la IP de el vecino, mGRE usa NHRP(Next Hop Resolution Protocol) que lo que hace es crear una tabla de equivalencias entre las IP dentro del tunel y la IP de destino a la que se tienen que enviar los paquetes para alcanzar los extremos del tunnel.

Configuración Basica:

HUB:

interface Tunnel0
  ip address x.x.x.x x.x.x.x
  ip nhrp map multicast dynamic <----si vas a usar un protocolo de routing deja que se hagan los mapeos de multicast dinámicos
  ip nhrp network-id 100 <----identifica a la red tiene que ser igual en todos
  tunnel source FastEthernet0/0<--- igual que los normales
  tunnel mode gre multipoint
  tunnel key 333<---si tienes varios y con VRF es mejor que lo uses

SPOKES:

interface Tunnel0
 ip address y.y.y.y y.y.y.y
 ip nhrp map <ip_dentro_tunel> <ip_fuera_tunel> <---el equivalente a un mapeo estático en FR, se pone en los spokes
 ip nhrp map multicast <ip_dentro_tunel_del_hub> <---indica a quien se envía el multicast
 ip nhrp network-id 100
 ip nhrp nhs <ip_dentro_tunel_del_hub> <---el servidor de nhrp osea el hub
 tunnel source FastEthernet0/0
 tunnel mode gre multipoint
 tunnel key 333
En el próximo artículo veremos un ejemplo real, configurado y un poco de troubleshooting.

lunes, 12 de marzo de 2012

mGRE: Configuración de tuneles GRE multipunto

Anteriormente vimos como se configuraban los mGRE, pero no habíamos visto un ejemplo de configuración de mGRE.

El ejemplo es muy sencillo, tres routers conectados en la misma LAN, el R1 es el HUB, y los otros dos son los spokes, lo he hecho en la misma lan, pero podían ser routers distanciados completamente, a miles de kilómetros...etc.


Configuración del HUB:

hostname HUB

interface Tunnel0
 ip address 192.168.1.1 255.255.255.0
 no ip redirects
 ip nhrp map multicast dynamic
 ip nhrp network-id 100
 ip nhrp shortcut
 tunnel source FastEthernet0/0
 tunnel mode gre multipoint
 tunnel key 333
!
interface FastEthernet0/0
 ip address 80.10.10.1 255.255.255.0
 duplex auto
 speed auto
!        
interface FastEthernet0/1
 no ip address
 shutdown
 duplex auto
 speed auto
 Configuración de el SPOKE 1:

hostname SPOKE1
interface Tunnel0
 ip address 192.168.1.2 255.255.255.0
 no ip redirects
 ip nhrp map 192.168.1.1 80.10.10.1
 ip nhrp map multicast 80.10.10.1
 ip nhrp network-id 100
 ip nhrp nhs 192.168.1.1
 ip nhrp registration timeout 120
 ip nhrp shortcut
 tunnel source FastEthernet0/0
 tunnel mode gre multipoint
 tunnel key 333
!
interface FastEthernet0/0
 ip address 80.10.10.2 255.255.255.0
 duplex auto
 speed auto
!
interface FastEthernet0/1
 no ip address
 shutdown
 duplex auto
 speed auto

Configuración de SPOKE2:

hostname SPOKE2
interface Tunnel0
 ip address 192.168.1.3 255.255.255.0
 no ip redirects
 ip nhrp map 192.168.1.1 80.10.10.1
 ip nhrp network-id 100
 ip nhrp nhs 192.168.1.1
 ip nhrp registration timeout 120
 ip nhrp shortcut
 tunnel source FastEthernet0/0
 tunnel mode gre multipoint
 tunnel key 333
!
interface FastEthernet0/0
 ip address 80.10.10.3 255.255.255.0
 duplex auto
 speed auto
!
interface FastEthernet0/1
 no ip address
 shutdown
 duplex auto
 speed auto
Tenemos conectividad desde todos los sitios:

HUB#ping 192.168.1.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/17/72 ms
HUB#ping 192.168.1.3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/8/12 ms

SPOKE1#          ping 192.168.1.3

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

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

SPOKE2#ping 192.168.1.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/11/24 ms
SPOKE2#ping 192.168.1.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/12/28 ms
Después de haberlo configurado en el spoke 1 deberíamos ver lo siguiente:

SPOKE1#show ip nhrp brief
   Target             Via            NBMA           Mode   Intfc   Claimed
192.168.1.1/32     192.168.1.1     80.10.10.1      static   Tu0     <   >
192.168.1.2/32     192.168.1.2     80.10.10.2      dynamic  Tu0     <   >
192.168.1.3/32     192.168.1.3     80.10.10.3      dynamic  Tu0     <   >
 Como podemos ver, tenemos una entrada estática para alcanzar el hub, y dinámicamente aprendemos como llegar al resto spokes.