jail bridge ip allocation

[glennpm]

I am a satisfied hobbyist user of FreeNAS 9.1.1. Thanks to everyone who has contributed to its success.

I am motivated to upgrade to 9.2.1.6, mainly so that when I have questions I can find relevant discussions on this forum.

My current question is about addressing an existing setup glitch during the upgrade process. In my current installation, the bridge IP for my jails is acquired via DHCP and I’d rather that it be statically assigned. I don’t know how this happened and haven’t found a way to change it within my existing installation (my semi-generous assessment of my networking knowledge is ‘intermediate’).

I’d rather not have to rebuild my jails during the upgrade as one of them was a pain to get working correctly (Squeezebox Server). Is there a way to address this before/during the upgrade without causing myself a headache?

The following snippet of ifconfig output shows the bridge0 configuration.

Code:

...
bridge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
ether 02:97:f7:2f:83:00
inet 192.168.10.35 netmask 0xffffff00 broadcast 192.168.10.255
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200
root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0
member: epair2a flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
ifmaxaddr 0 port 11 priority 128 path cost 2000
member: epair1a flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
ifmaxaddr 0 port 10 priority 128 path cost 2000
member: epair0a flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
ifmaxaddr 0 port 9 priority 128 path cost 2000
member: em0 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
ifmaxaddr 0 port 2 priority 128 path cost 20000
...

 

[cyberjock]

I didn't have to redo my jails when I upgraded from 9.1.1 to 9.2.0.. so why do you think you would have to? 8.x to 9.x required you to redo the jails, but 9.x to 9.x shouldn't.

 

[glennpm]

Here is my assumption: a standard upgrade would succeed transparently; however, a standard upgrade would also result in my bridge ip continuing to be allocated via DHCP. My concern is that the only way to change that configuration is to re-instantiate the jails, including then having to rebuild the contents. So my question: is there a way to change the ip allocation of bridge0 either before, during or after the upgrade without having to rebuild the jails?

 

[cyberjock]

Uhh.. WHAT!? I'm not seeing where you have a problem anywhere. Jails don't do DHCP. You do your upgrade of FreeNAS and the jails will "just work". If you don't believe me make a new install of FreeNAS with 9.2.1.6 and import your config file. You'll see it should "just work". Unless you've customized things beyond the scope of the WebGUI you shouldn't have any problem.

 

[glennpm]

I'm trying to be concise and failing to adequately explain things. Please excuse the verbosity of this response.

My router's DHCP allocation space is 192.168.10.20-192.168.10.99.
My FreeNAS installation has a static IP of 192.168.10.200.
My 3 jails are allocated, per my request, at 192.168.10.251, 192.168.10.252 and 192.168.10.253.
All this is good.
However, there is also an allocation for bridge0 from FreeNAS (cited in my original post above) at 192.168.10.35, within the DHCP space. This is what I'd like to change -- I'd like to allocate bridge0 manually.
(And as much as to convince myself that I'm not crazy as to convince you: my FreeNAS console says that the Web GUI is available at either 192.168.10.200 or 192.168.10.35.)

Further, and this is new information in this post in case it helps to explain things, my router logs frequent, ongoing DHCP offers to epair0a, epair1a and epair2a, the pairs associated with my 3 jails (as determined by comparing MAC addresses in ifconfig). These offers are never accepted.

You are correct that there isn't a functional problem (other than my router's logs filling up with these DHCP offers). I would like to make a change if possible, though.

The following is the complete ifconfig output if I ssh into 192.168.10.35:

Code:

em0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=42098<VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC,VLAN_HWTSO>
ether 00:22:4d:84:34:ae
inet 192.168.10.200 netmask 0xffffff00 broadcast 192.168.10.255
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
em1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=4219b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,WOL_MAGIC,VLAN_HWTSO>
ether 00:22:4d:84:34:ab
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
media: Ethernet autoselect
status: no carrier
ipfw0: flags=8801<UP,SIMPLEX,MULTICAST> metric 0 mtu 65536
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
options=600003<RXCSUM,TXCSUM,RXCSUM_IPV6,TXCSUM_IPV6>
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x7
inet 127.0.0.1 netmask 0xff000000
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
bridge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
ether 02:97:f7:2f:83:00
inet 192.168.10.35 netmask 0xffffff00 broadcast 192.168.10.255
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200
root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0
member: epair2a flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
ifmaxaddr 0 port 11 priority 128 path cost 2000
member: epair1a flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
ifmaxaddr 0 port 10 priority 128 path cost 2000
member: epair0a flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
ifmaxaddr 0 port 9 priority 128 path cost 2000
member: em0 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
ifmaxaddr 0 port 2 priority 128 path cost 20000
epair0a: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=8<VLAN_MTU>
ether 02:04:02:00:09:0a
inet6 fe80::4:2ff:fe00:90a%epair0a prefixlen 64 tentative scopeid 0x9
inet 0.0.0.0 netmask 0xff000000 broadcast 255.255.255.255
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
media: Ethernet 10Gbase-T (10Gbase-T <full-duplex>)
status: active
epair1a: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=8<VLAN_MTU>
ether 02:9b:d1:00:0a:0a
inet6 fe80::9b:d1ff:fe00:a0a%epair1a prefixlen 64 tentative scopeid 0xa
inet 0.0.0.0 netmask 0xff000000 broadcast 255.255.255.255
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
media: Ethernet 10Gbase-T (10Gbase-T <full-duplex>)
status: active
epair2a: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=8<VLAN_MTU>
ether 02:e1:a2:00:0b:0a
inet6 fe80::e1:a2ff:fe00:b0a%epair2a prefixlen 64 tentative scopeid 0xb
inet 0.0.0.0 netmask 0xff000000 broadcast 255.255.255.255
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
media: Ethernet 10Gbase-T (10Gbase-T <full-duplex>)
status: active

 

[cyberjock]

So I still think you should try doing a USB stick with 9.2.1.6 and doing a config upload and see how FreeNAS responds. I'm confused on this whole thing and there's only 2 options I see that are easy: stay on what you are on until you know it will be okay (which may be never) or try it. I can tell you that the developers would say 'try it and tell me when its broken'.

In all seriousness 9.1.1 is a year or so old. Both of my FreeNAS boxes (one is on 9.2.0 and one is 9.2.1.6) doesn't have an IP assigned to the bridge, so I tend to think that your problem may not even exist anymore.

As long as you don't do things like adding jails/plugins or doing a zpool upgrade you should be able to safely try 9.2.1.6 and if you don't like it roll back to 9.2.0.

 

[glennpm]

Thanks for your consideration of this.

I'm not surprised to read that my situation might be outdated or an anomaly. It's kind of what I expected when I couldn't find *any* hits when searching for circumstances similar to mine.

I will proceed with the upgrade in the next few days and post back my anticipated-to-be-succesful results to close the thread.

 

[glennpm]

I performed an upgrade from 9.1.1 to 9.2.1.6 last night. Everything went smoothly and the updated system is working well. I no long observe any of the unusual DHCP behavior that I wrote about earlier in this thread. I consider this question closed.

 

[cyberjock]

There ya go! Enjoy!