Announce Your Own IP Block via BGP on a VDS: Step by Step

To announce your own IP block with BGP from a VDS, you need four things in place: an ASN, a prefix registered to you, a matching RPKI ROA and IRR route object, and a BGP session from the VDS to your provider's router. Get the registry data right first and the session itself takes a few minutes. Get it wrong and the session comes up but your prefix is filtered, which is the most common support ticket in this area.

This guide walks through the order of operations, using documentation ranges (192.0.2.0/24, AS64496) so you can swap in your own values.

What you need before you start

If you hold the ASN and prefix through a sponsoring LIR or another organization, the ROA and route objects are usually created by whoever controls the resource in the RIR portal. Sort that out early, because it is often the slowest part.

Step 1: Confirm ownership in the RIR database

Look up your resources and check that the organization, status, and maintainer details are current:

whois -h whois.arin.net "n 192.0.2.0/24"
whois -h whois.ripe.net -- "-r AS64496"

Use the registry that actually holds your resource. Check that the contact details are valid, because ownership checks typically rely on them or on the RIR's own authentication.

Step 2: Create the RPKI ROA

A Route Origin Authorization (ROA) states which ASN is allowed to originate a prefix and how specific it may be. Networks that perform route origin validation will drop announcements that contradict it.

Create the ROA in your RIR's RPKI dashboard with these fields:

• Prefix: 192.0.2.0/24
• Origin ASN: AS64496
• Max length: 24

Set max length to the length you will actually announce. If you plan to announce only the /24, max length 24 is right. Setting it higher than needed lets an attacker announce more-specific routes that still validate as yours.

Do the same for IPv6, for example 2001:db8:100::/48 with origin AS64496 and max length 48.

Step 3: Create the IRR route object

Many providers still build prefix filters from IRR data. Create a route object (and route6 for IPv6) in the IRR database that is appropriate for your resource:

route:      192.0.2.0/24
origin:     AS64496
descr:      Example network
mnt-by:     EXAMPLE-MNT
source:     RIPE

route6:     2001:db8:100::/48
origin:     AS64496
descr:      Example network
mnt-by:     EXAMPLE-MNT
source:     RIPE

The source: line must match the database where you created the object. Also make sure your ASN has an aut-num object. If you have your own AS-SET, keep it current. Otherwise the upstream will build your filter from the ASN itself.

Step 4: Verify the data before you ask for a session

Check that the ROA is visible and valid. Public tools such as RIPEstat, bgp.tools, or a local validator like Routinator or rpki-client will show the status. You want to see "valid" for the prefix and origin pair. Then confirm the route object shows up in a public IRR query:

whois -h whois.radb.net 192.0.2.0/24

Registries can take some time to publish new ROAs, so don't be alarmed if it isn't visible right away. Wait until it is, then continue.

Step 5: Request BGP on the VDS

On a Nixcon VDS you can announce your own ASN and prefix from a BGP session on the server. Before enabling it, you choose the type of service:

• BGP announcement without DDoS protection
• BGP announcement with DDoS protection
• Full routing table, or only Nixcon routes if you don't need the full table

Nixcon validates the ASN and prefix ownership automatically using RPKI ROAs and the official RIR and IRR records, then adds your ASN to the AS-NIXCON AS-SET. Provisioning is automated, so there is no manual back-and-forth if your registry data already matches. You can see the available options on the BGP-enabled VDS page.

Nixcon operates AS40368, so that is the neighbor ASN you will peer with. Use the neighbor address and session details you receive for your VDS. The ones below are placeholders.

Step 6: Prepare the VDS

Put an address from your prefix on a local interface so the server answers for it. A dummy interface keeps this separate from the management address:

ip link add dummy0 type dummy
ip link set dummy0 up
ip addr add 192.0.2.10/32 dev dummy0

Using a /32 on the interface and announcing the /24 from the routing daemon is a common pattern. If you want to use many addresses from the block, add them the same way, or route them to other VMs behind this host.

To make this persistent, add it to your distribution's network configuration (netplan, systemd-networkd, or ifupdown).

Step 7: Configure BIRD

BIRD 2 is a common choice. Install it from your distribution's repositories and use a configuration like this. The addresses 203.0.113.10 (your VDS) and 203.0.113.1 (the neighbor) are placeholders:

router id 203.0.113.10;

protocol device {}

protocol kernel {
    ipv4 { export none; import all; };
}

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

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

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

protocol bgp nixcon {
    local 203.0.113.10 as 64496;
    neighbor 203.0.113.1 as 40368;
    ipv4 {
        import filter import_upstream;
        export filter export_mine;
    };
}

A few notes on this config:

• The static route with blackhole is only there to give BIRD something to originate. Traffic to individual addresses is still delivered through the more specific /32 on the dummy interface.
• The export filter announces only your prefix. A missing export filter is how people accidentally leak routes they learned from their provider.
• If you chose "Nixcon routes only", the import side will be small. If you chose the full table, make sure the VDS has enough memory for it before you enable it. Importing the full table into the kernel is not required for every use case, so decide whether you really need it.
• Add a similar protocol bgp block with ipv6 channels for IPv6.

Load the config and check the session:

birdc configure
birdc show protocols
birdc show route export nixcon

You want the protocol in Established state and your prefix listed in the export.

Step 8: Verify the announcement from outside

Once the session is up, check the announcement from places you don't control:

1. Use the Nixcon looking glass to query the BGP route for 192.0.2.0/24 and confirm it is present, with AS64496 as origin.
2. Run a ping and a traceroute from the looking glass locations (İzmir, Frankfurt, and the US) to an address in your block.
3. Check a public route collector or RIPEstat for the prefix to see whether it has spread beyond your upstream.
4. Re-check the RPKI status. It should read "valid" for the announced prefix.

If traffic reaches the VDS, check that the source address of outgoing packets is from your block when you want it to be. You can force that per route or per application:

ip route replace default via 203.0.113.1 src 192.0.2.10

Be careful with this on the primary interface. Test it from the console, so a mistake doesn't lock you out of SSH.

Common mistakes

• ROA max length too short. If the ROA says /23 and you announce a /24, validation marks it invalid. Match the announced length.
• Wrong origin ASN in the ROA or route object. It must match the ASN in your local ... as line.
• IRR object in the wrong database. An object in one registry may not be read by the filters your upstream uses. Check the source: line.
• Announcing something longer than /24 (IPv4) or /48 (IPv6). Most networks drop these.
• No address on the VDS. The route is announced, but nothing answers. Configure the address on dummy0 or lo.
• No export filter. You may re-announce routes learned from the upstream.
• Firewall blocking TCP 179 between the VDS and the neighbor.
• Testing too soon. Propagation, ROA publication, and IRR updates can lag. Wait and recheck before changing the config.
• Forgetting IPv6. A ROA for IPv4 does not cover your IPv6 prefix.

Protecting the announced block

Once your prefix is on the internet, attack traffic can find it. If you expect volumetric attacks, choose the DDoS-protected announcement option when you request the session, and review the DDoS protection and firewall options. Flow-based visibility from NixMon can also help you see what is hitting your prefix.

Summary

The order matters: confirm ownership, publish the ROA, create the IRR objects, verify both publicly, then bring up the session with strict filters. Most BGP problems on a VDS trace back to registry data that doesn't match the announcement. With clean data, the session itself is the easy part.