NovoServe BYOIP Integration Overview

This page provides a practical BYOIP (Bring Your Own IP) integration overview for NovoServe (novoserve.com). NovoServe explicitly supports—and publicly encourages—customers to announce their own IPv4/IPv6 prefixes under their own ASN on the NovoServe network so that workloads running on NovoServe bare metal can keep stable egress/ingress IP reputation and identity.

Important framing: NovoServe’s BYOIP model is a classic BGP-based provider announcement approach for dedicated servers / bare metal (not a hyperscaler control-plane “import prefix” feature). NovoServe’s network team provisions the BYOIP setup (including creating a virtual router instance and establishing a BGP session), and your organization remains responsible for typical “IP-holder duties” such as abuse policy handling and reverse DNS management for your own space.

Provider Details

BYOIP Overview (NovoServe model)

NovoServe’s BYOIP approach is based on BGP route origination for customer-owned prefixes. In practical terms:

• You obtain your own public IP space (IPv4 and/or IPv6) and typically your own ASN.
• You prepare routing authorization artifacts (ROA/RPKI and IRR route objects) per provider guidance.
• NovoServe provisions a virtual router instance and establishes a BGP session to your environment so your prefixes can be announced under your ASN on NovoServe’s network.
• Your NovoServe servers then use your IP space for services (e.g., VPN egress IP stability, mail/IP reputation continuity, brand trust, migrations without IP renumbering).

Technical & Administrative Requirements

Based on NovoServe’s published BYOIP guidance, you should plan for the following prerequisites before requesting BYOIP enablement:

• IP resources: Your own IPv4 and/or IPv6 prefix(es). Provider guidance indicates a /24 or larger for announced IP blocks.
• ASN: Your own ASN is recommended/encouraged for announcing your prefixes under your own routing identity.
• Routing authorization: Provider guidance indicates IRR route objects and RPKI ROA creation is mandatory for their standard onboarding flow.
• LoA fallback: If ROA creation is not available (e.g., broker cannot support RPKI), provider guidance indicates you must provide a Letter of Authorization (LoA). Provider guidance also states LoA is required for ASNs.
• Operational responsibility: Provider guidance states you are responsible for your own abuse policy and typically also for DNS/rDNS management for your IP space.

Onboarding Process (High-level)

The following sequence mirrors NovoServe’s published BYOIP onboarding flow and adds practical operator context where appropriate:

Configuration Notes for Operators

Because NovoServe provisions the BGP session on their side, your core tasks are typically: (1) ensuring routing authorization is correct (ROA/IRR), and (2) ensuring your edge/router is ready to exchange routes safely. Below is a vendor-neutral checklist you can apply to most BYOIP-with-BGP engagements.

• Confirm session parameters: exchange ASN details, peering IPs, and any session security requirements (e.g., MD5) with NovoServe networking.
• Prefix filtering: ensure you only advertise the exact prefix list authorized for the session; avoid accidental more-specific leakage.
• RPKI posture: keep ROAs aligned with your intended origin ASN; NovoServe’s guidance indicates ROAs help their automated systems announce quickly.
• Multi-site planning: if you deploy across multiple NovoServe data centers, plan subnet allocation per provider guidance (do not assume a subnet can span multiple sites; allocate at least one /24 per location).
• Abuse/rDNS readiness: have an internal process for abuse desk handling and PTR/rDNS workflows before you migrate sensitive services (mail, ads, VPN, etc.).

Example (generic) BGP prefix policy logic: advertise only your authorized prefixes; reject everything else. Adapt to your routing stack as needed.

# PSEUDOCODE (generic idea)
# OUTBOUND: allow only your BYOIP prefixes, then deny all
permit OUT 203.0.113.0/24
permit OUT 2001:db8:1234::/48
deny   OUT any

# INBOUND: accept only what you intend to learn (typically default or full-table per contract),
# and apply max-prefix / dampening policies as required.

Operations & Monitoring

After cutover, treat the BYOIP environment as production routing infrastructure:

• Validate reachability: use looking glass / traceroute views to confirm Internet pathing toward your prefixes from multiple regions.
• Track route hygiene: continuously monitor ROA validity and IRR consistency (route leaks and RPKI-invalid announcements can cause reachability issues with strict networks).
• DDoS posture: NovoServe states dedicated servers include always-on DDoS protection; confirm expectations and escalation path for larger threat models.
• Change control: manage prefix adds/removals as formal changes (update ROAs/route objects first, then request routing changes), and document rollback steps.

Deprovisioning / Offboarding

When retiring BYOIP from NovoServe (or migrating to another provider), plan a clean withdrawal to avoid prolonged blackholing or reputation harm:

FAQ

Official NovoServe Resources