BGP Server: What It Is, Who Uses It, and Requirements

A BGP server is a virtual or physical server whose hosting network lets you run a BGP session with your own ASN and announce your own IP prefixes from it. Instead of renting addresses from your provider, you bring your own IP block, and the provider carries it to the internet on your behalf.

This guide explains how that differs from a normal VPS, who actually needs one, the main use cases (anycast, multihoming, IP portability), and what you must have in place before ordering.

What makes a server a "BGP server"?

Any Linux box can run a BGP daemon. What makes a server a BGP server is the network around it. The provider must:

• Accept a BGP session from your server (usually eBGP multihop or a direct session over a dedicated VLAN or tunnel).
• Validate that you are allowed to announce the ASN and prefixes you send.
• Propagate those prefixes to upstreams and peers.
• Optionally send you routes back: either only the provider's own routes, or a full routing table.

On your side, you run a routing daemon such as BIRD or FRRouting. It peers with the provider, announces your prefixes, and applies filters. Your applications then bind to addresses from your own block.

A regular VPS gives you one or a few IPs that belong to the host. If you leave, you give them back. With a BGP server, the IPs belong to you and move with you.

Who uses BGP servers?

• Hosting companies and resellers that want to number customer VMs from their own address space.
• Game server operators who need stable IPs for players and want to move traffic between locations without renumbering.
• Networks with their own ASN that need a small footprint in another region without building a full POP.
• Anycast service operators running DNS, CDN edges, or API gateways.
• Security-conscious teams that want to put DDoS-protected transit in front of their own prefixes.
• Engineers and students who want a real BGP lab with real internet reachability.

If you only host one website and have no ASN, you do not need this. A standard VDS is simpler.

Use case 1: IP portability

Provider-assigned IPs are tied to the provider. If you move, you renumber: new DNS records, new firewall rules, new allowlists at your customers' sites, and a reputation reset for mail.

With your own prefix, migration looks different:

1. Build the new server and bring up the BGP session at the new provider.
2. Test with a small test address from the same block.
3. Announce the prefix from the new location.
4. Withdraw it from the old one.

Clients keep the same IPs. Downtime is limited to BGP convergence, which is typically short but not instant. Lower your expectations accordingly and plan a maintenance window for critical services.

Use case 2: Multihoming

Multihoming means announcing the same prefix through more than one upstream, so one provider failure does not take you offline. A BGP server can be one leg of that design.

A common pattern: your main infrastructure connects to Provider A, and a BGP server at Provider B announces the same block as a second path. You control which path is preferred using AS-path prepending or local-pref on your side where applicable.

Things to plan for:

• Asymmetric routing. Traffic may arrive via one provider and leave via another. Stateful firewalls hate this. Design for it or keep state out of the path.
• Consistent announcements. Announce the same prefix lengths everywhere, or the more specific one wins globally.
• Origin ASN consistency. Use the same origin ASN, and make sure your RPKI ROA covers every origin you use.

Use case 3: Anycast

Anycast means announcing the same prefix from several locations. Routers send each client to the topologically nearest instance. It suits DNS, NTP, lightweight APIs, and edge proxies.

A minimal setup on each node:

# Put the anycast service address on loopback
ip addr add 192.0.2.1/32 dev lo

# Verify the service listens on it
ss -lntu | grep 192.0.2.1

Your BGP daemon announces 192.0.2.0/24 (the covering prefix) only while the local service is healthy. A simple health-check approach:

#!/bin/sh
# Withdraw the route if the service is down
if ! dig +time=1 +tries=1 @192.0.2.1 example.com >/dev/null 2>&1; then
    birdc disable anycast_v4
else
    birdc enable anycast_v4
fi

Run it from cron or a systemd timer, or use a dedicated tool such as ExaBGP-style health checks. The key point is that a dead node must stop announcing, otherwise users are sent to a black hole.

Anycast works best for stateless or short-lived connections. Long TCP sessions can break when routing shifts between nodes, so test before putting stateful workloads on it.

Requirements checklist

Before ordering a BGP server, make sure you have these:

Prefixes are tested against ownership. With Nixcon, ASN and prefix ownership is verified automatically using RPKI ROAs and official RIR/IRR records, and your ASN is added to the AS-NIXCON AS-SET. Setup is automated, so you do not need to wait on a manual ticket for each step. Other providers differ, so ask how they validate before you order.

Choosing session options

Most BGP server offerings vary on two axes:

• Protected or unprotected announcement. A DDoS-protected announcement routes your prefix through filtering. An unprotected one is plain transit. Choose based on your threat model. Game servers and public-facing services usually want protection.
• Routes received. You can get only the provider's routes, or a full routing table. Only-provider routes are lighter on memory and CPU. A full table is useful for labs, route analysis, or complex policy, but needs enough RAM and a daemon configured for it.

Nixcon Group LLC offers BGP-enabled VDS and VPS servers with these options. Our network is AS40368, with locations in Izmir (Turkey), Frankfurt, and Fremont, California.

A minimal BIRD sketch

This is only to show the shape. Use documentation values and replace them with your own.

router id 198.51.100.10;

define MY_ASN = 64496;
define PROVIDER_ASN = 64511;

protocol static announce_v4 {
    ipv4;
    route 192.0.2.0/24 blackhole;
}

filter export_to_provider {
    if net = 192.0.2.0/24 then accept;
    reject;
}

protocol bgp upstream {
    local as MY_ASN;
    neighbor 203.0.113.1 as PROVIDER_ASN;
    multihop 2;
    ipv4 {
        import all;
        export filter export_to_provider;
    };
}

The export filter matters most. It guarantees you only announce what you own. For import filters, bogon filtering, and RPKI validation, see a full BIRD 2 configuration guide.

Common mistakes and fixes

Session stays in Active or Connect. Check the neighbor IP, ASN, and multihop/TTL settings. Confirm a firewall isn't blocking TCP 179. Test with nc -vz 203.0.113.1 179.

Session is up but the prefix is not visible on the internet. Usually a missing or invalid ROA, a missing route object, or a prefix longer than /24 (IPv4). Check public looking glasses. Nixcon runs one at lg.nixconllc.com for BGP route, ping, and traceroute queries from Izmir, Frankfurt, and the US.

Prefix visible but no traffic reaches the server. The server needs a local route for the block, usually a dummy or loopback interface, plus correct rp_filter and forwarding settings. Verify with ip addr, ip route, and tcpdump -ni any host 192.0.2.1.

Accidentally leaking routes. Always use an explicit export filter that rejects by default. Never export routes learned from your provider back to it.

Wrong ROA max length. If your ROA says /24 max and you announce /25, it is RPKI-invalid and will be dropped. Match the ROA to what you announce.

Full table overwhelms a small VM. Size RAM accordingly, or ask for provider-only routes instead.

Do you need DDoS protection with it?

If your prefix is public and attracts traffic, yes, consider it. An attack against one address in your block can saturate the path to everything. Pair your BGP server with DDoS protection and firewall so attack traffic is filtered before it reaches your session.

Summary

A BGP server gives you control that a normal VPS cannot: your own IPs, your own routing policy, and the ability to move or replicate services across locations. You need an ASN, a properly registered prefix, a valid ROA, and enough BGP knowledge to write safe filters. Start with a single prefix and a small test, verify it in a looking glass, and then expand to multihoming or anycast.