BGP: DVR fip has next_hop to snat gateway after associate first time
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
neutron |
Fix Released
|
Low
|
Ryan Tidwell |
Bug Description
ENV:
stable/mitaka
When A DVR floating IP associate to a port, the `floatingip_
But this bgp route is not right, its next_hop is set to snat gateway IP address.
And then after `periodic_interval` seconds, then the DR agent will resync that DVR fip route with new next_hop to the correct FIP namespace fg-device IP address.
Reproduce:
1. create a DVR router 1, set gateway
2. create a network/subnet, and connected to the DVR router 1
3. create a VM 1
4. bind a floating IP to that VM 1
5. in DR agent LOG, you may see the following infos:
2016-08-23 13:08:26.301 13559 INFO bgpspeaker.api.base [req-829d21e2-
2016-08-23 13:08:26.302 13559 INFO neutron.
2016-08-23 13:08:37.131 13559 INFO bgpspeaker.api.base [req-fa420676-
2016-08-23 13:08:37.131 13559 INFO neutron.
2016-08-23 13:08:37.132 13559 INFO bgpspeaker.api.base [req-fa420676-
2016-08-23 13:08:37.132 13559 INFO neutron.
description: | updated |
tags: | added: l3-bgp |
Changed in neutron: | |
status: | New → Confirmed |
importance: | Undecided → Low |
tags: | added: mitaka-backport-potential |
Changed in neutron: | |
assignee: | LIU Yulong (dragon889) → Ryan Tidwell (ryan-tidwell) |
This is happening because we seem to be assuming a centralized router when emitting the registry event on FIP association. I'm now beginning to see the wisdom in not including the host route in the registry event. We should just look up the host route in the registry event handler in neutron- dynamic- routing. The host route will be wrong initially, but within ~60 seconds the resync in the agent should clean things up. If we're not seeing this get straightened out after a re-sync, that is indicative of an issue with the agent re-sync.