RIPE database, route object e AS-SET: come si dichiara il proprio routing

Chi annuncia i propri prefissi in BGP scopre presto che la sessione stabilita non basta. Il vicino filtra, e filtra in base a quello che trova nei database di routing pubblici. Se gli oggetti non ci sono o sono sbagliati, il prefisso semplicemente non si propaga. È una delle cause più frequenti di annunci che "partono ma non arrivano".

Cos'è un IRR

Un Internet Routing Registry è un database pubblico dove gli operatori dichiarano quali prefissi intendono annunciare e con quale origine. Il RIPE NCC ne gestisce uno per la propria area di servizio; esistono anche registri indipendenti come RADB, NTTCOM, ALTDB e altri.

La differenza sostanziale è che il database RIPE è autorevole per le risorse allocate dal RIPE: non puoi creare un route object per un prefisso che non ti è stato assegnato, perché l'autorizzazione è vincolata all'oggetto inetnum o inet6num corrispondente. Nei registri indipendenti questo controllo è più debole, ed è il motivo per cui alcuni operatori li considerano meno affidabili.

Gli oggetti che contano

route e route6 dichiarano l'associazione tra un prefisso e l'AS che lo origina. Sono la base di ogni filtro.

route:          80.71.239.0/24
descr:          Velix Connect
origin:         AS199920
mnt-by:         MNT-ESEMPIO
source:         RIPE

route6:         2a13:4d00::/29
descr:          Velix Connect
origin:         AS199920
mnt-by:         MNT-ESEMPIO
source:         RIPE

Un oggetto route copre esattamente il prefisso indicato. Se annunci /24 disaggregati da un /22, servono oggetti per ciascun /24 oppure un oggetto che li comprenda tutti, a seconda di come il filtro dell'upstream espande la gerarchia. Non dare per scontato che l'aggregato copra i più specifici: alcuni generatori di filtri lo fanno, altri no.

aut-num descrive l'AS e, nel campo import/export, la sua policy di routing in linguaggio RPSL. È in gran parte documentale: pochissimi generano filtri leggendo direttamente le policy RPSL, ma un aut-num curato dice all'interlocutore che sai cosa stai facendo.

as-set è l'oggetto che raggruppa il tuo AS e quelli dei tuoi clienti downstream. Serve quando fornisci transito: l'upstream costruisce il filtro espandendo ricorsivamente il tuo as-set e accettando tutti i prefissi originati dagli AS che contiene.

as-set:         AS199920:AS-VELIX
members:        AS199920
members:        AS64500
mnt-by:         MNT-ESEMPIO
source:         RIPE

Il formato gerarchico con prefisso ASN (AS199920:AS-VELIX) è oggi lo standard raccomandato: evita collisioni di nomi tra registri diversi e rende esplicito chi è il proprietario dell'oggetto.

Come vengono costruiti i filtri

L'upstream o l'IX non legge i tuoi oggetti a mano. Usa strumenti come bgpq4 o irrd per generare automaticamente le prefix-list:

# Genera prefix-list IPv4 per un as-set, formato MikroTik
bgpq4 -M -l VELIX-V4 AS199920:AS-VELIX

# Stessa cosa per IPv6
bgpq4 -6 -M -l VELIX-V6 AS199920:AS-VELIX

# Formato JSON, utile per pipeline di automazione
bgpq4 -j -l velix AS199920:AS-VELIX

Da qui discende una conseguenza pratica importante: i filtri vengono rigenerati periodicamente, non in tempo reale. Se crei un route object oggi, l'annuncio può iniziare a propagarsi anche 24-48 ore dopo, a seconda della frequenza con cui l'upstream rigenera. Pianifica gli inserimenti con anticipo rispetto alla data in cui il prefisso deve essere raggiungibile.

IRR e RPKI non sono la stessa cosa

Sono due meccanismi paralleli e complementari:

• IRR documenta l'intenzione di annuncio ed è la base dei filtri prefix-list applicati dai peer
• RPKI fornisce una validazione crittografica dell'associazione prefisso-origine, verificata in tempo reale dal router

Un prefisso può essere RPKI-valid e comunque essere scartato perché manca il route object nell'IRR, e viceversa. Entrambi vanno mantenuti allineati: stessa origine, stessa lunghezza massima coerente con quello che annunci davvero.

Errore classico: si crea la ROA con maxLength /24 su un /22, si annunciano i /24, ma nell'IRR esiste solo il route object del /22. Risultato, metà Internet ti vede e metà no, con un debugging che può durare giorni.

Manutenzione e igiene degli oggetti

Alcune regole che evitano problemi:

• Rimuovi gli oggetti obsoleti. Un route object che punta a un AS con cui non lavori più tiene aperta una porta a dirottamenti involontari.
• Verifica dopo ogni modifica. Un whois -h whois.ripe.net 80.71.239.0/24 conferma quello che il mondo vede davvero, non quello che pensi di aver inserito.
• Tieni l'as-set pulito. Se includi un AS che a sua volta include mezzo Internet nel proprio as-set, l'espansione ricorsiva genera prefix-list enormi e alcuni upstream rifiutano di applicarle.
• Usa un solo source autorevole. Duplicare gli stessi oggetti su RIPE e su registri indipendenti crea incoerenze quando aggiorni solo uno dei due.
• Documenta su PeeringDB. Non è un IRR, ma è il posto dove i potenziali peer cercano il tuo as-set, le tue presenze e le tue policy. Un record incompleto rallenta ogni richiesta di peering.

La documentazione degli oggetti è il lavoro meno visibile di un operatore di rete e allo stesso tempo quello che determina se i pacchetti arrivano. Vale la pena farlo bene la prima volta.