IXP Manager logo

Route Servers

Overview

Normally on a peering exchange, all connected parties will establish bilateral peering relationships with each other member port connected to the exchange. As the number of connected parties increases, it becomes increasingly more difficult to manage peering relationships with members of the exchange. A typical peering exchange full-mesh eBGP configuration might look something similar to the diagram on the left hand side.

 

IXP full mesh peering relationships route-server-peering-rsonly
IXP full mesh peering relationships IXP route server peering relationships

 

The full-mesh BGP session relationship scenario requires that each BGP speaker configure and manage BGP sessions to every other BGP speaker on the exchange. In this example, a full-mesh setup requires 7 BGP sessions per member router, and this increases every time a new member connects to the exchange.

However, by using a route server for all peering relationships, the number of BGP sessions per router stays at two: one for each route server. Clearly this is a more sustainable way of maintaining IXP peering relationships with a large number of participants.

Should I use this service?

The INEX route server cluster is aimed at:

As a rule of thumb: If you do not have any good reason not to use the route server cluster, you should probably use it.

The service is designed to be reliable. It operates on two physical servers, each located in a different data centre. The service is available on all INEX networks (public peering lans #1 and #2) on both IPv4 and IPv6. Each server runs a separate routing daemon per VLAN and per L3 protocol. Should a single BGP server die for some unlikely reason, no other BGP server is likely to be affected. If one of the physical servers becomes unavailable, the second server will continue to provide BGP connectivity.

INEX has also implemented inbound prefix filtering on its route-server cluster. This uses internet routing registry data from the various IRR databases to allow connected members announce only the address prefixes which they have registered publicly.

INEX uses BIRD (Bird Internet Routing Demon) running on Ubuntu LTS 16.04 for its route server cluster. BIRD is widely used at internet exchanges for route server clusters, and has been found to be reliable in production.

How do I use the service?

If enabled, the route servers are set up to accept BGP connections from your router. Once this has been done, you will need to configure a BGP peering session to the correct internet address. The IP addresses of the route servers are listed as follows:

Peering LANRoute Server #1Route Server #2 
IPv4 AddressIPv6 AddressIPv4 AddressIPv6 Address
Public Peering LAN #1185.6.36.82001:7f8:18::8185.6.36.92001:7f8:18::9
Public Peering LAN #2194.88.240.82001:7f8:18:12::8194.88.240.92001:7f8:18:12::9
INEX Cork185.1.69.82001:7f8:18:210::8185.1.69.92001:7f8:18:210::9

For Cisco routers, you will need something like the following bgp configuration:

router bgp 64496
  no bgp enforce-first-as
  !
  ! Route server #1
  !
  neighbor 185.6.36.8 remote-as 43760
  neighbor 185.6.36.8 description INEX Route Server
  !
  address-family ipv4
    neighbor 185.6.36.8 password 
    neighbor 185.6.36.8 activate
    neighbor 185.6.36.8 prefix-list pl-announce-to-inex out
  !
  ! Route server #2
  !
  neighbor 185.6.36.9 remote-as 43760
  neighbor 185.6.36.9 description INEX Route Server
  !
  address-family ipv4
    neighbor 185.6.36.9 password s00persekr1t
    neighbor 185.6.36.9 activate
    neighbor 185.6.36.9 prefix-list pl-announce-to-inex out

You should also use route-maps to control outgoing prefix announcements to allow only the prefixes which you intend to announce.

Note that the route server system depends on information in the various IRR databases (typically the RIPE IRR database for INEX members). If you have not published correct route: and route6: objects in this database, your prefix announcements will be ignored by the route server and your peers will not route their traffic to you via the exchange. This is checked by INEX Operations during provisioning and guidance and assistance provided as required.

Community based prefix filtering

The INEX route server system also provides well known communities to allow members to
control the distribution of their prefixes. These communities are defined as follows:

DescriptionCommunity
Prevent announcement of a prefix to a peer
0:peer-as
Announce a route to a certain peer
43760:peer-as
Prevent announcement of a prefix to all peers
0:43760
Announce a route to all peers
43760:43760

So, for example, to instruct the route server to distribute a particular prefix only to AS64111 and AS64222, the prefix should be tagged with communities: 0:43760, 43760:64111 and 43760:64222.
Alternatively, to announce a prefix to all INEX members, excluding AS64333, the prefix should be tagged with community 0:64333.

Since November 2016, INEX’s route server #2 supports BGP large communities for IPv4 on both peering LANs. These communities are defined as follows:

DescriptionCommunity
Prevent announcement of a prefix to a peer
43760:0:peer-as
Announce a route to a certain peer
43760:1:peer-as
Prevent announcement of a prefix to all peers
43760:0:0
Announce a route to all peers
43760:1:0

Support for BGP large communities will be rolled out to all remaining server instances during 2017.