Could this be a race condition? I saw something similar, too, when a user tried to attach floating IPs via terraform or ansible (I'm not quite sure) at the same time to two different VMs. We could trace it in the Logs that the port was first attached to the first instance and then failed for the other. I don't recall if they use a workaround at the moment or if just works now, will need to check with them. If this is a race condition can you do anything about it in Heat? Like some sort of delay? It could be a bug, though. Zitat von Adivya Singh <adivya1.singh@gmail.com>:

Hi Eugen,

These are orchestration Heat templates, if there is a Single FLoating IP creation using this templates it works fine, But if there are multiple floating IP attachment it shows there is a issue on 2 to 3 floating IP attached to the instance

Regards Adivya Singh

On Tue, Jun 21, 2022 at 5:59 PM Eugen Block <eblock@nde.ag> wrote:

...

Do you have ha routers enabled?

...

Most of the template having issue , Have all instance having FLoating IP, a Stack with a single floating IP have chance of issue very less

I don't quite understand that sentence, could you please clarify?

Zitat von Adivya Singh <adivya1.singh@gmail.com>:

...

hi Eugen,

The current setup is 3 controller nodes, The Load is not much on each controller and the number of DHCP agent is always set to 2 as per the standard in the neutron.conf, The L3 agent seems to be stables as other router namespace works fine under it, Only few router Namespace get affected under the agent.

Most of the template having issue , Have all instance having FLoating IP, a Stack with a single floating IP have chance of issue very less

Regards Adivya Singh

On Tue, Jun 21, 2022 at 1:18 PM Eugen Block <eblock@nde.ag> wrote:

...

Hi,

this sounds very familiar to me, I had to deal with something similar a couple of times in a heavily used cluster with 2 control nodes. What does your setup look like, is it a HA setup? I would start checking the DHCP and L3 agents. After increasing dhcp_agents_per_network to 2 in neutron.conf and restarting the services this didn't occur again (yet). This would impact floating IPs as well, sometimes I had to disable and enable the affected router(s). If you only have one control node a different approach is necessary. Do you see a high load on the control node?

Zitat von Adivya Singh <adivya1.singh@gmail.com>:

...

hi Team,

We got a issue in Xena release, where we set the environment in Ubuntu Platform, But later we get some issues in Floating IP not reachable.

In a Network node, not all router namespace are Impacted and only few of them get affected, So we can not comment Network node has a issue.

The L3 agent where the Router is tied up, Worked just fine, as other routers work Fine.

and the one having issue in Floating IP, if i unassigned and assigned it starts working most of the time.

Any thoughts on this

Regards Adivya Singh