Introducción

Virtual Connect utiliza una arquitectura de cabecera de dos niveles, donde el enrutamiento y los planos de control GRE son proporcionados por un dispositivo y el plano de control IPSec es proporcionado por otro.

Al finalizar el Conexión virtual conectividad, se crearán dos túneles GRE sobre IPSec entre la red empresarial del cliente y los centros de datos de Cisco de instancia dedicada. Uno para cada centro de datos redundante dentro de la región respectiva. Los elementos de red adicionales necesarios para el emparejamiento son intercambiados por el socio o el cliente a Cisco a través del formulario de activación de Control Hub Virtual Connect.

La Figura 1 muestra un ejemplo del modelo de implementación de Virtual Connect para la opción de 2 concentradores en el lado del cliente.

Virtual Connect: VPN es un diseño de concentrador, en el que los sitios concentradores del cliente están conectados a DC1 y DC2 de los centros de datos de la instancia dedicada dentro de una región en particular.

Se recomiendan dos sitios de concentrador para una mejor redundancia, pero un sitio de concentrador con dos túneles también es un modelo de implementación compatible.

El ancho de banda por túnel está limitado a 250 Mbps.

Los sitios remotos del Cliente dentro de la misma región tendrían que volver a conectarse a los sitios del Hub a través de la WAN del Cliente y no es responsabilidad de Cisco por esa conectividad.

Se espera que los socios trabajen en estrecha colaboración con los clientes, asegurando que se elija la ruta más óptima para la región de servicio 'Virtual Connect'.

La Figura 2 muestra las regiones de emparejamiento de la conectividad de la nube de la instancia dedicada.

El enrutamiento para el complemento Virtual Connect se implementa mediante BGP externo (eBGP) entre la Instancia dedicada y el Equipo de las instalaciones del cliente (CPE). Cisco anunciará su red respectiva para cada DC redundante dentro de una región al CPE del cliente y el CPE debe anunciar una ruta predeterminada a Cisco.

• Cisco mantiene y asigna

  • Direccionamiento IP de interfaz de túnel (enlace transitorio para enrutamiento) Cisco asigna desde un espacio de direcciones compartido designado (no enrutable públicamente)

  • Dirección de destino de transporte de túnel (lado de Cisco)

  • Números de sistemas autónomos privados (ASN) para la configuración de enrutamiento BGP del cliente

    • Cisco asigna desde el rango de uso privado designado: 64512 a 65534

• eBGP utilizado para intercambiar rutas entre la instancia dedicada y el CPE

  • Cisco dividirá la red / 24 asignada en 2/25 una para cada DC en la región respectiva

  • En Virtual Connect, Cisco anuncia cada red / 25 a CPE a través de los respectivos túneles VPN de punto a punto (enlace transitorio)

  • El CPE debe configurarse con los vecinos eBGP adecuados. Si usa un CPE, se usarán dos vecinos eBGP, uno apuntando a cada túnel remoto. Si utiliza dos CPE, cada CPE tendrá un vecino eBGP que se pondrá en contacto con el túnel remoto único para el CPE.

  • El lado de Cisco de cada túnel GRE ( IP de interfaz de túnel) se configura como el vecino BGP en el CPE

  • Se requiere CPE para anunciar una ruta predeterminada en cada uno de los túneles

  • CPE es responsable de redistribuir, según sea necesario, las rutas aprendidas dentro de la red empresarial del cutomer.

• En condiciones de falla de enlace sin falla, un solo CPE tendrá dos túneles activos / activos. Para dos nodos de CPE, cada CPE tendrá un túnel activo y ambos nodos de CPE deben estar activos y pasar tráfico. En un escenario sin fallos, el tráfico debe dividirse en dos túneles que vayan a los destinos correctos / 25; si uno de los túneles se cae, el túnel restante puede transportar el tráfico de ambos. En tal escenario de falla, cuando la red / 25 está inactiva, la red / 24 se utiliza como ruta de respaldo. Cisco enviará el tráfico del cliente a través de su WAN interna hacia el DC que perdió la conectividad.

La negociación del túnel IPsec implica dos fases, la fase IKEv2 y la fase IPsec. Si la negociación de la fase IKEv2 no se completa, no hay inicio de una segunda fase IPsec. Primero, ejecute el comando "show crypto ikev2 sa" (en el equipo de Cisco ) o un comando similar en el equipo de terceros para verificar si la sesión de IKEv2 está activa. Si la sesión de IKEv2 no está activa, las posibles razones podrían ser:

• El tráfico interesante no activa el túnel IPsec.

• La lista de acceso al túnel IPsec está mal configurada.

• No hay conectividad entre el cliente y la IP del punto final del túnel IPsec de la instancia dedicada.

• Los parámetros de la sesión IKEv2 no coinciden entre el lado de la instancia dedicada y el lado del cliente.

• Un firewall está bloqueando los paquetes IKEv2 UDP .

Primero, verifique los registros de IPsec para ver si hay mensajes que muestren el progreso de la negociación del túnel IKEv2. Los registros pueden indicar dónde hay un problema con la negociación IKEv2. La falta de mensajes de registro también puede indicar que la sesión IKEv2 no se está activando.

Si los mensajes de registro no muestran ninguna actividad de negociación para la fase IKEv2, es posible que se necesite una captura de paquete .

Es posible que el lado de la instancia dedicada no siempre comience el intercambio de IKEv2 y, en ocasiones, se espere que el lado del CPE del cliente sea el iniciador. Compruebe la configuración del lado de CPE para los siguientes requisitos previos para el inicio de la sesión de IKEv2: Compruebe si hay una lista de acceso criptográfico IPsec para el tráfico GRE (protocolo 50) desde la IP de transporte del túnel CPE a la IP de transporte del túnel de la instancia dedicada. Asegúrese de que la interfaz del túnel GRE esté habilitada para los keepalives de GRE; si el equipo no es compatible con los keepalives de GRE, se notificará a Cisco porque los keepalives de GRE se habilitarán en el lado de la instancia dedicada de forma predeterminada. Asegúrese de que BGP esté habilitado y configurado con la dirección vecina de la IP del túnel de instancia dedicada.

Cuando se configura correctamente, lo siguiente comienza el túnel IPsec y la negociación IKEv2 de la primera fase:

• GRE keepalives desde la interfaz del túnel GRE del lado del CPE a la interfaz del túnel GRE del lado de la instancia dedicada.

• Sesión TCP del vecino BGP desde el vecino BGP del lado del CPE al vecino BGP del lado de la instancia dedicada.

• Haga ping desde la dirección IP del túnel del lado del CPE a la dirección IP dirección IP del túnel del lado de la instancia dedicada.

  Ping no puede ser la IP de transporte de túnel, debe ser la IP de túnel a la IP de túnel.

Si se necesita un seguimiento de paquetes para el tráfico IKEv2, configure el filtro para UDP y el puerto 500 (cuando no hay ningún dispositivo NAT en el medio de los puntos finales IPsec) o el puerto 4500 (cuando se inserta un dispositivo NAT en el medio del IPsec). puntos finales).

Verifique que los paquetes IKEv2 UDP con el puerto 500 o 4500 se envíen y reciban desde y hacia la dirección IP de DI IPsec.

Es posible que el centro de datos de la instancia dedicada no siempre comience el primer paquete IKEv2. El requisito es que el dispositivo CPE sea capaz de iniciar el primer paquete IKEv2 hacia el lado de la instancia dedicada. Si el firewall local lo permite, intente también hacer ping a la dirección IPsec remota. Si el ping no se realiza correctamente desde la dirección IPsec local a la remota, realice un seguimiento de la ruta para ayudar y determine dónde se cae el paquete. Es posible que algunos firewalls y equipos de Internet no permitan el rastreo de rutas.

Verifique que la primera fase de IPsec (es decir, la asociación de seguridad IKEv2) esté activa antes de solucionar los problemas de la segunda fase de IPsec. Ejecute "show crypto ikev2 sa" o un comando equivalente para verificar la sesión de IKEv2. En el resultado, verifique que la sesión de IKEv2 haya estado activa durante más de unos segundos y que no esté rebotando. El tiempo de actividad de la sesión se muestra como el "Tiempo activo" de la sesión o su equivalente en la salida.

Una vez que la sesión de IKEv2 se verifique como activa y activa, investigue la sesión de IPsec. Al igual que con la sesión IKEv2, ejecute "show crypto ipsec sa" o un comando equivalente para verificar la sesión IPsec. Tanto la sesión IKEv2 como la sesión IPsec deben estar activas antes de que se establezca el túnel GRE. Si la sesión de IPsec no se muestra como activa, consulte los registros de IPsec para ver si hay mensajes de error o errores de negociación.

Algunos de los problemas más comunes que pueden surgir durante las negociaciones de IPsec son:

La configuración en el lado de CPE no coincide con el lado de la instancia dedicada, vuelva a verificar la configuración:

• Verifique que los parámetros de cifrado y autenticación coincidan con la configuración del lado de la instancia dedicada.

• Verifique la configuración de Perfect Forward Secrecy y que la configuración coincida en el lado de la instancia dedicada.

• Verifique la configuración de por vida.

• Verifique que IPsec se haya configurado en modo túnel.

• Verifique las direcciones IPsec de origen y destino.

Cuando se verifica que las sesiones IPsec e IKEv2 estén activas, los paquetes de mantenimiento del túnel GRE pueden fluir entre la instancia dedicada y los extremos del túnel CPE. Si la interfaz del túnel no muestra el estado, algunos problemas comunes son:

• El VRF de transporte de la interfaz de túnel no coincide con el VRF de la interfaz de bucle invertido (si se utiliza la configuración de VRF en la interfaz de túnel).

  Si la configuración de VRF no se utiliza en la interfaz del túnel, esta verificación se puede ignorar.

• Keepalives no está habilitado en la interfaz del túnel del lado de CPE

  Si los keepalives no son compatibles con el equipo CPE, entonces se debe notificar a Cisco para que los keepalives predeterminados en el lado de la instancia dedicada también estén deshabilitados. Si se admiten keepalives, verifique que estén habilitados.

• La máscara o la dirección IP de la interfaz del túnel no es correcta y no coincide con los valores esperados de la instancia dedicada.

• La dirección de transporte del túnel de origen o destino no es correcta y no coincide con los valores esperados de la instancia dedicada.

• Un firewall está bloqueando los paquetes GRE enviados al túnel IPsec o recibidos desde el túnel IPsec (el túnel GRE se transporta a través del túnel IPsec)

Una prueba de ping debe verificar que la interfaz del túnel local esté activa y que la conectividad con la interfaz del túnel remoto sea buena. Realice la comprobación de ping desde la IP del túnel (no la IP de transporte) a la IP del túnel remoto.

La lista de acceso criptográfico para el túnel IPsec que transporta el tráfico del túnel GRE permite que solo se crucen los paquetes GRE. Como resultado, los pings no funcionarán desde la IP de transporte de túnel a la IP de transporte de túnel remoto.

La verificación de ping da como resultado un paquete GRE que se genera desde la IP de transporte del túnel de origen a la IP de transporte del túnel de destino, mientras que la carga útil del paquete GRE (la IP interna) será la IP del túnel de origen y de destino.

Si la prueba de ping no tiene éxito y se verifican los elementos anteriores, es posible que se requiera una captura de paquete para garantizar que el ping icmp dé como resultado un paquete GRE que luego se encapsula en un paquete IPsec y luego se envía desde la dirección IPsec de origen a la dirección IPsec de destino. Los contadores de la interfaz del túnel GRE y los contadores de sesiones de IPsec también pueden ayudar a mostrar. si los paquetes de envío y recepción aumentan.

Además del tráfico de ping, la captura también debe mostrar paquetes GRE activos incluso durante el tráfico inactivo. Por último, si se configura BGP, los paquetes de mantenimiento de BGP también deben enviarse como paquetes GRE encapsulados en paquetes IPSEC y a través de la VPN.

En el lado de la instancia dedicada, se habilitan dos características para ajustar dinámicamente la MTU para paquetes de gran tamaño. El túnel GRE agrega más encabezados a los paquetes IP que fluyen a través de la sesión VPN . El túnel IPsec agrega los encabezados adicionales en la parte superior de los encabezados GRE y reducirá aún más la MTU más grande permitida en el túnel.

El túnel GRE ajusta la función MSS y la ruta del túnel GRE en la función de descubrimiento de MTU está habilitada en el lado de la instancia dedicada. Configure "ip tcp adjust-mss 1350" o un comando equivalente, así como "tunel path \ u0002mtu-discovery" o un comando equivalente en el lado del cliente para ayudar con el ajuste dinámico de la MTU del tráfico a través del túnel VPN .