Avoir son ASN personnel pour annoncer ses IPs sur Internet
Je vais bientôt souffler la première bougie de mon ASN : 209238 🎉. Je me suis dit qu’il n’y aurait pas de meilleur cadeau pour lui que d’en faire un article de blog pour expliquer mon parcours et comment je l’utilise.
On va commencer par le début et expliquer déjà ce qu’est un ASN.
Qu’est-ce qu’un ASN ?
Un ASN (Autonomous System Number) est un numéro unique attribué à une entité qui gère un réseau autonome sur Internet. Un réseau autonome est un ensemble de réseaux IP qui sont sous le contrôle d’une même organisation. Les ASN sont utilisés pour identifier ces réseaux autonomes et pour permettre aux routeurs de communiquer entre eux en utilisant le protocole BGP (Border Gateway Protocol).
Donc en gros, c’est juste pour que 2 groupes de réseaux puissent communiquer entre eux, qu’est-ce qui change comparé à des routes classiques ?
Pour ça, faut qu’on creuse un peu ce qu’est le BGP, et même avant ça : qu’est-ce qu’un protocole de routage dynamique (et je peux enfin utiliser mes cours de DUT Réseaux et Télécoms ❤️).
Imaginez par exemple avoir une entreprise qui gère plusieurs batiments (A, B, C, D), si le batiment A veut joindre le batiment D, il doit passer par les liens physiques existant entre les batiments et donc : A -> B -> D. Si on remplace en utilisant des plages réseaux IP, on peut faire la même chose.
- A : 10.1.0.0/16
- B : 10.2.0.0/16
- C : 10.3.0.0/16
- D : 10.4.0.0/16
On configure le routeur A pour qu’il demande à joindre le réseau de D via B, et le routeur B pour qu’il demande à joindre le réseau.

Il faudra configurer les routeurs pour qu’ils sachent comment joindre les réseaux et par quels intermédiaires. Voici les commandes à exécuter pour configurer les routes sur les routeurs A et B :
Sur le routeur A:
ip route add 10.4.0.0 via 1.1.1.2
Sur le routeur B:
ip route add 10.4.0.0 via 2.2.2.2
Maintenant, si jamais j’ajoute un nouveau lien entre A et D, les routes sont absolument les mêmes et je ne profite pas de cette nouvelle optimisation (et ça devient réellement problématique si le lien entre A et B tombe en panne, car A ne pourra plus joindre D).
C’est là que les protocoles de routage dynamique entrent en jeu, ils permettent aux routeurs de s’échanger des informations sur les routes disponibles et de choisir la meilleure route pour joindre un réseau. L’EIGRP (Enhanced Interior Gateway Routing Protocol) est un exemple de protocole de routage dynamique dont la route est calculée en fonction de la bande passante, du délai, de la charge et de la fiabilité des liens. Le protocole RIP (Routing Information Protocol) est un autre exemple de protocole de routage dynamique qui le nombre de sauts (hop count) pour choisir la meilleure route.

Le BGP est donc un protocole de routage dynamique qui est utilisé pour les (très) grands réseaux (bien que rien ne l’empêche d’être utilisé pour des petits réseaux). Son chemin optimisé est calculé en fonction du nombre d’AS qu’il doit traverser pour joindre l’AS destination. Dans notre schéma, on pourrait considérer que chaque batiment est un AS, et que les liens entre les batiments sont des liens BGP.
Chaque AS est identifié par un numéro unique (l’ASN) comme par exemple : 65001.
Information
Comme pour les adresses IP, il existe des ASN publics et privés. Les ASN publics sont attribués par des organismes de régulation (comme l’ARIN, le RIPE, etc.) et sont utilisés pour les réseaux qui sont connectés à Internet. Les ASN privés sont utilisés pour les réseaux internes et ne sont pas routables sur Internet.
Il existe 2 types d’ASN : les ASN 32 bits (aussi appelés ASN 4 octets) et les ASN 16 bits (aussi appelés ASN 2 octets). Les ASN 16 bits sont limités à 65535, tandis que les ASN 32 bits peuvent aller jusqu’à 4294967295 (parrallèle possible entre l’IPv4 et l’IPv6).
Voici les plages d’ASN privés :
- 16-bit: 64512 – 65534
- 32-bit: 4200000000 – 4294967294
Maintenant, nouvelle information : c’est le BGP qui est utilisé pour créer des adresses IPs sur Internet. En effet, les ASN sont utilisés pour annoncer des routes IP : un ASN annonce qu’il gère un certain préfixe IP, et les autres ASN savent que pour joindre ce préfixe, il faut passer par cet ASN. C’est grâce à ça que les routeurs sur Internet savent comment joindre les différentes adresses IP dans le monde entier.
Si vous voulez faire du BGP chez vous, vous pouvez acheter du matériel de routeur (comme des Mikrotik, des Ubiquiti, etc.) et configurer le BGP vous-même. On nomme le BGP privé : l’iBGP (internal BGP), et le BGP public : l’eBGP (external BGP). L’iBGP est utilisé pour les réseaux internes, tandis que l’eBGP est utilisé pour les réseaux qui sont connectés à Internet.
C’est justement cette deuxième utilisation qui m’intéresse, comment on crée un ASN pour gérer nos propres adresses IP ?
La quête du Graal (et comment ne pas se ruiner)
Il faut déjà savoir que les ASN sont attribués par des organismes de régulation (comme l’ARIN, le RIPE… il en existe plusieurs dans le monde, chacun gérant une région géographique spécifique). En europe, il s’agit du RIPE (Regional Internet Registry for Europe). Pour obtenir un ASN, il faut faire une demande auprès de l’organisme de régulation, en fournissant des informations sur votre réseau et sur la manière dont vous allez utiliser l’ASN. Il y a généralement des frais associés à l’obtention d’un ASN, et il faut également renouveler l’ASN périodiquement (on parle de 1000e l’enregistrement initial, puis 100e par an pour le renouvellement).
C’est un budget 😅 mais il existe une alternative : le sponsoring !
Alors non, vous n’allez malheureusement pas être payé pour obtenir un ASN. C’est une pratique dans laquelle une organisation qui possède déjà un AS (et des prefixes IP) accepte de déléguer une partie de son espace d’adressage et de son AS à un acteur tiers. En d’autres termes, contre rémunération, vous obtenez un ASN et des adresses IP sans avoir à faire la demande auprès de l’organisme de régulation. C’est une pratique courante dans le monde de l’hébergement, où les hébergeurs proposent souvent des services de sponsoring pour les clients qui souhaitent obtenir un ASN et des adresses IP.
Il existe deux types de ressources :
- PA (Provider Assigned) : La ressource appartient au LIR qui vous la prête moyennant cotisation. Si le LIR ferme, vous perdez tout.
- PI (Provider Independent) : La ressource vous appartient et peut être transférée d’un LIR à un autre. Plus cher que le PA, mais plus flexible.
L’ASN est toujours une ressource PI, mais les adresses IP peuvent appartenir aux deux catégories.
Je suis passé par le sponsoring de ServPerso (qui semblait plus sérieux que plein d’autres), et j’ai obtenu mon ASN ainsi que mon préfixe IPv6 : 2a0c:b641:460::/44.
Comme vous avec pu le voir, j’ai dû faire un choix pragmatique. Les adresses IPv4 sont devenues de l’or en barre (pénurie oblige). Je suis donc parti sur un préfixe IPv6 uniquement : 2a0c:b641:460::/44 (soit 2^84 adresses IPv6, autant dire que je ne risque pas de manquer d’adresses 😂). J’aurais adoré avoir un préfixe IPv4 aussi, mais les prix sont devenus tellement prohibitifs que ce n’était pas envisageable pour moi (comptez une bonne centaine d’euros par /24 par mois).

Et après ?
Maintenant que j’ai mon ASN et mes IPs, il faut bien que je les utilise ! Comment ça se passe de ce côté-là ? Beh déjà, il va vous falloir un provider qui accepte de relayer l’annonce de vos routes. En effet, si vous êtes chez un FAI grand public, il y a de fortes chances que votre FAI ne vous laisse pas le faire. Il faudra se tourner vers des datacenters (housing) ou des hébergeurs le permettent. Si vous cherchez ces services, je vous recommande de faire un tour sur bgp.services qui énumère les différents providers qui proposent des services de sponsoring, housing, ou de VMs avec BGP.
Donc, adieu mes rêves de faire du BGP chez moi, il faudra forcément passer par un intermédiaire… Il existe aussi une troisième option : les tunnels GRE (generic routing encapsulation), qui permettent de faire du BGP sans avoir à être physiquement connecté à un provider. Cependant, cette option est plus complexe à mettre en place et peut être moins performante que les autres options. L’idée est de mapper une IP publique (fournie par le provider) à votre machine. Cependant, il n’y a pas d’authentification, le provider vous reconnait juste à votre adresse IP publique (ainsi, si elle est dynamique, ou si vous configurez plusieurs tunnels, ça peut poser problème). Je ne suis pas très fan de cette option mais elle peut avoir ses uses cases.
J’ai donc loué une VM chez Server9 (leurs prix étant très compétitifs). Une fois la VM en place, Patrik du support m’envoie les informations nécessaires pour annoncer mes routes : l’ASN de l’hébergeur (35100) et l’adresse IP du neighbor (2a01:7900:100::100).

Je sais à qui envoyer mes routes… mais lui n’a pas encore le droit de les annoncer en mon nom. Il faut d’abord que j’autorise cet ASN à relayer mes IPs. Pour ça, je dois me connecter à mon compte RIPE (créé lorsque j’ai obtenu mon ASN) et ajouter un objet de type export en ciblant l’ASN 35100.
export: to AS35100 announce AS209238
Ainsi, j’autorise l’ASN 35100 à annoncer les routes de mon ASN 209238. Une fois que c’est fait, je peux commencer à configurer le BGP pour annoncer mes routes.
Comment annoncer ses routes ?
Il y a deux grand logiciels pour faire du BGP : BIRD2 et FRR. J’ai opté sur BIRD2 qui semblait beaucoup plus noob-friendly que FRR (spoiler : je serai confronté plus bas).
log syslog all;
router id 171.25.158.67;
protocol device {}
protocol direct { ipv6; }
protocol static {
ipv6;
route 2a0c:b641:460::/44 blackhole;
route 2a01:7900:100::100/128 via "ens18";
}
protocol bgp upstream {
local 2a01:7900:162:11::1 as 209238;
neighbor 2a01:7900:100::100 as 35100;
multihop;
strict bind yes;
ipv6 {
import all;
gateway recursive;
export filter {
if net = 2a0c:b641:460::/44 then accept;
reject;
};
};
}
Dans cette configuration, on définit d’abord les protocoles de base (device et direct), puis on ajoute une route statique pour notre préfixe IPv6 : 2a0c:b641:460::/44 (en blackhole, car on ne veut pas que cette route soit utilisée pour joindre notre réseau, mais juste pour annoncer qu’on gère ce préfixe). On ajoute aussi une route statique pour le neighbor : 2a01:7900:100::100/128 (en indiquant l’interface ens18 qui est l’interface qui va nous permettre de joindre le neighbor).
Il ne me reste plus qu’à configurer une adresse IP dans ma range pour que BIRD transmette les routes à mon neighbor, et lui même à Internet.
Comme je n’ai qu’une machine unique, je positionne cette adresse IP dans la loopback (car je n’ai pas besoin d’avoir une adresse IP physique pour faire du BGP, tant que j’ai une adresse IP qui est routable et qui peut être utilisée pour établir la session BGP). Je choisis l’adresse 2a01:7900:162:11::1/128 (qui est dans ma range) et je l’ajoute à la loopback.
ip -6 addr add 2a01:7900:162:11::1/128 dev lo
sysctl -w net.ipv6.conf.all.forwarding=1
Et ….
➜ blog git:(bgp) ✗ ping6 -c3 2a01:7900:162:11::1
PING6(56=40+8+8 bytes) 2606:4700:110:8fe9:c02f:9e0e:dc05:c98c --> 2a01:7900:162:11::1
--- 2a01:7900:162:11::1 ping6 statistics ---
3 packets transmitted, 0 packets received, 100.0% packet loss
Beh ça marche pas 💀. J’ai honnêtement pris énormément de temps à déboguer cette configuration, avant que je ne découvre la commande birdc show protocols all upstream indiquant que le neighbor était dans un état “Idle” (c’est à dire que le BGP ne parvient pas à établir une session avec le neighbor). Il suffisait alors de demander à Patrik de Server9 qui m’annonce qu’il a mal configuré son côté.

Shit happens, mais au moins j’ai appris à utiliser BIRD2 pour faire du BGP :).
Après cette phase de debug “intensive” validant que mon neighbor est bien configuré, je peux maintenant annoncer mes routes !
Annoncer ses routes depuis Kubernetes ?
Aujourd’hui, c’est assez rare que je déploie des VMs individuelles, j’ai plutôt tendance à faire du Kubernetes. Je trouve ça nettement plus simple et maintenable au long terme (même si je n’ai qu’une seule machine) en sachant que la majorité de mes applications sont des images OCI mises à jour automatiquement via du Renovate.
Comment ça se passe pour faire du BGP dans Kubernetes ? Beh, il existe plusieurs solutions pour faire du BGP dans Kubernetes comme MetalLB, ou les CNIs Calico et Cilium. J’ai opté pour MetalLB dans un premier temps car plus simple à mettre en place sur un cluster (et on a réalisé ce setup en stream sur Twitch, donc il fallait que ce soit rapide à configurer).
Déjà, rappelons les informations dont je dispose :
- Mon ASN :
209238 - Mon préfixe IPv6 :
2a0c:b641:460::/44 - Mon Neighbor (celui qui va relayer mes annonces) :
2a01:7900:100::100(AS35100) - Mon Neighbor n’est pas dans mon réseau, je dois passer par mon routeur pour le joindre (important, car nativement les softwares pour annoncer des routes fonctionnent en mode “single-homed”, c’est à dire que le neighbor est dans le même réseau que l’interface qui fait du BGP).
Avant même de setup notre configuration MetalLB, il faut quand rappeler que le cluster doit être en IPv6 natif. Sans ça, impossible d’annoncer des routes IPv6.

J’aurais adoré mettre ça sur du Talos, mais mon hébergeur (Server9) ne supporte pas le fait de passer par des images ISO customisées. Du coup, j’ai opté pour un setup avec k3s sur Fedora.
J’ai opté pour la configuration suivante pour k3s avec des CIDRs IPv6 (et pas d’IPv4 ! ) :
# /etc/rancher/k3s/config.yaml
disable: traefik,servicelb
cluster-cidr: 2fd42:42:42::/56
service-cidr: 2fd42:43:1::/112
Merci à Batleforc qui m’a aidé à configurer le k3s en plein live
Information
Note : j’ai désactivé le service load-balancer de k3s, car il est incompatible avec MetalLB. Klipper (le loadbalancer en question) utilise une plage d’adresses IP contenant uniquement les adresses IPv4 des nodes, ce qui pose problème pour MetalLB qui a besoin d’une plage d’adresses IP dédiée pour fonctionner correctement. En désactivant Klipper, on évite les conflits d’adresses IP et on permet à MetalLB de gérer efficacement les adresses IP pour les services de type LoadBalancer.

Une fois le cluster prêt, on peut installer MetalLB :
kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/v0.15.3/config/manifests/metallb-frr.yaml
L’installation de MetalLB va créer les CRDs nécessaires pour configurer la partie BGP : IPAdressPool, BGPAdvertisement, et BGPPeer. On va les créer un par un.
Commençons par l’IPAddressPool, qui va définir le neighbor :
apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
generation: 1
name: asn-209238-ipv6-pool
namespace: metallb-system
spec:
addresses:
- 2a0c:b641:460::/44
autoAssign: true
avoidBuggyIPs: false
Puis le BGPAdvertisement, qui va définir comment on va annoncer les routes :
apiVersion: metallb.io/v1beta1
kind: BGPAdvertisement
metadata:
name: local
namespace: metallb-system
spec:
aggregationLengthV6: 44
ipAddressPools:
- asn-209238-ipv6-pool
J’en profite aussi pour préciser que le champ aggregationLengthV6 est important, car il va définir la taille minimale des préfixes que l’on va annoncer. Durant un premier test, j’avais mis un 128 (puisque je souhaite annoncer les routes une par une), mais mon neighbor a filtré toutes mes annonces, car n’accepte qu’une taille minimale de /44.
Et on termine par le BGPPeer, qui va définir le neighbor BGP :
apiVersion: metallb.io/v1beta2
kind: BGPPeer
metadata:
name: peer-to-35100
namespace: metallb-system
spec:
ebgpMultiHop: true
myASN: 209238
peerASN: 35100
peerAddress: 2a01:7900:100::100
peerPort: 179
Une fois tout ça appliqué, on peut créer un service de type LoadBalancer :
kubectl run nginx --image=nginx --port=80
kubectl expose pod nginx --port 80 --type=LoadBalancer
Et après quelques secondes, on peut vérifier que l’adresse IP a bien été assignée :
kubectl get svc nginx
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
nginx LoadBalancer 2a01:7900:162:11:2:1cae:b99c:82b4 2a0c:b641:460::1 80:31729/TCP 84s
Depuis le node on devrait pouvoir accéder au service (si non, il faut commencer à debugguer)… et même depuis l’extérieur du cluster, grâce à notre annonce BGP :
curl -6 -I 'http://[2a0c:b641:460::1]/'
HTTP/1.1 200 OK
Server: nginx/1.29.4
Date: Wed, 04 Feb 2026 11:49:05 GMT
Content-Type: text/html
Content-Length: 615
Last-Modified: Tue, 09 Dec 2025 18:28:10 GMT
Connection: keep-alive
ETag: "69386a3a-267"
Accept-Ranges: bytes
Et voilà, mon cluster Kubernetes annonce désormais des routes IPv6 directement depuis le cluster grâce à MetalLB et BGP 🎉.
Information
Normalement, il aurait aussi pu être possible de faire du BGP dans Kubernetes en utilisant les CNIs Calico ou Cilium, qui proposent tous les deux des fonctionnalités de routage natives. J’ai essayé pour Cilium (Désolé Alexis et Joseph, j’ai passé quelques heures à essayer de faire marcher ça mais ça n’a pas été un succès).
Conclusion
Et voilà ! Mon cluster avec MetalLB annonce maintenant mes routes BGP. Je peux créer un service de type LoadBalancer qui obtiendra automatiquement une IP de mon pool IPv6. J’ai pas forcément d’application concrète pour le moment, mais c’est déjà cool d’avoir réussi à réaliser ce setup et d’avoir une quantité presque illimitée d’adresses en LoadBalancer.
