- Inicio
- /
- Artículo
Gracias por sus comentarios.
Instancia dedicada - Conexión virtual
En este artículo
¿Comentarios?Virtual Connect es una opción adicional para la conectividad en la nube a la instancia dedicada Webex Calling. Virtual Connect permite a los clientes ampliar de forma segura su red privada a través de Internet utilizando túneles VPN IP punto a punto. Aquí discutimos sobre pedidos, activación y configuración para Virtual Connect.
Introducción
Virtual Connect es una opción adicional para la conectividad en la nube a la instancia dedicada para Webex Calling (instancia dedicada). Virtual Connect permite a los clientes ampliar de forma segura su red privada a través de Internet mediante túneles IP VPN punto a punto. Esta opción de conectividad proporciona un rápido establecimiento de la conexión de red privada mediante el uso del equipo local del cliente (CPE) existente y la conectividad a Internet.
Cisco aloja, administra y asegura túneles VPN IP redundantes y el acceso a Internet requerido en las regiones del centro de datos de instancia dedicada de Cisco donde se requiere el servicio. Del mismo modo, el Administrador es responsable de sus correspondientes servicios CPE e Internet que se requieren para el establecimiento de Virtual Connect.
Cada pedido de Virtual Connect en una región de instancia dedicada en particular incluiría dos túneles genéricos de encapsulación de enrutamiento (GRE) protegidos por cifrado IPSec (GRE sobre IPSec), uno para cada centro de datos de Cisco en la región seleccionada.
Virtual Connect tiene un límite de ancho de banda de 250 Mbps por túnel y se recomienda para implementaciones más pequeñas. Dado que se utilizan dos túneles VPN punto a punto, todo el tráfico a la nube tiene que pasar por el CPE de cabecera del cliente y, por lo tanto, puede no ser adecuado donde hay muchos sitios remotos. Para otras opciones alternativas de peering, consulte Conectividad en la nube.
Antes de enviar la solicitud de interconexión para Virtual Connect, asegúrese de que el servicio de instancia dedicada esté activado en esa región respectiva.
Prerrequisitos
Los requisitos previos para establecer Virtual Connect incluyen:
-
El cliente proporciona
-
Conexión a Internet con suficiente ancho de banda disponible para soportar la implementación
-
Direcciónes IP públicas para dos túneles IPSec
-
Direcciones IP de transporte GRE del lado del cliente para los dos túneles GRE
-
-
Socio y cliente
-
Trabajen juntos para evaluar los requisitos de ancho de banda
-
Asegúrese de que los dispositivos de red sean compatibles con el enrutamiento Border Gateway Protocol (BGP) y un diseño de túnel GRE sobre IPSec
-
-
El socio o cliente proporciona
-
Equipo de red con conocimiento de tecnologías de túnel VPN de sitio a sitio
-
Equipo de red con conocimiento de BGP, eBGP y principios generales de enrutamiento
-
-
Cisco
-
Cisco asignó números de sistema autónomos privados (ASN) y direccionamiento IP transitorio para interfaces de túnel GRE
-
Cisco asignó una red de clase C (/24) pública pero no enrutable por Internet para el direccionamiento en la nube de instancia dedicada
-
Si un cliente tiene solo 1 dispositivo CPE, entonces los 2 túneles hacia los centros de datos de Cisco (DC1 y DC2) en cada región, serán de ese dispositivo CPE. El cliente también tiene una opción para 2 dispositivos CPE, entonces cada dispositivo CPE debe conectarse a 1 túnel solo hacia los centros de datos de Cisco (DC1 y DC2) en cada región. Se puede lograr redundancia adicional al terminar cada túnel en un sitio/ubicación física separada dentro de la infraestructura del Cliente.
Detalles técnicos
Modelo de implementación
Virtual Connect utiliza una arquitectura de cabecera de doble nivel, donde el enrutamiento y los planos de control GRE son proporcionados por un dispositivo y el plano de control IPSec es proporcionado por otro.
Una vez completada 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 la instancia dedicada de Cisco. Uno para cada centro de datos redundante dentro de la región respectiva. Los elementos de red adicionales necesarios para el peering son intercambiados por el Partner o el Cliente a Cisco a través del formulario de activación de Control Hub Virtual Connect.
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 Hub, donde los sitios de concentradores del cliente están conectados a DC1 y DC2 de los centros de datos de una instancia dedicada dentro de una región en particular.
Se recomiendan dos sitios Hub para una mejor redundancia, pero un sitio 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. Para garantizar una conmutación por error efectiva, el tráfico combinado a través de ambos túneles no debe exceder los 250 Mbps, ya que todo el tráfico se enrutará a través de un túnel en caso de falla.
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 de Virtual Connect.
La siguiente figura muestra las regiones de interconexión de conectividad en la nube de instancia dedicada.
Enrutamiento
El complemento de enrutamiento para Virtual Connect se implementa utilizando BGP externo (eBGP) entre la instancia dedicada 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 se requiere que el CPE anuncie 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 del transporte del túnel (lado de Cisco)
-
Números de sistema autónomo privado (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 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 punto a punto (enlace transitorio)
-
CPE debe configurarse con los vecinos eBGP apropiados. Si usa un CPE, se utilizarán dos vecinos eBGP, uno apuntando a cada túnel remoto. Si usa dos CPE, entonces cada CPE tendrá un vecino eBGP que apunta al único túnel remoto 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 que CPE anuncie 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 cliente.
-
-
Bajo una condición de falla de enlace sin falla, un solo CPE tendrá dos túneles activos/activos. Para dos nodos CPE, cada CPE tendrá un túnel activo y ambos nodos CPE deben estar activos y pasar tráfico. En el escenario de no falla, el tráfico debe dividirse en dos túneles que van a los destinos /25 correctos; si uno de los túneles cae, el túnel restante puede transportar el tráfico para ambos. En un escenario de falla de este tipo, 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ó conectividad.
Flujo de tráfico de conexión virtual
Flujo de tráfico cuando ambos túneles están en marcha
Esta imagen ilustra una arquitectura de red Virtual Connect, detallando el flujo de tráfico cuando los túneles primario y secundario están operativos.
Representa un modelo de conectividad activo para que un cliente acceda a aplicaciones UC alojadas en los centros de datos de Cisco, aprovechando los túneles GRE/IPSEC duales a través de Internet con BGP para el intercambio de rutas.
Definiciones:
- Premisa del cliente:
- Esto representa la red in situ del cliente, donde se encuentran los usuarios y sus dispositivos (por ejemplo, teléfonos IP, computadoras que ejecutan clientes UC).
- El tráfico que se origina desde aquí debe llegar a las aplicaciones UC alojadas en los centros de datos de Cisco.
- Cisco Webex CallingCentros de datos de instancia dedicada (instancia dedicada) (WXC-Di DC-A y WXC-Di
DC-B):
- Estos son los centros de datos de Cisco que alojan las aplicaciones UC.
- DC-A y DC-B son geográficamente distintos, lo que proporciona redundancia.
- Cada centro de datos tiene su propia subred para aplicaciones UC:
- Sured DC-A: X.X.X.0/25
- Sured DC-B: X.X.X.128/25
- Túneles GRE/IPSec (Túnel 1 y Túnel 2):
- Estas son las conexiones seguras y encriptadas entre las instalaciones del cliente y el centro de datos de Cisco a través de Internet público.
- GRE (Encapsulación de enrutamiento genérico): Este protocolo se utiliza para encapsular varios protocolos de capa de red dentro de enlaces virtuales punto a punto. Permite que protocolos de enrutamiento como BGP operen sobre el túnel.
- IPSec (Internet Protocol Security): Este conjunto de protocolos proporciona servicios de seguridad criptográfica (autenticación, integridad, confidencialidad) para las comunicaciones IP . Encripta el tráfico encapsulado GRE, asegurando una transmisión segura de datos a través de Internet.
- Protocolo de puerta de enlace fronteriza (BGP):
- BGP es el protocolo de enrutamiento utilizado para intercambiar información de enrutamiento entre las instalaciones del cliente y los centros de datos de Cisco.
Como se muestra en el diagrama anterior, los dispositivos implementados en las instalaciones del cliente necesitan establecer dos túneles GRE/IPSEC.
Las convenciones de nomenclatura que se utilizan a continuación con XX/YY, DC-A DC-B son genéricas para todas las regiones donde se ofrece la instancia dedicada. Estos valores serán únicos para cada región y los valores reales para cada región. Los valores específicos se proporcionan durante la activación de la conexión virtual.
En el lado de Cisco, los túneles IPSec y GRE se terminarán en diferentes dispositivos. Por lo tanto, el cliente tiene que asegurarse de configurar las IP de destino IPSec y de destino GRE en los dispositivos en consecuencia. Los clientes pueden usar la misma IP para GRE e IPSEC si es compatible con sus dispositivos. Consulte el diagrama de arriba. Los valores relacionados con IP se proporcionan durante la activación de la conexión virtual en el portal.
- Túnel 1: conecta las instalaciones del cliente a la “instancia dedicada DC-A” (centro de datos A) a través de Internet. Este túnel utiliza BGP AS:64XX1 en el lado del cliente y BGP A:64XX2 en el lado DC-A de instancia dedicada. Las configuraciones de origen del túnel IPSEC y GRE se dividen entre los detalles proporcionados por el cliente y los proporcionados por Cisco.
- Túnel 2: conecta las instalaciones del cliente con la “instancia dedicada DC-B” (Data Center B) a través de Internet. Este túnel utiliza BGP AS:64YY1 en el lado del cliente y BGP A:64YY2 en el lado DC-B de instancia dedicada . Al igual que el túnel 1, las configuraciones de fuente del túnel IPSEC y GRE se comparten entre el cliente y Cisco.
En BGP como: 64XX y BGP A:64YY, XX e YY son específicos de una región en particular.
Una vez establecidos los túneles GRE/IPSEC en los centros de datos de instancias Webex Calling dedicadas (A y B), el cliente debe recibir las siguientes rutas anunciadas por Cisco a través de las sesiones BGP correspondientes.
- Para DC-A: Las rutas anunciadas por Cisco serán X.X.X.0/25 y X.X.X.0/24. Opcionalmente, si se solicita IaaS y se configura para el cliente, Cisco anunciará las rutas Y.Y..0/25 y Y.Y.0/24.
- Para DC-B: Las rutas anunciadas por Cisco serán X.X.X.128/25 y X.X.X.0/24. Opcionalmente, si se solicita IaaS y se configura para las rutas del cliente, Cisco anunciará Y.Y.Y.128/25 y Y.Y.0/24.
- El cliente necesita anunciar la ruta 0.0.0./0 a Cisco a través de ambas conexiones (túneles)
- El cliente tiene que seguir las rutas de prefijo más largas (/25) para enviar tráfico a Cisco a través de los túneles respectivos cuando ambos túneles están en funcionamiento.
- Cisco devolverá el tráfico a través de los mismos túneles para mantener el tráfico simétrico.
Flujo de tráfico:
- El tráfico destinado a “DC-A UC Apps” (X.X.X.0/25) desde las instalaciones del cliente fluye a través del túnel 1.
- El tráfico destinado a “DC-B UC Apps” (X.X.X.128/25) desde las instalaciones del cliente fluye a través del túnel 2.
Escenario de failover: flujo de tráfico cuando uno de los túneles está caído
Como se muestra en el diagrama anterior, cuando el túnel a DC-A está abajo, el bgp establecido a través del túnel a DC-A bajará.
Impacto en BGP: Cuando el túnel 1 se baja, la sesión de BGP sobre ese túnel también bajará. En consecuencia, DC-A ya no podrá anunciar sus rutas (específicamente X.X.X.0/25) al cliente a través de esta ruta. Por lo tanto, el router del cliente detectará la ruta como inalcanzable.
Ahora, dado que el túnel 1 está inactivo, el router del cliente en las instalaciones del cliente eliminará automáticamente las rutas aprendidas a través del Túnel 1 de su tabla de enrutamiento o las marcará como inalcanzables.
- El tráfico destinado a la red de aplicaciones UC (X.X.X.0/24) o la subred DC-A (X.X.X.0/25) se redirigirá a través del túnel de trabajo hacia DC-B, que continúa anunciando el X.X.X.0/24 que incluye la red X.X.X.0/25.
- Se observará un comportamiento similar si el túnel a DC-B está caído mientras que el túnel a DC-A todavía está arriba.
Proceso de conectividad
| 1 | |
| 2 | |
| 3 | |
| 4 |
Paso 1: Orden CCW
Virtual Connect es un complemento para la instancia dedicada en CCW.
| 1 |
Navegue hasta el sitio de pedidos de CCW y, a continuación, haga clic en Iniciar sesión para iniciar sesión en el sitio: |
| 2 |
Crear una estimación. |
| 3 |
Agregue el SKU “A-FLEX-3". |
| 4 |
Seleccione Editar opciones. |
| 5 |
En la pestaña de suscripción que aparece, seleccione Opciones y complementos. |
| 6 |
En Complementos adicionales, seleccione la casilla de verificación junto a “Conexión virtual para instancia dedicada”. El nombre del SKU es “A-FLEX-DI-VC”. |
| 7 |
Introduzca la cantidad y el número de regiones en las que se requiere Virtual Connect. La cantidad de Virtual Connect no debe exceder el número total de regiones compradas para la instancia dedicada. Además, solo se permite un pedido de Virtual Connect por región. |
| 8 |
Cuando esté satisfecho con sus selecciones, haga clic en Verificar y Guardar en la parte superior derecha de la página. |
| 9 |
Haga clic en Guardar y continuar para finalizar su pedido. Su pedido finalizado ahora aparece en la cuadrícula de pedidos. |
Paso 2: Activación de Virtual Connect en Control Hub
| 1 |
Inicie sesión en Control Hub https://admin.webex.com/login. |
| 2 |
En la sección Servicios, vaya a Llamadas > Instancia dedicada > Conectividad en la nube. |
| 3 |
En la tarjeta Virtual Connect, aparece la cantidad de Virtual Connect comprada. El administrador ahora puede hacer clic en Activar para iniciar la activación de Virtual Connect. 
El proceso de activación solo puede ser activado por administradores con la función de “Administrador completo del cliente”. Mientras que, un administrador con la función “Administrador de solo lectura del cliente” solo puede ver el estado. |
| 4 |
Al hacer clic en el botón Activar, se muestra el formulario Activar conexión virtual para que el administrador proporcione los detalles técnicos de Virtual Connect necesarios para las configuraciones de interconexión en el lado de Cisco. El formulario también proporciona información estática del lado de Cisco, según la región seleccionada. Esta información será útil para que los administradores del cliente configuren el CPE de su lado para establecer la conectividad. |
| 5 |
Haga clic en el botón Activar una vez que se hayan completado todos los campos obligatorios. |
| 6 |
Una vez completado el formulario de activación de Virtual Connect para una región en particular, el cliente puede exportar el formulario de activación desde Control Hub, Llamadas > Instancia dedicada > pestaña Conectividad en la nube y hacer clic en Exportar configuración. 
Debido a razones de seguridad, la autenticación y la contraseña BGP no estarán disponibles en el documento exportado, pero el administrador puede ver la misma en Control Hub haciendo clic en Ver configuración en Control Hub, Llamadas > Instancia dedicada > Conectividad en la nube. |
Paso 3: Cisco realiza la configuración de red
| 1 |
Una vez completado el formulario de activación de Virtual Connect, el estado se actualizará a Activación en curso en Llamadas > Instancia dedicada > Tarjeta de conexión virtual de conectividad en la nube. |
| 2 |
Cisco completará las configuraciones requeridas en el equipo lateral de Cisco dentro de los 5 días hábiles. Una vez completado con éxito, el estado se actualizará a “Activado” para esa región en particular en Control Hub. |
Paso 4: El cliente realiza la configuración de red
|
El estado se cambia a “Activado” para notificar al administrador del cliente que el lado de Cisco de las configuraciones para la conectividad IP VPN se ha completado en función de las entradas proporcionadas por el Cliente. Pero, se espera que el administrador del cliente complete su versión de las configuraciones en los CPE y pruebe las rutas de conectividad para que el túnel Virtual Connect esté en línea. En caso de cualquier problema que se enfrente en el momento de la configuración o la conectividad, el cliente puede comunicarse con usted Cisco TAC para obtener ayuda. |
Solución de problemas
Primera fase IPSec (Negociación IKEv2) Solución de problemas y validación
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, entonces no hay inicio de una segunda fase IPSec. Primero, ejecute el comando “show crypto ikev2 sa” (en equipos 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 IP del punto final del túnel IPSec de 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 bloquea los paquetes UDP IKEv2.
Primero, verifique los registros 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 del IKEv2 en el lado CPE no coincide con el lado de Cisco, vuelva a verificar la configuración mencionada:
-
Compruebe que la versión IKE es la versión 2.
-
Verifique que los parámetros de cifrado y autenticación coincidan con el cifrado esperado en el lado 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 Diffie Hellman.
-
Verifique la configuración de la función pseudoaleatoria.
-
-
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í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, es posible que se necesite una captura de paquetes.
Es posible que el lado de la instancia dedicada no siempre comience el intercambio IKEv2 y, a veces, puede esperar que el lado CPE del cliente sea el iniciador.
Compruebe la configuración del lado CPE para conocer los siguientes requisitos previos para el inicio de la sesión 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 hasta la IP de transporte del túnel de instancia dedicada.
-
Asegúrese de que la interfaz del túnel GRE esté habilitada para los keepalives GRE; si el equipo no admite los keepalives GRE, se notifica a Cisco porque los keepalives GRE se habilitarán en el lado 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 inicia el túnel IPSec y la primera fase de negociación IKEv2:
-
GRE mantiene la vida desde la interfaz del túnel GRE del lado CPE hasta la interfaz de 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 instancia dedicada.
-
Realice un ping desde la dirección IP del túnel lateral CPE a la dirección IP del túnel lateral de instancia dedicada.
Ping no puede ser la IP de transporte de túnel a la 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 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 puerto 500 o 4500 se envíen y reciban desde y hacia la dirección IP IPsec DI.
Es posible que el centro de datos de instancia dedicada no siempre inicie 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 una ruta de seguimiento para ayudar y determinar dónde se deja caer el paquete.
Algunos firewalls y equipos de Internet pueden no permitir la ruta de rastreo.
Segunda fase de IPSec (Negociación IPSec) Solución de problemas y validación
Verifique que la primera fase IPSec (es decir, la asociación de seguridad IKEv2) esté activa antes de solucionar problemas en la segunda fase de IPSec. Ejecute un comando “show crypto ikev2 sa” o equivalente para verificar la sesión IKEv2. En la salida, verifique que la sesión IKEv2 haya estado activo 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 equivalente en la salida.
Una vez que la sesión IKEv2 se verifique como activa y activa, investigue la sesión IPSec. Al igual que con la sesión IKEv2, ejecute 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 GRE. Si la sesión IPSec no se muestra como activa, compruebe los registros IPSec para ver si hay mensajes de error o errores de negociación.
Algunos de los problemas más comunes que pueden encontrarse durante las negociaciones IPSec son:
La configuración en el lado CPE no coincide con la parte 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 Instancia dedicada.
-
Verifique la configuración de Perfect Forward Secrecy y que la configuración coincida en el lado 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.
Solución de problemas y validación de la interfaz del túnel
Cuando las sesiones IPSec e IKEv2 se verifican como activas y activas, el túnel GRE mantiene los paquetes activos capaces de fluir entre los extremos de la instancia dedicada y del túnel 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 loopback (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 lateral CPE
Si los keepalives no son compatibles con el equipo CPE, entonces se debe notificar a Cisco para que también se deshabiliten los keepalives predeterminados en el lado de la instancia dedicada.
Si se admite keepalives, verifique que los keepalives 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 impide que los paquetes GRE se envíen al túnel IPSec o se reciban 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 para la interfaz del túnel remoto. 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 los paquetes GRE se crucen. Como resultado, los pings no funcionarán desde IP de transporte de túnel hasta IP de transporte de túnel remoto.
La comprobación de 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 interna) será la IP del túnel de origen y destino.
Si la prueba de ping no se realiza correctamente y se verifican los elementos anteriores, es posible que se requiera una captura de paquetes para asegurarse de que el ping icmp está dando 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 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 keepalive GRE incluso durante el tráfico inactivo. Finalmente, 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.
Solución de problemas y validación de BGP
Sesiones BGP
Se requiere BGP como protocolo de enrutamiento sobre el túnel IPSec VPN. El vecino local de BGP debe establecer una sesión eBGP con el vecino BGP de instancia dedicada. Las direcciones IP del vecino eBGP son las mismas que las direcciones IP del túnel local y remoto. Primero asegúrese de que la sesión de BGP esté activa y, a continuación, verifique que se estén recibiendo las rutas correctas desde la Instancia Dedicada y que la ruta predeterminada correcta se envíe a la Instancia Dedicada.
Si el túnel GRE está activo, verifique que un ping sea correcto entre la IP del túnel GRE local y la remota. Si el ping se realiza correctamente pero la sesión de BGP no se inicia, entonces investigue el registro de BGP para detectar errores de establecimiento de BGP.
Algunos de los problemas más comunes de negociación de BGP son:
-
El número de AS remoto no coincide con el número AS configurado en el lado Instancia dedicada, vuelva a verificar la configuración de AS vecino.
-
El número de AS local no coincide con lo que espera el lado Instancia dedicada, verifique que el número de AS local coincida con los parámetros esperados de la instancia dedicada.
-
Un firewall impide que los paquetes TCP BGP encapsulados en paquetes GRE se envíen al túnel IPSec o se reciban desde el túnel IPSEC
-
La IP del vecino BGP remoto no coincide con la IP del túnel GRE remoto.
Intercambio de ruta BGP
Una vez verificada la sesión BGP para ambos túneles, asegúrese de que se envíen y reciban las rutas correctas desde el lado de la instancia dedicada.
La solución VPN de instancia dedicada espera que se establezcan dos túneles desde el lado del cliente/socio. El primer túnel apunta al centro de datos de instancia dedicada A y el segundo túnel apunta al centro de datos de instancia dedicada B. Ambos túneles deben estar en estado activo y la solución requiere una implementación activa/activa. Cada centro de datos de instancia dedicada anunciará su ruta local /25, así como una ruta de respaldo /24. Cuando compruebe las rutas BGP entrantes desde la instancia dedicada, asegúrese de que la sesión BGP asociada al túnel que apunta al centro de datos de instancia dedicada A reciba la ruta local A/25 del centro de datos de instancia dedicada, así como la ruta de copia de seguridad /24. Además, asegúrese de que el túnel que apunta al centro de datos de instancia dedicada B recibe la ruta local B/25 del centro de datos de instancia dedicada así como la ruta de respaldo /24. Tenga en cuenta que la ruta de copia de seguridad /24 será la misma ruta anunciada desde el centro de datos de instancia dedicada A y el centro de datos de instancia dedicada B.
La redundancia se proporciona a un centro de datos de instancia dedicada si la interfaz de túnel a ese centro de datos se apaga. Si se pierde la conectividad al centro de datos de instancia dedicada A, el tráfico se reenviará del centro de datos de instancia dedicada B al centro de datos A. En este escenario, el túnel al centro de datos B utilizará la ruta del centro de datos B/25 para enviar tráfico al centro de datos B y el túnel al centro de datos B utilizará la ruta de backup /24 para enviar tráfico al centro de datos A a través del centro de datos B.
Es importante que, cuando ambos túneles están activos, el túnel A del centro de datos no se utilice para enviar tráfico al centro de datos B y viceversa. En este escenario, si el tráfico se envía al centro de datos A con un destino del centro de datos B, el centro de datos A reenviará el tráfico al centro de datos B y luego el centro de datos B intentará enviar tráfico de vuelta al origen a través del túnel B del centro de datos. Esto dará como resultado un enrutamiento subóptimo y también puede romper el tráfico que atraviesa los firewalls. Por lo tanto, es importante que ambos túneles estén en una configuración activa/activa durante el funcionamiento normal.
La ruta 0.0.0.0/0 debe anunciarse desde el lado del cliente hasta el lado del centro de datos de instancia dedicada. Rutas más específicas no serán aceptadas por el lado de la Instancia Dedicada. Asegúrese de que la ruta 0.0.0.0/0 se anuncie tanto en el túnel A del centro de datos de instancia dedicada como en el túnel B del centro de datos de instancia dedicada.
Configuración de MTU
En el lado de la instancia dedicada, dos funciones están habilitadas para ajustar dinámicamente la MTU para tamaños de paquetes grandes. 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 reducirá aún más la MTU más grande 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 la instancia dedicada. Configure “ip tcp adjust-mss 1350" o el 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 VPN.
