iocage network issues

[amiskell]

This doesn't seem to work for me. Upon reboot the ifconfig_epair0_name line is missing and it's replaced with ifconfig_epair0="DHCP" no matter what I do.

 

[antornix]

Hi everybody,

What a day of troubleshooting... I have just managed to recover networking capabilities in the 11.1-U5 jails.. I considered joining the forum in order to share this, as this was a total PITA, I hope this info helps you.

Today I upgraded to FreeNAS 11.1-U5 and lost Internet Access in the jails that were used to have Internet access beforehand.

As you can find in this forum, the problem is that U5 does not add the physical interface to the bridge0, something easy to fix by issuing:

ifconfig bridge0 addm lagg0 up

In my case it is lagg0, in your case it depends on your setup: look for your Internet-facing interface, which might be igb0, or em0, or something else# ..

However, I was in a situation in which I had 4 warden (legacy jails) and 2 iocage (modern jails), so after upgrading to FreeNAS 11.1 U5 I also considered it was the time to convert all my warden jails to iocage ones by means of the built-in script... /usr/local/sbin/migrate_warden.py

migrate_warden.py -v -j WARDEN_JAIL -p ZFS_POOL

ZFS_POOL being the same one of my actual iocage setup...

All the warden to iocage migrations went fine, but they were unable to communicate, whereas the 2 original iocages (the ones I did not need to convert) had no problems to access the network.

Every iocage jail has a config.json file: /mnt/iocage/jails/JAIL_NAME/config.json

The bug was in the most significant bytes of the MAC address, there is a flag in every iocage jail config file that seems to act as an ACL...

"mac_prefix": "02ff60",
"vnet0_mac": "02ff604bcbfb,02ff604bdbfc",

So make sure your MAC address at vnet0_mac begins by the prefix stated at mac_prefix, adhering to this fixed my networking on the converted jails, for some reason, the migration scripts fails to adhere to this.

Another issue was that the converted jails had type EMPTY, instead of the specific 11.1-RELEASE-p1, so iocage was not able to upgrade them to -p10. Again, replacing the "EMPTY" strings by the proper ones at the same config.json fixed the problem and I was able to upgrade just fine. The flags are cloned_release and release.


"cloned_release": "EMPTY"
"cloned_release": "11.0-RELEASE-p1"
...
"release": "EMPTY"
"release": "11.0-RELEASE-p1"


Sorry for such a long post.

Cheers!
Antornix

 

[meku]

Hi everybody,
The bug was in the most significant bytes of the MAC address, there is a flag in every iocage jail config file that seems to act as an ACL...

"mac_prefix": "02ff60",
"vnet0_mac": "02ff604bcbfb,02ff604bdbfc",

So make sure your MAC address at vnet0_mac begins by the prefix stated at mac_prefix, adhering to this fixed my networking on the converted jails, for some reason, the migration scripts fails to adhere to this.

I believe this is inaccurate.

If the jail needs to generate its own mac then it uses "mac_prefix", but if you set the vnet0_mac then it is not used. I do not see any reference to it being used as an ACL or otherwise.

Because this "02ff60" prefix is the default for all iocage jails it would be safer to avoid this prefix when you define your own MAC address.

Reference: iocage source

 

[subzer011]

i was having the same issue and symptoms as OP and the other posters with my IOCAGE jails on FN 11.2-RC1 (no network on vnet; yet actual nic works fine), however, mines was due to my recent migration into a FreeNAS VM. after 3 days of troubleshooting, figured out that it was the virtual switch/NIC causing the problem. vnet0 requires "promiscuous mode" to be enabled on the port group. it's disabled by default.