This is something that I had noticed on 10.3 —
While putting together a Mininet Switch class that uses the
if_bridge network bridge device, I noticed that there was some strange behavior: I would create a bridge within a jail, rename it, and when it came time to destroy it, I would receive an error:
ifconfig: SIOCIFDESTROY: Invalid argument
ifconfig makes you wonder – Mininet Switch objects are merely references to shells started in a network namespace, or in my case, a jail, so they work as glorified shell scripts that configure a software switch of your choice.)
The bridge would then get destroyed along with the jail when Mininet runs
jail -r, upon which it becomes “lost”. Trying to create another bridge with the same original name afterwards would fail:
# ifconfig bridge2 create ifconfig: SIOCIFCREATE2: File exists
Manually recreating the steps that Mininet runs through with
jexec let me reproduce this odd behavior.
# jexec 26 ifconfig bridge create bridge2 # jexec 26 ifconfig bridge2 | grep bridge bridge2: flags=8802 metric 0 mtu 1500 # jexec 26 ifconfig bridge2 name test2 # jexec 26 ifconfig test2 | grep test test2: flags=8802 metric 0 mtu 1500 # jexec 26 ifconfig test2 destroy ifconfig: SIOCIFDESTROY: Invalid argument
Playing around a bit more revealed that renaming it back to any name of the original format (bridge[n], n a number), would allow the bridge to be destroyed using that new-new name:
# jexec 26 ifconfig test2 name bridge100 # jexec 26 ifconfig -a | grep bridge bridge2: flags=8802 metric 0 mtu 1500 # jexec 26 ifconfig bridge100 destroy # jexec 26 ifconfig -a | grep bridge #
Another option is to pull the renamed bridge from the jail, and to destroy it in the host environment.
The workaround in my case was simply to not rename the bridge device to match the name of the Switch object – this also had the added benefit of reducing the number of
Now, the correct solution would probably be to file a bug report, or to dig around myself…
UPDATE: The behavior seems to have been fixed in 11.0.