BGP peering policy: come un ISP decide con chi scambiare traffico

Ogni rete autonoma su Internet — identificata da un ASN — non scambia traffico con chiunque a caso. Le decisioni su chi annunciare quali rotte, e quali rotte accettare, sono codificate in una peering policy. È il documento (formale o di fatto) che governa il routing BGP di un operatore e ha impatto diretto su latenza, costi e resilienza della rete.

Transit, peering pubblico, peering privato

Le relazioni BGP tra reti si riducono a tre tipi, con economie diverse:

• Transit (upstream): paghi un operatore più grande perché ti porti l'intera tabella di routing globale (full table, ~950k prefissi IPv4). È il modo più semplice per raggiungere "tutto Internet", ma è anche il più costoso al megabit.
• Peering pubblico: ti connetti a un Internet Exchange (IXP) e scambi traffico direttamente con le altre reti presenti sullo stesso switch fabric, tipicamente a costo marginale zero per il traffico (paghi solo la porta e la membership).
• Peering privato (PNI): un cross-connect dedicato punto-punto con un'altra rete, usato quando i volumi tra due AS giustificano una connessione fisica separata rispetto all'IXP.

La policy stabilisce quando passare da una modalità all'altra: tipicamente un prefisso si raggiunge via peering se disponibile (gratis e più diretto), altrimenti via transit (a pagamento).

La regola del valley-free routing

Il principio che sta alla base di quasi tutte le policy è il valley-free routing, derivato dalle relazioni economiche (modello Gao-Rexford):

• Le rotte imparate da un cliente si annunciano a tutti (clienti, peer, upstream).
• Le rotte imparate da un peer si annunciano solo ai propri clienti.
• Le rotte imparate da un upstream si annunciano solo ai propri clienti.

In pratica: non si fa mai da "tramite gratuito" tra due reti che dovrebbero pagarsi il transit. Annunciare a un peer le rotte di un altro peer significherebbe trasportare traffico altrui senza compenso. Questa logica si implementa con le BGP communities e i filtri in ingresso/uscita.

Criteri tipici di una peering policy

Un operatore che pubblica i propri requisiti (es. su PeeringDB) di solito specifica:

• Politica di peering: open (peering con chiunque lo richieda), selective (valutazione caso per caso) o restrictive (solo grandi reti).
• Requisiti di traffico: rapporto in/out massimo (es. 2:1), volume minimo aggregato.
• Presenza geografica: numero minimo di IXP o facility comuni.
• Requisiti tecnici: MD5 opzionale, MANRS compliance, filtri prefissi via IRR/RPKI, max-prefix limit.
• NOC 24/7 raggiungibile e dati PeeringDB aggiornati.

Per un ISP regionale come Velix, una policy open su un IXP italiano (es. peering con reti locali e CDN) abbatte la latenza verso i contenuti più richiesti e riduce la dipendenza dal transit a pagamento.

Filtri e sicurezza: RPKI e max-prefix

Una policy moderna non riguarda solo l'economia ma anche la sicurezza del routing:

• RPKI ROV (Route Origin Validation): si scartano gli annunci con origine non valida rispetto ai ROA pubblicati, mitigando i route hijack.
• Max-prefix limit: ogni sessione BGP ha un tetto di prefissi accettabili; superarlo (segno di un leak o misconfigurazione del peer) chiude la sessione invece di propagare l'errore.
• Prefix filtering via IRR: si accettano solo i prefissi che il peer ha registrato nel proprio AS-SET nei database IRR.
• MANRS: framework di best practice che molti IXP richiedono come baseline.

Local preference e ingegneria del traffico

Dentro la propria rete, l'operatore usa la local-preference per stabilire la priorità delle uscite:

• Peering: local-pref alta (preferito, gratis e diretto).
• Transit: local-pref media.
• Backup/transit secondario: local-pref bassa.

In ingresso, per influenzare da dove arriva il traffico, si usano AS-path prepending, annunci di prefissi più specifici e BGP communities concordate con l'upstream. Sono leve grezze: il prepending non garantisce il risultato perché ogni rete a monte applica le proprie policy.

In sintesi

Una peering policy ben fatta bilancia tre obiettivi: ridurre i costi di transit spostando traffico sul peering, abbassare la latenza accorciando l'AS-path verso le destinazioni più frequenti, e proteggere la rete da leak e hijack con RPKI e filtri rigorosi. Non è un documento statico: si rivede man mano che cambiano i flussi di traffico e la presenza dell'operatore negli exchange.