Configuration BGP avec BIRD2 sur un VPS Linux

16 min de lecture·Matthieu·bgpbird2routingipv6firewall|

Installez BIRD2 sur Debian 12 ou Ubuntu 24.04 et configurez une session BGP pour annoncer vos propres préfixes IP. Dual-stack, filtres d'export, interfaces dummy persistantes, règles nftables et vérification birdc.

BIRD est le daemon de routage maintenu par CZ.NIC. La version 2 a unifié IPv4 et IPv6 dans un seul daemon, remplacé l'architecture séparée BIRD/BIRD6 de la 1.x, et ajouté un langage de filtre puissant. Ce guide couvre l'installation de BIRD2 sur un VPS Linux, la configuration d'une session BGP avec votre fournisseur upstream, l'annonce de vos préfixes IP et la vérification de l'ensemble.

Tous les exemples sont dual-stack (IPv4 + IPv6). Remplacez les ASN, adresses IP et préfixes d'exemple par vos propres valeurs tout au long du guide.

De quoi avez-vous besoin avant de configurer BIRD2 pour BGP ?

Avant de toucher à bird.conf, il vous faut un ASN, un espace IP alloué et un fournisseur qui propose des sessions BGP sur votre VPS. Sans ces trois éléments, BIRD2 n'a rien à annoncer et personne avec qui établir un peering.

Rassemblez ces informations auprès de votre fournisseur ou de votre allocation RIR :

Élément Valeur d'exemple Où l'obtenir
Votre ASN AS65400 RIPE NCC, ARIN ou votre LIR
Votre préfixe IPv4 203.0.113.0/24 Allocation RIR ou assignation PA du fournisseur
Votre préfixe IPv6 2001:db8:1000::/48 Allocation RIR ou assignation PA du fournisseur
ASN upstream AS64496 Détails de la session BGP du fournisseur
IPv4 du peer upstream 198.51.100.1 Détails de la session BGP du fournisseur
IPv6 du peer upstream 2001:db8::1 Détails de la session BGP du fournisseur
Votre IPv4 de peering 198.51.100.2 Détails de la session BGP du fournisseur
Votre IPv6 de peering 2001:db8::2 Détails de la session BGP du fournisseur
Mot de passe MD5 (secret partagé) Convenu avec le fournisseur

Vous devez aussi avoir publié des enregistrements ROA pour vos préfixes avant que vos routes ne passent la validation RPKI auprès des réseaux en aval. Voir RPKI ROA pour BGP : créer des ROAs, valider les routes dans BIRD2 et FRR pour cette configuration.

Assurez-vous que votre fournisseur a ajouté vos préfixes à ses filtres IRR. Sans cela, vos annonces seront filtrées même si la session BGP s'établit.

Un VPS avec au moins 1 Go de RAM suffit pour BIRD2 avec une table complète (plus d'un million de routes IPv4). Si vous n'acceptez qu'une route par défaut de votre upstream, l'utilisation mémoire reste sous les 100 Mo.

Comment installer BIRD2 sur Debian 12 et Ubuntu 24.04 ?

BIRD2 est disponible dans les dépôts par défaut des deux distributions. Debian 12 fournit la version 2.0.12, Ubuntu 24.04 la version 2.14. Les deux fonctionnent pour du BGP de base, mais le dépôt officiel CZ.NIC propose BIRD 2.18 (publié en janvier 2026) avec le support BGP dynamic unnumbered, des améliorations de performance et des correctifs récents. Utilisez le dépôt CZ.NIC pour les déploiements en production.

Note : CZ.NIC publie les paquets BIRD2 sous le nom de projet bird2. Ne confondez pas avec le projet bird (qui ne couvre que Debian) ou bird3 (BIRD 3.x).

Installation depuis le dépôt CZ.NIC (recommandé)

Ajoutez le dépôt officiel, puis installez :

sudo apt-get update
sudo apt-get -y install apt-transport-https ca-certificates wget

Importez la clé GPG de CZ.NIC :

sudo wget -O /usr/share/keyrings/cznic-labs-pkg.gpg https://pkg.labs.nic.cz/gpg

Ajoutez le dépôt. Sur Debian 12 :

echo "deb [signed-by=/usr/share/keyrings/cznic-labs-pkg.gpg] https://pkg.labs.nic.cz/bird2 bookworm main" | sudo tee /etc/apt/sources.list.d/cznic-labs-bird.list

Sur Ubuntu 24.04 :

echo "deb [signed-by=/usr/share/keyrings/cznic-labs-pkg.gpg] https://pkg.labs.nic.cz/bird2 noble main" | sudo tee /etc/apt/sources.list.d/cznic-labs-bird.list

Installez BIRD2 :

sudo apt-get update
sudo apt-get -y install bird2

Installation depuis les dépôts par défaut

Si vous préférez le paquet de la distribution :

sudo apt-get update
sudo apt-get -y install bird2

Vérification de l'installation

bird --version

Sortie attendue (dépôt CZ.NIC) :

BIRD version 2.18

Contrôlez que le service tourne :

sudo systemctl status bird

BIRD démarre automatiquement après l'installation. La configuration par défaut dans /etc/bird/bird.conf est un squelette. Vous allez la remplacer entièrement dans la section suivante.

Comment est structuré bird.conf pour BGP ?

Un bird.conf prêt pour BGP contient cinq blocs : les paramètres globaux et quatre sections de protocole (device, direct, kernel, bgp). Chaque protocole fonctionne indépendamment et communique via les tables de routage.

Voici le bird.conf complet pour une configuration BGP dual-stack. Lisez-le d'abord, puis les sections suivantes expliquent chaque bloc.

sudo cp /etc/bird/bird.conf /etc/bird/bird.conf.bak

sudo tee /etc/bird/bird.conf > /dev/null << 'BIRDCONF'
# /etc/bird/bird.conf - BIRD2 BGP configuration
# Replace all placeholder values with your own

log syslog all;

router id 198.51.100.2;

# Watch interface state changes
protocol device {
    scan time 10;
}

# Import connected routes (needed for next-hop resolution)
protocol direct {
    ipv4;
    ipv6;
    interface "dummy0";
    interface "eth0";
}

# Sync BIRD routes to kernel routing table
protocol kernel {
    ipv4 {
        export all;
        import all;
    };
    learn;
    scan time 15;
    merge paths on;
}

protocol kernel {
    ipv6 {
        export all;
        import all;
    };
    learn;
    scan time 15;
    merge paths on;
}

# Define your prefixes
define OWN_V4_PREFIX = 203.0.113.0/24;
define OWN_V6_PREFIX = 2001:db8:1000::/48;

# Export filter: only announce your own prefixes
filter export_bgp_v4 {
    if net = OWN_V4_PREFIX then accept;
    reject;
}

filter export_bgp_v6 {
    if net = OWN_V6_PREFIX then accept;
    reject;
}

# Static routes for prefix origination (point to dummy0)
protocol static static_v4 {
    ipv4;
    route 203.0.113.0/24 via "dummy0";
}

protocol static static_v6 {
    ipv6;
    route 2001:db8:1000::/48 via "dummy0";
}

# BGP session with upstream provider
protocol bgp upstream1 {
    description "Upstream Provider";
    local 198.51.100.2 as 65400;
    neighbor 198.51.100.1 as 64496;
    source address 198.51.100.2;
    hold time 90;
    keepalive time 30;
    password "your-md5-secret";

    ipv4 {
        import all;
        export filter export_bgp_v4;
        next hop self;
    };

    ipv6 {
        import all;
        export filter export_bgp_v6;
        next hop self;
    };
}
BIRDCONF

Définissez les permissions sur le fichier de configuration. Seuls root et l'utilisateur bird ont besoin d'y accéder :

sudo chown root:bird /etc/bird/bird.conf
sudo chmod 640 /etc/bird/bird.conf

Assurez-vous les permissions :

ls -la /etc/bird/bird.conf

Sortie attendue :

-rw-r----- 1 root bird 1247 Mar 19 12:00 /etc/bird/bird.conf

Paramètres globaux

log syslog all;
router id 198.51.100.2;

router id doit être une adresse IPv4 globalement unique. Utilisez l'une de vos adresses IP assignées. BIRD peut la détecter automatiquement depuis les interfaces, mais une valeur explicite est préférable.

log syslog all envoie tous les messages de log au journal système. Consultez-les avec journalctl -u bird -f. Si vous avez besoin d'une sortie détaillée pendant le débogage d'un protocole spécifique, ajoutez temporairement debug protocols all;. Retirez-le une fois la session fonctionnelle. La journalisation en mode debug génère un volume élevé et peut remplir votre stockage journal.

Protocol device

protocol device {
    scan time 10;
}

Surveille les changements d'état des interfaces toutes les 10 secondes. Obligatoire. Sans lui, BIRD ne sait pas quand les interfaces montent ou descendent.

Protocol direct

protocol direct {
    ipv4;
    ipv6;
    interface "dummy0";
    interface "eth0";
}

Importe les routes connectées depuis les interfaces listées. BIRD en a besoin pour la résolution du next-hop. Listez uniquement les interfaces impliquées dans votre configuration BGP.

Protocol kernel

Deux blocs protocol kernel sont nécessaires : un pour IPv4, un pour IPv6. Chacun synchronise sa famille d'adresses entre la table de routage de BIRD et la table du noyau Linux.

merge paths on active l'ECMP si vous avez plusieurs upstreams. learn importe les routes existantes du noyau dans BIRD.

Que fait le bloc protocol BGP ?

Le bloc protocol bgp définit une session de peering avec un voisin. Il spécifie qui vous êtes (local ... as), avec qui vous peerez (neighbor ... as), l'authentification (password) et quelles routes échanger (blocs channel).

Directives principales :

Directive Fonction
local <ip> as <ASN> Votre IP de peering et votre ASN
neighbor <ip> as <ASN> IP de peering et ASN de l'upstream
source address <ip> IP source pour la connexion TCP
hold time 90 Secondes avant de déclarer le pair mort (3x keepalive)
keepalive time 30 Intervalle entre les messages keepalive
password "..." Authentification MD5 (RFC 2385)

L'authentification MD5 protège la session BGP contre les resets TCP usurpés et les attaques par injection. Les deux côtés doivent configurer le même mot de passe. Demandez le secret partagé à votre fournisseur.

Comment configurer les canaux dual-stack IPv4 et IPv6 ?

BIRD2 gère IPv4 et IPv6 comme des canaux (channels) séparés au sein du même bloc protocol. Chaque canal a sa propre politique d'import/export :

ipv4 {
    import all;
    export filter export_bgp_v4;
    next hop self;
};

ipv6 {
    import all;
    export filter export_bgp_v6;
    next hop self;
};

import all accepte toutes les routes de l'upstream. En production, vous devriez aussi filtrer les imports. Voir BGP Route Filtering : Prefix Lists, Filtres AS-Path, Rejet des Bogons et GTSM pour des exemples de filtres d'import.

next hop self réécrit l'attribut next-hop vers votre IP de peering. Nécessaire quand l'upstream attend que le trafic transite par votre adresse, ce qui est la configuration standard sur un VPS.

Si votre fournisseur utilise des sessions BGP séparées pour IPv4 et IPv6 (des IP de voisin différentes par famille d'adresses), divisez-les en deux blocs protocol bgp distincts.

Comment écrire des filtres d'export pour annoncer uniquement vos préfixes ?

Les filtres d'export contrôlent quelles routes BIRD envoie à l'upstream. Un filtre d'export mal configuré peut laisser passer des routes que vous ne possédez pas, ce qui entraînera la coupure de votre session et potentiellement un appel du NOC de votre upstream.

Le filtre dans la configuration ci-dessus utilise une correspondance de préfixe simple :

define OWN_V4_PREFIX = 203.0.113.0/24;

filter export_bgp_v4 {
    if net = OWN_V4_PREFIX then accept;
    reject;
}

Ceci accepte uniquement le /24 exact. Tout le reste est rejeté. Le reject à la fin est le deny par défaut.

Pour plusieurs préfixes, utilisez un set :

define OWN_V4_PREFIXES = [ 203.0.113.0/24, 198.51.100.0/24 ];

filter export_bgp_v4 {
    if net ~ OWN_V4_PREFIXES then accept;
    reject;
}

L'opérateur ~ effectue une correspondance dans un ensemble de préfixes (prefix set). Il supporte aussi la notation par plage :

define OWN_V4_PREFIXES = [ 203.0.113.0/24{24,24} ];

Le {24,24} restreint la correspondance à exactement /24. Utilisez {24,28} pour autoriser aussi la désagrégation jusqu'à /28 si vous avez besoin d'annoncer des more-specifics pour du traffic engineering.

Pour IPv6, le même schéma s'applique :

define OWN_V6_PREFIXES = [ 2001:db8:1000::/48{48,48} ];

filter export_bgp_v6 {
    if net ~ OWN_V6_PREFIXES then accept;
    reject;
}

Gardez toujours vos filtres d'export aussi stricts que possible. N'annoncez que ce que vous possédez, aux longueurs de préfixe exactes que vous visez. Un reject manquant à la fin de votre filtre fera utiliser à BIRD l'action par défaut du canal, qui peut être accept. Terminez toujours par un reject explicite.

Vous pouvez tester votre filtre sans l'appliquer :

sudo birdc eval '203.0.113.0/24 ~ [ 203.0.113.0/24 ]'

Ceci retourne TRUE ou FALSE et aide à déboguer la logique du filtre avant un rechargement de configuration.

Comment créer une interface dummy persistante pour l'origination de préfixes ?

BGP annonce les préfixes qui existent dans la table de routage. Vous avez besoin d'une interface avec votre préfixe assigné pour que BIRD puisse originer la route. Une interface dummy remplit ce rôle : elle est toujours active, n'a pas de lien physique et survit aux redémarrages quand elle est configurée via systemd-networkd.

Les commandes éphémères ip link add sont perdues au redémarrage. Utilisez plutôt systemd-networkd.

Créer le fichier .netdev

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

Créer le fichier .network

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

[Network]
Address=203.0.113.1/32
Address=2001:db8:1000::1/128
EOF

Assignez un seul /32 (ou /128 pour IPv6) de votre préfixe alloué à l'interface dummy. Cette adresse n'a pas besoin d'être joignable de l'extérieur. Elle existe uniquement pour que BIRD ait une route connectée pour le préfixe.

Appliquer et vérifier

sudo systemctl restart systemd-networkd

Attendez quelques secondes, puis vérifiez :

ip addr show dummy0

Sortie attendue :

3: dummy0: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000
    link/ether aa:bb:cc:dd:ee:ff brd ff:ff:ff:ff:ff:ff
    inet 203.0.113.1/32 scope global dummy0
       valid_lft forever preferred_lft forever
    inet6 2001:db8:1000::1/128 scope global
       valid_lft forever preferred_lft forever

Le state UNKNOWN pour une interface dummy est normal. Cela signifie que la couche liaison n'a pas de porteuse physique à suivre, mais l'interface est UP et transmet le trafic. L'adresse MAC est générée aléatoirement par systemd-networkd et sera différente sur votre système.

Si vous utilisez ifupdown au lieu de systemd-networkd (vérifiez avec networkctl status), vous devrez peut-être activer systemd-networkd d'abord :

sudo systemctl enable --now systemd-networkd

Confirmez que les fichiers sont en place pour le prochain redémarrage :

ls -la /etc/systemd/network/10-dummy0.*

-rw-r--r-- 1 root root  42 Mar 19 12:00 /etc/systemd/network/10-dummy0.netdev
-rw-r--r-- 1 root root  89 Mar 19 12:00 /etc/systemd/network/10-dummy0.network

Comment sécuriser BGP avec des règles de pare-feu nftables ?

BGP fonctionne sur le port TCP 179. Sans règles de pare-feu, n'importe quel hôte sur Internet peut tenter d'ouvrir une session BGP avec votre routeur. Les scanners automatisés trouvent un port 179 ouvert en quelques heures après la mise en ligne d'un VPS. Restreignez le port 179 à vos IP de pairs uniquement.

nftables peut ne pas être installé par défaut sur Ubuntu 24.04. Installez-le d'abord :

sudo apt-get -y install nftables

Créer le jeu de règles nftables

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

    set bgp_peers_v6 {
        type ipv6_addr
        elements = { 2001:db8::1 }
    }

    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

        # Drop BGP from everyone else
        tcp dport 179 drop
    }
}
EOF

Ajoutez d'autres IP de pairs aux sets au fur et à mesure que vous ajoutez des upstreams. Les sets nommés permettent de mettre à jour les listes de pairs sans réécrire les règles.

Intégrer avec votre configuration nftables existante

Si vous avez déjà /etc/nftables.conf, incluez les règles BGP :

echo 'include "/etc/nftables.d/bgp.conf"' | sudo tee -a /etc/nftables.conf

Si vous n'avez pas encore configuré nftables, créez le répertoire et chargez la configuration :

sudo mkdir -p /etc/nftables.d
sudo systemctl enable --now nftables

enable --now démarre nftables immédiatement et s'assure qu'il se charge à chaque démarrage.

Appliquez les règles :

sudo nft -f /etc/nftables.d/bgp.conf

Vérifier les règles

sudo nft list table inet bgp_filter

Sortie attendue :

table inet bgp_filter {
	set bgp_peers_v4 {
		type ipv4_addr
		elements = { 198.51.100.1 }
	}

	set bgp_peers_v6 {
		type ipv6_addr
		elements = { 2001:db8::1 }
	}

	chain input {
		type filter hook input priority filter; policy accept;
		tcp dport 179 ip saddr @bgp_peers_v4 accept
		tcp dport 179 ip6 saddr @bgp_peers_v6 accept
		tcp dport 179 drop
	}
}

nft list normalise priority 0 en priority filter et supprime les commentaires. C'est le comportement attendu.

Testez que la règle fonctionne en vérifiant l'état des connexions. Depuis le VPS :

sudo nft list ruleset | grep -c "179"

Ceci devrait retourner un nombre correspondant au nombre de règles port 179 que vous avez créées.

Confirmez aussi que le trafic BGP n'est pas bloqué entre vous et votre pair. Les règles ci-dessus n'affectent que les connexions entrantes. BIRD initie les connexions sortantes vers le pair, qui sont gérées par l'entrée conntrack established/related. Si vous avez une politique sortante restrictive, ajoutez :

sudo nft add rule inet bgp_filter input ct state established,related accept

Cette règle devrait déjà être dans votre jeu de règles de pare-feu de base. Si ce n'est pas le cas, ajoutez-la avant les règles BGP.

Comment appliquer la configuration BIRD2 ?

Avant de charger une nouvelle configuration, validez-la :

sudo birdc configure check

Sortie attendue :

BIRD 2.18 ready.
Reading configuration from /etc/bird/bird.conf
Configuration OK

S'il y a des erreurs de syntaxe, BIRD indique le numéro de ligne et le problème. Corrigez et revérifiez.

Appliquez la configuration :

sudo birdc configure

BIRD 2.18 ready.
Reading configuration from /etc/bird/bird.conf
Reconfigured

Vous pouvez voir Reconfiguration in progress au lieu de Reconfigured si BIRD traite encore les changements de protocole (comme l'établissement d'une nouvelle session BGP). Les deux messages sont normaux.

BIRD applique la nouvelle configuration sans redémarrage. Les sessions existantes effectuent une reconfiguration douce (soft reconfiguration) quand c'est possible. Si vous avez changé l'IP du voisin ou l'AS local, BIRD redémarre automatiquement le protocole concerné.

Pour les changements de configuration qui ne doivent pas perturber les sessions en cours (modifications de filtres, ajouts de routes statiques), utilisez :

sudo birdc reload upstream1

Ceci réapplique les filtres d'import/export aux routes existantes sans couper la session TCP.

Comment vérifier votre session BGP et les annonces de routes ?

Après avoir appliqué la configuration, utilisez birdc pour vérifier que la session est établie et que les routes sont annoncées. Ces commandes sont vos outils principaux de débogage.

Commande Ce qu'elle affiche Quand l'utiliser
show protocols Résumé de l'état des protocoles (Established, Active, etc.) Premier contrôle après un changement de config
show protocols all upstream1 Détails complets de la session, compteurs, timers Débogage d'une session spécifique
show route Toutes les routes dans la table de BIRD Vérifier les routes reçues et statiques
show route export upstream1 Routes envoyées à l'upstream Confirmer que vos préfixes sont annoncés
show route for 203.0.113.0/24 Meilleure route pour un préfixe donné Tracer la sélection de chemin
show route protocol static_v4 Routes d'un protocole spécifique Vérifier que les routes statiques sont chargées

Vérifier l'état de la session

sudo birdc show protocols

Sortie attendue quand tout fonctionne :

BIRD 2.18 ready.
Name       Proto      Table      State  Since         Info
device1    Device     ---        up     12:00:00.000
direct1    Direct     ---        up     12:00:00.000
kernel1    Kernel     master4    up     12:00:00.000
kernel2    Kernel     master6    up     12:00:00.000
static_v4  Static     master4    up     12:00:00.000
static_v6  Static     master6    up     12:00:00.000
upstream1  BGP        ---        up     12:00:05.000  Established

L'état Established signifie que la session BGP est active et que les routes peuvent être échangées. Tout autre état indique un problème.

Vérifier les routes exportées

sudo birdc show route export upstream1

BIRD 2.18 ready.
Table master4:
203.0.113.0/24       unicast [static_v4 12:00:00.000] * (200)
	dev dummy0
Table master6:
2001:db8:1000::/48   unicast [static_v6 12:00:00.000] * (200)
	dev dummy0

Vos deux préfixes IPv4 et IPv6 doivent apparaître ici. Si un préfixe manque, le filtre d'export le rejette.

Vérifier les détails complets de la session

sudo birdc show protocols all upstream1

Cherchez la ligne Routes: :

  Routes:         2 imported, 0 filtered, 2 exported, 0 preferred

Le nombre exported doit correspondre au nombre de préfixes que vous comptez annoncer.

Vérifier depuis l'extérieur

Utilisez un looking glass public pour confirmer que votre préfixe est visible sur Internet. Le NLNOG Looking Glass ou PeeringDB peuvent aider. Recherchez votre préfixe et vérifiez :

  • L'AS d'origine correspond au vôtre
  • Le chemin AS (AS path) passe par votre upstream
  • Aucun statut RPKI invalid n'apparaît

Vérifiez aussi depuis la table de routage du noyau :

ip route show | grep 203.0.113
ip -6 route show | grep 2001:db8:1000

Vous devriez voir des routes pointant vers l'interface dummy0.

Comment dépanner les problèmes BGP courants avec BIRD2 ?

La plupart des problèmes BGP entrent dans quelques catégories. Vérifiez-les dans l'ordre.

Référence des états de session BGP

État Signification Quoi vérifier
Idle BIRD ne tente pas de se connecter Erreur de configuration, protocole désactivé
Connect Connexion TCP en cours Pare-feu bloquant le port 179, mauvaise IP de voisin
Active Connexion TCP échouée, nouvelle tentative Pair injoignable, pare-feu, mauvaise adresse source
OpenSent TCP connecté, en attente de la réponse OPEN Discordance MD5, mauvais ASN côté distant
OpenConfirm OPEN reçu, en attente du KEEPALIVE Rarement observé, transition généralement rapide
Established Session active, échange de routes Fonctionnel

Session bloquée en Connect ou Active

Cela signifie que TCP ne peut pas atteindre le port 179 du pair. Vérifiez :

# Can you reach the peer at all?
ping -c 3 198.51.100.1

# Is port 179 open on the peer?
nc -zv 198.51.100.1 179

# Are your nftables rules blocking outbound?
sudo nft list ruleset | grep 179

# Check BIRD logs
journalctl -u bird --since "5 minutes ago" --no-pager

Causes fréquentes : mauvaise source address dans le bloc BGP, le pair n'a pas encore configuré son côté, ou votre pare-feu bloque les connexions sortantes.

Session bloquée en OpenSent

La connexion TCP fonctionne mais le message BGP OPEN est rejeté. C'est presque toujours une discordance de mot de passe MD5. Vérifiez :

  1. Votre password dans bird.conf correspond exactement à ce que le fournisseur vous a donné (sensible à la casse, attention aux espaces en fin de ligne)
  2. Les deux côtés s'accordent sur l'ASN

Consultez les logs pour les détails :

journalctl -u bird | grep -i "error\|md5\|password"

Préfixe absent de show route export

Votre préfixe existe dans la table de BIRD mais le filtre d'export ne l'accepte pas. Déboguez le filtre :

sudo birdc show route 203.0.113.0/24 all

Contrôlez la source de la route. Si elle indique [device1] ou [direct1] au lieu de [static_v4], la route statique n'est pas configurée correctement. Le filtre d'export fait la correspondance sur la route, elle doit donc provenir du bon protocole.

sudo birdc show route noexport upstream1

Ceci affiche les routes que le filtre a explicitement rejetées. Si votre préfixe apparaît ici, la logique du filtre contient un bug.

Préfixe annoncé mais non visible sur un looking glass

Votre export fonctionne mais la route ne se propage pas. Causes possibles :

  • Pas d'enregistrement ROA : votre upstream ou ses pairs filtrent les routes RPKI-invalid. Publiez d'abord les enregistrements ROA RPKI ROA pour BGP : créer des ROAs, valider les routes dans BIRD2 et FRR
  • Filtrage IRR : votre upstream filtre sur la base des objets IRR (RIPE DB, RADB). Créez ou mettez à jour vos objets route/route6
  • Limite max-prefix : votre upstream peut avoir une limite de préfixes configurée. Contactez-le si vous l'atteignez
  • Délai de propagation : la convergence BGP prend quelques minutes. Attendez 5 à 10 minutes et revérifiez

Lire les logs

BIRD écrit dans le journal système. Pour le dépannage en temps réel :

journalctl -u bird -f

Pour les événements de la dernière heure :

journalctl -u bird --since "1 hour ago" --no-pager

Cherchez les lignes contenant Error, BGP, session ou Received. Elles indiquent exactement ce que BIRD fait et ce qui a mal tourné.

BIRD2 vs BIRD 1.x : notes de migration

Si vous migrez depuis BIRD 1.x, les différences principales sont :

  • Daemon unique : BIRD2 remplace bird et bird6 par un seul processus
  • Syntaxe des canaux : IPv4 et IPv6 sont configurés comme des canaux (channels) à l'intérieur des blocs protocol, pas comme des protocoles séparés
  • Syntaxe des filtres : globalement compatible, mais certaines fonctions ont changé de nom. Consultez la documentation BIRD2 pour la référence complète des filtres
  • Fichier de configuration : l'emplacement par défaut est passé de /etc/bird/bird.conf et /etc/bird/bird6.conf à un seul /etc/bird/bird.conf
  • Socket birdc : un seul socket à /run/bird/bird.ctl au lieu de sockets IPv4/IPv6 séparés

Prochaines étapes

Avec votre session BGP établie et vos préfixes annoncés, plusieurs choses restent à configurer :

Pour le daemon de routage alternatif, voir Configuration BGP avec FRRouting sur un VPS Linux. Pour le parcours BYOIP complet, commencez par BGP et Bring Your Own IP sur un VPS : le guide complet.

Prêt à essayer ?

Lancez des sessions BGP sur votre propre espace IP avec un VPS Virtua.Cloud. →