Preguntas frecuentes de AWS

Haga clic en cualquiera de las preguntas frecuentes del área de navegación de la derecha para obtener sugerencias y soluciones.

¿Cómo puedo configurar la VPN como copia de seguridad de mi conexión de Direct Connect?

Quiero configurar una conexión VPN de respaldo para la conmutación por error con mi conexión de AWS Direct Connect. ¿Alguna recomendación y mejores prácticas?

Solución

Para configurar la VPN de hardware como copia de seguridad de su conexión de Direct Connect:

Asegúrese de que utiliza la misma puerta privada virtual tanto para Direct Connect como para la conexión VPN a la VPC.
Si está configurando una VPN de protocolo de puerta de enlace de borde (BGP), anuncie el mismo prefijo para Direct Connect y la VPN.
Si está configurando una VPN estática, añada los mismos prefijos estáticos a la conexión VPN que esté anunciando con la interfaz virtual de Direct Connect.
Si se anuncian las mismas rutas hacia la VPC de AWS, siempre se prefiere la ruta de Direct Connect, independientemente de la anteposición de la ruta de acceso AS.

Importante

Asegúrese de que Direct Connect es la ruta preferida desde tu extremo y no a través de la VPN cuando la interfaz virtual de Direct Connect esté activada para evitar el enrutamiento asimétrico; esto podría causar el descenso del tráfico. Siempre preferimos una conexión de Direct Connect sobre las rutas VPN. Para obtener información sobre la prioridad de la ruta y las opciones de enrutamiento, consulte el tema de AWS Route Priority.

Nota

Si desea una solución a corto plazo o de menor coste, considere la posibilidad de configurar una VPN de hardware como opción de conmutación por error para una conexión de Direct Connect. Las conexiones VPN no están diseñadas para proporcionar el mismo nivel de ancho de banda disponible para la mayoría de las conexiones de Direct Connect. Asegúrese de que su caso de uso o aplicación puede tolerar un menor ancho de banda si está configurando una VPN como respaldo de una conexión de Direct Connect.

¿Cómo puedo habilitar la BFD para utilizarla con Direct Connect?

La detección de reenvío bidireccional (BFD) es un protocolo de detección de fallos en la red que proporciona tiempos de detección de fallos rápidos, lo que facilita un tiempo de reconvergencia más rápido para los protocolos de enrutamiento dinámico. Es independiente de los medios, del protocolo de enrutamiento y de los datos. Recomendamos habilitar BFD cuando se configuren varias conexiones de AWS Direct Connect o cuando se configure una única conexión de AWS Direct Connect y una conexión VPN como respaldo para garantizar una rápida detección y conmutación por error. Puede configurar BFD para detectar fallos en los enlaces o en las rutas y actualizar el enrutamiento dinámico, ya que Direct Connect termina rápidamente el emparejamiento BGP para que las rutas de copia de seguridad puedan entrar en acción. Esto asegura que la relación de vecino de la detección de reenvío bidireccional (BGP) se rompa rápidamente en lugar de esperar a que fallen 3 mantenimientos de conexiones abiertas con un tiempo de espera de 90 segundos.

Solución

El intervalo de la BFD especifica la frecuencia con la que enviamos paquetes BFD, el min_rx es la frecuencia con la que un enrutador espera recibir los paquetes, y el multiplicador es cuántos podemos perder antes de que la relación de vecino del BGP se considere caída.

La BFD asíncrona se habilita automáticamente para cada interfaz virtual de Direct Connect en el lado de AWS, pero no surte efecto hasta que se configura en el enrutador. El valor por defecto de Direct Connect establece el intervalo mínimo de detección de vitalidad BFD en 300 ms y el multiplicador de detección de vida de BFD en 3.

Antes de utilizar el modo de eco de BFD con su dispositivo de red, debe desactivar el envío de mensajes del protocolo de mensajes de control de Internet (ICMP) y de redirección con el comando no ip redirect para evitar una alta utilización de la CPU.

¿Cómo se establece una conexión de Direct Connect activa/pasiva?

Cuando se utiliza AWS Direct Connect para transportar cargas de trabajo de producción hacia y desde AWS, se recomienda utilizar circuitos virtuales duales de Direct Connect, ya sea desde un solo puerto, un par de conexiones de puertos físicos (ya sea discreto o LAG/LACP) en un solo DC o repartidos en varias ubicaciones de DC.

Puede configurar lo siguiente:

Dos enrutadores para terminar las conexiones DX primarias y secundarias para evitar un único punto de fallo del dispositivo.
Una interfaz virtual privada en cada uno de los enrutadores DX que terminan en la misma VPC. Protocolos de enrutamiento de HA (como HSRP, VRRF, GLBP, etc.) en dos enrutadores para permitir que los servidores locales utilicen varios enrutadores que actúen como un único enrutador virtual, manteniendo la conectividad incluso si falla el enrutador primario, porque el enrutador secundario tomará el relevo y pasará a estar activo, o ejecutar un protocolo de enrutamiento interno como iBGP que aprenderá las rutas de Direct Connect EBGP y distribuirá los prefijos a las puertas iBGP internas.
Activo/Pasivo (conmutación por error). Una de las conexiones gestiona el tráfico y la otra está en espera. Si la conexión activa deja de estar disponible, todo el tráfico se encamina a través de la conexión pasiva. Tendrá que anteponer la ruta de acceso AS a uno de sus enlaces para que sea el enlace pasivo. Para obtener más información, consulte Configure Redundant Connections with AWS Direct Connect (Configurar conexiones redundantes con AWS Direct Connect).

El atributo de preferencia local identifica un punto de salida preferido del sistema autónomo (AS) local. Si hay varios puntos de salida del AS, el atributo de preferencia local selecciona el punto de salida para una ruta específica.

Influencia en el tráfico saliente de AWS mediante la anteposición de la ruta AS

El algoritmo de mejor ruta de BGP decide cómo se selecciona la mejor ruta hacia un sistema autónomo. Un valor común para determinar la mejor ruta es la longitud de la ruta AS. Cuando existen dos o más rutas para alcanzar un prefijo, el valor por defecto en BGP es preferir la ruta con la ruta AS más corta.

El enrutador secundario anunciará una ruta AS más larga, por lo que el tráfico desde la VPC a su red siempre pasará por el enrutador primario.

Mi interfaz virtual pública está atascada en el estado “verifying (verificando)”. ¿Qué puedo hacer?

Cuando se crea una interfaz virtual pública y se especifican las direcciones IP públicas de los pares, se requiere la aprobación del equipo de AWS Direct Connect (las VIF/VXC privadas no requieren esta autorización y están disponibles en cuestión de minutos). Antes de aprobar los prefijos IP públicos o los ASN públicos, el equipo de AWS Direct Connect tiene que verificar la propiedad de los prefijos IP públicos y los ASN de BGP. El equipo de AWS Direct Connect verifica la propiedad confirmando que el registro regional pertenece al nombre de la organización que figura en su cuenta de AWS.

Solución

Si el estado de la interfaz virtual pública está en estado de verificación durante más de 72 horas, compruebe la dirección de correo electrónico registrada en su cuenta de AWS. Es posible que haya recibido un correo electrónico del equipo de AWS Direct Connect si el propietario del ASN de BGP o de una de sus rutas anunciadas no coincide con los datos de su cuenta.

Si el ASN de BGP o una de sus rutas anunciadas no coincide su cuenta, puede hacer lo siguiente:

Pida al propietario de la dirección IP que envíe un correo electrónico a directconnect-requests@amazon.com indicando que autoriza que se aprueben los prefijos IP públicos para la interfaz virtual pública dxvif-xxx.

—o—
Pida al propietario de la dirección IP que presente una carta de autorización escrita con el membrete de la empresa o que envíe un correo electrónico autorizando el uso del prefijo IP público para la interfaz virtual pública dxvif-xxx con su cuenta de AWS. A continuación, inicie sesión en la cuenta que posea la interfaz virtual pública de Direct Connect, abra un caso y adjunte la carta de autorización a su caso.

El estado de la BGP de la interfaz virtual está inactivo en la consola de AWS. ¿Qué debo hacer?

El estado de su interfaz virtual podría ser inactivo debido a problemas de configuración con la capa 2 de OSIInterconexión de sistemas abiertos.
Modelo que caracteriza y estandariza las funciones de comunicación de un sistema de telecomunicaciones o informático. La mayoría de los productos de Megaport son de capa 2 con algunas de las construcciones OSI que pasan a la capa 3, donde se intercambia la información de direccionamiento IP, conocida como servicio L2/L3. o el protocolo de gateway de borde (BGP).

Configuración de la capa 2 de OSI

En primer lugar, verifique que su capa 2 de OSI está configurada correctamente. Verifique los siguientes datos:

Ha configurado el ID de VLAN correcta con encapsulación dot1Q en su dispositivo (como un enrutador o un conmutador). El ID de la VLAN aparece en la pestaña Portal Information (Información del portal) como el servicio de extremo A de su VXC.
La configuración de la dirección IP del par es idéntica en su dispositivo, a través del portal y en la consola de AWS Direct Connect.
Todos los dispositivos intermedios se han configurado para el etiquetado VLAN con el ID de VLAN adecuado, y el tráfico con etiquetado VLAN se conserva en el punto de conexión de AWS Direct Connect.
Su dispositivo está aprendiendo la dirección de Media Access Control (MAC) del punto de conexión de AWS Direct Connect para el ID de la VLAN configurado a partir de la tabla del protocolo de resolución de direcciones (ARP).
Su dispositivo puede hacer un ping a la IP del par de Amazon desde su IP del par.

Configuración de BGP

Si los resultados de la prueba de la capa 2 de OSI son positivos, confirme la configuración de BGP en su dispositivo. Verifique lo siguiente:

El ASN local y el ASN remoto indicados en la pestaña Portal Information (Información del portal) como el servicio de extremo A de su VXC.
La dirección IP vecina y la contraseña MD5 de BGP indicadas en la pestaña Portal Information (Información del portal) como el servicio de extremo A de su VXC.
Su dispositivo no está bloqueando la entrada o la salida del puerto TCP 179 (BGP) u otros puertos efímeros pertinentes.
Su dispositivo no está anunciando más de 100 prefijos a AWS por BGP. Por defecto, AWS solo acepta hasta 100 prefijos con una sesión BGP en AWS Direct Connect.

Cuando confirme estas configuraciones, debería aparecer el estado de su interfaz virtual de BGP.

Última actualización: 2022-06-13