Considérations générales

Passez en revue les considérations générales suivantes avant de créer un serveur de routage dynamique :

• Un serveur de routage dynamique est un service de routage qui ne transfère pas le trafic de données. Au lieu de cela, il apprend les routes auprès de ses pairs à l'aide du protocole BGP et ajoute des routes aux tables de routage du VPC en fonction des politiques définies.
• Une instance de serveur de routage dynamique est créée au sein d'un seul VPC et gère les routes uniquement pour ce VPC.
• Vous devez fournir au moins un et au plus trois membres (un par zone) lorsque vous créez une instance de serveur de routage dynamique. Pour garantir une haute disponibilité, utilisez un nœud par zone de disponibilité.
• Tous les membres d'une instance de serveur de routage dynamique doivent utiliser le même ASN local.
• Une fois qu'une instance de serveur de routage dynamique a été créée, elle doit atteindre un état de cycle de vie stable avant que vous puissiez configurer des pairs, des groupes de pairs ou des politiques de routage.

Considérations relatives aux interfaces réseau virtuelles

Tenez compte des éléments suivants lorsque vous sélectionnez une interface réseau virtuelle (VNI) pour une instance de serveur de routage dynamique :

• Chaque membre du serveur de routage dynamique nécessite un VNI que vous devez créer au préalable.
• Toutes les adresses VNI doivent appartenir au même VPC que l'instance du serveur de routage dynamique.
• Chaque VNI doit disposer d'une adresse IP privée réservée et d'un ou plusieurs groupes de sécurité autorisant le trafic BGP.
• Un VNI existant que vous utilisez pour un membre doit répondre aux exigences suivantes :
  • Il se trouve dans le même compte que le serveur de routage dynamique et n'est lié à aucune autre cible.
  • L'usurpation d'adresse IP n'est pas autorisée, le NAT au niveau de l'infrastructure est activé et le filtrage d'état des protocoles n'est pas désactivé.
  • Il ne dispose ni d'adresse IP flottante, ni d'adresses IP secondaires réservées, ni d'aucune autre adresse IP que son adresse IP principale.
• Pour garantir une haute disponibilité, sélectionnez des VNI situées dans différentes zones de disponibilité.
• Une adresse VNI associée à une instance de serveur de routage dynamique ne peut pas être supprimée tant qu'elle n'a pas été dissociée de ce serveur.
• Les sous-réseaux associés à des VNI doivent disposer d'une capacité IP suffisante pour les adresses IP réservées et les opérations en cours.

Considérations relatives au BGP, au BFD et à l'ASN

Passez en revue les considérations suivantes relatives au BGP avant de créer une instance de serveur de routage dynamique :

• Un serveur de routage dynamique utilise l' eBGP pour échanger des routes avec des pairs, tels que des routeurs, des pare-feu ou une passerelle de transit.
• Vous devez spécifier un ASN local lorsque vous créez une instance de serveur de routage dynamique.
• Chaque pair doit être configuré avec un ASN de pair différent de l'ASN local.
• Les valeurs ASN 0, 13884, 36351, 64512, 64513, 65100, 65200-65234, 65402-65433, 65500, 65516, 65519, 65521, 65531, et sont 4201065000-4201065999 réservées et ne peuvent pas être utilisées comme ASN locaux ou de pairs.
• En cas de conflit d'ASN, les sessions BGP ne peuvent pas s'établir tant que la configuration de l'ASN n'a pas été corrigée.
• La détection bidirectionnelle de transfert (BFD) peut être activée sur les groupes de pairs pour accélérer la détection des pannes et le retrait des routes.
• Les appliances de serveurs de routage dynamiques établissent des sessions BGP à l'aide du protocole multihop. Pour utiliser la détection de transfert bidirectionnelle (BFD) avec des sessions BGP, configurez le BGP multihop à la fois sur l'appareil de serveur de routage dynamique et sur le périphérique homologue. Assurez-vous que la configuration BGP du périphérique homologue prend en charge le multihop afin d'activer la détection des défaillances BFD.

Considérations relatives à l'intégration de Transit Gateway

Tenez compte des considérations suivantes lorsque vous intégrez un serveur de routage dynamique à IBM Cloud® Transit Gateway:

• Vous pouvez créer une connexion de passerelle de transit vers un serveur de routage dynamique soit lors de la création d'une passerelle de transit, soit en ajoutant une connexion réseau à une passerelle de transit existante.
• Une instance de serveur de routage dynamique ne peut être connectée qu'à une seule passerelle de transit.
• Une connexion de passerelle de transit utilise des tunnels GRE (Generic Routing Encapsulation) redondants avec l' eBGP entre une passerelle de transit et les membres du serveur de routage dynamique.
• Si vous spécifiez un CIDR pour les adresses IP du tunnel GRE, celui-ci doit être d'au moins et /27 ne doit chevaucher aucun sous-réseau VPC ni aucun CIDR de tunnel de passerelle de transit existant.
• Si aucun CIDR n'est spécifié, une plage CIDR par défaut est utilisée.
• Lorsqu'un serveur de routage dynamique est connecté à une passerelle de transit, les routes apprises auprès de cette dernière ne peuvent être diffusées à d'autres pairs que si les politiques du serveur de routage dynamique l'autorisent.

Pour établir une connexion entre Transit Gateway et les appliances de serveurs de routage dynamiques, configurez les listes de contrôle d'accès réseau (NACL) afin d'autoriser le trafic GRE (protocole IP 47). Configurez également les règles du groupe de sécurité (SG) pour autoriser le trafic BGP (port TCP 179) et le trafic GRE (protocole IP 47) entre la passerelle Transit Gateway et les appliances de serveur de routage dynamique.

Considérations relatives aux tables de routage et aux politiques

Passez en revue les considérations suivantes relatives au routage avant de configurer les politiques de serveur de routage dynamique :

• Vous pouvez utiliser les politiques de pairs pour refléter les routes apprises entre pairs, diffuser des préfixes d'adresses VPC vers les pairs, ajouter des routes apprises aux tables de routage VPC et diffuser des routes statiques personnalisées.
• Un serveur de routage dynamique met à jour les tables de routage personnalisées du VPC en fonction des politiques de routage que vous définissez.
• Les routes ne sont ajoutées qu'aux tables de routage que vous référencez explicitement dans les politiques de table de routage du VPC.
• Si vous dépassez les limites de la table de routage, l'ajout d'une route peut échouer. Pour plus d'informations, consultez les quotas relatifs aux tables de routage et aux routes. Dans ce cas, vous devrez peut-être demander une augmentation de votre quota.
• Lorsqu'une politique de table de routage VPC est configurée, configurez les groupes de pairs d'un serveur de routes dynamiques de manière à ce que les pairs appartenant à des groupes différents n'annoncent pas la même destination. La diffusion de la même destination auprès de plusieurs groupes de pairs peut entraîner des incohérences dans les itinéraires appris.

Considérations relatives à la haute disponibilité et à la résilience

Passez en revue les considérations suivantes relatives à la disponibilité :

• Pour la tolérance aux pannes par zone, déployez un serveur de routage dynamique par zone de disponibilité.
• Chaque membre établit des sessions BGP indépendantes avec ses pairs.
• Si un nœud tombe en panne, le serveur de routage dynamique retire automatiquement les routes concernées et les réaffecte via des nœuds opérationnels.
• La surveillance de l'état de fonctionnement repose sur l'état de la session BGP et le statut BFD (si cette fonctionnalité est activée).

Remarques relatives à la sécurité

Passez en revue les considérations de sécurité suivantes :

• Les appliances de serveurs de routage dynamique sont gérées par IBM Cloud et s'exécutent dans des VPC isolés gérés par le service.
• La communication entre les composants du serveur de routage dynamique et les services IBM Cloud s'effectue via un réseau privé et des points de terminaison privés virtuels.
• Les groupes de sécurité associés aux VNI doivent autoriser le trafic BGP (port TCP179) ainsi que tout trafic supplémentaire spécifique à un pair nécessaire au contrôle du routage.
• Toutes les modifications de configuration et tous les événements du cycle de vie des serveurs de routage dynamiques sont consignés à l'aide de IBM Cloud® Activity Tracker. Pour plus d’informations, consultez les sections État et descriptions du serveur de routage dynamique, Événements du serveur de routage dynamique et Journalisation du serveur de routage dynamique.

Considérations opérationnelles

Passez en revue les considérations opérationnelles suivantes :

• Vous ne pouvez pas supprimer une instance de serveur de routage dynamique si des groupes de pairs ou des politiques existent encore et dépendent de cette instance.
• Pour supprimer une instance de serveur de routage dynamique, vous devez d'abord supprimer toutes les politiques, supprimer tous les groupes de pairs, puis détacher le serveur de routage dynamique de toutes les passerelles de transit.
• Les modifications de configuration, telles que l'ajout de pairs, de groupes de pairs ou de politiques, n'interrompent pas les flux de trafic existants.
• Les modifications d'acheminement sont immédiatement répercutées dans les tables de routage VPC, en fonction de la politique et de l'état de santé.

Liens connexes

Outre les considérations relatives à la planification, consultez la liste des problèmes connus avant de configurer un serveur de routage dynamique. Pour plus d'informations, consultez la section Problèmes connus concernant les serveurs de routage dynamiques.