AS58218 · Bird v2 · RPKI + IRRDB
DSIX Route Server
Simplify your peering, connect to two route servers instead of managing individual BGP sessions with every member.
Should I use the Route Server?
The DSIX route server cluster is designed for:
- ✓ Small to medium members who don't have time or resources to manage individual peering relationships
- ✓ Larger members with an open peering policy where managing sessions with smaller peers isn't worth the effort
- ✓ Anyone who wants instant peering with all current and future DSIX members automatically
Rule of thumb: if you don't have a specific reason NOT to use the route server, you should use it.
Redundant Design
Two independent physical servers (RS1 + RS2). Full IPv4 and IPv6 support. If one server fails, the other continues providing BGP connectivity seamlessly.
RPKI + IRRDB Filtering
Inbound prefix filtering using RPKI ROA validation with IRRDB fallback. Only prefixes you've registered publicly are announced to peers. Invalid RPKI = dropped.
Bird v2 on Ubuntu 24.04
BIRD Internet Routing Daemon v2, the industry standard for IXP route servers. Battle-tested at exchanges worldwide, running on Ubuntu LTS 24.04.
Route Server Addresses
BGP Communities
Control prefix distribution to specific peers using standard and large BGP communities.
Standard Communities (16-bit)
Large Communities (32-bit)
Note: If your router supports large BGP communities, use those instead of standard 16-bit communities, especially since many DSIX members use 32-bit ASNs. Do not mix standard and large communities, choose one or the other.
Frequently Asked Questions
What members ask before and after setting up their session.
Why do IXPs use route servers instead of a full mesh?
A full-mesh topology needs N*(N-1)/2 BGP sessions between N members. At 20 members that is 190 sessions; at 100 members it is 4,950. Route servers collapse the mesh into 2*N sessions (every member peers with RS1 and RS2). Each member then receives routes from every other member through the RS, without having to negotiate and maintain hundreds of bilateral sessions. This is how essentially every modern IXP scales, and it is defined by RFC 7947.
Should every DSIX member peer with the route servers?
Unless you have a specific reason not to, yes. The route server is free, fully automated and gives you instant visibility of every current and future DSIX member. Members who run a selective peering policy typically peer with the RS and filter inbound on their side using standard DSIX BGP communities.
What filtering do the DSIX route servers enforce?
We validate every inbound prefix against RPKI (reject Invalid, accept Valid, accept NotFound) and cross-check the origin ASN against the member's registered IRR as-set. We also apply bogon filters, maximum-prefix limits per member, and enforce the DSIX peering policy (no default route, no private ASNs, no private IPs). A prefix that fails any of those is silently dropped.
Why two route servers instead of one?
Redundancy. RS1 and RS2 run on independent hardware with independent upstream power and cooling. A software bug or hardware failure on one does not interrupt peering on the other. Members should configure a BGP session to both: when RS1 becomes unreachable, RS2 keeps paths flowing without a single dropped session.
What software do you run on the route servers?
BIRD on Ubuntu 24.04 LTS. BIRD is the de-facto standard on European IXPs (AMS-IX, DE-CIX, LINX, FranceIX all run it). BIRD gets active upstream maintenance, has clean config-file semantics and supports everything modern IX operators need: RPKI ROV, large communities, role-based multiprotocol sessions, generalised filters.
Do you add a next-hop-self, or is the peer's next hop preserved?
We preserve the original next hop. Route servers are transparent on DSIX, so the next-hop you receive for prefix X points directly at the member that announced it, not at the RS. Your forwarding traffic therefore goes peer-to-peer across the L2 fabric, not through the route server.
What is the AS path on routes received via the RS?
Since DSIX uses the standard transparent RS behaviour, the RS ASN (58218) is removed from the AS_PATH. You receive each prefix with the originating member's AS as first hop, exactly as if you had a direct session with them. This is what RFC 7947 mandates and it avoids accidentally treating the RS as an AS hop.
Can I use BGP communities to control what the RS announces to other members?
Yes, that is exactly what the community schema on this page is for. Tag a prefix with
0:AS to prevent it being announced to a specific AS, 0:58218 to blackhole a specific member group, 58218:AS to announce only to a specific AS, and so on. Large communities are supported on the same semantics.What address families do the route servers support?
Full IPv4 and IPv6, each on a separate BGP session. Follow industry convention and keep IPv4 and IPv6 as two distinct sessions (one per AFI). Mixed-AFI on the same TCP connection is not recommended.
Are the looking glasses public or member-only?
Public. Anyone can query our looking glasses to inspect the DSIX table without a login. They are a useful tool for prospective members to validate their own announcements before joining, and for troubleshooting BGP problems. Internally we use the same LG during incident response.
What does the Config Generator actually produce?
You provide your ASN, IPv4 address, optionally IPv6 address and announced prefix, and pick your router platform. The generator prints a complete BGP snippet: session definitions for RS1+RS2 across IPv4 and IPv6, prefix filters pointing at your IRR as-set, RPKI validator hooks where the platform supports it, and community policy comments. BIRD 2, FRR, MikroTik RouterOS 7 and Cisco IOS are supported today.
Can I customise the config before using it?
Absolutely. The generator is a starting point, not a finished production config. We deliberately keep it minimal and well-commented so you can adapt it to your naming conventions, timers, RPKI validator endpoint and filter strategy. Most members paste it in, adjust 2-3 values and reload.
Do the route servers accept BGP communities like BLACKHOLE?
Yes. We honour the well-known RFC 7999
65535:666 community and apply RTBH propagation to the prefix across the DSIX fabric. DSIX-specific communities for blackholing a prefix only against a single member are documented in the communities table.Why would an RPKI-Valid prefix still be dropped?
Most common cause: the prefix is announced by an origin ASN different from the one authorised in the ROA. We accept Valid and NotFound, reject Invalid. A prefix that has a ROA, but the announcing AS does not match, is Invalid. Fix the ROA or announce from the correct AS.
How often do you roll the RS software?
Ubuntu package updates are applied weekly during the standard DSIX maintenance window (Tuesday 02:00-06:00 EET). Bird major upgrades are announced at least 14 days in advance via the DSIX members list and noc@dreamserver.ro. Minor config changes (new communities, filter adjustments) are applied with a shorter notice.
