Comme certains le savent peut-être, j'ai décidé d'obtenir un numéro d'AS afin de pouvoir annoncer mes propres IPv4 et v6. J'ai donc obtenu l'AS n° 210349 en avril 2025.

J'ai décidé de sauter le pas après plusieurs années d'hésitation afin de pouvoir en apprendre plus sur le domaine qui me passionne le plus, à savoir le réseau. Ça m'a permis d'apprendre en profondeur le fonctionnement d'internet que je connaissais déjà avant, mais avec lequel je n'avais pas vraiment pu expérimenter à grande échelle.

J'ai donc décidé de me faire sponsoriser par ServPerso Systems pour l'AS, elle me fournit donc aussi un /44 d'IPv6 à savoir 2a0c:b641:3b0::/44. Je loue en parallèle un /24 d'IPv4 chez Prager IT.

C'est bien, tu as ton numéro d'AS et tes IPs, on fait quoi maintenant ?

Et bien maintenant, il va falloir les annoncer. Pour cela, il y a deux possibilités:

• Payer des transitaires pour qu'ils annoncent mes IPs à tous les autres gens à qui ils sont connectés, donc leurs clients, leurs peers, et leurs autres transitaires s'ils en ont. Ils m'enverront aussi une vue globale de la table de routage globale, qu'on appellera DFZ pour Default Zone. Il est possible de ne prendre que du transit et de ne pas avoir de relations de peering en dehors d'eux. Le désavantage du transit est qu'il est payant, et cher dans la très grande majorité des cas.
• Peer avec d'autres AS pour qu'ils reçoivent mes IPs et m'envoient les leurs afin d'établir un meilleur trajet sans passer par des transitaires. En effet, les relations de peering sont souvent gratuites (en dehors des coûts de cross connect en datacenter si vous disposez de vos propres machines en DC, et que vous optez pour un PNI (Peering sur lien privé)). Par contre, contrairement à un transitaire, ils n'enverront pas une full view de la DFZ, mais seulement leurs préfixes et ceux de leurs clients. Ils ne propageront pas non plus mes annonces vers internet. Il n'est toutefois pas possible de n'utiliser que du peering pour avoir accès à tout internet, sinon, vous seriez transitaire de tier 1.
  • Il est aussi possible d'avoir une présence sur un/des IXPs, qui sont en gros de gros switchs sur lesquels leurs membres viennent se connecter afin de permettre à leurs membres de peer plus facilement entre eux. il est aussi possible de peer avec ce que l'on appelle les "route servers". Qui sont en gros des serveurs qui reçoivent les annonces de tous les membres et les répètent aux autres.

Ok, j'ai des transitaires, et je suis présent sur des IXP pour peer, c'est quoi la suite ?

Personnellement, j'ai choisi deux transitaires:

• ServPerso Systems, petit transitaire belge, plutôt orienté petits AS et homelabbers, chez qui j'ai une petite VM à Düsseldorf.
• iFog Gmbh, chez qui j'ai un serveur dédié à Francfort, à NTT FRA1.

Via ces deux transitaires, j'ai aussi plusieurs possibilités pour le peering, je suis donc présent sur

• BGP.Exchange Dusseldorf, qui est un IXP virtuel.
• FogIXP, qui est l'IXP d'iFog pour leurs clients
• FogIXP FRA, qui est aussi l'IXP d'iFog, mais uniquement pour leurs clients à Francfort, où sont présents notamment Clouflare, Hetzner, HydraCom, Valve, et d'autres.
• LOCIX Dusseldorf, où sont aussi présents pas mal d'autres gens.

J'ai aussi une seule (c'est peu je sais) session de peering direct (à travers le réseau de FogIXP FRA) vers Cloudflare afin de recevoir tous leurs préfixes.

Le protocole qui rend tout ça possible

BGP est le protocole qui fait fonctionner internet aujourd'hui et qui rend possible ce genre de projets. C'est un protocole de routage dynamique, à l'instar d'OSPF, d'IS-IS, de RIPv2, etc. mais il a vocation à interconnecter les routeurs à l'échelle mondiale en ne se basant non pas sur le chemin physique que vont emprunter les paquets (donc tel routeur, puis tel routeur, et ainsi de suite), mais plutôt sur combien de réseaux différents va-t-il traverser. En effet, le travail de BGP est de recevoir des routes, dans ce genre de formats:

N*> 1.0.4.0/24       118.91.186.xxx                         0 34927 1299 4826 2764 38803 i

La dernière partie, juste après le zéro, c'est le chemin, les AS que le paquet va traverser. On peut donc voir par exemple que si je voulais envoyer un paquet vers une IP comprise dans 1.0.4.0/24, son chemin serait:

• AS210349 (moi, caché)
• AS34927 iFog
• AS1299 Arelion aka Telia
• AS4826 Vocus Connect
• AS2764 AAPT
• AS38803 Gtelecom, le destinataire final
  
  Et donc, à moins que vous ne décidiez d'utiliser un mécanisme permettant de faire du traffic engineering comme la localpref, le weight (chez Cisco), ou les communautés BGP de vos transitaires, BGP choisira toujours le trajet avec le moins d'AS entre vous et le destinataire final.

Ça donne quoi comme architecture ça ?

Ce genre de choses:

Pour expliquer un peu, DUS-EDGE-1 et FRA-EDGE-1 sont mes routeurs de bordure, ceux qui s'interconnectent avec les transitaires, les peers, et les IXP.
LGE-CORE-1 et FRA-CORE-1 sont mes routeurs de coeur de réseau, c'est eux qui s'occupent de tout mon trafic intersite, et vers/depuis l'extérieur.
LGE-ACCESS-1 et FRA-ACCESS-1 sont mes routeurs d'accès. C'est avec eux que s'interfacent mes machines virtuelles, serveurs, etc. C'est aussi sur eux que j'applique mes règles de firewall sur le traffic sortant.
Et finalement, FRA-TUN-1 est le routeur sur lequel se terminent les tunnels que je fournis à certains de mes amis qui ont besoin d'IPv4/v6 chez eux.

Les liens entre DUS et FRA, DUS et LGE, FRA et LGE sont réalisés avec GRE sans chiffrement car je considère que dès que l'on communique avec une autre IP publique, même si elle est dans le même réseau, le trajet doit être considéré comme non sécurisé et la communication elle-même doit être chiffrée plutôt que d'essayer de faire rustine en chiffrant le transport.

Et VyOS dans tout ça ?

VyOS est un système d'exploitation réseau (NOS) basé sur Debian et FRR qui a l'avantage de fournir une interface en ligne de commande qui rassemble toutes les fonctions FRR, strongswan (pour IPsec), de configuration d'interfaces, et toutes les autres de façon unifiée. Ça permet donc de ne pas devoir faire du frankenstein pour configurer son routeur et d'avoir une expérience homogène pour toutes les configurations. De plus, étant basé sur Debian, il profite de la stabilité éprouvée du noyau Linux. FRR est aussi un pilier du routage sous Linux et fait preuve d'une stabilité exemplaire, que ce soit pour BGP, MPLS, etc.

Aujourd'hui, VyOS fournit toujours une version gratuite de son NOS qui m'a permis de construire toute cette infrastructure, et qui est, je pense, une excellente brique pour commencer dans le domaine. La CLI a une approche hiérarchique qui permet de comprendre facilement où l'on se trouve, et de trouver facilement ce que l'on recherche en cas de doute. La documentation en ligne est aussi fort fournie.

Pourquoi pas une autre solution telle qu'une Debian barebone avec FRR ou Mikrotik CHR par exemple ? Outre les coûts de licence de Mikrotik qui restent assez abordables, VyOS permet comme je le disais d'éviter de devoir bricoler avec strongswan, ifupdown/netplan, wireguard, FRR, etc. Toute cette complexité est cachée par VyOS et sa CLI. Et quant à Mikrotik, l'architecture de leur mode de configuration est parfois déboussolante et ne ressemble pas forcément à ce qui se fait ailleurs, il est donc parfois compliqué d'adapter ses connaissances existantes à du Mikrotik ou l'inverse.

C'est pourquoi pour ce genre de projet, où la stabilité reste une composante importante, et où j'ai envie de faire du réseau plus que du sysadmin, je préfère 100x VyOS aux autres solutions existantes.

Je détaillerai dans un prochain article une configuration type sur l'un de mes routeurs de bordure, de coeur de réseau, et d'accès sur VyOS.