Configuration BGP avec FRRouting sur un VPS Linux

15 min de lecture·Matthieu|

Configuration BGP pas a pas avec FRRouting pour annoncer vos propres prefixes IPv4 et IPv6 depuis un VPS Linux. Couvre l'installation, la configuration vtysh, les prefix-lists, route-maps, GTSM et les regles de firewall nftables.

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

A la fin, vous aurez une session eBGP fonctionnelle avec votre fournisseur upstream, une origination de prefixes dual-stack via des interfaces dummy persistantes, un filtrage de routes entrant et sortant, une securisation de session GTSM et des regles de firewall nftables verrouillant le port TCP 179.

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

Pour en savoir plus sur l'utilisation de votre propre espace IP sur un VPS, voir BGP : apporter votre propre IP sur un VPS.

Prerequis

Avant de commencer, vous avez besoin de :

  • Un ASN (Autonomous System Number) public. Si vous n'en avez pas encore, voir Enregistrer un ASN au RIPE NCC.
  • Au moins un prefixe IPv4 /24 ou IPv6 /48 assigne a votre ASN.
  • Des objets ROA (Route Origin Authorization) crees dans le tableau de bord RPKI de votre RIR. Voir .
  • 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 echeant.
  • Un VPS Linux sous Debian 12 (Bookworm) ou Ubuntu 24.04 (Noble). Acces root ou sudo.

Tout au long de ce guide, remplacez ces marqueurs par vos valeurs reelles :

Marqueur Signification Exemple
YOUR_ASN Votre numero d'AS 212345
PEER_ASN Numero 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 cote du peering BGP (IPv4) 198.51.100.2
YOUR_IPV6 Votre cote du peering BGP (IPv6) 2001:db8:1::2
YOUR_PREFIX_V4 Votre prefixe IPv4 203.0.113.0/24
YOUR_PREFIX_V6 Votre prefixe 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 depot apt officiel pour obtenir la derniere version stable (10.5.x en mars 2026). Les paquets des distributions Debian et Ubuntu ont souvent plusieurs versions majeures de retard. Le depot officiel suit la branche stable actuelle et supporte Bookworm et Noble.

Ajoutez la cle de signature GPG :

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

Ajoutez le depot. Utilisez frr-stable pour suivre la derniere 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 (necessaires pour frr-reload.py) :

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

Verifiez la version installee :

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 apres un redemarrage et demarrez-le immediatement :

sudo systemctl enable --now frr

Verifiez qu'il tourne :

systemctl status frr

Vous devriez voir active (running) dans la sortie. FRR execute plusieurs daemons (zebra, bgpd, etc.) geres par un processus parent unique.

Comment activer le daemon BGP dans FRR ?

FRR est livre avec tous les daemons de protocole desactives 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.

Editez le fichier daemons :

sudo nano /etc/frr/daemons

Trouvez la ligne bgpd et mettez-la a yes :

bgpd=yes

Tous les autres daemons (ospfd, isisd, etc.) peuvent rester a no sauf si vous en avez besoin. Zebra est toujours active et gere la table de routage du noyau.

Voici le role de chaque daemon :

Daemon Role Defaut
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

Redemarrez FRR pour appliquer le changement :

sudo systemctl restart frr

Verifiez 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 ete configure. Nous allons le faire maintenant.

Les bases de vtysh

vtysh est le shell integre 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 etes maintenant dans le CLI de FRR. Le prompt affiche le hostname. Les modes que vous utiliserez :

Mode Entrer avec Prompt Fonction
Exec (par defaut) # Commandes show, verification
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 ecrit dans /etc/frr/frr.conf. FRR utilise un modele de configuration integre par defaut : 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 cree le processus router, definit le router ID, desactive l'unicast IPv4 automatique (pour controler exactement quelles familles d'adresses sont actives par voisin), et definit 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, generalement votre adresse IPv4 principale. Doit etre unique sur le peering.
  • no bgp default ipv4-unicast : Empeche 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 usurpes provenant de sources distantes. Mutuellement exclusif avec ebgp-multihop.
  • password : Configure l'authentification TCP MD5 (RFC 2385). Les deux cotes doivent utiliser la meme chaine. Tous les fournisseurs ne l'exigent pas. Omettez-la si votre fournisseur ne le demande pas.
  • soft-reconfiguration inbound : Stocke les routes recues en memoire pour appliquer des changements de politique sans reinitialiser la session. Consomme plus de RAM mais evite les coupures de session lors des mises a jour de filtres.

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

Comment annoncer mes propres prefixes IPv4 et IPv6 ?

L'origination de prefixes dans FRR necessite deux choses : une instruction network dans la configuration BGP, et le prefixe present dans la table de routage du noyau. La methode la plus simple pour injecter le prefixe dans le noyau est via une interface dummy. Nous allons d'abord configurer les interfaces dummy, puis les familles d'adresses BGP.

Comment creer des interfaces dummy persistantes pour l'origination de prefixes ?

Une interface dummy est une interface de type loopback qui porte une adresse IP sans etre liee a du materiel physique. Le daemon zebra de FRR recupere les routes du noyau, donc si votre prefixe est assigne a une interface dummy, zebra l'installe et bgpd peut l'annoncer.

Creez les interfaces dummy avec systemd-networkd pour qu'elles persistent apres un redemarrage.

Creez le fichier netdev :

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

Creez le fichier network avec vos prefixes :

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 premiere IP utilisable de votre prefixe (ex. 203.0.113.1/24). Pour IPv6, utilisez n'importe quelle adresse dans votre prefixe (ex. 2001:db8:abc::1/48).

Activez systemd-networkd s'il n'est pas deja actif, et redemarrez-le :

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

Verifiez que l'interface dummy est active :

ip addr show dummy-bgp

Vous devriez voir vos adresses IPv4 et IPv6 assignees a l'interface.

Verifiez 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 re-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

Details :

  • activate active le voisin dans cette famille d'adresses. Necessaire car nous avons desactive bgp default ipv4-unicast.
  • network indique a bgpd d'originer ce prefixe. Le prefixe doit exister dans la table de routage du noyau (zebra le recupere depuis l'interface dummy).
  • maximum-prefix 500000 80 coupe la session si le peer envoie plus de 500 000 prefixes IPv4. Le 80 genere un avertissement a 80 % (400 000). Ajustez selon que vous recevez une table complete ou uniquement une route par defaut. Pour une session route-par-defaut uniquement, fixez cette valeur a 10.
  • Les references route-map et prefix-list pointent vers les filtres que nous definissons 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 prefixes que vous ne possedez 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 strategies de filtrage, voir .

Prefix-lists sortantes

N'annoncez que les prefixes que vous possedez. 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 prefixes, ajoutez d'autres lignes permit avec des numeros de sequence croissants.

Prefix-lists bogon entrantes

Rejetez les prefixes qui ne devraient jamais apparaitre 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 derniere ligne permit de chaque liste accepte tout ce qui n'est pas explicitement refuse. Le le 24 (IPv4) et le 48 (IPv6) rejettent les prefixes trop specifiques : 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 supplementaires (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 prefixes. Tout le reste est implicitement refuse (FRR refuse tout ce qui n'est pas explicitement matche 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

Verifiez que la configuration a ete ecrite :

ls -la /etc/frr/frr.conf

Le fichier devrait afficher un horodatage de modification recent avec le proprietaire frr:frr et les permissions 640.

Comment securiser la session BGP et proteger le port TCP 179 ?

BGP tourne sur le port TCP 179. N'importe quel hote sur internet peut tenter de s'y connecter. Au-dela du GTSM et de l'authentification MD5 deja configures, vous avez besoin de regles de firewall pour restreindre le port TCP 179 aux adresses de vos peers.

Regles de firewall nftables

Installez nftables s'il n'est pas deja present. Sur les installations minimales d'Ubuntu 24.04, il n'est pas inclus par defaut :

sudo apt install -y nftables

Creez le repertoire /etc/nftables.d/ pour les fichiers de configuration modulaires et ajoutez une directive include dans la configuration principale nftables pour que les regles personnalisees persistent apres un redemarrage :

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

Creez un fichier de configuration nftables dedie 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 deja une configuration nftables, integrez ces regles dans votre chaine input existante au lieu de creer une table separee. L'approche ci-dessus est autonome et n'interfere pas avec les autres regles 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 regles persistent apres un redemarrage, puis rechargez pour prendre en compte le nouveau include :

sudo systemctl enable --now nftables
sudo systemctl reload nftables

Verifiez que les regles sont chargees :

sudo nft list table inet bgp-filter

Vous devriez voir les IP de vos peers dans les sets et les regles de la chaine listees.

Resume de la securite

Protection Fonction Configure dans
GTSM (ttl-security hops 1) Rejette les paquets BGP ne provenant pas d'un peer directement connecte vtysh, par voisin
TCP MD5 (password) Authentifie les segments TCP, empeche l'injection de RST vtysh, par voisin
Prefix-list (sortante) N'annonce que vos propres prefixes vtysh, route-map
Prefix-list (entrante) Rejette les plages bogon/reservees 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 verifier la session BGP et la propagation des prefixes ?

Apres avoir sauvegarde la configuration avec write memory, la session BGP devrait commencer a s'etablir. La verification se fait en trois etapes : verifications locales vtysh, table de routage du noyau et looking glasses externes.

Commandes de verification vtysh

Commande Ce qu'elle affiche
show bgp summary Tous les peers, leur etat, prefixes recus
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 (necessite soft-reconfiguration inbound)
show ip bgp neighbors PEER_IPV4 Etat detaille du voisin, uptime, capacites

Verifiez l'etat de la session :

sudo vtysh -c "show bgp summary"

Sortie attendue (simplifiee) :

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 etablie et que ce nombre de prefixes a ete recu. Si vous voyez Active, Connect ou OpenSent, la session n'est pas encore montee. Consultez la section suivante pour le depannage.

Verifiez que votre prefixe est annonce :

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

Votre prefixe devrait apparaitre dans la sortie. S'il n'apparait pas, verifiez que :

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

Verification externe

Verifiez depuis l'exterieur de votre reseau que le prefixe est visible sur internet.

Depuis votre machine locale (pas le VPS) :

traceroute YOUR_PREFIX_V4_FIRST_IP

Utilisez bgp.tools pour rechercher votre prefixe et verifier :

  • L'AS d'origine correspond a votre ASN.
  • Le statut ROA affiche « Valid » (pas « Unknown » ni « Invalid »).
  • Le prefixe 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 executez write memory dans vtysh. Tant que le service FRR est active (systemctl enable frr), il lit ce fichier au demarrage.

Verifiez les deux mecanismes de persistance :

sudo systemctl is-enabled frr

Devrait retourner enabled.

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

Comparez avec le fichier sauvegarde :

head -5 /etc/frr/frr.conf

Ils devraient correspondre. S'ils divergent, executez write memory a nouveau.

L'interface dummy persiste grace a systemd-networkd (configure precedemment). Verifiez :

sudo systemctl is-enabled systemd-networkd

Exemple complet annote de frr.conf

Voici un exemple de configuration complet pour reference. 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 prefixes) ---
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
!

Depannage

Session BGP bloquee en etat Active ou Connect

La session tente de s'etablir mais TCP 179 ne peut pas se connecter. Verifiez dans l'ordre :

  1. Firewall : Pouvez-vous atteindre le peer sur TCP 179 ? 
    sudo nft list ruleset | grep 179
  2. IP du peer : L'adresse IP du voisin est-elle correcte ? Les fautes de frappe sont la cause la plus frequente. 
    sudo vtysh -c "show bgp neighbors PEER_IPV4" | grep "BGP state"
  3. Discordance MD5 : Si vous utilisez TCP MD5, les deux cotes doivent avoir exactement la meme chaine de mot de passe. Il n'y a pas de message d'erreur explicite pour cela. La session echoue silencieusement.
  4. GTSM : Si ttl-security hops 1 est configure mais que le peer est a plusieurs sauts (derriere un NAT ou un tunnel), la verification du TTL echoue. Retirez ttl-security et utilisez ebgp-multihop a la place pour les sessions multi-hop.

Prefixe non visible exterieurement

Votre session est etablie mais le prefixe n'apparait pas sur les looking glasses.

  1. Verifiez les routes annoncees :

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

    Si votre prefixe n'est pas liste, le filtre sortant le bloque. Verifiez que la prefix-list correspond exactement a votre prefixe.

  2. Verifiez la route dans le noyau :

    ip route show YOUR_PREFIX_V4

    Si elle est absente, l'interface dummy est arretee ou mal configuree.

  3. Verifiez la validite ROA : Si votre ROA est manquant ou incorrect, les reseaux validant le RPKI rejetteront votre annonce. Verifiez sur RIPE RPKI Validator.

Lire les logs

FRR ecrit dans syslog par defaut. Pour suivre les evenements specifiques a BGP :

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

Pour une sortie plus detaillee, activez le debug temporairement dans vtysh :

debug bgp updates
debug bgp keepalives

Desactivez-le quand vous avez termine (c'est tres verbeux) :

no debug bgp updates
no debug bgp keepalives

Prochaines etapes

  • Ajouter la validation RPKI : Configurez le support RPKI integre de FRR pour valider les routes entrantes par rapport aux donnees ROA. Voir .
  • Filtrage avance : Construisez des route-maps plus granulaires avec du matching par community, des filtres AS-path et du reglage de local-preference. Voir .
  • 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.

Copyright 2026 Virtua.Cloud. Tous droits reserves. Ce contenu est une creation originale de l'equipe Virtua.Cloud. Toute reproduction, republication ou redistribution sans autorisation ecrite est interdite.

Prêt à essayer ?

Déployez votre serveur en quelques secondes. Linux, Windows ou FreeBSD.

Voir les offres VPS