Route Servers
The FIX Berlin route servers enable multilateral peering between all connected members, and the collection of all peering routes for investigation purposes.
Connecting
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
| Hostname | AS Number | IPv4 Address | IPv6 Address | Platform |
|---|---|---|---|---|
| rs1.fix berlin.net | AS198136 | 185.0.32.1 | 2001:7f8:14b::1 | Bird 2 |
| rs2.fix berlin.net | AS198136 | 185.0.32.2 | 2001:7f8:14b::2 | Coming 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:
- Reject if the prefix is too specific (Greater than /24 for IPv4, greater than /48 for IPv6)
- Reject if the AS_PATH is empty or longer than 64
- Reject if the peer AS is not the first in the AS_PATH
- Reject if the prefix is a known martian or bogon
- Reject if the next hop is not that of a router operated by the peer on the FIX Berlin peering LAN
- Reject if the AS_PATH contains a known transit-free network
- Reject if the AS_PATH contains an AS number not in the peer's AS set
- Reject if the prefix is RPKI Invalid
- Accept if the prefix is RPKI Valid
- 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.
| # | Community | Action |
|---|---|---|
| 0 | (198136, 0, PEERAS) | Do not export to PEERAS |
| 1 | (198136, 1, PEERAS) | Export to PEERAS |
| 2 | (198136, 0, 0) | Do not export prefix |
In the case of selective peering arrangements, you can use the (198136, 0, 0) to prevent advertising of a prefix
by default and then use specific (198136, 1, PEERAS) communities to advertise to specific peers
Prepend Control
The following large communities may be used to influence prepends towards specific peers.
| # | Community | Action |
|---|---|---|
| 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
| # | Community | Action |
|---|---|---|
| 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:
| Community | Translation | Interpretation |
|---|---|---|
| (0, 0) | (198136, 0, 0) | Do not export prefix |
| (0, PEERAS) | (198136, 0, PEERAS) | Do not export prefix to PEERAS |