Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
# Red
Para que las operaciones de administración, supervisión y servicio funcionen correctamente, la implementación de una instancia de Outposts depende de una conexión resiliente a su zona de disponibilidad (AZ) de anclaje. Debe aprovisionar su red local para proporcionar conexiones de red redundantes para cada rack de Outpost y una conectividad fiable hasta los puntos de anclaje de la nube. AWS También deben tenerse en cuenta las rutas de red entre las cargas de trabajo de las aplicaciones que se ejecutan en Outposts y el resto de sistemas en las instalaciones y la nube con los que se comunican. ¿Cómo se va a enrutar este tráfico en la red?
**Topics**
+ [Conexión de redes](network-attachment.md)
+ [Conectividad de anclaje](anchor-connectivity.md)
+ [Enrutamiento de aplicaciones y cargas de trabajo](applicationworkload-routing.md)
# Conexión de redes
Cada AWS Outposts rack está configurado con top-of-rack conmutadores redundantes denominados Outpost Networking Devices (). ONDs Los servidores de cómputo y almacenamiento de cada rack se conectan a ambos. ONDs Debe conectar cada OND a un conmutador independiente denominado dispositivo de red del cliente (CND) del centro de datos para proporcionar diversas rutas físicas y lógicas para cada rack de Outpost. ONDs conéctese al suyo CNDs mediante una o más conexiones físicas mediante cables de fibra óptica y transceptores ópticos. Las [conexiones físicas](https://docs.aws.amazon.com/outposts/latest/userguide/local-network-connectivity.html#physical-connectivity) se configuran en [enlaces lógicos de grupos de agregación de enlaces (LAG)](https://docs.aws.amazon.com/outposts/latest/userguide/local-network-connectivity.html#link-aggregation).
![\[Diagrama que muestra una instancia de múltiples bastidores de Outposts con conexiones redundantes de red\]](http://docs.aws.amazon.com/es_es/whitepapers/latest/aws-outposts-high-availability-design/images/multi-rack-outpost.png)
Los enlaces OND a CND siempre se configuran en un LAG, aunque la conexión física sea un solo cable de fibra óptica. La configuración de los enlaces como grupos LAG permite aumentar el ancho de banda de los enlaces mediante la incorporación de conexiones físicas adicionales al grupo lógico. Los enlaces LAG se configuran como redes troncales Ethernet de estándar IEEE 802.1q para permitir la creación de redes segregadas entre Outposts y la red en las instalaciones.
Cada instancia de Outposts tiene al menos dos redes segregadas de forma lógica que deben comunicarse con la red del cliente o a través de ella:
+ **Red de enlace de servicio**: asigna las direcciones IP del enlace de servicio a los servidores de Outpost y facilita la comunicación con la red local para permitir que los servidores se conecten de nuevo a los puntos de anclaje de Outpost en la región. Si tienes múltiples implementaciones de rack en un único Outposts lógico, necesitas asignar un CIDR de Service Link /26 para cada rack.
+ **Red de puerta de enlace local**: permite la comunicación entre las subredes de VPC de Outposts y la red en las instalaciones a través de la puerta de enlace local (LGW) de Outposts.
[Estas redes segregadas se conectan a la red local mediante un conjunto de conexiones IP a través de point-to-point los enlaces LAG.](https://docs.aws.amazon.com/outposts/latest/userguide/local-network-connectivity.html#network-layer-connectivity) Cada enlace LAG de OND a CND se configura con VLAN IDs, subredes IP point-to-point (/30 o /31) y emparejamiento eBGP para cada red segregada (enlace de servicio y LGW). Debe considerar los enlaces LAG, con sus subredes y subredes, como conexiones de capa 3 enrutadas point-to-point VLANs y segmentadas de capa 2. Las conexiones IP enrutadas proporcionan rutas lógicas redundantes que facilitan la comunicación entre las redes segregadas de Outposts y la red en las instalaciones.
![\[Diagrama que muestra la interconexión de enlaces de servicio\]](http://docs.aws.amazon.com/es_es/whitepapers/latest/aws-outposts-high-availability-design/images/service-link-peering.png)
![\[Diagrama que muestra la interconexión de una puerta de enlace local\]](http://docs.aws.amazon.com/es_es/whitepapers/latest/aws-outposts-high-availability-design/images/page-20-local-gateway-peering.png)
Debe terminar los enlaces LAG de capa 2 (y sus enlaces VLANs) en los conmutadores CND conectados directamente y configurar las interfaces IP y la interconexión BGP en los conmutadores CND. No debe conectar el LAG entre los conmutadores de su centro de datos VLANs . Para obtener más información, consulte [Conectividad de la capa de red](https://docs.aws.amazon.com/outposts/latest/userguide/local-network-connectivity.html#network-layer-connectivity) en la *Guía del usuario de AWS Outposts *.
Dentro de un Outpost lógico con varios racks, ONDs están interconectados de forma redundante para ofrecer una conectividad de red de alta disponibilidad entre los racks y las cargas de trabajo que se ejecutan en los servidores. AWS es responsable de la disponibilidad de la red en el Outpost.
## Prácticas recomendadas para una conexión de red de alta disponibilidad sin ACE
+ Cada dispositivo de red de Outposts (OND) de un bastidor de Outposts debe conectarse a un dispositivo de red del cliente (CND) independiente del centro de datos.
+ Termine los enlaces de capa 2 VLANs, las subredes IP de capa 3 y la interconexión BGP en los conmutadores de dispositivos de red del cliente (CND) conectados directamente. No conecte el OND con el CND entre la red local o a través de ella VLANs . CNDs
+ Agregue enlaces a los grupos de agregación de enlaces (LAGs) para aumentar el ancho de banda disponible entre el puesto de avanzada y el centro de datos. No confíe en el ancho de banda agregado de las diversas rutas que atraviesan ambos ONDs.
+ Utilice las diversas rutas a través de la redundante ONDs para proporcionar una conectividad flexible entre las redes de Outpost y la red local.
+ Para lograr una redundancia óptima y permitir un mantenimiento de los OND sin interrupciones, recomendamos que los clientes configuren los anuncios y las políticas de BGP de la siguiente manera:
+ El equipo de red del cliente debe recibir anuncios de BGP de Outpost sin cambiar los atributos de BGP y habilitar el BGP en caso de que sea necesario realizar tareas de mantenimiento. multipath/load-balancing to achieve optimal inbound traffic flows (from customer towards Outpost). AS-Path prepending is used for Outpost BGP prefixes to shift traffic away from a particular OND/uplink La red del cliente debería preferir las rutas de Outposts con una longitud del atributo AS-Path de 1 a las rutas con una longitud del atributo AS-Path de 4; es decir, debe reaccionar al atributo AS-Path.
+ La red de clientes debe anunciar en Outpost prefijos BGP iguales con los mismos atributos. ONDs De forma predeterminada, la carga de red de Outposts equilibra el tráfico saliente (hacia el cliente) de todos los enlaces ascendentes. Las políticas de enrutamiento se utilizan en Outposts para desviar el tráfico de un OND en particular en caso de que sea necesario realizar tareas de mantenimiento. Para realizar este cambio de tráfico y realizar el mantenimiento de forma no disruptiva, ONDs se requieren prefijos BGP iguales por parte del cliente. Cuando sea necesario realizar tareas de mantenimiento en la red del cliente, recomendamos utilizar prefijos con el atributo AS-Path a fin de desviar temporalmente el tráfico procedente de un enlace ascendente o dispositivo concreto.
## Prácticas recomendadas para una conexión de red de alta disponibilidad con ACE
Para una implementación de varios racks con cuatro o más racks de cómputo, debe usar el rack Aggregation, Core y Edge (ACE), que actuará como punto de agregación de la red para reducir la cantidad de enlaces de fibra a los dispositivos de red locales. El rack ACE proporciona la conectividad a cada rack de Outposts, por lo que AWS será propietario de la asignación y configuración de la interfaz VLAN entre ONDs los dispositivos de red ACE. ONDs
Se siguen necesitando capas de red aisladas para las redes Service Link y Local Gateway, independientemente de si se utiliza o no un rack ACE, cuyo objetivo es tener una VLAN point-to-point (/30 o /31), subredes IP y una configuración de interconexión eBGP para cada red segregada. Las arquitecturas propuestas deben seguir cualquiera de las dos arquitecturas siguientes:
![\[Dispositivos de red para dos clientes\]](http://docs.aws.amazon.com/es_es/whitepapers/latest/aws-outposts-high-availability-design/images/page-22-two-customer-networking-devices.png)
+ Con esta arquitectura, el cliente debe tener dos dispositivos de red (CND) para interconectar los dispositivos de red ACE, lo que proporciona redundancia.
+ Para cada conexión física, debe habilitar un LAG (para aumentar el ancho de banda disponible entre el Outpost y el centro de datos), incluso si se trata de un único puerto físico, y transportará dos segmentos de red, con configuraciones de 2 point-to-point VLANs (/30 o /31) y eBGP entre y. ACEs CNDs
+ En un estado estable, la carga del tráfico se equilibra siguiendo el to/from the customer network from the ACE layer, 25% traffic distribution across the ACE to customer. In order to allow this behavior, the eBGP peering’s between ACEs and CNDs must have BGP multipath/load equilibrio de patrones de rutas múltiples de igual costo (ECMP) habilitado y se anuncian los prefijos del cliente con la misma métrica de BGP en las 4 conexiones de emparejamiento eBGP.
+ Para lograr una redundancia óptima y permitir un mantenimiento del OND sin interrupciones, recomendamos a los clientes que sigan estas recomendaciones:
+ El dispositivo de red del cliente debe anunciar prefijos BGP iguales con los mismos atributos en todos los anuncios de Outpost. ONDs
+ El dispositivo de red del cliente debe recibir anuncios de BGP de Outpost sin cambiar los atributos de BGP y habilitar el equilibrio de carga y rutas múltiples de BGP.
![\[Dispositivos de red para cuatro clientes\]](http://docs.aws.amazon.com/es_es/whitepapers/latest/aws-outposts-high-availability-design/images/page-23-four-customer-networking-devices.png)
Con esta arquitectura, el cliente dispondrá de cuatro dispositivos de red (CND) para interconectar los dispositivos de red ACE, lo que proporcionará redundancia y la misma lógica de red VLANs, incluidos eBGP y ECMP aplicables a una arquitectura de 2 CND.
# Conectividad de anclaje
Un [enlace de servicio de Outpost](https://docs.aws.amazon.com/outposts/latest/userguide/region-connectivity.html) se conecta a puntos de anclaje públicos o privados (no a ambos) en una zona de disponibilidad (AZ) específica de la región principal del Outpost. Los servidores de Outpost inician las conexiones VPN de enlace de servicio saliente desde sus direcciones IP de enlace de servicio hasta los puntos de anclaje de la AZ de anclaje. Estas conexiones utilizan los puertos UDP y TCP 443. AWS es responsable de la disponibilidad de los puntos de anclaje en la Región.
Debe asegurarse de que las direcciones IP del enlace del servicio Outpost puedan conectarse a través de su red a los puntos de anclaje de la zona de anclaje. Las direcciones IP del enlace de servicio no necesitan comunicarse con otros hosts de la red local.
Los puntos de anclaje públicos residen en los [rangos de IP públicas](https://docs.aws.amazon.com/general/latest/gr/aws-ip-ranges.html) de la región (en los bloques CIDR del EC2 servicio) y se puede acceder a ellos a través de Internet o de las interfaces virtuales públicas [AWS Direct Connect](https://aws.amazon.com/directconnect/)(DX) (VIFs). El uso de puntos de anclaje públicos permite una selección de rutas más flexible, ya que el tráfico del enlace de servicio se puede enrutar por cualquier ruta disponible que pueda llegar correctamente a los puntos de anclaje de la Internet pública.
Los puntos de anclaje privados permiten usar al usuario sus propios rangos de direcciones IP para establecer la conectividad de anclaje. Los puntos de anclaje privados se crean en una [subred privada dentro de una VPC dedicada](https://docs.aws.amazon.com/outposts/latest/userguide/region-connectivity.html#private-connectivity) mediante direcciones IP asignadas por el cliente. La VPC se crea en la VPC propietaria del recurso Outpost y usted es responsable de garantizar Cuenta de AWS que la VPC esté disponible y configurada correctamente. [Utilice una política de control de seguridad (SCP) en AWSOrigamiServiceGateway Organizations para evitar que los usuarios eliminen esa Virtual Private Cloud (VPC). Se debe acceder a los puntos de anclaje privados mediante Direct Connect private. VIFs](https://aws.amazon.com/blogs/networking-and-content-delivery/introducing-aws-outposts-private-connectivity/)
Se deben aprovisionar rutas de red redundantes entre Outposts y los puntos de anclaje de la región, con conexiones que terminen en dispositivos independientes de más de una ubicación. Se debe configurar el direccionamiento dinámico para redirigir automáticamente el tráfico a rutas alternativas cuando las conexiones o los dispositivos de red fallen. Se debe aprovisionar una capacidad de red suficiente para garantizar que un error en una ruta WAN no sobrecargue las rutas restantes.
El siguiente diagrama muestra tres Outposts con rutas de red redundantes hasta su punto de anclaje AZs , AWS Direct Connect además de conectividad pública a Internet. Las instancias de Outposts A y B están ancladas a diferentes zonas de disponibilidad de la misma región. La instancia de Outposts A se conecta a puntos de anclaje privados en la AZ 1 de la región 1. La instancia de Outposts B se conecta a puntos de anclaje públicos en la AZ 2 de la región 1. La instancia de Outposts B se conecta a puntos de anclaje públicos en la AZ 2 de la región 1.
![\[El diagrama muestra la conectividad de anclaje de alta disponibilidad AWS Direct Connect y el acceso público a Internet\]](http://docs.aws.amazon.com/es_es/whitepapers/latest/aws-outposts-high-availability-design/images/highly-available-anchor-connectivity.png)
La instancia de Outposts A tiene tres rutas de red redundantes para llegar al punto de anclaje privado. Hay dos rutas disponibles a través de circuitos de Direct Connect redundantes en una única ubicación de Direct Connect. La tercera ruta está disponible a través de un circuito de Direct Connect en una segunda ubicación de Direct Connect. Este diseño mantiene el tráfico del enlace de servicio del Outpost A en las redes privadas y proporciona una redundancia de rutas que permite el fallo de cualquiera de los circuitos de Direct Connect o el fallo de toda una ubicación de Direct Connect.
La instancia de Outposts B tiene cuatro rutas de red redundantes para llegar al punto de anclaje privado. Hay tres rutas disponibles a través de VIFs aprovisionamiento público en los circuitos y ubicaciones de Direct Connect utilizados por Outpost A. La cuarta ruta está disponible a través de la WAN del cliente y la Internet pública. El tráfico del enlace de servicio de Outpost B puede enrutarse a través de cualquier ruta disponible que pueda llegar correctamente a los puntos de anclaje de la Internet pública. El uso de las rutas Direct Connect puede proporcionar una latencia más coherente y una mayor disponibilidad de ancho de banda, mientras que la ruta de Internet pública se puede usar para la recuperación de desastres o aumentar el ancho de banda.
La instancia de Outposts C tiene dos rutas de red redundantes para llegar al punto de anclaje privado. La instancia de Outposts C se encuentra implementada en un centro de datos diferente al de las instancias de Outposts A y B. El centro de datos de la instancia de Outposts C no tiene circuitos dedicados que se conecten a la WAN del cliente. En cambio, el centro de datos tiene conexiones a Internet redundantes proporcionadas por dos proveedores de servicios de Internet diferentes (). ISPs El tráfico del enlace de servicio de Outpost C puede enrutarse a través de cualquiera de las redes del ISP para llegar a los puntos de anclaje de la Internet pública. Este diseño ofrece flexibilidad para enrutar el tráfico de los enlaces de servicio a través de cualquier conexión pública a Internet disponible. Sin embargo, la end-to-end ruta depende de las redes públicas de terceros, donde la disponibilidad del ancho de banda y la latencia de la red fluctúan.
La ruta de red entre un Outpost y sus puntos de anclaje de enlace de servicio debe cumplir con la siguiente especificación de ancho de banda:
+ 500 Mbps: 1 Gbps de ancho de banda disponible por bastidor de Outposts (por ejemplo, para 3 bastidores, el ancho de banda disponible debe ser de entre 1,5 y 3 Gbps)
## Prácticas recomendadas para una conectividad de anclaje de alta disponibilidad
+ Proporcione rutas de red redundantes entre cada implementación de Outposts y sus puntos de anclaje en la región.
+ Utilice las rutas de Direct Connect (DX) para controlar la latencia y la disponibilidad del ancho de banda.
+ Asegúrese de que los puertos TCP y UDP 443 estén abiertos (salientes) desde los bloques CIDR de Outpost Service Link hasta los [rangos de direcciones EC2 IP](https://docs.aws.amazon.com/general/latest/gr/aws-ip-ranges.html) de la región principal. Confirme que los puertos estén abiertos en todas las rutas de red.
+ Realice un seguimiento de los rangos de direcciones EC2 IP de Amazon en su firewall si utiliza un subconjunto de rangos de CIDR para la región.
+ Compruebe que cada ruta cumple con los requisitos de latencia y disponibilidad de ancho de banda específicos.
+ Utilice el direccionamiento dinámico para automatizar el redireccionamiento del tráfico en caso de producirse errores en la red.
+ Pruebe a enrutar el tráfico del enlace de servicio a través de cada ruta de red planificada para asegurarse de que la ruta funcione según lo esperado.
# Enrutamiento de aplicaciones y cargas de trabajo
Hay dos rutas de salida de Outposts para las cargas de trabajo de las aplicaciones:
+ La ruta del enlace del servicio: tenga en cuenta que el tráfico de las aplicaciones competirá con el tráfico del plano de control de Outposts, además de limitar la [MTU a 1300 bytes](https://docs.aws.amazon.com/outposts/latest/userguide/region-connectivity.html#service-links).
+ La ruta de la puerta de enlace local (LGW): tenga en cuenta que la red local del cliente permite el acceso tanto a las aplicaciones locales como a las que se encuentran en la misma. Región de AWS
Las tablas de enrutamiento de la subred de Outposts se configuran para controlar la ruta que se debe seguir para llegar a las redes de destino. Las rutas que apuntan a la LGW dirigirán el tráfico desde la puerta de enlace local hacia la red en las instalaciones. Las rutas que apuntan a los servicios y recursos de la región, como Internet Gateway, NAT Gateway, Virtual Private Gateway y TGW, utilizarán [Service Link](https://docs.aws.amazon.com/outposts/latest/userguide/region-connectivity.html) para alcanzar estos objetivos. Si tienes una conexión de emparejamiento de VPC con varias VPCs en el mismo Outpost, el tráfico entre ellas VPCs permanece en el Outpost y no utiliza el enlace del servicio para volver a la región. *Para obtener información sobre la interconexión de VPC, consulte Conectarse [mediante la interconexión de VPCs VPC en la Guía del usuario](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-peering.html) de Amazon VPC.*
![\[Diagrama que muestra una visualización del enlace del servicio Outpost y de las rutas de red LGW\]](http://docs.aws.amazon.com/es_es/whitepapers/latest/aws-outposts-high-availability-design/images/outpost-service-link-and-lgw-network-paths.png)
A la hora de planificar el enrutamiento de las aplicaciones, se debe tener en cuenta tanto el funcionamiento normal como la disponibilidad limitada del servicio y el enrutamiento cuando se producen errores en la red. La ruta de enlace de servicio no está disponible si Outposts está desconectado de la región.
Se deben aprovisionar diversas rutas y configurar el direccionamiento dinámico entre la LGW de Outposts y las aplicaciones, sistemas y usuarios esenciales en las instalaciones. Las rutas de red redundantes permiten a la red redirigir el tráfico en caso de error y garantizar que los recursos en las instalaciones puedan comunicarse con las cargas de trabajo que se ejecutan en Outposts en caso de que la red falle parcialmente.
Las configuraciones de enrutamiento de las VPC de Outposts son estáticas. Las tablas de enrutamiento de subred se configuran mediante la Consola de administración de AWS CLI y otras herramientas de infraestructura como código (IaC); sin embargo, no podrá modificar las tablas de enrutamiento de subred durante un evento de desconexión. APIs Deberá restablecerse la conectividad entre Outposts y la región para que las tablas de enrutamiento puedan actualizarse. Deben usarse las mismas rutas para las operaciones normales que las previstas para los eventos de desconexión.
Los recursos del Outpost pueden acceder a Internet a través del enlace de servicio y una puerta de enlace de Internet (IGW) en la región o a través de la ruta de puerta de enlace local (LGW). Enrutar el tráfico de Internet a través de la ruta LGW y la red local permite utilizar los puntos de entrada y salida de Internet locales existentes y puede ofrecer una latencia más baja y unos costes de salida de AWS datos más altos MTUs y reducidos en comparación con el uso de la ruta de enlace de servicio a una IGW de la región.
Si la aplicación debe ejecutarse en las instalaciones y es necesario que se pueda acceder a ella desde la Internet pública, el tráfico de la aplicación se debe enrutar a través de las conexiones a Internet en las instalaciones hasta la LGW con el objetivo de llegar a los recursos de Outposts.
Si bien se pueden configurar las subredes en Outposts como subredes públicas de la región, no representa la práctica más deseable para la mayoría de los casos de uso. El tráfico de Internet entrante entrará por el enlace de servicio Región de AWS y se enrutará a través del enlace de servicio hasta los recursos que se encuentran en el Outpost.
El tráfico de respuesta, a su vez, se enrutará a través del enlace del servicio y regresará a través de las conexiones a Internet del Región de AWS servicio. Este patrón de tráfico puede aumentar la latencia e incurrir en gastos de salida de datos cuando el tráfico salga de la región en dirección a Outposts y el tráfico de retorno vuelva a través de la región hacia Internet. Si la aplicación se puede ejecutar en la región, será el mejor lugar para ejecutarla.
El tráfico entre los recursos de la VPC (en la misma VPC) siempre seguirá la ruta CIDR de la VPC local y los enrutadores de VPC implícitos lo redirigirán entre las subredes.
Por ejemplo, el tráfico entre una EC2 instancia que se ejecuta en Outpost y un punto final de VPC en la región siempre se enrutará a través del enlace de servicio.
![\[Diagrama que muestra el enrutamiento de la VPC local a través de enrutadores implícitos\]](http://docs.aws.amazon.com/es_es/whitepapers/latest/aws-outposts-high-availability-design/images/local-vpc-routing-through-implicit-routers.png)
## Prácticas recomendadas para el enrutamiento de aplicaciones y cargas de trabajo
+ Siempre que sea posible, utilice la ruta de la puerta de enlace local (LGW) en lugar de la ruta del enlace de servicio.
+ Enrute el tráfico de Internet a través de la ruta LGW.
+ Configure las tablas de enrutamiento de la subred de Outposts con un conjunto estándar de rutas; se usarán tanto para las operaciones normales como durante los eventos de desconexión.
+ Aprovisione rutas de red redundantes entre la LGW de Outposts y los recursos esenciales de las aplicaciones en las instalaciones. Utilice el direccionamiento dinámico para automatizar el redireccionamiento del tráfico en caso de producirse errores en la red en las instalaciones.