2

Given the current exhaustion of IPv4 addresses, I would like to try to use the network and broadcast address of by /29 prefix.

Is this possible?

I am renting a /29 from Hetzner and assign the individual IPs to virtual machines which are running on a dedicated server.

The server itself has another IPv4 address from a different subnet.

Steffen Vogel
  • 31
  • 2

1 Answers1

0

This is a Linux-only answer (but at least the second method presented is not very Linux-specific so can probably be used with other OSes).

Here are three methods to do this for a Linux server (acting as router here) and using VMs also running Linux. The first method is just here to help introduce the third method. the second or the third methods should be used, not the first. All three methods can be used together (ie: some VMs using one method, others using an other, same for the Linux server acting as router).

I'll assume in examples below that the IP address block is 192.0.2.0/29 and the server's IP in this block is 192.0.2.1/29 set directly on a bridge interface (as often done by virtualization softwares) named bridge0. VMs will have an eth0 interface.

Configure a standard /29 LAN as usual on Linux, but remove the special broadcast role of the first and last IP addresses

  • pro: ... helps introduce the 3rd method.
  • con: uses a trick, which must be done again each time the network interface is administratively brought down then up or have an IP address change. It must be applied after the interface is up, with a possible slight traffic disruption window.

Once an address is added and the interface brought up, the local routing table receives two broadcast addresses: the first and the last of the network block:

# ip address add 192.0.2.2/29 dev eth0
# ip link set dev eth0 up
# ip route show table local dev eth0
broadcast 192.0.2.0 proto kernel scope link src 192.0.2.2 
local 192.0.2.2 proto kernel scope host src 192.0.2.2 
broadcast 192.0.2.7 proto kernel scope link src 192.0.2.2

Just removing those two extra broadcast entries removes the special roles of the network and broadcast addresses, turning them into normal unicast IP addresses in communication:

# ip route flush table local dev eth0 type broadcast
# ip route show table local dev eth0
local 192.0.2.2 proto kernel scope host src 192.0.2.2

Until it's done, this system probably can't communicate properly with 192.0.2.0 and 192.0.2.7. The system must have custom configuration settings to do this at boot or when bringing up an interface (eg up commands in /etc/network/interface for some Debian-like systems).

And as usual, add the default route to the server:

# ip route add default via 192.0.2.1

Exactly the same is done for the systems using 192.0.2.0 and 192.0.2.7. Those systems might have communication problems with any other system until the broadcast routes are removed.

That's it. But if the interface is brought down/up or have its IP address changed, this will have to be done again, because the broadcast routes in the local table are automatically re-added by the kernel each time this happens.

If some VMs can't accept this setting (eg: don't run Linux) nor the following choices, isolation (PVLAN) for them and those using 192.0.2.0 and 192.0.2.7 (so involving at least 3 VMs) should probably be done (see for example Is it possible to enable port isolation on Linux bridges?).

Use a /32 address and /32 routes for any IP address in the /29 LAN

  • pro: quite similar to failover-IP settings described by some host providers (not very clear example here), so there's probably documentation for various OSes already available.
  • con: requires to set one route per peer.

While the interfaces will still be (virtual) ethernet interfaces at layer 2 and will still be using ARP as usual to resolve IPv4 addresses under the hood, all routes will be added like would be done for layer 3 point-to-point routes.

For example on the system using the 192.0.2.0 IP address, the address would be added like this:

# ip address add 192.0.2.0/32 dev eth0

which won't add any route in the main routing table and only the scope host route in the local table. Routes in the main routing table must now be added manually:

# ip route add 192.0.2.1/32 dev eth0

These first two commands ( /32 address + one /32 route, probably to the router) can optionally be abbreviated in a single command like this:

# ip address add 192.0.2.0 peer 192.0.2.1/32 dev eth0

the bonus being the route is added back automatically by the kernel when the interface is brought down/up.

The default route must still be added as usual:

# ip route add default via 192.0.2.1

If this VM has to communicate with an other VM, just add its specific /32 route as needed:

# ip route add 192.0.2.2/32 dev eth0
# ip route add 192.0.2.3/32 dev eth0
# ip route add 192.0.2.4/32 dev eth0
# ip route add 192.0.2.5/32 dev eth0
# ip route add 192.0.2.6/32 dev eth0
# ip route add 192.0.2.7/32 dev eth0

Keep the best of both: set a /32 address, manually add a /29 route

  • pro: simple
  • con: none I can see, except again I don't know the non-Linux equivalents.

Add a /32 address (so again, no special broadcast routes gets automatically added in the local routing table by the kernel) and complete manually with an usual /29 route which was not automatically added in the main routing table by the kernel:

# ip address add 192.0.2.3/32 dev eth0
# ip route add 192.0.2.0/29 dev eth0
# ip route add default via 192.0.2.1

# ip route show table local dev eth0
local 192.0.2.3 proto kernel scope host src 192.0.2.3

The result is the same as the first case, except the Linux kernel didn't automatically add the potentially disrupting broadcast addresses in the local routing table, so they don't have to be removed when changes like down/up are done. The LAN route must be added back manually then instead.

A.B
  • 11,090
  • 2
  • 24
  • 45