I didn’t even set up the incusbr0 as a bridge; it had to have been generated automagically. I can’t even find anywhere to remove it unless I start finagling via CLI. There is an option to set container networking IP ranges, I can try moving that to something different and see what happens.
I think at times, we ALL have CTS!
Yep, I just went back and checked. The Networking section of the Applications configuration has a single setting in the drop-down of: Automatic with no real way to manage that bridge it automatically generates.
I’m going to try some CLI systemctl/googling to see if I can stop and reconfigure it… hold my beer!
In the GUI (of 24.10.2.1) you can only create bridges with names like br<some-number> (and I wasn’t able to create my beloved br-lan and br-san). So your statement is totally believable.
So, stopping the incus and incus.socket services makes the incusbr0 go away and it returns as soon as you restart the services.
But, I get the exact same results trying to create br0 with incus temporarily turned off.
I am currently searching for a way to make my VM reach TrueNAS IP on the network and found your post. I also had the same thing with bridge and couldn’t reach truenas from any IP but I restarted my machine and I guess in the boot sequense it configures it correctly and it solves the problem for me. I just followed the old way of making a bridge but from the true as CLI with my keyboard, saved it (at that point it was unreachable) and restarted and it worked I guess. Also make sure the MTU on your Ethernet is the same on the bridge. My default is 1500
Yeah, I should have pointed out that I did try doing a reboot via the BMC after creating the bridge and it boots up fine, but it still basically shuts my entire network down and doesn’t come back up until I either power-off the Truenas host -or- unplug the SFP transceiver and reset it back to pre-bridge settings.
It’s just plain weird that it works fine when using the un-bridged ens5f0 with a static IP address, and breaks the entire network when introducing the br0… Narrowing down what changes on the network is the solution, I think.
If it brings the entire network down there’s a very high probability you created a loop. Really only a single connection/cable from the TrueNAS to your switched infrastructure?
Yes, I’ve omitted the 2nd SFP+ port intentionally while trying to isolate the issue. The Truenas OS detects 2 SFP+ "nic"s as ens5f0 and ensf5f1, so I’ve completely removed the SFP+ transceiver from the ens5f1 port entirely and I’ve NOT included it in the bridge definition.
Just reiterating that the ens5f0 with a static IP address works perfectly well without any issues; it’s once I add the br0 and move that static IP address from ens5f0 to the new br0 is when all hell breaks loose. Aside from the MTU, there’s really nothing being set that could cause a loop; but, wireshark should, hopefully, help identify what changes when testing re-adding the bridge.
Just being explicit… there is still the BMC attachment, too, but that shouldn’t have any bearing on the Truenas br0 issue, since they are basically different machines within the same chassis.
Not an issue at all. The IPMI port is not managed by TrueNAS.
Yes, it’s definitely a loop. I’ve done a Wireshark packet capture on a different VM and see lots of:
1834 74.125629164 SuperMic_0f:3d:a4 → Broadcast ARP 60 Who has 10.X.X.X? Tell 10.X.X.X (duplicate use of 10.X.X.X detected!)
1842 74.281123944 10.X.X.X → 224.0.0.251 MDNS 452 Standard query 0x0000 ANY 4.a.d.3.f.0.e.f.f.f.b.6.f.1.e.a.0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa, "QM" question ANY truenas.local, "QM" question ANY X.X.X.10.in-addr.arpa, "QM" question ANY truenas._smb._tcp.local, "QM" question ANY truenas._http._tcp.local, "QM" question ANY truenas._device-info._tcp.local, "QM" question A 10.X.X.X PTR truenas.local SRV 0 0 445 truenas.local TXT SRV 0 0 80 truenas.local TXT SRV 0 0 9 truenas.local TXT AAAA fe80::ae1f:6bff:fe0f:3da4 PTR truenas.local
1844 74.384679801 SuperMic_0f:3d:a4 → Broadcast ARP 60 Who has 10.X.X.X? Tell 10.X.X.X (duplicate use of 10.X.X.X detected!)
...
...sanitized cruft out...
...
4254 122.988116170 Netgear_10:4d:2b → Broadcast RLDP 60 Network Loop Detection
all before the network goes down; but nothing after that due to losing connection to the terminal running dumpcap and it forces termination.
So, it almost looks like the ens5f0 nic isn’t releasing it’s IP address before trying to assign it to the new br0, if I had to guess. But, I’m deleting that alias on ens5f0 before assigning it to the new br0.
Are you sure about that BMC interface being really just BMC only?
The default for Supermicro is
I’m just taking shots since I am not at your system. What you observe: power on Truenas → network meltdown, that just screams “loop” 
I am 95% sure it’s BMC only; it has it’s own IP & MAC address and doesn’t even appear as an option to chose in the Truenas GUI or CLI methods. As part of this diagnostic efforts, I’ve even switched all my BMC’s to a separate VLAN instead of maintaining them on the main network; I’ve heard that is a good idea for safety, as well, so it was time to make that change.
Truenas DOES show that interface as an IPMI channel, but doesn’t include it in any configuration options for other general networking.
Success!!! I found the issue!!!
For some stupid reason (and I’m publicly face-palming myself) that I have no clue why I even did this… I had a custom profile applied to that switch port that ens5f0 was connected to with STP disabled. Once I enabled RSTP on that specific port, I was able to create the bridge, test it, and save/apply the new configuration. If I had used the ens5f1 port instead of ens5f0, I’m confident it would have worked the first attempt because RSTP is enabled in the default profile (which was still assigned to that 2nd switch port where ens5f1 was plugged in.)
All the other SFP+ ports on my switch are using defaults, but this one I had applied a different profile to, and I’m still scratching my head as to WHY I did something silly like that!
So, moral of the story: If you run across anything similar to what I ran across, be sure to check your switch and ensure Spanning-Tree Protocol is actually enabled!
