Virtual Connect utiliza una arquitectura de cabecera de doble nivel, donde un dispositivo proporciona los planes de control DE direccionamiento y SION Y el plano de control IPSec es provisto por otro.

Cuando haya finalizado la conectividad de conexión virtual , se crearán dos túneles SSH sobre IPSec entre la red empresarial del cliente y los centros de datos de Cisco de la instancia de uso exclusivo. Uno a cada centro de datos redundante dentro de la Región respectiva. El socio o cliente de Cisco intercambia los elementos de red adicionales requeridos para el emparejamiento a través del formulario de activación de la Conexión virtual del concentrador de control.

En la siguiente figura, se muestra el ejemplo del modelo de implementación de conexión virtual para la opción de 2 concentradores del lado del cliente.

Conexión virtual : vpn es un diseño de concentrador, donde los sitios del concentrador 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 recomienda utilizar dos sitios de concentradores para una mejor redundancia, pero el sitio de Un concentrador con dos túneles también es un modelo de implementación compatible.

Se espera que los socios trabajen en estrecha colaboración con los Clientes, lo que garantiza que se elija la ruta más óptima para la región de servicio de Conexión virtual .

La siguiente figura muestra las regiones de emparejamiento de conectividad en la nube de la instancia dedicada.

El enrutamiento para el complemento de Virtual Connect se implementa mediante BGP (eBGP) externo entre la instancia de uso exclusivo y el equipo local del cliente (CPE). Cisco anunciará sus redes respectivas 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

  • Dirección IP de la interfaz de túnel (enlace transitorio para el enrutamiento) Cisco asigna desde un Espacio de dirección compartido designado (no enrutado públicamente)

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

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

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

• eBGP se utiliza para intercambiar rutas entre la Instancia de uso exclusivo y el CPE

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

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

  • El CPE debe configurarse con el eBGP correcto. Si se utiliza un CPE, se utilizarán dos eBGP ssh, uno apuntando a cada túnel remoto. Si está utilizando dos CPE, cada CPE tendrá un elemento vecino de eBGP que aparecerá en el túnel remoto único para el CPE.

  • Se configura el lado de Cisco de cada túnel BGP (IP de la interfaz de túnel) como el vecino de BGP en el CPE

  • CPE debe 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 administrador.

• En condición de falla de enlace de no falla, un solo CPE tendrá dos tuneles activos/activos. Para dos nodos de CPE, cada CPE tendrá un túnel activo y ambos nodos CPE deberían estar activos y su tráfico de paso. En una situación de no falla, el tráfico debe dividirse en dos túneles que van a los /25 destinos correctos; si uno de los túneles queda fuera de servicio, el túnel restante puede llevar el tráfico para ambos. En dicha situación de falla, cuando la red /25 está abajo, la red /24 se utiliza como ruta de copia de seguridad. Cisco enviará el tráfico del cliente a través de su WAN interna hacia el CENTRO de datos que perdió la conectividad.

La negociación del túnel de IPsec implica dos fases, la fase IKEv2 y la fase IPsec. Si la negociación de la fase de IKEv2 no se completa, entonces no se iniciará una segunda fase de IPsec. Primero, emita 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 IKEv2 no está activa, las posibles razones podrían ser:

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

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

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

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

• Un firewall está bloqueando los paquetes UDP IKEv2.

Primero, compruebe los registros de IPsec para cualquier mensaje que muestre el progreso de la negociación del túnel de 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 IKEv2 no está siendo activada.

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

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

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

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

    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 por vida.

  • Verifique el grupo de módulos de Diffie Hellman.

  • Verifique la configuración de la función pseudoaleatoria.

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

  • Permitir 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íficamente 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, entonces puede ser necesaria una captura de paquetes.

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

• Actividad de GRE desde la interfaz del túnel de GRE del lado de CPE hasta la interfaz del túnel de GRE del lado de Dedicated Instance.

• Sesión TCP de proximidad de BGP desde el vecino BGP del lado de CPE al vecino BGP del lado de Dedicated Instance.

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

  Ping no puede ser la IP de transporte de túnel a 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, defina 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).

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

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. 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 funcionado durante más de unos pocos segundos y que no esté rebotando. El tiempo de actividad de la sesión se muestra como la sesión "Tiempo activo" o su equivalente en la salida.

Una vez que la sesión de IKEv2 se verifique como activa, Investigue la sesión de IPsec. Al igual que con la sesión IKEv2, realice un comando "show crypto ipsec sa" o 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 de GRE. Si la sesión de IPsec no se muestra como activa, compruebe los registros de IPsec para ver si hay mensajes de error o errores de negociación.

Algunas de las cuestiones más comunes que se pueden encontrar durante las negociaciones del IPsec son:

La configuración del lado de CPE no coincide con la del lado 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 la instancia dedicada.

• Verifique la configuración de secreto perfecto hacia adelante 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 el modo túnel.

• Verifique las direcciones IPsec de origen y destino.

Cuando las sesiones IPsec e IKEv2 se verifican como activas y activas, los paquetes keepalive del túnel de GRE pueden fluir entre los extremos de la instancia dedicada y del túnel de CPE. Si la interfaz del túnel no muestra el estado, algunos problemas comunes son los siguientes:

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

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

• Los módulos de actividad no están activados en la interfaz del túnel lateral de CPE

  Si los módulos de actividad predeterminados no son compatibles con el equipo de CPE, se debe notificar a Cisco para que también se deshabiliten los módulos de actividad predeterminados del lado de la instancia dedicada.

  Si los módulos de actividad son compatibles, verifique que estén activados.

• 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 está bloqueando los paquetes de GRE que se envían al túnel de IPsec o se reciben 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é funcionando y que la conectividad sea buena con la interfaz remota del túnel. Realice la comprobación de ping desde la IP del túnel (no la IP de transporte) hasta la IP remota del túnel.

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

Si la prueba de ping no es exitosa y se verifican los elementos anteriores, es posible que se requiera una captura de paquetes 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 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 ping, la captura también debería mostrar paquetes de 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 también a través de la VPN.

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

El túnel de GRE ajusta la característica de MSS y la ruta del túnel de GRE en la característica de detección de MTU está habilitada en el lado de la instancia dedicada. Configure "ip tcp adjust-mss 1350" o un comando equivalente, así como "tunnel 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 de VPN.