La opción Virtual Connect ayuda a extender de forma segura su red privada a través de Internet mediante túneles IP VPN de punto a punto.
Introducción
Virtual Connect es una opción complemento para la conectividad de la nube a una 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 VPN IP punto a punto. Esta opción de conectividad proporciona un establecimiento rápido de la conexión de red privada mediante el uso del equipo en las instalaciones del cliente (CPE) existente y la conectividad a Internet.
Cisco aloja, administra y asegura túneles IP VPN redundantes y el acceso a Internet requerido en las regiones de centros de datos de instancias dedicadas de Cisco donde se requiere el servicio. Del mismo modo, el Administrador es responsable de su correspondiente CPE y los servicios de 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 de encapsulación de enrutamiento genérico (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 de punto a punto, todo el tráfico a la nube tiene que pasar por el CPE de la cabecera del cliente y, por lo tanto, es posible que no sea adecuado donde hay muchos sitios remotos. Para otras opciones de emparejamiento alternativas, consulte Conectividad en la nube .
 |
Antes de enviar la solicitud de emparejamiento para Virtual Connect, asegúrese de que el servicio de instancia dedicada esté activado en esa región respectiva. |
Requisitos previos
Los requisitos previos para establecer Virtual Connect incluyen:
El cliente proporciona
Conexión a Internet con suficiente ancho de banda disponible para admitir la implementación
Direcciones dirección 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
Trabajar juntos para evaluar los requisitos de ancho de banda
Asegúrese de que los dispositivo de red con el enrutamiento del Protocolo de puerta de enlace fronteriza (BGP) y un diseño de túnel GRE sobre IPSec
El socio o el cliente proporciona
Equipo de red con conocimiento de las tecnologías de túneles 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 privados (ASN) y direcciones IP transitorias para las interfaces del túnel GRE
Cisco asignó una red de clase C (/ 24) pública pero no enrutable a Internet para el direccionamiento de la nube de instancia dedicada
|
Si un cliente tiene solo 1 dispositivo CPE, los 2 túneles hacia los centros de datos de Cisco (DC1 y DC2) en cada región serán desde ese dispositivo CPE. El cliente también tiene una opción para 2 dispositivos CPE, luego 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 una 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 dos niveles, donde el enrutamiento y los planos de control GRE son proporcionados por un dispositivo y el plano de control IPSec es proporcionado por otro.
Al finalizar el Conexión virtual conectividad, se crearán dos túneles GRE sobre IPSec entre la red empresarial del cliente y los centros de datos de Cisco de instancia dedicada. Uno para cada centro de datos redundante dentro de la región respectiva. Los elementos de red adicionales necesarios para el emparejamiento son intercambiados por el socio o el cliente a Cisco a través del formulario de activación de Control Hub Virtual Connect.
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.
Virtual Connect: VPN es un diseño de concentrador, en el que los sitios concentradores 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 recomiendan dos sitios de concentrador para una mejor redundancia, pero un sitio de concentrador 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, asegurando que se elija la ruta más óptima para la región de servicio 'Virtual Connect'.
La Figura 2 muestra las regiones de emparejamiento de la conectividad de la nube de la instancia dedicada.
Enrutamiento
El enrutamiento para el complemento Virtual Connect se implementa mediante BGP externo (eBGP) entre la Instancia dedicada y el Equipo de las instalaciones 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 compartido designado (no enrutable públicamente)
Dirección de destino de transporte de túnel (lado de Cisco)
Números de sistemas autónomos privados (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 el 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 de punto a punto (enlace transitorio)
El CPE debe configurarse con los vecinos eBGP adecuados. Si usa un CPE, se usarán dos vecinos eBGP, uno apuntando a cada túnel remoto. Si utiliza dos CPE, cada CPE tendrá un vecino eBGP que se pondrá en contacto con el túnel remoto único 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 CPE para 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 cutomer.
En condiciones de falla de enlace sin falla, un solo 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 un escenario sin fallos, el tráfico debe dividirse en dos túneles que vayan a los destinos correctos / 25; si uno de los túneles se cae, el túnel restante puede transportar el tráfico de ambos. En tal escenario de falla, 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.
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 luego haga clic en Iniciar sesión para iniciar sesión en el sitio: |
||
| 2 | Crear presupuesto. |
||
| 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 de SKU es "A-FLEX-DI-VC". |
||
| 7 | Introduzca la cantidad y el número de regiones en las que se requiere Virtual Connect.
|
||
| 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 | Iniciar sesión en Control Hubhttps://admin.webex.com/login . |
||||||||
| 2 | En el Servicios sección, navegue a Llamadas> Instancia dedicada> Conectividad en la nube . |
||||||||
| 3 | En la tarjeta de Virtual Connect, se muestra la cantidad de Virtual Connect comprada. El administrador ahora puede hacer clic en Activar para iniciar la activación de Virtual Connect. 
|
||||||||
| 4 | Al hacer clic en el Activar botón Activar Virtual Connect Se muestra un formulario para que el administrador proporcione los detalles técnicos de Virtual Connect necesarios para las configuraciones de emparejamiento en el lado de Cisco.
|
||||||||
| 5 | Haga clic en el Activar una vez que se hayan completado todos los campos obligatorios. |
||||||||
| 6 | Después de que se complete 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. 
|
Paso 3: Cisco realiza la configuración de la red
| 1 | Una vez que se complete 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 5 días laborales . 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 la red
El estado 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 según las entradas proporcionadas por el Cliente. Sin embargo, se espera que el administrador del cliente complete su parte de las configuraciones en los CPE y pruebe las rutas de conectividad para que el túnel de Virtual Connect esté en línea. En caso de que surja algún problema en el momento de la configuración o la conectividad, el cliente puede comunicarse con TAC de Cisco para obtener ayuda. |
Solución de problemas
Solución de problemas y validación de la primera fase de IPsec (negociación IKEv2)
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 hay inicio de una segunda fase IPsec. Primero, ejecute 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 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 IPsec está mal configurada.
No hay conectividad entre el cliente y la IP del punto final del túnel IPsec de la instancia dedicada.
Los parámetros de la sesión IKEv2 no coinciden entre el lado de la instancia dedicada y el lado del cliente.
Un firewall está bloqueando los paquetes IKEv2 UDP .
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.
La configuración para el IKEv2 en el lado de CPE no coincide con el lado de Cisco , vuelva a verificar 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 la 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 de cifrado no está configurada para:
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 paquete .
|
Es posible que el lado de la instancia dedicada no siempre comience el intercambio de IKEv2 y, en ocasiones, se espere que el lado del CPE del cliente sea el iniciador. Compruebe la configuración del lado de CPE para los siguientes requisitos previos para el inicio de la sesión de IKEv2:
|
Cuando se configura correctamente, lo siguiente comienza el túnel IPsec y la negociación IKEv2 de la primera fase:
GRE keepalives 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 del vecino BGP desde el vecino BGP del lado del CPE al vecino BGP del lado de la instancia dedicada.
Haga ping desde la dirección IP del túnel del lado del CPE a la dirección IP dirección IP del túnel del lado de la instancia dedicada.
Ping no puede ser 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, 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 del IPsec). puntos finales).
Verifique que los paquetes IKEv2 UDP con el puerto 500 o 4500 se envíen y reciban desde y hacia la dirección IP de DI IPsec.
|
Es posible que el centro de datos de la instancia dedicada no siempre comience 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 un seguimiento de la ruta para ayudar y determine dónde se cae el paquete. Es posible que algunos firewalls y equipos de Internet no permitan el rastreo de rutas. |
Solución de problemas y validación de la segunda fase de IPsec (negociación de 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. Ejecute "show crypto ikev2 sa" o un comando equivalente para verificar la sesión de IKEv2. En el resultado, verifique que la sesión de IKEv2 haya estado activa 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 su equivalente en la salida.
Una vez que la sesión de IKEv2 se verifique como activa y activa, investigue la sesión de IPsec. Al igual que con la sesión IKEv2, ejecute "show crypto ipsec sa" o un comando 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 de IPsec no se muestra como activa, consulte 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 en el lado de CPE no coincide con el lado de la 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 de la instancia dedicada.
Verifique la configuración de Perfect Forward Secrecy 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 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 se verifica que las sesiones IPsec e IKEv2 estén activas, los paquetes de mantenimiento del túnel GRE pueden fluir entre la instancia dedicada y los extremos 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 de VRF en la interfaz de túnel).
Si la configuración de VRF no se utiliza en la interfaz del túnel, esta verificación se puede ignorar.
Keepalives no está habilitado en la interfaz del túnel del lado de CPE
Si los keepalives no son compatibles con el equipo CPE, entonces se debe notificar a Cisco para que los keepalives predeterminados en el lado de la instancia dedicada también estén deshabilitados.
Si se admiten keepalives, verifique que estén habilitados.
La máscara o la 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 los paquetes GRE enviados al túnel IPsec o recibidos 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 con la interfaz del túnel remoto sea buena. 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 se crucen los paquetes GRE. Como resultado, los pings no funcionarán desde la IP de transporte de túnel a la IP de transporte de 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 de destino.
Si la prueba de ping no tiene éxito y se verifican los elementos anteriores, es posible que se requiera una captura de paquete 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 de la interfaz del túnel GRE y los contadores de sesiones de IPsec también pueden ayudar a mostrar. si los paquetes de envío y recepción aumentan.
Además del tráfico de ping, la captura también debe mostrar paquetes GRE activos incluso durante el tráfico inactivo. Por último, si se configura BGP, los paquetes de mantenimiento de BGP también deben enviarse como paquetes GRE encapsulados en paquetes IPSEC y a través de la VPN.
Validación y resolución de problemas de BGP
Sesiones BGP
Se requiere BGP como protocolo de enrutamiento a través del túnel VPN IPsec. El vecino BGP local debe establecer una sesión eBGP con el vecino BGP de instancia dedicada. Las direcciones IP vecinas de 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 reciban las rutas correctas de la instancia dedicada y que se envíe la ruta predeterminada correcta a la instancia dedicada.
Si el túnel GRE está activo, verifique que un ping sea exitoso entre la IP del túnel GRE local y remota. Si el ping es exitoso pero la sesión de BGP no se inicia, investigue el registro de BGP en busca de 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 de AS configurado en el lado de la instancia dedicada; vuelva a verificar la configuración de AS del vecino.
El número de AS local no coincide con lo que espera el lado de la instancia dedicada, verifique que el número de AS local coincida con los parámetros esperados de la instancia dedicada.
Un firewall está bloqueando paquetes BGP TCP encapsulados en paquetes GRE para que no 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 rutas BGP
Una vez que se verifique la sesión de 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. Al verificar las rutas BGP entrantes desde la instancia dedicada, asegúrese de que la sesión BGP asociada con el túnel que apunta al centro de datos A de la instancia dedicada reciba la enrutamiento local del centro de datos A / 25 de la instancia dedicada, así como la ruta de respaldo / 24. Además, asegúrese de que el túnel que apunta al centro de datos de instancia dedicada B reciba la enrutamiento local del centro de datos de instancia dedicada B / 25, así como la ruta de respaldo / 24. Tenga en cuenta que la ruta de respaldo / 24 será la misma ruta anunciada desde el centro de datos de instancia dedicada A y el centro de datos de instancia dedicada B.
Se proporciona redundancia a un centro de datos de instancia dedicada si la interfaz de túnel a ese centro de datos se cae. Si se pierde la conectividad al centro de datos A de la instancia dedicada, el tráfico se reenviará desde el centro de datos B de la instancia dedicada 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 al túnel al centro de datos B utilizará la ruta de respaldo / 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 del centro de datos A 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 el tráfico de regreso al origen a través del túnel del centro de datos B. 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 la instancia dedicada. El lado de la instancia dedicada no aceptará rutas más específicas. Asegúrese de que la ruta 0.0.0.0/0 se anuncie tanto en el túnel del centro de datos de la instancia dedicada A como en el túnel del centro de datos de la instancia dedicada B.
Configuración de MTU
En el lado de la instancia dedicada, se habilitan dos características 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 en la parte superior de los encabezados GRE y 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 "tunel 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 .
