Virtual Connect utiliza una arquitectura de cabecera de doble nivel, donde un dispositivo proporciona los planos de control de enrutamiento y GRE y otro el plano de control de IPSec.

Una vez finalizada la conectividad Virtual Connect, se crearán dos túneles GRE sobre IPSec entre la red empresarial del Cliente y los centros de datos de Cisco de Dedicated Instance. Uno a cada centro de datos redundante dentro de la Región respectiva. El socio o el cliente intercambian los elementos de red adicionales necesarios para el emparejamiento con Cisco a través del formulario de activación de la conexión virtual de Control Hub.

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.

Conexión virtual - VPN es un diseño de hub, en el que los sitios de hub del cliente están conectados a DC1 y DC2 de los centros de datos de Dedicated Instance dentro de una región en particular.

Se recomiendan dos sitios Hub para mejorar la redundancia, pero el sitio One Hub 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, garantizando que se elija la ruta más óptima para la región de servicio «Conexión virtual».

La Figura 2 muestra las regiones de emparejamiento de conectividad en la nube de instancias dedicadas.

El enrutamiento para el complemento Virtual Connect se implementa mediante BGP externo (eBGP) entre Dedicated Instance y el equipo local 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 compartidas designado (no enrutable públicamente)

  • Dirección de desitinación del transporte en túnel (lado de Cisco)

  • Números de sistema autónomo privado (ASN) para la configuración de enrutamiento BGP del cliente

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

• eBGP utilizado para intercambiar rutas entre Dedicated Instance y CPE

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

  • En la conexión virtual, Cisco vuelve a anunciar cada red /25 a CPE a través de los respectivos túneles de VPN punto a punto (enlace transitorio)

  • El CPE debe configurarse con los vecinos de eBGP apropiados. Si se utiliza un CPE, se utilizarán dos vecinos de eBGP, uno apuntando a cada túnel remoto. Si utiliza dos CPE, cada CPE tendrá un vecino de eBGP poniéndose al túnel remoto único para el CPE.

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

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

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

• En condición de fallo de enlace sin fallo, un único 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 el escenario de no fallo, el tráfico debe dividirse en dos túneles que vayan a los destinos correctos /25; si uno de los túneles cae, el túnel restante puede transportar el tráfico para ambos. En este escenario de fallo, 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 consta de dos fases, la fase IKEv2 y la fase IPsec. Si la negociación de la fase IKEv2 no se completa, no se iniciará una segunda fase IPsec. En primer lugar, emita el comando "show crypto ikev2 sa" (en equipos de Cisco) o un comando similar en equipos 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 de IPsec está mal configurada.

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

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

• Un firewall está bloqueando los paquetes UDP IKEv2.

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

Algunos errores comunes con la negociación de IKEv2 son:

• La configuración de IKEv2 en el lado de CPE no coincide con el lado de Cisco; vuelva a comprobar la configuración mencionada:

  • Compruebe que la versión de IKE es la versión 2.

  • Verifique que los parámetros de cifrado y autenticación coincidan con el cifrado esperado en el lado de Dedicated Instance.

    Cuando el cifrado "GCM" está en uso, el protocolo GCM maneja la autenticación y establece el parámetro de autenticación en NULL.

  • Verifique la configuración de vida útil.

  • Verifique el grupo del módulo Diffie Hellman.

  • Verifique la configuración de la función pseudo aleatoria.

• La lista de acceso para el mapa criptográfico no está configurada en:

  • Permiso GRE (local_tunnel_transport_ip) 255.255.255.255 (remote_tunnel_transport_ip) 255.255.255.255" (o comando equivalente)

    La lista de acceso debe ser específica para el protocolo "GRE" y el protocolo "IP" no funcionará.

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

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

Una vez configurada correctamente, se inicia el túnel IPsec y la negociación de primera fase de IKEv2:

• GRE pasa de la interfaz del túnel GRE lateral del CPE a la interfaz del túnel GRE lateral de la instancia dedicada.

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

• Ping desde la dirección IP del túnel lateral de CPE a la dirección IP del túnel lateral de la instancia exclusiva.

  Ping no puede ser la IP de transporte de túnel a IP de transporte de túnel, debe ser IP de túnel a 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 extremos IPsec) o el puerto 4500 (cuando se inserta un dispositivo NAT en el medio de los extremos IPsec).

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

Es posible que el centro de datos de Dedicated Instance no siempre comience el primer paquete de IKEv2. El requisito es que el dispositivo CPE sea capaz de iniciar el primer paquete de IKEv2 hacia el lado de Dedicated Instance. Si el firewall local lo permite, intente también hacer ping a la dirección IPsec remota. Si el ping no tiene éxito desde una dirección IPsec local a una dirección remota, realice una ruta de seguimiento para ayudar y determine dónde se ha caído el paquete. Es posible que algunos firewalls y equipos de Internet no permitan la ruta de rastreo.

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

Una vez que la sesión de IKEv2 se verifique como activada y activa, Investigue la sesión de IPsec. Al igual que con la sesión de IKEv2, realice un comando "show crypto ipsec sa" o equivalente para verificar la sesión de IPsec. Tanto la sesión IKEv2 como la sesión IPsec deben estar activas antes de establecer el túnel GRE. Si la sesión de IPsec no se muestra como activa, compruebe los registros de IPsec en busca de mensajes de error o errores de negociación.

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

La configuración del lado de CPE no coincide con la de Dedicated Instance; vuelva a comprobar la configuración:

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

• Verifique la configuración de Perfect Forward Secrecy (Secreto de reenvío perfecto) y que la configuración coincida en el lado de Dedicated Instance.

• Verifique la configuración de vida útil.

• Verifique que el 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 activadas y activas, los paquetes keepalive del túnel de GRE pueden fluir entre los extremos del túnel de Dedicated Instance y CPE. Si la interfaz del túnel no muestra el estado, algunos problemas comunes son:

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

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

• Los keepalives no están habilitados en la interfaz del túnel lateral del CPE

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

• La máscara o la dirección IP de la interfaz del túnel no son correctas y no coinciden 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 impide que los paquetes GRE se envíen al túnel de IPsec o se reciban desde el túnel de IPsec (el túnel de GRE se transporta a través del túnel de IPsec).

Una prueba de ping debe verificar que la interfaz del túnel local está encendida y que la conectividad es buena con la interfaz del túnel remoto. Realice la comprobación de ping desde la IP del túnel (no la IP de transporte) hasta la IP del túnel remoto.

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

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

Si la prueba de ping no tiene éxito y se verifican los elementos anteriores, es posible que se requiera una captura de paquetes para garantizar que el ping icmp está dando lugar a 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 en la interfaz del túnel de GRE y los contadores de sesiones de IPsec también pueden ayudar a mostrar si los paquetes de envío y recepción están aumentando.

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

En el lado de Dedicated Instance, se habilitan dos funciones 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 encima de los encabezados GRE reducirá aún más la mayor MTU permitida sobre 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 Dedicated Instance. Configure el comando "ip tcp adjust-mss 1350" o equivalente, así como el comando "tunnel path\u0002mtu-discovery" o equivalente en el lado del cliente para ayudar con el ajuste dinámico de MTU del tráfico a través del túnel VPN.