Configuration du service BGP

Objectif

Le service BGP vous permet de construire des infrastructures hautement disponibles en exécutant le protocole de routage BGP (Border Gateway Protocol) standard directement depuis vos hôtes OVHcloud. Vos hôtes établissent des sessions BGP privées avec les routeurs OVHcloud via votre vRack et annoncent vos blocs d'IP publiques : des Additional IP OVHcloud ou vos propres adresses IP, importées avec Bring Your Own IP (BYOIP).

Le service BGP est une option de vRack Services : vous le commandez, le configurez et le gérez depuis l'onglet Service BGP de votre vRack Services.

Découvrez comment commander et configurer le service BGP, puis établir les sessions BGP sur vos hôtes.

Prérequis

• Disposer d'un réseau privé vRack et d'un vRack Services dans l'une des régions disponibles. Si votre vRack Services n'est pas encore lié à un vRack, vous pourrez en sélectionner ou en créer un lors de la commande du service BGP.
• Disposer des serveurs ou instances qui participeront au peering BGP (serveurs Bare Metal, machines virtuelles Hosted Private Cloud VMware on OVHcloud ou instances Public Cloud), connectés au vRack et directement au sous-réseau utilisé pour BGP.
• Disposer d'au moins un bloc d'IP publiques à annoncer : un bloc Additional IP ou votre propre bloc importé avec Bring Your Own IP (BYOIP).
• Avoir des connaissances des réseaux IP, du protocole de routage BGP et des paramètres réseau Linux.

Fonctionnement du service BGP

Le service BGP ajoute le routage de niveau 3 à votre vRack Services :

• Service BGP : un par vRack Services, donc un par région pour un même vRack. Il porte les ASN utilisés de part et d'autre des sessions BGP et la liste des blocs d'IP publiques que vous êtes autorisé à annoncer.
• Plage BGP (BGP range) : un petit bloc d'adresses privées (un /28 en IPv4, un /124 en IPv6) pris dans un sous-réseau de votre vRack Services, et donc utilisé au sein d'un réseau privé vRack. Elle contient les IP de peering utilisées aux deux extrémités des sessions BGP : 4 IP de peering OVHcloud et de 1 à 4 IP privées de peering client. Vous configurez une plage BGP pour l'IPv4 et, si vous annoncez des blocs IPv6, une pour l'IPv6.
• Blocs d'IP publiques : les blocs Additional IP ou BYOIP qu'OVHcloud accepte de vos sessions BGP. Un bloc absent de cette liste ne peut pas être annoncé.

Chacun de vos hôtes en peering établit une session BGP avec chacune des 4 IP de peering OVHcloud et annonce vos blocs d'IP publiques via ces sessions. OVHcloud les propage sur Internet et annonce en retour une route par défaut à vos hôtes. Lorsque plusieurs hôtes annoncent le même bloc, le trafic entrant est réparti entre eux (ECMP). Si un hôte cesse d'annoncer le bloc, son trafic bascule sur les hôtes restants en quelques secondes (environ 4 secondes avec BFD : intervalle de 500 ms, multiplicateur de 8), sans aucun appel à l'API OVHcloud.

Capacités du service

• Un service BGP par vRack Services : un vRack Services est régional, et un vRack ne peut être lié qu'à un seul vRack Services par région.
• Sous-réseau : sous-réseau IPv4 et/ou IPv6 de votre vRack Services, utilisé également par le service BGP. Ces sous-réseaux ne doivent pas être tagués (pas de VLAN) et ne peuvent plus être changés une fois configurés.
• Plage BGP : définit la partie d'un sous-réseau privé client utilisée pour adresser les hôtes de peering OVHcloud et client (next hops) ou les Route Servers. /28 en IPv4, /124 en IPv6.
• IP de peering OVHcloud : exactement 4 IP de peering OVHcloud par version d'IP, calculées à partir de la plage BGP.
• IP de peering client : de 1 à 4 pairs BGP (10 hôtes next hop au maximum au total), calculés à partir de la plage BGP. Au-delà de 4 hôtes en peering BGP, déployez des Route Servers (voir le cas d'utilisation Configuration BGP avancée utilisant des Route Servers).
• ASN : ASN privés uniquement. L'ASN client (64512 par défaut) et l'ASN OVHcloud (65534 par défaut) doivent tous deux être compris entre 64512 et 65534, et les deux valeurs doivent être différentes. Les ASN sont communs aux configurations IPv4 et IPv6.
• Blocs d'IP publiques : jusqu'à 50 blocs par version d'IP, dont 32 au maximum par version d'IP peuvent être annoncés simultanément, tous pairs confondus.
• Tailles des blocs d'IP publiques :

• Tailles des annonces : vous pouvez annoncer un bloc d'IP publiques entier ou n'importe quel sous-ensemble de ce bloc, jusqu'à /32 en IPv4 et /64 en IPv6.
• Blocs d'IP dédiés : un bloc d'IP publiques ne peut appartenir qu'à un seul service BGP à la fois. Seuls les blocs Additional IP qui ne sont associés à aucun autre service (serveur dédié, instance Public Cloud, etc.) peuvent être sélectionnés.
• Routes reçues : OVHcloud annonce uniquement une route par défaut.
• Bande passante : 5 000 Mbit/s par service BGP.
• Non pris en charge : l'authentification MD5 des sessions BGP, les ASN publics et les annonces anycast. OVHcloud ignore les communautés BGP associées aux routes annoncées par vos hôtes.
• Maintenances OVHcloud : avant une maintenance de son côté, OVHcloud peut marquer les routes qu'il annonce avec la communauté GRACEFUL_SHUTDOWN (RFC 8326).
• BFD : le protocole Bidirectional Forwarding Detection (BFD) est activé par défaut du côté d'OVHcloud, avec des paramètres fixes (intervalle de 500 ms, multiplicateur de 8). Pour utiliser BFD, configurez vos hôtes avec ces mêmes valeurs.

Cas d'usage potentiels

Le service BGP prend en charge une large gamme d'architectures réseau personnalisées ; les exemples suivants illustrent certaines des implémentations les plus courantes :

• Exécutez votre propre stack de routage (FRR/Bird/VMware NSX, etc.) sur des serveurs Bare Metal ou des routeurs virtuels et établissez des sessions BGP standard directement avec les Edges OVHcloud.
• Créez des frontends à haute disponibilité : utilisez BGP pour déplacer des adresses IP entre plusieurs serveurs (actif/actif ou actif/passif) en modifiant vos annonces BGP, permettant ainsi un basculement rapide (failover).
• Mettez en place le routage ECMP / multi-path entre vos hôtes et le backbone OVHcloud pour renforcer la résilience sur plusieurs serveurs ou VM.
• Remplacez le mécanisme de basculement des Additional IP : conservez le même bloc Additional IP, mais annoncez-le avec BGP pour basculer en quelques secondes et servir le trafic depuis plusieurs hôtes à la fois.
• Concevez des nœuds de services multi-tenants en remplaçant le proxy-ARP L2 par du routage L3 natif, où les préfixes IP des clients sont routés via votre infrastructure en tant que next hop.

En pratique

Étape 1 : préparer vos blocs d'IP publiques

Vous devez soit acheter un bloc Additional IP chez OVHcloud, soit importer votre propre bloc d'IP avec BYOIP. Pour importer vos IP, suivez notre documentation BYOIP.

Le bloc doit se trouver dans la même région que votre vRack Services.

Étape 2 : préparer votre vRack et votre vRack Services

Le service BGP s'appuie sur un vRack Services, dans la région où se trouvent vos hôtes. Si vous n'en avez pas encore, créez un vRack Services dans cette région et liez-le au vRack qui contient vos hôtes (consultez notre guide vRack Services).

Étape 3 : commander le service BGP

Accès à la console OVHcloud

• Lien direct : vRack Services
• Pour accéder à vos services : Bare Metal Cloud > vRack Services

Sélectionnez votre vRack Services, ouvrez l'onglet Service BGP, puis cliquez sur Commander un service BGP.

Sur la page Commander un service BGP :

• Si votre vRack Services n'est pas encore lié à un vRack, sélectionnez le vRack à utiliser. Seuls les vRack qui ne sont pas déjà liés à un autre vRack Services dans la même région sont proposés. Pour utiliser un nouveau vRack, cliquez sur Commander un vRack : une fois créé, le vRack est sélectionné automatiquement.
• Vérifiez le récapitulatif de la commande, cliquez sur Continuer ma commande, puis finalisez votre commande.

Une fois votre service BGP livré, l'onglet Service BGP affiche ses informations et son statut, Draft, tant que vous ne l'avez pas configuré.

Étape 4 : configurer l'IPv4 du service BGP

Dans l'onglet Service BGP, ouvrez Configuration IPv4 et cliquez sur Configurer l'IPv4.

Remplissez le formulaire :

Dès que vous avez saisi une plage BGP valide, le formulaire suggère des IP de peering (affichées en gris) calculées à partir de celle-ci. Par exemple, avec la plage BGP 10.35.0.16/28 :

Cliquez sur Enregistrer.

Une fois la configuration appliquée, le Statut du service de votre service BGP passe à Ready. S'il reste à Draft, survolez l'icône d'information à côté du statut pour connaître l'élément manquant : Aucune plage BGP déclarée ou Aucun bloc d'IP publiques déclaré.

Étape 5 : configurer l'IPv6 du service BGP (facultatif)

Pour annoncer des blocs IPv6, ouvrez Configuration IPv6 dans l'onglet Service BGP et cliquez sur Configurer l'IPv6.

Le formulaire est identique à celui de l'IPv4, aux différences suivantes près :

• Le sous-réseau est un sous-réseau IPv6 en adresses privées ULA (fd00::/8), par exemple fd00::/64.
• La plage BGP est un bloc /124 compris dans ce sous-réseau, par exemple fd00::10/124.
• Les blocs d'IP publiques sont des blocs IPv6 /56.
• Les valeurs ASN privé du client et ASN privé OVHcloud sont communes avec la configuration IPv4.

Cliquez sur Enregistrer.

Étape 6 : configurer BGP sur vos hôtes

Vous pouvez maintenant établir les sessions BGP de votre côté, à l'aide des valeurs affichées dans la section Configuration de l'onglet Service BGP :

Configurez chaque IP de peering client sur un hôte (ou un Route Server) directement connecté au sous-réseau BGP.

Les cas d'utilisation ci-dessous détaillent deux configurations types : un load balancing sur 4 hôtes au maximum, et une configuration avec des Route Servers pour 10 hôtes au maximum.

Cas d'utilisation : Configuration BGP simple - Load Balancing utilisant BGP et ECMP

Cette architecture convient aux configurations avec jusqu'à 4 hôtes en peering BGP, le nombre d'IP de peering client étant limité à 4. Au-delà, reportez-vous au cas d'utilisation Configuration BGP avancée utilisant des Route Servers ci-dessous.

Voici une architecture simple qui vous permet d'effectuer un load balancing de votre trafic sur 3 hôtes :

Pour réaliser cette installation, vous devez installer un daemon BGP, tel que FRR, sur chaque hôte.

Paramètres

Dans les fichiers de configuration de votre routeur, remplacez les paramètres suivants par les valeurs de la configuration de votre service BGP.

Configuration d'un daemon BGP (FRR)

Pour établir une session BGP à l'aide de FRR, suivez les étapes ci-dessous.

Étape 1 : Installer FRR

Sur un système basé sur Debian, installez FRR avec la commande suivante :

sudo apt update && sudo apt install frr frr-pythontools

Étape 2 : Configurer FRR

Configuration des listes de préfixes et route-maps

Dans cet exemple :

• Les hôtes n'acceptent que les routes par défaut provenant des Edges OVHcloud.
• Les hôtes n'annoncent que les préfixes du client aux Edges OVHcloud.

Listes de préfixes et route-maps connexes pour filtrer les routes :

ip prefix-list PL_DEFAULT_ROUTE_V4 seq 10 permit 0.0.0.0/0

ip prefix-list PL_CUSTOMER_PREFIX_V4 seq 10 permit <CUSTOMER_PREFIX_V4> ge <length>
... <d'autres séquences peuvent être ajoutées selon la configuration du client>

ipv6 prefix-list PL_DEFAULT_ROUTE_V6 seq 10 permit ::/0

ipv6 prefix-list PL_CUSTOMER_PREFIX_V6 seq 10 permit <CUSTOMER_PREFIX_V6> eq <length>
... <d'autres séquences peuvent être ajoutées selon la configuration du client>


route-map RM_EDGE_V4_OUT permit 10
  match ip address prefix-list PL_CUSTOMER_PREFIX_V4
route-map RM_EDGE_V4_IN permit 10
  match ip address prefix-list PL_DEFAULT_ROUTE_V4

route-map RM_EDGE_V6_OUT permit 10
  match ipv6 address prefix-list PL_CUSTOMER_PREFIX_V6
route-map RM_EDGE_V6_IN permit 10
  match ipv6 address prefix-list PL_DEFAULT_ROUTE_V6

Configuration BFD

bfd
 profile edge
  detect-multiplier 8
  receive-interval 500
  transmit-interval 500

 peer <EDGE_IPV4>
  profile edge
  no shutdown
...
 peer <EDGE_IPV6>
  profile edge
  no shutdown
...

Configuration BGP

Configuration globale :

router bgp <CUSTOMER_ASN>
 bgp router-id <HOST_IPV4>
 no bgp default ipv4-unicast
 maximum-paths 16
 maximum-paths ibgp 16

Appairage BGP avec les Edges OVHcloud :

router bgp <CUSTOMER_ASN>
 neighbor PG_EDGE_V4 peer-group
 neighbor PG_EDGE_V4 remote-as <OVHcloud_ASN>
 neighbor PG_EDGE_V4 bfd
 neighbor PG_EDGE_V6 peer-group
 neighbor PG_EDGE_V6 remote-as <OVHcloud_ASN>
 neighbor PG_EDGE_V6 bfd
 neighbor <EDGE_IPV4> peer-group PG_EDGE_V4
...
 neighbor <EDGE_IPV6> peer-group PG_EDGE_V6
...

 address-family ipv4 unicast
  neighbor PG_EDGE_V4 activate
  neighbor PG_EDGE_V4 route-map RM_EDGE_V4_IN in
  neighbor PG_EDGE_V4 route-map RM_EDGE_V4_OUT out
 address-family ipv6 unicast
  neighbor PG_EDGE_V6 activate
  neighbor PG_EDGE_V6 route-map RM_EDGE_V6_IN in
  neighbor PG_EDGE_V6 route-map RM_EDGE_V6_OUT out

Étape 3 : Redémarrer FRR

Après avoir modifié la configuration, redémarrez FRR pour appliquer les modifications :

sudo systemctl restart frr

Étape 4 : Vérifier l'état de la session BGP

Vérifiez l'état de vos sessions BGP avec la commande suivante :

vtysh -c 'show bgp summary'

Les sessions avec les Edges OVHcloud doivent être à l'état Established.

Étape 5 : Vérifier la connectivité entrante et sortante

Pour vous assurer que votre session BGP fonctionne correctement, testez le trafic entrant et sortant :

• Vérifier le trafic entrant

Utilisez un serveur distant pour effectuer un ping ou traceroute vers votre préfixe IP publié :

ping YOUR_ADVERTISED_IP
traceroute YOUR_ADVERTISED_IP

Vérifiez que le trafic atteint votre réseau via les chemins d'accès BGP attendus.

• Vérifier le trafic sortant

Depuis votre serveur, vérifiez la table de routage et assurez-vous que vos routes BGP sont bien utilisées :

ip route show
vtysh -c 'show ip route bgp'

Confirmez que le trafic sortant suit les chemins d'accès BGP corrects.

Cas d'utilisation : Configuration BGP avancée utilisant des Route Servers (RS)

Au-delà de 4 hôtes, vous devez déployer et gérer des Route Servers (RS). Cette architecture prend en charge jusqu'à 10 hôtes/next hops. Chaque Route Server utilise l'une des 4 IP de peering client : vous pouvez donc déployer jusqu'à 4 Route Servers. Le Route Server peut être déployé in-path ou out-of-path, selon votre architecture.

Les RS s'appairent avec les Edges OVHcloud et les hôtes, et établissent deux sessions par pair (une pour l'IPv4, l'autre pour l'IPv6).

Voici une vue d'ensemble du système :

Et voici une vue détaillée des sessions BGP entre les Edges, les RS et les Hôtes :

Pour réaliser cette installation, vous devez installer un daemon BGP, comme FRR, sur chaque hôte et le configurer.

Paramètres

Dans les fichiers de configuration de votre routeur, remplacez les paramètres suivants par les valeurs de la configuration de votre service BGP.

Configuration d'un daemon BGP (FRR)

Pour établir une session BGP à l'aide de FRR, suivez les étapes ci-dessous.

Étape 1 : Installer FRR

Sur un système basé sur Debian, installez FRR avec la commande suivante :

sudo apt update && sudo apt install frr frr-pythontools

Étape 2 : Configurer FRR

Configuration de FRR sur les Route Servers

Configuration des listes de préfixes et route-maps

Les Route Servers acceptent les routes par défaut des Edges OVHcloud et toutes les routes des hôtes si elles correspondent à la longueur de préfixe définie (voir les tailles d'annonces autorisées dans la section Capacités du service). Les Route Servers annoncent les routes des hôtes vers les Edges OVHcloud et les routes par défaut vers les hôtes.

Listes de préfixes et route-maps connexes pour filtrer les routes :

ip prefix-list PL_DEFAULT_ROUTE_V4 seq 10 permit 0.0.0.0/0

ip prefix-list PL_CUSTOMER_PREFIX_V4 seq 10 permit <CUSTOMER_PREFIX_V4> ge <length>
... <d'autres séquences peuvent être ajoutées selon la configuration du client>

ipv6 prefix-list PL_DEFAULT_ROUTE_V6 seq 10 permit ::/0

ipv6 prefix-list PL_CUSTOMER_PREFIX_V6 seq 10 permit <CUSTOMER_PREFIX_V6> eq <length>
... <d'autres séquences peuvent être ajoutées selon la configuration du client>


route-map RM_EDGE_V4_OUT deny 10
 match ip address prefix-list PL_DEFAULT_ROUTE_V4
route-map RM_EDGE_V4_OUT permit 20
  match ip address prefix-list PL_CUSTOMER_PREFIX_V4

route-map RM_EDGE_V4_IN permit 10
 match ip address prefix-list PL_DEFAULT_ROUTE_V4

route-map RM_HOST_V4_IN deny 10
  match ip address prefix-list PL_DEFAULT_ROUTE_V4
route-map RM_HOST_V4_IN permit 20
  match ip address prefix-list PL_CUSTOMER_PREFIX_V4

route-map RM_HOST_V4_OUT permit 10
 match ip address prefix-list PL_DEFAULT_ROUTE_V4


route-map RM_EDGE_V6_OUT deny 10
 match ipv6 address prefix-list PL_DEFAULT_ROUTE_V6
route-map RM_EDGE_V6_OUT permit 20
  match ipv6 address prefix-list PL_CUSTOMER_PREFIX_V6

route-map RM_EDGE_V6_IN permit 10
 match ipv6 address prefix-list PL_DEFAULT_ROUTE_V6

route-map RM_HOST_V6_IN deny 10
  match ipv6 address prefix-list PL_DEFAULT_ROUTE_V6
route-map RM_HOST_V6_IN permit 20
  match ipv6 address prefix-list PL_CUSTOMER_PREFIX_V6

route-map RM_HOST_V6_OUT permit 10
 match ipv6 address prefix-list PL_DEFAULT_ROUTE_V6

Configuration BFD

bfd
 profile edge
  detect-multiplier 8
  receive-interval 500
  transmit-interval 500

 peer <EDGE_IPV4>
  profile edge
  no shutdown
 peer <EDGE_IPV6>
  profile edge
  no shutdown

Configuration BGP

Configuration globale :

router bgp <CUSTOMER_ASN>
 bgp router-id <RS_IPV4>
 no bgp default ipv4-unicast

Appairage BGP avec les Edges OVHcloud :

router bgp <CUSTOMER_ASN>
 neighbor PG_EDGE_V4 peer-group
 neighbor PG_EDGE_V4 remote-as <OVHcloud_ASN>
 neighbor PG_EDGE_V4 bfd
 neighbor PG_EDGE_V6 peer-group
 neighbor PG_EDGE_V6 remote-as <OVHcloud_ASN>
 neighbor PG_EDGE_V6 bfd
 neighbor <EDGE_IPV4> peer-group PG_EDGE_V4
 neighbor <EDGE_IPV6> peer-group PG_EDGE_V6

 address-family ipv4 unicast
  neighbor PG_EDGE_V4 activate
  neighbor PG_EDGE_V4 addpath-tx-all-paths
  neighbor PG_EDGE_V4 attribute-unchanged next-hop
  neighbor PG_EDGE_V4 route-map RM_EDGE_V4_IN in
  neighbor PG_EDGE_V4 route-map RM_EDGE_V4_OUT out
 address-family ipv6 unicast
  neighbor PG_EDGE_V6 activate
  neighbor PG_EDGE_V6 addpath-tx-all-paths
  neighbor PG_EDGE_V6 attribute-unchanged next-hop
  neighbor PG_EDGE_V6 route-map RM_EDGE_V6_IN in
  neighbor PG_EDGE_V6 route-map RM_EDGE_V6_OUT out

Appairage BGP avec les Hôtes :

router bgp <CUSTOMER_ASN>
 neighbor PG_HOST_V4 peer-group
 neighbor PG_HOST_V4 remote-as <CUSTOMER_ASN>
 neighbor PG_HOST_V6 peer-group
 neighbor PG_HOST_V6 remote-as <CUSTOMER_ASN>
 neighbor <HOST_IPV4> peer-group PG_HOST_V4
 neighbor <HOST_IPV6> peer-group PG_HOST_V6

 address-family ipv4 unicast
  neighbor PG_HOST_V4 activate
  neighbor PG_HOST_V4 addpath-tx-all-paths
  neighbor PG_HOST_V4 route-map RM_HOST_V4_IN in
  neighbor PG_HOST_V4 route-map RM_HOST_V4_OUT out
 address-family ipv6 unicast
  neighbor PG_HOST_V6 activate
  neighbor PG_HOST_V6 addpath-tx-all-paths
  neighbor PG_HOST_V6 route-map RM_HOST_V6_IN in
  neighbor PG_HOST_V6 route-map RM_HOST_V6_OUT out

Configuration de FRR sur les Hôtes

Configuration des listes de préfixes et route-maps

Dans cet exemple :

• Les hôtes n'acceptent que les routes par défaut provenant des RS.
• Les hôtes n'annoncent que les préfixes du client aux RS.

Listes de préfixes et route-maps connexes pour filtrer les routes :

ip prefix-list PL_DEFAULT_ROUTE_V4 seq 10 permit 0.0.0.0/0

ip prefix-list PL_CUSTOMER_PREFIX_V4 seq 10 permit <CUSTOMER_PREFIX_V4> ge <length>
... <d'autres séquences peuvent être ajoutées selon la configuration du client>

ipv6 prefix-list PL_DEFAULT_ROUTE_V6 seq 10 permit ::/0

ipv6 prefix-list PL_CUSTOMER_PREFIX_V6 seq 10 permit <CUSTOMER_PREFIX_V6> eq <length>
... <d'autres séquences peuvent être ajoutées selon la configuration du client>


route-map RM_RS_V4_OUT permit 10
  match ip address prefix-list PL_CUSTOMER_PREFIX_V4
route-map RM_RS_V4_IN permit 10
  match ip address prefix-list PL_DEFAULT_ROUTE_V4

route-map RM_RS_V6_OUT permit 10
  match ipv6 address prefix-list PL_CUSTOMER_PREFIX_V6
route-map RM_RS_V6_IN permit 10
  match ipv6 address prefix-list PL_DEFAULT_ROUTE_V6

Configuration BFD

Les valeurs ci-dessous sont données à titre d'exemple : vous pouvez choisir d'autres valeurs pour vos RS et vos hôtes.

bfd
 profile rs
  detect-multiplier 8
  receive-interval 500
  transmit-interval 500

 peer <RS_IPV4>
  profile rs
  no shutdown
...
 peer <RS_IPV6>
  profile rs
  no shutdown
...

Configuration BGP

Configuration globale :

router bgp <CUSTOMER_ASN>
 bgp router-id <HOST_IPV4>
 no bgp default ipv4-unicast
 maximum-paths 16
 maximum-paths ibgp 16

Appairage BGP avec les RS :

router bgp <CUSTOMER_ASN>
 neighbor PG_RS_V4 peer-group
 neighbor PG_RS_V4 remote-as <CUSTOMER_ASN>
 neighbor PG_RS_V4 bfd
 neighbor PG_RS_V6 peer-group
 neighbor PG_RS_V6 remote-as <CUSTOMER_ASN>
 neighbor PG_RS_V6 bfd
 neighbor <RS_IPV4> peer-group PG_RS_V4
...
 neighbor <RS_IPV6> peer-group PG_RS_V6
...

 address-family ipv4 unicast
  neighbor PG_RS_V4 activate
  neighbor PG_RS_V4 route-map RM_RS_V4_IN in
  neighbor PG_RS_V4 route-map RM_RS_V4_OUT out
 address-family ipv6 unicast
  neighbor PG_RS_V6 activate
  neighbor PG_RS_V6 route-map RM_RS_V6_IN in
  neighbor PG_RS_V6 route-map RM_RS_V6_OUT out

Étape 3 : Redémarrer FRR

Sur chaque hôte et RS, après avoir modifié la configuration, redémarrez FRR pour appliquer les modifications :

sudo systemctl restart frr

Étape 4 : Vérifier l'état de la session BGP

Vérifiez l'état de vos sessions BGP sur vos hôtes et RS avec la commande suivante :

vtysh -c 'show bgp summary'

Les sessions doivent être à l'état Established.

Étape 5 : Vérifier la connectivité entrante et sortante

Pour vous assurer que votre session BGP fonctionne correctement, testez le trafic entrant et sortant :

• Vérifier le trafic entrant

Utilisez un serveur distant pour effectuer un ping ou traceroute vers votre préfixe IP publié :

ping YOUR_ADVERTISED_IP
traceroute YOUR_ADVERTISED_IP

Vérifiez que le trafic atteint votre réseau via les chemins d'accès BGP attendus.

• Vérifier le trafic sortant

Depuis votre serveur, vérifiez la table de routage et assurez-vous que vos routes BGP sont bien utilisées :

ip route show
vtysh -c 'show ip route bgp'

Confirmez que le trafic sortant suit les chemins d'accès BGP corrects.

Gérer votre service BGP

Toutes les actions ci-dessous sont disponibles dans l'onglet Service BGP de votre vRack Services.

Modifier une configuration

Dans la section Configuration, sélectionnez Configuration IPv4 ou Configuration IPv6, puis cliquez sur Configurer l'IPv4 (ou Configurer l'IPv6).

Vous pouvez modifier la plage BGP, les ASN, les IP de peering et les blocs d'IP publiques. Pour retirer un bloc d'IP publiques, cliquez sur la croix de son étiquette. Le sous-réseau ne peut pas être modifié.

Certaines modifications redémarrent les sessions BGP et peuvent interrompre votre trafic :

Lorsque vous modifiez un ASN ou la plage BGP, ou que vous retirez le dernier bloc d'IP publiques, un bandeau vous avertit que le service va redémarrer et liste les champs concernés. Planifiez les modifications qui redémarrent les sessions BGP pendant une fenêtre de maintenance, puis cliquez sur Enregistrer.

Renommer votre service BGP

Dans la section Informations, cliquez sur l'icône en forme de crayon à côté du Nom du service BGP, saisissez le nouveau nom, puis enregistrez.

Résilier votre service BGP

Dans la section Informations, cliquez sur Résilier le service BGP, puis confirmez avec Résilier.

Le service s'arrête à la fin de la période de facturation en cours : vos sessions BGP et vos annonces de préfixes prennent alors fin, et la configuration est supprimée. Il en va de même si le service n'est pas renouvelé. La résiliation est irréversible. Avant de résilier, assurez-vous que votre trafic ne dépend plus des blocs d'IP annoncés.

Bonnes pratiques en production

Maintenance d'un hôte sans interruption de trafic

Pour retirer un hôte du service en vue d'une maintenance (mise à jour de l'OS, intervention matérielle, etc.), retirez ses annonces avant de l'arrêter. Les pairs OVHcloud ignorent les communautés envoyées par vos hôtes : marquer les routes avec GRACEFUL_SHUTDOWN ne draine donc pas le trafic entrant. L'hôte doit cesser d'annoncer les blocs.

Avec FRR, coupez toutes les sessions BGP de l'hôte à maintenir :

vtysh -c 'configure terminal' -c 'router bgp <CUSTOMER_ASN>' -c 'bgp shutdown'

L'hôte ferme ses sessions et ses routes sont retirées : le trafic entrant bascule sur les hôtes restants qui annoncent les mêmes blocs. Retirer les routes avant d'arrêter l'hôte évite d'attendre la détection de panne (environ 4 secondes avec BFD). Cela ne permet pas de maintenir des sessions (par exemple, TCP) si celles-ci ne sont pas synchronisées entre les hôtes annonçant la route. Une fois le trafic basculé (vérifiez les tables de routage des autres hôtes ou du Route Server), procédez à la maintenance.

Après la maintenance, réactivez les sessions :

vtysh -c 'configure terminal' -c 'router bgp <CUSTOMER_ASN>' -c 'no bgp shutdown'

L'hôte rétablit ses sessions, annonce de nouveau ses blocs et recommence à recevoir du trafic.

Régions disponibles

Ce produit est disponible dans les régions suivantes :

Résolution des problèmes

Si vous rencontrez des problèmes avec votre service BGP :

• Le statut reste à Draft : survolez l'icône d'information à côté du statut pour en connaître la raison. Aucune plage BGP déclarée indique que la configuration est incomplète ; Aucun bloc d'IP publiques déclaré indique qu'aucun bloc d'IP publiques n'est sélectionné.
• Un bloc d'IP publiques n'est pas proposé dans la liste : vérifiez que le bloc se trouve dans la même région que votre vRack Services, qu'il n'est associé à aucun autre service et qu'il n'est pas déjà utilisé par un autre service BGP.
• Une session BGP n'atteint pas l'état Established : vérifiez que l'hôte utilise l'une des IP de peering client, qu'il est directement connecté au sous-réseau BGP et que les ASN configurés sur l'hôte correspondent aux valeurs ASN privé du client et ASN privé OVHcloud.
• Votre préfixe n'est pas joignable depuis Internet : vérifiez qu'il appartient à l'un de vos blocs d'IP publiques, que sa taille est autorisée et qu'aucune annonce n'entre en conflit.
• Assurez-vous que vos règles de pare-feu et vos politiques réseau autorisent le trafic BGP (port TCP 179) et, si vous l'utilisez, BFD (ports UDP 3784 et 3785).

Si le problème persiste, créez une demande d'assistance depuis notre centre d'aide.

Aller plus loin

Exposer un service managé sur votre vRack avec vRack Services

Bring Your Own IP (BYOIP)

Échangez avec notre communauté d'utilisateurs.