Skip to content

Gcore BYOIP BYOIP Integration Overview

BYOIP SUPPORTER
ASN AS199524
IPv4 support
IPv6 support
LOA support
ROA support
Process Manual
Locations supported
Other: South Africa, Japan, Saudi Arabia, Singapore, South Korea, United Arab Emirates, Hong Kong, France, Germany, Ireland, Italy, Netherlands, Poland, Spain, Switzerland, United Kingdom, Canada, Mexico, United States, Argentina, Brazil, Chile, Colombia, Australia, New Zealand

Location

This page outlines the technical and procedural information for integrating Bring Your Own IP (BYOIP) with Gcore CDN (and, where relevant, Gcore’s DDoS/Super Transit network services). Gcore supports two main BYOIP models for CDN: (1) provider-announced BYOIP, where your IPv4 subnet (typically /24 or larger) is originated from Gcore’s ASNs and anycasted across their global CDN, and (2) customer-ASN (BYOASN), where you retain control of BGP announcements with your own ASN while still leveraging Gcore’s CDN and edge infrastructure.

Provider Details

FieldInformation
Provider NameGcore
Website Gcore CDN BYOIP feature  |  Bring Your Own IP (BYOIP/BYOASN) docs  |  Dedicated IP  |  Gcore CDN documentation
ASN(s) Global Gcore network is advertised from multiple ASNs, including (non-exhaustive):
AS199524 – G-Core Labs S.A. (hosting / CDN / network)
AS202422 – G-Core Labs S.A. (additional network footprint)
BYOIP announcements may use one or more of these ASNs depending on region and service design.
Regions Supported Gcore advertises a global edge network with 180–210+ PoPs across six continents. BYOIP for CDN is designed for global anycast coverage across these PoPs. Representative coverage includes:
North America: US (multiple cities), Canada, Mexico
Europe: UK, Ireland, Germany, France, Netherlands, Spain, Italy, Switzerland, Poland, Nordics, Eastern Europe
APAC & Oceania: Singapore, Hong Kong, Japan, South Korea, Australia, New Zealand
LATAM: Brazil, Chile, Argentina, Colombia and others
MEA & Africa: UAE, Saudi Arabia, South Africa and other regional PoPs
Exact PoP list and routing footprint for your BYOIP deployment are confirmed during solution design.
Support Contact Contact Sales (BYOIP / CDN)  |  Gcore Help Center  |  24/7 Technical Support (chat/ticket)  |  Email: sales@gcore.com, support@gcore.com
Tech Article & Date Bring Your Own IP to Gcore CDN – premium BYOIP feature (marketing page; describes /24 example, global anycast, provider-announced and BYOASN options).
BYOIP/BYOASN docs (high-level feature description).
CDN Dedicated IP and BYOIP update (blog; dedicated IP + BYOIP for CDN).
BYOIP Scope Gcore’s CDN-focused BYOIP feature supports two main patterns:
1) Provider-announced BYOIP (Gcore ASN): You supply a public IPv4 subnet (e.g. /24) that you own. Gcore validates ownership and announces this prefix from their ASNs across the Gcore CDN anycast network. CDN edge IPs seen by end-users and origin/SaaS allowlists are from your IP space rather than Gcore’s.
2) BYOASN / customer-ASN BYOIP: You bring your own ASN and keep BGP announcements under your ASN while integrating with Gcore’s CDN/edge network (design specifics agreed with Gcore). This model targets customers needing maximum control and strict routing/compliance policies.
BYOIP is positioned as a premium add-on for customers with security, compliance, branding, or IP-reputation requirements.
Supported Versions IPv4: Public IPv4 prefixes are the primary and explicitly documented case (e.g. /24 subnets for global announcement).
IPv6: Gcore operates IPv6 across parts of its edge / cloud network, but public BYOIP materials focus on IPv4 for CDN BYOIP. Treat BYO-IPv6 as “not publicly documented – require confirmation” at this time.
Supported Services BYOIP is currently described as a CDN feature, integrated with:
– Gcore CDN (HTTP/HTTPS content delivery)
– Anycast edge IPs used for CDN resource hosts and origin connections
In some designs, BYOIP can intersect with DDoS protection / Super Transit and IP transit where Gcore announces your prefixes and scrubs/forwards traffic, but the primary documented use case is CDN egress and allowlisting.

Technical Requirements

RequirementDetails
Prefix Size Gcore’s BYOIP page cites providing your own IP subnet “such as a /24 range” for global announcement. In practice:
Minimum (IPv4): Typically /24 for global routing and anycast (industry standard; confirm with Gcore if smaller or aggregated blocks are acceptable).
– Larger prefixes (/23, /22, …) can be partially used; you may choose which addresses in the block to map to CDN resources.
No explicit IPv6 prefix requirements are documented for CDN BYOIP as of now.
ASN Ownership Required Not required for provider-announced BYOIP: Gcore announces your subnet(s) from their ASNs and handles global routing.
Required for BYOASN scenarios: if you want your own ASN to be the origin for your BYOIP prefixes, you must already control an ASN and BGP setup; Gcore coordinates routing and CDN integration for that case.
IRR / Route Objects The public docs do not spell out IRR details, but standard practice applies when a provider originates your space:
– Your prefix must be correctly registered with an RIR (RIPE/ARIN/APNIC/etc.).
– Route/route6 objects and upstream IRR data must be consistent with the intended origin ASN (Gcore ASN for provider-announced, your ASN for BYOASN).
Gcore will typically validate ownership and routing policy before accepting the prefix into their network; any required IRR updates are handled by the customer.
ROA or LOA Gcore does not publicly publish a detailed ROA/LOA checklist for BYOIP, but in practice:
ROA: RPKI ROAs should be created or updated so that the correct origin ASN (Gcore ASN or your ASN) is authorized for the prefix; highly recommended for global routing robustness.
LOA: A Letter of Authorization is typically required when Gcore announces your space from their ASN, proving that they are allowed to originate and use your IPs on their CDN network.
Exact documentation is finalized during onboarding with Sales/Network Engineering.
RIR Limitations Prefixes must be globally routable public IP space, registered under a recognized RIR with clear WHOIS/RDAP records. There are no public RIR-specific exclusions, but:
– Space that is hijacked, disputed, or widely blocklisted will generally not be accepted.
– For regulatory-sensitive regions (finance, government), Gcore may apply additional due-diligence checks.

Step-by-Step BYOIP Process

Estimated Setup Time: Typically from a few business days to a couple of weeks, depending on RIR validation, BGP routing setup, and DNS / SaaS allowlist changes.

Tested By Us: Not yet

A) Provider-announced BYOIP (Gcore originates your subnet from its ASNs)

  • Engage Gcore Sales / Technical Account team to request the CDN BYOIP feature as a premium add-on. Define which services (CDN, possibly DDoS / Super Transit) will use your IP space and in which regions.
  • Provide details of your IP subnet(s) (typically IPv4 /24 or larger), RIR registration information, and proof of ownership (WHOIS, ROAs, and an LOA authorizing Gcore to announce and use the prefix).
  • Gcore validates ownership and routing policy, then configures BGP announcements for your prefixes from one or more Gcore ASNs across their global edge network (anycast where appropriate).
  • Gcore maps your CDN resources to use addresses from your BYOIP pool as the visible edge IPs for end-users and origin/SaaS allowlists. You update DNS and application configuration to reference these IPs or associated hostnames as needed.
  • Test globally: verify that traffic reaches your content through Gcore CDN but appears on the internet as coming from your IP space. Update SaaS, firewall, and partner IP allowlists, and then migrate production traffic incrementally.

B) BYOASN / customer-ASN BYOIP (you originate; Gcore integrates)

  • Ensure you control an ASN and suitable upstream connectivity (transit/peering) to originate your prefixes under your ASN according to your routing policy and ROAs.
  • Work with Gcore engineers to design how your BYOASN announcements and Gcore’s CDN edge will interoperate (anycast strategy, preferred paths, DDoS/Super Transit integration, GRE tunnels or other interconnects if applicable).
  • Announce your prefixes from your ASN as agreed, ensuring IRR / ROA data permits the intended routing. Gcore configures its CDN routing so that your IP space is used for CDN edge egress while respecting your policies.
  • Configure your CDN resources and DNS so that content is delivered via Gcore CDN but associated with your BYOIP addresses. Validate reachability, latency, and failover behavior across key geographies.
  • Roll out to production in phases, monitor performance and routing (BGP looking glasses, RIPEstat, etc.), and adjust announcements/communities in coordination with Gcore if you need fine-grained traffic engineering.

References: Gcore CDN BYOIP feature, BYOIP/BYOASN docs, Dedicated IP, Super Transit docs, DDoS Protection overview.

Cost and Limitations

ItemDetails
Fees Gcore positions CDN BYOIP as a premium add-on with manual setup support rather than a self-service toggle. Pricing is not publicly listed and depends on:
– Number/size of prefixes and regions
– Traffic volumes and CDN features (e.g. DDoS, WAAP, Super Transit)
Commercial terms are defined with Gcore Sales / Account Management.
Bundled or Standalone BYOIP is not a standalone transit offering. It is tightly integrated with:
– Gcore CDN (primary use case)
– Optionally Gcore DDoS / Super Transit and network protection for certain architectures
You consume it as part of a broader CDN/security deployment rather than buying “raw” IP transit.
Traffic/Peering Restrictions – BYOIP traffic always traverses Gcore’s edge network and obeys CDN/cache and security policies you configure.
– Gcore retains control over internal traffic engineering, peering, and backbone routing; you cannot arbitrarily dictate all paths, though advanced customers may coordinate BGP policy and communities.
– IP ranges must not be widely blocklisted or associated with abusive traffic; Gcore may require cleanup before accepting them into the platform.
Other Limitations – BYOIP currently focuses on IPv4 and CDN egress; BYO-IPv6 and deep cloud integration are possible but not formally described in public docs and should be validated with Gcore.
– Feature availability, SLAs, and routing behavior may differ between regions/PoPs.
– Some complex regulatory/compliance scenarios (e.g. very strict data-residency) require custom design and may not be supported everywhere.

Automation & Developer Access

  • API Access: Yes — every Gcore product (including CDN) is backed by public REST APIs. Once BYOIP is enabled, you can manage CDN resources, origins, and hostnames programmatically while continuing to use your BYOIP addresses.
  • Terraform: Official Terraform provider (G-Core/gcore) supports managing Gcore Cloud and CDN. You can codify CDN resources that use BYOIP ranges, though the initial BYOIP entitlement/onboarding remains a support-driven process.
  • IaC / Automation: Standard tooling (Terraform, Ansible, CI/CD) can orchestrate DNS, CDN configuration, and infrastructure that depends on your BYOIP addresses for allowlisting and compliance.
  • Logging & Monitoring: CDN logs and DDoS/Super Transit telemetry can be exported to external systems for monitoring how your BYOIP addresses are used and for troubleshooting routing or reputation issues.

Abuse & Reputation Management

  • Because you retain ownership of the BYOIP prefix, long-term IP reputation (blocklists, abuse complaints, RBL entries) remains your responsibility, even though Gcore carries and caches the traffic across their CDN and DDoS mitigation platform.
  • Gcore provides DDoS protection, WAAP, and security controls that help prevent abuse originating from your traffic, but they will expect you to maintain acceptable-use compliance and to coordinate any required delisting or remediation with external parties, using logs from both your systems and Gcore’s platform.

Gcore Homepage
Gcore CDN Product Page
Bring Your Own IP to Gcore CDN
BYOIP/BYOASN Documentation
Dedicated IP for CDN
Super Transit (BGP-based protection and acceleration)
DDoS Protection Documentation
Gcore API Overview
Terraform Provider: G-Core/gcore
Gcore Help Center

FAQ

BYOIP, or Bring Your Own IP, is a service that enables organizations to bring their own public IP addresses—whether owned outright or leased from an IP provider—into a service provider’s network infrastructure. Instead of relying on IP addresses assigned by the provider, BYOIP allows businesses to retain control over their IP resources. This ensures continuity, particularly for organizations with established IP-based reputations, branding, or dependencies on specific address blocks. IP providers can assist in streamlining this process, making it easy to integrate your IPs into the desired network environment.

BYOIP offers several compelling advantages. By using your own IPs, you can maintain continuity in your network’s identity, reduce the risk of disruptions to email deliverability or service recognition, and avoid reputational concerns associated with shared IPs. Additionally, BYOIP provides enhanced flexibility and control over your IP resources.

BYOIP is ideal for organizations that either own public IP addresses or lease them from a trusted IP provider with explicit BYOIP support. This includes enterprises, cloud providers, content delivery networks (CDNs), and businesses with compliance requirements or IP reputation needs. Working with a reputable IP provider ensures that leased IPs can be seamlessly integrated into another provider’s infrastructure without ownership concerns.

You must either legally own the IP addresses or have explicit authorization from a leasing IP provider to route and manage them. IP providers who offer BYOIP-ready IP addresses simplify this process, providing documentation and support to ensure compliance with regional internet registry (RIR) policies and service provider requirements. This collaboration ensures smooth implementation without any legal or operational issues.

To use BYOIP, you’ll typically need to present documentation verifying your authority over the IP block. This can include official records from a regional internet registry (RIR) such as ARIN, RIPE NCC, or APNIC. If you are leasing IPs, the IP provider should supply proof of their ownership and grant you permission for BYOIP. Providers that specialize in IP leasing often handle this paperwork for you, reducing administrative burden and ensuring compliance.

Yes, BYOIP is designed to be a secure and reliable solution. Reputable service providers and IP providers implement robust safeguards to prevent unauthorized use or hijacking of IP addresses. Security measures include BGP filtering, route validation, and advanced protocols like Resource Public Key Infrastructure (RPKI). By collaborating with a trusted IP provider, businesses can benefit from additional layers of protection, ensuring that only authorized traffic is routed through their IP blocks.

The setup process for BYOIP varies by provider, typically taking anywhere from a few hours to a few days. Factors include the complexity of your network, the verification process for IP ownership or authorization, and the time needed for global BGP route propagation. IP providers often expedite the preparation and validation stages, ensuring a smooth and timely integration into the desired infrastructure.

Absolutely. Many providers, in partnership with IP providers, support routing IPs across multiple data centers or geographic regions. This feature optimizes performance for global businesses by reducing latency and improving service availability. When working with an IP provider, you can also ensure that your leased or owned IPs are aligned with your geographic requirements for compliance and efficiency.

If you choose to discontinue BYOIP with a provider, your IP addresses will be released from their network, and routing will cease. You can then reallocate these IPs for use with a different service provider or project.