The Beginner’s Guide: ASN Setup

So your organisation has acquired an ASN Number and the IP Address Space or is seriously thinking about it.

But you are not sure what are the next steps to ensure the global visibility of your ASN and IPs in BGP?

We regularly get these questions from our clients, so we understand how frustrating and confusing this subject can be at first.

In this guide, we are going to be focusing on the RIPE (registry) side configuration, rather than the BGP router setup, that hopefully, your network team have under control. However, if you need help with your router setup, we offer a reasonably priced BGP implementation service. Contact us for details.

We’ve prepared this actionable guide to show you precisely what needs doing to get you up and running quickly. 

We are also going to be introducing some tools to help you validate the results, and as a bonus, we’ve prepared a downloadable checklist so that you can keep yourself organised as you read this guide.

Sign up for an IP Transit

First of all, for your organisation to announce a BGP route, you need an upstream provider to establish a BGP session and exchange routes.

The upstream provider could be an ISP or a hosting company where you host your servers.

As part of the service often called the “IP Transit”, they will provide you with a BGP session.

However, this guide is not going to attempt to make a recommendation on upstream providers as these vary from country to county, and it is impossible to cover all the options available to you. 

If your organisation already holds an ASN number, then hopefully your upstream providers are already decided. Otherwise, you are encouraged to do your research separately.

As you are going to learn, sooner or later, your upstream providers employ some kind of a route filtering, on the BGP session with you. They do this to ensure that you only announce them the networks registered to your organisation.

This practice is to protect the rest of the internet from what is technically known as a “route leak“. And it happens when a network operator advertises a route of another network operator that they are not authorised to advertise, and hijack the traffic destined for that network.

Now, with this introduction out of the way, let’s focus on the actual steps for you to follow.



Setting Up a new ASN


Create a PeeringDB profile

Quoting directly from PeeringDB’s website:

PeeringDB is a freely available, user-maintained, database of networks, and the go-to location for interconnection data. The database facilitates the global interconnection of networks at Internet Exchange Points (IXPs), data centers, and other interconnection facilities, and is the first stop in making interconnection decisions.

So, seriously before you do anything else, you should create a PeeringDB profile for your organisation.

Some of the tools that we are going to be introducing later depend on your organisations having a PeeringDB profile, to display proper information. Also, if you are thinking of peering on an Internet Exchange, then PeeringDB is a must.

While the process is pretty straight forward, it requires manual verification, to link your ASN to your PeeringDB account. So, please make sure that your email address is correct in the RIPE whois database before you proceed.

The point worth mentioning is that you will come across the option for specifying route prefix-limit. Some providers use these on their BGP sessions to limit how many prefixes you can advertise to them before disabling the BGP session. This is yet another layer of protection against the route leaks.

Our advice here is to start with something like 25 even if you are announcing just a single route. The reason for this is that you are likely to quickly forget that you’ve set this up and it has the potential to cause issues later.

Create IRR route objects

Internet Routing Registry (IRR) is a database used to record a connection between a route (IP Address Space) and the originating ASN number.

At the time of writing of this blog post, all the Regional Internet Registries (RIRs) except for LACNIC, so namely RIPE, APNIC, AFRINIC, and ARIN run their IRR databases.

These databases are available to their respective resources holders only. So, too put this in perspective, as an example, RIPE routes can be registered in RIPE IRR (part of RIPE WHOIS), but not in APNIC IRR.

As previously mentioned, LACNIC does not have its own IRR database, and its resource holders should be registering their routes in one of the following third-party IRRs:

  • RADb (commercial)
  • NTTCOM (available to NTT clients only)
  • ALTDB (free, but takes time for new maintainers to be approved)

Additionally, these third-party databases accept routes from all RIRs, so it would be acceptable to register RIPE routes in RADb as an example.

However, you should use a local RIR’s IRR database as much as possible for the best results, as some network providers ignore one or more of these third party databases.

The route objects in the RIPE whois look like this:

route for IPv4

route: 185.88.213.0/24
descr: LIR SERVICES
origin: AS17818

route6 for IPv6

route6: 2a0a:6500::/48
descr: LIR SERVICES
origin: AS17818

So, route and route6 attributes describe the network address for IPv4 or IPv6, respectively, and the origin describes the originating ASN.

The descr attribute isn’t displayed on the object creation screen by default, and you got to add it from the dropdown when creating the object. The reason for adding the descr attributes is that it is used as a network name by some tools (such as the HE BGP Toolkit) that we are introducing later.

To create the route objects follow these direct links to the RIPE whois database. You would need to login to your RIPE account.

create a route object for IPv4
create a route6 object for IPv6

And populate the form as in the example below:

Creating a route object in RIPE whois

Check and update your Routing Policy statements

The import and export statements describe your Autonomous Systems routing policy. These are written in the RPSL (Routing Policy Specification Language), which is defined in RFC4012. While not a common practice anymore, some network providers may still rely on these to create their BGP filters and authenticate peering relationships.

We suggest that you create and keep these up to date.

If your organisation already has an ASN, you would remember that as part of your original ASN registration, you have provided details of two peering partners (usually upstream providers). RIPE then had used this information to create the routing policy statements that may look like this:

import: from AS47950 accept ANY
export: to AS47950 announce AS17818

While the above statements relate to IPv4 only, some network providers for simplicity build both IPv4 and IPv6 filters based on these statements. However, this isn’t always the case, so we also recommend creating mp-import and mp-export that were specifically introduced to support both IPv4 and IPv6 protocols.

The final example would look like this:

import: from AS47950 accept ANY
export: to AS47950 announce AS17818
mp-import: afi ipv6.unicast from AS47950 accept ANY
mp-export: afi ipv6.unicast to AS47950 announce AS17818

For you to update these, you would need to edit your ASN (aut-num) entry in RIPE.

To do this, go to the RIPE Whois, search for your ASN, and click on the “update” button.

For simplicity, we suggest that you do this update in the “text area” mode.

Edit RIPE object in text area

Create RPKI Route Origin Authorisation

Resource Public Key Infrastructure (RPKI) is a cryptographic method of signing route objects that associate BGP route announcement with originating ASN number. RPKI is defined in the RFC6480

The RPKI was created to work around some limits of IRR, which does not validate the origin ASN of the announcement, technically allowing a network to announce somebody else’s IP blocks.

To create an RPKI Route Origin Authorisation (ROA), you would navigate to the RPKI Dashboard.

Please note, however, that this option is available to PI (Provider Independent) resource holders only. If you are leasing you IPs from a provider such as LIR SERVICES, you would need to ask your provider to create the ROAs. We automatically create these for all our clients.

Create an AS-SET

This step is entirely optional, so feel free to skip it if it doesn’t apply to you.

AS-SET is an object that groups multiple ASN numbers together. It can then be used by other networks (i.e. upstream providers) to generate BGP filters, to allow routes from multiple ASNs on a single BGP session.

It is going to be super handy if your organisation decides to provide IP Transit as a service to clients at a later date or partner with another network to provide a backup connection for each other.

Whatever your plans are, our opinion is that it is still worth creating an AS-SET with just a single ASN, as it can save you quite a bit of time in the future on contacting your upstream providers to request this change.

If you decide that AS-SET is right for you, please remember to update your Routing Policy created in one of the previous steps to reflect this.

Note: Starting in 2023, it is no longer possible to create non-hierarchical (i.e., AS-MYCOMPANY) AS-SETs in the RIPE database. This is to prevent potential crashes between different IRR databases. You would need to create a hierarchical AS-SET, such as AS17818:AS-MYCOMPANY, instead.

You will use the AS-SET name (our’s is AS17818:AS-ALL) instead of your ASN number on the export filters, like in the following example:

export: to AS47950 announce AS17818:AS-ALL
mp-export: afi ipv6.unicast to AS47950 announce AS17818:AS-ALL

To create an AS-SET use the following direct link:

creating an AS-SET in RIPE whois

Please note that you would need to add the members attribute from the dropdown manually as it isn’t displayed by default.

Creating an as-set object in RIPE whois

Configure Reverse DNS

You may also want to set up the reverse DNS records for your networks. These will be necessary if you plan to host mail servers.

RIPE validates DNS servers configuration as part of the setup process, so you would need to meet some specific conditions. These are, quoting directly from RIPE’s website:

  • Make sure you set up at least two name servers that are authoritative for the zone.
  • Ensure that the servers are at least in different subnets, but preferably in different networks that are geographically distributed.
  • The resolvable names of these name servers should be in the NS resource records of the zone.
  • The SOA resource record (RR) should have the same content, both serial number and other data, on all the nameservers.
  • The SOA should contain a valid ‘RNAME’ (the contact address).
  • The timing parameters should be reasonable.

The reverse DNS is controlled by the domain object in RIPE whois.

create a domain object

If your organisation does not host own DNS servers, or if your DNS provider does not support reverse DNS zones, we can provide hosted Reverse DNS for an annual fee of 60 EUR per IP Block. Our hosted Reverse DNS comes with an admin panel to manage the revdns zone. If this is of interest, get in touch today.

Talk to your upstream providers

That’s it! We’ve covered all the technical steps, and it is the time to talk to your upstream providers and ask some questions. And optionally let them know what your AS-SET is.

We suggest that you download our FREE ASN checklist before you talk to your providers as it will help you formulate the right questions and record the answers.

The questions that you should ask:

  • Do you build BGP filters automatically or manually?
  • If automatically, how often do you update the filters?
  • If manually, can you build them based on the AS-SET, or you need a list of prefixes? How often do you make manual changes?
  • Do you enforce any prefix limits on the BGP sessions? How is it updated, and what is our current limit? Ask if updating it automatically from the PeeringDB is possible.

These should hopefully cover the most common scenarios, but if you find something else worth mentioning here, that comes up in discussion with your provider, please let us know so that we could update this guide.

Validate your annoucements

So now that you followed all these steps, it would be helpful to validate that your announcements are working as expected. For this, we are introducing a few tools.

However, please bear in mind that most of these tools aren’t real-time so it may take a few hours to a few days for these to pick up your announcements.

RIPE Stat – RIPE’s own statistical tool; contains some handy functions, such as Routing Status and Visibility. Just search for your own ASN. Data is updated a few times a day.

Hurricane Electric’s BGP Toolkit – Our go-to tool for general informaion on any given ASN. Displays peering information and network prefixes advertised. Updated daily, but may take a few days to show up initially.

PeeringDB – A database of networks and their interconnections. Ideal for finding facilities where a given network is present. You’ve hopefully listened to us and created a profile for your ASN by now!

BGPmon – a tool used to monitor your BGP prefixes, and send email notifications on unusual events such as prefix hijack, change of AS path, or a transit provider. It can also monitor RPKI ROA status.

Looking Glass – these can help you validate if your routes are being properly seen by various networks in real-time, however, the output might be a little bit difficult to read at first. Google your upstream provider’s name + “looking glass”, and give it a go.

Conclusion

Thanks to this guide, you’ve got everything that you need to get started in one place, and it hopefully saves you some time, and you found it useful.

Before you start implementing these steps, make sure to share this guide on your favourite social media.

Now that your IPs are visible in BGP you may also want to read our Network Administrator’s Guide to IP Geolocation to ensure that their location is recognised properly.

Oh, and remember to download our free ASN checklist.

The Network Administrator’s Guide to IP Geolocation

IP geolocation is a term used to identify or estimate the geographic location of an IP address and therefore a location of specific device that uses that IP address.

This guide is meant for network operators and assumes that your organisation already has IP address space that you want to geolocate, but if that isn’t the case, LIR SERVICES is a trusted provider of IP Address Lease and ASN Registration.

Importance of IP geolocation

For the most part, many services depend on knowing the user’s location to work correctly. Some examples are:

Relevant Content – among others, Google uses the IP geolocation to serve search results targeted to the user’s location. This way, when you search for, let say “bakery”, you will see results targeted for your current location. The same goes for Ads. You are more likely to see an Ad for businesses in your area rather than those from miles away.

Language-Specific Content – at the same time, many multilingual websites use the IP geolocation to serve pages in a particular language based on the IP country of origin. Unless you are in Poland or fluent in Polish, you probably wouldn’t want to see your pages displayed in Polish and prices in PLN.

Content Restrictions – Netflix, BBC iPlayer, are examples of services that employ restrictions based on IP geolocation. That happens mainly due to content licencing restrictions. Anyhow, ever tried watching iPlayer from outside of the UK? Well, it doesn’t work!

Local Legislation – IP geolocation can help to ensure regulatory compliance in certain jurisdictions. One example of this is GDPR in the European Union that requires the website owners to display a specific notice to their EU based visitors, but not necessary to everyone else.

Access Control List – some websites are known to limit access or even completely ban visitors from certain countries – all due to an increased risk of abuse, such as hacking from these less reputable jurisdictions.

Fraud Prevention – credit card processors use the IP geolocation and attempt to match that with the billing address of a cardholder in their fraud prevention decision-making process.

Sources of IP geolocation data

Hopefully, by now, you understand the benefits of the IP geolocation and why it is essential for your business whether you are an ISP or a hosting provider. Lets now look at the sources of IP geolocation data, and available providers.

Initially, information about the IPs was kept in RIRs (Regional Internet Registry) whois databases such as the RIPE Whois Database and was maintained by the organisation that owned the IP addresses, such as the ISPs.

For this purpose, a country attribute on the inetnum and inet6num objects was made available. So network operators could set something like,

whois record showing the country attribute

There was no provision to define a more accurate location such as a city, knowing that the end user’s location generally differs from registered administrative contact location of an ISP making the accuracy of the geolocation data low.

To work around the shortcomings of the country attribute, RIRs introduced a new geoloc attribute to the inet(6)num objects. This attribute takes a form of GPS coordinates, so as an example a network located in Tokyo, Japan would use

whois record showing the country and geoloc attributes

However, it is essential to mention that at the time of writing this post, the method isn’t authoritative and the geoloc attributes may be ignored in case that the conflicting data exists in more reputable sources.

IP geolocation Databases

At the same time, several IP geolocation services appeared on the market. There are free and paid databases among them. The general idea is that if you are building a service that depends on precise geolocation of your users, then you likely need access to their entire database, which usually comes with a price tag attached. Still, these databases highly depend on the accuracy of the IP data that they provide to their customers, so the details relating to your IP address space can be corrected free of charge.

The following databases are known to be in operation:

All of the above databases use various sources to estimate the location of any given IP. Some of these sources are:

Whois Databases – previously mentioned Regional Internet Registry, that includes data about the country of registration, the GPS coordinates from geoloc whois attribute.

Data supplied by the users – some websites such as weather forecast take the user’s postcode, and share alongside the IP address with one or more of the IP geolocation providers.

Data supplied by the ISPs – many ISPs submit this data to IP geolocation services voluntarily to ensure that their clients get content tailored to their location. 

Routing Information  – several techniques such as automated traceroute are employed to map the connections of various infrastructures on the internet. The maps are then used to estimate geolocation.

Updating IP geolocation Databases

As you hopefully appreciate by now, your business can not rely on the accuracy of data in just as single of these databases, and you should contact all these providers to ensure that your IP geolocation data is correct across the board. That makes perfect sense knowing that it is hard to tell which website uses which of these databases.

To save you time we have prepared the below contact information for all the previously listed providers.

DatabaseContact
GeoLite2 by Maxmindrequest form
Googlerequest form
IP2Location[email protected]
DB-IP[email protected]
IPinfo[email protected]
NetAcuity IP by Digital Envoy[email protected]
NeuStar IPintelligence[email protected]
ipapi.co[email protected]
ipgeolocation.io[email protected]
BigDataCloud[email protected]
ipregistry[email protected]
EurekAPI[email protected]

Geofeeds

Self-published IP Geolocation Data or simply a Goefeed, is an advanced topic. The first thing to mention is that the Geofeed is currently a draft and not an approved RFC. This fact, however, did not stop the internet community from embracing the concept. The first version of the draft was published in 2013, so it has been around for a while.

The Geofeed allows network operators to publish the IP geolocation for the IP blocks that are under their control. The feeds are published in the CSV format and contain the following information:

ip_range,country,region,city,postal_code

The idea is that the content providers will be able to process changes to your IP space geolocation automatically, based on the Geofeed that you publish, which saves you time on having to contact these providers individually to notify of any changes.

Unfortunately, currently, no standardised mechanism for advertising your feed to the rest of the world exists. A few ideas were proposed, such as the NAPT records in the reverse DNS zone, but in reality, the network operators still share the Geofeed URLs with interested parties via an e-mail.

As a side note,  LACNIC now offers a hosted Geofeed for network operators from within their service region. That might be easier than hosting the Geofeed on your servers for some.

Now, it isn’t straightforward to tell which content providers support the Geofeeds – and we haven’t heard of anyone other than Google admitting they support Geofeed publically. Interestingly Google came up with the idea of Geofeed originally. The point is that even if a list of content providers that support Geofeeds existed, it would be a lot of work to contact all these providers to have them poll your Geofeed for updates regularly.

Finally, the Geofeeds are much easier to administer than the geoloc entries. The Geofeeds are just a flat file that can be edited at speed. At the same time, geoloc entries are troublesome to manage at scale (i.e. when you subdivide IP blocks that are then in use at different locations) as they require separate objects in the whois databases.

Provider Support

So hopefully understand by now, most of your IP geolocation efforts should be centred around the IP geolocation databases as these databases are de facto the standard today. We’ve also coverer the geoloc attributes in the RIR whois databases and the self-published Geofeeds.

So what we did next was that we reached to all the previously listed IP geolocation database providers to ask about their support for geoloc attributes and the self-published geofeeds. Here is what we found…

Providergeolocgeofeed (update interval)
MaxMind? [0]Y (Ad-hoc)
IP2LocationN [1]N [1]
DB-IPYY (Weekly)
IPinfoYY (Daily)
Digital EnvoyYY (Weekly)
NeuStar?Y (Weekly)
ipapi.coYY (Daily)
ipgeolocationYY (Daily)
BigDataCloudYY (Daily)
ipregistryYY (Daily)
[0] Maxmind did not respond to our queries by the time this post was published.
[1] IP2Location confirmed that they specifically discontinued geoloc and geofeeds support and now rely mainly on routing information because of abusive usage to manipulate location by certain organisations. Still, they remain a reputable geolocation provider and can not be neglected.

If you are an IP Geolocation provider and haven’t been included in this blog post, contact us using our contact form. When reaching out to us, please include the company name, the URL, the client-facing support e-mail or an update form URL as well as whether you support Geofeeds and the poll interval offered.

Final words…

So there you have it: everything you need to know about having your IP address space geolocated correctly. We hope that this guide has helped you to understand everything you need to know about IP geolocation and why it is essential to your business. 

We appreciate that this is a lot of work to liaise with all these providers, so for all our IP Address Lease clients, we include initial submission to all the IP geolocation databases free of charge.

As a final note, please bear in mind that an up to date entry in all the IP Geolocation databases does not guarantee that your IP Address Space will be recognised appropriately everywhere. This happens because some content providers download the updates from the IP Geolocation databases less frequently than others. If this happens to you, our advice is to contact the specific content provider and ask them to download the IP Golocation updates.

Becoming a RIPE LIR in 2021

This blog post was updated in December 2020 after the RIPE NCC published the Billing Procedure for 2021.

This blog post was also previously updated in November 2019 to reflect that RIPE has now run-out of IPs and currently operates a waiting list for a single /24 instead of previous allocation size of /22.

What is an IP Address Run Out

IP Exhaustion or IP Address Run Out is a term that is used to describe the depletion of unallocated IPv4 addresses. The unallocated IPv4 address space refers to IP addresses that haven’t been allocated to anyone and could be requested by organisations such as your business.

Benefits of becoming an LIR

RIPE membership comes with the following benefits:

  • A final allocation of a /24 (256 IP addresses) of IPv4 address space
  • Allocation of up to a /29 of IPv6 address space
  • Ability to self sponsor your ASN and PI address space (and save on current sponsoring LIR fees)
  • Ability to attend RIPE NCC Training Courses
  • Ability to attend the RIPE NCC General Meetings and vote candidates to the RIPE NCC Executive Board
  • Two tickets to RIPE meeting event (€350 value each) – however, due to ongoing COVID situation, both RIPE meetings in 2020 were virtual and so will be the RIPE 82 in May 2021.

RIPE Fees

In 2021, RIPE will continue to charge a one-time Sign-Up Fee of €2,000 (excluding VAT), and the Annual Membership Fee of €1,400 (excluding VAT). The VAT at the Dutch rate of 21% is charged where applicable.

The Annual Membership Fee covers a period from January to December. Therefore in your first year of membership, you can expect the Annual Membership Fee to be pro-rated based on the quarter in which your LIR account was opened. As an example, for an LIR account opened in July, the first year’s Annual Membership Fee would be €700 (excluding VAT) for the months from July to December.

In subsequent years Annual Membership Fee will be invoiced in February will cover a whole year, and cost €1,400 (excluding VAT).

There was previously an option available to split the Annual Membership Fee into four quarterly instalments of €350 (excluding VAT), but as of 2019, this option is no longer available.

IP Allocation

With IPv4 address exhaustion around the corner, we understand that your primary motivation on becoming an LIR is the final allocation of a /24 (256 IP addresses) of IPv4 address space.

On 25th November 2019 RIPE has run out of IPv4 addresses, and implemented the following changes:

  • The allocation size was reduced from a /22 to a /24 (so reduction from 1024 to 256 IP addresses)
  • RIPE continues to recover small amounts of IPV4 addresses for foreseeable future
  • A waiting list for IPv4 allocation was created, and allocations of recovered IPv4 addresses will be made on a first-come, first-served basis.

So what this means is that new LIRs requesting a /24 IPv4 allocation will put on the waiting list, and the IPs will be allocated as they are reclaimed by RIPE from networks that return their resources.

IP Address Lease

An alternative worth considering would be leasing the IP addresses from a provider such as LIR SERVICES

Let’s take a look at both of these options and how they perform cost-wise.

First YearNext Years
LIR Membership€3,400€1,400
LIR SERVICES IP Address Lease€1,500€1,250
Savings on IP Lease€2,150€150

Becoming an LIR for a single allocation of /24 would currently cost you €3,400 (excluding VAT) in the first year, and then €1,400 every year after that. The first year fee includes the LIR Account Setup and the Annual Membership Fee.

In comparison, our IP Lease Service the annual cost of €1,250 for a /24 IP block and no setup fees. Simple, right?

So our IP Address Lease service offers an upfront saving of €2,150 in the first year (which is enough for almost another 2 years of IP Lease with us) and €150 in each year after as compared to current RIPE LIR fees.

It is also worth noting that our service will be a lot quicker too, as you won’t need to go through the lengthy LIR application procedure and wait on the waiting list for the IP allocation. Instead, you will be able to start announcing the IP block almost right away because the setup of an IP lease with us typically takes three business days on average.

Buying IPv4 Addresses

If you would rather buy IPv4 addresses, as opposed to leasing them, this is something that we can also assist with. We are a registered RIPE IPv4 Transfer Broker, and so we have all of the experience needed to put your mind at ease. Navigating the secondary market without expertise is not recommended. This is because there are a lot of scams out there and there are people who are selling IP addresses that have been blacklisted. This could be a disaster for your business.

A few things to consider are that taking this route may still require your organisation to sign-up for an LIR membership if you purchase PA (Provider Aggregate) addresses rather than PI (Provider Independent) addresses. The latter option only requires an LIR sponsor, such as ourselves.

Additionally, pricing isn’t as straight forward as with IP Address Lease, as there are additional costs of Due Diligence and Escrow to consider. Please do get in touch with us for more details.

Summary

Considering all the above-discussed options, before the RIPE IPv4 Address Run-out we strongly recommended becoming an LIR solely for the large IPv4 /22 allocation. Nevertheless, now with the new /24 policy in place, our recommendation has changed. 

As illustrated in this blog post, if your business is after a relatively small number of IPs (such as /24) we recommend our ASN Registration and IP Address Lease services that are more cost-effective than becoming an LIR in 2021.

If your organisation, however, is after a larger IP block, it might be worth considering purchasing the IP addresses on the aftermarket. We can certainly help with this.

Still, if your organisation sees the benefits of becoming an LIR, please consider our LIR Setup and fully Managed LIR services.