Il traffico fra Italia e Francia passa da Francoforte? Interconnessione diretta e punti di scambio

Il 16 luglio 2026 ielo, operatore infrastrutturale francese, e MIX, il principale punto di scambio internet italiano, hanno annunciato una partnership. ielo si attesta sul campus di Via Caldera a Milano, dove il MIX è presente, con capacità attive che collegano Lione, Nizza e Milano, e offre ai propri partner l’accesso all’ecosistema MIX in remote peering, cioè senza aprire una presenza locale in Italia.

L’obiettivo dichiarato, nelle parole di Hélios de Creisquer, direttore tecnico di ielo, è «creare interconnessioni più dirette fra Francia e Italia, senza dipendere dagli hub del Nord Europa». Mattia Flena, direttore commerciale del MIX, lo legge dal lato italiano: ISP e carrier internazionali raggiungono le reti italiane senza doversi installare qui.

Quello che nei comunicati non c’è: nessuna capacità per tratta, nessuna latenza, nessuna data di attivazione percorso per percorso. L’unica cifra è il picco di traffico del MIX, dichiarato attorno a 3,7 Tb/s. Un obiettivo dichiarato non è una misura, e per chi firma un capitolato la differenza è tutta lì.

Perché il traffico prende la strada lunga

La geografia non instrada. Instradano gli accordi. Due reti si scambiano traffico dove hanno comprato una porta e dove qualcuno ha accettato di parlare con loro: se il punto di incontro più conveniente è un carrier hotel di Francoforte, Amsterdam o Londra, il pacchetto ci va, anche quando le due reti distano trecento chilometri. In gergo si chiama tromboning. Non è un errore di configurazione: è massa critica formatasi altrove — dove ci sono più reti conviene andare, e più gente arriva più conviene.

La strada lunga si paga due volte. In ritardo di propagazione, che è fisica e si misura. E in numero di soggetti che toccano il pacchetto, che è contrattuale e si scopre quando qualcosa si rompe. Se poi il vostro traffico verso una controparte francese passi davvero dal Nord Europa, quello non lo sapete finché non lo misurate: vale per la vostra rete, non per «l’Italia».

Il remote peering non sposta la fibra

Il remote peering merita una definizione precisa, perché è dove si formano i malintesi più costosi. Consiste nell’affacciarsi alla LAN di peering di un punto di scambio attraverso la porta di un terzo, invece che con un proprio apparato in sala. La sessione BGP risulta «a Milano»; il router che la termina può stare a Lione.

Il vantaggio è di accesso, ed è reale: si raggiunge un ecosistema di reti senza aprire un punto di presenza. Ma va comprato per quello che è. Una sessione locale non garantisce una latenza locale, né un percorso corto: la fibra sta dove stava prima. Due domande al fornitore, per iscritto: dove termina fisicamente la mia porta, e che percorso fa il traffico fra quel punto e la LAN di peering. Se la risposta è generica, quella tratta non è nel vostro capitolato.

Le sessioni non sono tutte uguali

Su un punto di scambio si parla in due modi. Bilaterale: una sessione BGP per ciascuna controparte. Multilaterale: una sessione verso il route server, intermediario verso tutti gli altri clienti, modello specificato dalla RFC 7947.

La RFC che serve a chi scrive un capitolato è però la RFC 7948, Internet Exchange BGP Route Server Operations, perché elenca gli effetti collaterali. Il primo si chiama path hiding: quando le politiche di due clienti sono in conflitto il route server può nascondere un percorso, e il cliente riceve informazioni di raggiungibilità incomplete. Non è un guasto: è il funzionamento nominale.

Conseguenza pratica: la destinazione resta raggiungibile, ma per un’altra strada — di norma il transito a pagamento — con un’altra latenza e un altro costo. È il difetto più difficile da vedere in esercizio, perché nessun allarme scatta. Se un servizio è venduto come «peering al MIX», nel capitolato va scritto se è via route server, bilaterale o entrambi, e va chiesto che cosa succede quando il percorso preferito sparisce. La stessa RFC raccomanda più route server per dominio di livello 2 con configurazione equivalente, limiti di prefissi in ingresso per cliente e verifica del NEXT_HOP annunciato: tre requisiti che si scrivono e si controllano.

«Due percorsi diversi»: come si verifica

Il vocabolario esiste già, e va usato. La RFC 4202, al paragrafo 2.3, definisce lo shared risk link group: un insieme di collegamenti costituisce un SRLG «se condividono una risorsa il cui guasto può interessare tutti i collegamenti dell’insieme». Tradotto: «percorsi diversi» è un’affermazione su rischi condivisi, non su nomi di città. Due tratte che si chiamano Milano-Lione e Milano-Nizza possono condividere un giunto in un pozzetto, e allora non sono due.

Sette cose da chiedere prima di firmare.

Il tracciato reale delle due tratte, in forma consultabile (as-built, KMZ), non gli estremi.
Una dichiarazione SRLG esplicita: quali risorse condividono i due percorsi — cavidotto, attraversamento, muffola, camera, montante, sala, alimentazione, apparato.
I cross-connect uno per uno: quanti, in quale sala, in quale rack, con quale percorso della bretella dentro l’edificio. Due permute nello stesso pettine sono una permuta sola.
Ingressi in edificio distinti, su lati opposti, con adduzioni separate fino alla strada.
Le sessioni di peering: quali, con chi, via route server o bilaterali, e il comportamento previsto alla caduta di ciascuna.
La diversità come vincolo continuativo, non come fotografia. Dopo una riparazione il percorso cambia — bretella provvisoria, bypass, nuovo giunto — e la diversità sparisce senza che nessuno lo comunichi. Serve una clausola di notifica per ogni ri-instradamento che modifichi gli SRLG dichiarati.
La riverifica periodica, con esito verbalizzato. La diversità si ricollauda; non si certifica una volta e basta.

Misurare, invece di crederci

Tre strumenti pubblici, nessuno dei quali basta da solo. Il pavimento di latenza: il minimo RTT osservato su una lunga serie di misure dipende dalla lunghezza della fibra, non dal carico, e se sta molto sopra il minimo compatibile con la distanza il traffico sta facendo un giro. I looking glass degli operatori, per vedere l’instradamento dal loro punto di vista invece che dal vostro. I registri pubblici delle presenze agli IXP — PeeringDB e l’IXPDB di Euro-IX — per verificare che una presenza dichiarata in gara esista davvero. Insieme non provano il tracciato: dicono se la storia che vi hanno raccontato sta in piedi.

È il rovescio del lavoro fatto sui cavi sottomarini: lì il tema era il guasto fisico, qui non si rompe niente e il problema è dove passa il pacchetto quando tutto funziona.

Che cosa fare adesso

Misurate il pavimento di latenza verso le tre o quattro destinazioni che contano per la produzione: prima di cambiare fornitore, sapere dove siete.
Se avete sedi collegate in DWDM o CWDM, verificate che le due direzioni dell’anello non condividano l’ultimo chilometro; nei data center, fatevi dare la mappa dei cross-connect.

Il punto.

Un annuncio di interconnessione non cambia il vostro instradamento: cambia le opzioni. Quale opzione convenga si decide con una misura e con un capitolato scritto bene, non con la mappa dell’Europa. Per questo, quando rivediamo un capitolato, la diversità di percorso è una voce con requisiti verificabili — tracciato, SRLG, cross-connect, riverifica — e non un aggettivo. Sul dove far girare i sistemi che quel traffico serve abbiamo scritto a parte; le misure e i dati che raccogliamo restano dove servono a voi, on‑premise nel vostro ambiente oppure su cloud dedicato con VPN dedicata e data center in Italia, in locali presidiati direttamente da noi.

Avete due collegamenti «ridondanti» che non avete mai verificato, o un capitolato di interconnessione da scrivere? Parlatene con un tecnico.