Ubuntu
gnome-nettool package

auto eth0:0 directive in /etc/network/interfaces & "Waiting for network configuration" on boot

Asked by billy

I'm sorry if this was already addressed elsewhere but I can't find a definitive answer to this exact problem even if it seems to affect a lot of people...

Configuring a "Virtual Network Adapter" via the "auto eth0:0" syntax delays boot with Ubuntu 12.04.

In previous versions of Ubuntu you could configure an ethernet interface with multiple static IPs by using this kind of configuration in /etc/network/interfaces:

auto eth0
iface eth0 inet static
        address 192.168.0.64
        netmask 255.255.255.0
        gateway 192.168.0.1

auto eth0:0
iface eth0:0 inet static
        address 192.168.0.65
        netmask 255.255.255.0
        gateway 192.168.0.1

In 12.04 this configuration still works a expected (the two interfaces are brought up and pingable just after the kernel is booted), however the boot process is then delayed for 2 minutes with the messages:
"Waiting for network configuration..."
"Waiting up to 60 more seconds for network configuration..."
"Booting system without full network configuration..."

The messages and delay can be traced to the /etc/init/failsafe.conf file and the behavior can be traced back to the "auto eth0:0" directive.

All the related launchpad issues and forum posts I found are marked as resolved, but I still have this problem with a fully updated fresh install of the 12.04 base system.

So I was wondering if this was intended behaviour, or is this kind of virtual interface configuration still supported ?
If it's still supposed to work, is there an opened launchpad issue I can refer to ?
If not, what's the preferred way to assign a second static IP ?

Question information

Language:
English Edit question
Status:
Solved
For:
Ubuntu gnome-nettool Edit question
Assignee:
No assignee Edit question
Solved by:
actionparsnip
Solved:
Last query:
Last reply:
Revision history for this message
Best actionparsnip (andrew-woodhead666) said : 		#1

Should you give the interface itself an IP if you are using subinterfaces? You also have 2 interfaces on the same subnet which will cause all sorts of headaches.

Revision history for this message
actionparsnip (andrew-woodhead666) said : 		#2

Try:

auto eth0:0
iface eth0:0 inet static
        address 192.168.1.65
        netmask 255.255.255.0
        gateway 192.168.1.1

Revision history for this message
billy (miztadux) said : 		#3

Thanks for pointing out the same subnet issue, I've been using this kind of configuration for so long that it didn't even cross my mind (kind of mandated by the environment where the servers are)

As for setting up the base eth0 itself, I think this is the usual way of doing things, at least according to the various documentations.

Anyway the same behavior is exhibited when using different subnets, boot still goes to failsafe even though the interfaces are brought up correctly.

Revision history for this message
billy (miztadux) said : 		#4

Your subnets comment gave me an idea, as you point out this setup has ambiguous routing.
Sure enough removing the gateway line on the sub-interfaces does the trick, no more failsafe :)

Here's a example configuration that works on a test vm:

auto eth0
iface eth0 inet static
        address 192.168.0.64
        netmask 255.255.255.0
        gateway 192.168.0.1
        dns-nameservers 192.168.0.1

auto eth0:0
iface eth0:0 inet static
        address 192.168.0.65
        netmask 255.255.255.0

auto eth0:1
iface eth0:1 inet static
        address 192.168.1.65
        netmask 255.255.255.0

(note that the netmask for eth0:0 could also be 255.255.255.255, to avoid a duplicate route, but it doesn't matter for virtual interfaces)

OR so I thought...but when trying this config on real servers (with more packages installed) I got another issue: now the subinterfaces don't show up, but doing "ifup eth0:0" says they are.
Doing ifdown && ifup brought'em back up, but at this may be a whole other problem...

Thanks for the time you took helping me on this.

Revision history for this message
billy (miztadux) said : 		#5

Further testing on the new "aliases not brought up" issue points to the open-vm-tools package and is not related to my original question.
The answer to which seems be getting rid of the gateway directive for the aliases.

Thanks again for responding.

Revision history for this message
billy (miztadux) said : 		#6

Thanks actionparsnip, that solved my question.