I am trying to add a route to my network bridge, but whenever I try, it states that it is not a valid IPv4 Network Address when it clearly is:
Config parsing error: Invalid value for network “hyebr0” option “ipv4.routes”: Item “195.178.121.58/29”: Not an IPv4 network address “195.178.121.58/29”
Press enter to open the editor again or ctrl+c to abort change
Can you show a simplified self-contained example that demonstrates this error?
Apparently, here you use the edit command to edit the configuration file, then try to save, and you get the error. You can use the set command to set ipv4.routes key to the appropriate resources.
Yes.
If I create a network:
incus network create hyebr0
Then set the following options:
incus network set hyebr0 ipv4.nat=false
incus network set hyebr0 ipv4.address=195.178.121.50/29
incus network set hyebr0 ipv4.dhcp=true
incus network set hyebr0 ipv4.dhcp.ranges=195.178.121.51-195.178.121.54, 198.178.121.58-198.178.121.58
When I try to route the last address, which is outside of the subnet to the bridge so the DHCP assignment is valid, using incus network set hyebr0 ipv4.routes=198.178.121.58/29, Incus states that “198.178.121.58/29” is not a valid network address, even though it is.
I tested incus network set hyebr0 ipv4.routes=198.178.121.58,
but this yields Error: Invalid value for network “hyebr0” option “ipv4.routes”: Item “195.178.121.58”: invalid CIDR address: 195.178.121.58
Leading me to believe the CIDR format I used previously is as-intended (as the documentation states) so I’m not sure why this isn’t working.
What it says is correct: that is not a valid network address. /29 netblocks are on a boundary of 8 addresses, so valid ones would be 195.178.121.56/29 or 195.178.121.64/29
“ipv4.routes” lists the subnets that you want to route, not an address within that network.
Looking at your setup: you have set the bridge’s own IP address to 195.178.121.50/29. This means that the network is 195.178.121.48/29, and it contains the addresses .49 to .54 inclusive. You’ve taken .50 for the bridge, so the remaining five usable addresses are .49 and .51-.54
dhcp can only give out addresses from that subnet, so .51-54 are valid, but .58 is not.
If you really wanted to route the single extra address .58 then you would set ipv4.routes=195.178.121.58/32, but this is almost certainly not going to be what you want.
The question remains, what exactly does incus do with an extra “ipv4.route” like 195.178.121.56/29 on a bridge, if it doesn’t have a next hop?
I tried it, by adding ipv4.routes: 195.178.121.56/29 to incusbr0. It has added it as a “connected route”:
root@nuc3:~# ip r
default via 10.12.255.1 dev br0 proto static
10.12.1.0/24 dev wg0 proto kernel scope link src 10.12.1.1
10.12.13.0/24 dev incusbr0 proto kernel scope link src 10.12.13.1
10.12.255.0/24 dev br0 proto kernel scope link src 10.12.255.13
195.178.121.56/29 dev incusbr0 proto static scope link
root@nuc3:~# ip a | grep 195.178
root@nuc3:~#
As far as I can see, this doesn’t achieve anything. Any container on incusbr0 which was allocated an address from this subnet, would not have a default gateway; equally, the host itself cannot ARP for any address in this range (as it doesn’t have an address in the range 195.178.121.57 to .62). So nothing can communicate.
However, if anybody can show me a situation where ipv4.routes on an incus-managed bridge is actually useful, I’ll be very interested to see it.