Route Servers

We operate geo-redundant route servers at currently two Rheintal IX sites. The route servers serve to simplify peerings between the individual participants. We recommend that all peers participate in our route servers.

The details of the Rheintal IX route servers can be found in the table below:

 

Name ASN IPv4 IPv6 Max prefix limit MD5 password
rs1.rheintal-ix.net AS58171 91.232.229.254 2001:7f8:66::254 260.000 IPv4 / 160.000 IPv6 see member portal
rs2.rheintal-ix.net AS58171 91.232.229.253 2001:7f8:66::253 260.000 IPv4 / 160.000 IPv6 see member portal

 

All prefixes announced to the route servers are checked for validity via the IRR databases (RIPE, ARIN, RADB, etc.) and via RPKI Route Origin Validation (ROV). Invalid prefixes are filtered by the route servers by default. More information about RPKI can be found here.

By default, some router models try to compare the AS of the received route with the AS of the peer. If these are not identical, the route is marked as invalid. The route server at Rheintal IX has its own AS number, but does not insert it into the AS path. Please configure your router accordingly for this, e.g. via the parameter “no bgp enforce-first-as” on Cisco platforms.

For troubleshooting the prefixes announced to the route servers there is a BGP Looking Glass available.

 

Selective prefix announcement via the route server

Via BGP Standard Communities (set community x:y), the prefix distribution on the Rheintal IX Route Servers can be controlled:

  • 0:<Participant AS> are not announced to the participant with this AS.
  • 58171:<Participant AS> are announced to the participant with this AS.
  • 0:58171 are not announced to any participant of the Rheintal IX.
  • 58171:58171 will be announced to all participants of the Rheintal IX.

If a prefix is not provided with a BGP standard community, the prefix is announced by the route servers to all participants of the Rheintal IX.

 

IRR and AS-Set macro

All peering relationships should basically be mapped accordingly in the AS/AUT-NUM object of each participant via the IRR databases (RIPE, ARIN, APNIC, etc.), since corresponding IRR filters can be generated by other participants on the basis of this data. For this purpose, we maintain the AS-RIX-RS object in the RIPE database.

The following is an example RPSL entry for IPv4 and IPv6 route server peerings at Rheintal IX:

remarks:      # Rheintal IX Route Servers
mp-import:    afi any.unicast from AS58171 accept AS-RIX-RS
mp-export:    afi any.unicast to AS58171 announce <Your_AS_or_AS-SET>