Additional addresses and routed subnets
Extra addresses arrive in one of two shapes, and configuring the wrong one is the single most common reason a new block does not work.
The two shapes
- On-link (on the same subnet as your main address)
- The extra addresses share your existing gateway. You add them to your interface and that is the whole job.
- Routed (a separate block pointed at your machine)
- We route the block to your server's main address. The gateway for that block is your own server, not ours. This is how larger blocks and anything you want to subdivide are delivered.
When we hand over addresses we tell you which kind they are. If you are not sure, ask before you configure — thirty seconds of question beats an hour of tcpdump.
Adding on-link addresses
To test immediately, without touching configuration files:
ip addr add 192.0.2.50/32 dev eth0
Note the /32. The subnet is already defined by your main address;
adding a second address with the full subnet mask is a classic way to break routing
on the machine.
Make it permanent in netplan, /etc/network/interfaces or an
nmcli connection depending on your distribution — an address
added with ip is gone at the next reboot.
Using a routed block
A routed block is yours to arrange as you like. The three normal uses:
- Straight onto the host. Add the addresses to a loopback or dummy interface and use them as service addresses.
- Onto a bridge for virtual machines. Create a bridge, give it the first usable address of the block as its own, and give each guest an address from the block with the bridge as gateway.
- Behind NAT. Fewer public addresses than guests; the host translates.
For the bridge case, remember that guests must send their traffic to the bridge, and the host must forward:
sysctl -w net.ipv4.ip_forward=1 — and make it permanent in
/etc/sysctl.d/
IPv6
IPv6 is supported everywhere on our network and is not an afterthought. Blocks are generous by design — there is no reason to be frugal with v6 addresses, and subnetting a /64 smaller than /64 breaks autoconfiguration. Give each virtual machine or container its own address rather than translating. See IPv6 on your server.
MAC addresses and why we do not want yours spoofed
Our ports expect the hardware address we know about. Guests behind a bridge should use their own addresses from your routed block, not addresses invented on the shared subnet, and switching ports should not see traffic claiming to be another customer's address. This is enforced. It is also why a routed block is the right answer for virtualisation: it removes the temptation entirely.
Reverse DNS
Every address we give you can have a PTR record and you can set it yourself. If the machine sends mail, this is not optional — see reverse DNS.
Justifying a request
IPv4 is finite and RIPE expects addresses to be used, so a request for a larger block needs a sentence about what it is for — one address per customer site, one per virtual machine, separate addresses for TLS on distinct domains, and so on. A plain technical reason is all that is needed; we are not making it difficult, we are keeping records that stand up to an audit.
If you already hold your own space, you do not need ours at all: see bring your own IP space.
Still stuck? Mail support@novogara.com — an engineer answers, at any hour. Back to the knowledge base