Configurazione BGP con BIRD2 su VPS Linux

15 min di lettura·Matthieu|

Installa BIRD2 su Debian 12 o Ubuntu 24.04 e configura una sessione BGP per annunciare i tuoi prefissi IP. Dual-stack, filtri di esportazione, interfacce dummy persistenti, regole nftables e verifica con birdc.

BIRD e il demone di routing mantenuto da CZ.NIC. La versione 2 ha unificato IPv4 e IPv6 in un singolo demone, sostituendo l'architettura divisa BIRD/BIRD6 della 1.x, e ha introdotto un linguaggio di filtri avanzato. Questa guida copre l'installazione di BIRD2 su un VPS Linux, la configurazione di una sessione BGP con il provider upstream, l'annuncio dei propri prefissi IP e la verifica del funzionamento.

Tutti gli esempi sono dual-stack (IPv4 + IPv6). Sostituisci gli ASN, gli IP e i prefissi di esempio con i tuoi valori reali.

Cosa serve prima di configurare BIRD2 per BGP?

Prima di toccare bird.conf, servono un ASN, spazio IP allocato e un provider che offra sessioni BGP sul VPS. Senza tutti e tre, BIRD2 non ha nulla da annunciare e nessun peer con cui parlare.

Raccogli questi dati dal provider o dall'allocazione RIR:

Elemento Valore di esempio Dove ottenerlo
Il tuo ASN AS65400 RIPE NCC, ARIN o il tuo LIR
Il tuo prefisso IPv4 203.0.113.0/24 Allocazione RIR o assegnazione PA dal provider
Il tuo prefisso IPv6 2001:db8:1000::/48 Allocazione RIR o assegnazione PA dal provider
ASN upstream AS64496 Dettagli sessione BGP del provider
IPv4 peer upstream 198.51.100.1 Dettagli sessione BGP del provider
IPv6 peer upstream 2001:db8::1 Dettagli sessione BGP del provider
Il tuo IPv4 di peering 198.51.100.2 Dettagli sessione BGP del provider
Il tuo IPv6 di peering 2001:db8::2 Dettagli sessione BGP del provider
Password MD5 (shared secret) Concordata con il provider

Servono anche record ROA pubblicati per i tuoi prefissi prima che le rotte passino la validazione RPKI presso le reti downstream. Vedi per quella configurazione.

Assicurati che il provider abbia aggiunto i tuoi prefissi ai filtri IRR. Senza quello, gli annunci verranno filtrati anche se la sessione BGP si stabilisce.

Un VPS con almeno 1 GB di RAM e sufficiente per BIRD2 con una tabella completa (oltre 1 milione di rotte IPv4). Se accetti solo una default route dall'upstream, il consumo di memoria resta sotto i 100 MB.

Come installare BIRD2 su Debian 12 e Ubuntu 24.04?

BIRD2 e disponibile nei repository predefiniti di entrambe le distribuzioni. Debian 12 include la versione 2.0.12, Ubuntu 24.04 la 2.14. Entrambe funzionano per BGP base, ma il repository ufficiale CZ.NIC fornisce BIRD 2.18 (rilasciato a gennaio 2026) con supporto BGP dynamic unnumbered, miglioramenti delle prestazioni e bug fix recenti. Usa il repository CZ.NIC per i deployment in produzione.

Nota: CZ.NIC pubblica i pacchetti BIRD2 con il nome progetto bird2. Non confonderlo con il progetto bird (che copre solo Debian) o bird3 (BIRD 3.x).

Installazione dal repository CZ.NIC (consigliata)

Aggiungi il repository ufficiale, poi installa:

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

Importa la chiave GPG di CZ.NIC:

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

Aggiungi il repository. Su 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

Su 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

Installa BIRD2:

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

Installazione dai repository predefiniti

Se preferisci il pacchetto della distribuzione:

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

Verifica dell'installazione

bird --version

Output atteso (repository CZ.NIC):

BIRD version 2.18

Controlla che il servizio sia in esecuzione:

sudo systemctl status bird

BIRD si avvia automaticamente dopo l'installazione. La configurazione predefinita in /etc/bird/bird.conf e uno scheletro. La sostituirai interamente nella sezione successiva.

Come e strutturato bird.conf per BGP?

Un bird.conf pronto per BGP ha cinque blocchi: impostazioni globali e quattro sezioni protocol (device, direct, kernel, bgp). Ogni protocol funziona in modo indipendente e comunica attraverso le tabelle di routing.

Ecco il bird.conf completo per un setup BGP dual-stack. Leggilo prima, poi le sezioni seguenti spiegano ogni blocco.

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

Imposta i permessi sul file di configurazione. Solo root e l'utente bird devono avere accesso:

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

Verifica i permessi:

ls -la /etc/bird/bird.conf

Output atteso:

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

Impostazioni globali

log syslog all;
router id 198.51.100.2;

router id deve essere un indirizzo IPv4 globalmente univoco. Usa uno dei tuoi IP assegnati. BIRD puo rilevarlo automaticamente dalle interfacce, ma specificarlo esplicitamente e preferibile.

log syslog all invia tutti i messaggi di log al journal di sistema. Leggili con journalctl -u bird -f. Se serve un output dettagliato durante il debug di un protocol specifico, aggiungi debug protocols all; temporaneamente. Rimuovilo quando la sessione funziona. Il logging a livello debug genera un volume elevato e puo riempire lo storage del journal.

Protocol device

protocol device {
    scan time 10;
}

Monitora i cambiamenti di stato delle interfacce ogni 10 secondi. Obbligatorio. Senza questo blocco, BIRD non sa quando le interfacce vanno su o giu.

Protocol direct

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

Importa le rotte connesse dalle interfacce elencate. BIRD ne ha bisogno per la risoluzione del next-hop. Elenca solo le interfacce coinvolte nel setup BGP.

Protocol kernel

Servono due blocchi kernel protocol: uno per IPv4, uno per IPv6. Ciascuno sincronizza la propria address family tra la tabella di routing di BIRD e la tabella del kernel Linux.

merge paths on abilita l'ECMP se hai piu upstream. learn importa le rotte kernel esistenti in BIRD.

Cosa fa il blocco protocol BGP?

Il blocco protocol bgp definisce una sessione di peering con un neighbor. Specifica chi sei (local ... as), con chi fai peering (neighbor ... as), l'autenticazione (password) e quali rotte scambiare (blocchi channel).

Campi principali:

Direttiva Scopo
local <ip> as <ASN> Il tuo IP e ASN di peering
neighbor <ip> as <ASN> IP e ASN dell'upstream
source address <ip> IP sorgente per la connessione TCP
hold time 90 Secondi prima di dichiarare il peer morto (3x keepalive)
keepalive time 30 Intervallo tra messaggi keepalive
password "..." Autenticazione MD5 (RFC 2385)

L'autenticazione MD5 protegge la sessione BGP da TCP reset spoofati e attacchi di injection. Entrambi i lati devono configurare la stessa password. Chiedi al provider il shared secret.

Come configurare i canali dual-stack IPv4 e IPv6?

BIRD2 gestisce IPv4 e IPv6 come canali separati all'interno dello stesso blocco protocol. Ogni canale ha la propria policy di 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 accetta tutte le rotte dall'upstream. In produzione, dovresti filtrare anche gli import. Vedi per esempi di filtri di importazione.

next hop self riscrive l'attributo next-hop con il tuo IP di peering. Necessario quando l'upstream si aspetta che il traffico passi attraverso il tuo indirizzo, che e la configurazione standard su un VPS.

Se il provider usa sessioni BGP separate per IPv4 e IPv6 (IP neighbor diversi per address family), dividile in due blocchi protocol bgp separati.

Come scrivere filtri di esportazione per annunciare solo i propri prefissi?

I filtri di esportazione controllano quali rotte BIRD invia all'upstream. Un filtro di esportazione mal configurato puo causare un leak di rotte che non possiedi, il che fara chiudere la tua sessione e potenzialmente ricevere una telefonata dal NOC dell'upstream.

Il filtro nella configurazione precedente usa un semplice prefix match:

define OWN_V4_PREFIX = 203.0.113.0/24;

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

Accetta solo l'esatto /24. Tutto il resto viene rifiutato. Il reject finale e il default deny.

Per prefissi multipli, usa 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'operatore ~ fa il match su un prefix set. Supporta anche la notazione a range:

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

{24,24} limita il match esattamente al /24. Usa {24,28} per permettere anche la deaggregazione fino a /28 se devi annunciare more-specifics per traffic engineering.

Per IPv6, lo stesso pattern si applica:

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

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

Mantieni sempre i filtri di esportazione il piu stretti possibile. Annuncia solo cio che possiedi, alle lunghezze di prefisso esatte che intendi. Un reject mancante alla fine del filtro fara usare a BIRD l'azione predefinita del canale, che potrebbe essere accept. Termina sempre con un reject esplicito.

Puoi testare il filtro senza applicarlo:

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

Restituisce TRUE o FALSE e aiuta a fare debug della logica del filtro prima di un reload della configurazione.

Come creare un'interfaccia dummy persistente per l'origination dei prefissi?

BGP annuncia prefissi che esistono nella tabella di routing. Serve un'interfaccia con il prefisso assegnato affinche BIRD possa originare la rotta. Un'interfaccia dummy serve a questo scopo: e sempre attiva, non ha link fisico e sopravvive ai riavvii se configurata tramite systemd-networkd.

Comandi ip link add effimeri vengono persi al riavvio. Usa systemd-networkd.

Crea il file .netdev

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

Crea il file .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

Assegna un singolo /32 (o /128 per IPv6) dal prefisso allocato all'interfaccia dummy. Questo indirizzo non deve essere raggiungibile dall'esterno. Esiste solo affinche BIRD abbia una rotta connessa per il prefisso.

Applica e verifica

sudo systemctl restart systemd-networkd

Attendi qualche secondo, poi controlla:

ip addr show dummy0

Output atteso:

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

Lo state UNKNOWN per un'interfaccia dummy e normale. Significa che il livello di collegamento non ha un carrier fisico da tracciare, ma l'interfaccia e UP e inoltra traffico. L'indirizzo MAC viene generato casualmente da systemd-networkd e sara diverso sul tuo sistema.

Se usi ifupdown invece di systemd-networkd (controlla con networkctl status), potrebbe essere necessario abilitare prima systemd-networkd:

sudo systemctl enable --now systemd-networkd

Verifica che i file siano presenti per il prossimo riavvio:

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

Come proteggere BGP con regole firewall nftables?

BGP gira sulla porta TCP 179. Senza regole firewall, qualsiasi host su internet puo tentare di aprire una sessione BGP con il tuo router. Scanner automatici trovano la porta 179 aperta entro poche ore dalla messa online di un VPS. Limita la porta 179 ai soli IP dei tuoi peer.

nftables potrebbe non essere installato di default su Ubuntu 24.04. Installalo prima:

sudo apt-get -y install nftables

Crea il ruleset 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

Aggiungi altri IP di peer ai set man mano che aggiungi upstream. I named set permettono di aggiornare le liste di peer senza riscrivere le regole.

Integrazione con la configurazione nftables esistente

Se hai gia /etc/nftables.conf, includi le regole BGP:

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

Se non hai ancora configurato nftables, crea la directory e carica la configurazione:

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

enable --now avvia nftables immediatamente e garantisce il caricamento ad ogni boot.

Applica le regole:

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

Verifica le regole

sudo nft list table inet bgp_filter

Output atteso:

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 normalizza priority 0 a priority filter e rimuove i commenti. Questo e il comportamento atteso.

Verifica che la regola funzioni controllando lo stato delle connessioni. Dal VPS:

sudo nft list ruleset | grep -c "179"

Dovrebbe restituire un conteggio corrispondente al numero di regole sulla porta 179 che hai creato.

Conferma inoltre che il traffico BGP non sia bloccato tra te e il tuo peer. Le regole precedenti riguardano solo le connessioni in ingresso. BIRD avvia connessioni in uscita verso il peer, gestite dall'entry conntrack established/related. Se hai una policy in uscita restrittiva, aggiungi:

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

Questa regola dovrebbe gia essere nel tuo ruleset firewall di base. Se non c'e, aggiungila prima delle regole BGP.

Come applicare la configurazione BIRD2?

Prima di caricare una nuova configurazione, validala:

sudo birdc configure check

Output atteso:

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

Se ci sono errori di sintassi, BIRD riporta il numero di riga e il problema. Correggi e ricontrolla.

Applica la configurazione:

sudo birdc configure

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

Potresti vedere Reconfiguration in progress invece di Reconfigured se BIRD sta ancora elaborando i cambiamenti di protocol (come lo stabilimento di una nuova sessione BGP). Entrambi sono normali.

BIRD applica la nuova configurazione senza riavvio. Le sessioni esistenti eseguono una soft reconfiguration quando possibile. Se hai cambiato il neighbor IP o il local AS, BIRD riavvia automaticamente il protocol interessato.

Per modifiche alla configurazione che non devono interrompere le sessioni attive (modifiche ai filtri, aggiunta di rotte statiche), usa:

sudo birdc reload upstream1

Questo riapplica i filtri import/export alle rotte esistenti senza abbattere la sessione TCP.

Come verificare la sessione BGP e gli annunci di rotte?

Dopo aver applicato la configurazione, usa birdc per verificare che la sessione sia stabilita e le rotte vengano annunciate. Questi comandi sono i tuoi strumenti di debug primari.

Comando Cosa mostra Quando usarlo
show protocols Riepilogo stato protocol (Established, Active, ecc.) Primo controllo dopo modifica config
show protocols all upstream1 Dettagli completi sessione, contatori, timer Debug di una sessione specifica
show route Tutte le rotte nella tabella BIRD Verifica rotte ricevute e statiche
show route export upstream1 Rotte inviate all'upstream Conferma annuncio dei prefissi
show route for 203.0.113.0/24 Miglior rotta per un prefisso specifico Tracciare la selezione del percorso
show route protocol static_v4 Rotte da un protocol specifico Verificare caricamento rotte statiche

Controlla lo stato della sessione

sudo birdc show protocols

Output atteso quando funziona:

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

Lo stato Established significa che la sessione BGP e attiva e le rotte possono essere scambiate. Qualsiasi altro stato indica un problema.

Controlla le rotte esportate

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

Entrambi i prefissi IPv4 e IPv6 dovrebbero comparire qui. Se un prefisso manca, il filtro di esportazione lo sta rifiutando.

Controlla i dettagli completi della sessione

sudo birdc show protocols all upstream1

Cerca la riga Routes::

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

Il conteggio exported dovrebbe corrispondere al numero di prefissi che intendi annunciare.

Verifica dall'esterno

Usa un looking glass pubblico per confermare che il tuo prefisso sia visibile su internet. NLNOG Looking Glass o PeeringDB possono aiutare. Cerca il tuo prefisso e verifica:

  • L'origin AS corrisponde al tuo
  • L'AS path passa attraverso il tuo upstream
  • Non appare nessuno stato RPKI invalid

Controlla anche dalla tabella di routing del kernel:

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

Dovresti vedere rotte che puntano all'interfaccia dummy0.

Come risolvere i problemi comuni di BIRD2 BGP?

La maggior parte dei problemi BGP rientra in poche categorie. Controllale in ordine.

Riferimento stati sessione BGP

Stato Significato Cosa verificare
Idle BIRD non sta tentando di connettersi Errore di configurazione, protocol disabilitato
Connect Connessione TCP in corso Firewall che blocca la porta 179, IP neighbor errato
Active Connessione TCP fallita, nuovo tentativo Peer irraggiungibile, firewall, indirizzo sorgente errato
OpenSent TCP connesso, in attesa della risposta OPEN Mismatch MD5, ASN errato sul lato remoto
OpenConfirm OPEN ricevuto, in attesa del KEEPALIVE Raramente visibile, di solito transita rapidamente
Established Sessione attiva, scambio rotte Funzionante

Sessione bloccata su Connect o Active

Significa che TCP non riesce a raggiungere la porta 179 sul peer. Controlla:

# 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

Cause comuni: source address errato nel blocco BGP, il peer non ha ancora configurato il suo lato, o il firewall blocca le connessioni in uscita.

Sessione bloccata su OpenSent

La connessione TCP funziona ma il messaggio BGP OPEN viene rifiutato. Quasi sempre si tratta di un mismatch della password MD5. Verifica:

  1. La password in bird.conf corrisponde esattamente a quella fornita dal provider (case-sensitive, attenzione agli spazi finali)
  2. Entrambi i lati concordano sull'ASN

Controlla i log per i dettagli:

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

Prefisso non visibile in show route export

Il prefisso esiste nella tabella di BIRD ma il filtro di esportazione non lo accetta. Fai debug del filtro:

sudo birdc show route 203.0.113.0/24 all

Controlla la sorgente della rotta. Se dice [device1] o [direct1] invece di [static_v4], la rotta statica non e configurata correttamente. Il filtro di esportazione fa match sulla rotta, quindi deve provenire dal protocol giusto.

sudo birdc show route noexport upstream1

Questo mostra le rotte che il filtro ha esplicitamente rifiutato. Se il tuo prefisso appare qui, la logica del filtro ha un bug.

Prefisso annunciato ma non visibile sul looking glass

L'esportazione funziona ma la rotta non si propaga. Possibili cause:

  • Nessun record ROA: Il tuo upstream o i suoi peer filtrano le rotte RPKI-invalid. Pubblica prima i record ROA
  • Filtri IRR: Il tuo upstream filtra in base agli oggetti IRR (RIPE DB, RADB). Crea o aggiorna i tuoi oggetti route/route6
  • Limite max-prefix: Il tuo upstream potrebbe avere un limite di prefissi configurato. Contattalo se lo stai raggiungendo
  • Ritardo di propagazione: La convergenza BGP richiede minuti. Attendi 5-10 minuti e ricontrolla

Leggi i log

BIRD scrive nel journal di sistema. Per il troubleshooting in tempo reale:

journalctl -u bird -f

Per gli eventi dell'ultima ora:

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

Cerca righe contenenti Error, BGP, session o Received. Indicano esattamente cosa sta facendo BIRD e cosa e andato storto.

BIRD2 vs BIRD 1.x: note di migrazione

Se stai migrando da BIRD 1.x, le differenze principali sono:

  • Singolo demone: BIRD2 sostituisce sia bird che bird6 con un singolo processo
  • Sintassi dei canali: IPv4 e IPv6 sono configurati come canali dentro i blocchi protocol, non come protocol separati
  • Sintassi dei filtri: Principalmente compatibile, ma alcune funzioni hanno cambiato nome. Consulta la documentazione BIRD2 per il riferimento completo dei filtri
  • File di configurazione: Il percorso predefinito e cambiato da /etc/bird/bird.conf e /etc/bird/bird6.conf a un singolo /etc/bird/bird.conf
  • Socket birdc: Singolo socket in /run/bird/bird.ctl invece di socket separati IPv4/IPv6

Prossimi passi

Con la sessione BGP stabilita e i prefissi annunciati, ci sono diversi aspetti da configurare:

  • Validazione RPKI: Configura RTR per validare le rotte in ingresso contro i dati ROA
  • Filtri di importazione: Filtra le rotte in ingresso per prevenire route leak e hijack
  • Upstream multipli: Aggiungi un secondo blocco protocol bgp per la ridondanza. Usa preference per impostare primario/backup
  • BFD: Abilita il Bidirectional Forwarding Detection per failover sub-second tra gli upstream
  • Monitoraggio: Esporta le metriche BIRD verso Prometheus con bird_exporter

Per il demone di routing alternativo, vedi . Per il percorso BYOIP completo, parti dalla guida BYOIP.

Copyright 2026 Virtua.Cloud. Tutti i diritti riservati. Questo contenuto e un'opera originale del team Virtua.Cloud. La riproduzione, ripubblicazione o redistribuzione senza autorizzazione scritta e vietata.

Pronto a provare?

Distribuisci il tuo server in pochi secondi. Linux, Windows o FreeBSD.

Vedi piani VPS
Configurazione BGP BIRD2 su VPS Linux (Dual-Stack)