ServerSP BYOIP Integration Overview
This page outlines the technical and procedural information required for integrating Bring Your Own IP (BYOIP) concepts with ServerSP infrastructure (Bare Metal / Dedicated Servers, VPS, and Virtual Data Center). ServerSP productizes BYOIP as “Bring Your Own IP (BYOIP) - IP Announcement BGP Peering”, enabling customers to use their own IPv4/IPv6 prefixes on ServerSP resources while maintaining IP portability and reputation.
ServerSP’s BYOIP model is Miami-only: prefixes are announced and routed exclusively through ServerSP’s Miami, Florida data center, but with global reachability via multiple upstream providers. ServerSP supports customers that either (a) bring their own ASN and announce prefixes using BGP, or (b) do not have an ASN and have ServerSP originate the routes under AS214456 (provider-origin model).
In practice, BYOIP with ServerSP is realized in three common patterns:
1. Customer-owned prefixes advertised using the customer’s ASN (BGP peering / classic BYOIP);
2. Customer-owned prefixes originated via ServerSP ASN (AS214456) when the customer does not have an ASN (sponsored-origin / provider-origin model);
3. Leased IPv4 resources (e.g., IPXO-leased blocks) announced through ServerSP once delegated correctly and accompanied by the required authorization artifacts (LOA + RPKI/IRR validity).
Provider Details
| Field | Information |
|---|---|
| Provider Name | ServerSP (BYOIP - IP Announcement BGP Peering) |
| Website | BYOIP - Bring Your Own IP | Miami Data Center | About Us (Legal / Company) | Contact / Support | Terms of Service (AUP / SLA) |
| Legal Entity | ServerSP LLC (Wyoming, USA). ServerSP states services are provided through its U.S. entity, with global operations. |
| ASN(s) |
AS214456 (SERVERSP-AS). ServerSP states customers may announce using their own ASN or have ServerSP announce under AS214456 when the customer lacks an ASN. PeeringDB lists SERVERSP-AS as a global-scope network with an open peering policy and a Looking Glass URL. |
| BYOIP Location / PoP | Miami, Florida (USA). ServerSP states all BYOIP and BGP announcement infrastructure is located in Miami and routes are announced/routed exclusively via this data center. |
| Data Center / Facility |
ServerSP states its infrastructure is hosted in Digital Realty MI1 (Downtown Miami). Address listed by ServerSP: 36 NE 2nd Street, Miami, FL 33132. ServerSP also publishes facility posture statements (e.g., Tier 1 provider connectivity, hurricane resilience) and compliance/security claims. |
| Looking Glass / Network Test |
Looking Glass: lg.serversp.com Network test endpoints published by ServerSP: - IPv4: 103.230.142.1- IPv6: 2a14:7581:c01:1::1
|
| Regions Supported |
Provisioning: United States (Miami PoP). Reachability: Global routing via multiple upstream providers (ServerSP describes “global BGP connectivity” and multiple upstreams), but the control-plane / origination is Miami-only. |
| Supported Services | ServerSP states BYOIP ranges can be used across: Bare Metal / Dedicated Servers, VPS, and Virtual Data Center. BYOIP prefixes can be routed to any ServerSP instance. |
| Support Contact |
Contact / Support (24/7 technical support) |
Submit Ticket (Client Portal) ServerSP also publishes a support-response target (infra issues handled within ~30 minutes) and states services are unmanaged (client responsible for management). |
| SLA (Published) | ServerSP publishes a 99.9% monthly uptime target for network and power, with a credit schedule in its Terms of Service. |
| Tech Article(s) ; Date |
BYOIP - Bring Your Own IP - BYOIP scope, ASN options, validation requirements, activation timeline, IPXO-leased block support. Miami Data Center - facility location, MI1 reference, address, network posture notes. PeeringDB: AS214456 (SERVERSP-AS) - peering policy, LG, scope metadata. |
Technical Requirements
| Requirement | Details |
|---|---|
| IP Version Support | IPv4 and IPv6 are supported for BYOIP. ServerSP states it will review ownership and routing-validity before announcement. |
| Prefix Size |
ServerSP does not publish a minimum prefix size on the BYOIP page. Industry baseline for global routability is typically /24 (IPv4) and /48 (IPv6); confirm exact acceptance and filtering with ServerSP during onboarding. |
| ASN Ownership Required |
Not strictly required. ServerSP states that if you don’t have an ASN, ServerSP can announce your prefixes using AS214456. If you do have your own ASN, ServerSP states you can announce using your ASN (classic BYOIP model). |
| IRR / Route Objects | ServerSP states it reviews IRR data as part of ownership/routing validation. You should ensure IRR objects correctly reflect prefix-to-origin authorization (your ASN or ServerSP ASN, depending on your model). |
| RPKI (ROA) | ServerSP states the IP space must be properly registered in RPKI. Practically, that means maintaining valid ROAs consistent with the intended origin ASN (your ASN or AS214456). |
| LOA (Letter of Authorization) | Required. ServerSP states BYOIP requires a valid LOA and that activation occurs after ownership validation + LOA receipt. |
| Routing Scope Constraint | Miami-only / ServerSP-only. ServerSP states BYOIP is available only within ServerSP’s network and prefixes are announced and routed exclusively through the Miami data center. |
| Abuse / Reputation Controls | ServerSP publishes Acceptable Use constraints (e.g., spam/phishing, malicious activity prohibitions) and states it applies security filtering on email ports 25/465/587 to protect network reputation (exceptions require support review). |
Step-by-Step BYOIP Process
A) Customer-owned prefixes with customer ASN (classic BYOIP / BGP peering)
Provision or identify the ServerSP service where the addresses will be used (Bare Metal, VPS, or Virtual Data Center) and open a technical support request to start BYOIP onboarding.
prefix list (IPv4/IPv6), your public ASN, and intended origin policy. Ensure your IRR route objects and RPKI ROAs are consistent with your ASN as origin.
If you are not operating a physical router, you can implement BGP using a virtual router (FRR/BIRD) on a dedicated server and peer from there.
Then route the usable addresses to the intended ServerSP instances (Bare Metal, VPS, or VDC) per your architecture.
monitor BGP session health and prefix visibility, document your intended origin/ROA/IRR state, and use ServerSP support for changes (add/remove prefixes, routing adjustments, withdrawal).
Open a BYOIP onboarding request with ServerSP support and specify that ServerSP will originate your prefixes under AS214456 (ServerSP states this is supported when you do not have an ASN).
Provide the prefix list (IPv4/IPv6) plus a valid LOA authorizing ServerSP to announce the space, and ensure the IP space has valid RPKI/IRR data consistent with the intended origin.
ServerSP states your prefixes can be routed to any ServerSP instance (Bare Metal / VPS / VDC).
If you later obtain your own ASN, plan a controlled migration of origin (update ROAs/IRR, coordinate cutover with ServerSP, and validate propagation) to move from provider-origin to customer-origin while preserving reachability.
Lease the IPv4 block from IPXO and ensure it is properly delegated to your organization with the required authorization artifacts (ServerSP states IPXO-leased resources are supported if LOA + RPKI data are valid).
Use IPXO’s delegated RPKI capabilities (where applicable) to generate the necessary LOA/ROA artifacts for safe routing, then submit the packet to ServerSP for validation.
announce using your ASN (if you have one) or have ServerSP originate via AS214456; align IRR and ROA maximum-length/origin accordingly to avoid invalid announcements.
Once active, deploy the leased addresses on ServerSP services and continuously monitor reputation/abuse signals; leased space is especially sensitive to reputation regressions and may require faster remediation workflows.
Cost and Limitations
| Item | Details |
|---|---|
| Fees | ServerSP does not publish a standalone BYOIP price list on the BYOIP page; onboarding is support-assisted and typically commercialized as part of ServerSP infrastructure services (Dedicated/Bare Metal, VPS, VDC). Use the ServerSP contact/support channel for pricing and feasibility. |
| BYOIP Geography | Miami-only. BYOIP prefixes are announced and routed exclusively through ServerSP’s Miami data center; BYOIP is not available “outside ServerSP’s infrastructure.” |
| Operational Model | Semi-manual onboarding. ServerSP validates RPKI/IRR + LOA, then activates configurations (stated 1-2 business days after validation/LOA). Day-2 control is via BGP (customer-origin model) and/or support requests (provider-origin model). |
| SLA / Availability | ServerSP publishes a 99.9% monthly uptime target for network/power (credit schedule in ToS). This does not eliminate your responsibility to design redundancy (multi-server, multi-region, backups). |
| AUP / Abuse Limitations | ServerSP ToS includes strong prohibitions against spam/phishing, malicious activity, botnets, DDoS participation, proxies/TOR relays (among others). ServerSP also states it applies filtering on outbound email ports 25/465/587 to protect reputation; approvals require review. |
Automation and Developer Access
- Client Portal ticketing: ServerSP provides a client portal (manager.serversp.com) for submitting tickets and managing services; BYOIP onboarding and changes are typically coordinated through support workflows.
- BGP as control plane: In the customer-origin model, automation is primarily BGP-driven (prefix advertisements, withdrawals, policy). Integrate your BGP speaker (physical or virtual router) into your IaC/automation stack (e.g., Ansible) for controlled rollouts.
- Observability: Use ServerSP’s Looking Glass plus external route collectors to validate propagation and detect accidental invalid/filtered announcements (often caused by ROA/IRR mismatches).
- Operational tooling: ServerSP publishes connectivity test endpoints and provides online tools for network operations; combine these with your monitoring/alerting for BGP session health and prefix visibility.
Abuse and Reputation Management
- You remain responsible for the reputation of your prefixes. Even when ServerSP originates your routes, abuse sourced from your workloads can cause filtering, ticket escalations, and potential service action under the ToS/AUP.
- Expect stricter controls for email-sending use cases: ServerSP states outbound ports 25/465/587 are filtered by default, with exceptions requiring review. Plan mail architecture accordingly (dedicated mail relay providers, warm-up, feedback loops).
- Maintain ROA/IRR hygiene: mismatched ROAs (wrong origin ASN or max-length) or missing IRR objects can cause route rejections or reduced propagation as more networks enforce RPKI-based filtering.