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.

La siguiente figura muestra el ejemplo del modelo de implementación de conexión virtual para la opción de 2 concentradores en el 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, garantizando que se elija la ruta más óptima para la región de servicio Virtual Connect.

La siguiente figura muestra las regiones de emparejamiento de conectividad en la nube de instancias dedicadas.

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 IPsec implica dos fases: la fase IKEv2 y la fase IPsec. Si la negociación de la fase IKEv2 no se completa, no se inicia una segunda fase IPsec. Primero, emita el comando "show crypto ikev2 sa" (en el equipo Cisco) o un comando similar en el equipo de terceros para verificar si la sesión 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 IPsec.

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

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

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

• Un firewall está bloqueando los paquetes UDP IKEv2.

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.

Algunos errores comunes con la negociación IKEv2 son:

• La configuración de IKEv2 en el lado de CPE no coincide con el lado de Cisco, vuelva a verificar las configuraciones mencionadas:

  • 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 se utiliza el cifrado "GCM", 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 de módulos 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í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.

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

• GRE mantiene activa la conexión 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 de vecino BGP desde el vecino BGP del lado CPE al vecino BGP del lado de la instancia dedicada.

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

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

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

Verifique que la primera fase de IPsec (es decir, la asociación de seguridad IKEv2) esté activa antes de solucionar problemas de la segunda fase de IPsec. Ejecute el comando "show crypto ikev2 sa" o equivalente para verificar la sesión IKEv2. En la salida, verifique que la sesión IKEv2 haya estado activa durante más de unos pocos 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 equivalente en la salida.

Una vez que la sesión IKEv2 se verifique como activa, investigue la sesión IPsec. Al igual que con la sesión IKEv2, ejecute el 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 GRE. Si la sesión IPsec no aparece como activa, verifique 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 del lado CPE no coincide con la del lado de la instancia dedicada, vuelva a verificar la configuración:

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

• Verifique la configuración de Perfect Forward Secrecy y que coincida con la configuración del lado de la Instancia Dedicada.

• Verifique la configuración de vida útil.

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

• Verificar las direcciones IPsec de origen y destino.

Cuando se verifica que las sesiones IPsec e IKEv2 están activas, los paquetes keepalive del túnel GRE pueden fluir entre la instancia dedicada y los puntos finales 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 VRF en la interfaz de túnel).

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

• Los keepalives no están habilitados en la interfaz del túnel del lado 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 la instancia dedicada también se deshabiliten.

  Si se admiten keepalives, verifique que estén habilitados.

• La máscara o 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 el envío de paquetes GRE al túnel IPsec o su recepción 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 sea buena con la interfaz del túnel remoto. Realice la verificación de ping desde la IP del túnel (no la IP de transporte) a la IP del 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 destino.

Si la prueba de ping no es exitosa y se verifican los elementos anteriores, entonces puede ser necesaria una captura de paquetes para garantizar que el ping ICMP genere 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 GRE y los contadores de sesión IPsec también pueden ayudar a mostrar si los paquetes de envío y recepción están incrementando.

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 BGP está configurado, 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 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 encabezados adicionales sobre los encabezados GRE, lo que 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 "tunnel" path\u0002mtu-discovery" o 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.