Router Teldat. Dynamic Multipoint VPN s

Transcripción

1 Router Teldat Dynamic Multipoint Doc. DM768 Rev Marzo, 2006

2 ÍNDICE Capítulo 1 Introducción Introducción a las redes dinámicas multipunto Qué problemas presenta crear una DMVPN?... 3 a) IPSec no soporta protocolos de routing dinámico... 3 b) Origen y destino del túnel... 3 c) Direcciones IP dinámicas El protocolo NHRP Funcionamiento del protocolo NHRP Tipos de paquete NHRP Referencias Capítulo 2 Configuración Configuración de una DMVPN Configuración del interfaz Túnel IP (TNIP) DESTINATION DISABLE ENABLE ENCAPSULATION KEEPALIVE LIST MODE NHRP NHRP-TOS PATH-MTU-DISCOVERY QOS-PRE-CLASSIFY SOURCE VRF-ENCAP Configuración del protocolo de encapsulado GRE (Generic Routing Encapsulation) CHECKSUM CIPHER CIPHER-KEY KEY LIST SEQUENCE-DATAGRAMS Configuración del protocolo NHRP AUTHENTICATION ENABLE HOLDTIME LIST MAP NHS RATE-LIMIT RECORD REGISTRATION RESPONDER SERVER-ONLY USE Capítulo 3 Monitorización Monitorización del protocolo NHRP ? (AYUDA) CLEAR ii -

3 a) CLEAR CACHE b) CLEAR STATISTICS LIST Capítulo 4 Ejemplos Ejemplo de configuración de una DMVPN a) Escenario b) Modo de funcionamiento c) Configuración HUB d) Configuración SPOKE e) Configuración Teldat f) Configuración Teldat iii -

4 Capítulo 1 Introducción

5 1. Introducción a las redes dinámicas multipunto A lo largo de este manual se describe el funcionamiento de las redes privadas virtuales dinámicas multipunto basadas en el protocolo IPSec (DMVPN). El objetivo es mostrar su utilidad y servir como referencia a la hora de construir DM basadas en Routers Teldat. La finalidad de las DM es permitir la interconexión entre las distintas sedes de una compañía, no sólo con la sede central de ésta, sino también entre ellas, sin necesidad de que el tráfico tenga que pasar a través de la sede central. La ventaja principal de las DM es que permiten hacerlo mediante túneles cifrados a través del acceso a la red pública, como puede ser Internet, sin necesidad de contratar enlaces punto a punto dedicados, que son mucho menos económicos. El acceso a Internet es relativamente barato y en muchos casos ya está presente en las sedes de la compañía. El protocolo IPSec permite conexiones punto a punto cifradas garantizando la integridad y la privacidad de los datos en redes públicas. La manera más factible de organizar una red de gran tamaño basada en el protocolo IPSec e Internet, es utilizar una red completamente o parcialmente mallada o un esquema hub-and-spoke. Se suele elegir el esquema hub-and-spoke porque en la mayoría de los casos la mayor parte del tráfico transcurre entre cada spoke y el hub, mientras el resto es tráfico esporádico entre spokes. Una red completamente mallada tiene el inconveniente de exigir mayor potencia a los spokes, para que estos se puedan conectar al resto de spokes, cuyo número puede ser elevado en una red de gran tamaño. En una DMVPN para conectar el hub a los spokes se utiliza Internet y por tanto los spokes tienen la posibilidad de conectarse entre ellos al ser Internet una red mallada. Red privada Router HUB Internet SPOKE1 Router Router SPOKE2 Router SPOKE3 Red privada Red privada Red privada Dado que la conexión entre spokes es posible, es preferible que el tráfico entre spokes se realice directamente sin pasar a través del hub, ya que de esta forma no se consumen recursos del hub y los ROUTER TELDAT Introducción Dynamic Multipoint I - 2

6 caminos de ida y vuelta de la información son más óptimos que los que pasen por el hub, cuya localización geográfica desconocemos y probablemente sea más lejana que la del spoke con el que se desea comunicar Qué problemas presenta crear una DMVPN? La implementación de una red de este tipo plantea ciertos problemas que hay que resolver: a) IPSec no soporta protocolos de routing dinámico Para poder enviar a la red las tablas de rutas de los spokes se utilizan protocolos de routing dinámicos. Los protocolos de routing dinámicos se basan en la utilización de paquetes broadcast y multicast. El protocolo IPSec, al ser punto a punto, sólo permite paquetes de tipo unicast. Para poder utilizar protocolos de routing dinámico con IPSec se utiliza el protocolo de encapsulamiento GRE (Generic Routing Encapsulation). Los paquetes GRE son paquetes unicast y sólo necesitan conocer su origen y destino. Al ser los paquetes GRE de tipo unicast el protocolo IPSec puede cifrarlos. Como el protocolo GRE encapsula los paquetes, ya no es necesario que IPSec vuelva a encapsularlos y añada otra cabecera IP, permitiendo así utilizar IPSec en modo transporte y ahorrar 20 bytes por paquete. b) Origen y destino del túnel La necesidad del protocolo GRE de conocer el origen y el destino de cada túnel hace que la configuración de los hubs pueda llegar a ser excesivamente grande en redes de gran tamaño. Esto es así ya que el hub debe conocer las direcciones de todos los spokes a los que da servicio. Del mismo modo, si se quiere que un spoke pueda conectarse con cualquier otro spoke de la red, esto implica la necesidad de crear una red completamente mallada lo que complicará en exceso la configuración de los spokes. c) Direcciones IP dinámicas Otra característica de las conexiones a Internet es que suelen utilizar direcciones IP dinámicas obtenidas de un servidor a través del protocolo DHCP o PPP. Esto complica aún más el esquema y hace imposible conocer de antemano la dirección destino del túnel. El protocolo GRE, como ya hemos comentado, necesita conocer con antelación estas direcciones para poder crear el túnel entre los extremos origen y destino. Para solucionar todos estos problemas las DM utilizan dos protocolos: Mutipoint GRE (mgre) y NHRP (Next Hop Resolution Protocol). mgre permite la creación de túneles dinámicos multipunto y utiliza NHRP para averiguar la dirección destino del túnel, la dirección del siguiente salto El protocolo NHRP El protocolo NHRP que implementan los equipos Teldat es conforme al estándar del documento RFC2332 NBMA Next Hop Resolution Protocol (NHRP). El protocolo NHRP permite la simplificación de la configuración de los equipos, tanto de spokes como de hubs. Los equipos que actúan como hubs no necesitan tener configurada la dirección de ninguno de los spokes de la red y por tanto las direcciones de los spokes pueden haber sido asignadas dinámicamente. Sólo los spokes necesitan tener configurada la dirección de uno o varios hubs. Nada más arrancar, cada spoke se encarga de registrarse en el hub que tenga configurado, estableciéndose un túnel permanente entre cada spoke y el hub. A su vez, cada spoke tiene configurada una dirección multicast a la que enviar los paquetes del protocolo de routing dinámico que tenga configurado. La dirección multicast suele ser la del hub que tiene configurado el spoke. De esta forma el spoke informa al hub de las rutas de sus redes mediante algún protocolo de enrutamiento dinámico. ROUTER TELDAT Introducción Dynamic Multipoint I - 3

7 Por su parte el hub crea una entrada multicast para cada spoke que se registra y se encarga de informar a todos los spokes de la red que tenga registrados, de las rutas de todos los spokes. Esto permite que cada spoke pueda tener acceso a cualquier red de otro spoke como si de una red completamente mallada se tratara, pero con la ventaja de no complicar las configuraciones de los spokes. Los túneles entre spokes en una DMVPN se establecen dinámicamente. El hub hace las veces de servidor NHRP y se encarga de dar servicio a los spokes que previamente se han registrado en él. Para establecer un túnel entre dos spokes, primero el spoke1 realiza una petición al hub para conocer la dirección pública del interfaz del spoke2 al que quiere conectar (dirección destino del túnel). Si el spoke2 está registrado en el hub, se recibe una respuesta positiva del hub con la información solicitada. El spoke2 hace lo mismo al recibir la solicitud del spoke1 de establecer un túnel y solicita al hub la información de siguiente salto del spoke1. A continuación ambos spokes negocia la creación de un túnel IPSec sobre el interfaz mgre (multipoint GRE) y establecen la comunicación. Cuando el túnel deja de tener utilidad para ambos spokes, este muere al cabo de un tiempo de inactividad configurable. El túnel que se ha creado une directamente ambos spokes, mientras el hub sólo interviene para facilitar las direcciones destino necesarias para que los spokes sean capaces de establecer un túnel directo entre ellos. De esta forma se libera al hub de cualquier tarea de cifrado y encaminamiento adicional. El protocolo NHRP de cada equipo mantiene en una memoria caché la información del siguiente salto (dirección pública del interfaz para una dirección privada conocida) de cada túnel que tiene activo el equipo. En un hub está almacenada la información de cada spoke que se haya registrado en él. En cada spoke está la información de los hubs en los que se haya registrado y la información que haya solicitado a éstos para establecer túneles con otros spokes Funcionamiento del protocolo NHRP Las DM se configuran sobre un interfaz virtual de tipo túnel llamado TNIP (abreviatura de túnel IP) El interfaz TNIP tiene su propia dirección IP y sobre él se configura el protocolo mgre. En el interfaz TNIP se configuran también los parámetros de funcionamiento del protocolo NHRP que da servicio al protocolo mgre. El manual dónde se describe el interfaz TNIP es el Dm 719. El interfaz TNIP se configura con una dirección IP privada y tiene a su vez una dirección IP pública asociada, la del interfaz físico sobre el que se establecerá el túnel. El objetivo de NHRP es descubrir la dirección pública del interfaz TNIP del equipo remoto con el que se quiere establecer comunicación a través de un túnel. La dirección privada ya se conoce por medio del protocolo de routing dinámico que está corriendo en la red: Cada spoke se registra periódicamente en el hub o hubs que tenga configurados y mantiene activos los túneles que establece con éstos. A través de estos túneles viajan los paquetes multicast del protocolo de rutado dinámico. El hub transmite a los spokes las rutas del resto de equipos de la DMVPN a través del túnel mencionado, es decir, se transmite el siguiente salto, que normalmente coincide con la dirección privada. Para descubrir la dirección IP destino del túnel, el protocolo mgre realiza una petición al protocolo NHRP con la dirección privada del siguiente salto. El protocolo NHRP consulta en su memoria caché si tiene disponible alguna entrada con esta dirección IP privada. Si encuentra una entrada devuelve la dirección IP pública que tiene almacenada y mgre se encarga de establecer el túnel. Si no encuentra una entrada, el protocolo NHRP genera un paquete de petición de resolución al hub principal que tenga configurado (NHS Next Hop Server) y que esté activo. Mientras se espera la respuesta, el NHS devuelve al protocolo mgre su propia dirección pública. De esta forma se evita la pérdida de paquetes mientras se espera la respuesta del hub a la petición de resolución. Los paquetes viajan desde un spoke al hub y por último al otro spoke (camino spoke-hub-spoke), mientras se obtiene la dirección que nos ROUTER TELDAT Introducción Dynamic Multipoint I - 4

8 permita establecer el camino más óptimo que es el spoke-spoke. Nada más llegar la respuesta del hub, en el siguiente paquete que se intente enviar entre los spokes, se crea el túnel entre ellos. Una vez se ha establecido el túnel dinámicamente entre dos spokes y ha finalizado su utilidad, este caduca en un intervalo previamente configurado y se borran las entradas de la caché de los spokes que se crearon con el túnel Tipos de paquete NHRP En el protocolo NHRP existen siete tipos de paquete posibles que viajan entre los NHC s (Next Hop Client) y los NHS s (Next Hop Servers): 1. Registration Request: petición de registro del NHC en el NHS. 2. Registration Reply: respuesta del NHS al NHC a una petición de registro. 3. Resolution Request: petición de resolución de una dirección de siguiente salto que envía el NHC al NHS. 4. Resolution Reply: respuesta del NHS al NHC con la dirección de siguiente salto solicitada. 5. Purge Request: petición de borrado de una entrada de caché que envía el NHS al NHC cuando la información de dicha entrada deja de ser válida. 6. Purge Reply: respuesta del NHC al NHS a una petición de borrado de una entrada de caché. 7. Indicación de Error: paquete de error que indica algún problema en alguno de los paquetes recibidos en el equipo que genera el paquete de error. Los paquetes NHRP se componen de dos partes, una cabecera fija, una parte obligatoria y una parte de extensiones opcionales. La estructura del paquete es la siguiente: Parte fija AFN unused Protocol Type unused Hop Count Packet Size Checksum Extensions Offset Prot. Version Packet Type SHTL SSTL AFN Indica el tipo de dirección de la capa de enlace, en nuestro caso el valor será un 0x1 que indica direcciones con formato IPv4. Protocol Type 0x0800 que indica Ethertype. ROUTER TELDAT Introducción Dynamic Multipoint I - 5

9 Hop Count Es el número máximo de NHS s que puede atravesar un paquete antes de ser descartado. Packet Size Es el tamaño del paquete NHRP en octetos. Checksum Es la suma de comprobación IP del paquete NHRP completo. Extensions Offset Si es 0 indica que el paquete no tiene extensiones y si es distinto de cero es la distancia en octetos desde la cabecera del paquete NHRP hasta el comienzo de las extensiones. Protocol Version Versión del protocolo NHRP. En nuestro caso un 1, que indica que es la versión definida en la RFC2332. Packet Type NHRP Resolution Request(1), NHRP Resolution Reply(2), NHRP Registration Request(3), NHRP Registration Reply(4), NHRP Purge Request(5), NHRP Purge Reply(6), o NHRP Error Indication(7). SHTL SSTL Tipo y longitud de la dirección NBMA (Non Broadcast Multiaccess Network) origen (dirección pública del interfaz). Para nuestro caso, direcciones IPv4, este valor es 4. Si es 0 el campo Source NBMA Address de la parte obligatoria no existe en el paquete. En nuestro caso, direcciones IPv4, siempre 0. Esto implica que el campo Source NBMA Subaddress de la parte obligatoria no exista en ningún paquete. Parte obligatoria Source Prot. Length Dest. Prot. Length Flags Request ID Source NBMA Address Source NBMA Subaddress Source Protocol Address Destination Protocol Address ROUTER TELDAT Introducción Dynamic Multipoint I - 6

10 Source Protocol Length Longitud en octetos de la dirección privada origen, en nuestro caso, direcciones IPv4, siempre es 4. Si es 0, el campo Source Protocol Length no existirá en el paquete. Destination Protocol Legth Longitud en octetos de la dirección privada destino, en nuestro caso, direcciones IPv4, siempre es 4. Si es 0, el campo Destination Protocol Length no existirá en el paquete. Flags Su significado depende del tipo de paquete: Resolution Request: Q A D U S unused Q: indica que el equipo que generó el Resolution Request es un router. A: la información que se pide debe ser autorizada, obtenida de un paquete de registro en el NHS. D: no utilizado, debe estar a 0. U: indica que la información requerida debe ser única, se obtiene un único CIE (entrada de información de cliente). S: la información del equipo contenida en el paquete es estable y exacta. Resolution Reply: Q A D U S unused Q: valor copiado del Resolution Request. A: la información que se incluye en el CIE del paquete es autorizada, obtenida de un paquete de registro en el NHS. D: la información que contiene el CIE es estable y su valor se garantiza durante el tiempo que especifica el campo Holding Time del CIE. U: valor copiado del Resolution Request. S: valor copiado del Resolution Request. Registration Request: U unused U: indica que la información que estamos registrando es única. ROUTER TELDAT Introducción Dynamic Multipoint I - 7

11 Purge Request: N unused N: si es 1 indica que el equipo que generó el paquete no espera un paquete de Purge Reply como respuesta. Request ID Junto con el valor de la dirección origen sirve para identificar el paquete NHRP. Source NBMA Address Es la dirección pública origen. La dirección del equipo que ha enviado el paquete de request. Si el campo SHTL de la parte fija del paquete NHRP es cero entonces el campo que ocupa esta dirección no existe dentro del paquete. Source NBMA Subaddress En nuestro caso, direcciones IPv4, este campo no existe dentro del paquete, el campo SSTL de la parte fija del paquete NHRP es 0. Source Protocol Address Es la dirección privada origen del paquete de request y la dirección privada destino de un paquete de reply. Destination Protocol Address Es la dirección privada destino de un paquete de request. ROUTER TELDAT Introducción Dynamic Multipoint I - 8

12 CIE s (entradas de información de cliente) Code Prefix Length unused MTU Holding Time Client Add T/L Client Subadd T/L Client Protocol len Preference Client NBMA Address Client NBMA Subaddress Client Protocol Address... Code Prefix Length unused MTU Holding Time Client Add T/L Client Subadd T/L Client Protocol len Preference Client NBMA Address Client NBMA Subaddress Client Protocol Address Code En los paquetes tipo request es 0 y en los reply indica un acuse de recibo positivo (ACK) si es 0 y negativo (NAK) si tiene cualquier otro valor. Los valores que puede tomar son los siguientes: 0. Successful Registration. 1. Unrecognized Extension. 3. NHRP Loop Detected. 4. Administratively Prohibited. 5. Insufficient Resources. 6. Protocol Address Unreachable. 7. Protocol Error. 8. NHRP SDU Size Exceeded. 9. Invalid Extension. 10. Invalid NHRP Resolution Reply Received. 11. Authentication Failure. 12. No Internetworking Layer Address to NBMA Address Binding Exists. 13. Binding Exists But Is Not Unique. 14. Unique Internetworking Layer Address Already Registered. 15. Hop Count Exceeded. ROUTER TELDAT Introducción Dynamic Multipoint I - 9

13 Prefix Length Si es distinto de 0 y distinto de 0xFF indica que la información que contiene el CIE corresponde a una red y es el número de unos de la máscara de la red. En caso de ser 0 indica que la dirección corresponde a un único equipo. MTU Este valor es la unidad de transmisión máxima del equipo cliente. En nuestro caso tiene el valor por defecto de 1514 octetos. Holding Time Especifica el número de segundos para los que la información del siguiente salto contenida en el CIE es válida. Cuando este tiempo haya expirado esta información debe ser borrada de la caché. En un NAK debe ser 0. Client Address Type & Length Es la longitud en octetos del campo Client NBMA Address. En nuestro caso, direcciones IPv4, será 4 si el campo Client NBMA Address aparece en el CIE, 0 en caso de que no exista. Client Subaddress Type & Length En nuestro caso es siempre 0 y el campo Client NBMA Subaddress no existe en el CIE. Client Protocol Length Es la longitud en octetos del campo Client Protocol Address. En nuestro caso, direcciones IPv4, será 4 si el campo Client Protocol Address aparece en el CIE, 0 en caso de que no exista. Preference Cuando el paquete NHRP contiene varios CIE s indica la preferencia de uno respecto de los otros, un valor más alto indica mayor preferencia. Client NBMA Address Dirección pública del siguiente salto. Client NBMA Subaddress Este campo no existe en nuestro caso, direcciones IPv4. Client Protocol Address Dirección privada del siguiente salto. ROUTER TELDAT Introducción Dynamic Multipoint I - 10

14 Parte obligatoria de un paquete de error Source Prot. Length Dest. Prot. Legth Flags Error Code Source NBMA Address Source NBMA Subaddress Source Protocol Address Destination Protocol Address Contents of NHRP Packet in error Error Offset Error Code Contiene el código de la causa del error que se ha producido. Los posibles valores son: 1, 3, 6, 7, 8, 9, 10, 11, 15. Para ver los mensajes de error que se corresponden con cada código ver más arriba el campo Code del CIE de la parte obligatoria del paquete NHRP. Error Offset Es el offset en octetos desde el inicio de la parte fija del paquete NHRP original, en la que se ha observado el error, hasta el campo que se considera erróneo en el paquete original. Contents of NHRP Packet in error El contenido completo del paquete en el que se ha observado el error, desde la parte fija hasta las extensiones. Extensiones C u Type Length Value... Compulsory bit Indica que la extensión es obligatoria y no puede ser ignorada. Type Tipo de extensión: 0. The End of Extensions. 3. Responder Address Extension. 4. NHRP Forward Transit NHS Record Extension. 5. NHRP Reverse Transit NHS Record Extension. ROUTER TELDAT Introducción Dynamic Multipoint I - 11

15 7. NHRP Authentication Extension. 8. NHRP Vendor-Private Extension. Length Longitud en octetos del campo Value de la extensión (no incluye los campos Type y Length). Value Depende del tipo de extensión. La End of Extensions no lleva campo Value. La Responder Address Extension incluye un CIE con las direcciones del equipo que ha generado el paquete de respuesta (reply). La Forward Transit NHS Record Extension lleva un CIE por cada NHS que ha atravesado el paquete en el camino de ida (caso de un paquete request). Por su parte la Reverse Transit NHS Record Extension incluye un CIE por cada NHS que ha atravesado el paquete en el camino de vuelta (caso de un paquete reply). La Vendor-Private Extension en nuestro caso no existe. El contenido del campo Value de la Authentication Extension se detalla en el siguiente punto. Valor de la extensión de autenticación reserved Source Address Authentication Data... SPI (Security Parameter Index) SPI Es el Security Parameter Index que en nuestro caso es 1 e indica que la autenticación se realiza con una palabra de autenticación de 8 caracteres. Source Address En nuestro caso no existe este campo. Authentication Data Palabra de 8 caracteres que funciona como palabra de autenticación. ROUTER TELDAT Introducción Dynamic Multipoint I - 12

16 2. Referencias RFC-2332: NBMA Next Hop Resolution Protocol (NHRP), April Dm719: Interfaz Túnel IP (TNIP). ROUTER TELDAT Introducción Dynamic Multipoint I - 13

17 Capítulo 2 Configuración

18 1. Configuración de una DMVPN En este apartado se describen los pasos necesarios para configurar una DMVPN basada en equipos Teldat. Para acceder al menú de configuración ejecutamos el comando CONFIG o PROCESS 4 sobre el menú raíz de la consola del equipo. *PROCESS 4 Config> Para crear una DMVPN debemos crear en cada equipo un interfaz virtual de tipo túnel IP o TNIP. Para crear un interfaz de tipo Túnel IP se debe introducir ADD DEVICE tnip <identificador del túnel> en el menú de configuración global. Config>ADD DEVICE tnip 1 Added TNIP interface tnip1 Config> Para entrar posteriormente en configuración basta con teclear NETWORK tnipx, donde X representa el identificador del túnel: Config>NETWORK tnip1 -- IP Tunnel Net Configuration -- El protocolo que es soportado sobre el interfaz TNIP es el IP. Es necesario para activar el IP sobre el interfaz TNIP asignar una dirección IP al citado interfaz o configurarlo como interfaz de tipo no numerado. Ejemplo con dirección IP conocida: ip address Ejemplo como interfaz no numerado: ip address unnumbered ROUTER TELDAT Configuración Dynamic Multipoint II - 15

19 2. Configuración del interfaz Túnel IP (TNIP) En este apartado se describen los comandos de configuración del interfaz TNIP. Para acceder al entorno de configuración de TNIP, se debe introducir NETWORK <interfaz TNIP> : *P 4 Config>NETWORK tnip1 -- IP Tunnel Net Configuration --? description Enter interface description destination Destination address disable Disable the tunnel interface enable Enable the tunnel interface encapsulation Encapsulation configuration ip Interface Internet Protocol config commands keepalive Enable keepalive list Show tunnel interface configuration mode Encapsulation mode for the tunnel interface nhrp NHRP protocol configuration nhrp-tos Mark NHRP packets with a TOS value no path-mtu-discovery Enable Path MTU Discovery on tunnel qos-pre-classify QoS pre-classify shutdown Change state to administratively down source Source address or source interface update Update a level indicator vrf-encap Specify parameters for a VPN Routing/Forwarding instance Hay ciertos comandos comunes para todos los interfaces del equipo. Estos comandos se describen en el manual de configuración común de interfaces (Dm772 Configuración Común de Interfaces). Los comandos disponibles son los siguientes: Comando Función? (AYUDA) Lista los comandos u opciones disponibles. DESTINATION Configura la dirección IP destino del túnel. DISABLE Deshabilita el interfaz túnel. ENABLE Habilita el interfaz túnel. ENCAPSULATION Accede al menú de configuración del protocolo encapsulador. KEEPALIVE Habilita el mantenimiento keepalive. LIST Muestra los parámetros configurados. MODE Selecciona el modo de encapsular en el interfaz túnel (protocolo encapsulador). NHRP Comandos de configuración del protocolo NHRP. NHRP-TOS Permite marcar los paquetes NHRP con un valor de TOS. NO Deshabilita o elimina funcionalidades. PATH-MTU-DISCOVERY Habilita Path MTU Discovery en el túnel. QOS-PRE-CLASSIFY Habilita la preclasificación de paquetes de BRS. SOURCE Configura la dirección IP origen del túnel. ROUTER TELDAT Configuración Dynamic Multipoint II - 16

20 VRF-ENCAP EXIT Especifica parámetros de una instancia VPN Routing/Forwarding. Sale del menú de configuración de TNIP DESTINATION Configura la dirección IP destino del túnel IP. Debe coincidir con la dirección IP configurada como origen del túnel en el router del otro extremo. Si la dirección IP destino del túnel no coincide con la configurada como origen en el otro extremo, los paquetes que se envíen a dicho router serán descartados por no pertenecer al túnel. Es necesario que exista ruta hacia la dirección IP destino pues si no los paquetes del túnel no pueden ser encaminados. Como precaución, dicha ruta debe ser una ruta estática para evitar el problema de recursividad en la tabla de rutas explicado en el capítulo 1 del manual de TNIP DM719. Para dejar la dirección IP de destino sin especificar (túnel dinámico o promiscuo) se emplea el comando NO DESTINATION. Ejemplo: DESTINATION? <a.b.c.d> Ipv4 format DESTINATION DISABLE Deshabilita el interfaz túnel. Por defecto el interfaz túnel está deshabilitado. Ejemplo: DISABLE? <cr> DISABLE 2.3. ENABLE Habilita el interfaz túnel. Por defecto el interfaz túnel no se encuentra habilitado. Ejemplo: ENABLE? <cr> ENABLE ROUTER TELDAT Configuración Dynamic Multipoint II - 17

21 2.4. ENCAPSULATION Accede a la configuración del protocolo encapsulador. De momento el único protocolo encapsulador soportado es GRE (Generic Routing Encapsulation). Este submenu se describe en el apartado 3. Ejemplo: ENCAPSULATION? <cr> tnip1 GRE config> ENCAPSULATION -- GRE Configuration -- tnip1 GRE config> 2.5. KEEPALIVE Habilita el mantenimiento keepalive del Túnel IP. Este mantenimiento consiste en el envío periódico de paquetes de petición keepalive. Si no se reciben dentro del periodo configurado se determina la pérdida de conectividad del túnel, y se deja el interfaz de Túnel IP inoperativo (estado down ) hasta que se restablezca la conectividad. En los túneles dinámicos sólo se mandarán paquetes de mantenimiento "keepalive" cuando el túnel esté establecido, es decir, cuando se haya aprendido la dirección IP del túnel (ver comando de monitorización LIST STATUS). En los túneles promiscuos nunca se enviarán paquetes de mantenimiento "keepalive". El formato de este comando es KEEPALIVE [<periodo> [<intentos>]]. Los parámetros se describen a continuación: Parámetro periodo intentos Descripción Número de segundos entre envíos sucesivos de paquetes de petición keepalive. También actúa como tiempo máximo de respuesta, ya que sólo se consideran las respuestas al último paquete de petición keepalive enviado. El rango permitido es de 1 a segundos, y el valor por defecto 10 segundos. Número de paquetes consecutivos de petición keepalive sin respuesta para determinar que se ha perdido la conectividad. El rango permitido es de 1 a 255 envíos sin respuesta, y el valor por defecto 3. Para deshabilitar el mantenimiento keepalive se emplea el comando NO KEEPALIVE. KEEPALIVE? < > Keepalive period (default 10 seconds) <cr> KEEPALIVE 30? <1..255> Keepalive retries (default 3 retries) <cr> ROUTER TELDAT Configuración Dynamic Multipoint II - 18

22 Ejemplo: KEEPALIVE LIST Muestra la configuración del túnel IP. Ejemplo: LIST? <cr> LIST Tunnel mode: GRE (enabled) Tunnel source , destination QoS preclassify: disabled Keepalive: enabled with period 10, 3 retries NHRP type of service: 25 Tunnel mode: indica el tipo de encapsulado y el estado (habilitado/deshabilitado). Tunnel source / destination: direcciones IP origen / destino del túnel. QoS preclassify: indica si se encuentra habilitada la preclasificación de BRS. Keepalive: muestra la configuración del mantenimiento keepalive. NHRP type of service: muestra el tipo de servicio seleccionado para los paquetes NHRP MODE Selecciona el modo de encapsulación. Soporta GRE (Generic Routing Encapsulation) y mgre (Multipoint GRE). Ejemplo1: Ejemplo2: MODE? gre Generic Routing Encapsulation Protocol MODE GRE? ip Over IP multipoint Over IP (multipoint) <cr> MODE GRE IP MODE GRE MULTIPOINT 2.8. NHRP Permite configurar el protocolo NHRP. Para más información ver el apartado 4. Configuración del protocolo NHRP. ROUTER TELDAT Configuración Dynamic Multipoint II - 19

23 NHRP? authentication enable holdtime list map nhs rate-limit record registration responder server-only use Authentication string Enable NHRP protocol Advertised holdtime List NHRP protocol's configuration Map dest IP addresses to NBMA addresses Specify a next hop server Rate limit NHRP traffic Enable NHRP transit record extensions Change registration mode Responder interface Disable NHRP requests Minimum use for sending requests 2.9. NHRP-TOS Permite marcar los paquetes NHRP con un valor de TOS (type of service). De esta forma podemos filtrar los paquetes NHRP, por ejemplo para evitar que los paquetes NHRP registration request inicien una llamada en un enlace UMTS. Ejemplo: NHRP-TOS? <0..255> IPv4 type of service value NHRP-TOS PATH-MTU-DISCOVERY Activa la funcionalidad que detecta cuál es el valor de MTU apropiado para que no haya fragmentación en los paquetes que se envían desde un extremo al otro del túnel. Esta funcionalidad se encarga de descubrir la mínima MTU en el camino entre los dos extremos del túnel y de esta forma evitar que se produzca fragmentación. Al activar esta funcionalidad los paquetes TCP/IP que envíe el equipo llevan el bit DF (don t fragment) activado. Ejemplo: PATH-MTU-DISCOVERY? <cr> PATH-MTU-DISCOVERY QOS-PRE-CLASSIFY Habilita la preclasificación de paquetes por parte del BRS. Al habilitar esta opción los paquetes que llegan al túnel son clasificados por el BRS (consultar el manual de BRS, Dm715) antes de ser encapsulados por el túnel. Esto permite distinguir entre distintos tipos de tráfico IP que son enviados a través del túnel. Si esta opción está deshabilitada los paquetes serán clasificados una vez encapsulados, por lo que todo el tráfico que sea procesado por el túnel tendrá la misma cabecera IP (la que pone el túnel) y serán clasificados todos en la misma clase de BRS. ROUTER TELDAT Configuración Dynamic Multipoint II - 20

24 Para deshabilitar este parámetro se utiliza NO QOS-PRE-CLASSIFY. Ejemplo: QOS-PRE-CLASSIFY? <cr> QOS-PRE-CLASSIFY SOURCE Configura el interfaz o la dirección IP origen del túnel IP. En el caso de una dirección IP, esta debe coincidir con la dirección IP de uno de los interfaces configurados en el router (Ethernet, PPP, Loopbak, etc.) excepto la del propio túnel. También debe coincidir con la dirección IP configurada como destino en el equipo que sea el otro extremo del túnel. En el caso de especificar un interfaz como origen del túnel este debe ser uno de los interfaces configurados en el router excepto el propio túnel. Si la dirección IP origen del túnel no coincide con ninguno de los interfaces del router, los paquetes destinados a esta dirección IP no son considerados por el router como propios y los intentará encaminar hacia otro equipo. Si la dirección IP configurada como origen no coincide con la configurada como destino en el otro extremo del router, no existirá nunca enlace. Si el origen del túnel es un interfaz PPP que recibe asignación dinámica de dirección IP (consultar el manual del Interfaz PPP, Dm710), entonces se debe especificar el interfaz PPP en cuestión como origen del túnel. Ejemplo1: Ejemplo2: SOURCE? <a.b.c.d> Tunnel source address <interface> Tunnel source interface SOURCE SOURCE ppp VRF-ENCAP Este comando permite asociar la dirección destino del túnel IP a una instancia VRF. La ruta para dicho destino será entonces consultada en la tabla de rutas de la VRF asociada. El origen y el destino del túnel deben estar en la misma VRF. Ejemplo: VRF-ENCAP? <1..32 chars> VPN Routing/Forwarding instance name VRF-ENCAP thisisanexample ROUTER TELDAT Configuración Dynamic Multipoint II - 21

25 3. Configuración del protocolo de encapsulado GRE (Generic Routing Encapsulation) En este apartado se describen los comandos de configuración del protocolo encapsulador GRE. Para acceder al entorno de configuración de GRE hay que introducir el comando ENCAPSULATION en el menú de configuración del interfaz túnel (con el interfaz configurado en modo de encapsulación GRE). *P 4 Config>NETWORK tnip1 -- IP Tunnel Net Configuration -- TNIP config>encapsulation -- GRE Configuration -- GRE config>? checksum cipher cipher-key key list no sequence-datagrams GRE config> End-to-end checksum RC4 Ciphering Cipher key ID key for the tunnel interface Show GRE configuration Drop out-of-order datagrams Los comandos disponibles son los siguientes: Comando CHECKSUM CIPHER CIPHER-KEY KEY LIST SEQUENCE-DATAGRAMS Función Habilita el checksum extremo-a-extremo (GRE). Habilita el cifrado RC4 en el túnel GRE. Configura la clave del cifrado RC4. Configura el identificador de túnel. Muestra los parámetros configurados. Descartar datagramas recibidos fuera de orden CHECKSUM Habilita la opción de envío de checksum en el paquete GRE. Por defecto, el túnel no garantiza la integridad de los paquetes. Habilitando dicha opción el router envía los paquetes GRE con campo checksum. Si se recibe un paquete con el campo checksum siempre se comprueba el checksum, descartando aquellos paquetes que lo tengan inválido, independientemente de que el equipo tenga o no habilitada la opción. Para deshabilitar el checksum se utiliza NO CHECKSUM. tnip1 GRE config>checksum? <cr> tnip1 GRE config> ROUTER TELDAT Configuración Dynamic Multipoint II - 22

26 Ejemplo: tnip1 GRE config>checksum tnip1 GRE config> 3.2. CIPHER Activa el cifrado RC4 de los paquetes encapsulados en el túnel GRE. Por defecto no se encuentra habilitado el cifrado. Aunque los paquetes de petición keepalive se cifran, los de respuesta no se cifran, ya que realmente no se encapsulan en el túnel. Para deshabilitar el cifrado RC4 se utiliza NO CIPHER. Ejemplo: tnip1 GRE config>cipher? <cr> tnip1 GRE config> tnip1 GRE config>cipher tnip1 GRE config> 3.3. CIPHER-KEY Configura la clave de cifrado del interfaz túnel. Dicha clave admite un máximo de 32 caracteres alfanuméricos. Para restablecer la clave por defecto de cifrado en túneles GRE se utiliza NO CIPHER-KEY. Ejemplo: tnip1 GRE config>cipher-key? <word> Text tnip1 GRE config> tnip1 GRE config>cipher-key thisisanexample tnip1 GRE config> 3.4. KEY Habilita la comprobación del identificador del túnel. Al habilitarse esta opción el equipo solicita un identificador para el túnel en cuestión. Dicho identificador de túnel ha de ser igual en ambos extremos del túnel. El identificador es un número entero comprendido entre 0 y (32 bits). Por defecto el túnel tiene deshabilitada esta opción. Cuando el identificador de túnel se encuentra habilitado el router descarta aquellos paquetes recibidos con un identificador distinto al configurado. ROUTER TELDAT Configuración Dynamic Multipoint II - 23

27 Ejemplo: tnip1 GRE config>key? < > Value in the specified range tnip1 GRE config> tnip1 GRE config>key 5 tnip1 GRE config> 3.5. LIST Muestra la configuración del protocolo GRE. Ejemplo: tnip1 GRE config>list? <cr> tnip1 GRE config> tnip1 GRE config>list RC4 Cipher...: enabled End-to-End Checksumming...: enabled Tunnel identification key..: enabled [5] Drop Out-of-Order Datagrams: disabled tnip1 GRE config> RC4 Cipher: indica si se encuentra habilitado el cifrado RC4. End-to-End Checksumming: indica si se encuentra habilitado el checksum extremo a extremo. Tunnel identification key: identificador de túnel (si se ha habilitado). Drop Out-of-Order Datagrams: descartar datagramas recibidos fuera de orden SEQUENCE-DATAGRAMS Habilita la opción de asegurar orden en datagramas entrantes. Habilitando esta opción el router comprueba el número de secuencia incluido en la cabecera GRE y descarta aquellos paquetes que lleguen fuera de orden. Por defecto, el túnel GRE tiene deshabilitada esta opción. Para deshabilitar el número de secuencia se utiliza NO SEQUENCE-DATAGRAMS. Ejemplo: tnip1 GRE config>sequence-datagrams? <cr> tnip1 GRE config> tnip1 GRE config>sequence-datagrams tnip1 GRE config> ROUTER TELDAT Configuración Dynamic Multipoint II - 24

28 4. Configuración del protocolo NHRP En este apartado se describen los comandos de configuración del protocolo NHRP. Para acceder al entorno de configuración de NHRP, se debe introducir NETWORK <interfaz TNIP> : *P 4 Config>NETWORK tnip1 -- IP Tunnel Net Configuration -- nhrp? authentication Authentication string enable Enable NHRP protocol holdtime Advertised holdtime list List NHRP protocol's configuration map Map dest IP addresses to NBMA addresses nhs Specify a next hop server rate-limit Rate limit NHRP traffic record Enable NHRP transit record extensions registration Change registration mode responder Responder interface server-only Disable NHRP requests use Minimum use for sending requests Para introducir un comando NHRP este debe ir precedido de la palabra NHRP de la siguiente forma NHRP <comando>. Una vez que se ha accedido al menú de configuración del interfaz túnel IP, los comandos disponibles del submenú NHRP son los que se describen a continuación: Comando Función? (AYUDA) Lista los comandos u opciones disponibles. AUTHENTICATION Específica la palabra de autenticación. ENABLE Habilita el protocolo NHRP. HOLDTIME Tiempo de validez de la información de siguiente salto que se envíe por NHRP. LIST Muestra los parámetros configurados. MAP Crea una entrada estática en la caché de NHRP. NHS Específica la dirección privada de un Next Hop Server (NHS) RATE-LIMIT Permite especificar una tasa de transferencia máxima de paquetes NHRP. RECORD Habilita las NHRP Transit Record Extensions REGISTRATION Cambia el modo de registrarse en un NHS permitiendo entradas múltiples. RESPONDER Especifica el interfaz que responde a las peticiones NHRP. SERVER-ONLY Deshabilita la generación de paquetes de tipo Resolution Request y la caché. USE Cantidad mínima de paquetes que generan el establecimiento de un túnel AUTHENTICATION Este comando permite introducir una palabra de configuración de hasta 8 caracteres. La palabra de configuración sirve para evitar que equipos que no tengan configurada la misma palabra de configuración puedan comunicarse a través de NHRP. Por esta razón todos los equipos que vayan a formar parte de la misma red y que vayan a intercambiar información por NHRP deben tener ROUTER TELDAT Configuración Dynamic Multipoint II - 25

29 configurada la misma palabra de autenticación. Por defecto no hay configurada ninguna palabra y por tanto la autenticación está desactivada. Ejemplo: NHRP AUTHENTICATION? <1..8 chars> Authentication word NHRP AUTHENTICATION teldat 4.2. ENABLE Este comando habilita el protocolo NHRP en el interfaz TNIP correspondiente. El ejemplo habilita el protocolo NHRP en el interfaz tnip1. Ejemplo: NHRP ENABLE? <cr> NHRP ENABLE En configuración dinámica después de hacer un no nhrp enable se debe hacer un shutdown del interfaz TNIP y a continuación un no shutdown del mismo. De esta forma se vuelve a levantar el interfaz TNIP y levanta a su vez el protocolo NHRP HOLDTIME Este comando permite especificar el tiempo durante el que se consideran válidas las direcciones que el router proporciona en las respuestas positivas a peticiones NHRP. El valor por defecto es 60 minutos. El tiempo se especifica en segundos y debe estar comprendido entre 1 y segundos. Ejemplo: NHRP HOLDTIME? < > seconds NHRP HOLDTIME LIST Muestra la configuración del protocolo NHRP. NHRP LIST? <cr> ROUTER TELDAT Configuración Dynamic Multipoint II - 26

30 Ejemplo: NHRP LIST NHRP protocol: enabled Multicast NBMA: Destination ip: Destination NBMA: NHS: Authentication word: teldat Holding time: 300 seconds Max packet count: 100 packets Rate interval: 1 seconds Responder interface: internal Minimum packets for request: 1 packets Record extensions: ON Registration no unique: OFF Server only mode: OFF Server no caching: OFF NHRP protocol: indica si se encuentra habilitado el protocolo NHRP. Multicast NBMA: dirección IP pública a la que se enviarán paquetes multicast. Destination ip: dirección IP privada del destino de un túnel estático. Destination NBMA: dirección IP pública del destino de un túnel estático. NHS: dirección IP privada del Next Hop Server. Authentication word: palabra de autenticación del protocolo. Holding time: Tiempo de validez de la información de siguiente salto que se envíe por NHRP. Max packet count: máximo número de paquetes NHRP que se pueden transmitir en un rate interval. Rate interval: intervalo de tiempo para enviar el número de paquetes de max packet count. Responder interface: interfaz de respuesta a las peticiones NHRP. Minimum packets for request: mínimo número de consultas a NHRP antes de enviar un paquete de Resolution Request. Record extensions: indica si están activadas las Transit Record Extensions. Registration no unique: indica si está activado el modo de registro no-unique. Server only mode: indica si está activado el modo server-only. Server no caching: indica si está activado el modo no-caching (cache deshabilitada) MAP El comando MAP tiene dos funcionalidades: Permite crear entradas estáticas en la cache del protocolo NHRP. En estas entradas se guarda la correspondencia entre las direcciones públicas y privadas de los equipos de la red. Permite configurar las direcciones a través de las cuales se enviarán paquetes multicast. Por ejemplo los paquetes generados por protocolos de routing como RIP. Para seleccionar una u otra funcionalidad basta con poner o no poner la palabra MULTICAST a continuación del comando MAP. Para configurar una entrada estática en la cache, debemos poner a continuación del comando MAP la dirección IP privada, la máscara de subred y por último la dirección IP pública que se corresponde con ROUTER TELDAT Configuración Dynamic Multipoint II - 27

31 la dirección IP privada. Se debe configurar una entrada estática en cada equipo con las direcciones del NHS que le da servicio. De esta forma queda establecido permanentemente un túnel entre el spoke y el hub (NHS). Ejemplo 1: NHRP MAP? multicast Multicast mode <a.b.c.d> Point to point mode, destination ip address NHRP MAP MULTICAST? dynamic Dynamic multicast mode <a.b.c.d> Destination NBMA ip address NHRP MAP Para configurar los destinos de los paquetes multicast existen dos casos. El primero es que vayamos a ser un Next Hop Server (NHS) y por tanto vayamos a recibir peticiones de registro de otros equipos. En este caso las entradas serán dinámicas y no conoceremos a priori a quién debemos enviar los paquetes multicast. Utilizaremos la opción DYNAMIC para hacer que el equipo cree una entrada dinámica con cada equipo que se registre y de esta forma los paquetes multicast se envíen a todos los equipos registrados en el NHS. Ejemplo 2: NHRP MAP MULTICAST DYNAMIC La segunda opción es que seamos un cliente de NHRP. Configurados de este modo, lo que tiene sentido es que enviemos los paquetes multicast a el o los NHS s que tengamos configurados para que ellos los distribuyan por el resto de la red. A la opción MULTICAST sigue en este caso la dirección pública del NHS al que enviaremos los paquetes multicast. Ejemplo 3: NHRP MAP MULTICAST Se pueden crear tantas entradas como se quieran utilizando el comando MAP repetidas veces con distintas direcciones NHS Este comando configura la dirección privada del Next Hop Server que da servicio al equipo. Se pueden configurar varias direcciones de distintos NHS s con solo ejecutar el comando varias veces con distintas direcciones IP. El NHS principal es el primero que se haya configurado y es a este al que se manden las peticiones NHRP siempre que esté activo. El equipo se registra en todos los NHS s que tenga configurados. NHRP NHS? <a.b.c.d> Next hop server ip address ROUTER TELDAT Configuración Dynamic Multipoint II - 28

32 Ejemplo: NHRP NHS RATE-LIMIT Este comando permite cambiar la tasa de transferencia máxima de paquetes NHRP configurando el número máximo de paquetes y el intervalo en el que se pueden mandar. Por defecto la máxima tasa de transferencia de paquetes NHRP es de 100 paquetes cada segundo. Ejemplo: NHRP RATE-LIMIT? < > Max packet count NHRP RATE-LIMIT 20? < > Time interval in seconds NHRP RATE-LIMIT En el ejemplo se configura el equipo de forma que la tasa de transferencia máxima es de 20 paquetes cada 10 segundos. Los valores, tanto del número máximo de paquetes como del intervalo de tiempo deben estar comprendidos entre 1 y RECORD Este comando activa el envío de las Transit Record Extensions en los paquetes NHRP, tanto la Forward como la Reverse. Estas extensiones permiten conocer los NHS s a través de los cuales ha viajado el paquete NHRP y tienen su utilidad a la hora de depurar. Cuando están activas permiten al protocolo detectar la existencia de bucles en la red. Por defecto están desactivadas. Ejemplo: NHRP RECORD? <cr> NHRP RECORD 4.9. REGISTRATION Por defecto los equipos se registran en los NHS s de forma única, incluyendo una única entrada con información de siguiente salto (CIE) en el paquete de registro y con el bit Uniqueness activado. Este comando permite deshabilitar este bit en los paquetes de registro. NHRP REGISTRATION? no-unique Turns off nhrp unique flag ROUTER TELDAT Configuración Dynamic Multipoint II - 29

33 Ejemplo: NHRP REGISTRATION NO-UNIQUE RESPONDER Cuando un equipo realiza una petición NHRP y quiere conocer quién es el equipo que genera la respuesta, debe incluir en el paquete la Responder Extension. El equipo que responde rellena la extensión con los datos de la dirección IP primaria del interfaz, por defecto el interfaz TNIP por el que le ha llegado el paquete de petición. El comando RESPONDER permite elegir el interfaz con el que se rellena la Responder Extension. Ejemplo: NHRP RESPONDER? <interface> Interface name NHRP RESPONDER serial0/ SERVER-ONLY Para poder hacer que un equipo se comporte únicamente como servidor y que no genere peticiones NHRP, sino que se limite a dar respuesta a las peticiones que le llegan, existe este comando. Ejemplo 1: NHRP SERVER-ONLY? <cr> non-caching Disable NHRP cache memory NHRP SERVER-ONLY También se le puede desactivar la cache de forma que no guarde información en ella mediante la opción NON-CACHING. Esta opción se suele utilizar en un router que está situado entre otros dos. Ejemplo 2: NHRP SERVER-ONLY NON-CACHING USE Este comando permite especificar al equipo que espere un número de paquetes antes de realizar una consulta a través de NHRP para conocer y establecer un mejor camino para los paquetes. De esta forma podemos evitar que se establezcan túneles en trayectos con escaso tráfico y que no justifiquen su creación. El comando irá seguido por el número deseado de peticiones a NHRP antes de que el protocolo envíe una petición de resolución a su NHS. ROUTER TELDAT Configuración Dynamic Multipoint II - 30

34 Ejemplo: NHRP USE? < > Minimum number of packets to send a NHRP request NHRP USE 5 En el ejemplo hasta que no se hayan realizado 5 peticiones a NHRP, no se generará un paquete NHRP de petición de resolución. Los cinco paquetes no se pierden y son enviados, pero por un camino menos eficiente que el que se puede establecer conociendo la información de siguiente salto. El numero de paquetes debe estar comprendido entre 1 y El valor por defecto es 1. ROUTER TELDAT Configuración Dynamic Multipoint II - 31