Optimization of BGP sessions
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 see on this diagram, Control-plan and Data-plane are different.
Less BGP sessions to configure
Quick and easy way to get a multitude of routes
Easily tunable using BGP communities
No need to make multiple peering arrangements with other members
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.
Features and security
France-IX RS have the following features:
Select and advertise the best BGP Path for each route
Do not modify the AS_PATH (the ASN of the RS is not appended to the AS_PATH)
Do not modify the Next-Hop IP address (traffic will flow directly between routers)
Do not interpret well-known communities: (NO-EXPORT, NO_ADVERTISE, etc.) these communities will be advertised to the peers
Support ADD-PATH (Tx-only), this means your router will receive several routes for the same network destination if it has the capability
Support selective announcement (with specific BGP communities)
Make some security checks (see below)
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:
Paris Route-servers :
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
Marseille Route-servers :
0:peer-as = Don't send route to this peer as 42064:peer-as = Send route to this peer as 0:42064 = Don't send route to any peer 42064:42064 = Send route to all peers
Additional information are available on our RIPE objects:
Paris:
whois -h whois.ripe.net as51706
or https://apps.db.ripe.net/db-web-ui/lookup?source=ripe&key=AS51706&type=aut-num
Marseille:
whois -h whois.ripe.net as42064
or https://apps.db.ripe.net/db-web-ui/lookup?source=ripe&key=AS42064&type=aut-num
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 fight 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).
RPKI / ROA and IRR filtering
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” (Paris) / “42064:65011” (Marseille). Otherwise, the BGP community “51706:65021" (Paris) / “42064:65021" (Marseille) 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” (Paris) / “42064:65012" or “42064:65023” (Marseille) and is accepted. If the ROA status is “INVALID”, the community “51706:65022” (Paris) or “42064:65022” (Marseille) is added and then rejected by default. It is therefore essential that ROA declarations with the RIR are achieved properly.
Best practices
For IPv4 and IPv6 address families:
export: to AS51706 announce ASxxxx |
or |
export-via: AS51706 to AS-ANY announce ASxxxx |
or |
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 |
or |
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 |
or |
mp-export: ipv6.unicast to AS51706 announce ASxxxx |
For Marseille route-servers, replace AS51706 with AS42064.
If you wish to filter routes collected from France-IX RS, you can filter prefixes using the following AS-SETs:
Members ASN list connected to the Paris route servers:
AS51706:AS-MEMBERS:AS-PAR-RS
AS-Set containing all members (including downstream customers) connected to the Paris route servers:
AS51706:AS-MEMBERS
Members ASN list connected to the Marseille route servers:
AS42064:AS-MEMBERS:AS-MRS-RS
AS-Set containing all members (including downstream customers) connected to the Marseille route servers:
AS42064:AS-MEMBERS