Route Servers

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. They are:

OpenBGPd, running OpenBSD.
BIRD, running Debian GNU/Linux.

We offer two route servers for resilience, so please turn up a session to both. Running two route-servers protects peers against bugs discovered on one platform destroying the multilateral peering service, and it allows us to perform safe upgrades on the platform that do not interrupt 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:0 - Do not echo prefix to any other route-server participants.

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 193.203.5.1 peer-group lonaprs
	neighbor 193.203.5.2 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.