Does Italy-France traffic really go via Frankfurt? Direct interconnection and exchange points

On 16 July 2026 ielo, a French infrastructure operator, and MIX, Italy’s main internet exchange point, announced a partnership. ielo has established itself on the Via Caldera campus in Milan, where MIX is present, with active capacity linking Lyon, Nice and Milan, and offers its partners access to the MIX ecosystem through remote peering — that is, without opening a local presence in Italy.

The stated aim, in the words of Hélios de Creisquer, ielo’s technical director, is to “create more direct interconnections between France and Italy, without depending on Northern European hubs”. Mattia Flena, MIX’s commercial director, reads it from the Italian side: international ISPs and carriers reach Italian networks without deploying here.

What the releases do not contain: no per-route capacity, no latency, no activation date route by route. The only figure is MIX’s declared traffic peak, around 3.7 Tb/s. A stated aim is not a measurement, and for anyone signing a specification that is the whole difference.

Why traffic takes the long way round

Geography does not route. Agreements route. Two networks exchange traffic where they have bought a port and where somebody has agreed to talk to them: if the cheapest meeting point is a carrier hotel in Frankfurt, Amsterdam or London, the packet goes there, even when the two networks are three hundred kilometres apart. The trade calls it tromboning. It is not a misconfiguration: it is critical mass that formed somewhere else — where there are more networks it pays to go, and the more that arrive the more it pays.

The long way round is paid for twice. In propagation delay, which is physics and can be measured. And in the number of parties that touch the packet, which is contractual and only surfaces when something breaks. Whether your own traffic towards a French counterparty really goes through Northern Europe is something you do not know until you measure it: that applies to your network, not to “Italy”.

Remote peering does not move the fibre

Remote peering deserves a precise definition, because this is where the most expensive misunderstandings are made. It means facing the peering LAN of an exchange point through a third party’s port, rather than with your own equipment in the room. The BGP session shows up “in Milan”; the router terminating it may sit in Lyon.

The benefit is one of access, and it is real: you reach an ecosystem of networks without opening a point of presence. But buy it for what it is. A local session does not guarantee local latency, nor a short path: the fibre is exactly where it was. Two questions for the supplier, in writing: where does my port physically terminate, and what path does traffic take between that point and the peering LAN. If the answer is vague, that section is not in your specification.

Sessions are not all the same

There are two ways to speak at an exchange point. Bilateral: one BGP session per counterparty. Multilateral: one session towards the route server, which brokers towards all other clients — the model specified in RFC 7947.

The RFC that matters to whoever writes the specification, though, is RFC 7948, Internet Exchange BGP Route Server Operations, because it lists the side effects. The first is called path hiding: where two clients’ policies conflict, the route server may mask a path, and the client receives incomplete reachability information. This is not a fault; it is nominal behaviour.

The practical consequence: the destination stays reachable, but by another road — usually paid transit — with different latency and different cost. It is the hardest defect to spot in service, because no alarm fires. If a service is sold as “peering at MIX”, the specification must state whether it is via route server, bilateral or both, and must ask what happens when the preferred path disappears. The same RFC recommends multiple route servers per layer 2 domain with equivalent configuration, per-client inbound prefix limits, and validation of the announced NEXT_HOP: three requirements you can write down and check.

“Two different paths”: how to verify it

The vocabulary already exists and should be used. RFC 4202, at section 2.3, defines the shared risk link group: a set of links constitutes an SRLG “if they share a resource whose failure may affect all links in the set”. In plain terms: “different paths” is a claim about shared risk, not about city names. Two sections labelled Milan-Lyon and Milan-Nice can share one splice in one chamber — and then they are not two.

Seven things to ask before signing.

The real route of both sections, in usable form (as-built, KMZ), not just the endpoints.
An explicit SRLG declaration: which resources the two paths share — duct, crossing, closure, chamber, riser, room, power feed, equipment.
The cross-connects one by one: how many, in which room, in which rack, and the path of the patch cord inside the building. Two patches in the same comb are one patch.
Separate building entries, on opposite sides, with separate lead-ins to the street.
The peering sessions: which ones, with whom, via route server or bilateral, and the expected behaviour when each drops.
Diversity as a standing constraint, not a snapshot. After a repair the path changes — a temporary cord, a bypass, a new splice — and diversity vanishes with nobody reporting it. You need a notification clause for every re-route that alters the declared SRLGs.
Periodic re-verification, with a recorded result. Diversity is re-tested; it is not certified once and forgotten.

Measure it, instead of believing it

Three public tools, none of which is enough on its own. The latency floor: the minimum RTT observed over a long series of measurements depends on fibre length, not on load, and if it sits well above the minimum compatible with the distance, the traffic is going round. Operators’ looking glasses, to see routing from their point of view rather than yours. Public IXP presence registries — PeeringDB and Euro-IX’s IXPDB — to check that a presence claimed in a tender actually exists. Together they do not prove the route: they tell you whether the story you were told holds up.

This is the mirror image of the work done on submarine cables: there the subject was physical failure; here nothing breaks, and the problem is where the packet goes while everything works.

What to do now

Measure the latency floor towards the three or four destinations that matter for production: before changing supplier, know where you stand.
If you have sites linked over DWDM or CWDM, check that the two directions of the ring do not share the last kilometre; in data centres, ask for the cross-connect map.

The point.

An interconnection announcement does not change your routing: it changes your options. Which option is worth taking is settled by a measurement and a well-written specification, not by a map of Europe. That is why, when we review a specification, path diversity is an item with verifiable requirements — route, SRLG, cross-connects, re-verification — and not an adjective. On where the systems that traffic serves should run, we have written separately; the measurements and data we collect stay where they are useful to you, on‑premise in your own environment or on a dedicated cloud with a dedicated VPN and a data centre in Italy, in premises we staff directly.

Do you have two “redundant” links you have never actually verified, or an interconnection specification to write? Talk to a technician.