openstack team mailing list archive

[Kiall Mac Innes <kiall@xxxxxxxxxxxx>]

<stab in the dark>
Have you kept an eye on the mysql table itself, rather than relying on the
cli tools / dashboard that may very well cache the data?
</stab in the dark>

Thanks,
Kiall


On Wed, Mar 28, 2012 at 1:58 PM, Kevin Jackson <kevin@xxxxxxxxxxxxxxxxxxx>wrote:

> Cheers Phil,
> It's not that I can't get to the instances - I'd assume it was an ARP
> issue at that point - its the fact that Nova hasn't notified me that it has
> assigned an IP address: see my additional note where I guessed an IP
> address it would've assigned and I could access it... but management tools
> were still blissfully unaware.
> I used to have a working Diablo set up with pretty much this same set up
> (this is under Essex RC1 / Ubuntu 12.04) and never had an issue.
>
> This just looks like it has assigned the IP to the instance, but hasn't
> notified the management underbelly of MySQL so any client tools
> interrogating the instance doesn't see that nova has done this work already.
>
> Kev
>
>
> On 28 March 2012 13:04, Day, Phil <philip.day@xxxxxx> wrote:
>
>> Are you sure that its Nova that is taking the time to associate the IP,
>> and not an ARP issue in your network ?****
>>
>> ** **
>>
>> I’ve seen this behaviour when quickly reusing floating IP addresses –
>> Nova does the assignment and sends out an unsolicited ARP response
>> (assuming you have the “send_arp_for_ha” flag set) – this is in
>> network/linux_net.bind_floating_ip().   However  sometimes an unsolicited
>> APR response can get dropped in the network, ad so if the switch doesn’t
>> see this message and it already has a previous ARP mapping in its cache
>> then it will continue to try and send traffic to the previous user of that
>> address until the cache times out. ****
>>
>> ** **
>>
>> Note that some network failover systems send multiple requests to get
>> more certainty around this (for example I’ve seen a VPN solution use 6
>> messages).****
>>
>> ** **
>>
>> There are a couple of things you could try:****
>>
>> ** **
>>
>> **-          **Add a flag to be able to increase the number of
>> arp_responses sent****
>>
>> **-          **Change the allocation of floating_ips so that instead of
>> picking the first free one in the DB you pick the one which has been unused
>> for the longest time (reduces the risk of reusing an address before the
>> switch times out the entry in its cache).****
>>
>> ** **
>>
>> Phil****
>>
>> ** **
>>
>> *From:* openstack-bounces+philip.day=hp.com@xxxxxxxxxxxxxxxxxxx [mailto:
>> openstack-bounces+philip.day=hp.com@xxxxxxxxxxxxxxxxxxx] *On Behalf Of *Kevin
>> Jackson
>> *Sent:* 28 March 2012 12:49
>> *To:* openstack@xxxxxxxxxxxxxxxxxxx
>> *Subject:* [Openstack] Auto Assigned Floating IPs take a long time to
>> associate****
>>
>> ** **
>>
>> Hi all,****
>>
>> I've got the following set in my nova.conf:****
>>
>> ** **
>>
>> --auto_assign_floating_ip****
>>
>> ** **
>>
>> and I fire up an instance.****
>>
>> Everything works, a private IP is assigned... the instance is running...
>> but it can take an inordinate amount of time (anywhere upwards of 2 mins,
>> sometimes a lot longer) to associate a floating IP automatically.****
>>
>> ** **
>>
>> Anybody else experienced this?  Any clues on what I can do to
>> troubleshoot this?  What is the condition when a Floating IP is assigned?
>>  I've seen it assign Floating IPs very quickly when it is still Booting,
>> not Active, say.****
>>
>> Is it dependent on anything within the Instance itself?****
>>
>> ** **
>>
>> Cheers,****
>>
>> ** **
>>
>> Kev****
>>
>> --
>> Kevin Jackson
>> @itarchitectkev****
>>
>
>
>
> --
> Kevin Jackson
> @itarchitectkev
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>