Route servers (aka RS) are servers with which members can establish BGP sessions in order to centralize routes and reduce network management.
A route server is not a router. There is no data going through the RS, it is only used to aggregate BGP information. For example, even if two members only establish BGP sessions with the RS, they will be able to exchange routing information through the RS, but the data will flow directly between their routers, because they are on the same LAN.
As you can this on this diagram, Control-plan and Data-plane are different.
The main benefits for peers connecting to RS are:
This “One session to rule them all” approach can make you save a lot of time!
Please keep in mind that some networks prefer to establish directly bilateral BGP peering and may not use the RS. RS adoption by France-IX members is indicated in France-IX members list. Alternatively you would need to send each network a peering request to their peering contact email.
France-IX RS have the following features:
By default, when advertising a route to a RS, every member receives this route. Alternatively, a member can choose to announce (or not) this route to selected members using BGP communities:
0:peer-as = Don't send route to this peer as 51706:peer-as = Send route to this peer as 0:51706 = Don't send route to any peer 51706:51706 = Send route to all peers
Additional information are available on our RIPE object:
whois -h whois.ripe.net as51706
In order to mitigate some fat (and “thin”) fingers errors, France-IX RS perform the following checks:
Any non compliant route is rejected.
In order to help our members fighting against DDoS (Distributed Denial of Service) attacks, a BLACKHOLING service is available. This service allows members to advertise routes with specific BGP communities in order to block malicious traffic.
The blackholing service is detailed here : FRANCE-IX BLACKHOLING
Please note that any route tagged with the BLACKHOLING community but non compliant the IRR check is rejected (see below).
There are several IRRs (Internet Routing Registries) managed by RIRs (Regional Internet Registries) and external entities, to register allocated IP ranges. In addition, there is also an RPKI infrastructure allowing Internet networks to check the origin of the routes announcements with ROAs (Route Origin Authorization).
ROA definition and prefixes registration are explained on the RIPE page of ressource management and certification.
France-IX route servers are tagging routes with BGP communities depending on their IRR and RPKI/ROA validation status. We are using several IRR in addition to the RIPE database and a local instance of the RIPE RPKI validator to ensure accurate data.
How is a route identified as “IRR NOT FOUND” or “ROA INVALID” by the France-IX RS?
“IRR NOT FOUND”: for each member connected to France-IX, an algorithm searches for the AS-SET object associated with the member’s ASN. First, the AS-SET is researched in the “IRR Record” field on PeeringDB. If the field is empty, the algorithm will try to find an AS-SET in the “AUT-NUM” object through the “export” lines (RPSL syntax). It is therefore crucial that the “IRR Record” on PeeringDB is fully completed with the AS-SET or if this is not possible, the AUT-NUM.
Once the AS-SET object (or AUT-NUM) is found, the algorithm searches and establishes a list of the ROUTE objects defined for the AUT-NUM present in this AS-SET (or AUT-NUM). The bgpq3 tool is used to do this recursive search, using the IRR database from NTT (rr.ntt.net) and the following sources as parameters:
RIPE, APNIC, AFRINIC, ARIN, LACNIC, NTTCOM, ALTDB, BBOI, BELL, GT, JPIRR, LEVEL3, RADB, RGNET, SAVVIS and TC
This list of IRR entries is stored in our information system and then replicated locally on the RS. When a route is announced, the RS will search if it is included in this “IRR FOUND” list for the AS that announces the prefix (first-AS). If so, the route is then tagged by the RS with the BGP community “51706:65011”. Otherwise, the BGP community “51706:65021" is added to the route and it will be rejected by default.
“ROA INVALID”: a local instance of the RIPE RPKI validator is installed in France-IX’s infrastructure, allowing to have a copy of ROA entries and thus generate a list stored in our information system and then replicated locally on the RS, in the same way as for IRR entries.
When a route is announced, the RS checks the route status for the Origin AS. If the ROA status is “VALID” or “UNKNOWN”, the route is tagged respectively with the communities “51706:65012" or “51706:65023” and is accepted. If the ROA status is “INVALID”, the community “51706:65022” is added and then rejected by default. It is therefore essential that ROA declarations with the RIR are achieved properly
For IPv4 and IPv6 address families:
export: to AS51706 announce ASxxxx
export-via: AS51706 to AS-ANY announce ASxxxx
mp-export: afi ipv4.unicast,ipv6.unicast to AS51706 announce ASxxxx
For IPv4 address family only:
export-via: afi ipv4.unicast AS51706 to AS-ANY announce ASxxxx
mp-export: afi ipv4.unicast to AS51706 announce ASxxxx
For IPv6 address family only:
export-via: afi ipv6.unicast AS51706 to AS-ANY announce ASxxxx
mp-export: ipv6.unicast to AS51706 announce ASxxxx
If you wish to filter routes collected from France-IX RS, you can filter prefixes using the following AS-SET:
Members connected to the Paris route servers:
Members connected to the Marseille route servers: