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 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 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 estrechamente con los clientes, lo que garantiza que se elija la ruta más óptima para la región de servicio "Virtual Connect".

En la Figura 2 se muestran las regiones peering de conectividad a la nube de la instancia de 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 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.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.

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

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