NCL-IX Route Servers

Normally on a peering exchange, all connected parties will establish bilateral peering relationships with each other member 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. However, by using a route servers for peering relationships, the number of BGP sessions per router stays at two: one for each route server (assuming a resilient set up). Clearly this is a more sustainable way of maintaining IXP peering relationships with a large number of participants.

NCL-IX uses the secure-by-default templates from IXP Manager to generate our route server configurations. This includes mandatory prefix filtering using IRRDB route objects and RPKI. The filtering algorithm is explained below.

Connection Details

If enabled, the route servers are set up to accept BGP connections from your router. Please contact support@ncl-ix.uk if not enabled or for assistance. Once enabled, you will need to configure BGP peering sessions to the each address of the resilient route server cluster:

Filtering Algorithm

1. Filter small prefixes (default is > /24 / /48 for ipv4 / ipv6).
2. Filter martians / bogons prefixes (see this template).
3. Sanity check - filter prefixes with no AS path or > 64 ASNs in AS path.
4. Sanity check to ensure peer AS is the same as first AS in the prefix’s AS path.
5. Prevent next-hop hijacking. This occurs when a participant advertises a prefix with a next hop IP other than their own. An exception exists to allow participants with multiple connections advertise their other router (next-hop within the same AS).
6. Filter known transit networks.
7. IRRDB filtering: ensure origin AS is in set of ASNs from member AS-SET.
8. RPKI:
   • Valid -> accept
   • Invalid -> drop
   • RPKI Unknown -> revert to standard IRRDB prefix filtering.