What are route servers

Route servers (aka RS) are servers with which peers 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 peers 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.

Benefits

• 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 peers

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 peers is indicated in France-IX peers 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
• Does not modify the AS_PATH (the ASN of the RS is not appended to the AS_PATH)
• Does not modify the Next-Hop IP address (traffic will flow directly between routers)
• Does 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 the peer has and uses the capability
• Support selective announcement (with specific BGP communities)
• Make some security checks (see below)
• BGP Roles (RFC9234) Support : Routes having the OTC (Only To Customer) BGP attribute are rejected
• BFD (Bidirectional Forwarding Detection) support, on request

Route-Servers ASN on France-IX Peering LANs

Route-servers signalling and prefix tagging

Peers can use BGP communities to signal selective announcement, and route-servers use BGP communities to tag various information regarding the re-announced routes.RFC8092 - style BGP communities (a.k.a “Large BGP communities”) are the preferred way of signalling, and in the medium-longer term will be the only way of signalling between route-servers and peers. We are following Euro-IX guidelines for the use of Large BGP communities : https://www.euro-ix.net/en/forixps/large-bgp-communities/RFC1997 - style BGP communities (a.k.a. “Classic BGP communities”) are still supported on route-servers having a 16-bit ASN (less than 65535), and only for signalling regarding other 16-bit ASNs as well as well-known “Blackhole” community (65535:666, as specified in RFC7999). This may change in the future, so please use “Large BGP communities” (RFC8092) instead.

Selective announcement

By default, when advertising a route to a RS, every peer receives this route. Alternatively, a peer can choose to announce (or not) this route to selected peers using BGP communities:

• RS-ASN:0:0 - Do NOT send route to ANY peer unless explicitly specified otherwise
• RS-ASN:0:PeerASN - Do NOT send route to the specified peer ASN
• RS-ASN:1:0 - Default behaviour : DO send route to all peers
• RS-ASN:1:PeerASN - DO Send route to the specified peer ASN, even if RS-ASN:0:0 was specified

Route properties changement

• RS-ASN:101:PeerASN - Prepend 1 time when announcing to PeerASN
• RS-ASN:102:PeerASN - Prepend 2 times when announcing to PeerASN
• RS-ASN:103:PeerASN - Prepend 3 times when announcing to PeerASN
• RS-ASN:901:PeerASN - Set MED to 50 when announcing to PeerASN
• RS-ASN:902:PeerASN - Set MED to 100 when announcing to PeerASN
• RS-ASN:903:PeerASN - Set MED to 200 when announcing to PeerASN

Communities set by the route-servers

Route-servers tag routes with large/RFC8092 BGP communities in order to signal the result of checks performed. The following communities are set by the route-servers:

On routes re-announced to peers:

• RS-ASN:1000:1 - RPKI_VALID : Valid ROA found
• RS-ASN:1000:2 - RPKI_NOTFOUND : No ROA found
• RS-ASN:1001:1 - IRR_VALID : Origin ASN in Peer AS-Set and origin validation (IRR or RPKI) passed
• RS-ASN:1001:6 - No IRR “Route:” object present. If you receive the route, it has a valid ROA signature

On the looking-glass only, for filtered routes:

• RS-ASN:1000:4 - RPKI_INVALID : ROA found, but does not match origin ASN or prefix size
• RS-ASN:1001:4 - Not found in IRR database (generic)
• RS-ASN:1001:5 - Origin AS not found in announcing peers AS-SET
• RS-ASN:1011:9 - FILTERED : IRR Not found or Invalid
• RS-ASN:1011:10 - FILTERED : Origin AS not found in announcing peers AS-SET
• RS-ASN:1011:11 - FILTERED : No IRR “route:” object and no valid ROA
• RS-ASN:1011:13 - FILTERED : RPKI_INVALID
• RS-ASN:1011:14 - FILTERED : “Never via RS” ASN found in AS-Path

Security

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

• Prefix length: IPv4 netmask must be ≥ /8 and ≤ /24; IPv6 netmask must be ≥ /19 and ≤ /48
• RFC5735 : Filtering martial/bogon prefixes for IPv4
• RFC5156 : Filtering martial/bogon prefixes for IPv6
• RFC6996 : Private ASN: no private ASN in the AS_PATH
• Bad NEXT_HOP: verification that the next-hop IP in the BGP update is the announcing peer IP.
• Enforce First AS : verification that the first AS of the AS-PATH is the peer AS.
• RFC9234 : Our role is RS_Server, peers’ role is RS_Client, and we are filtering routes already continuing the OTC (Only To Customer) attribute.
• Max-prefix: limits the number of prefixes learned per peer on RS (shutdown the BGP session if the threshold is exceeded)

Any non compliant route is rejected.

Blackholing

In order to help peers fight against DDoS (Distributed Denial of Service) attacks, a BLACKHOLING service is available. This service allows peers to advertise routes with specific BGP communities in order to block malicious traffic.

To use it, configure the community `65535:666` in your export policy for the related routes (see RFC7999).

Please note that any route tagged with the BLACKHOLING community must pass the following criteria:

• Prefix length between /24 and /32 (IPv4) or /64 and /128 (IPv6).
• Announcing ASN must be authorized to announce the less-specific covering prefix.

RPKI / ROA and IRR filtering

ROA definition and prefixes registration are explained on the RIPE page of ressource management and certification.

France-IX route servers are filtering routes based on their IRR and RPKI/ROA validation status. RPKI/ASPA validation will be enabled as soon as the IETF documents describing the process reach a version stable enough. We are using several IRR sources in addition to the RIPE database and multiple local RPKI validator instances to ensure accurate data.

Validation precess:

• First AS in path must be the peer’s ASN
• Announced next-hop must be the peer’s IP on the peering LAN
• Prefix length is checked:
  • IPv4 routes : between /8 and /24, included
  • IPv6 routes : between /19 and /48, included
  • Blackhole IPv4 routes : between /24 and /32, included
  • Blackhole IPv6 routes : between /64 and /128, included
• Routes must NOT contain private or bogon ASNs in the path (RFC6996)
• Bogon prefixes are not allowed (RFC5735, RFC1918, RFC6598, RFC5156)
• Routes must NOT contain ASNs that declared themselves as “Never via RS” in PeeringDB
• RPKI : Routes must be ROA valid or unknown. ROA Invalid routes are filtered
• IRR : Origin ASN must be in the peer’s AS-Set (or be the peer’s ASN)
• IRR : ROA Unknown routes must have a “route:” or “route6:” object declared in an authoritative IRR database.

The following IRR sources are used (in this order) :

• RIR-based IRR sources : RIPE, APNIC, LACNIC, AFRINIC, ARIN
• Country-based IRR sources : JPIRR, IDNIC
• Due to historic reasons that are still valid, RADB is still being used in a number of cases

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 (check PeeringDB for correct values and remember to update them regularly as the number of routes keep growing)
• 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, 77.95.71.0/24, 77.95.66.0/23, 185.1.144.0/24, 193.105.232.0/24, 91.213.236.0/24, 2001:7f8:54::/48, 2001:7f8:47::/48 and more specifics from all BGP peers/transits and DO NOT re-announce them.
• Create ROA for your prefixes on your LIR portal (i.e. https://dashboard.rpki.ripe.net/#overview for European networks)
• Keep up-to-date your ASN / AUT-NUM (and eventually AS-SET) object.
• Create and keep up to date your PeeringDB record with max-prefix and AS-Set values.

Example for how to update you ASN/AUT-NUM object (ASxxxx being your ASN or your AS-set):

• For IPv4 and IPv6 address families (choose one):
  • 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 (choose only one):
  • 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

For route-servers of the other peering LANs, replace AS51706 the appropriate ASN (preceded by “AS” - in the ASnnnnn format). See the list above.

If you wish to filter routes collected from France-IX RS, you can filter prefixes using the AS-Sets specified above in the table with route-servers’ ASNs.