Troubleshooting Static IP on unmanaged bridge

I followed several threads to finally get a working static IP address on my unmanaged bridge, br0, but it feels like I made it too complex. Can somebody give this a quick scan and tell me what I can do to simplify this?

In a nutshell, I run “incus config device set kubeadm-leader eth0 security.ipv4_filtering=true ipv4.address=10.0.0.100,” but that doesn’t produce an IP address, it’s blank. I still have to go into Netplan and configure it. So, what is the point in running the command to assign the IP if I just set it with Netplan anyway?

Here is the Incus Profile.

config: {}
description: Unmanaged  Bridge Incus profile
devices:
  eth0:
    name: eth0
    nictype: bridged
    parent: br0
    type: nic
  root:
    path: /
    pool: default
    type: disk
name: homelab

I started with these commands.

incus launch images:ubuntu/22.04 kubeadm-leader --profile homelab
incus stop kubeadm-leader
incus network attach br0 kubeadm-leader eth0 eth0 
incus config device set kubeadm-leader eth0 security.ipv4_filtering=true ipv4.address=10.0.0.100
incus start kubeadm-leader
incus list

At this point, the Linux container is running, but it has no IP address assigned. To fix that, I edit /etc/netplan/10-lxc.yaml like this.

network:
  version: 2
  ethernets:
    eth0:
      dhcp4: false
      dhcp-identifier: mac
      addresses: [10.0.0.100/16]
      nameservers:
         addresses:
         - 10.0.0.8
         - 10.0.0.9
         - 10.0.0.1
         search: [byteworksinc.com]
      routes:
         - to: default
           via: 10.0.0.1
      mtu: 1500

That gives me an IP address and makes the Linux container accessible.

 # ip a show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
66: eth0@if67: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 00:16:3e:02:41:8f brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 10.0.0.100/16 brd 10.0.255.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::216:3eff:fe02:418f/64 scope link
       valid_lft forever preferred_lft forever

Is there a more straightforward way?

Your bridge being unmanaged, Incus cannot handle the static IP for you.

You indeed either need to do it yourself through netplan or by using a container image which supports cloud-init and then provide basically the same netplan configuration to the container through cloud-init.

ipv4.address/ipv6.address on the NIC, only tells Incus to configure a static DHCP lease for the instance. This only works when Incus is in charge of DHCP and the instance itself uses DHCP too.

incus launch images:ubuntu/22.04/cloud mycontainer --profile P1 --config=user.network-config="$(cat <<EOF
version: 2
ethernets:
  eth0:
    dhcp4: no
    addresses:
      - 192.168.1.100/24  # Static IP for the container
    gateway4: 192.168.1.1  # Gateway for the container (adjust as needed)
    nameservers:
      addresses:
        - 8.8.8.8
        - 8.8.4.4
EOF
)" --config=volatile.eth0.host_name=br0

See if this helps

I suppose that you would rather get some warning message when you try to set ipv4.address on an unmanaged (by Incus) network interface? Like, The ipv4.address parameter is not used on network interfaces that are not managed by Incus?

I am not sure how the implementation logic would go with that. Because you can replace the network interface from one to another, you can apply/stack profiles to containers, etc.

I went right back to your initial statement, which maybe I misunderstand. You want to get a static IP assigned to your HOST bridge, right? Assuming so:-

I note you use netplan, so do I (on debian 12), so this is how I get a static IP assigned to my bridge and it’s solid for me.

sudo cat /etc/netplan/50-netplan.yml    #excerpt-only shown:

network:
  ethernets:
    enp98s0f0:
      dhcp4: true
      optional: true
  version: 2

  bridges:
    br0:
      dhcp4: yes
      optional: false  
      addresses: [10.231.25.9/24]
      interfaces:
          - enp98s0f0
      routes:
        - to: default
          via: 10.231.25.1
      nameservers:
        addresses: [1.1.1.1,1.0.0.1]
      parameters:
        stp: false
        forward-delay: 0

On my host, my bridge looks like this:

6: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 9a:a5:6d:27:15:f6 brd ff:ff:ff:ff:ff:ff
inet 10.231.25.9/24 metric 100 brd 10.231.25.255 scope global dynamic br0
valid_lft 6110sec preferred_lft 6110sec
inet6 fe80::98a5:6dff:fe27:15f6/64 scope link
valid_lft forever preferred_lft forever

I can also use my router to assign the static IP since I declare ‘dhcp4: yes’. In practice, I typically do both.

I assign this host br0 bridge device to an incus profile thus:

incus profile show br0
config:
  limits.cpu: "2"
  limits.memory: 4GiB
  snapshots.expiry: 2w
  snapshots.schedule: '@daily'
description: Default LXD profile with BRIDGE network
devices:
  eth0:
    nictype: bridged
    parent: br0
    type: nic
  root:
    path: /
    pool: default
    type: disk
name: br0
used_by:
- [/1.0/.....]
project: default

So something like:

incus launch images:debian/12 cbr1 --profile br0
incus launch images:debian/12 c1

incus list

+---------------------------------+---------+-------------------------+------+-----------------+-----------+
| c1                              | RUNNING | 10.23.16.79 (eth0)      |      | CONTAINER       | 0         |
+---------------------------------+---------+-------------------------+------+-----------------+-----------+
| cbr1                            | RUNNING | 10.231.25.139 (eth0)    |      | CONTAINER       | 0         |
+---------------------------------+---------+-------------------------+------+-----------------+-----------+

c1 gets its IP from the standard incusbr0 (10.23.16.0/24) and cbr1 has an IP from the lan (10.231.25.0/24). Both can access internet and you can route etc.

Is that what you’re trying to achieve? If so, hopefully this is helpful. If not, well sorry I read your question wrong. Good luck.

Andrew