Establecimiento de ejemplos de prioridad de ruta

• Si tiene una ruta con un prefijo /32 y una prioridad de 1, y una ruta con un destino de /31 y una prioridad 0, se utiliza /32 en primer lugar (coincidencia de prefijo más larga). En otras palabras, la prioridad sólo importa cuando hay más de una ruta con el mismo prefijo exacto.
• Si tiene tres rutas con 0.0.0.0/0 (ruta predeterminada), sólo se utiliza la ruta con la prioridad más alta. Si se elimina la ruta seleccionada (por ejemplo, mediante automatización), se selecciona la prioridad más alta de las dos rutas restantes.
• Si la tabla de enrutamiento personalizada tiene solo una ruta con un prefijo específico, esa ruta siempre se usa independientemente de su prioridad. La mejor selección de ruta se realiza para cada prefijo específico y elige la ruta con mayor prioridad.

El direccionamiento de varias vías de acceso de igual coste (ECMP) se utiliza cuando dos rutas tienen el mismo destino y prioridad (ampliando el comportamiento actual donde se utiliza ECMP para dos rutas con el mismo destino). Como máximo, se permite que dos rutas de una tabla de direccionamiento tengan el mismo destino y prioridad. Por ejemplo, si la tabla de direccionamiento personalizado tiene tres rutas con el mismo destino, una ruta con prioridad 1 y las otras dos rutas con prioridad 4 (ECMP), la ruta con prioridad 1 se selecciona y las rutas ECMP se ignoran (sin ECMP). Ahora, si las dos rutas con el mismo destino y prioridad tienen la prioridad más alta, el sistema selecciona estas dos rutas y realiza ECMP. A continuación, si se suprime una de estas rutas, la ruta que todavía existe se selecciona y no se realiza ECMP.

Para ver las limitaciones de prioridad de ruta, consulte Limitaciones y directrices.

Consideraciones sobre la ruta publicitaria

Tenga en cuenta las siguientes consideraciones al anunciar rutas:

• Puede anunciar rutas fuera del prefijo de dirección raíz asignado a la VPC, de modo que pueda anunciar sus redes externas o redes que residen fuera de la VPC a un Direct Link o Transit Gateway.

• Si hay varias Transit Gateways o Direct Links conectadas a su VPC, puede utilizar el filtrado de rutas en cada una de ellas. Transit Gateway o Direct Link conexiones para ajustar qué rutas se anuncian a qué conexiones.

• Si se anuncian varias rutas a un prefijo de destino con diferentes prioridades, la ruta con mayor prioridad (valor de prioridad menor) se usa como principal y la ruta con menor prioridad (valor de prioridad más alto) se usa como respaldo.

• Si anuncia dos rutas diferentes, como 172.16.0.0/31 a través de 10.1.1.0 y 172.16.0.0/32 a través de 10.1.2.0, la ruta con un /32 El prefijo siempre tiene prioridad sobre la ruta con un /31 prefijo. Esto es coherente con el conjunto de reglas "Cotejo de prefijo más largo". Siempre se prefiere un prefijo más largo para un destino de host a un prefijo más estrecho.

• Actualmente, no hay ningún mecanismo para señalar rutas duplicadas desde Transit Gateway o Direct Link. El Transit Gateway selecciona la mejor ruta utilizando el prefijo más específico y la ruta AS más corta, según se prefiera. De lo contrario, el Transit Gateway selecciona la ruta que recibió primero. Es posible que esta ruta no sea la ruta más antigua en el lado de VPC y puede cambiar si las rutas al Transit Gateway se actualizan internamente.

• Las rutas anunciadas desde una puerta de enlace VPN dependen del tipo de VPN. Las puertas de enlace VPN basadas en políticas no anuncian rutas de forma dinámica. Solo se propagan los prefijos CIDR definidos en la política VPN, y la tabla de enrutamiento debe configurarse para aceptar rutas desde la puerta de enlace VPN. Las puertas de enlace VPN basadas en rutas con BGP anuncian las rutas de forma dinámica.

  Cuando se anuncien rutas desde una tabla de enrutamiento que incluya conectividad VPN, asegúrese de que el tipo de puerta de enlace VPN admita el comportamiento de propagación de rutas previsto.

Caso de uso 1: cortafuegos de proxy Edge

{: caption="

Caso de uso 2: equilibrador de carga público

{: caption="

Caso de uso 3: VPN

Para tener una pasarela VPN como el siguiente salto en una tabla de direccionamiento de VPC, la pasarela se crea en una subred dedicada. Esta subred solo se utiliza para la pasarela VPN y se asocia con la subred de pasarela VPN con una tabla de direccionamiento diferente cuando hay una ruta 0.0.0.0/0 y el siguiente salto es una conexión de VPN.

Por ejemplo:

• La subred A se utiliza para alojar los servidores virtuales y está asociada con la tabla de direccionamiento predeterminada. Hay una ruta 0.0.0.0/0y el siguiente salto es una conexión de VPN.
• La subred B se utiliza para alojar la pasarela VPN y crea una nueva tabla de direccionamiento (tabla de direccionamiento B). Asocia la subred B con la tabla de direccionamiento B. De forma predeterminada, no necesita ninguna ruta en la tabla de direccionamiento B.

Para disponer de conectividad entre subredes cuando se tiene un « 0.0.0.0/0 » de ruta y el siguiente salto es una conexión VPN, puedes añadir las siguientes rutas delegadas:

destination CIDR==zone3 VPC prefix, action==delegate, location==zone1
destination CIDR==zone1 VPC prefix, action==delegate, location==zone3

Limitaciones generales

• Actualmente, no puede utilizar una tabla de direccionamiento personalizada para el tráfico de entrada (conectado a un origen de tráfico) y de salida (conectado a un subred). Además, la tabla de direccionamiento personalizada predeterminada no se puede asociar con un origen de tráfico de entrada.
• Actualmente, el tráfico de retorno puede fallar debido a un direccionamiento asimétrico. Este problema afecta a todos los servicios que dependen de rutas estáticas ECMP. Por ejemplo, supongamos que crea dos rutas ECMP en la VPC A con el destino 10.134.39.64/26 y los saltos siguientes son 192.168.2.4 y 192.168.2.5 respectivamente. Estos saltos siguientes son direcciones IP de dispositivo NFV. Cuando envía tráfico desde la instancia A en la VPC, el paquete se enruta aleatoriamente a uno de los siguientes saltos y no hay garantía de que el tráfico de retorno siga la misma ruta que el tráfico de reenvío debido al algoritmo hash ECMP en el otro lado. . Este fenómeno se conoce como direccionamiento asimétrico. Cuando se produce un enrutamiento asimétrico, el problema no está en el enrutamiento en sí, sino que el grupo de seguridad descarta el tráfico incluso si las reglas del grupo de seguridad lo permiten porque el grupo de seguridad ve el tráfico en una sola ruta. En general, es aconsejable evitar el uso de rutas ECMP.
• La capacidad de llegar a una dirección IP de salto siguiente en una ruta personalizada no es un factor determinante para la ruta se utilice para el tráfico de reenvío. Esto puede ocasionar problemas cuando se utilizan varias rutas con el mismo prefijo (pero distintas direcciones IP de siguiente salto), ya que es posible que no se entregue el tráfico a las direcciones IP de siguiente salto no accesibles.
• IBM Cloud VPC permite el uso privado de espacios de direcciones RFC-1918 y IPv4 registrados en la IANA dentro de su VPC, con algunas excepciones en los rangos de la IANA destinados a fines especiales y en determinados rangos asignados a servicios IBM Cloud. Cuando utiliza rangos registrados en IANA dentro de la empresa, y dentro de VPC junto con IBM Cloud Transit Gateway o IBM Cloud Direct Link, debe instalar rutas personalizadas en cada zona. Para obtener más información, consulte Direccionamiento de las consideraciones para asignaciones de IP registradas por IANA.
• En el caso de que existan 2 rutas anunciadas diferentes hacia el mismo destino, se aplican las siguientes limitaciones:
  • Cuando el siguiente salto para ambas rutas está en la misma zona, la ruta con mayor prioridad (es decir, un valor menor para priority ) se utiliza como ruta principal y la ruta con menor prioridad (es decir, un valor más alto para priority ) se utiliza como ruta de respaldo. Si la prioridad para ambas rutas es la misma, se utiliza ECMP para direccionar el tráfico por igual a través de las 2 rutas.
  • Cuando el salto siguiente para ambas rutas está en zonas diferentes, el direccionador Transit Gateway o Direct Link elige la mejor ruta. En este caso, esa es la ruta publicitada más antigua.

Prioridad de ruta

Si existen varias rutas con el mismo CIDR/prefijo de destino, se utiliza la ruta con el valor de prioridad más alto. Las rutas con el mismo CIDR/prefijo y prioridad de destino utilizan el direccionamiento ECMP.

Rutas de salida

Para las rutas personalizadas de salida, cuando añada una ruta de destino debe seleccionar una zona. Sin embargo, no es necesario que el siguiente esté en la misma zona. Para las rutas personalizadas de entrada, el siguiente salto debe estar en la misma zona.

Multivía de coste igual (ECMP)

El direccionador implícito realiza el direccionamiento ECMP (varias rutas con el mismo destino, pero distintas direcciones de siguiente salto) con las siguientes limitaciones:

• Esto solo se aplica a las rutas con una acción de deliver.
• Solo se permiten dos rutas de destino idénticas por zona, y cada una de ellas debe tener distintas direcciones de siguiente salto.
• Cuando se utiliza ECMP, es posible que la vía de acceso de retorno no tome la misma vía de acceso.
• ECMP sólo da soporte a un tipo de dirección IP de salto siguiente.

Rutas de entrada

• Actualmente, el enrutamiento de entrada público (public internet traffic choice) sólo está disponible en la consola. La CLI y la API están próximas.
• Cada tipo de origen de entrada se puede asociar con hasta una tabla de direccionamiento de entrada por VPC, sin embargo, una VPC puede tener varias tablas de direccionamiento de entrada y cada tabla de direccionamiento de entrada puede tener uno o varios tipos de entrada asociados.
• El tráfico de entrada procedente de un determinado origen de tráfico se direcciona mediante las rutas de la tabla de direccionamiento personalizada que está asociada con dicho origen de tráfico.
• Las rutas personalizadas de una tabla de direccionamiento personalizada asociada con un origen de tráfico de entrada y con una acción de deliver deben tener una IP de siguiente salto contenida en uno de los prefijos de dirección del VPC en la zona de disponibilidad donde se añade la ruta. Además, la siguiente IP de salto se debe configurar en una interfaz de servidor virtual en la VPC y en la zona de disponibilidad a la que se dirige la ruta.
• El tráfico de entrada procedente de un determinado origen de tráfico se direcciona mediante las rutas de la tabla de direccionamiento personalizada que está asociada con dicho origen de tráfico. Si no se encuentra ninguna ruta coincidente en una tabla de direccionamiento personalizada, el direccionamiento continúa utilizando la tabla de direccionamiento del sistema de VPC. Puede evitar este comportamiento con una ruta predeterminada de la tabla de direccionamiento personalizada con la acción Eliminar.
• Una tabla de direccionamiento personalizado de entrada que contenga cualquier ruta personalizada con IP de destino (FIP) debe definirse en la misma zona que la instancia de servidor virtual con la que está asociada una FIP.
• Las IP flotantes que están vinculadas a una pasarela IBM Cloud VPN no se pueden utilizar como destino de una ruta personalizada en una tabla de enrutamiento de entrada cuando está habilitado el tipo de origen Internet público route_internet_ingress).

Longitudes de prefijo exclusivas

Puede utilizar un máximo de 14 longitudes de prefijo exclusivas por tabla de direccionamiento personalizada. Puede tener varias rutas con el mismo prefijo que solo cuentan como un prefijo exclusivo. Por ejemplo, puede tener varias rutas con el prefijo /28. Esta longitud de prefijo cuenta como un único prefijo.

VPN

• Al crear una ruta para una conexión VPN estática basada en rutas, debes introducir el ID de la conexión VPN correspondiente al siguiente salto. La pasarela VPN debe estar en la misma zona que la subred a la que está asociada la tabla de direccionamiento. No se recomienda definir una pasarela VPN como el siguiente salto en una zona distinta de la subred que está asociada con la tabla de direccionamiento.
• Para las VPN basadas en rutas, evite utilizar una dirección IP privada como siguiente salto para las rutas VPN. Si la VPN se reinicia o su IP cambia, las rutas que apuntan a una dirección IP podrían romperse y la conectividad podría fallar. Utilice siempre el nombre de la conexión VPN (ID) como siguiente salto para que las rutas se actualicen automáticamente cuando la VPN se vuelva a conectar.
• Una ruta con una conexión de VPN como el siguiente salto solo entra en vigor cuando la conexión de VPN está activa. Esta ruta se omite durante la búsqueda de direccionamiento si la conexión de VPN está inactiva.
• Una tabla de direccionamiento personalizada que contiene rutas personalizadas con un siguiente salto asociado con una conexión VPN no se puede asociar con un origen de tráfico de entrada.
• Las rutas personalizadas sólo están soportadas en las VPN basadas en ruta. Si utiliza VPN basadas en políticas, el servicio VPN creará las rutas automáticamente en la tabla de direccionamiento predeterminada.