No, we're not doing anything with floating IPs at all, as far as this VM is concerned. The VM is created with only a fixed IP from a tenant network that's attached to an external network via a router.
These are the only logs in l3-agent around the time the VM was created:
--snip--
2020-01-02 20:42:40.506 31081 INFO neutron.agent.l3.agent [req-ecc73975-7759-4f95-a973-4c13cf24526b 5d6706b2a83e4bd99aa785eb1a090e2f b5c8283145054ef38c79253112b21e09 - - -] Got routers updated notification :[u'fd1da85e-773f-4fab-926f-8560caa4578d']
2020-01-02 20:42:40.507 31081 INFO neutron.agent.l3.agent [-] Starting router update for fd1da85e-773f-4fab-926f-8560caa4578d, action 3, priority 1
--snip--
I'm wondering if this is possible if the fixed IP attached to the VM was previously associated with an older VM, and the floating IP was attached to that? The ip rule could be leftover from the previous association. Just a wild idea, given the lack of errors in the logs.
No, we're not doing anything with floating IPs at all, as far as this VM is concerned. The VM is created with only a fixed IP from a tenant network that's attached to an external network via a router.
These are the only logs in l3-agent around the time the VM was created: agent.l3. agent [req-ecc73975- 7759-4f95- a973-4c13cf2452 6b 5d6706b2a83e4bd 99aa785eb1a090e 2f b5c8283145054ef 38c79253112b21e 09 - - -] Got routers updated notification :[u'fd1da85e- 773f-4fab- 926f-8560caa457 8d'] agent.l3. agent [-] Starting router update for fd1da85e- 773f-4fab- 926f-8560caa457 8d, action 3, priority 1
--snip--
2020-01-02 20:42:40.506 31081 INFO neutron.
2020-01-02 20:42:40.507 31081 INFO neutron.
--snip--
I'm wondering if this is possible if the fixed IP attached to the VM was previously associated with an older VM, and the floating IP was attached to that? The ip rule could be leftover from the previous association. Just a wild idea, given the lack of errors in the logs.