Route Servers

The FIX Berlin route servers enable multilateral peering between all connected members, and the collection of all peering routes for investigation purposes.


The route servers will be automatically configured to accept connections from new peers. New peers will need to establish BGP sessions towards the route servers

HostnameAS NumberIPv4 AddressIPv6 AddressPlatform
rs1.fix berlin.netAS198136185.0.32.12001:7f8:14b::1Bird 2
rs2.fix berlin.netAS198136185.0.32.22001:7f8:14b::2Coming soon

The route servers implement the RFC7911 Additional Paths Extension in the transmit direction only. This means that they will accept only a single (best) path from each peer, but will export all known paths to peers who have enabled additional path reception. This can be used to prevent path hiding issues in cases where prefix filtering rules cause certain prefixes to be discarded.

Configuration Generation

The FIX Routeserver configuration is automatically generated by IXP Manager. The servers automatically pull new configuration files from the IXP Manager every 15 minutes.

Route-Server Prefix Filtering

The route servers perform prefix filtering in order to prevent route leaks and similar issues. We perform the following filtering on ingress:

  1. Reject if the prefix is too specific (Greater than /24 for IPv4, greater than /48 for IPv6)
  2. Reject if the AS_PATH is empty or longer than 64
  3. Reject if the peer AS is not the first in the AS_PATH
  4. Reject if the prefix is a known martian or bogon
  5. Reject if the next hop is not that of a router operated by the peer on the FIX Berlin peering LAN
  6. Reject if the AS_PATH contains a known transit-free network
  7. Reject if the AS_PATH contains an AS number not in the peer's AS set
  8. Reject if the prefix is RPKI Invalid
  9. Accept if the prefix is RPKI Valid
  10. Accept if the prefix is RPKI Unknown but IRRDB Valid

Well-known BGP Communities

The RFC1997 Well-known Communities NO_EXPORT, NO_ADVERTISE and NO_EXPORT_SUBCONFED are not interpreted by the route servers (in line with common practice) and are instead passed through to peers

Standard Route Server Large Communities

The FIX Berlin route serves implement the Euro-IX Large BGP Communities standard

Export Control

Export control communities are interpreted in the following order.

0(198136, 0, PEERAS)Do not export to PEERAS
1(198136, 1, PEERAS)Export to PEERAS
2(198136, 0, 0)Do not export prefix

Prepend Control

The following large communities may be used to influence prepends towards specific peers.

1(198136, 103, PEERAS)Prepend 3x to PEERAS
2(198136, 102, PEERAS)Prepend 2x to PEERAS
3(198136, 101, PEERAS)Prepend 1x to PEERAS

FIX Berlin Specific Export Control Large Communities

FIX Berlin implements the following additional control communities:

No-Advertise & No-Export

1(198136, 902, PEERAS)Add NO_ADVERTISE community towards PEERAS
2(198136, 901, PEERAS)Add NO_EXPORT community towards PEERAS
3(198136, 900, PEERAS)Don't add either community towards PEERAS
4(198136, 902, 0)Add NO_ADVERTISE community towards all peers
5(198136, 901, 0)Add NO_EXPORT community towards all peers

Legacy Export Control Communities

The following traditional communities are translated as follows prior to interpretation:

(0, 0)(198136, 0, 0)Do not export prefix
(0, PEERAS)(198136, 0, PEERAS)Do not export prefix to PEERAS