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.

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.

SNMP: Configurando monitorización y alertas en equipos cisco

Una de esas cosas básicas que debería tener cualquier red medio decente es monitorización, y para ello se utiliza SNMP.

SNMP es algo bastante sencillo, consiste en un servidor que cada x tiempo se conecta a una serie de direcciones ip que tiene almacenadas, y extrae información de varios parámetros, como por ejemplo la CPU usada en el router, el porcentaje de uso de una interfaz...etc.

Para hacer esto utiliza MIBs, que permiten extraer los parámetros requeridos de cada dispositivo de cada fabricante, por ejemplo para saber cual es el uso de CPU de un router se utiliza una MIB, en cambio para saber la ocupación de disco duro de un pc con windows 7 se utilizara otra.

Un servidor de SNMP solo se puede conectar a un dispositivo por SNMP si en el dispositivo hay un agente de SNMP corriendo, y aquí veremos como configurar el agente SNMP en un disitivo cisco con ios.

Lo primero que debe hacerse para habilitar snmp es activar una community string, la community va a ser una especie de password que va a tener el dispositivo para poder conectarse a el por SNMP, se pueden configurar varias, y se puede regular lo que se puede hacer con cada community, si queremos que la community solo permita leer el estado del router pero no modificarlo deberemos crear una commmunity de lectura, si ademas queremos permitir que desde el servidor de SNMP se modifique la configuración del equipo deberemos crear una community de escritura.

Router(config)#snmp-server community SuPeRsEcRetO ?
  <1-99>       Std IP accesslist allowing access with this community string
  <1300-1999>  Expanded IP accesslist allowing access with this community
               string
  WORD         Access-list name
  ipv6         Specify IPv6 Named Access-List
  ro           Read-only access with this community string
  rw           Read-write access with this community string
  view         Restrict this community to a named MIB view

Como se puede ver el comando es muy sencillo, con ro para solo lectura, rw para lectura y escritura, y además podemos o mas bien debemos crear una ACL en la que restringiremos los equipos que pueden consultar por SNMP el estado del disposivivo.

Una vez metido este comando ya tenemos la funcionalidad básica de SNMP, tenemos una community y nuestro equipo ya debería ser accesible por SNMP.

Ahora vamos a habilitar otras cosillas útiles, como por ejemplo habilitar eventos que automáticamente hagan que nuestro dispositivo lance información SNMP a un servidor de monitorización

snmp-server enable traps snmp linkdown linkup <---- Si se cae o levanta una interfaz avísame
snmp-server enable traps cpu threshold <---- Avísame si la cpu sobrepasa un umbra
process cpu threshold type total rising 80 interval 60 <---- El umbral es el 80% de CPU, se comprueba cada 60 segundos y si se sobrepasa se envía un trap.

snmp-server host 155.1.146.100 SuPeRsEcRetO <---- el host al que envío los traps de  SNMP y la comuunity con la que lo hago

¿Sobre que cosas se pueden enviar traps de SNMP?

Router(config)#snmp-server enable traps ?  
  atm            Enable SNMP atm traps
  bgp            Enable BGP traps
  bstun          Enable SNMP BSTUN traps
  casa           Enable SNMP casa traps
  cnpd           Enable NBAR Protocol Discovery traps
  config         Enable SNMP config traps
  config-copy    Enable SNMP config-copy traps
  cpu            Allow cpu related traps
  dial           Enable SNMP dial control traps
  dlsw           Enable SNMP dlsw traps
  dnis           Enable SNMP DNIS traps
  ds0-busyout    Enable ds0-busyout traps
  ds1            Enable SNMP DS1 traps
  ds1-loopback   Enable ds1-loopback traps
  ds3            Enable SNMP DS3 traps
  dsp            Enable SNMP dsp traps
  eigrp          Enable SNMP EIGRP traps
  entity         Enable SNMP entity traps
  envmon         Enable SNMP environmental monitor traps
  event-manager  Enable SNMP Embedded Event Manager traps
  flash          Enable SNMP FLASH notifications
  frame-relay    Enable SNMP frame-relay traps
  hsrp           Enable SNMP HSRP traps
  icsudsu        Enable SNMP ICSUDSU traps
  ipmobile       Enable SNMP ipmobile traps
  ipmulticast    Enable SNMP ipmulticast traps
  ipsec          Enable IPsec traps
  isakmp         Enable ISAKMP traps traps
  isdn           Enable SNMP isdn traps
  l2tun          Enable SNMP L2 tunnel protocol traps
  msdp           Enable SNMP MSDP traps
  mvpn           Enable Multicast Virtual Private Networks traps
  ospf           Enable OSPF traps
  pim            Enable SNMP PIM traps
  pppoe          Enable SNMP pppoe traps
  rsvp           Enable RSVP flow change traps
  rtr            Enable SNMP Response Time Reporter traps
  snmp           Enable SNMP traps
  stun           Enable SNMP STUN traps
  syslog         Enable SNMP syslog traps
  tty            Enable TCP connection traps
  voice          Enable SNMP voice traps
  vrrp           Enable SNMP vrrp traps
  vtp            Enable SNMP VTP traps
  xgcp           Enable XGCP protocol traps

Como se puede ver se puede configurar traps sobre muchas cosas, pero mi recomendación es no pasarse configurando traps, porque si tienes demasiada información en el el servidor de SNMP al final nadie le hace ni caso, mejor solo monitorizar cosas importantes.






Por último os dejo un link en la web de cisco, por si un día os toca monitorizar algo para lo que no teneis la mib, es el mib locator, donde con paciencia podeis encontrar la mib para monitorizar todo lo que se pueda monitorizar en un dispositivo de cisco.

http://tools.cisco.com/ITDIT/MIBS/servlet/index

Access-list: Filtrado de paquetes fragmentados

Una cosa a tener en cuenta en el mundo del networking es, que no todos los medios nos ofrecen la misma MTU. MTU significa Maximum Uransmition Unit, y es el tamaño máximo de trama de nivel 2 que admite el medio de transmisión.

Por defecto Ethernet tiene una MTU de 1500bytes, en cambio hay medios ópticos que admiten 4000 o mas bytes, un servicio MPLS sobre Ethernet añade un cierto payload, por tanto tampoco pueden ofrecer 1500bytes, un túnel GRE como hemos visto en artículos anteriores ofrece una MTU sobre Ethernet de 1475bytes.

El caso es que si queremos transmitir un paquete que a nivel 3 tiene mas bytes, que la MTU que tiene el Medio a nivel 2, lo que se hace es fragmentar el paquete. Fragmentar consiste en enviar el paquete en “trocitos” de nivel 2 hasta el siguiente salto, estos trocitos no contienen toda la información de nivel 3, por tanto para poder determinar el siguiente  salto por defecto los routers deberán cachear los paquetes fragmentados, y después adaptar el paquete de nivel 3 a la MTU del camino que lleva al siguiente salto.

Ese proceso que conlleva el uso de fragmentación de paquetes supone un cierto stress extra para los routers, y también supone un cierto problema para algunos firewalls no muy avanzados ya que no son capaces de analizar ciertos paquetes.

En algunos entornos para evitar esto lo que se hace es denegar los paquetes fragmentados, algo que puede llegar a ser medio viable en algunas redes corporativas, pero no sería viable en ningún operador.
Estos paquetes fragmentados se pueden filtrar con Access list, no es algo demasiado complicado de hacer con una lista extendida.

Access-list extended SIN_FRAGMENTACION
 Deny ip any any fragments
 Permit ip any any

Tuneles GRE: La navaja suiza del networking

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.

¿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

TCP Intercept:

TCP Intercept es una tecnología que permite interceptar las sesiones con origen o destino de un flujo(una ACL), estableciendose la sesión contra el router, que será el intermediario de la sesión.

Se usa particularmente para ataques de SYN flood, y en general para ataques de denegación de servicio basados en sesiones.

Tiene un monton de opciones a configurar, tiempo de inactividad, numero de conexiones con syn pero sin ACK...etc.

access-list 146 permit ip any 155.1.146.0 0.0.0.255  <---el trafico que interceptas
ip tcp intercept list 146 
ip tcp intercept connection-timeout 30 <----inactividad

El enlace a la web de cisco con todas las posibilidades que se pueden configurar.

Filtrado a nivel 7 con NBAR

NBAR es una tecnología que permite el reconocimiento de aplicaciones y protocolos a nivel de aplicación, sin trabajar tan solo a nivel de puerto como hace un firewall, lo que permite NBAR, es leer a nivel de cabeceras html...etc

Una funcionalidad de seguridad que se le puede dar a NBAR es descartar los paquetes de los protocolos no permitidos.

En este ejemplo vamos a descartar los paquetes de bittorrent, da igual que cambie de puerto el bittorrent, NBAR se basa en patrones de tráfico a nivel de aplicación, y descartará el tráfico.

Ejemplo:

class-map match-all TORRENTE
   match protocol bittorrent
policy-map ELIMINAR
  class TORRENTE
   drop 

int fa0/0
    service-policy output ELIMINAR

Lo malo que tienen todo este tipo de trabajos de inspección a nivel 7, es que incurre en una mayor carga de trabajo para el router. Cosa aplicable a cualquier tecnología de este tipo, por lo que se recomienda hacerlo en equipos que no están demasiado justos de CPU y memoria.