France-IX Route Servers

What are route servers?

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.

Route servers (aka RS) are servers

As you can this on this diagram, Control-plan and Data-plane are different.

The main benefits for peers connecting to RS are:

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),

Selective announcement

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

bgp rs announcement

Additional information are available on our RIPE objects:

Paris:

whois -h whois.ripe.net as51706

or https://apps.db.ripe.net/search/lookup.html?source=ripe&key=AS51706&type=aut-num

Marseille:

whois -h whois.ripe.net as42064

or https://apps.db.ripe.net/search/lookup.html?source=ripe&key=AS42064&type=aut-num

Securities

In order to mitigate some fat (and “thin”) fingers errors, France-IX RS perform the following checks:

Filtering Martian’s prefixes (BOGONS VIA HTTP)
Max-prefix: limits the number of prefixes learned per peer on RS (shutdown the BGP session if the threshold is exceeded)
Prefix length: IPv4 netmask must be >= /8 and <= /24, IPv6 netmask must be >= /19 and <= /48
Private ASN: no private ASN in the AS_PATH
Bad NEXT_HOP: verification that the next-hop IP in the BGP update is also the source of the IP packet.
Enforce First AS : verification that the leftmost AS of the AS-PATH is the peer AS.

Any non compliant route is rejected.

Blackholing

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).

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.

rs routes validation

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

Specify "no bgp enforce-first-as” (IOS and IOS-XE) or “bgp enforce-first-as disable” (IOS-XR) when setting your configuration with the RS (only if you are using Cisco equipment since RS do not add their ASN in the AS_PATH);
Set max prefixes limit with proper values (and remember to update them from time to time as the number of routes keep growing on the RS: looking-glass;
If you wish to filter prefix length, please remember that prefixes with BLACKHOLE community are accepted up to /32 in IPv4 and /128 in IPv6 on our RS;
Filter out our IXP prefixes 37.49.232.0/24, 37.49.236.0/22, 2001:7f8:54::/48 (and more specifics) from all BGP peers/transits. This can protect you from problems if somebody accidentally announces those prefixes;
Create ROA for your prefixes on your LIR portal (i.e. https://my.ripe.net/#/rpki for European networks);
Fill, and keep up-to-date your ASN / AUT-NUM (and eventually AS-SET) object. Here are some examples of macro that should be set in your AUT-NUM object (ASxxxx can be your AS Number or your AS-SET name):

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