Définition d'exemples de priorité de route

• Si vous disposez d'une route avec le préfixe /32 et la priorité 1, et d'une route avec la destination /31 et la priorité 0, /32 est utilisé en premier (correspondance de préfixe la plus longue). En d'autres termes, la priorité n'a d'importance que lorsqu'il y a plus d'une route avec le même préfixe.
• Si vous disposez de trois routes avec 0.0.0.0/0 (route par défaut), seule la route ayant la priorité la plus élevée est utilisée. Si la route sélectionnée est supprimée (par exemple, via l'automatisation), la priorité la plus élevée des deux routes restantes est sélectionnée.
• Si la table de routage personnalisée ne comporte qu'une seule route avec un préfixe spécifique, cette route est toujours utilisée quelle que soit sa priorité. La sélection du meilleur itinéraire est effectuée pour chaque préfixe spécifique et choisit l'itinéraire ayant la priorité la plus élevée.

Le routage ECMP (Egal-Cost Multi-Path) est utilisé lorsque deux routes ont la même destination et la même priorité (extension du comportement actuel où ECMP est utilisé pour deux routes ayant la même destination). Au maximum, deux routes d'une table de routage peuvent avoir la même destination et la même priorité. Par exemple, si la table de routage personnalisée comporte trois routes avec la même destination, une route avec la priorité 1 et les deux autres routes avec la priorité 4 (ECMP), la route avec la priorité 1 est sélectionnée et les routes ECMP sont ignorées (pas ECMP). Maintenant, si les deux routes ayant la même destination et la même priorité ont la priorité la plus élevée, le système sélectionne ces deux routes et exécute ECMP. Ensuite, si l'une de ces routes est supprimée, la route qui existe encore est sélectionnée et ECMP n'est pas exécutée.

Pour les limitations de priorité de route, voir Limitations et instructions.

Considérations relatives aux itinéraires publicitaires

Soyez conscient des considérations suivantes lors de la publicité d'itinéraires :

• Vous pouvez annoncer des routes en dehors du préfixe d'adresse racine attribué au VPC, afin de pouvoir annoncer vos réseaux externes ou résidant en dehors du VPC à un Direct Link ou Transit Gateway.

• Si plusieurs Transit Gateways ou Direct Links sont connectés à votre VPC, vous pouvez utiliser le filtrage de routes sur des réseaux individuels. Transit Gateway ou Direct Link connexions pour affiner les itinéraires annoncés vers quelles connexions.

• Si plusieurs routes sont annoncées vers un préfixe de destination avec des priorités différentes, la route avec la priorité la plus élevée (valeur de priorité la plus faible) est utilisée comme route principale et la route avec la priorité la plus faible (valeur de priorité la plus élevée) est utilisée comme sauvegarde.

• Si vous annoncez deux itinéraires différents, par exemple 172.16.0.0/31 à travers 10.1.1.0 et 172.16.0.0/32 à travers 10.1.2.0, l'itinéraire avec un /32 le préfixe a toujours priorité sur l'itinéraire avec un /31 préfixe. Cela est cohérent avec le jeu de règles "Correspondance de préfixe la plus longue". Un préfixe plus long vers une destination hôte est toujours préféré à un préfixe plus étroit.

• Actuellement, il n'existe aucun mécanisme permettant de marquer les routes en double à partir d'une passerelle Transit Gateway ou Direct Link. Le Transit Gateway sélectionne le meilleur chemin en utilisant le préfixe le plus spécifique et le chemin AS le plus court, selon vos préférences. Sinon, le Transit Gateway sélectionne l'itinéraire qu'il a reçu en premier. Cette route n'est peut-être pas la plus ancienne du côté du VPC, et elle peut changer si les routes vers le Transit Gateway sont rafraîchis en interne.

• Les routes annoncées à partir d'une passerelle VPN dépendent du type de VPN. Les passerelles VPN basées sur des politiques n'annoncent pas dynamiquement les routes. Seuls les préfixes CIDR définis dans la stratégie VPN sont propagés, et la table de routage doit être configurée pour accepter les routes provenant de la passerelle VPN. Les passerelles VPN basées sur les routes avec BGP annoncent les routes de manière dynamique.

  Lorsque vous annoncez des routes à partir d'une table de routage qui inclut une connectivité VPN, assurez-vous que le type de passerelle VPN prend en charge le comportement de propagation de route souhaité.

Cas d'utilisation 1 : Pare-feu de proxy Edge

{: caption="utilisation d'un pare-feu proxy en périphérieCas " caption-side="bottom}'utilisation d'un pare-feu proxy en périphérie

Cas d'utilisation 2 : Equilibreur de charge public

{: caption="d'utilisation d'un équilibreur de charge publicCas " caption-side="bottom}'utilisation d'un équilibreur de charge public

Cas d'utilisation 3 : VPN

Pour disposer d'une passerelle VPN comme tronçon suivant dans une table de routage VPC, la passerelle est créée dans un sous-réseau dédié. Ce sous-réseau est utilisé uniquement pour la passerelle VPN et associé au sous-réseau de la passerelle VPN avec une table de routage différente lorsqu'il existe une route 0.0.0.0/0 et que le tronçon suivant est une connexion VPN.

Exemple :

• Le sous-réseau A est utilisé pour héberger les serveurs virtuels et est associé à la table de routage par défaut. Il existe une route 0.0.0.0/0, et le tronçon suivant est une connexion VPN.
• Le sous-réseau B est utilisé pour héberger la passerelle VPN et crée une nouvelle table de routage (la table de routage B). Le sous-réseau B est associé à la table de routage B. Par défaut, vous n'avez pas besoin de routes dans la table de routage B.

Pour assurer la connectivité entre des sous-réseaux en cas d' 0.0.0.0/0 de routage et lorsque le saut suivant est une connexion VPN, vous pouvez ajouter les routes déléguées suivantes :

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

Limitations générales

• Actuellement, vous ne pouvez pas utiliser une table de routage personnalisée pour le trafic entrant (table associée à une source de trafic) et sortant (table associée à un sous-réseau). En outre, la table de routage personnalisée par défaut ne peut pas être associée à une source de trafic entrant.
• Actuellement, le trafic de retour peut échouer en raison d'un routage asymétrique. Ce problème affecte tous les services qui dépendent des routes statiques ECMP. Par exemple, supposons que vous créez deux routes ECMP dans VPC A avec la destination 10.134.39.64/26 et que les tronçons suivants sont respectivement 192.168.2.4 et 192.168.2.5. Ces tronçons suivants sont des adresses IP d'unité NFV. Lorsque vous envoyez du trafic depuis l'instance A dans le VPC, le paquet est acheminé de manière aléatoire vers l'un des sauts suivants, et il n'y a aucune garantie que le trafic de retour suive le même chemin que le trafic de transfert en raison de l'algorithme de hachage ECMP de l'autre côté. . Ce phénomène est appelé routage asymétrique. Lorsqu'un routage asymétrique se produit, le problème ne vient pas du routage lui-même, mais du groupe de sécurité abandonnant le trafic même si les règles du groupe de sécurité autorisent ce trafic, car le groupe de sécurité voit le trafic dans un seul chemin. En général, il est conseillé d’éviter l’utilisation des routes ECMP.
• La possibilité d'atteindre une adresse IP de tronçon suivant sur une route personnalisée n'est pas un facteur déterminant pour savoir si la route est utilisée pour acheminer du trafic. Cela peut provoquer des problèmes lorsque plusieurs routes ayant le même préfixe (mais des adresses IP de tronçon suivant différentes) sont utilisées, car le trafic vers les adresses IP de tronçon suivant inaccessibles peut ne pas être distribué.
• IBM Cloud Le VPC autorise l'utilisation des espaces d'adresses RFC-1918 et IPv4 enregistrés auprès de l'IANA à des fins privées au sein de votre VPC, à quelques exceptions près concernant les plages d'adresses à usage spécifique de l'IANA et certaines plages attribuées aux services IBM Cloud. Si vous utilisez des plages enregistrées par IANA au sein de votre entreprise et dans des VPC conjointement avec IBM Cloud Transit Gateway ou IBM Cloud Direct Link, vous devez installer des routes personnalisées dans chaque zone. Pour plus d'informations, voir Remarques relatives au routage pour les affectations d'adresses IP enregistrées par IANA.
• Dans le cas où 2 itinéraires annoncés différents existent vers la même destination, les limitations suivantes s'appliquent :
  • Lorsque le prochain saut des deux routes se trouve dans la même zone, la route ayant la priorité la plus élevée (c'est-à-dire une valeur moindre pour priority ) est utilisé comme chemin principal et comme route ayant la moindre priorité (c'est-à-dire une valeur plus élevée pour priority ) est utilisé comme chemin de sauvegarde. Si la priorité pour les deux routes est la même, ECMP est utilisé pour acheminer le trafic de manière identique sur les deux routes.
  • Lorsque le tronçon suivant pour les deux routes se trouve dans des zones différentes, le routeur Transit Gateway ou Direct Link choisit la meilleure route. Dans ce cas, il s'agit de l'itinéraire annoncé le plus ancien.

Priorité de route

S'il existe plusieurs routes avec le même CIDR/préfixe de destination, la route avec la valeur de priorité la plus élevée est utilisée. Les routes ayant le même CIDR/préfixe de destination et la même priorité utilisent le routage ECMP.

Routage sortant

Pour les routes personnalisées pour le trafic sortant, lorsque vous ajoutez une route de destination, vous devez sélectionner une zone. En revanche, il n'est pas nécessaire que le tronçon suivant se trouve dans la même zone. Pour les routes personnalisées pour le trafic entrant, le tronçon suivant doit se trouver dans la même zone.

Equal-Cost Multi-Path (ECMP)

Le routeur implicite effectue le routage ECMP (plusieurs routes avec la même destination, mais différentes adresses de tronçon suivant) avec les limitations suivantes :

• Cela s'applique uniquement aux routes avec une action deliver.
• Seules deux routes de destination identiques sont autorisées par zone et chacune d'elles doit avoir des adresses de tronçon suivant différentes.
• Lorsque le routage ECMP est utilisé, il se peut que le chemin de retour soit différent du chemin initial.
• ECMP prend uniquement en charge un type de tronçon suivant d'adresse IP.

Routage entrant

• Actuellement, le routage d'entrée public (public internet traffic choice) n'est disponible que dans la console. L'interface de ligne de commande et l'API sont disponibles.
• Chaque type de source d'entrée peut être associé à jusqu'à une table de routage d'entrée par VPC, mais un VPC peut avoir plusieurs tables de routage d'entrée et chaque table de routage d'entrée peut avoir un ou plusieurs types d'entrée associés.
• Le trafic entrant à partir d'une source de trafic donnée est acheminé via les routes définies dans la table de routage personnalisée qui est associée à cette source de trafic.
• Les routes personnalisées d'une table de routage personnalisée associée à une source de trafic entrant, et avec une action deliver, doivent avoir une adresse IP de tronçon suivant contenue dans l'un des préfixes d'adresse du VPC dans la zone de disponibilité où la route est ajoutée. En outre, l'adresse IP de tronçon suivant doit être configurée sur une interface de serveur virtuel dans le VPC et la zone de disponibilité où la route est ciblée.
• Le trafic entrant à partir d'une source de trafic donnée est acheminé via les routes définies dans la table de routage personnalisée qui est associée à cette source de trafic. Si aucune route correspondante n'est trouvée dans une table de routage personnalisée, le routage continue à l'aide de la table de routage système du VPC. Vous pouvez éviter ce comportement avec une route par défaut d'une table de routage personnalisée à l'aide d'une action Supprimer.
• Une table de routage personnalisée d'entrée contenant des routes personnalisées avec l'adresse IP de destination (FIP) doit être définie dans la même zone que l'instance de serveur virtuel à laquelle est associée une FIP.
• Les IP flottantes liées à une passerelle IBM Cloud VPN ne peuvent pas être utilisées comme destination d'une route personnalisée dans une table de routage d'entrée lorsque le type de source Internet public route_internet_ingress) est activé.

Longueurs de préfixe unique

Vous pouvez utiliser un maximum de 14 longueurs de préfixe uniques par table de routage personnalisée. Vous pouvez avoir plusieurs routes avec le même préfixe, ce qui est comptabilisé comme un seul préfixe unique. Par exemple, vous pouvez disposer de plusieurs routes dotées d'un préfixe /28. Cette longueur de préfixe est considérée comme un préfixe unique.

VPN

• Lorsque vous créez une route pour une connexion VPN statique basée sur des routes, vous devez saisir l'identifiant de la connexion VPN correspondant au saut suivant. La passerelle VPN doit se trouver dans la même zone que le sous-réseau auquel la table de routage est associée. Il n'est pas recommandé de définir une passerelle VPN comme tronçon suivant d'une zone différente du sous-réseau qui est associé à la table de routage.
• Pour les VPN basés sur des routes, évitez d'utiliser une adresse IP privée comme prochain saut pour les routes VPN. Si le VPN redémarre ou si son IP change, les routes pointant vers une adresse IP peuvent être interrompues et la connectivité peut échouer. Utilisez toujours le nom de la connexion VPN (ID) comme prochain saut afin que les routes soient automatiquement mises à jour lorsque le VPN se reconnecte.
• Une route avec une connexion VPN comme tronçon suivant prend effet uniquement lorsque la connexion VPN est active. Cette route est ignorée lors de la recherche de routage si la connexion VPN est inactive.
• Une table de routage personnalisée contenant des routes personnalisées avec un tronçon suivant qui est associé à une connexion VPN ne peut pas être associée à une source de trafic entrant.
• Les routes personnalisées ne sont prises en charge que sur les réseaux privés virtuels basés sur des routes. Si vous utilisez des VPN basés sur des règles, les routes sont créées automatiquement par le service VPN dans la table de routage par défaut.