Route servers facilitate Multilateral Peering. A single BGP session with each route server allows you to see the prefixes of all of the other networks peering with the route servers. The route servers preserve the sending peer's next-hop and other prefix attributes. No traffic is ever routed by the route servers, they simply facilitate prefix exchange. Connecting is free - there are no additional fees charged for using this service.
LONAP operate two route servers, running different releases of BIRD
We offer two route servers for resilience, so please turn up a session to both. Having two servers allows us to perform safe upgrades and maintenance on the platform without interrupting service.
LONAP permit participants on the route-servers to filter their announcements such that they are not offered to certain other peers on the route servers. This is useful if you wish to prevent your prefixes from reaching your transit customers via the route-servers, or you wish to deny peering to some networks as a matter of policy. Today, the filtering logic is expressed with the use of BGP Communities:
- 8550:8550 - Send prefixes to all other route-server participants
- 8550:ASN - Send prefix to only route-server participant with specific ASN
- 0:ASN - Do not send prefix to route-server participant with specific ASN
- 0:8550 - Do not echo prefix to any other route-server participants.
The default behaviour if no communities are specified is to advertise all prefixes to all peers.
The well-known community NO-EXPORT (65535:65281) is not processed by the route server, but is passed transparently to peers. Setting NO-EXPORT specifies that your prefixes will advertised to LONAP Peers, but that peers should not advertise to downsteam or other external ASNs.
The community logic is identical for IPv4 and IPv6 peering. The LONAP route servers support IPv4 and IPv6 prefix exchange.
You must register any prefixes that you send to the route-servers in a public routing registry database, ideally one that is mirrored to RADB. For most of our members, this means 'please register route objects in the RIPE database for your prefixes' (and encourage your customers to do the same). Any prefixes which are not properly registered with route objects will not be accepted by the route servers.
Most members will want to send their prefixes to the route servers, and tag community 8550:8550 with them. Here is an example Cisco configuration which achieves this.
router bgp 123 no bgp enforce-first-as (- very important for route servers) neighbor lonaprs peer-group neighbor lonaprs remote-as 8550 neighbor lonaprs description LONAP MLP IPv4 neighbor lonaprs route-map lonap-rs-out out neighbor lonaprs route-map lonap-rs-in in neighbor lonaprs maximum-prefix 20000 neighbor 22.214.171.124 peer-group lonaprs neighbor 126.96.36.199 peer-group lonaprs neighbor lonaprs6 peer-group neighbor lonaprs6 remote-as 8550 neighbor lonaprs6 description LONAP MLP IPv6 neigbbor lonaprs6 route-map lonap-rs6-out out neighbor lonaprs6 route-map lonap-rs6-in in neighbor lonaprs6 maximum-prefix 10000 neighbor 2001:7f8:17::1 peer-group lonaprs6 neighbor 2001:7f8:17::2 peer-group lonaprs6 route-map lonap-rs-out match as-path 10 (- or however you prefix filter) set community xxx route-map lonap-rs-in set local-preference 1000 (- or whatever you use for peers) route-map lonap-rs6-out match as-path 10 set community xxx route-map lonap-rs6-in set local-preference 1000
We recommend that any network who have not explicitly built a policy forbidding multi-lateral peering, do connect to the route-servers.
To connect, you need to request that LONAP support configure your route-servers sessions. Please email support-at-lonap-dot-net to reach this team.