Technical

Route Servers

Route servers facilitate multilateral peering. A single BGP session with each route server allows participants to see the prefixes of all participants also peering with the route servers.

Over 80% of networks present at LONAP also peer with the route servers.

Without route server peering, individual BGP sessions must be configured for every peer.

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. No additional fees are charged for using this service.

How to use

We offer two route servers for resilience and ask that all participants create a session to both. Each server is housed in different facilities. Having two servers also allows us to perform safe upgrades and maintenance without interrupting service.

LONAP Members may enable BGP sessions to the route servers:

RS1 - AS 8550 : 5.57.80.1 / 2001:7f8:17::1
RS2 - AS 8550 : 5.57.80.2 / 2001:7f8:17::2

To connect, you need to request that LONAP support enables your route server sessions. Please email support-at-lonap-dot-net if the sessions don’t establish.

Inbound Filtering

LONAP’s route servers implement prefix filtering using both Resource Public Key Infrastructure (RPKI) and Internet Routing Registry (IRR) data from various databases (RIPE, RADB, ARIN etc.) to allow connected members advertise only the address prefixes which they have registered publicly. If your prefix has a valid RPKI ROA, it will be accepted.

If the RPKI ROA check result is unknown (you have not yet set up a ROA), we fall back to the IRRDB test. (For details see filtering policy.)

If a prefix has no valid ROA or is not correctly registered in the IRRDB, it will not be accepted.

Use the “Filtered Prefixes” tab in the LONAP Portal, and the Route Server Looking Glass to determine if any prefixes are being filtered, or if you are approaching the maximum prefix limit.

Communities

Route server participants may 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 transit customers via the route servers, or if you do not wish to peer with some networks as a matter of policy. The filtering logic is expressed with the use of BGP communities. Large communities also allow prefixes to be prepended towards specific peers from the route servers.

Action	Standard Communities	Large Communities
Send prefixes to all other route server participants (default)	`8550:8550`	`8550:1:0`
Send prefix to route server participant with specific ASN	`8550:`ASN	`8550:1:`ASN
Do not send prefix to route-server participant with specific ASN	`0:`ASN	`8550:0:`ASN
Do not send prefix to any other route server participants	`0:8550`	`8550:0:0`
Prepend to specific peer AS once	-	`8550:101:`ASN
Prepend to specific peer AS twice	-	`8550:102:`ASN
Prepend to specific peer AS three times	-	`8550:103:`ASN

Communities Notes

Example: To announce a prefix only to AS65001 and AS64500, tag the prefix with communities 0:8550 8550:65001 and 8550:64500
Example: To announce a prefix to all members, excluding AS64500, tag the prefix with community 0:64500
Large communities are evaluated before standard BGP communities.
Most members will want to send their prefixes to the route servers, and tag community 8550:8550 (or 8550:1:0) with them.
To avoid the limitations when using standard communities with 32-bit ASNs, we strongly recommend using only large communities (RFC 8092) if your router supports this.
The default behaviour if no communities are specified is to advertise all prefixes to all peers.
The RFC 1997 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 be advertised to LONAP peers, but that peers should not advertise to downstream or other external ASNs.
The community logic is identical for IPv4 and IPv6 peering.

Cisco Configuration Example

    ip bgp-community new-format

    ! Example: Locally originated prefixes
    ip as-path access-list 10 permit ^$

    route-map LONAP-RS-OUT
        match as-path 10     ! or however you prefix filter
        set community xxx    ! send all default is 8550:8550

    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


    router bgp 123
        no bgp enforce-first-as    ! - very important for route servers

    ! Your address-family setup may differ slightly

    neighbor LONAP-RS peer-group
    neighbor LONAP-RS description LONAP MLP IPv4
    neighbor LONAP-RS remote-as 8550

    address-family ipv4
     neighbor LONAP-RS route-map LONAP-RS-OUT out
     neighbor LONAP-RS route-map LONAP-RS-IN in
     neighbor LONAP-RS send-community
     neighbor LONAP-RS maximum-prefix 120000
    exit-address-family

    neighbor 5.57.80.1 peer-group LONAP-RS
    neighbor 5.57.80.2 peer-group LONAP-RS

    address-family ipv4
      neighbor 5.57.80.1 activate
      neighbor 5.57.80.2 activate
    exit-address-family

    neighbor LONAP-RS6 peer-group
    neighbor LONAP-RS6 description LONAP MLP IPv6
    neighbor LONAP-RS6 remote-as 8550

    address-family ipv6
     neighbor LONAP-RS6 route-map LONAP-RS6-OUT out
     neighbor LONAP-RS6 route-map LONAP-RS6-IN in
     neighbor LONAP-RS6 send-community
     neighbor LONAP-RS6 maximum-prefix 50000
    exit-address-family
     
    neighbor 2001:7f8:17::1 peer-group LONAP-RS6
    neighbor 2001:7f8:17::2 peer-group LONAP-RS6
   
    address-family ipv6
     neighbor 2001:7f8:17::1 activate
     neighbor 2001:7f8:17::2 activate
    exit-address-family

Resource Public Key Infrastructure (RPKI)

Using cryptographically verifiable certificates, RPKI allows IP address-holders to specify which Autonomous Systems (ASNs) are authorised to originate their IP address prefixes. With RPKI, BGP route announcements received from a router are validated to make sure that the route is coming from the legitimate resource holder and that it is a valid route.

Enabling RPKI and creating Route Origin Authorisation (ROA) objects for your prefixes is done with the relevant RIR.

All RIRs provide a hosted RPKI service to make the process of implementing RPKI straightforward.

For prefixes allocated by RIPE NCC, it is simple to enable RPKI and create the relevant ROAs for your prefixes via the RIPE NCC RPKI Dashboard (requires LIR login).

Enabling RPKI and creating ROAs requires no changes to your existing network configuration.

Once created, it is important to maintain valid ROAs to ensure prefixes are accepted by the route servers:

The LONAP Portal includes tools to identify any prefixes being filtered by the route servers, and why.
The RIPE NCC RPKI Dashboard features automatic alerts if invalid or unknown announcements are detected globally.

Further information on RPKI

The following links provide more detail on RPKI, including tools and examples for enabling RPKI validation in your own network for customer and peer prefixes.

RIPC NCC: Resource Public Key Infrastructure (RPKI)
- Everything you need to get started.
NLnet Labs: RPKI Documentation
- An excellent overview and FAQ. Links to tools and further resources.

Filtering Policy

LONAP’s Route Server filtering policy is based on the BIRD2 route server configuration developed by IXP Manager:

Drop small prefixes – longer than /24 for ipv4 and longer than /48 for ipv6.

Drop all well-known martians and bogons.
Private and reserved addresses defined by RFC 1918, RFC 5735, and RFC 6598

Ensure there is at least 1 ASN and less than 64 ASNs in the AS path.

Ensure the peer ASN is the same as the first ASN in the AS path.

Drop any prefix where the next-hop IP address is not the same as the peer IP address. This prevents prefix hijacking.

Drop any prefix with a well-known transit network ASN in the AS path.

Ensure that origin ASN is in set of ASNs from the client’s IRRDB as-set.
(If no as-set is specified, all prefixes must originate from the peer ASN.)

If the prefix is evaluated as RPKI valid, accept.

If the prefix is evaluated as RPKI invalid, drop.

If the prefix is evaluated as RPKI unknown (no ROA exists), revert to standard IRRDB prefix filtering:

Every origin ASN must be listed as a member: in your as-set: (AS Macro) in the IRRDB.

There must be a route: or route6: object with a correct origin: ASN for the prefix to be accepted. LONAP route servers accept more-specifics of IRRDB prefixes, however we strongly recommend a route: object for every prefix you intend to advertise.

Note: If you publish prefix information in more than one IRRDB (e.g. RIPE, RADB, ALTDB, ARIN) you will need to let us know to use these sources.

As an added safeguard to protect against configuration errors, a maximum prefix limit is also enforced. This is set to 100 by default for members only advertising a few prefixes.

For members advertising more prefixes, the maximum prefix count is based on IPv4 prefixes from PeeringDB, or as we observe from the collector router. (Some members set the actual number of prefixes at PeeringDB, while others set a maximum prefix limit.)

The route server will shut down the BGP session if the maximum prefix limit is exceeded.

Use the “Filtered Prefixes” tab in the LONAP Portal, and the Route Server Looking Glass to determine if any prefixes are being filtered or if you are approaching the maximum prefix limit.

Example IRRDB objects

route[6]: object at RIPE:

route: 192.0.2.0/24 
descr: Awesome Networks 
origin: AS65001 
mnt-by: AWESOME-MNT
source: RIPE 

as-set (AS-Macro) object at RIPE:

as-set:         AS-AWESOMENET
descr:          Awesome Networks Ltd
members:        AS65001
members:        AS112
members:        AS…
tech-c:         AWS651-RIPE
admin-c:        AWS651-RIPE
mnt-by:         AWESOME-MNT
source:         RIPE

Notes

We recommend that any network with an open multi-lateral peering policy, do connect to the route servers.
During the provisioning process, LONAP Support will check RPKI and IRRDB information, and provide guidance as needed.
Maximum prefix recommendations change occasionally. We update this in PeeringDB here
- For automation purposes, use the PeeringDB API to obtain this information in a machine-readable form. JSON)
There are many tools and integrations available for automation and router configuration with peeringDB.
For automation, we support the IX-F JSON export schema and update various RIPE objects.
- See the Resources section in the LONAP Portal (login required).
Use the route server looking glass for prefix information and debugging. (Logged-in members can view more up-to-date prefix information.)