Technical

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 RPKI and internet routing registry data from the various IRR 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.

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 200000
    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 100000
    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:

1. Drop small prefixes – longer than /24 for ipv4 and longer than /48 for ipv6.
2. Drop all well-known martians and bogons.
   (Private and reserved addresses defined by RFC 1918, RFC 5735, and RFC 6598)
3. Ensure there is at least 1 ASN and less than 64 ASNs in the AS path.
4. Ensure the peer ASN is the same as the first ASN in the AS path.
5. Drop any prefix where the next-hop IP address is not the same as the peer IP address. This prevents prefix hijacking.
6. Drop any prefix with a well-known transit network ASN in the AS path.
7. 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.)
8. If the prefix is evaluated as RPKI valid, accept.
9. If the prefix is evaluated as RPKI invalid, drop.
10. If the prefix is evaluated as RPKI unknown (no ROA exists), revert to standard IRRDB prefix filtering:
    1. Every origin ASN must be listed as a member: in your as-set: (AS Macro) in the IRRDB.
    2. 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 maximum prefixes from PeeringDB, or as we observe from the collector router. 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: 192.0.2.0/24 
descr: Awesome Networks 
origin: AS65001 
mnt-by: AWESOME-MNT
source: 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.)

Further Reading / Resources

• RIPE 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.
• BGP Filter Guide A simple guide to ISP BGP Filtering by NLNOG
• MANRS: Mutually Agreed Norms for Routing Security
  Tutorials, guidance and papers on filtering and routing security for network operators.
• PeeringDB A global directory of network operators, IXPs and facilities, supporting APIs for automation.
• RFC 7947: Internet Exchange BGP Route Server