Ce tutoriel explique comment configurer FRRouting (FRR) pour annoncer vos propres préfixes IPv4 et IPv6 via BGP depuis un VPS Linux. Chaque commande est testée sur Debian 12 et Ubuntu 24.04 avec FRR 10.5.

À la fin, vous aurez une session eBGP fonctionnelle avec votre fournisseur upstream, une origination de préfixes dual-stack via des interfaces dummy persistantes, un filtrage de routes entrant et sortant, une sécurisation de session GTSM et des règles de firewall nftables verrouillant le port TCP 179.

Si vous hésitez entre FRR et BIRD2, les deux sont de bons choix. FRR utilise un CLI de type Cisco (vtysh) qui sera familier si vous avez travaillé avec IOS ou JunOS. BIRD2 utilise un fichier de configuration déclaratif. Ce guide couvre FRR. Pour BIRD2, voir Configuration BGP avec BIRD2 sur un VPS Linux.

Pour en savoir plus sur l'utilisation de votre propre espace IP sur un VPS, voir BGP et Bring Your Own IP sur un VPS : le guide complet.

Prérequis

Avant de commencer, vous avez besoin de :

Un ASN (Autonomous System Number) public. Si vous n'en avez pas encore, voir Comment obtenir un ASN auprès du RIPE NCC.
Au moins un préfixe IPv4 /24 ou IPv6 /48 assigné à votre ASN.
Des objets ROA (Route Origin Authorization) créés dans le tableau de bord RPKI de votre RIR. Voir RPKI ROA pour BGP : créer des ROAs, valider les routes dans BIRD2 et FRR.
Un fournisseur upstream proposant une session BGP (transit IP ou peering). Vous aurez besoin de : l'ASN du fournisseur, les adresses IPv4 et IPv6 du peer, et un mot de passe MD5 convenu le cas échéant.
Un VPS Linux sous Debian 12 (Bookworm) ou Ubuntu 24.04 (Noble). Accès root ou sudo.

Tout au long de ce guide, remplacez ces marqueurs par vos valeurs réelles :

Marqueur	Signification	Exemple
`YOUR_ASN`	Votre numéro d'AS	`212345`
`PEER_ASN`	Numéro d'AS du fournisseur upstream	`6939`
`PEER_IPV4`	IPv4 du peer BGP du fournisseur	`198.51.100.1`
`PEER_IPV6`	IPv6 du peer BGP du fournisseur	`2001:db8:1::1`
`YOUR_IPV4`	Votre côté du peering BGP (IPv4)	`198.51.100.2`
`YOUR_IPV6`	Votre côté du peering BGP (IPv6)	`2001:db8:1::2`
`YOUR_PREFIX_V4`	Votre préfixe IPv4	`203.0.113.0/24`
`YOUR_PREFIX_V6`	Votre préfixe IPv6	`2001:db8:abc::/48`
`MD5_PASSWORD`	Mot de passe TCP MD5 convenu	(fourni par votre provider)

Comment installer FRRouting sur Debian 12 et Ubuntu 24.04 ?

Installez FRR depuis le dépôt apt officiel pour obtenir la dernière version stable (10.5.x en mars 2026). Les paquets des distributions Debian et Ubuntu ont souvent plusieurs versions majeures de retard. Le dépôt officiel suit la branche stable actuelle et supporte Bookworm et Noble.

Ajoutez la clé de signature GPG :

curl -s https://deb.frrouting.org/frr/keys.gpg | sudo tee /usr/share/keyrings/frrouting.gpg > /dev/null

Ajoutez le dépôt. Utilisez frr-stable pour suivre la dernière branche stable :

FRRVER="frr-stable"
echo deb '[signed-by=/usr/share/keyrings/frrouting.gpg]' https://deb.frrouting.org/frr \
     $(lsb_release -s -c) $FRRVER | sudo tee /etc/apt/sources.list.d/frr.list

Installez FRR et les outils Python (nécessaires pour frr-reload.py) :

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

Contrôlez la version installée :

sudo vtysh -c "show version" | head -1

Sortie attendue :

FRRouting 10.5.3 (<hostname>) on Linux(6.8.0-xxx-generic).

FRR s'installe en tant que service systemd. Activez-le pour qu'il persiste après un redémarrage et démarrez-le immédiatement :

sudo systemctl enable --now frr

Vérifiez qu'il tourne :

systemctl status frr

Vous devriez voir active (running) dans la sortie. FRR exécute plusieurs daemons (zebra, bgpd, etc.) gérés par un processus parent unique.

Comment activer le daemon BGP dans FRR ?

FRR est livré avec tous les daemons de protocole désactivés sauf zebra. Vous devez activer explicitement bgpd dans le fichier daemons avant que FRR ne lance un processus BGP. Le fichier daemons se trouve dans /etc/frr/daemons.

Éditez le fichier daemons :

sudo nano /etc/frr/daemons

Trouvez la ligne bgpd et mettez-la à yes :

bgpd=yes

Tous les autres daemons (ospfd, isisd, etc.) peuvent rester à no sauf si vous en avez besoin. Zebra est toujours activé et gère la table de routage du noyau.

Voici le rôle de chaque daemon :

Daemon	Rôle	Défaut
`zebra`	Gestion des routes noyau, suivi des interfaces	toujours actif
`bgpd`	Protocole BGP	`no`
`ospfd`	OSPFv2	`no`
`ospf6d`	OSPFv3 (IPv6)	`no`
`ripd`	RIP	`no`
`isisd`	IS-IS	`no`
`staticd`	Routes statiques via vtysh	`no`

Redémarrez FRR pour appliquer le changement :

sudo systemctl restart frr

Assurez-vous que bgpd tourne :

sudo vtysh -c "show bgp summary"

Vous devriez voir % BGP instance not found. C'est normal : bgpd tourne, mais aucun router bgp n'a encore été configuré. Nous allons le faire maintenant.

Les bases de vtysh

vtysh est le shell intégré de FRR. Il fournit un CLI de type Cisco pour configurer tous les daemons FRR depuis une seule interface. Quelques notions avant de commencer la configuration.

Entrez dans vtysh :

sudo vtysh

Vous êtes maintenant dans le CLI de FRR. Le prompt affiche le hostname. Les modes que vous utiliserez :

Mode	Entrer avec	Prompt	Fonction
Exec	(par défaut)	`#`	Commandes show, vérification
Config	`configure terminal`	`(config)#`	Configuration globale
Router BGP	`router bgp ASN`	`(config-router)#`	Configuration BGP
Address-family	`address-family ipv4 unicast`	`(config-router-af)#`	Configuration par AFI/SAFI

Pour sauvegarder la configuration courante sur le disque :

write memory

Cela écrit dans /etc/frr/frr.conf. FRR utilise un modèle de configuration intégré par défaut : toutes les configurations des daemons sont dans un seul fichier.

Quittez vtysh avec exit ou end (retour au mode exec depuis n'importe quel sous-mode).

Comment configurer une session BGP avec mon fournisseur upstream ?

Entrez dans vtysh et passez en mode configure terminal pour mettre en place la configuration BGP de base. Cela crée le processus router, définit le router ID, désactive l'unicast IPv4 automatique (pour contrôler exactement quelles familles d'adresses sont actives par voisin), et définit le peer upstream.

sudo vtysh

configure terminal

router bgp YOUR_ASN
 bgp router-id YOUR_IPV4
 no bgp default ipv4-unicast

 neighbor PEER_IPV4 remote-as PEER_ASN
 neighbor PEER_IPV4 description Upstream-v4
 neighbor PEER_IPV4 password MD5_PASSWORD
 neighbor PEER_IPV4 ttl-security hops 1
 neighbor PEER_IPV4 soft-reconfiguration inbound

 neighbor PEER_IPV6 remote-as PEER_ASN
 neighbor PEER_IPV6 description Upstream-v6
 neighbor PEER_IPV6 password MD5_PASSWORD
 neighbor PEER_IPV6 ttl-security hops 1
 neighbor PEER_IPV6 soft-reconfiguration inbound

Ce que fait chaque directive :

bgp router-id : Un identifiant sur 32 bits, généralement votre adresse IPv4 principale. Doit être unique sur le peering.
no bgp default ipv4-unicast : Empêche FRR d'activer automatiquement l'unicast IPv4 pour chaque voisin. Vous activez les familles d'adresses explicitement. C'est la pratique standard pour les configurations dual-stack.
ttl-security hops 1 : Active le GTSM (RFC 5082). Exige que les paquets arrivent avec un TTL de 254 (un seul saut). Rejette les paquets BGP usurpés provenant de sources distantes. Mutuellement exclusif avec ebgp-multihop.
password : Configure l'authentification TCP MD5 (RFC 2385). Les deux côtés doivent utiliser la même chaîne. Tous les fournisseurs ne l'exigent pas. Omettez-la si votre fournisseur ne le demande pas.
soft-reconfiguration inbound : Stocke les routes reçues en mémoire pour appliquer des changements de politique sans réinitialiser la session. Consomme plus de RAM mais évite les coupures de session lors des mises à jour de filtres.

Ne quittez pas le mode config. Nous allons ajouter les familles d'adresses et les filtres ensuite.

Comment annoncer mes propres préfixes IPv4 et IPv6 ?

L'origination de préfixes dans FRR nécessite deux choses : une instruction network dans la configuration BGP, et le préfixe présent dans la table de routage du noyau. La méthode la plus simple pour injecter le préfixe dans le noyau est via une interface dummy. Nous allons d'abord configurer les interfaces dummy, puis les familles d'adresses BGP.

Comment créer des interfaces dummy persistantes pour l'origination de préfixes ?

Une interface dummy est une interface de type loopback qui porte une adresse IP sans être liée à du matériel physique. Le daemon zebra de FRR récupère les routes du noyau, donc si votre préfixe est assigné à une interface dummy, zebra l'installe et bgpd peut l'annoncer.

Créez les interfaces dummy avec systemd-networkd pour qu'elles persistent après un redémarrage.

Créez le fichier netdev :

sudo tee /etc/systemd/network/10-dummy-bgp.netdev > /dev/null << 'EOF'
[NetDev]
Name=dummy-bgp
Kind=dummy
EOF

Créez le fichier network avec vos préfixes :

sudo tee /etc/systemd/network/10-dummy-bgp.network > /dev/null << 'EOF'
[Match]
Name=dummy-bgp

[Address]
Address=YOUR_PREFIX_V4

[Address]
Address=YOUR_PREFIX_V6
EOF

Pour l'adresse IPv4, utilisez la première IP utilisable de votre préfixe (ex. 203.0.113.1/24). Pour IPv6, utilisez n'importe quelle adresse dans votre préfixe (ex. 2001:db8:abc::1/48).

Activez systemd-networkd s'il n'est pas déjà actif, et redémarrez-le :

sudo systemctl enable --now systemd-networkd
sudo systemctl restart systemd-networkd

Confirmez que l'interface dummy est active :

ip addr show dummy-bgp

Vous devriez voir vos adresses IPv4 et IPv6 assignées à l'interface.

Contrôlez que les routes sont dans le noyau :

ip route show dev dummy-bgp
ip -6 route show dev dummy-bgp

Configuration des familles d'adresses

De retour en mode config vtysh (ou réentrez avec sudo vtysh puis configure terminal puis router bgp YOUR_ASN) :

 address-family ipv4 unicast
  network YOUR_PREFIX_V4
  neighbor PEER_IPV4 activate
  neighbor PEER_IPV4 route-map EXPORT-V4 out
  neighbor PEER_IPV4 route-map IMPORT-V4 in
  neighbor PEER_IPV4 prefix-list BOGONS-V4 in
  neighbor PEER_IPV4 maximum-prefix 500000 80
 exit-address-family

 address-family ipv6 unicast
  network YOUR_PREFIX_V6
  neighbor PEER_IPV6 activate
  neighbor PEER_IPV6 route-map EXPORT-V6 out
  neighbor PEER_IPV6 route-map IMPORT-V6 in
  neighbor PEER_IPV6 prefix-list BOGONS-V6 in
  neighbor PEER_IPV6 maximum-prefix 200000 80
 exit-address-family

Détails :

activate active le voisin dans cette famille d'adresses. Nécessaire car nous avons désactivé bgp default ipv4-unicast.
network indique à bgpd d'originer ce préfixe. Le préfixe doit exister dans la table de routage du noyau (zebra le récupère depuis l'interface dummy).
maximum-prefix 500000 80 coupe la session si le peer envoie plus de 500 000 préfixes IPv4. Le 80 génère un avertissement à 80 % (400 000). Ajustez selon que vous recevez une table complète ou uniquement une route par défaut. Pour une session route-par-défaut uniquement, fixez cette valeur à 10.
Les références route-map et prefix-list pointent vers les filtres que nous définissons ensuite.

Comment filtrer les routes BGP avec des prefix-lists et des route-maps ?

Le filtrage des routes n'est pas optionnel. Sans filtres sortants, une erreur de configuration pourrait fuiter des préfixes que vous ne possédez pas. Sans filtres entrants, vous acceptez des routes bogon et risquez de blackholer du trafic. Ceci suit la RFC 7454 (BGP Operations and Security).

Pour un examen approfondi des stratégies de filtrage, voir BGP Route Filtering : Prefix Lists, Filtres AS-Path, Rejet des Bogons et GTSM.

Prefix-lists sortantes

N'annoncez que les préfixes que vous possédez. Rien d'autre.

ip prefix-list OUR-PREFIXES-V4 seq 10 permit YOUR_PREFIX_V4
ip prefix-list OUR-PREFIXES-V4 seq 999 deny any

ipv6 prefix-list OUR-PREFIXES-V6 seq 10 permit YOUR_PREFIX_V6
ipv6 prefix-list OUR-PREFIXES-V6 seq 999 deny any

Si vous annoncez plusieurs préfixes, ajoutez d'autres lignes permit avec des numéros de séquence croissants.

Prefix-lists bogon entrantes

Rejetez les préfixes qui ne devraient jamais apparaître sur l'internet public. Cette liste suit le NLNOG BGP Filter Guide :

ip prefix-list BOGONS-V4 seq 10 deny 0.0.0.0/8 le 32
ip prefix-list BOGONS-V4 seq 20 deny 10.0.0.0/8 le 32
ip prefix-list BOGONS-V4 seq 30 deny 100.64.0.0/10 le 32
ip prefix-list BOGONS-V4 seq 40 deny 127.0.0.0/8 le 32
ip prefix-list BOGONS-V4 seq 50 deny 169.254.0.0/16 le 32
ip prefix-list BOGONS-V4 seq 60 deny 172.16.0.0/12 le 32
ip prefix-list BOGONS-V4 seq 70 deny 192.0.2.0/24 le 32
ip prefix-list BOGONS-V4 seq 80 deny 192.88.99.0/24 le 32
ip prefix-list BOGONS-V4 seq 90 deny 192.168.0.0/16 le 32
ip prefix-list BOGONS-V4 seq 100 deny 198.18.0.0/15 le 32
ip prefix-list BOGONS-V4 seq 110 deny 198.51.100.0/24 le 32
ip prefix-list BOGONS-V4 seq 120 deny 203.0.113.0/24 le 32
ip prefix-list BOGONS-V4 seq 130 deny 224.0.0.0/4 le 32
ip prefix-list BOGONS-V4 seq 140 deny 240.0.0.0/4 le 32
ip prefix-list BOGONS-V4 seq 999 permit 0.0.0.0/0 le 24

ipv6 prefix-list BOGONS-V6 seq 10 deny ::/8 le 128
ipv6 prefix-list BOGONS-V6 seq 20 deny 100::/64 le 128
ipv6 prefix-list BOGONS-V6 seq 30 deny 2001:2::/48 le 128
ipv6 prefix-list BOGONS-V6 seq 40 deny 2001:10::/28 le 128
ipv6 prefix-list BOGONS-V6 seq 50 deny 2001:db8::/32 le 128
ipv6 prefix-list BOGONS-V6 seq 60 deny 3fff::/20 le 128
ipv6 prefix-list BOGONS-V6 seq 70 deny 2002::/16 le 128
ipv6 prefix-list BOGONS-V6 seq 80 deny 3ffe::/16 le 128
ipv6 prefix-list BOGONS-V6 seq 90 deny 5f00::/16 le 128
ipv6 prefix-list BOGONS-V6 seq 100 deny fc00::/7 le 128
ipv6 prefix-list BOGONS-V6 seq 110 deny fe80::/10 le 128
ipv6 prefix-list BOGONS-V6 seq 120 deny fec0::/10 le 128
ipv6 prefix-list BOGONS-V6 seq 130 deny ff00::/8 le 128
ipv6 prefix-list BOGONS-V6 seq 999 permit ::/0 le 48

La dernière ligne permit de chaque liste accepte tout ce qui n'est pas explicitement refusé. Le le 24 (IPv4) et le 48 (IPv6) rejettent les préfixes trop spécifiques : personne ne devrait annoncer un /25 ou plus long en IPv4, ni un /49 ou plus long en IPv6.

Route-maps

Les route-maps combinent les prefix-lists et offrent un point d'ajout de politiques supplémentaires (local-pref, communities, AS-path prepending).

route-map EXPORT-V4 permit 10
 match ip address prefix-list OUR-PREFIXES-V4

route-map EXPORT-V6 permit 10
 match ipv6 address prefix-list OUR-PREFIXES-V6

route-map IMPORT-V4 permit 10
 match ip address prefix-list BOGONS-V4

route-map IMPORT-V6 permit 10
 match ipv6 address prefix-list BOGONS-V6

Les route-maps d'export n'autorisent que vos propres préfixes. Tout le reste est implicitement refusé (FRR refuse tout ce qui n'est pas explicitement matché par une route-map). Les route-maps d'import font passer le trafic par la prefix-list bogon, qui refuse les plages bogon et autorise tout le reste.

Sauvegardez la configuration :

write memory

Assurez-vous que la configuration a été écrite :

ls -la /etc/frr/frr.conf

Le fichier devrait afficher un horodatage de modification récent avec le propriétaire frr:frr et les permissions 640.

Comment sécuriser la session BGP et protéger le port TCP 179 ?

BGP tourne sur le port TCP 179. N'importe quel hôte sur internet peut tenter de s'y connecter. Au-delà du GTSM et de l'authentification MD5 déjà configurés, vous avez besoin de règles de firewall pour restreindre le port TCP 179 aux adresses de vos peers.

Règles de firewall nftables

Installez nftables s'il n'est pas déjà présent. Sur les installations minimales d'Ubuntu 24.04, il n'est pas inclus par défaut :

sudo apt install -y nftables

Créez le répertoire /etc/nftables.d/ pour les fichiers de configuration modulaires et ajoutez une directive include dans la configuration principale nftables pour que les règles personnalisées persistent après un redémarrage :

sudo mkdir -p /etc/nftables.d
echo 'include "/etc/nftables.d/*.conf"' | sudo tee -a /etc/nftables.conf

Créez un fichier de configuration nftables dédié au BGP :

sudo tee /etc/nftables.d/bgp.conf > /dev/null << 'EOF'
table inet bgp-filter {
    set bgp_peers_v4 {
        type ipv4_addr
        elements = { PEER_IPV4 }
    }

    set bgp_peers_v6 {
        type ipv6_addr
        elements = { PEER_IPV6 }
    }

    chain input {
        type filter hook input priority 0; policy accept;

        # Allow BGP from known peers only
        tcp dport 179 ip saddr @bgp_peers_v4 accept
        tcp dport 179 ip6 saddr @bgp_peers_v6 accept

        # Allow BGP return traffic (our side initiates)
        tcp sport 179 ip saddr @bgp_peers_v4 accept
        tcp sport 179 ip6 saddr @bgp_peers_v6 accept

        # Drop all other BGP attempts
        tcp dport 179 drop
        tcp sport 179 drop
    }
}
EOF

Si vous avez déjà une configuration nftables, intégrez ces règles dans votre chaîne input existante au lieu de créer une table séparée. L'approche ci-dessus est autonome et n'interfère pas avec les autres règles de firewall.

Pour ajouter plusieurs peers, ajoutez leurs IP dans le set elements :

elements = { 198.51.100.1, 203.0.113.1 }

Activez nftables pour que les règles persistent après un redémarrage, puis rechargez pour prendre en compte le nouveau include :

sudo systemctl enable --now nftables
sudo systemctl reload nftables

Confirmez que les règles sont chargées :

sudo nft list table inet bgp-filter

Vous devriez voir les IP de vos peers dans les sets et les règles de la chaîne listées.

Résumé de la sécurité

Protection	Fonction	Configuré dans
GTSM (`ttl-security hops 1`)	Rejette les paquets BGP ne provenant pas d'un peer directement connecté	vtysh, par voisin
TCP MD5 (`password`)	Authentifie les segments TCP, empêche l'injection de RST	vtysh, par voisin
Prefix-list (sortante)	N'annonce que vos propres préfixes	vtysh, route-map
Prefix-list (entrante)	Rejette les plages bogon/réservées	vtysh, par voisin
`maximum-prefix`	Coupe la session si le peer envoie trop de routes	vtysh, par address-family
nftables	Restreint le port TCP 179 aux IP des peers connus	`/etc/nftables.d/bgp.conf`

Comment vérifier la session BGP et la propagation des préfixes ?

Après avoir sauvegardé la configuration avec write memory, la session BGP devrait commencer à s'établir. La vérification se fait en trois étapes : vérifications locales vtysh, table de routage du noyau et looking glasses externes.

Commandes de vérification vtysh

Commande	Ce qu'elle affiche
`show bgp summary`	Tous les peers, leur état, préfixes reçus
`show bgp ipv4 unicast`	Table BGP IPv4
`show bgp ipv6 unicast`	Table BGP IPv6
`show bgp ipv4 unicast neighbors PEER_IPV4 advertised-routes`	Ce que vous envoyez au peer
`show bgp ipv4 unicast neighbors PEER_IPV4 received-routes`	Ce que le peer vous envoie (nécessite `soft-reconfiguration inbound`)
`show ip bgp neighbors PEER_IPV4`	État détaillé du voisin, uptime, capacités

Contrôlez l'état de la session :

sudo vtysh -c "show bgp summary"

Sortie attendue (simplifiée) :

IPv4 Unicast Summary:
BGP router identifier YOUR_IPV4, local AS number YOUR_ASN, vrf default
Neighbor        V    AS   MsgRcvd  MsgSent  TblVer   InQ  OutQ  Up/Down  State/PfxRcd
PEER_IPV4       4  PEER_ASN   1205     843       0      0     0 01:23:45        12

Notez la colonne State/PfxRcd. Un nombre signifie que la session est établie et que ce nombre de préfixes a été reçu. Si vous voyez Active, Connect ou OpenSent, la session n'est pas encore montée. Consultez la section suivante pour le dépannage.

Assurez-vous que votre préfixe est annoncé :

sudo vtysh -c "show bgp ipv4 unicast neighbors PEER_IPV4 advertised-routes"

Votre préfixe devrait apparaître dans la sortie. S'il n'apparaît pas, vérifiez que :

L'interface dummy est active (ip addr show dummy-bgp).
La route existe dans le noyau (ip route show YOUR_PREFIX_V4).
L'instruction network correspond exactement au préfixe et au masque.

Vérification externe

Vérifiez depuis l'extérieur de votre réseau que le préfixe est visible sur internet.

Depuis votre machine locale (pas le VPS) :

traceroute YOUR_PREFIX_V4_FIRST_IP

Utilisez bgp.tools pour rechercher votre préfixe et vérifier :

L'AS d'origine correspond à votre ASN.
Le statut ROA affiche « Valid » (pas « Unknown » ni « Invalid »).
Le préfixe est visible depuis plusieurs points de vue.

Vous pouvez aussi interroger le looking glass RIPE RIS :

curl -s "https://stat.ripe.net/data/looking-glass/data.json?resource=YOUR_PREFIX_V4" | python3 -m json.tool | head -50

Persistance de la configuration

FRR sauvegarde sa configuration dans /etc/frr/frr.conf quand vous exécutez write memory dans vtysh. Tant que le service FRR est activé (systemctl enable frr), il lit ce fichier au démarrage.

Confirmez les deux mécanismes de persistance :

sudo systemctl is-enabled frr

Devrait retourner enabled.

sudo vtysh -c "show running-config" | head -5

Comparez avec le fichier sauvegardé :

head -5 /etc/frr/frr.conf

Ils devraient correspondre. S'ils divergent, exécutez write memory à nouveau.

L'interface dummy persiste grâce à systemd-networkd (configuré précédemment). Vérifiez :

sudo systemctl is-enabled systemd-networkd

Exemple complet annoté de frr.conf

Voici un exemple de configuration complet pour référence. Remplacez tous les marqueurs par vos valeurs.

frr version 10.5.3
frr defaults traditional
hostname bgp-vps
log syslog informational
!
! --- Prefix-lists : sortantes (uniquement nos préfixes) ---
ip prefix-list OUR-PREFIXES-V4 seq 10 permit 203.0.113.0/24
ip prefix-list OUR-PREFIXES-V4 seq 999 deny any
!
ipv6 prefix-list OUR-PREFIXES-V6 seq 10 permit 2001:db8:abc::/48
ipv6 prefix-list OUR-PREFIXES-V6 seq 999 deny any
!
! --- Prefix-lists : filtres bogon entrants ---
ip prefix-list BOGONS-V4 seq 10 deny 0.0.0.0/8 le 32
ip prefix-list BOGONS-V4 seq 20 deny 10.0.0.0/8 le 32
ip prefix-list BOGONS-V4 seq 30 deny 100.64.0.0/10 le 32
ip prefix-list BOGONS-V4 seq 40 deny 127.0.0.0/8 le 32
ip prefix-list BOGONS-V4 seq 50 deny 169.254.0.0/16 le 32
ip prefix-list BOGONS-V4 seq 60 deny 172.16.0.0/12 le 32
ip prefix-list BOGONS-V4 seq 70 deny 192.0.2.0/24 le 32
ip prefix-list BOGONS-V4 seq 80 deny 192.88.99.0/24 le 32
ip prefix-list BOGONS-V4 seq 90 deny 192.168.0.0/16 le 32
ip prefix-list BOGONS-V4 seq 100 deny 198.18.0.0/15 le 32
ip prefix-list BOGONS-V4 seq 110 deny 198.51.100.0/24 le 32
ip prefix-list BOGONS-V4 seq 120 deny 203.0.113.0/24 le 32
ip prefix-list BOGONS-V4 seq 130 deny 224.0.0.0/4 le 32
ip prefix-list BOGONS-V4 seq 140 deny 240.0.0.0/4 le 32
ip prefix-list BOGONS-V4 seq 999 permit 0.0.0.0/0 le 24
!
ipv6 prefix-list BOGONS-V6 seq 10 deny ::/8 le 128
ipv6 prefix-list BOGONS-V6 seq 20 deny 100::/64 le 128
ipv6 prefix-list BOGONS-V6 seq 30 deny 2001:2::/48 le 128
ipv6 prefix-list BOGONS-V6 seq 40 deny 2001:10::/28 le 128
ipv6 prefix-list BOGONS-V6 seq 50 deny 2001:db8::/32 le 128
ipv6 prefix-list BOGONS-V6 seq 60 deny 3fff::/20 le 128
ipv6 prefix-list BOGONS-V6 seq 70 deny 2002::/16 le 128
ipv6 prefix-list BOGONS-V6 seq 80 deny 3ffe::/16 le 128
ipv6 prefix-list BOGONS-V6 seq 90 deny 5f00::/16 le 128
ipv6 prefix-list BOGONS-V6 seq 100 deny fc00::/7 le 128
ipv6 prefix-list BOGONS-V6 seq 110 deny fe80::/10 le 128
ipv6 prefix-list BOGONS-V6 seq 120 deny fec0::/10 le 128
ipv6 prefix-list BOGONS-V6 seq 130 deny ff00::/8 le 128
ipv6 prefix-list BOGONS-V6 seq 999 permit ::/0 le 48
!
! --- Route-maps ---
route-map EXPORT-V4 permit 10
 match ip address prefix-list OUR-PREFIXES-V4
!
route-map EXPORT-V6 permit 10
 match ipv6 address prefix-list OUR-PREFIXES-V6
!
route-map IMPORT-V4 permit 10
 match ip address prefix-list BOGONS-V4
!
route-map IMPORT-V6 permit 10
 match ipv6 address prefix-list BOGONS-V6
!
! --- Configuration BGP ---
router bgp 212345
 bgp router-id 198.51.100.2
 no bgp default ipv4-unicast
 !
 ! Peer IPv4
 neighbor 198.51.100.1 remote-as 6939
 neighbor 198.51.100.1 description Upstream-v4
 neighbor 198.51.100.1 password SECRET
 neighbor 198.51.100.1 ttl-security hops 1
 neighbor 198.51.100.1 soft-reconfiguration inbound
 !
 ! Peer IPv6
 neighbor 2001:db8:1::1 remote-as 6939
 neighbor 2001:db8:1::1 description Upstream-v6
 neighbor 2001:db8:1::1 password SECRET
 neighbor 2001:db8:1::1 ttl-security hops 1
 neighbor 2001:db8:1::1 soft-reconfiguration inbound
 !
 address-family ipv4 unicast
  network 203.0.113.0/24
  neighbor 198.51.100.1 activate
  neighbor 198.51.100.1 route-map EXPORT-V4 out
  neighbor 198.51.100.1 route-map IMPORT-V4 in
  neighbor 198.51.100.1 prefix-list BOGONS-V4 in
  neighbor 198.51.100.1 maximum-prefix 500000 80
 exit-address-family
 !
 address-family ipv6 unicast
  network 2001:db8:abc::/48
  neighbor 2001:db8:1::1 activate
  neighbor 2001:db8:1::1 route-map EXPORT-V6 out
  neighbor 2001:db8:1::1 route-map IMPORT-V6 in
  neighbor 2001:db8:1::1 prefix-list BOGONS-V6 in
  neighbor 2001:db8:1::1 maximum-prefix 200000 80
 exit-address-family
!

Dépannage

Session BGP bloquée en état Active ou Connect

La session tente de s'établir mais TCP 179 ne peut pas se connecter. Vérifiez dans l'ordre :

Firewall : Pouvez-vous atteindre le peer sur TCP 179 ?
```
sudo nft list ruleset | grep 179
```
IP du peer : L'adresse IP du voisin est-elle correcte ? Les fautes de frappe sont la cause la plus fréquente.
```
sudo vtysh -c "show bgp neighbors PEER_IPV4" | grep "BGP state"
```
Discordance MD5 : Si vous utilisez TCP MD5, les deux côtés doivent avoir exactement la même chaîne de mot de passe. Il n'y a pas de message d'erreur explicite pour cela. La session échoue silencieusement.
GTSM : Si ttl-security hops 1 est configuré mais que le peer est à plusieurs sauts (derrière un NAT ou un tunnel), la vérification du TTL échoue. Retirez ttl-security et utilisez ebgp-multihop à la place pour les sessions multi-hop.

Préfixe non visible extérieurement

Votre session est établie mais le préfixe n'apparaît pas sur les looking glasses.

Vérifiez les routes annoncées :
```
sudo vtysh -c "show bgp ipv4 unicast neighbors PEER_IPV4 advertised-routes"
```
Si votre préfixe n'est pas listé, le filtre sortant le bloque. Vérifiez que la prefix-list correspond exactement à votre préfixe.
Vérifiez la route dans le noyau :
```
ip route show YOUR_PREFIX_V4
```
Si elle est absente, l'interface dummy est arrêtée ou mal configurée.
Vérifiez la validité ROA : Si votre ROA est manquant ou incorrect, les réseaux validant le RPKI rejetteront votre annonce. Vérifiez sur RIPE RPKI Validator.

Lire les logs

FRR écrit dans syslog par défaut. Pour suivre les événements spécifiques à BGP :

journalctl -u frr -f --grep="bgpd"

Pour une sortie plus détaillée, activez le debug temporairement dans vtysh :

debug bgp updates
debug bgp keepalives

Désactivez-le quand vous avez terminé (c'est très verbeux) :

no debug bgp updates
no debug bgp keepalives

Prochaines étapes

Ajouter la validation RPKI : Configurez le support RPKI intégré de FRR pour valider les routes entrantes par rapport aux données ROA. Voir RPKI ROA pour BGP : créer des ROAs, valider les routes dans BIRD2 et FRR.
Filtrage avancé : Construisez des route-maps plus granulaires avec du matching par community, des filtres AS-path et du réglage de local-preference. Voir BGP Route Filtering : Prefix Lists, Filtres AS-Path, Rejet des Bogons et GTSM.
Monitoring : Mettez en place la supervision des sessions BGP avec des outils comme Prometheus + bgp_exporter ou des traps SNMP Zabbix pour recevoir des alertes quand une session tombe.