Acerca de tablas de direccionamiento y de las rutas
IBM Cloud® Virtual Private Cloud (VPC) genera automáticamente una tabla de direccionamiento predeterminada para la VPC a fin de gestionar el tráfico en la zona. De forma predeterminada, esta tabla de direccionamiento está vacía. Puede añadir rutas a la tabla de direccionamiento predeterminada o crear una o varias tablas de direccionamiento personalizadas y luego añadir rutas. Por ejemplo, si desea una política de direccionamiento especializada para una subred específica, puede crear una tabla de direccionamiento y asociarla con una o varias subredes. Sin embargo, si desea cambiar la política de enrutamiento por defecto que afecta a todas las subredes que utilizan la tabla de enrutamiento por defecto, entonces debe añadir rutas a la tabla de enrutamiento por defecto.
La tabla de direccionamiento predeterminada funciona igual que otras tablas de direccionamiento, excepto por que se crea automáticamente, y se utiliza cuando se crea una subred sin especificar una tabla de direccionamiento.
Puede definir rutas dentro de cualquier tabla de direccionamiento para dar forma al tráfico de la manera que desee. Cada subred está asignada a una tabla de enrutamiento, que es responsable de administrar el tráfico de la subred. Puede cambiar la tabla de direccionamiento que utiliza una subred para gestionar su tráfico de salida en cualquier momento.
Este servicio también permite utilizar la virtualización de funciones de red (NFV) para servicios de red avanzados, como el direccionamiento de terceros, cortafuegos, equilibrio de carga local/global, cortafuegos de aplicaciones web y más. Las tablas de direccionamiento personalizadas también se están integrando actualmente en los servicios de IBM Cloud.
Direccionamiento de salida y de entrada
-
Las rutas de salida controlan el tráfico, que se origina dentro de una subred y viaja hacia la Internet pública, o hacia otra VM en la misma o diferente zona.
-
Las rutas de entrada permiten personalizar las rutas en el tráfico entrante a una VPC desde fuentes de tráfico externas a la zona de disponibilidad de la VPC ( IBM Cloud Direct Link, IBM Cloud Transit Gateway, otra zona de disponibilidad en la misma VPC, o la Internet pública).
Solo se puede asociar una tabla de direccionamiento personalizada con un origen de tráfico de entrada en concreto. Sin embargo, puede utilizar diferentes tablas de direccionamiento para distintos orígenes de tráfico. Por ejemplo, la tabla de enrutamiento A podría utilizar Transit Gateway y VPC Zone, mientras que la tabla de enrutamiento B utiliza Direct Link.
Definición de la tabla de direccionamiento implícito del sistema
No se puede configurar una tabla de enrutamiento para utilizar la tabla de enrutamiento implícita del sistema; se rellena automáticamente. La tabla de enrutamiento implícito del sistema se utiliza cuando no se encuentra ninguna ruta coincidente en la tabla de enrutamiento personalizada asociada a la subred de salida del tráfico. Si no se encuentra ninguna coincidencia, se descarta el paquete.
Se mantiene una tabla de enrutamiento implícita en el sistema para cada VPC. Una VPC puede tener presencia en varias zonas, y la tabla de enrutamiento implícita en el sistema de la VPC es diferente en cada zona. Para el enrutamiento de entrada, la tabla de enrutamiento implícito del sistema contiene sólo rutas a cada interfaz de red en la zona de la VPC.
Este comportamiento puede evitarse con una ruta por defecto de tabla de enrutamiento personalizada con una acción de drop.
La tabla de direccionamiento implícito del sistema contiene:
-
Rutas al CIDR de cada subred de la VPC
-
Rutas a subredes dentro de la zona (mantenido estáticamente)
-
Rutas a subredes en otras zonas que se aprenden a través de BGP
-
Rutas dinámicas aprendidas a través de BGP (por ejemplo, Direct Link y Transit Gateway )
-
La ruta predeterminada para el tráfico de Internet (se utiliza cuando una pasarela pública o una IP flotante está asociada con la VPC)
-
Rutas a los CIDR de red de servicio de infraestructura clásica (que se utilizan cuando una pasarela de servicio está asociada con el VPC), por ejemplo:
10.0.0.0/14,10.200.0.0/14,10.198.0.0/15y10.254.0.0/16son CIDR de red de servicio de infraestructura clásica.
Determinación de la preferencia de ruta
Puede designar la prioridad de la ruta (0-4 ) de rutas VPC para determinar qué rutas tienen una mayor prioridad cuando existen varias rutas para un destino específico. Las rutas existentes y las nuevas, que se crean
sin un valor de prioridad, se configuran automáticamente con la prioridad predeterminada (2 ).
La prioridad de ruta se considera sólo en destinos idénticos y es similar a cualquier ruta aprendida dinámicamente.
Establecimiento de ejemplos de prioridad de ruta
- Si tiene una ruta con un prefijo
/32y una prioridad de1, y una ruta con un destino de/31y una prioridad0, se utiliza/32en 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.
Rutas publicitarias
En el pasado, los prefijos de dirección dentro del prefijo de dirección raíz de la VPC se anunciaban en Direct Link y Transit Gateway. Sin embargo, no ha podido anunciar los prefijos de dirección fuera del prefijo de dirección raíz de la VPC.
El anuncio de ruta añade esta capacidad. Por ejemplo, la Figura 1 anuncia la ruta 0.0.0.0/0 en todas las zonas a un salto siguiente específico de zona.
{: caption="
Para más información, ver Crear una tabla de enrutamiento y Actualizar una tabla de enrutamiento.
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/31a través de10.1.1.0y172.16.0.0/32a través de10.1.2.0, la ruta con un/32El prefijo siempre tiene prioridad sobre la ruta con un/31prefijo. 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.
Casos de uso
Los casos de uso siguientes ilustran diferentes escenarios de direccionamiento.
Caso de uso 1: cortafuegos de proxy Edge
{: caption="
| Destino | Acción | Salto siguiente | Ubicación |
|---|---|---|---|
10.10.0.0/16 |
Delegar | Dallas DC 1 | |
10.11.0.0/16 |
Delegar | Dallas DC 1 | |
0.0.0.0/0 |
Deliver | 10.10.1.5 |
Dallas DC 1 |
Objetivo: cortafuegos de proxy Edge
Proteja los flujos a la Internet pública desde detrás de un dispositivo de pasarela, proxy o cortafuegos definido por el cliente, al mismo tiempo que permite que los recursos de las otras subredes fluyan a través de la pasarela pública gestionada por VPC.
Mediante el uso de rutas personalizadas VPC con enrutamiento de salida por subred, puede crear una tabla para anular el enrutamiento implícito del sistema dentro de la red VPC. En este ejemplo, la tabla por defecto creada por el sistema,
en la que se asignan todas las subredes en el momento de la creación, no se modifica. También se crea una tabla para dirigir el tráfico de la subred 10.10.1.0/24 a través de un proxy de borde (NFV Proxy).
Dado que el destino de los flujos proxy es la Internet pública y, normalmente, siguen la ruta por defecto (0.0.0.0/0), primero debe eximir los flujos hacia redes privadas alcanzables internamente utilizando la función Delegate
de las rutas personalizadas. Los recursos de la subred 10.10.3.0/24 siguen utilizando la pasarela pública que está conectada a esa subred.
Mientras que las instancias que utilizan el proxy comparten una subred común con el proxy en este ejemplo, no es necesario que lo hagan. Con rutas personalizadas, puede especificar una IP de siguiente salto de una instancia que esté conectada
a una subred diferente. De este modo, puede escalar horizontalmente sin preocuparse por el tamaño de las subredes de los servicios Edge. Por ejemplo, se puede adjuntar una tabla de enrutamiento proxy a la subred 10.10.3.0/24 y dirigir todos los flujos públicos al proxy NFV.
Funciones utilizadas en un cortafuegos de proxy Edge
Este caso de uso utiliza las siguientes funciones de cortafuegos de proxy Edge:
- Inhabilitación de la comprobación de suplantación de IP en las interfaces
10.10.0.5y10.10.1.5para habilitar la conservación de la dirección de origen. Esta acción requiere permisos IAM elevados en la instancia. - Una pasarela pública para flujos de salida con recursos que no se dirigen a través del proxy de NFV.
- La IP flotante conectada a la interfaz
10.10.0.5para habilitar los flujos públicos de entrada y salida directamente al proxy de NFV. - Adición de grupos de seguridad con estado y listas de control de acceso (ACL) de red a las interfaces de instancias y subredes VPC, respectivamente, para proporcionar recursos de aislamiento adicionales dentro del VPC.
Caso de uso 2: equilibrador de carga público
{: caption="
| Destino | Acción | Salto siguiente | Ubicación |
|---|---|---|---|
10.10.0.0/16 |
Delegar | Dallas DC 1 | |
10.11.0.0/16 |
Delegar | Dallas DC 1 | |
161.26.0.0/16 * |
Delegar | Dallas DC 1 | |
166.8.0.0/14 * |
Delegar | Dallas DC 1 | |
0.0.0.0/0 |
Deliver | 10.10.1.5 |
Dallas DC 1 |
Objetivo: equilibrador de carga público
Alojamiento de aplicaciones web que utilizan un equilibrador de carga de red o de aplicaciones definido por el cliente.
Al utilizar rutas personalizadas de VPC con enrutamiento de salida por subred, puede crear una tabla para anular el enrutamiento implícito del sistema con la red de VPC sin actualizar la información de enrutamiento en cada instancia. En este ejemplo, se conserva la IP de origen de los usuarios de Internet a la capa web. Las capas de web a aplicación y de aplicación a base de datos se comunican mediante enrutamiento VPC implícito y siguen utilizando la pasarela pública para la salida a Internet.
La delegación de rutas es necesaria para las redes internas/privadas dentro de las redes de servicio de VPC y IBM a través de la red troncal privada. Para evitar la necesidad de delegación, los servidores de capa web se pueden conectar a la subred de la capa de aplicaciones, y se puede cambiar el direccionamiento en las instancias web para que utilice la pasarela de subred de aplicaciones como el siguiente salto para las redes de servicio de nube y VPC internas.
Funciones utilizadas en los equilibradores de carga públicos
Este caso de uso utiliza las siguientes funciones de los equilibradores de carga públicos:
- Inhabilitación de la comprobación de suplantación de IP en las interfaces
10.10.0.5y10.10.1.5para habilitar la conservación de la dirección de origen. Esta acción requiere permisos IAM elevados en la instancia. - Una pasarela pública para flujos de salida para los recursos que no se dirigen a través del proxy de NFV.
- La IP flotante conectada a la interfaz
10.10.0.5para habilitar los flujos públicos de entrada y salida directamente al equilibrador de carga de NFV. - Adición de grupos de seguridad con estado y listas de control de acceso (ACL) de red a las interfaces de instancias y subredes VPC, respectivamente, para proporcionar recursos de aislamiento adicionales dentro del VPC.
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 tener conectividad entre subredes cuando tiene la ruta 0.0.0.0/0 y el siguiente salto es una conexión de VPN, como se indica anteriormente, puede 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 y directrices
Las siguientes limitaciones y directrices se aplican a las Rutas personalizadas de IBM Cloud para VPC.
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/26y los saltos siguientes son192.168.2.4y192.168.2.5respectivamente. 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.
- El VPC de IBM Cloud permite el uso de espacios de direcciones IPv4 registrados en IANA y RFC-1918 de forma privada dentro del VPC, con algunas excepciones en los rangos de propósito especial de IANA y rangos seleccionados asignados a servicios de 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 parapriority) 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.
- Cuando el siguiente salto para ambas rutas está en la misma zona, la ruta con mayor prioridad (es decir, un valor menor para
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 internettraffic 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
deliverdeben 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. Esto cuenta como un prefijo exclusivo.
VPN
- Al crear una ruta para una conexión VPN estática basada en rutas, debe introducir el ID de conexión VPN para el 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.
- 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.