Tips for Peering

Tips for the Best Peering Experience

Tips for the best peering experience

Administration

Before you can "start using the Internet", it's important to have all BGP routing information registered correctly. Without the proper administration networks on the Internet might not accept your routes, and they won't be able to reach your network because of that.

The first step is updating your IRR (Internet Routing Registry), e.g. RIPE in Europe, ARIN for North America and APNIC for the Asia-Pacific region. Within your IRR's toolbox you can register various data that are used by third party systems, like route objects and policy objects.

For Internet Exchanges the following data are required to be setup:

  • Route Objects - Create to specify which ASNs are allowed to *originate* a prefix
  • AS-SET - Create to specify your AS cone (AS pyramid of all downstream networks)
  • RPKI - Create ROAs to specify which ASNs are allowed to *originate* a prefix, including its prefix length

Now that you won't have any trouble getting your routes accepted, the second step is to make sure your network's PeeringDB page is up to date to allow others to understand how to reach you. This goes for both your network as well as your peering team. PeeringDB is the main source of information used to figure out where to peer with whom. It also has the option to enter contact information so that others can get into contact with you regarding your peering relationship.

Use the Route Servers

The intent of an Internet Exchange is to provide a place where networks can reach each other directly and exchange traffic directly. To optimize the direct exchange of traffic, Internet Exchanges operate Route Servers with the specific purpose of aggregating all peer routes into a single BGP feed. This is often seen as the only purpose of Route Servers, but there are more.

With the advancements in BGP security, like RPKI and prefix-list checks, it's becoming more complex to fully manage your Internet routing. Ideally, every DFZ prefix (a prefix that does not require a default route to send a destination packet) received is checked to determine whether the originating peer is allowed to source that prefix. For many (smaller) networks these extra checks reduce the overall experience of peering, as they might not have the resources available to handle these extra tasks.

The NL-ix Route Servers perform all necessary BGP security checks to determine whether a route advertisement is valid or not, and will not advertise invalid routes to other peers.

Traffic Engineering using the Route Server

The default behaviour of the NL-ix Route Server is to advertise your routes to all other peers, and in turn you receive all other available routes. This is the original intent of a Route Server; to save you the time of setting up a BGP relation with all other peers while getting the benefits.

Having your routes advertised towards all other networks may however cause a suboptimal traffic flow due to BGP route selection. It's possible that you already have a PNI (Private Network Interconnect) with a network, but the BGP route selection algorithm keeps preferring the IXP route due to BGP attributes. For cases like that it's possible to inform the Route Server to take an action for you. This is done by using so called Action Communities; they signal a desired action to take.

The following Action Communities are supported by the NL-ix Route Servers:

  • Filter ASN - Do not advertise route towards a single ASN
  • Filter metro - Do not advertise route towards any peer in the metro
  • Prepend ASN - Prepend 1/2/3 times towards a single ASN

More information on all NL-ix Peering Communities can be found here

When to use them?

Note that when using Route Server communities for actions, you still have to implement the reverse action on your router to engineer how traffic flows the other way (if that is desired). The Route Servers provide Informational Communities to encode information onto a route that can be used by the receiving router to perform Traffic Engineering.

Route Server Dashboard

For those who prefer to use a web-based tool instead of working with BGP communities on router we have our Route Server Dashboard.

The Route Server Dashboard has a couple of unique features that make Traffic Engineering easier or possible in the first place.

  • Bilateral actions - In most cases an action should be applied in both directions. When filtering or prepending, actions set in the Dashboard will be applied bilaterally to limit the amount of work needed on a router.
  • Session-based - The available action communities work at ASN or metro level. From the Dashboard it's possible to engineer around specific BGP sessions instead, giving more control over networks present at multiple locations
  • Latency slider - With the NL-ix network spanning multiple countries, some are interested in keeping their latency to a minimum. With the slider peers outside of the chosen latency will be filtered out.
  • Filter presets - To make a quick selection of e.g. a country, you can use the pre-defined presets to filter a group of peers.

Anycast

Some networks use anycast to optimize traffic coming into their networks, for example to ensure that latency is minimized, or to pull traffic into their network as quickly as possible to have full control over the forwarding path. When anycasting prefixes, they become multi-homed.

Within a distributed Internet Exchange the concept of anycast becomes very valuable given that these kind of technologies deal with the same problem that distributed Internet Exchanges try to solve: optimize end-user latency to improve the quality of user experience.

Geo-redundancy

Given that most Internet Exchanges are located in a single metro, it's not possible to enjoy geo-redundancy like you could with for example a Transit upstream that is present in multiple countries.

With NL-ix' footprint it's possible to connect to the Internet Exchange network from multiple countries, providing the option to connect geo-redundantly. When connecting from any redundant location, you will be able to setup exactly the same peering relations as on your other router, with the only difference being your own IP address on the network.

* prepending/filtering (traffic engineering)

Set up bilateral sessions

Some networks are not available on the Route Servers for any reason. These are often larger networks that like to be in control themselves. As their routes are not available on the Route Servers, to exchange traffic with them directly it's necessary to set up bilateral BGP sessions with these networks. In that case you have a one-to-one relation with the network and exchange routes directly, without a Route Server in between.

Keep in mind that the Route Server BGP security check will not be performed on these bilateral BGP sessions. You are responsible to validate the received routes yourself.

Happy Peering!