BGP VDS: Announce Your Own ASN and IP Block from a VPS

A BGP VDS (also called a BGP VPS) is a virtual dedicated server that can run a BGP session with its provider, so you can announce your own ASN and IP block straight from the VM. Your addresses stay yours, they are reachable on the internet through the provider's network, and you can move them somewhere else later without renumbering anything.

This guide explains what a BGP-enabled VDS is, who actually needs one, what you gain compared with provider-assigned IPs, and how to set one up without the usual mistakes.

What a BGP VDS actually is

A normal VPS comes with IP addresses that belong to the hosting provider. If you leave, the addresses stay behind. A BGP VDS is different in one important way: the virtual server can speak BGP, so the IP space that appears on it is space you own (or are authorized to originate), announced under your own autonomous system number.

At Nixcon Group LLC, VDS servers run on VMware vSphere and operate inside our own network, AS40368. Our data center is in Izmir, Turkey, with points of presence in Frankfurt, Germany and Fremont, California. A customer with an ASN and a prefix can establish a BGP session from the VDS and announce that prefix into the network.

You are not renting a router. You are running a BGP daemon (BIRD, FRRouting, or similar) inside a Linux or BSD VM, and the provider handles the upstream side, filtering, and propagation.

Who needs a BGP VPS

Not everyone does. If you run a single website, provider IPs are fine. BGP starts to make sense in these situations:

• Small networks and hosting startups with their own ASN. You have an allocation from a RIR, but no router, no transit contract, and no rack space. A BGP VDS lets you get your block on the internet without buying hardware.
• Game server operators. Players and attackers both target IPs. If your game servers sit on your own prefix, you can change where the traffic lands without telling players to connect to a new address.
• IP lessors and resellers. If you lease addresses to customers, you need a place to originate them from.
• Anyone who wants provider independence. Changing hosts normally means renumbering, updating DNS, notifying customers, and waiting out TTLs. With your own prefix, migration is a routing change.
• Labs and learning environments. Testing BGP policy, RPKI, or anycast designs on real internet routes is far more instructive than a simulator.
• Services needing stable, whitelisted IPs. Partners and payment APIs often whitelist by IP. Owning the block means those entries survive a hosting move.

Advantages of announcing your own space from a VM

Portability. The prefix follows you. Moving from one provider to another is an announcement change, not a migration project.

Control over addressing. You decide how to subnet, which addresses go to which services, and what reverse DNS says (subject to the delegation of your block).

Reputation you control. IP reputation is tied to your block, not a shared pool. That cuts both ways, so abuse handling is on you, but a clean block stays clean.

Flexible protection. Because the traffic arrives over BGP, you can choose whether the prefix is announced with or without DDoS filtering in front of it.

Real routing visibility. You can see which routes you receive, check how your prefix is seen from different places, and debug with real data instead of guesswork.

Options on a Nixcon BGP VDS

On our BGP-enabled VDS servers you pick the combination that fits your use case:

• BGP announcement without DDoS protection: plain origination of your prefix.
• BGP announcement with DDoS protection: your prefix is announced through the protected path.
• Full routing table: if you want it, the session carries the full table. Otherwise you receive only Nixcon routes, which is lighter and enough for many setups.

Provisioning is automated. Ownership of your ASN and prefix is verified automatically against RPKI ROAs and official RIR/IRR records, and once validated, your ASN is added to the AS-NIXCON AS-SET so the rest of the network accepts your announcements.

Before you order: prerequisites checklist

1. An ASN. Obtained from your regional registry (ARIN, RIPE NCC, APNIC, LACNIC, AFRINIC), directly or through a sponsoring organization.
2. An IP prefix. In practice, IPv4 announcements need to be /24 or shorter, and IPv6 announcements /48 or shorter. Anything more specific is usually filtered by networks around the world.
3. A route object in the IRR for each prefix, with your ASN as origin.
4. A ROA in RPKI authorizing your ASN to originate the prefix, with a maximum length that matches what you plan to announce.
5. Correct registry contacts. Make sure the organization and maintainer data are current, because validation compares against them.

The examples below use documentation values: AS64496, 203.0.113.0/24, and 2001:db8:100::/48. Replace them with your own.

Example: BIRD 2 configuration

First, put an address from your block on the VM so the services have something to answer on. A dummy or loopback interface works well:

ip link add dummy0 type dummy
ip link set dummy0 up
ip addr add 203.0.113.10/32 dev dummy0
ip -6 addr add 2001:db8:100::10/128 dev dummy0

Then configure BIRD to originate the prefixes and export only those:

router id 192.0.2.10;

protocol device { }

protocol static originate4 {
    ipv4;
    route 203.0.113.0/24 blackhole;
}

protocol static originate6 {
    ipv6;
    route 2001:db8:100::/48 blackhole;
}

filter export_v4 {
    if net = 203.0.113.0/24 then accept;
    reject;
}

filter export_v6 {
    if net = 2001:db8:100::/48 then accept;
    reject;
}

protocol bgp upstream {
    local as 64496;
    neighbor 192.0.2.1 as 40368;   # placeholder: use the peer address from your provisioning
    ipv4 {
        import all;
        export filter export_v4;
    };
    ipv6 {
        import all;
        export filter export_v6;
    };
}

The blackhole static route is a common way to originate a prefix: it creates the route BGP needs without sending traffic anywhere locally. Specific addresses on dummy0 are more specific than the blackhole, so local traffic is still delivered correctly.

If you take a full table, make sure the VM has enough memory for it and tighten the import filter to drop bogons and your own prefixes.

Check the session and what you are announcing:

birdc show protocols
birdc show route export upstream
birdc show route count

When the session is Established and the export list shows your prefix, check from outside. The Nixcon looking glass offers BGP route, ping, and traceroute queries from Izmir, Frankfurt, and US locations, so you can confirm your prefix is visible and see the path traffic takes to reach it.

Common mistakes

Announcing without a matching ROA. Networks that do RPKI route origin validation will mark your route invalid and may drop it. Create the ROA before you announce.

ROA max-length mismatch. If your ROA allows only /24 and you announce two /25s, they are invalid. Announce exactly what the ROA covers.

Leaking routes you learn. Without an export filter, a BGP daemon might send learned routes back to your upstream and turn you into an unintended transit. Always use an explicit export filter that accepts only your own prefixes, as in the example above.

Missing IRR route objects. Provider filters are built from IRR data. If no route object exists for your prefix and origin ASN, the announcement may not propagate.

Forgetting the host firewall. BGP uses TCP port 179. If your VM firewall drops it, the session never comes up. Also confirm that reverse path filtering (rp_filter) is not discarding traffic for your own addresses.

Announcing a prefix with no live address behind it. Traffic arrives and goes nowhere. Bring up at least one service address before you announce.

Ignoring IPv6. If you have a v6 block, announce it too. Many clients prefer IPv6 when it is available.

Where DDoS protection fits in

If your prefix attracts attacks, filtering at the edge matters more than anything on the VM itself. The protected announcement option sends your traffic through our DDoS protection and firewall path. If you already host elsewhere but own an ASN and prefix, NixGuard Edge delivers clean traffic to your network over a GRE tunnel, with AS-SET support. For visibility into what is happening before and during an attack, NixMon provides flow-based monitoring and DDoS detection.

Summary

A BGP VDS gives you the benefits of owning your address space without the cost and effort of building your own router infrastructure. Get your ASN, prefix, IRR route object, and ROA in order, announce only what you own, filter your exports, and verify the result from outside your network. After that, your IPs are yours wherever you decide to host them.