I don't think you get what I'm saying. If the code is tracking what it creates for bridges (and it obviously uses bridges for jails), creating a bridge might confuse the code. The code might expect bridge0 to be for jails and might be hard coded that way. If you do bridge0 how is that going to work with the jails?
Since the jail code appears to go to some trouble to be able to keep track of the active bridges, I'm *guessing* it'll be just fine. You can go check out the code over in /usr/local/share/warden/scripts/backend/functions.sh etc yourself if you wish.
Generally speaking, there are some of us that spent years finding the edge cases, talking to subsystem developers, filing bug reports, and helping guide the development of FreeBSD's high performance network stack. That's why things like "ifconfig bridge create" go to the trouble of dynamically allocating a new bridge and putting the new device name on standard output, and why a lot of the rc code to implement the network stack is so complicated.
Will the code realize that you've already created a bridge and create bridge1 instead?
Appears to. We can work around it if it really doesn't;
1) s/bridge0/bridge999/g
2) A more thorough solution that would address the
more likely issue of the postinit script running after jails starting and the bridge0 already existing: use
ifconfig ix0 up; ifconfig `ifconfig bridge create` addm em0 addm ix0 up
but I deemed backquoting to be less likely to work in a command so I didn't suggest it - keeping it simple and understandable is somewhat better anyways.
Try it instead of spreading FUD.
Will it work correctly? Will it work correctly in the future? These are all questions that none of us can answer with a high degree of certainty.
Maybe a question that
you can't answer with a high degree of certainty. I'm familiar enough with them that I feel pretty certain. Just a matter of getting the details right.
I'm not saying that the bridging feature isn't trivial. It is. I'm saying that using it when FreeNAS expects full control and for you to not do anything spooky behind it's back is probably a bad place to assume.
And you might call it "easy to debug", but I bet 99% of the forum wouldn't know where to start if there was a problem with bridges.
A new user in this very thread figured it out from a push I gave in the general right direction. I think any admin smart enough to ask the question can be safely given the information. Which brings us back to the original post in this thread.
Now, rather than unproductively rattle on about how dangerous and risky this all is, a more productive course of action would be to advocate to create a feature to support interface bridging. It's similar in complexity to vlans or lacp in that the technology is well-understood and baked into the system, and just requires a little configuring.