Considérations générales

Tous les préfixes d'un VPC et tous les sous-réseaux d'un réseau classique se connecteront à la passerelle de transit; il est donc important qu'ils ne se chevauchent pas. Lors de la création de VPC destinés à se connecter à une passerelle Transit Gateway, veillez à créer les VPC avec des préfixes VPC qui ne se chevauchent pas.

• IBM Cloud Transit Gateway prend en charge la mise à disposition des passerelles de transit dans les régions répertoriées dans lesemplacements IBM Cloud Transit Gateway.
• Créez votre passerelle Transit Gateway dans un emplacement qui a du sens pour votre charge de travail. Ainsi, si vous connectez deux VPC dans la région us-south (Dallas) et un VPC dans la région eu-de (Francfort), le choix le plus efficace pour placer votre charge de travail sera la région us-south.
• Il n'est pas possible de connecter un VPC Classic Access directement à une passerelle de transit. Pour connecter les ressources classiques, utilisez la connexion d'infrastructure IBM Cloud classique et toutes les ressources de votre VPC d'accès classique sont automatiquement connectées.
• Une passerelle Transit Gateway requiert au moins deux connexions pour que le trafic réseau puisse circuler sur la passerelle Transit Gateway. Les passerelles Transit Gateway qui ont moins de deux connexions pendant 45 jours ou plus sont susceptibles d'être récupérées (suspendues, puis supprimées après 30 jours).
• Vous pouvez connecter un VPC, une infrastructure Direct Link ou une infrastructure classique à plusieurs passerelles locales et à une seule passerelle globale.
• Les passerelles Transit Gateway et leurs connexions peuvent mettre plusieurs minutes après leur mise à disposition avant d'être disponibles.
• Soyez le plus descriptif possible quand vous donnez un nom à vos connexions Transit Gateway. Lors de la connexion à des ressources entre comptes, vous devez spécifier un nom de connexion. Lors de la connexion à des ressources situées dans le même compte que la passerelle Transit Gateway, le nom VPC ou le mot 'classic' est la sélection par défaut et peut être modifié.
• IBM Cloud Transit Gateway est une application mutualisée, où une seule instance du logiciel, et son infrastructure de support, peut être utilisée par plusieurs clients. Par conséquent, la surveillance de votre utilisation de la bande passante est importante. Si vous utilisez trop de bande passante, votre instance Transit Gateway peut être suspendue. Si vous pensez que c'est le cas, vérifiez le statut de connexion de l'instance Transit Gateway pour voir si elle se trouve à l'état Suspended. Dans ce cas, contactez le support pour la réintégrer.
• Les noms ASN suivants sont bloqués sur les connexions Transit Gateway Generic Routing Encapsulation (GRE) et Direct Link. Evitez d'utiliser ces ASN sur les dispositifs afin qu'ils ne soient pas inclus sur les routes annoncées dans le chemin AS. L'inclusion de ces noms ASN empêche les réseaux de fonctionner correctement.

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

Considérations relatives à l'ECMP

• Lors de la planification d'un réseau ECMP (Equal-Cost Multi-Path), gardez à l'esprit que le débit n'évolue pas de manière linéaire en fonction du nombre de liaisons directes. Par exemple, si vous connectez deux liaisons directes de 10 Go à une passerelle de transit prenant en charge l'ECMP, vous n'obtiendrez pas un débit de 20 Go; vous obtiendrez un débit supérieur à 10 Go, mais inférieur à 20 Go. En effet, l'ECMP fonctionne au niveau de chaque flux ou de chaque source; cela signifie que si le trafic provient d'un seul point d'extrémité, le système privilégiera probablement une seule liaison, et non les deux. Pour obtenir un débit plus équilibré, il est recommandé d'acheminer le trafic provenant de plusieurs sources, car cela permet de répartir la charge de manière plus homogène entre les liaisons directes disponibles.

• Limitation : ECMP ne fonctionne pas pour les liens directs sur un seul routeur. En revanche, il est pris en charge par plusieurs routeurs ayant des liens directs, pour autant que ces routeurs annoncent le même préfixe.

• Restriction connue : Les nouvelles passerelles de transit prennent en charge l'ECMP à 4 voies, mais les passerelles existantes ne peuvent pas utiliser cette fonctionnalité, sauf si vous ouvrez un dossier de support pour obtenir de l'aide.

  Si vous ne souhaitez pas que la fonction ECMP soit activée sur vos passerelles de transit, vous pouvez ouvrir un dossier de support pour être ajouté à une liste de refus, ce qui désactivera cette fonction sur vos passerelles.

Considérations relatives à la tarification

L' estimateur de coûts IBM Cloud, situé sur la page de provisionnement Transit Gateway, ne peut pas interpréter les types de connexion réseau. Pour obtenir une estimation fiable des coûts, saisissez le nombre estimé de passerelles de transit et de connexions. Gardez à l'esprit que si vous créez un GRE redondant, chaque tunnel est une connexion individuelle qui compte par rapport à votre limite de connexion.

Considérations relatives à la connexion à l'infrastructure classique

• Pour utiliser une passerelle Transit Gateway pour connecter vos VPC à votre infrastructure IBM Cloud classique, vous devez activer votre compte classique pour VRF (Virtual Routing and Forwarding) et le lier à votre compte IBM Cloud. Pour plus d'informations sur l'activation de votre compte pour VRF, voir Activation de VRF et des noeuds finaux de service.

• Lorsque vous connectez un VPC et l'infrastructure classique à une passerelle Transit Gateway, tous les préfixes du VPC deviennent visibles du service VRF de l'infrastructure classique, qui utilise des adresses IP dans l'espace 10.0.0.0/8. Pour garantir une connectivité optimale avec l'infrastructure classique, n'utilisez pas dans vos VPC de préfixes qui chevauchent les blocs 10.254.0.0/16 10.0.0.0/14, 10.200.0.0/14, 10.198.0.0/15, et. De plus, ne vous servez pas d'adresses en provenance de vos sous-réseaux d'infrastructure classique. Pour afficher la liste de vos sous-réseaux d'infrastructure classique, voir Affichage de tous les sous-réseaux.

• Les instances de serveur virtuel classiques peuvent avoir à la fois une interface réseau privée (eth0) et une interface réseau publique (eth1). Actuellement, les tables de routage de ces interfaces indiquent la passerelle par défaut vers l'interface publique (eth1). Vous devrez peut-être ajouter des entrées de routage pour acheminer les sous-réseaux à partir d'autres PC via l'interface privée.

• Tous vos réseaux d'infrastructure IBM Cloud classique situés dans des régions multizones sont accessibles via cette connexion, quel que soit l'emplacement de la passerelle Transit Gateway ou le type de routage spécifié.

• Les ressources d'infrastructure classiques situées dans ces Centres de données se connectent via une passerelle de transit aux ressources VPC.

• Lorsqu'une infrastructure classique est connectée à une passerelle de transit, elle inclut également tous les VPC Classic Access associés au compte, car les sous-réseaux de ces VPC sont associés au VRF de l'infrastructure classique. C'est la seule façon de connecter une passerelle Transit Gateway à un VPC d'accès classique : en connectant l'ensemble de l'infrastructure classique à la passerelle Transit Gateway (au lieu de VPC à accès classique spécifiques).

• Les connexions classiques résidant dans le même centre de données ne peuvent pas communiquer entre elles si elles se trouvent dans une région différente de la passerelle Transit Gateway.

Considérations sur le filtrage des préfixes

• Les filtres de préfixe sont pris en charge pour tous les types de connexion Transit Gateway, à l'exception des connexions par tunnel GRE. Pour les connexions GRE, le filtrage des préfixes est pris en charge pour les types de connexions GRE redondantes et GRE non liées.
• Pour les connexions non-GRE, le propriétaire du réseau peut ajouter des filtres de préfixes. Pour les connexions GRE, seul le propriétaire de Transit Gateway peut ajouter ou modifier les filtres de préfixe, ce qui est important pour les connexions entre comptes.
• Pour les connexions sur plusieurs comptes, seul le propriétaire du compte de la connexion concernée peut modifier les filtres de préfixe. Les autres comptes peuvent consulter la connexion, mais ne peuvent pas modifier les filtres.
• Vous ne pouvez pas filtrer les préfixes entrants provenant d'un autre compte.
• Pour les connexions GRE redondantes et les passerelles VPN, les filtres de préfixe ne peuvent être configurés qu'au niveau de la connexion de premier niveau. Les tunnels individuels sous ces connexions ne supportent pas de filtres de préfixes séparés; tout filtre appliqué au niveau supérieur s'appliquera à tous les tunnels associés.
• Les filtres de préfixe de la liste sont traités de manière séquentielle. Vous pouvez modifier l'ordre à tout moment.
• Si vous sélectionnez Demander une connexion à un réseau d'un autre compte comme option de portée de connexion, vous ne pouvez pas définir de filtres de préfixe, car vous n'êtes pas le propriétaire du réseau pour cette connexion. Les filtres de préfixes doivent être configurés dans le compte propriétaire du réseau. Pour les connexions GRE, seul le propriétaire de Transit Gateway peut définir des filtres de préfixe lors de la création de la connexion.
• Les masques de sous-réseau des filtres de préfixe sont spécifiques. Par exemple, une règle définie comme ne 10.10.20.0/24 correspond ni au sous-réseau 10.10.20.0/28 ni à aucun autre préfixe de sous-réseau.
• Consultez les limites de service de préfixe pour les passerelles Transit Gateway.

Remarques sur les connexions GRE (Generic Routing Encapsulation)

Passez en revue les considérations suivantes pour votre connexion GRE particulière.

Direct Link Considérations relatives à la connexion

Vous pouvez créer des connexions Direct Link à une passerelle Transit Gateway pour autoriser les réseaux sur site à se connecter aux autres réseaux d'IBM Cloud. Une fois que le lien direct s'est connecté à la passerelle Transit Gateway, le réseau sur site reçoit l'accès à toutes les autres connexions de passerelle Transit Gateway. De même, tous les autres réseaux connectés à la passerelle Transit Gateway ont accès au réseau sur site. Les connexions Direct Link suivent le même processus pour les connexions croisées physiques ou virtuelles que l'offre Direct Link standard. Une fois que la connexion a été supprimée d'une passerelle Transit Gateway, cette dernière fonctionne comme si elle n'avait jamais été connectée à un lien direct.

Les considérations à prendre en compte pour les sous-réseaux de réseau des connexions de passerelle Transit Gateway s'appliquent également aux connexions Direct Link. Pour garantir une connectivité optimale, n'utilisez pas, dans votre réseau connecté à Direct Link, de préfixes qui se chevauchent avec d'autres connexions.

Remarques sur la connexion à Power Virtual Server

Vous pouvez connecter une instance Power Virtual Server à une passerelle Transit Gateway. Cela vous permet d'associer directement Power Virtual Server à une passerelle Transit Gateway en aval. Une fois l' Power Virtual Server e connectée à la passerelle de transit, votre instance du service « Power Virtual Server » a accès à toutes les ressources et à tous les services en aval de la passerelle de transit. De même, tous les réseaux en aval connectés à la passerelle de transit ont accès à l'instance d' Power Virtual Server.

Les connexions Power Virtual Server peuvent utiliser le routage local ou global. Toutefois, seules les instances Power Virtual Server de la même région que la passerelle Transit Gateway peuvent utiliser le routage local. De plus, une instance Power Virtual Server peut être connectée à plusieurs passerelles Transit Gateway avec le routage local, mais une seule passerelle Transit Gateway avec le routage global. Les services en aval respecteront la préférence de route en fonction du type de passerelle Transit Gateway.

Les mêmes considérations relatives aux sous-réseaux pour les connexions aux passerelles de transit s'appliquent également aux connexions aux services Power Virtual Server. Pour garantir une connectivité réussie, n'utilisez pas de préfixes dans votre instance Power Virtual Server qui se chevauchent avec d'autres connexions. Notez que Transit Gateway propose un filtrage des préfixes pour limiter les préfixes exposés, ainsi qu'un rapport sur la table de routage pour voir les éventuels chevauchements après la création de la connexion.

Considérations relatives à la connexion à la passerelle VPN

Vous pouvez créer des connexions de passerelle VPN vers une passerelle de transit pour permettre aux réseaux sur site ou externes de se connecter à d'autres réseaux sur IBM Cloud. La passerelle VPN agit comme un rayon dans l'architecture de la passerelle de transit, permettant un peering efficace à travers plusieurs réseaux tout en réduisant la complexité du tunnel. Cette conception utilise le routage dynamique avec eBGP sur des tunnels GRE redondants pour fournir une connectivité évolutive et résiliente.

• Chaque connexion de passerelle VPN prévoit automatiquement quatre tunnels GRE redondants entre la passerelle VPN et la passerelle de transit. IBM gère ces tunnels, avec des sessions eBGP fonctionnant sur ces tunnels pour le routage dynamique. La connectivité sur site utilise eBGP sur des tunnels IPsec pour une communication sécurisée. Si vous pouvez créer, supprimer et renommer des connexions de passerelles VPN, vous ne pouvez pas modifier ou supprimer les tunnels GRE individuels.

• Le prix est basé sur le coût de 4 tunnels GRE par connexion, plus les frais de trafic de données.

• Par défaut, les connexions aux passerelles VPN sont limitées à 4 par passerelle de transit et à 2 par zone.

• Les connexions à la passerelle VPN ne prennent pas en charge le filtrage des préfixes. Vous êtes responsable de la gestion de tout filtrage de route de votre côté de la session BGP.

• Vous pouvez créer des connexions VPN dynamiques ou statiques à tout moment. Les connexions statiques sont fonctionnelles avec ou sans passerelle de transit. Les connexions dynamiques nécessitent que la passerelle VPN soit attachée à une passerelle de transit avant que le trafic ne puisse circuler.

• Une fois qu'une passerelle VPN est attachée à une passerelle de transit, l'ASN local ne peut pas être modifié.

• Pour configurer un VPN comme backup pour une connexion Direct Link, vous devez vous assurer que les routes de Direct Link sont préférées. Pour ce faire, vous pouvez tirer parti de mécanismes tels que l'AS Path prepending ou le MED (Multi-Exit Discriminator) sur votre appareil sur site.

• Lorsque vous créez une connexion de passerelle VPN, vous devez définir un bloc CIDR pour les adresses IP du tunnel GRE. Il est recommandé d'utiliser une plage d'adresses privées RFC 1918, car elle ne nécessite pas de route Delegate-VPC supplémentaire. Le bloc CIDR doit être au minimum de /27 et ne doit pas se chevaucher avec d'autres CIDR de connexion configurés sur la passerelle de transit.

  Si vous attribuez un CIDR à une passerelle VPN qui se trouve en dehors des plages IP privées standard (10.0.0.0/8, 172.16.0.0/12, ou 192.168.0.0/16), vous devez ajouter manuellement des itinéraires dans la table de routage VPC (dans la même zone que la passerelle VPN) pour permettre un flux de trafic correct. Deux options s'offrent à vous :

  • Ajoutez une route unique avec la destination définie sur le CIDR complet attribué par le VPN (par exemple, 100.31.128.0/18) et l'action définie sur Delegate-VPC.
  • Ajoutez quatre routes distinctes, chacune ciblant l'IP de la passerelle locale de chaque tunnel VPN (par exemple, 100.31.128.1/32) avec l'action définie sur Delegate-VPC.

  La première option est plus simple, tandis que la seconde offre un contrôle plus granulaire du routage, ce qui peut être préférable dans les conceptions de réseau avancées ou pour le dépannage.

Remarques relatives à VPC

• IBM Cloud Le VPC autorise l'utilisation d'adresses RFC-1918 et d'espaces d'adresses IPv4 enregistrés auprès de l'IANA, de manière privée au sein de votre VPC, à quelques exceptions près concernant les plages réservées à des fins spécifiques par 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, des routes personnalisées doivent être installées dans chaque zone. Pour plus d'informations, voir Remarques relatives au routage pour les affectations d'adresses IP enregistrées par IANA.

• Vous pouvez créer une ou plusieurs passerelles Transit Gateway pour interconnecter plusieurs clouds privés virtuels (VPC) IBM Cloud. Vous pouvez également connecter votre infrastructure classique IBM Cloud à une passerelle Transit Gateway afin de fournir une communication transparente avec des ressources d'infrastructure classique. Pour plus d'informations, voir Interconnexion de VPC.

• Bare metal dans VPC n'est pas pris en charge.

Considérations relatives au routage

• Toutes les connexions à une passerelle Transit Gateway étant connectées les unes aux autres, réfléchissez donc bien au préalable aux ressources à interconnecter avant de décider du type de routage (local ou mondial) qui convient pour chaque passerelle.

  Le trafic, quel que soit l'option de routage, ne quitte pas le réseau privé IBM Cloud et est optimisé pour les performances.

• Si vous envisagez d'utiliser la passerelle pour connecter des VPC dans la même région multizone (MZR (Multi-Zone Region)), utilisez le routage local pour fournir une connectivité à toutes les ressources accessibles dans la même région multizone, par exemple, us-south (Dallas).

  

• Si vous envisagez d'utiliser vos passerelles Transit Gateway pour connecter des VPC en local et entre différentes régions multizones, utilisez des passerelles locales pour les VPC de la même région multizone et une passerelle globale pour les VPC entre les régions multizones. Vous pouvez également utiliser l'exemple qui suit un scénario à haute disponibilité (HA). Toutes les données des VCP A et B peuvent être reproduites sur les VCP C et D. S'il y a un problème dans la région du sud des États-Unis, les connexions sont réacheminés vers l'Est américain.

  ![Routage globalRoutage](/images/2-aboutLocalAndGlobalRoutingExample.png "et " caption-side="bottom"} de "){: caption="de routage local et global

  Quel que soit le type de routage spécifié, IBM Cloud Transit Gateway peut se connecter à des réseaux d'infrastructure classique situés dans n'importe quelle région multizone. Pour cela, il suffit d'ajouter la connexion classique à votre passerelle Transit Gateway.

• Vous pouvez éditer le type de routage d'une passerelle après sa mise à disposition. Toutefois, pour modifier le type de routage de Global à Local, vous devez d'abord supprimer toutes les connexions globales (c'est-à-dire les connexions vers des ressources qui ne se trouvent pas au même emplacement que la passerelle). Notez que les connexions à l'infrastructure classique d'IBM Cloud sont toujours considérées comme locales.

• Lorsque vous passez d'un routage local à un routage mondial, toutes les connexions mondiales associées vous sont facturées. Le trafic réseau n'est pas affecté lors du changement de type de routage.

Considérations relatives au rapport de route

• Le chemin AS affiché dans un rapport d'itinéraire fournit une perspective de zone unique. Si votre source ou votre destination s'étend sur différentes zones, la longueur du chemin peut varier. Par exemple, considérons deux liens directs : l'un dans DAL10 et l'autre dans DAL12, tous deux annonçant la même longueur de chemin AS vers une passerelle de transit basée sur DAL et connectée à un VPC ou à un environnement classique. Lors d'un appel à partir d'une instance de serveur virtuel DAL10:

  • Il est préférable d'utiliser le lien direct DAL10.
  • Pour les connexions provenant de DAL12, le lien direct DAL12 est préféré.
  • Dans le cas de DAL13, vous obtiendrez soit un routage ECMP, en supposant que votre passerelle soit configurée pour cela, soit un lien direct unique sera utilisé. Cependant, lors d'une réinitialisation BGP, il pourrait basculer sur l'autre lien direct.

• Les routes de chevauchement constituent un problème commun lors de la configuration de Transit Gateway. Si les itinéraires de deux ou plusieurs connexions se chevauchent, le trafic risque de ne pas être acheminé comme prévu. Pour plus d'informations, voir Adressage des conflits de route.

• Une fois qu'une nouvelle connexion virtuelle (VPC, infrastructure classique ou Direct Link) atteint l'état Actif, prévoyez 5 minutes pour que les routes soient apprises par votre passerelle Transit Gateway. La génération d'un rapport de route avant l'apprentissage de toutes les routes génère un rapport de route partiel.

• Si une connexion expose une route de 0.0.0.0/0, cette route est ignorée lors du calcul des préfixes qui se chevauchent.

• Un seul rapport par passerelle est disponible à tout moment. Si vous générez un nouveau rapport, l'ancien rapport sera supprimé.

• Les rapports de route plus anciens peuvent devenir inexacts une fois que vous avez ajouté ou supprimé une connexion. Par conséquent, si vous mettez à jour des itinéraires au sein de ces connexions, il est recommandé de générer un nouveau rapport d'itinéraires.

• Si un ou plusieurs itinéraires sont refusés par les filtres de préfixe, ces itinéraires n'apparaissent pas dans le rapport d'itinéraires.

Limites de service

Gardez à l'esprit les limites de service suivantes lors de l'utilisation d'IBM Cloud Transit Gateway.

Vous pouvez ouvrir un cas IBM Support pour augmenter vos limites de service.