Route Servers

An external BGP session with our Route Server ASN must be deployed to activate the service. Our ASN will not be added to your prefixes’ BGP AS-PATH so a specific configuration must be required on some routing devices.

We configure our session to be passive so each member should be in active mode.

Our total number of prefixes is updated in our PeeringDB entry:

• IPv4: 110000
• IPv6: 40000

With new members joining it’s normal that this number increases. For this reason we recommend to set up a margin for growth or to have a regular checkup on routing policies.

Besides having to own a PeeringDB entry, we also ask every peer to keep it updated as we’re using some values to render our templates:

• AS-SETs to make IRRdb validation
• Max Prefixes v4 to configure as a safety measure (we add a 15% margin)
• Max Prefixes v6 to configure as a safety measure (we add a 15% margin)

While our servers are configured as a BGP reflector, we still implement some IXP security mechanism that are promoted by the MANRS initiative. We will drop any route that:

• Has a prefix reserved by RFC
• Has an invalid ASN in AS-PATH
• Has more than 32 ASN in AS-PATH
• Has at least one ASN tagged with “never-via-route-servers” attribute (PeeringDB);
• Has an invalid ROA associated with it
• Represents an IPv4 network larger than /8 or smaller than /24
• Represents an IPv46 network larger than /12 or smaller than /48

The route severs apply filtering based on the IRRdb. Therefore, it is important for members to maintain their routing data information updated in the IRR system.

However, we will tag our validation with information communities (Large Communities):

• 12833:1900:1 Prefix in AS-SET
• 12833:1900:2 Prefix not in AS-SET
• 12833:1900:3 Origin ASN in AS-SET
• 12833:1900:4 Origin ASN not in AS-SET
• 12833:1900:8 ASN was accepted through a whitelist

Changes on the default filtering behaviour or the possible addition of whitelist or blacklist on a peer-basis should be submitted to GigaPIX teams for a more in-depth analysis.

ROA validation is done through an internal tool managed by RCTS CERT. It is implemented with RIPE Validator.

It is also possible to use communities to define a custom outbound policy at the route server.

We recommend the use of Large Communities although we’re still mapping some of the services with Standard Communities.

EXPORT CONTROL

We offer two options to explicitly define which members should receive a prefix (Std. Community | Large Community):

• Set “no-export-to” community for each ASN that should not receive a route:

0:peerasn | 12833:0:peerasn 

• Set “no-export-to-any” community combined with “export-to”:

0:12833 | 12833:0:0 combined with 1:peerasn | 12833:1:peerasn

PREPENDING

To add each peer ASN to AS-PATH up to three times, we offer the following options (Std. Communities | Large Communities):

• Set “prepend-to-all” community:

65001:0 | 12833:100:1 – prepend once

65002:0 | 12833:100:2 – prepend twice

65003:0 | 12833:100:3 – prepend thrice

• Set the “prepend-to” community for a granular control:

12833:101:peerasn – prepend once per peer

12833:102:peerasn – prepend twice per peer

12833:103:peerasn – prepend thrice per peer

ADD NO-EXPORT OR NO-ADVERTISE

To trigger our Route Servers to add RFC no-export or no-advertise a peer should :

• Set “add-no-export” or “add-no-advertise” to all:

12833:65281 for no-export

12833:65282 for no-advertise

• Set the “add-no-export-to” or “add-no-advertise-to” community for a more granular control:

12833:901:peerasn to add no-export to peerasn

12833:902:peerasn to add no-advertise to peerasn

RFC COMMUNITIES

GigaPIX Route Servers act actively to RFC communities:

• RFC 8326 for Graceful Shutdown;
• RFC 1993 for No-Export and No-Advertise

We have a public web page to show every prefix processed at our servers:

LG GigaPIX

In this web address everyone can also see who is currently peering with the servers and the reason why some prefixes might being filtered.