FreeBSD 9.0 ipv4 / ipv6 aliases + vmwaretools

I noticed some changes to the way we configure aliases in /etc/rc.conf, specialy when ipv4 and ipv6 are combined. For instance, in 7.4-RELEASE, I would do:

Code:
hostname="aaa.bbb.cc"
ifconfig_em0="inet 11.111.139.11/25"
ifconfig_em0_alias0="inet 11.111.139.12/32"
ifconfig_em0_alias1="inet 11.111.139.13/32"
ifconfig_em0_alias2="inet 11.111.139.14/32"
ifconfig_em0_alias3="inet 11.111.139.15/32"
defaultrouter="11.111.139.1"
ipv6_enable="YES"
ipv6_ifconfig_em0="2A02:F18:1:8B01:11:111:139:11/64"
ipv6_ifconfig_em0_alias0="2A02:F18:1:8B01:11:111:139:12/128"
ipv6_ifconfig_em0_alias1="2A02:F18:1:8B01:11:111:139:13/128"
ipv6_ifconfig_em0_alias2="2A02:F18:1:8B01:11:111:139:14/128"
ipv6_ifconfig_em0_alias3="2A02:F18:1:8B01:11:111:139:15/128"
ipv6_defaultrouter="FE80::1%em0"

Notice the numbering of the aliases for ipv4 and ipv6 both start with 0.

But now, in 9.0, if we do this, we get a couple of warnings:

Code:
/etc/rc.d/netif: WARNING: $ipv6_enable is obsolete. Use $ipv6_activate_all_interfaces instead.
/etc/rc.d/netif: WARNING: $ipv6_ifconfig_em0 is obsolete. Use ifconfig_em0_ipv6 instead.
/etc/rc.d/netif: WARNING: $ipv6_ifconfig_em0_alias0 is obsolete. Use ifconfig_em0_aliasN instead.

So if we change that accordingly:

Code:
hostname="aaa.bbb.cc"
ifconfig_em0="inet 11.111.139.11/25"
ifconfig_em0_alias0="inet 11.111.139.12/32"
ifconfig_em0_alias1="inet 11.111.139.13/32"
ifconfig_em0_alias2="inet 11.111.139.14/32"
ifconfig_em0_alias3="inet 11.111.139.15/32"
defaultrouter="11.111.139.1"
ipv6_activate_all_interfaces="YES"
ifconfig_em0_ipv6="2A02:F18:1:8B01:11:111:139:11/64"
ifconfig_em0_alias0="inet6 2A02:F18:1:8B01:11:111:139:12/128"
ifconfig_em0_alias1="inet6 2A02:F18:1:8B01:11:111:139:13/128"
ifconfig_em0_alias2="inet6 2A02:F18:1:8B01:11:111:139:14/128"
ifconfig_em0_alias3="inet6 2A02:F18:1:8B01:11:111:139:15/128"
ipv6_defaultrouter="FE80::1%em0"

This 'conflicts' with the already present ipv4 aliases. Could be deliberate, but the consequence is that the number of the aliases has to change, because otherwise the ipv6 aliases will overwrite the ipv4 ones, leaving you without any ipv4 aliases after a upgrade/reboot. In fact, it should become:

Code:
hostname="aaa.bbb.cc"
ifconfig_em0="inet 11.111.139.11/25"
ifconfig_em0_alias0="inet 11.111.139.12/32"
ifconfig_em0_alias1="inet 11.111.139.13/32"
ifconfig_em0_alias2="inet 11.111.139.14/32"
ifconfig_em0_alias3="inet 11.111.139.15/32"
defaultrouter="11.111.139.1"
ipv6_activate_all_interfaces="YES"
ifconfig_em0_ipv6="2A02:F18:1:8B01:11:111:139:11/64"
ifconfig_em0_alias4="inet6 2A02:F18:1:8B01:11:111:139:12/128"
ifconfig_em0_alias5="inet6 2A02:F18:1:8B01:11:111:139:13/128"
ifconfig_em0_alias6="inet6 2A02:F18:1:8B01:11:111:139:14/128"
ifconfig_em0_alias7="inet6 2A02:F18:1:8B01:11:111:139:15/128"
ipv6_defaultrouter="FE80::1%em0"

This works fine. But it seems odd.

Is it a bug or a feature?


The second issue is that vmware tools does not start on a 9.0 guest;

Code:
# /usr/local/etc/rc.d/vmware-tools.sh start
VMware Tools is installed, but it has not been
(correctly) configured for the running kernel.
To (re-)configure it, invoke the following command:
/usr/local/bin/vmware-config-tools.pl.


freebsd# /usr/local/bin/vmware-config-tools.pl
Initializing...


Making sure services for VMware Tools are stopped.

Stopping VMware Tools services in the virtual machine:
   Guest operating system daemon:                                      done
   Guest memory manager:                                               done


No X install found.

You have a pre-existing pango.modules.  The new version will be created as
/usr/local/lib/vmware-tools/lib64-63/libconf/etc/pango/NEW_pango.modules.
Please check the new file for any new values that you may need to migrate to
your current pango.modules.

Starting VMware Tools services in the virtual machine:
   Switching to guest configuration:                                   done
   Guest memory manager:                                              failed
   Guest operating system daemon:                                      done
Unable to start services for VMware Tools

Execution aborted.

# tail /var/log/messages
Jan 13 15:45:40 freebsd kernel: KLD vmmemctl.ko: depends on kernel - not available or version mismatch
Jan 13 15:45:40 freebsd kernel: linker_load_file: Unsupported file type

I know this is not a FreeBSD issue, but I was wondering if more have seen it and perhaps found a solution?
 
What happens when you replace

Code:
ifconfig_em0="inet 11.111.139.11/25"
ifconfig_em0_alias0="inet 11.111.139.12/32"
ifconfig_em0_alias1="inet 11.111.139.13/32"
ifconfig_em0_alias2="inet 11.111.139.14/32"
ifconfig_em0_alias3="inet 11.111.139.15/32"

with the more modern

Code:
ipv4_addrs_em0="11.111.139.11-15/25"
(yes, this will create 11/25, 12/32, 13/32, 14/32, 15/32)

and don't define any literal IPv4 aliases there?

See also the ipv6_prefix_ed0 example in rc.conf(5) which suggests that the same thing can be done for IPv6 aliases.

Whether this sorts out your alias conflicts automatically remains to be seen, of course.
 
tony1athome said:
I'm also seeing an incompatibility message on vmblock.ko

Has anyone opened at ticket with VMware?

I haven't, but I have posted to the ESXi5 forum. Where do I submit a bug/problem-report?
 
DutchDaemon said:
What happens when you replace

Code:
ifconfig_em0="inet 11.111.139.11/25"
ifconfig_em0_alias0="inet 11.111.139.12/32"
ifconfig_em0_alias1="inet 11.111.139.13/32"
ifconfig_em0_alias2="inet 11.111.139.14/32"
ifconfig_em0_alias3="inet 11.111.139.15/32"

with the more modern

Code:
ipv4_addrs_em0="11.111.139.11-15/25"
(yes, this will create 11/25, 12/32, 13/32, 14/32, 15/32)

and don't define any literal IPv4 aliases there?

See also the ipv6_prefix_ed0 example in rc.conf(5) which suggests that the same thing can be done for IPv6 aliases.

Whether this sorts out your alias conflicts automatically remains to be seen, of course.

Thanks. Will try. But it's more a nice thing to know than a real solution. Or can I also configure non-sequential IP's in this way?
For instance:

Code:
ipv4_addrs_em0="11.111.139.11-15,30-36/25"

.. to create create 11.111.139.11/25, 12/32, 13/32, 14/32, 15/32 + 11.111.139.30, 31/32, 32/32, 33/32, 34/32, 35/32 and 36/32?
 
I haven't tried it exactly like that, but this certainly works:

Code:
ipv4_addrs_em0="xx.yy.141.196/27 xx.yy.141.205/32 xx.yy.141.206/32 xx.yy.141.207/32"
 
Did you try the example from the manual? I can't try it locally.

Code:
For example, the following configuration

		 ipv6_prefix_ed0="2001:db8:1:0 2001:db8:2:0"

		 is equivalent to the following:

		 ifconfig_ed0_alias0="inet6 2001:db8:1:: eui64 prefixlen 64"
		 ifconfig_ed0_alias1="inet6 2001:db8:1:: prefixlen 64 anycast"
		 ifconfig_ed0_alias2="inet6 2001:db8:2:: eui64 prefixlen 64"
		 ifconfig_ed0_alias3="inet6 2001:db8:2:: prefixlen 64 anycast"
 
Back
Top