• No se han encontrado resultados

Router Teldat. Dynamic Multipoint VPN s

N/A
N/A
Protected

Academic year: 2021

Share "Router Teldat. Dynamic Multipoint VPN s"

Copied!
52
0
0

Texto completo

(1)

Router Teldat

Dynamic Multipoint VPN’s

Doc. DM768 Rev. 10.70

(2)

Í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

(3)

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 -

(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 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 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

VPN’s I - 2

Doc.DM768

(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.

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

(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.

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

(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.

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

(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

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

(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:

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

(11)

• 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

(12)

• 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

(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

VPN’s I - 10

Doc.DM768

(14)

• 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

(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

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

(16)

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

(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 -- 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

(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 -- 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

(20)

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

(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.

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

(22)

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

(23)

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

(24)

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

(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 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

(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”.

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

(27)

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

(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 -- 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

(29)

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

(30)

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

(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).

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

(32)

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

(33)

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

(34)

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

(35)

Capítulo 3

Monitorización

(36)

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

(37)

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

(38)

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

(39)

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

(40)

Capítulo 4

Ejemplos

Referencias

Documento similar

Primeros ecos de la Revolución griega en España: Alberto Lista y el filohelenismo liberal conservador español 369 Dimitris Miguel Morfakidis Motos.. Palabras de clausura

(29) Cfr. MUÑOZ MACHADO: Derecho público de las Comunidades Autóno- mas, cit., vol. Es necesario advertir que en la doctrina clásica este tipo de competencias suele reconducirse

Como asunto menor, puede recomendarse que los órganos de participación social autonómicos se utilicen como un excelente cam- po de experiencias para innovar en materia de cauces

Tras establecer un programa de trabajo (en el que se fijaban pre- visiones para las reuniones que se pretendían celebrar los posteriores 10 de julio —actual papel de los

Por PEDRO A. EUROPEIZACIÓN DEL DERECHO PRIVADO. Re- laciones entre el Derecho privado y el ordenamiento comunitario. Ca- racterización del Derecho privado comunitario. A) Mecanismos

En el capítulo de desventajas o posibles inconvenientes que ofrece la forma del Organismo autónomo figura la rigidez de su régimen jurídico, absorbentemente de Derecho público por

Cedulario se inicia a mediados del siglo XVIL, por sus propias cédulas puede advertirse que no estaba totalmente conquistada la Nueva Gali- cia, ya que a fines del siglo xvn y en