bridge0 LAN IP not present
-
@tedquade Are you able to upload any config or logs from the system you have hitting this?
If so please do so here: https://nc.netgate.com/nextcloud/s/7rdEWfnigQWKdTN
Steve
-
@stephenw10 I can.
What specific config do you need? The XML backup or system config files? If the latter, provide me with the exact path.
As for logs, what do you need, ie OS boot log, etc. and specific system path as appropriate.
Ted Quade
-
The full config backup would be ideal if it's a test box you're able to do that with.
The boot logs may also show something.
The redacted status_output file from <your_firewall_IP>/status.php would be useful if you can't use the full config.
Steve
-
@stephenw10 XML config backup and OS Boot log uploaded.
Ted Quade
-
Thanks!
-
Are you able to test booting with the OpenVPN server disabled?
We think we've found where this is happening but it would be good to get another data point to confirm it because it's not a simple fix.
Steve
-
@stephenw10 You have the additional data point.
Bridge0 came up configured on reboot with OpenVPN server disabled.
Now for the real fun by the sounds of it!
Ted Quade
-
Yes, the 'correct' fix for this is.... non-trivial!
Thanks for confirming.
-
@stephenw10 With this mornings build, the problem is resolved.
FreeBSD 14.0-CURRENT #0 plus-devel-main-n255990-b4bd6673756: Thu Dec 1 06:29:16 UTC 2022
Ted Quade
-
Excellent! Thanks for the feedback.
I tested every combination of bridges, vlans, qinqs and openvpns I could think of there and it looks good. There are a lot of possible combos though so let me know if you find anything.
One thing this exposed is that the bridge interfaces handling in FreeBSD 14 does a few things differently. The MTU setting especially has changed. Setting the MTU on the bridge should now propagate that to all members. And conversely it will override any setting on a member interface. So in the current snapshot you should find interfaces that are bridge members have the MTU field greyed out.
Steve
