Networking problem in Eucalyptus when VNET_PUBLICIPS has an IP being used in its range

Bug #476619 reported by Etienne Goyer
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Eucalyptus
Won't Fix
Undecided
Daniel Nurmi
eucalyptus (Ubuntu)
Won't Fix
Wishlist
Unassigned

Bug Description

This was reported to me by a third-party, and I have not verified or reproduced the problem myself. Also, I understand it is a user error, but I think we should have some safeguard against it, as it is an easy one to make.

If the VNET_PUBLICIPS directive include an IP that is being used by the CC, networking will get very get wonky when that IP is attributed to an instance. For example, given a frontend (CC) that as an IP of 192.168.1.100 for eth0 (it's "public" interface), if you have VNET_PUBLICIPS="192.168.1.100-192.168.1.200" in /etc/eucalyptus/eucalyptus.conf (that could happen, for example, if you provided that range during the installation), then Eucalyptus will assign 192.168.1.100 as public IP for the first instance to be run, and then neither the instance nor the frontend will be reachable from the network. Inspecting the output of ifconfig, you will notice that both eth0 and eth0:publics interfaces have 192.168.1.100 as an IP, which is probably what broke networking on the frontend.

Best would be for Eucalyptus to actually check for that condition and not assign an IP that is in use by the CC to an instance.

Thierry Carrez (ttx)
Changed in eucalyptus (Ubuntu):
importance: Undecided → Wishlist
status: New → Triaged
Changed in eucalyptus (Ubuntu):
status: Triaged → Won't Fix
Changed in eucalyptus:
assignee: nobody → Daniel Nurmi (nurmi)
Daniel Nurmi (nurmi)
Changed in eucalyptus:
status: New → Won't Fix
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.