Route Servers


When becoming a new member at any IXP, the initial setup process is not easy, one has to establish bilateral agreements with the other members that are already connected. Each peering requires a separate neighbor configuration, requires time and effort.

Route Servers make this task easier. When peering with a route server the new member “peers directly” with all the other ones that also peer with it. This simplifies the configurations (one BGP peering for all members connected), improves performance and reliability (can act as a backup for other bilateral agreements).

By peering with the route server, any member can still pursue bilateral agreements with other members that are connected (or not) to the route server.

GigaPIX has set up route servers in Lisbon (LX) and Porto (PRT) sites.


IPv6: 2001:7F8:A:1::1000

ASN: 12833

Platform: BIRD 2.0.7

All services in production.


IPv6: 2001:7F8:A:1::1244

ASN: 12833

Plataforma: BIRD 1.6.8

All services in production.


IPv6: 2001:7F8:A:2::1061

ASN: 12833

Platform: BIRD 2.0.7

All services in production.


IPv6: 2001:7F8:A:2::1062

ASN: 12833

Platform: BIRD 1.6.8

All services in production.



IPv6: 2001:7F8:A:11::100

ASN: 12833

Plataforma: BIRD 1.6.8

Communities and filtering to be activated.

Any member peering with a route server is automatically receiving all prefixes of all members connected in a multilateral peering setup. This scenario make it easier to connect and faster to peer within our IXP.


Peering with one of our Route Servers doesn’t prevent bilateral peering agreements between members. In fact, it can be seen as an improvement on the resiliency of the connection.


Also focusing on resiliency, we ask our members to have sessions to both servers available in each LAN and to configure exactly the same outbound routing policy. This way we ensure the proper operation of the service in case of unexpected failure or planned maintenance of one machine.

BGP Configuration

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)
Filtering Policies

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.


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


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


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


GigaPIX Route Servers act actively to RFC communities:

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

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


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