Configuration du service BGP

Objectif

Le protocole Border Gateway Protocol (BGP) vous permet de construire des infrastructures hautement disponibles en exécutant le protocole de routage BGP standard directement à partir de vos hôtes OVHcloud. Il peut être utilisé avec les Additional IP d’OVHcloud ou avec vos propres adresses IP, en utilisant Bring Your Own IP (BYOIP).

Prérequis

• Au moins un serveur dédié Bare Metal parmi les gammes suivantes : High Grade, Scale, Advance Gen3. Tous les serveurs qui participeront au peering BGP doivent être dans la même région 1-AZ.
• Être connecté à l’espace client OVHcloud.
• Si vous utilisez Bring Your Own IP (BYOIP) : les préfixes IP que vous possédez et pouvez annoncer.
• Un réseau privé vRack.
• Des connaissances des réseaux IP et du protocole de routage BGP.
• Des connaissances des paramètres réseau Linux.

Capacités et limites du service

Avant de configurer le service BGP, veuillez prendre connaissance des capacités et contraintes suivantes :

• Un service BGP par région : Un seul service BGP peut être déployé par région disponible (hors régions 3-AZ, APAC et US actuellement).
• Plusieurs blocs IP : Il est possible d'utiliser plusieurs blocs IPv4 et IPv6 par région.
• Tailles de blocs utilisables : /24 à /30 pour l'IPv4, /56 pour l'IPv6.
• Pile IP : Les configurations IPv4 seul ou IPv4+IPv6 sont prises en charge. L'IPv6 seul n'est pas pris en charge actuellement.
• Blocs d'IP dédiés : Les blocs d'adresses Additional IP utilisés par un service BGP ne doivent pas être partagés avec d'autres services OVHcloud, tels que les serveurs dédiés, les instances Public Cloud, etc.
• Nombre maximum d'annonces par pair BGP : Jusqu'à 32 préfixes IPv4 et 32 préfixes IPv6 par client.
• Tailles d'annonces : Pour l'IPv4, tout préfixe entre /24 et /32 peut être annoncé. Pour l'IPv6, seuls les préfixes /56 et /64 peuvent être annoncés.
• BFD : Le protocole Bidirectional Forwarding Detection (BFD) est activé par défaut du côté d'OVHcloud, avec des paramètres fixes (intervalle de 500ms, multiplicateur de 8). Pour utiliser le protocole BFD, configurez votre service BGP avec ces mêmes paramètres.
• Sessions BGP : 4 sessions BGP par client (4 IPv4 + 4 IPv6). Au-delà de 4 hôtes en peering BGP, le déploiement d'un Route Server est nécessaire (voir le cas d'utilisation Configuration BGP avancée utilisant des Route Servers).
• Hôtes : Jusqu'à 10 hôtes par client.

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.
• 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 : rejoindre l'Alpha

Vous devez d'abord demander à rejoindre l'alpha sur cette page. Après réception de votre candidature, nous vous contacterons par e-mail.

Étape 2 : préparer vos adresses IP

Vous devez soit acheter des Additional IP chez OVHcloud, soit utiliser vos propres adresses IP avec BYOIP.

Si vous souhaitez importer vos adresses IP, vous devez utiliser notre service BYOIP. Veuillez suivre cette documentation pour importer vos IP chez OVHcloud.

Étape 3 : configurer votre vRack

Vous devez avoir créé un vRack, qui est un réseau privé où se fera le peering entre vos serveurs et le service BGP.

Le vRack doit contenir les serveurs qui participeront au peering BGP.

Étape 4 : fournir les paramètres de configuration de votre service BGP

Vous devez nous fournir les paramètres suivants afin que nous puissions configurer le service BGP côté OVHcloud :

Étape 5 : livraison du service BGP

Après environ 2 semaines, votre service sera livré. Nous vous recontacterons pour vous informer que le service est prêt à être utilisé et vous donner les paramètres nécessaires suivants de votre côté :

• Adresses IP des Edges OVHcloud (4 IPs)
• AS clients et AS OVHcloud à utiliser pour les sessions de peering BGP
• Paramètres BFD

Étape 6 : configuration côté client

Vous pouvez maintenant configurer les sessions BGP de votre côté. Vous trouverez ci-dessous une procédure qui détaille une configuration typique pour un load balancing simple à l'aide de BGP ECMP.

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 de sessions BGP côté OVHcloud é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

Les paramètres suivants sont à remplacer dans les fichiers de configuration de votre routeur par ceux convenus avec OVHcloud lors des étapes de configuration et de livraison.

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 lignes peuvent être ajoutées en fonction de 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 lignes peuvent être ajoutées en fonction de 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 votre session BGP avec la commande suivante :

show protocols all

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

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

• 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.

• 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.

Étape 6 : Vérifier la connectivité auprès de l'équipe OVHcloud

Une fois votre installation terminée et après avoir effectué des tests de base, vous devez nous en informer par e-mail à l'adresse bgp_alpha@ovh.net.

Nous nous assurerons que la connectivité BGP et les annonces IP sont correctes de notre côté.

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

Au-delà de 4 hôtes, déployez et gérez un Route Server (RS) sur un hôte dédié. Cette architecture permet de supporter jusqu'à 10 hôtes/nexthops. Le Route Server peut être déployé in-path ou out-of-path, selon votre architecture.

Les RS s'appairent avec les Load Balancing Edges (LBEdges) 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

Les paramètres ci-dessous doivent être substitués par ceux validés avec OVHcloud pendant les étapes de configuration et de livraison.

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 LBEdges et toutes les routes des Hôtes si elles correspondent à la longueur de préfixe définie (cf. les règles OVHcloud pour la longueur de préfixe IPv4 et IPv6). Les Route Servers publient les routes des hôtes vers les LBEdges 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 lignes peuvent être ajoutées en fonction de 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 lignes peuvent être ajoutées en fonction de 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_slow
  no shutdown
 ```

##### Configuration BGP

Configuration globale :

```bash
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_V4 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 lignes peuvent être ajoutées en fonction de 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 lignes peuvent être ajoutées en fonction de 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, et le client peut choisir n'importe quelle valeur parmi ses RS et 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

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 votre session BGP avec la commande suivante :

show protocols all

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

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

• 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.

• 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.

Étape 6 : Vérifier la connectivité auprès de l'équipe OVHcloud

Une fois votre installation terminée et après avoir effectué des tests de base, vous devez nous en informer par e-mail à l'adresse bgp_alpha@ovh.net.

Nous nous assurerons que la connectivité BGP et les annonces IP sont correctes de notre côté.

Bonnes pratiques en production

Maintenance d'un hôte sans interruption de trafic

Pour retirer un serveur en vue d'une maintenance (mise à jour de l'OS, intervention matérielle, etc.) sans interruption de trafic, vous pouvez utiliser le mécanisme BGP graceful shutdown (RFC 8326). Ce mécanisme signale aux pairs de déprioriser les routes vers l'hôte avant la coupure de la session, ce qui permet au trafic de basculer sur les hôtes restants sans perte de paquets. Cependant, 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.

Avec FRR, lancez un graceful shutdown sur l'hôte à maintenir :

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

FRR marque alors toutes les routes annoncées avec la communauté GRACEFUL_SHUTDOWN, indiquant aux pairs de privilégier les chemins alternatifs. Une fois le trafic drainé (vérifiez les tables de routage sur les autres hôtes ou le Route Server), vous pouvez procéder à la maintenance.

Après la maintenance, désactivez le graceful shutdown :

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

L'hôte reprend l'annonce de ses routes et recommence à recevoir du trafic.

Régions disponibles

Ce produit est disponible dans les régions suivantes :

Résolution des problèmes

Si vous recontrez des problèmes avec votre session BGP :

• Vérifiez que vos préfixes ASN et IP sont correctement configurés.
• Vérifiez qu'il n'y a pas d'annonces en conflit.
• Assurez-vous que vos stratégies de pare-feu et de réseau autorisent le trafic BGP.
• Contactez notre équipe pour obtenir de l'aide par e-mail : bgp_alpha@ovh.net

Aller plus loin

Échangez avec notre communauté d'utilisateurs.