Vultr DocsLatest Articles

Vultr IP Prefix Onboarding Process and Timeline

TL
Updated on October 14, 2024
Vultr IP Prefix Onboarding Process and Timeline header image

Introduction

Vultr enables customers to bring their own IP prefixes and advertise them using Border Gateway Protocol (BGP). This document outlines the necessary steps and timelines for onboarding IP prefixes to Vultr.

Route Origin Authorization (ROA)

Route Origin Authorization (ROA) is a digital certificate that specifies which Autonomous System Number (ASN) is authorized to advertise a particular IP prefix. It is crucial for securing internet routing, as it prevents unauthorized ASNs from hijacking or misrouting traffic by ensuring only valid ASNs can announce specific IP ranges.

Before onboarding, it is recommended to create a Route Origin Authorization (ROA) for the IP prefix. The ROA must be signed with your public Autonomous System Number (ASN). If you are using a private ASN assigned by Vultr, it must be signed with AS20473 ensuring that the traffic is routed correctly within Vultr's network. Any ROA signed with a different ASN will be rejected by Vultr's system as invalid.

Note
Please note that multiple ROAs can be created for a single prefix, allowing different ASNs to be authorized to announce the same IP block. This flexibility can be useful for redundancy or multi-homing, ensuring that traffic can be routed through various networks if needed.

Route Object

Route object is an entry in an Internet Routing Registry (IRR) that defines how a specific IP prefix should be routed on the internet. It links an IP prefix to an Autonomous System Number (ASN) and indicates which networks are authorized to advertise that prefix. By registering a route object, you help prevent unauthorized entities from advertising your IP prefixes, which can protect against potential routing hijacks or misconfigurations.

Before onboarding, it is recommended to create a route object in an Internet Routing Registry (IRR). If a route object is not created, Vultr will automatically generate one in RADb. Vultr accepts route objects from the following IRRs: RADb, ARIN, RIPE, and APNIC.

Vultr Onboarding Process

  • Prefix Request: When a customer requests to add a prefix, Vultr performs various verifications, including checks against Spamhaus listings, ROA validity and others. If any issues are found, such as an invalid ROA, a warning will be displayed in the customer GUI, prompting corrective action before re-adding the prefix.

  • Confirmation Process: If the prefix passes initial verification, an email is sent to the prefix’s point of contact (POC) as listed in the Regional Internet Registry (RIR). The email contains a link that must be clicked to confirm the prefix's entry into Vultr’s system.

  • Final Verification and Activation: After confirmation, the onboarding process may take an additional 24 to 48 hours for further verifications. If successful, the prefix is added to the customer’s account. If no route object exists, one will be created automatically, and if the customer is using a public ASN, the ASN will be added to RADB::AS20473:AS-CONE.

Onboarding a prefix for Bare Metal (BM) servers involves an additional step. Unlike Virtual Machines (VMs), which automatically add the prefix to host filters, customers must open a support ticket to specify which BM servers will be advertising the prefix. Please note that this subprocess is subject to the standard ticket response time.

Transit Provider Filtering

  • Filtering Timeline: Updates from transit providers may take between 6 and 48 hours, depending on their processes.

  • Filtering Types: Most transit providers filter AS20473 announcements using prefix lists and route maps derived from the information registered in RADB::AS20473:AS-CONE. Some local transit providers use prefix LOAs or registration systems to add prefixes to their filters.

    • Dynamic Filtering: Typically ready within 6 to 24 hours for providers using dynamic methods based on IRR objects.
    • Manual Filtering: May take longer (over 48 hours) for local transit providers using prefix LOAs or registration systems.

The table below outlines the process by region and country:

Region/Country Filter Type
US, Canada, Europe, Japan, South Africa Dynamic
Korea, Singapore, Australia, Latin America Dynamic for global transits and manual for local transit providers
India, Israel Manual

Prefix Lifecycle

Prefix Removal

  • Active Status: Once registered, listed in RADb, and transit filters are updated, the prefix remains active until one of the following occurs:

    1. The customer requests removal of the prefix.
    2. The ROA becomes invalid.
    3. Vultr determines, after investigation, that the prefix belongs to another entity.

  • Removal Process: The first two actions (customer removal request and ROA invalidation) are automated processes. In cases of ownership disputes, Vultr will contact both the customer and the party claiming ownership. If the claim is found valid, the prefix will be removed. Both the second and third actions generate customer support tickets.

Route Object Removal

Customers retain control over creating their own route objects in the IRRs mentioned above. If a customer chooses to create their own route object, they must contact Vultr to request the removal of the route object previously created by Vultr's maintainer in RADb.