Vultr DocsLatest Content

Peering Policy

Updated on 17 October, 2025
Discover how to interconnect with Vultr AS20473, including peering requirements, technical criteria, and mutual benefits for networks.
Peering Policy header image

Interconnect with Vultr AS20473

This document describes how and where to interconnect with Vultr AS20473, including requirements and other factors that may affect how we peer with third parties.

Vultr has a selective settlement-free peering policy. Vultr will peer with other organizations based on several factors including:

  • Current and anticipated traffic levels between the networks.
  • Number of sites where both peers are present.
  • If there is mutual benefit to proceed with the peering.
  • If the peer complies with our technical and legal requirements.

Vultr will review this peering policy periodically and reserves the right to modify this policy at any time.

Public Peering Policy

Vultr maintains active peering sessions with Internet Exchange Point (IXP) route servers (RSs) at all peering locations. Networks already peering with the RSs receive the same routing information as would be provided through a direct public peering session. Due to Vultr’s network topology, only local routes are advertised at each IXP. Therefore, requests for additional public peering are generally unnecessary.

Public peering requests may be considered under the following conditions:

  • The requesting network does not peer with the relevant IXP RSs, or
  • The requesting network peers with the RSs but does not announce a complete routing table.

Exceptions may be made at Vultr’s discretion in accordance with our selective peering policy.

Private Peering Policy

We recommend configuring private peering when traffic between autonomous systems is more than 3 Gbps and have at least two sites in common. The cost of in-building cross-connects will be shared equitably between Vultr and the peer. Interface IP addresses will be assigned by both peers in accordance to best common practices. The minimum link speed for private peering interconnections is 10Gbps. Private peering facilities are listed in our PeeringDB entry. Both peers will periodically review bandwidth and upgrade as required.

Vultr Peering Information

Peering Process

Peers that would like to establish a settlement-free peering, either private or public, will follow the next process:

  1. Review and agree to this policy, including technical and legal requirements, before contacting AS20473
  2. All peering requests should be sent to peering@Vultr.com indicating your ASN, places to peer, and, if public peering, including your IP addresses.
  3. Vultr analyzes the request.
  4. We evaluate peering requests monthly and answer all the requests with a positive or negative answer.

We will analyze your peering request to determine eligibility for it, and we reserve the right to decline any peering request based on our criteria. We are not required to provide a specific reason to decline a peering request. We also reserve the right to eliminate any established peering at any moment in time.

Technical Requirements

  1. The peer must have a complete and up-to-date entry on PeeringDB.
  2. The peer prefixes must be registered in at least one of the well-known public Internet Routing Registries.
  3. The peer must provide their BGP communities list.
  4. The peer must not advertise our prefixes to transit providers.
  5. The peer must not advertise to us other than own and customer prefixes.
  6. The peer must provide their contact for their 24x7 NOC, which has to be knowledgeable enough to provide technical support for any event that could arise.
  7. The peer must accept that AS20473 will selectively withdraw prefixes from public IXP as needed to protect service quality.
  8. The peer should operate a dual-stack (IPv4 and IPv6) network.
  9. The peer should inform in advance of scheduled maintenance windows.
  10. Peers are encouraged to provide their blackhole communities if available.
  11. Peers are encouraged to implement Mutually Agreed Norms for Routing Security (MANRS).
  12. RPKI invalid prefixes will not be accepted.

We do not require contracts or agreements in order to establish a peering session, nor we will enter into one for public peering.

Comments