How the exchange works
A mental model for what happens when you connect and announce routes.
The big picture
Every participant connects to the exchange over a GRE or VxLAN tunnel. The tunnel drops your router onto a shared Layer 2 network — the peering LAN. On that LAN sit the two route servers (RS1 and RS2) and every other participant's tunnel endpoint.
What a route server does — and doesn't do
It does
- ✓Accept BGP sessions from participants
- ✓Validate and filter route announcements
- ✓Redistribute valid routes to all other participants
- ✓Preserve the original next-hop IP
It does NOT
- ✗Carry any data traffic
- ✗Appear in traceroutes between participants
- ✗Prepend its own ASN to routes it passes on
- ✗Provide internet transit
192.168.100.101,
your router sends packets directly to that IP over the peering LAN bridge — not through RS1.
The route server is only in the control plane, never the data plane.
This is why RS IPs will not appear in traceroutes between participants.
Why two route servers?
RS1 and RS2 are completely independent BIRD2 processes, each listening on its own IP. You should establish BGP sessions to both.
Redundancy
If one route server is restarted for maintenance, your BGP sessions and route table stay intact through the other. With only one RS session, any maintenance window drops all your peering routes.
Independent views
Each RS builds its own route table independently. If one receives a bad UPDATE and blocks a session, the other continues distributing routes normally.
No path through the RS
Because traffic never flows through a route server, both RSes can run on the same physical host without becoming a single traffic choke point. Redundancy here is purely about BGP session continuity.
What happens when you announce a route
-
1
You advertise a prefix to RS1 and RS2
Your BGP daemon sends an UPDATE to both route servers over your peering LAN sessions. The next-hop in the UPDATE is your assigned peering LAN IP.
-
2
The route server validates the announcement
Before accepting the route, the RS checks it against the import filter. Announcements that fail are silently dropped — see Route filters below. If it passes, the route is added to the RS's routing table.
-
3
The RS redistributes the route to other participants
The RS sends an UPDATE to every other connected participant, with your peering LAN IP preserved as the next-hop. It does not add its own ASN to the AS path — so from a peer's perspective the route appears to come directly from your AS.
-
4
Peer routers install the route and send traffic directly to you
A peer receiving the UPDATE installs a route pointing to your peering LAN IP as next-hop. Any traffic they send toward your prefix goes directly from their tunnel interface, across the peering LAN bridge, into your tunnel — the route server is not involved.
Route filters
The route server rejects any announcement that fails these checks. Rejections are silent — the session stays up but the prefix will not appear in other participants' tables. Use the Routes page to confirm which of your prefixes are actually held by each RS.
| Rule | IPv4 | IPv6 |
|---|---|---|
| No bogons | RFC 1918, loopback, link-local, multicast, reserved ranges | All ULA (fc00::/7), link-local, documentation, benchmarking |
| No default route | 0.0.0.0/0 rejected |
::/0 rejected |
| Maximum prefix length | Longer than /24 rejected | Longer than /48 rejected |
| No peering LAN prefixes | The peering LAN subnet itself may not be announced | |
| Next-hop on peering LAN | Next-hop must be within the peering LAN subnet | Next-hop must be within the peering LAN subnet or link-local (fe80::/10) |
| Prefix limit | Each participant has a maximum prefix count set at registration. Exceeding it blocks the session for that address family until the count drops back under the limit. | |
Private and public ASNs
This exchange separates participants into two classes based on their ASN.
Private ASNs
Range 64512–65534, assigned by this portal.
Routes from private-ASN participants are only distributed to other private-ASN participants. Public-ASN participants will not see them.
Public ASNs
Registered ASNs verified via RDAP.
Routes from public-ASN participants are only distributed to other public-ASN participants. Private-ASN participants will not see them.
This is enforced at the route server export filter — it is not a configuration option. If you registered with a private ASN for testing and need to exchange routes with a production public-ASN network, you will need to register a real ASN.
Ready to connect?
Go to your Locations page to connect to an exchange location. Once provisioned, the Connection Instructions tab shows ready-to-paste configs for your platform.