BYOIP chez Vultr : annoncez vos propres adresses IP en BGP

Vous demandez l'accès BGP, Vultr contrôle le préfixe et le fait confirmer par le contact du registre, puis votre instance annonce le préfixe à Vultr. Vultr n'attribue pas d'adresses appartenant au client à des instances d'une autre manière.

Ce que Vultr accepte

D'après la documentation de Vultr, le jour de notre vérification :

• Taille. IPv4 du /24 au /16, IPv6 du /48 au /32. Au plus cinq préfixes par client, IPv4 et IPv6 confondus.
• Registre. N'importe quel registre Internet régional ; le guide de demande cite l'ARIN, le RIPE NCC et l'APNIC comme exemples. Rien sur l'espace PA, PI ou legacy.
• Qui annonce. Votre propre ASN, avec AS20473 devant lui sur Internet, ou AS20473 lui-même si Vultr vous attribue un ASN privé.
• Où. N'importe quel site Vultr, mais « our locations are not linked » (traduction : « nos sites ne sont pas reliés ») : vous annoncez un /24 depuis chaque site où vous utilisez les adresses, ou un préfixe depuis plusieurs sites en anycast. Un préfixe ne peut pas être partagé avec un autre compte.
• Qui peut demander. Un compte avec au moins une instance Compute active. Le bare metal fonctionne aussi, avec un ticket au support nommant les serveurs qui annonceront le préfixe.
• Prix. La page Cloud Networking de Vultr dit : « There is no additional cost for running BGP with us. » (traduction : « Faire tourner du BGP chez nous n'entraîne aucun coût supplémentaire. ») La documentation BGP et BYOIP ne cite aucun frais pour apporter un préfixe.
• Délai. 24 à 48 heures après la confirmation du contact du registre, puis 6 à 48 heures pour les filtres des opérateurs de transit.

Avant de commencer

Un ROA. La politique de Vultr en recommande un pour accélérer l'acceptation, et son contrôle d'intégration rejette un ROA erroné. Le ROA nomme votre ASN public, ou AS20473 si vous utilisez un ASN privé Vultr : « any ROA signed with a different ASN will be rejected by Vultr's system as invalid » (traduction : « tout ROA signé avec un autre ASN sera rejeté comme invalide par le système de Vultr ») (RPKI et ROA).

Un objet route, si vous voulez le vôtre. Sans objet route, Vultr le crée dans RADb. Avec un ASN public, Vultr ajoute aussi votre ASN à RADB::AS20473:AS-CONE, à partir duquel la plupart des opérateurs de transit construisent leurs filtres. Vultr accepte les objets route de RADb, de l'ARIN, de la base de données RIPE et de l'APNIC.

Une lettre d'autorisation (LOA). Le modèle de Vultr autorise « Vultr with AS20473 to announce the following IP address blocks » (traduction : « Vultr, avec AS20473, à annoncer les blocs d'adresses IP suivants ») et est signé par un représentant de l'entreprise qui les détient. Vous le téléversez avec la demande.

Un contact de registre qui lit ses e-mails. Vultr confirme le préfixe par e-mail à un point de contact de l'objet du registre, et vous laisse choisir lequel quand l'objet en a plusieurs. Choisissez une boîte mail que quelqu'un lit.

Étape par étape

01Demandez l'accès BGP. Dans la Vultr Console, ouvrez Products, Network, BGP et cliquez sur Get Started. Activez I have my own IP space, saisissez votre ASN, un mot de passe BGP et le préfixe, et téléversez la LOA. Choisissez les routes que Vultr vous envoie, décrivez votre usage et cliquez sur Request BGP Setup.

02Passez les contrôles. Vultr vérifie entre autres les listes de Spamhaus et le ROA, et affiche un avertissement dans la console si un contrôle échoue. Le contact du registre clique ensuite sur le lien de l'e-mail de Vultr, et les contrôles finaux prennent 24 à 48 heures.

03Redémarrez depuis le panneau de contrôle toute instance déployée avant la mise en place du BGP. Un redémarrage via SSH ne suffit pas.

04Montez la session depuis l'adresse IP principale de l'instance, avec le mot de passe et un multihop de 2. Sur un VPS, le voisin est 169.254.169.254 dans AS64515 ; sur du bare metal, c'est 169.254.1.1 dans AS20473. Vultr recommande BIRD. Son exemple, avec des valeurs de documentation et une route statique pour votre bloc :

router id 192.0.2.10;

protocol device {
  scan time 5;
}

protocol static {
  ipv4;
  route 203.0.113.0/24 unreachable;
}

protocol bgp vultr {
  local as 64500;
  source address 192.0.2.10;
  ipv4 {
    import none;
    export all;
  };
  graceful restart on;
  multihop 2;
  neighbor 169.254.169.254 as 64515;
  password "your-bgp-password";
}

birdc show proto all vultr doit indiquer Established. L'onglet BGP de chaque instance dans la console propose aussi des exemples de configuration BIRD et FRR.

05Mettez les adresses en service. Ajoutez une adresse à une interface dummy et laissez BIRD l'exporter en /32 (un bloc protocol direct pour dummy*) à côté du /24 couvrant. Plusieurs instances d'un même site peuvent annoncer le même /32 pour la bascule (failover).

06Tenez compte des filtres. Là où les opérateurs de transit filtrent à partir des données IRR, comme en Europe et aux États-Unis, les mises à jour prennent en général 6 à 24 heures. Les filtres manuels, comme en Inde et en Israël, peuvent prendre plus de 48 heures.

Les erreurs qui coûtent une journée

• L'ASN privé dans le ROA. Avec un ASN privé Vultr, le ROA nomme AS20473, jamais le numéro privé. Vultr contrôle le RPKI chaque nuit, et un ROA qui devient invalide retire automatiquement un préfixe actif.
• La longueur maximale. « Invalid Prefix Length » dans la console signifie que la longueur maximale du ROA ne correspond pas à ce que vous annoncez. La solution de Vultr est un nouveau ROA avec la bonne longueur, « such as 24 for IPv4 » (traduction : « par exemple 24 pour l'IPv4 »).
• Un contact de registre obsolète. Si personne ne lit la boîte aux lettres de l'objet du registre, l'intégration s'arrête à l'e-mail de confirmation.
• Des pages qui se contredisent sur l'ASN. Le guide de demande, mis à jour le 16 octobre 2026, associe votre propre espace IP à votre propre ASN et dit que sans ASN vous utilisez l'espace IP de Vultr. Le guide BGP du 15 avril 2026, la page d'intégration et la page RPKI admettent un ASN privé Vultr avec votre propre espace, le ROA nommant AS20473. Précisez ce que vous voulez dans le champ du cas d'usage.
• Retirer un préfixe demande un ticket au support.

Si vous louez le bloc

La page RPKI de Vultr dit que seul le propriétaire d'un espace IP peut gérer ses ROA, et « if you are leasing IP space, contact your provider » (traduction : « si vous louez un espace IP, contactez votre fournisseur ») pour le RPKI. Le titulaire fait trois choses : il crée le ROA pour votre ASN ou pour AS20473, signe la LOA en tant qu'entreprise qui détient le bloc, et clique sur le lien de confirmation que Vultr envoie au contact du registre. Vultr n'exige pas que le bloc soit à votre nom, mais il retire un préfixe dont il constate qu'il appartient à une autre entité : conservez donc la LOA du titulaire dans vos dossiers.

La place de RTM Networks

Nous louons des /24 et plus grands depuis notre propre espace d'adresses RIPE NCC, et vendons des blocs dans les régions du RIPE NCC, de l'ARIN et de l'APNIC. Pour un espace loué chez nous, nous créons le ROA pour votre ASN ou AS20473 et signons la lettre d'autorisation pour Vultr (louer de l'IPv4). Le bloc est enregistré à votre nom, donc l'e-mail de confirmation de Vultr peut arriver dans votre propre boîte mail, ce que nous recommandons ; si vous choisissez plutôt notre contact, écrivez-nous que le préfixe part chez Vultr et nous le confirmons. Nous ne confirmons que pour les blocs que nous détenons : pour une plage obtenue ailleurs, le contact du registre est celui de son titulaire. Si vous voulez annoncer depuis votre propre ASN sans être LIR, nous parrainons des numéros d'AS (parrainage d'ASN). S'il vous faut moins de 256 adresses, ou si vous préférez ne pas faire tourner de BGP, nous annonçons un bloc et le livrons à votre instance par GRE ou WireGuard, jusqu'à une seule adresse (tunnels GRE et WireGuard). Autres fournisseurs : guides BYOIP.