Router Teldat
Dynamic Multipoint VPN’s
Doc. DM768 Rev. 10.70
ÍNDICE
Capítulo 1 Introducción ...1
1. Introducción a las redes dinámicas multipunto ... 2
1.1. ¿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 ... 3
1.2. El protocolo NHRP ... 3
1.3. Funcionamiento del protocolo NHRP ... 4
1.4. Tipos de paquete NHRP... 5
2. Referencias... 13
Capítulo 2 Configuración...14
1. Configuración de una DMVPN ... 15
2. Configuración del interfaz Túnel IP (TNIP)... 16
2.1. DESTINATION ... 17 2.2. DISABLE... 17 2.3. ENABLE... 17 2.4. ENCAPSULATION... 18 2.5. KEEPALIVE... 18 2.6. LIST ... 19 2.7. MODE... 19 2.8. NHRP... 19 2.9. NHRP-TOS ... 20 2.10. PATH-MTU-DISCOVERY... 20 2.11. QOS-PRE-CLASSIFY... 20 2.12. SOURCE... 21 2.13. VRF-ENCAP ... 21
3. Configuración del protocolo de encapsulado GRE (Generic Routing Encapsulation) ... 22
3.1. CHECKSUM ... 22 3.2. CIPHER ... 23 3.3. CIPHER-KEY... 23 3.4. KEY ... 23 3.5. LIST ... 24 3.6. SEQUENCE-DATAGRAMS ... 24
4. Configuración del protocolo NHRP ... 25
4.1. AUTHENTICATION ... 25 4.2. ENABLE... 26 4.3. HOLDTIME... 26 4.4. LIST ... 26 4.5. MAP... 27 4.6. NHS ... 28 4.7. RATE-LIMIT... 29 4.8. RECORD ... 29 4.9. REGISTRATION ... 29 4.10. RESPONDER ... 30 4.11. SERVER-ONLY... 30 4.12. USE... 30
Capítulo 3 Monitorización ...32
1. Monitorización del protocolo NHRP... 33
1.1. ? (AYUDA)... 33
1.2. CLEAR ... 33
a) CLEAR CACHE ... 33
b) CLEAR STATISTICS ... 34
1.3. LIST ... 34
Capítulo 4 Ejemplos ...37
1. Ejemplo de configuración de una DMVPN... 38
a) Escenario ... 38 b) Modo de funcionamiento... 39 c) Configuración HUB1 ... 42 d) Configuración SPOKE2 ... 44 e) Configuración Teldat1 ... 46 f) Configuración Teldat2 ... 48 - iii -
Capítulo 1
Introducción
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 DMVPN’s basadas en Routers Teldat.
La finalidad de las DMVPN’s 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 DMVPN’s 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.
Router
SPOKE1
SPOKE2
SPOKE3
HUB
Internet
Router Router Router Red privada Red privadaRed 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
VPN’s I - 2
Doc.DM768
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.
1.1. ¿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 DMVPN’s 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.
1.2. 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
VPN’s I - 3
Doc.DM768
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.
1.3. Funcionamiento del protocolo NHRP
Las DMVPN’s 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
VPN’s I - 4
Doc.DM768
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.
1.4. 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
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
AFN Protocol Type
unused
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
VPN’s I - 5
Doc.DM768
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
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.
SSTL
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
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
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
VPN’s I - 6
Doc.DM768
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:
1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
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:
1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
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:
1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
U unused
U: indica que la información que estamos registrando es única.
ROUTER TELDAT – Introducción Dynamic Multipoint
VPN’s I - 7
Doc.DM768
• Purge Request:
1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
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
VPN’s I - 8
Doc.DM768
• CIE’s (entradas de información de cliente).
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
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
VPN’s I - 9
Doc.DM768
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
VPN’s I - 10
Doc.DM768
• Parte obligatoria de un paquete de error
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Source Prot. Length Dest. Prot. Legth Flags
Error Code Error Offset
Source NBMA Address Source NBMA Subaddress
Source Protocol Address Destination Protocol Address Contents of NHRP Packet in error
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 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 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
VPN’s I - 11
Doc.DM768
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
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
reserved SPI (Security Parameter Index)
Source Address Authentication Data...
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
VPN’s I - 12
Doc.DM768
2. Referencias
RFC-2332: NBMA Next Hop Resolution Protocol (NHRP), April 1998. Dm719: Interfaz Túnel IP (TNIP).
ROUTER TELDAT – Introducción Dynamic Multipoint
VPN’s I - 13
Doc.DM768
Capítulo 2
Configuración
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 -- tnip1 config>
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:
tnip1 config>ip address 5.5.5.1 255.255.0.0 tnip1 config>
Ejemplo como interfaz no numerado:
tnip1 config>ip address unnumbered tnip1 config>
ROUTER TELDAT – Configuración Dynamic Multipoint
VPN’s II - 15
Doc.DM768
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 -- tnip1 config>?
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
exit
tnip1 config>
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
VPN’s II - 16
Doc.DM768
VRF-ENCAP Especifica parámetros de una instancia VPN Routing/Forwarding. EXIT Sale del menú de configuración de TNIP.
2.1. 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”.
Sintaxis:
tnip1 config>DESTINATION ? <a.b.c.d> Ipv4 format tnip1 config>
Ejemplo:
tnip1 config>DESTINATION 66.187.232.56 tnip1 config>
2.2. DISABLE
Deshabilita el interfaz túnel. Por defecto el interfaz túnel está deshabilitado.
Sintaxis: tnip1 config>DISABLE ? <cr> tnip1 config> Ejemplo: tnip1 config>DISABLE tnip1 config>
2.3. ENABLE
Habilita el interfaz túnel. Por defecto el interfaz túnel no se encuentra habilitado.
Sintaxis: tnip1 config>ENABLE ? <cr> tnip1 config> Ejemplo: tnip1 config>ENABLE tnip1 config>
ROUTER TELDAT – Configuración Dynamic Multipoint
VPN’s II - 17
Doc.DM768
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.
Sintaxis:
tnip1 config>ENCAPSULATION ? <cr>
tnip1 GRE config>
Ejemplo:
tnip1 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 Descripción
periodo 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 32767 segundos, y el valor por defecto 10 segundos. intentos 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”.
Sintaxis:
tnip1 config>KEEPALIVE ?
<1..32767> Keepalive period (default 10 seconds) <cr>
tnip1 config>KEEPALIVE 30 ?
<1..255> Keepalive retries (default 3 retries) <cr>
tnip1 config>
ROUTER TELDAT – Configuración Dynamic Multipoint
VPN’s II - 18
Doc.DM768
Ejemplo:
tnip1 config>KEEPALIVE 30 5 tnip1 config>
2.6. LIST
Muestra la configuración del túnel IP.
Sintaxis: tnip1 config>LIST ? <cr> tnip1 config> Ejemplo: tnip1 config>LIST
Tunnel mode: GRE (enabled)
Tunnel source 212.95.195.132, destination 66.187.232.56 QoS preclassify: disabled
Keepalive: enabled with period 10, 3 retries NHRP type of service: 25
tnip1 config>
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.
2.7. MODE
Selecciona el modo de encapsulación. Soporta GRE (Generic Routing Encapsulation) y mGre (Multipoint GRE).
Sintaxis:
tnip1 config>MODE ?
gre Generic Routing Encapsulation Protocol tnip1 config>MODE GRE ?
ip Over IP
multipoint Over IP (multipoint) <cr>
tnip1 config>
Ejemplo1:
tnip1 config>MODE GRE IP tnip1 config>
Ejemplo2:
tnip1 config>MODE GRE MULTIPOINT tnip1 config>
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
VPN’s II - 19
Doc.DM768
Sintaxis:
tnip1 config>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 tnip1 config>
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.
Sintaxis:
tnip1 config>NHRP-TOS ?
<0..255> IPv4 type of service value tnip1 config>
Ejemplo:
tnip1 config>NHRP-TOS 25 tnip1 config>
2.10. 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.
Sintaxis: tnip1 config>PATH-MTU-DISCOVERY ? <cr> tnip1 config> Ejemplo: tnip1 config>PATH-MTU-DISCOVERY tnip1 config>
2.11. 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
VPN’s II - 20
Doc.DM768
Para deshabilitar este parámetro se utiliza “NO QOS-PRE-CLASSIFY”. Sintaxis: tnip1 config>QOS-PRE-CLASSIFY ? <cr> tnip1 config> Ejemplo: tnip1 config>QOS-PRE-CLASSIFY tnip1 config>
2.12. 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.
Sintaxis:
tnip1 config>SOURCE ?
<a.b.c.d> Tunnel source address <interface> Tunnel source interface tnip1 config> Ejemplo1: tnip1 config>SOURCE 212.95.195.132 tnip1 config> Ejemplo2: tnip1 config>SOURCE ppp1 tnip1 config>
2.13. 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.
Sintaxis:
tnip1 config>VRF-ENCAP ?
<1..32 chars> VPN Routing/Forwarding instance name tnip1 config>
Ejemplo:
tnip1 config>VRF-ENCAP thisIsAnExample tnip1 config>
ROUTER TELDAT – Configuración Dynamic Multipoint
VPN’s II - 21
Doc.DM768
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 End-to-end checksum cipher RC4 Ciphering cipher-key Cipher key
key ID key for the tunnel interface list Show GRE configuration
no
sequence-datagrams Drop out-of-order datagrams exit
GRE config>
Los comandos disponibles son los siguientes:
Comando Función
CHECKSUM Habilita el checksum extremo-a-extremo (GRE). CIPHER Habilita el cifrado RC4 en el túnel GRE.
CIPHER-KEY Configura la clave del cifrado RC4. KEY Configura el identificador de túnel. LIST Muestra los parámetros configurados.
SEQUENCE-DATAGRAMS Descartar datagramas recibidos fuera de orden.
3.1. 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”.
Sintaxis:
tnip1 GRE config>CHECKSUM ? <cr>
tnip1 GRE config>
ROUTER TELDAT – Configuración Dynamic Multipoint
VPN’s II - 22
Doc.DM768
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”.
Sintaxis:
tnip1 GRE config>CIPHER ? <cr>
tnip1 GRE config>
Ejemplo:
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”.
Sintaxis:
tnip1 GRE config>CIPHER-KEY ? <word> Text
tnip1 GRE config>
Ejemplo:
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 4294967295 (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
VPN’s II - 23
Doc.DM768
Sintaxis:
tnip1 GRE config>KEY ?
<0..4294967295> Value in the specified range tnip1 GRE config>
Ejemplo:
tnip1 GRE config>KEY 5 tnip1 GRE config>
3.5. LIST
Muestra la configuración del protocolo GRE.
Sintaxis:
tnip1 GRE config>LIST ? <cr>
tnip1 GRE config>
Ejemplo:
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..
3.6. 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”.
Sintaxis:
tnip1 GRE config>SEQUENCE-DATAGRAMS ? <cr>
tnip1 GRE config>
Ejemplo:
tnip1 GRE config>SEQUENCE-DATAGRAMS tnip1 GRE config>
ROUTER TELDAT – Configuración Dynamic Multipoint
VPN’s II - 24
Doc.DM768
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 -- tnip1 config>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 tnip1 config>
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.
4.1. 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
VPN’s II - 25
Doc.DM768
configurada la misma palabra de autenticación. Por defecto no hay configurada ninguna palabra y por tanto la autenticación está desactivada.
Sintaxis:
tnip1 config>NHRP AUTHENTICATION ? <1..8 chars> Authentication word tnip1 config>
Ejemplo:
tnip1 config>NHRP AUTHENTICATION teldat tnip1 config>
4.2. ENABLE
Este comando habilita el protocolo NHRP en el interfaz TNIP correspondiente. El ejemplo habilita el protocolo NHRP en el interfaz tnip1.
Sintaxis:
tnip1 config>NHRP ENABLE ? <cr>
tnip1 config>
Ejemplo:
tnip1 config>NHRP ENABLE tnip1 config>
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.
4.3. 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 65535 segundos.
Sintaxis:
tnip1 config>NHRP HOLDTIME ? <1..65535> seconds tnip1 config>
Ejemplo:
tnip1 config>NHRP HOLDTIME 300 tnip1 config>
4.4. LIST
Muestra la configuración del protocolo NHRP.
Sintaxis:
tnip1 config>NHRP LIST ? <cr>
tnip1 config>
ROUTER TELDAT – Configuración Dynamic Multipoint
VPN’s II - 26
Doc.DM768
Ejemplo:
tnip1 config>NHRP LIST NHRP protocol: enabled Multicast NBMA: 10.1.1.2
Destination ip: 1.1.1.1 255.255.255.255 Destination NBMA: 10.1.1.2
NHS: 1.1.1.1
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 tnip1 config>
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).
4.5. 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
VPN’s II - 27
Doc.DM768
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).
Sintaxis:
tnip1 config>NHRP MAP ? multicast Multicast mode
<a.b.c.d> Point to point mode, destination ip address tnip1 config>NHRP MAP MULTICAST ?
dynamic Dynamic multicast mode <a.b.c.d> Destination NBMA ip address tnip1 config>
Ejemplo 1:
tnip1 config>NHRP MAP 1.1.1.1 255.255.255.255 10.1.1.2 tnip1 config>
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:
tnip1 config>NHRP MAP MULTICAST DYNAMIC tnip1 config>
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:
tnip1 config>NHRP MAP MULTICAST 10.1.1.2 tnip1 config>
Se pueden crear tantas entradas como se quieran utilizando el comando MAP repetidas veces con distintas direcciones.
4.6. 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.
Sintaxis:
tnip1 config>NHRP NHS ?
<a.b.c.d> Next hop server ip address tnip1 config>
ROUTER TELDAT – Configuración Dynamic Multipoint
VPN’s II - 28
Doc.DM768
Ejemplo:
tnip1 config>NHRP NHS 1.1.1.2 tnip1 config>
4.7. 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.
Sintaxis:
tnip1 config>NHRP RATE-LIMIT ? <1..65535> Max packet count tnip1 config> NHRP RATE-LIMIT 20 ? <1..65535> Time interval in seconds tnip1 config>
Ejemplo:
tnip1 config>NHRP RATE-LIMIT 20 10 tnip1 config>
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 65535.
4.8. 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.
Sintaxis:
tnip1 config>NHRP RECORD ? <cr>
tnip1 config>
Ejemplo:
tnip1 config>NHRP RECORD tnip1 config>
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.
Sintaxis:
tnip1 config>NHRP REGISTRATION ?
no-unique Turns off nhrp unique flag tnip1 config>
ROUTER TELDAT – Configuración Dynamic Multipoint
VPN’s II - 29
Doc.DM768
Ejemplo:
tnip1 config>NHRP REGISTRATION NO-UNIQUE tnip1 config>
4.10. 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.
Sintaxis:
tnip1 config>NHRP RESPONDER ? <interface> Interface name tnip1 config>
Ejemplo:
tnip1 config>NHRP RESPONDER serial0/2 tnip1 config>
4.11. 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.
Sintaxis:
tnip1 config>NHRP SERVER-ONLY ? <cr>
non-caching Disable NHRP cache memory tnip1 config>
Ejemplo 1:
tnip1 config>NHRP SERVER-ONLY tnip1 config>
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:
tnip1 config>NHRP SERVER-ONLY NON-CACHING tnip1 config>
4.12. 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
VPN’s II - 30
Doc.DM768
Sintaxis:
tnip1 config>NHRP USE ?
<1..65535> Minimum number of packets to send a NHRP request tnip1 config>
Ejemplo:
tnip1 config>NHRP USE 5 tnip1 config>
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 65535. El valor por defecto es 1.
ROUTER TELDAT – Configuración Dynamic Multipoint
VPN’s II - 31
Doc.DM768
Capítulo 3
Monitorización
1. Monitorización del protocolo NHRP
Para acceder al menú de monitorización asociado al protocolo NHRP se debe introducir el comando “PROTOCOL NHRP” en el menú de monitorización (+).
*P 3
+PROTOCOL NHRP
-- NHRP protocol monitor -- nhrp+
También se puede acceder desde el menú de monitorización del interfaz TNIP escribiendo “NHRP
<opción>” donde opción es la opción deseada.
*P 3
+NETWORK TNIP1
-- TNIP protocol monitor -- tnip1+NHRP <opción>
Una vez que se ha accedido al entorno de monitorización del protocolo NHRP, se pueden introducir los comandos que se describen a continuación:
Comando Función
? (AYUDA) Lista los comandos u opciones disponibles
CLEAR Permite borrar entradas de la caché o los estadísticos.
LIST Muestra información de monitorización del protocolo NHRP.
1.1. ? (AYUDA)
Este comando se utiliza para listar los comandos válidos en el nivel donde se está programando el router. Se puede también utilizar este comando después de un comando específico para listar las opciones disponibles.
Sintaxis:
tnip1+NHRP ?
clear Permit you to delete the cache entries or the statistics list Display monitoring information on the NHRP protocol tnip1+
1.2. CLEAR
El comando CLEAR se utiliza para poner a cero los contadores de los estadísticos y para borrar entradas de la cache.
Sintaxis:
tnip1+NHRP CLEAR ?
cache Delete the NHRP protocol cache entries statistics Zeroize the NHRP protocol statistic counters tnip1+
a) CLEAR CACHE
Borra entradas de la cache del protocolo NHRP. Las entradas estáticas no se pueden borrar ya que han sido introducidas por configuración mediante el comando MAP.
ROUTER TELDAT – Monitorización Dynamic Multipoint
VPN’s III - 33
Doc.DM768
Hay dos formas posibles de borrar entradas en la cache, borrar la cache completa o borrar una entrada concreta de la cache. Para borrar una entrada concreta de la cache hay que introducir la dirección IP privada que la identifica y la máscara que la acompaña.
Ejemplo 1: Borrado completo de la cache
tnip1+NHRP CLEAR CACHE ALL tnip1+
Ejemplo 2: Borrado de una línea de cache
tnip1+NHRP CLEAR CACHE ADDRESS 1.1.1.3 255.255.255.255 tnip1+
b) CLEAR STATISTICS
Pone a cero los contadores de los estadísticos del protocolo NHRP.
Ejemplo:
tnip1+NHRP CLEAR STATISTICS tnip1+
1.3. LIST
Muestra información acerca del estado del protocolo NHRP, así como estadísticos relevantes.
Sintaxis:
tnip1+NHRP LIST ?
cache Display the NHRP protocol cache content nhs Display the state of the NHSs configured
state Display information on the state of the NHRP protocol statistics Display the NHRP protocol statistics
tnip1+
• LIST CACHE
Muestra el contenido de la cache del protocolo NHRP para el interfaz actual. Se puede mostrar la información de la cache completa o según los tipos de entrada sólo las entradas dinámicas, estáticas o las incompletas. También se puede mostrar la información reducida o detallada incluyendo los equipos a los que se les ha proporcionado la información que contiene la entrada como respuesta a una petición NHRP.
Sintaxis:
tnip1+NHRP LIST CACHE ?
all Display all types of cache entries dynamic Display dynamic cache entries incomplete Display incomplete cache entries static Display static cache entries tnip1+NHRP LIST CACHE ALL ?
detail Display all types of cache entries in a detailed form reduced Display all types of cache entries in a reduced form tnip1+
ROUTER TELDAT – Monitorización Dynamic Multipoint
VPN’s III - 34
Doc.DM768
Ejemplo 1: Caso de un NHS
tnip1+NHRP LIST CACHE ALL DETAIL
1.1.1.2 255.255.255.255, tnip1 08/26/05, 16:50:57 expire 0h 3m 30s Type: dynamic Flags: authoritative unique registered
NBMA address: 10.1.2.2
Requester: 1.1.1.3 Request ID: 1775
1.1.1.3 255.255.255.255, tnip1 08/26/05, 16:51:51 expire 0h 4m 24s Type: dynamic Flags: authoritative unique registered used NBMA address: 10.1.3.2
Requester: 1.1.1.2 Request ID: 263 tnip1+
En la primera línea se muestra la dirección privada de la entrada, la máscara, el interfaz al que pertenece la entrada de cache, la fecha y hora de creación de la entrada y el tiempo que falta para que la entrada caduque y sea considerada inválida (expired) y borrada de la cache, si no se refresca antes de que esto suceda.
En la segunda línea se muestra el tipo de entrada, puede ser dynamic, static o incomplete. A continuación los Flags de NHRP que indican cómo es el tipo de información de la entrada y su estado.
En la tercera línea se muestra la dirección pública o dirección de siguiente salto.
En las líneas siguientes aparece la dirección IP privada de los equipos a los que se les ha proporcionado la información de la entrada y el request ID del paquete de petición de resolución NHRP.
Ejemplo 2: Caso de un NHC
tnip1+NHRP LIST CACHE ALL DETAIL
1.1.1.3 255.255.255.255, tnip1 08/26/05, 17:06:50 expire 0h 4m 6s Type: dynamic Flags: router used
NBMA address: 10.1.3.2
1.1.1.1 255.255.255.255, tnip1 08/26/05, 09:47:08 never expire Type: static Flags: authoritative used
NBMA address: 10.1.1.2 tnip1+
Ejemplo 3: Caso de un NHC
tnip1+ NHRP LIST CACHE DYNAMIC REDUCED
1.1.1.3 255.255.255.255, tnip1 08/26/05, 17:06:50 expire 0h 3m 11s Type: dynamic Flags: router
NBMA address: 10.1.3.2 tnip1+
• LIST NHS
Muestra el estado de los NHS’s configurados para el equipo y el interfaz. También muestra el tiempo que resta para que se envíe un nuevo paquete NHRP de petición de registro al NHS. Cada NHS se reconoce por su dirección privada y su estado puede ser alive, not alive, alive and expecting reg reply, not alive and expecting reg reply. Un NHS se considera not alive si no contesta a una petición de registro. En cuanto se recibe una respuesta positiva a una petición de registro el NHS se considera alive.
ROUTER TELDAT – Monitorización Dynamic Multipoint
VPN’s III - 35
Doc.DM768
Ejemplo 1:
tnip1+NHRP LIST NHS
Interface tnip1:
1.1.1.1 alive (next reg req in 0h 1m 27s)
tnip1+
Ejemplo 2:
tnip1+NHRP LIST NHS
Interface tnip1:
1.1.1.1 not alive and expecting reg reply (next reg req in 0h 0m 6s)
tnip1+
• LIST STATE
Muestra información sobre el estado del protocolo NHRP para el interfaz. Indica si está habilitado y si el protocolo está levantado.
Ejemplo:
tnip1+NHRP LIST STATE
Interface tnip1 is UP and ENABLED
tnip1+
• LIST STATISTICS
Muestra estadísticos del protocolo NHRP para el interfaz actual. Indica el número de paquetes recibidos y enviados de cada tipo de paquete NHRP y los totales de paquetes enviados y recibidos.
Ejemplo:
tnip1+NHRP LIST STATISTICS
Interface tnip1: Sent: Resolution Request: 21 Resolution Reply: 0 Register Request: 1745 Register Reply: 0 Purge Request: 0 Purge Reply: 0 Error: 0 Total sent: 1766 Received: Resolution Request: 0 Resolution Reply: 21 Register Request: 0 Register Reply: 1736 Purge Request: 0 Purge Reply: 0 Error: 0 Total received: 1757 tnip1+
ROUTER TELDAT – Monitorización Dynamic Multipoint
VPN’s III - 36
Doc.DM768