Planificación de IBM Cloud Transit Gateway

Revise las consideraciones siguientes antes de solicitar IBM Cloud® Transit Gateway.

Consideraciones generales

Todos los prefijos de una VPC y todas las subredes de una red clásica se conectarán a la puerta de enlace de tránsito, por lo que es importante que no se solapen. Al crear VPC que están pensadas para conectarse a una pasarela de tránsito, asegúrese de crear las VPC con prefijos de VPC no solapados.

  • IBM Cloud Transit Gateway da soporte a las pasarelas de tránsito de suministro en las regiones listadas en Ubicaciones de IBM Cloud Transit Gateway.
  • Cree la pasarela de tránsito en una ubicación que tenga sentido para la carga de trabajo. Por ejemplo, si está conectando dos VPC en la región us-south (Dallas) y una VPC en la región eu-de (Frankfurt), la creación de la pasarela en la región us-south sería la más eficaz para su carga de trabajo.
  • No es posible conectar una VPC de acceso clásico directamente a una puerta de enlace de tránsito. Para conectar los recursos clásicos, utilice la conexión de la infraestructura clásica de IBM Cloud y, a continuación, se conectan automáticamente todos los recursos de la VPC de acceso clásico.
  • Una pasarela de tránsito requiere al menos dos conexiones antes de que el tráfico de red pueda fluir a través de la pasarela de tránsito. Las pasarelas de tránsito que tienen menos de dos conexiones durante 45 días o más están sujetas a ser reclamadas (suspendidas y luego suprimidas después de 30 días).
  • Puede conectar una VPC, un Direct Link o una infraestructura clásica a varias puertas de enlace locales y a una única puerta de enlace global.
  • Las pasarelas de tránsito y sus conexiones pueden tardar varios minutos a estar disponibles después del suministro.
  • Sea descriptivo al dar un nombre a las conexiones de la pasarela de tránsito. Al conectarse a los recursos de diferentes cuentas, debe especificar un nombre de conexión. Al conectarse a los recursos en la misma cuenta que la pasarela de tránsito, el nombre de VPC o la palabra 'clásico' es la selección predeterminada y se puede modificar.
  • IBM Cloud Transit Gateway es una aplicación de varios arrendatarios, donde una sola instancia del software y su infraestructura de soporte sirve a varios clientes. Como resultado, la supervisión de su uso de ancho de banda es importante. Si utiliza demasiado ancho de banda, la instancia de pasarela de tránsito puede suspenderse. Si sospecha que es el caso, compruebe el estado de conexión de la instancia de pasarela de tránsito para ver si tiene un estado Suspended. Si es así, póngase en contacto con el soporte para restablecerlo.
  • Los ASN siguientes están bloqueados en las conexiones de Transit Gateway Generic Routing Encapsulation (GRE) y Direct Link. Evite utilizar estos ASN en los dispositivos para que no se incluyan en las rutas anunciadas en la vía de acceso AS. El hecho de incluir estos ASN impide que las redes funcionen correctamente.

0, 13884, 36351, 64512, 64513, 65100,, 65200-65234, 65402-65433, 65500``65516, 65519, 65521, 65531 y 4201065000-4201065999

Consideraciones relativas al PECM

  • A la hora de planificar una configuración ECMP (Equal-Cost Multi-Path), hay que tener en cuenta que el rendimiento no varía de forma lineal con el número de enlaces directos. Por ejemplo, si conectas dos enlaces directos de 10 GB a una pasarela de tránsito compatible con ECMP, no obtienes un ancho de banda de 20 GB; el ancho de banda será superior a 10 GB, pero inferior a 20 GB. Esto se debe a que ECMP funciona por flujo o por origen, lo que significa que, si el tráfico procede de un único punto final, es probable que se dé prioridad a un enlace, y no a ambos. Para lograr un rendimiento más equilibrado, se recomienda canalizar el tráfico desde varias fuentes, ya que así la carga se distribuye de forma más uniforme entre los enlaces directos disponibles.

  • Limitación: ECMP no funciona para enlaces directos en un único router. En su lugar, se admite en varios routers con enlaces directos, siempre que dichos routers anuncien el mismo prefijo.

  • Restricción conocida: Las nuevas pasarelas de tránsito admiten ECMP de 4 vías, pero las pasarelas existentes no pueden utilizar esta función a menos que abra un caso de soporte para obtener ayuda.

    Si no desea que se active la función ECMP en sus puertas de enlace de tránsito, puede abrir un caso de soporte para que se le añada a una denylist, que desactivará esta función en sus puertas de enlace.

Consideraciones sobre precios

El estimador de costes IBM Cloud, situado en la página de aprovisionamiento Transit Gateway, no puede interpretar los tipos de conexión de red. Para obtener un presupuesto fiable, introduzca el número estimado de puertas de enlace y conexiones de tránsito. Tenga en cuenta que si crea un GRE redundante, cada túnel es una conexión individual que cuenta con el límite de conexiones.

Consideraciones de conexión de infraestructura clásica

  • Para utilizar una pasarela de tránsito para conectar las VPC a la infraestructura clásica de IBM Cloud, debe habilitar la cuenta clásica para el direccionamiento y el reenvío virtuales (VRF) y enlazarla a su cuenta de IBM Cloud. Para obtener información sobre la habilitación de la cuenta para VRF, consulte Habilitación de VRF y puntos finales de servicio.

  • Cuando conecta una VPC y la infraestructura clásica a una pasarela de tránsito, todos los prefijos de la VPC se hacen visibles para el VRF de infraestructura clásica, que utiliza direcciones de IP en el espacio 10.0.0.0/8. Para garantizar una conectividad correcta con la infraestructura clásica, no utilices prefijos en tus VPC que se solapen con los bloques 10.254.0.0/16 10.0.0.0/14, 10.200.0.0/14, 10.198.0.0/15, y. Tampoco utilice direcciones de las subredes de la infraestructura clásica. Para ver una lista de las subredes de infraestructura clásica, consulte Ver todas las subredes.

  • Las instancias de servidor virtual clásico pueden tener una interfaz de red privada (eth0) y pública (eth1). Actualmente, las tablas de direccionamiento para estas interfaces apuntan la pasarela predeterminada a la interfaz pública (eth1). Es posible que tenga que añadir entradas de direccionamiento para direccionar las subredes de otras VPC a través de la interfaz privada.

  • Se puede acceder a todas las redes de infraestructura clásicas de IBM Cloud en MZR mediante esta conexión, independientemente de la ubicación de la pasarela de tránsito o del tipo de direccionamiento especificado.

  • Los recursos de infraestructura clásica ubicados en estos centros de datos se conectan a través de una pasarela de tránsito a recursos de VPC.

  • Cuando la infraestructura clásica se conecta a una puerta de enlace de tránsito, también incluye cualquier VPC de Classic Access asociada a la cuenta, ya que las subredes de estas VPC están asociadas al VRF de la infraestructura clásica. Esta es la única forma de conectar una pasarela de tránsito a una VPC de acceso clásico: conectar toda la infraestructura clásica a la pasarela de tránsito (en lugar de las VPC de acceso clásico específicas).

  • Las conexiones clásicas que residen en el mismo centro de datos no pueden comunicarse entre sí si están en una región distinta de la pasarela de tránsito.

Consideraciones sobre el filtrado de prefijos

  • Los filtros de prefijo son compatibles con todos los tipos de conexión Transit Gateway excepto las conexiones de túnel GRE heredadas. En el caso de las conexiones GRE, el filtrado de prefijos es compatible con los tipos de conexión GRE redundante y GRE no vinculante.
  • Para las conexiones que no son GRE, el propietario de la red puede añadir filtros de prefijo. Para las conexiones GRE, sólo el propietario de Transit Gateway puede añadir o modificar filtros de prefijo, lo cual es una consideración importante para las conexiones entre cuentas.
  • Para las conexiones entre cuentas, solo el propietario de la cuenta de la conexión correspondiente puede modificar los filtros de prefijo. Otras cuentas pueden ver la conexión, pero no pueden modificar los filtros.
  • No se pueden filtrar los prefijos entrantes procedentes de otra cuenta.
  • Para conexiones GRE redundantes y pasarelas VPN, los filtros de prefijo sólo pueden configurarse en la conexión de nivel superior. Los túneles individuales bajo estas conexiones no admiten filtros de prefijo independientes; cualquier filtro aplicado en el nivel superior se aplicará a todos los túneles asociados.
  • Los filtros de prefijo de la lista se procesan secuencialmente. Puede modificar el pedido en cualquier momento.
  • Si seleccionas Solicitar conexión a una red de otra cuenta como opción de alcance de conexión, no podrás configurar filtros de prefijo, ya que no eres el propietario de la red para esa conexión. Los filtros de prefijo deben configurarse en la cuenta propietaria de la red. Para las conexiones GRE, sólo el propietario de Transit Gateway puede establecer filtros de prefijo al crear la conexión.
  • Las máscaras de subred de filtro de prefijo son específicas. Por ejemplo, una regla definida como no 10.10.20.0/24 coincide con la subred 10.10.20.0/28 ni con ningún otro prefijo de subred.
  • Revise los límites de prefijo de servicio para las pasarelas de tránsito.

Consideraciones sobre la conexión GRE (Generic Routing Encapsulation)

Revise las consideraciones siguientes para la conexión GRE concreta.

Consideraciones generales sobre la conexión GRE

  • Al configurar un túnel GRE, debe especificar una zona de disponibilidad en la que crear el túnel. Debido a esto, si por alguna razón esa zona no está disponible, cualquier red conectada a través de un túnel GRE en esa zona es inalcanzable. Para configurar un túnel GRE de alta disponibilidad, debe crear un túnel GRE en varias zonas, conectando los mismos puntos finales.
  • Las conexiones GRE requieren el uso de un servicio BGP entre direcciones IP de túnel GRE. La pasarela de tránsito configura un servicio BGP en la conexión de túnel, antes de conectarse al otro punto final de túnel. A continuación, una vez que el protocolo BGP intercambia rutas entre el punto final conectado y la pasarela de tránsito, el túnel GRE se convierte en la vía de acceso de datos para el tráfico direccionado.
  • Las rutas del túnel GRE se aprenden directamente en las sesiones BGP establecidas a través del túnel. Por este motivo, el filtrado de prefijos no está habilitado para estas conexiones.
  • El número de túneles GRE conectados a una pasarela de tránsito está limitado por la cuota. La cuota predeterminada es 12.
  • Si utiliza rutas de igual coste entre GRE y Direct Link (la misma longitud de ruta), se prefiere Direct Link en lugar de equilibrar la carga entre GRE y Direct Link.

Consideraciones sobre la propagación de rutas mejorada con GRE

La propagación mejorada de rutas GRE controla si los túneles GRE conectados a la misma pasarela de tránsito pueden aprender rutas unos de otros, cuando están entre zonas o dentro de un par GRE redundante (RGRE).

Cuando cree o actualice una pasarela de tránsito, evalúe si los túneles GRE deben poder compartir rutas. La activación del conmutador de propagación de ruta mejorada GRE permite la interconectividad entre GRE en la misma pasarela de tránsito y puede reducir la necesidad de configuraciones de túnel redundantes. Dependiendo de su topología, esta configuración puede introducir cambios significativos en cómo se propagan las rutas y cómo fluye el tráfico.

Activar o desactivar este conmutador puede provocar cambios inmediatos en la propagación de rutas. Asegúrese de comprender el impacto antes de realizar cambios en un entorno de producción.

Cuando el conmutador está desactivado:

  • Los túneles GRE en el mismo RGRE no aprenden rutas unos de otros.
  • Los túneles GRE no enlazados que aterrizan en diferentes zonas de entrada de tránsito no aprenden rutas entre sí.
  • Los túneles GRE de la misma zona siguen aprendiendo rutas unos de otros.

Esta configuración limita la propagación de rutas entre túneles GRE, pero no proporciona un aislamiento estricto de la red ni garantiza una separación forzosa.

Cuando el interruptor está activado:

  • Los túneles GRE de un par RGRE aprenden rutas entre sí, aunque estén en la misma zona.
  • Los GRE no vinculados en diferentes zonas de pasarela de tránsito también aprenden rutas unos de otros, lo que permite la propagación de rutas entre zonas.

Esta configuración permite a los GRE aprender rutas de otros GRE, a través de zonas o dentro del mismo RGRE, lo que puede cambiar cómo se propagan las rutas y cómo fluye el tráfico a través de su red.

Consideraciones sobre GRE redundante

  • Un GRE redundante es esencialmente una agrupación de al menos dos túneles GRE.

  • El número de túneles no puede exceder de dos por zona.

  • Puede colocar los túneles dentro de un GRE redundante en la misma zona o en zonas diferentes.

  • Todas las conexiones y túneles de la pasarela de tránsito deben tener nombres exclusivos.

  • Todos los túneles de un GRE redundante se dirigen a la misma red y cuenta.

  • Cuando se utiliza el tipo de red base VPC:

    • Debe habilitar el distintivo de suplantación de IP para el tipo de red de VPC. Para obtener información sobre cómo habilitar comprobaciones de suplantación de IP, consulte Acerca de la suplantación de IP.
    • El perfil de interfaz de servidor virtual debe ser v2.
    • La IP de pasarela local:
      • Debe cumplir con RFC 1918 (o no hay IP flotantes o pasarelas públicas en la VPC).
      • No debe ser una dirección IP dentro del rango de multidifusión de 224.0.0.0 a 239.255.255.255 y no puede estar en conflicto con ninguna red existente que esté conectada a la pasarela de tránsito.
      • No se puede utilizar como local-gateway-ip para otro GRE que utilice la misma red subyacente.
  • GRE propagación de rutas mejorada:

    • Cuando está desactivado (por defecto), todos los túneles dentro de un GRE redundante no tienen sus rutas propagadas entre sí y no pueden comunicarse entre sí. Sin embargo, los túneles GRE redundantes pueden tener sus rutas propagadas a los túneles GRE fuera del GRE redundante que están conectados a la misma pasarela de tránsito y están en la misma zona.

    • Cuando está activado, todos los túneles GRE propagan sus rutas a otros GRE si están conectados a la misma pasarela de tránsito.

Consideraciones sobre túneles GRE no enlazados

  • Las rutas clásicas se anuncian a través de un túnel GRE desenlazado.
  • Puede comunicarse a través de otros túneles GRE no enlazados conectados a la misma pasarela de tránsito en la misma zona de disponibilidad.
  • Los túneles GRE no unidos en la misma pasarela de tránsito, ubicados en diferentes zonas de disponibilidad, no pueden comunicarse a menos que esté activada la propagación de ruta mejorada GRE. Sin embargo, no se debe confiar en la propagación de rutas GRE mejorada para aislar la red, ya que la ausencia de tráfico GRE no enlazado entre zonas no garantiza una separación forzosa.

Si necesita aislamiento de red, considere la posibilidad de utilizar pasarelas de tránsito separadas.

  • No requiere una conexión clásica en la pasarela de tránsito. Las subredes de red clásica no se anuncian a las conexiones de la pasarela de tránsito (ni viceversa).
  • El número predeterminado de redes base exclusivas que pueden ser objetivo de túneles GRE no enlazados está limitado a cinco. Si necesitas ampliar estos límites del servicio, puedes abrir un caso de soporte técnico en IBM.

Para obtener más información y ver un ejemplo de caso práctico, consulta Conectar redes mediante un túnel GRE de alta disponibilidad.

Consideraciones sobre GRE de legado

  • Las rutas clásicas no se anuncian a través de un túnel GRE heredado.
  • No se puede comunicar a través de otros túneles GRE en la misma pasarela de tránsito.
  • Requerir una conexión clásica en la pasarela de tránsito antes de la creación. Como resultado, todas las subredes clásicas se anunciarán a todas las conexiones conectadas a la pasarela de tránsito, así como a cualquier otra subred de la conexión en la red clásica.

Direct Link Consideraciones sobre la conexión

Puede crear conexiones de Direct Link a una pasarela de tránsito para permitir que las redes locales se conecten a otras redes en IBM Cloud. Después de que el enlace directo se conecta a la pasarela de tránsito, la red local recibe acceso a todas las demás conexiones de pasarela de tránsito. Asimismo, todas las demás redes conectadas a la pasarela de tránsito tienen acceso a la red local. Las conexiones de Direct Link siguen el mismo proceso para conexiones cruzadas físicas o virtuales que la oferta estándar de Direct Link. Una vez suprimida la conexión de una pasarela de tránsito, la pasarela de tránsito funciona como si nunca hubiera estado conectada a un enlace directo.

Las mismas consideraciones de subred de red para las conexiones de pasarela de tránsito también se aplican a las conexiones de Direct Link. Para garantizar una conectividad correcta, no utilices prefijos en tu red conectada a Direct Link que se solapen con otras conexiones.

Consideraciones sobre la conexión de Power Virtual Server

Puede conectar una instancia de Power Virtual Server a una pasarela de tránsito. Esto le permite conectar directamente Power Virtual Server a una pasarela de tránsito en sentido descendente. Una vez que el servicio « Power Virtual Server » se haya conectado a la pasarela de tránsito, su instancia del servicio « Power Virtual Server » tendrá acceso a todos los recursos y servicios de la pasarela de tránsito situados más abajo en la cadena. Del mismo modo, todas las redes de destino conectadas a la puerta de enlace de tránsito tienen acceso a la instancia de Power Virtual Server.

Las conexiones Power Virtual Server pueden utilizar el direccionamiento local o global. Sin embargo, sólo las instancias de Power Virtual Server de la misma región que la pasarela de tránsito pueden utilizar el direccionamiento local. Además, una instancia de Power Virtual Server se puede conectar a varias pasarelas de tránsito con direccionamiento local, pero sólo una pasarela de tránsito con direccionamiento global. Los servicios en sentido descendente respetarán la preferencia de ruta basada en el tipo de pasarela de tránsito.

Las mismas consideraciones sobre subredes que se aplican a las conexiones de pasarela de tránsito también se aplican a las conexiones de Power Virtual Server. Para garantizar el éxito de la conectividad, no utilice prefijos en su instancia Power Virtual Server que se solapen con otras conexiones. Tenga en cuenta que Transit Gateway proporciona filtrado de prefijos para limitar los prefijos que se exponen, así como un informe de la tabla de enrutamiento para ver cualquier solapamiento después de crear la conexión.

Consideraciones sobre la conexión a la pasarela VPN

Puede crear conexiones de pasarela VPN a una pasarela de tránsito para permitir que las redes locales o externas se conecten con otras redes en IBM Cloud. La pasarela VPN actúa como un radio dentro de la arquitectura de pasarela de tránsito, lo que permite un peering eficiente a través de múltiples redes al tiempo que reduce la complejidad del túnel. Este diseño utiliza enrutamiento dinámico con eBGP sobre túneles GRE redundantes para proporcionar conectividad escalable y resistente.

  • Cada conexión de pasarela VPN aprovisiona automáticamente cuatro túneles GRE redundantes entre la pasarela VPN y la pasarela de tránsito. IBM gestiona estos túneles, con sesiones eBGP que se ejecutan sobre ellos para el enrutamiento dinámico. La conectividad local utiliza eBGP sobre túneles IPsec para una comunicación segura. Aunque puede crear, eliminar y renombrar conexiones de pasarela VPN, no puede modificar ni eliminar los túneles GRE individuales.

  • El precio se basa en el coste de 4 túneles GRE por conexión más los gastos de tráfico de datos.

  • Las conexiones de pasarela VPN están limitadas por defecto a 4 por pasarela de tránsito y 2 por zona.

  • Las conexiones de pasarela VPN no admiten el filtrado de prefijos. Usted es responsable de gestionar cualquier filtrado de rutas en su lado de la sesión BGP.

  • Puede crear conexiones VPN dinámicas o estáticas en cualquier momento. Las conexiones estáticas funcionan con o sin pasarela de tránsito. Las conexiones dinámicas requieren que la pasarela VPN esté conectada a una pasarela de tránsito antes de que el tráfico pueda fluir.

  • Después de conectar una pasarela VPN a una pasarela de tránsito, el ASN local no se puede cambiar.

  • Para configurar una VPN como copia de seguridad de una conexión Direct Link, debe asegurarse de que se prefieren las rutas de Direct Link. Para ello, puede aprovechar mecanismos como AS Path prepending o MED (Multi-Exit Discriminator) en su dispositivo local.

  • Cuando se crea una conexión de puerta de enlace VPN, es necesario definir un bloque CIDR para las direcciones IP del túnel GRE. Se recomienda utilizar un rango de direcciones privadas RFC 1918, ya que no requiere una ruta Delegate-VPC adicional. El bloque CIDR debe tener un mínimo de /27 y no debe solaparse con ningún otro CIDR de conexión configurado en la pasarela de tránsito.

    Si asigna un CIDR a una pasarela VPN que está fuera de los rangos IP privados estándar (10.0.0.0/8, 172.16.0.0/12, o 192.168.0.0/16), debe añadir manualmente rutas en la tabla de enrutamiento de la VPC (en la misma zona que la pasarela VPN) para permitir un flujo de tráfico adecuado. Tiene dos opciones:

    • Añada una única ruta con el destino establecido en el CIDR completo asignado a la VPN (por ejemplo, 100.31.128.0/18) y la acción establecida en Delegate-VPC.
    • Añada cuatro rutas separadas, cada una dirigida a la IP de la puerta de enlace local de cada túnel VPN (por ejemplo, 100.31.128.1/32) con la acción establecida como Delegate-VPC.

    La primera opción es más sencilla, mientras que la segunda ofrece un control de enrutamiento más granular, que podría ser preferible en diseños de red avanzados o para la resolución de problemas.

Consideraciones sobre VPC

  • IBM Cloud VPC permite el uso de direcciones RFC-1918 y del espacio de direcciones IPv4 registradas en la IANA, de forma privada dentro de su VPC, con algunas excepciones en los rangos de la IANA destinados a fines especiales y en determinados rangos asignados a los servicios IBM Cloud. Cuando se utilizan rangos registrados por IANA dentro de la empresa, y dentro de las VPC junto con IBM Cloud Transit Gateway, se deben instalar rutas personalizadas en cada zona. Para obtener más información, consulte Direccionamiento de las consideraciones para asignaciones de IP registradas por IANA.

  • Puede crear una única pasarela de tránsito o varias pasarelas de tránsito para interconectar más de un VPC de IBM Cloud. También puede conectar la infraestructura clásica de IBM Cloud a una pasarela de tránsito para proporcionar una comunicación fluida con los recursos de la infraestructura clásica. Para obtener más información, consulte Interconexión de VPC.

  • Bare Metal en VPC no está soportado.

Consideraciones sobre direccionamiento

  • Todas las conexiones a una pasarela de tránsito están conectadas entre sí, por lo tanto, piense encarecidamente en todos los recursos que desee interconectar antes de decidir si el direccionamiento local o global sea el adecuado para cada pasarela.

    El tráfico procedente de cualquiera de las opciones de direccionamiento no sale de la red privada de IBM Cloud y está optimizado para el rendimiento.

  • Si tiene previsto utilizar la pasarela para conectar VPC en la misma región multizona (MZR), utilice el direccionamiento local para proporcionar conectividad para todos los recursos accesibles dentro de la misma MZR; por ejemplo, us-south (Dallas).

    ![](/images/1-aboutLocalRoutingExample.png "localEnrutamiento " caption-side="bottom"}"){: caption="de enrutamiento local

  • Si tiene previsto utilizar las pasarelas de tránsito para conectar VPC localmente y entre distintas MZR, utilice pasarelas locales para VPC en la misma MZR y una pasarela global para VPC entre MZR. Puede utilizar el ejemplo que sigue a un escenario de alta disponibilidad (HA). Todos los datos de las VPC A y B se pueden replicar en las VPC C y D. Si hay un problema en la región Sur de los Estados Unidos, las conexiones se redireccionan hacia el Este de los Estados Unidos.

    ![Enrutamiento globalEnrutamiento](/images/2-aboutLocalAndGlobalRoutingExample.png "y " caption-side="bottom"} de "){: caption="de enrutamiento local y global

    Independientemente del tipo de direccionamiento especificado, IBM Cloud Transit Gateway se puede conectar a las redes de infraestructura clásica de cualquier MZR. Para lograrlo, basta con añadir la conexión clásica a la pasarela de tránsito.

  • Puede editar el tipo de direccionamiento de una pasarela después de que se haya suministrado. Sin embargo, para cambiar el tipo de enrutamiento de Global a Local, primero debe eliminar cualquier conexión global (es decir, conexiones a recursos que no se encuentren en la misma ubicación que la pasarela). Tenga en cuenta que las conexiones con la infraestructura clásica de IBM Cloud siempre se consideran locales.

  • Al cambiar de enrutamiento local a global, se le cobrarán todas las conexiones globales asociadas. El tráfico de red no se ve afectado cuando se cambia el tipo de direccionamiento.

Consideraciones de informe de ruta

  • La ruta AS mostrada en un informe de ruta proporciona una perspectiva de zona única. Si el origen o el destino abarcan zonas diferentes, la longitud de la ruta puede variar. Por ejemplo, considere dos enlaces directos: uno en DAL10 y el otro en DAL12, ambos anunciando la misma longitud de ruta de AS hacia una pasarela de tránsito basada en DAL conectada a una VPC o entorno clásico. Cuando se llama desde una instancia de servidor virtual DAL10:

    • Se prefiere el enlace directo DAL10.
    • Para las conexiones procedentes de DAL12, se prefiere el enlace directo DAL12.
    • En el caso de DAL13, se obtendría un enrutamiento ECMP, suponiendo que la pasarela esté configurada para ello, o se utilizaría un único enlace directo. Sin embargo, durante un reinicio de BGP, podría cambiar al otro enlace directo.
  • Las rutas que se solapan son un problema común cuando se configura una pasarela de tránsito. Si las rutas de dos o más conexiones se solapan, es posible que el tráfico no se enrute según lo previsto. Para obtener más información, consulte Direccionamiento de conflictos de ruta.

  • Después de que una nueva conexión virtual (VPC, infraestructura clásica o Direct Link) alcance el estado Activo, espere 5 minutos para que la pasarela de tránsito aprenda las rutas. La generación de un informe de ruta antes de que se aprendan todas las rutas da como resultado un informe de ruta parcial.

  • Si una conexión expone una ruta de 0.0.0.0/0, dicha ruta se ignora al calcular los prefijos solapados.

  • Sólo hay un informe por pasarela disponible en cualquier momento. Si genera un informe nuevo, se suprime el informe antiguo.

  • Los informes de rutas antiguos pueden ser inexactos después de añadir o eliminar una conexión. En consecuencia, si actualiza las rutas dentro de esas conexiones, se recomienda que genere un nuevo informe de rutas.

  • Si una o más rutas son denegadas por filtros de prefijo, esas rutas no aparecen en el informe de rutas.

Límites de servicio

Tenga en cuenta los siguientes límites de servicio al utilizar IBM Cloud Transit Gateway.

Límites del servicioIBM Cloud Transit Gateway
Límite de servicio Valor predeterminado
Número de pasarelas de tránsito 10 pasarelas por cuenta, 5 pasarelas por región
Número de conexiones por pasarela de tránsito
  • 10 IBM Cloud VPC conexiones
  • 5 IBM Cloud conexiones clásicas
  • 5 IBM Cloud Direct Link conexiones
  • 5 Power Virtual Server conexiones
Número de prefijos por conexión
  • 50 prefijos para conexiones VPC
  • 120 prefijos para conexiones clásicas
  • 120 prefijos para conexiones GRE
  • 120 prefijos para conexiones Direct Link
  • 120 prefijos para conexiones Power Virtual Server
Número de conexiones con filtros de prefijo 2 conexiones con filtros de prefijo por pasarela
Número de filtros de prefijo por conexión 10 filtros de prefijo por conexión
Número de túneles GRE por pasarela de tránsito 12 túneles GRE por pasarela
Número de redes base exclusivas dirigidas por túneles GRE no enlazados por pasarela de tránsito 5 redes base exclusivas dirigidas por túneles GRE no enlazados por pasarela

Puede abrir un caso de soporte de IBM si necesita ampliar los límites de servicio.