6 min read Advanced 5.9k

BIRD 2 : sessions BGPv4 + BGPv6 vers VeryCloud (AS198825)

Published on May 18, 2026 at 04:01 PM

Configuration complète de BIRD 2.x pour établir une session BGP IPv4 + IPv6 vers le backbone VeryCloud, annoncer tes préfixes, recevoir une default route (ou full table), avec filtres propres et logging structuré.

Introduction

BIRD (BIRD Internet Routing Daemon) est l'un des deux démons de routage open source de référence dans le monde des opérateurs (l'autre étant FRR). BIRD 2.x unifie IPv4 et IPv6 dans un seul démon avec une syntaxe nette, et il tourne en single-thread très efficacement — c'est ce qui fait tourner beaucoup de looking glass et de route-servers IXP (FranceIX inclus).

Ce tuto te montre comment monter une session BGP dual-stack vers VeryCloud (AS198825) une fois que ton tunnel GRE/VXLAN/WireGuard est UP.

Prérequis

Un serveur Linux avec un tunnel UP vers VeryCloud (voir tutos transports)
Le mail technique VeryCloud avec : 169.254.X.1 (peer v4 VeryCloud), 2a0e:XXXX:XXXX::0 (peer v6), MD5 password si choisi
Ton ASN (public ex AS65000 ou privé 64512-65534)
Tes préfixes IPv4 et IPv6 à annoncer
BIRD 2.x installé

Étape 1 : Installer BIRD 2

# Debian / Ubuntu
sudo apt update
sudo apt install -y bird2

# RHEL / Rocky / Alma
sudo dnf install -y bird

# Vérifier
bird --version

💡 BIRD 1.x (legacy) avait un démon séparé v4/v6 (bird et bird6). BIRD 2 unifie tout. Si tu as encore un BIRD 1, migre maintenant.

Étape 2 : Structure de la config

Le fichier principal est /etc/bird/bird.conf. Structure logique :

1. Variables et router-id global
2. Protocols base (device, kernel, direct, static)
3. Templates BGP (optionnel mais propre)
4. Filters (filtres in/out)
5. Sessions BGP (une par peer)

BIRD travaille avec des tables de routage (par défaut master4 et master6) et chaque protocole import/export des routes depuis/vers ces tables avec des filtres.

Étape 3 : Variables et préfixes

En haut de /etc/bird/bird.conf :

log syslog all;
log "/var/log/bird.log" all;

# Ton router-id : une IPv4 unique a toi (loopback par exemple)
router id 192.0.2.1;

# Tes prefixes a annoncer
define MY_PREFIXES_V4 = [
    192.0.2.0/24,
    198.51.100.0/24
];

define MY_PREFIXES_V6 = [
    2001:db8::/32
];

# AS distant : VeryCloud
define VC_ASN = 198825;

⚠️ router id doit être une IPv4 unique sur ta machine. Si tu n'as qu'IPv6, utilise une /32 arbitraire interne (ex : 0.0.0.1, c'est juste un identifiant).

Étape 4 : Protocoles de base

# Apprendre les interfaces locales
protocol device {
    scan time 10;
}

# Lier les routes BGP au kernel
protocol kernel {
    ipv4 {
        export all;
        import none;
    };
    merge paths on;
}

protocol kernel {
    ipv6 {
        export all;
        import none;
    };
    merge paths on;
}

# Routes connectees locales
protocol direct {
    ipv4;
    ipv6;
    interface "lo", "eth0", "wg-vc", "gre-vc", "vxlan-vc";
}

# Routes statiques pour les prefixes que tu annonces
protocol static static_v4 {
    ipv4;
    route 192.0.2.0/24 blackhole;
    route 198.51.100.0/24 blackhole;
}

protocol static static_v6 {
    ipv6;
    route 2001:db8::/32 blackhole;
}

Les routes blackhole sont parfaites pour des préfixes "anchor" : elles existent dans la table BIRD, elles sont annoncées via BGP, mais le trafic sans route spécifique va vers null.

Étape 5 : Filtres

Le filtrage est le cœur de la sécurité BGP.

# Filtre IMPORT : ce qu'on accepte de VeryCloud
filter bgp_in_v4 {
    if net = 0.0.0.0/0 then accept;
    if net.len > 24 then reject;
    if net.len < 8 then reject;
    accept;
}

filter bgp_in_v6 {
    if net = ::/0 then accept;
    if net.len > 48 then reject;
    if net.len < 16 then reject;
    accept;
}

# Filtre EXPORT : ce qu'on annonce a VeryCloud
filter bgp_out_v4 {
    if net ~ MY_PREFIXES_V4 then accept;
    reject;
}

filter bgp_out_v6 {
    if net ~ MY_PREFIXES_V6 then accept;
    reject;
}

💡 Toujours filtrer en sortie. Sans ce filtre, tu risques d'annoncer des préfixes que tu ne possèdes pas — incident BGP majeur.

Étape 6 : Template BGP

template bgp vc_peers {
    local as 65000;
    multihop 2;
    password "MD5_SECRET";
    hold time 90;
    keepalive time 30;
    graceful restart on;
}

local as 65000 → remplace par TON ASN
password → uniquement si VeryCloud t'a fourni un MD5
multihop 2 → utile si le peer-IP n'est pas directement connectée (cas tunnel)

Étape 7 : Sessions BGP

protocol bgp verycloud_v4 from vc_peers {
    description "VeryCloud Transit v4";
    neighbor 169.254.X.1 as VC_ASN;

    ipv4 {
        import filter bgp_in_v4;
        export filter bgp_out_v4;
        next hop self;
        import limit 5000 action restart;
    };
}

protocol bgp verycloud_v6 from vc_peers {
    description "VeryCloud Transit v6";
    neighbor 2a0e:XXXX:XXXX::0 as VC_ASN;

    ipv6 {
        import filter bgp_in_v6;
        export filter bgp_out_v6;
        next hop self;
        import limit 1000 action restart;
    };
}

💡 import limit protège contre une fuite massive du peer. Si VeryCloud t'envoie 500 000 préfixes par accident, BIRD redémarre la session au lieu de saturer ta RAM.

Étape 8 : Démarrer BIRD

# Valider la syntaxe
sudo bird -p -c /etc/bird/bird.conf

# Demarrer
sudo systemctl enable --now bird

# Statut
sudo systemctl status bird

Étape 9 : Vérifier les sessions

sudo birdc show protocols

État attendu :

Name         Proto  Table  State  Since         Info
verycloud_v4 BGP    ---    up     16:45:12      Established
verycloud_v6 BGP    ---    up     16:45:12      Established

Détails :

sudo birdc show protocols all verycloud_v4

Tu verras BGP state: Established, Neighbor address, Neighbor AS, etc.

Étape 10 : Vérifier les routes

# Routes recues
sudo birdc show route protocol verycloud_v4
sudo birdc show route protocol verycloud_v6

# Routes annoncees
sudo birdc show route export verycloud_v4
sudo birdc show route export verycloud_v6

# Table complete
sudo birdc show route

Valider que ta default route est dans le kernel :

ip route show default
ip -6 route show default

Dépannage

Session reste en Active ou Connect

Ping sur la peer-IP du tunnel ? si non, problème de tunnel
TCP/179 firewallé ? sudo iptables -L | grep 179
MD5 pas en place ou mauvais mot de passe → log BGP: Auth failed

Session Established mais aucune route reçue

Filtres trop restrictifs : birdc show route filter bgp_in_v4 pour debug
Côté VeryCloud, vérifie qu'ils ont activé l'envoi des routes

Tes préfixes ne sont pas annoncés

birdc show route export verycloud_v4 : si vide, filtre out trop restrictif
Le protocol static ou protocol direct inclut-il bien tes préfixes ?

Route limit exceeded

Tu reçois plus de routes que prévu — passe en full table ou augmente import limit

MD5 password rejected

BIRD 2 utilise TCP-MD5 kernel. Mot de passe identique octet à octet des deux côtés

Commandes utiles

# Recharger la config sans coupure
sudo birdc configure

# Restart d'une session
sudo birdc restart verycloud_v4

# Disable / Enable
sudo birdc disable verycloud_v4
sudo birdc enable verycloud_v4

# CLI interactif
sudo birdc

# Logs en live
sudo journalctl -u bird -f

Conclusion

BIRD 2 = config déclarative claire, filtres puissants, single binary v4+v6. Une fois la structure de fichier comprise (protocols, filters, tables), tu poses des sessions BGP en quelques minutes. Pour un setup VeryCloud Remote Transit IP, le squelette de ce tuto te couvre 95% des cas.

Pour aller plus loin : RPKI avec routinator + protocol RPKI, BFD pour failover rapide, communautés BGP pour traffic engineering, multipath ECMP entre plusieurs tunnels.