| 2015-05-11 15:34:51 |
Assaf Muller |
bug |
|
|
added bug |
| 2015-05-11 15:51:15 |
Assaf Muller |
description |
When a node boots, it starts the OVS and L3 agents. As an example, in RDO systemd unit files, these services have no dependency. This means that the L3 agent can stop before the OVS agent. It can start configuring routers before the OVS agent finished syncing with the server and starts processing ovsdb monitor updates. The result is that when the L3 agent finishes configuring an HA router, it starts up keepalived, which under certain conditions will transition to master and send our gratuitous ARPs before the OVS agent finishes plugging its ports. This means that the gratuitous ARP will be lost, but with the router acting as master, this can cause black holes.
Possible solutions:
* Introduce systemd dependencies, but this has its set of intricacies and it's hard to solve the above problem comprehensively just with this approach.
* Regardless, it's a good idea to use new keepalived flags:
garp_master_repeat <INTEGER> # how often the gratuitous ARP after MASTER
# state transition should be repeated?
garp_master_refresh <INTEGER> # Periodic delay in seconds sending
# gratuitous ARP while in MASTER state |
When a node boots, it starts the OVS and L3 agents. As an example, in RDO systemd unit files, these services have no dependency. This means that the L3 agent can stop before the OVS agent. It can start configuring routers before the OVS agent finished syncing with the server and starts processing ovsdb monitor updates. The result is that when the L3 agent finishes configuring an HA router, it starts up keepalived, which under certain conditions will transition to master and send our gratuitous ARPs before the OVS agent finishes plugging its ports. This means that the gratuitous ARP will be lost, but with the router acting as master, this can cause black holes.
Possible solutions:
* Introduce systemd dependencies, but this has its set of intricacies and it's hard to solve the above problem comprehensively just with this approach.
* Regardless, it's a good idea to use new keepalived flags:
garp_master_repeat <INTEGER> how often the gratuitous ARP after MASTER state transition should be repeated?
garp_master_refresh <INTEGER> Periodic delay in seconds sending gratuitous ARP while in MASTER state |
|
| 2015-05-11 15:51:30 |
Assaf Muller |
description |
When a node boots, it starts the OVS and L3 agents. As an example, in RDO systemd unit files, these services have no dependency. This means that the L3 agent can stop before the OVS agent. It can start configuring routers before the OVS agent finished syncing with the server and starts processing ovsdb monitor updates. The result is that when the L3 agent finishes configuring an HA router, it starts up keepalived, which under certain conditions will transition to master and send our gratuitous ARPs before the OVS agent finishes plugging its ports. This means that the gratuitous ARP will be lost, but with the router acting as master, this can cause black holes.
Possible solutions:
* Introduce systemd dependencies, but this has its set of intricacies and it's hard to solve the above problem comprehensively just with this approach.
* Regardless, it's a good idea to use new keepalived flags:
garp_master_repeat <INTEGER> how often the gratuitous ARP after MASTER state transition should be repeated?
garp_master_refresh <INTEGER> Periodic delay in seconds sending gratuitous ARP while in MASTER state |
When a node boots, it starts the OVS and L3 agents. As an example, in RDO systemd unit files, these services have no dependency. This means that the L3 agent can stop before the OVS agent. It can start configuring routers before the OVS agent finished syncing with the server and starts processing ovsdb monitor updates. The result is that when the L3 agent finishes configuring an HA router, it starts up keepalived, which under certain conditions will transition to master and send our gratuitous ARPs before the OVS agent finishes plugging its ports. This means that the gratuitous ARP will be lost, but with the router acting as master, this can cause black holes.
Possible solutions:
* Introduce systemd dependencies, but this has its set of intricacies and it's hard to solve the above problem comprehensively just with this approach.
* Regardless, it's a good idea to use new keepalived flags:
garp_master_repeat <INTEGER> how often the gratuitous ARP after MASTER state transition should be repeated?
garp_master_refresh <INTEGER> Periodic delay in seconds sending gratuitous ARP while in MASTER state
These will be configurable and have sane defaults. |
|
| 2015-05-11 21:52:14 |
Sridhar Gaddam |
neutron: assignee |
|
Sridhar Gaddam (sridhargaddam) |
|
| 2015-05-12 13:45:56 |
Assaf Muller |
neutron: assignee |
Sridhar Gaddam (sridhargaddam) |
Nir Magnezi (nmagnezi) |
|
| 2015-05-13 13:12:55 |
Assaf Muller |
description |
When a node boots, it starts the OVS and L3 agents. As an example, in RDO systemd unit files, these services have no dependency. This means that the L3 agent can stop before the OVS agent. It can start configuring routers before the OVS agent finished syncing with the server and starts processing ovsdb monitor updates. The result is that when the L3 agent finishes configuring an HA router, it starts up keepalived, which under certain conditions will transition to master and send our gratuitous ARPs before the OVS agent finishes plugging its ports. This means that the gratuitous ARP will be lost, but with the router acting as master, this can cause black holes.
Possible solutions:
* Introduce systemd dependencies, but this has its set of intricacies and it's hard to solve the above problem comprehensively just with this approach.
* Regardless, it's a good idea to use new keepalived flags:
garp_master_repeat <INTEGER> how often the gratuitous ARP after MASTER state transition should be repeated?
garp_master_refresh <INTEGER> Periodic delay in seconds sending gratuitous ARP while in MASTER state
These will be configurable and have sane defaults. |
When a node boots, it starts the OVS and L3 agents. As an example, in RDO systemd unit files, these services have no dependency. This means that the L3 agent can start before the OVS agent. It can start configuring routers before the OVS agent finished syncing with the server and starts processing ovsdb monitor updates. The result is that when the L3 agent finishes configuring an HA router, it starts up keepalived, which under certain conditions will transition to master and send our gratuitous ARPs before the OVS agent finishes plugging its ports. This means that the gratuitous ARP will be lost, but with the router acting as master, this can cause black holes.
Possible solutions:
* Introduce systemd dependencies, but this has its set of intricacies and it's hard to solve the above problem comprehensively just with this approach.
* Regardless, it's a good idea to use new keepalived flags:
garp_master_repeat <INTEGER> how often the gratuitous ARP after MASTER state transition should be repeated?
garp_master_refresh <INTEGER> Periodic delay in seconds sending gratuitous ARP while in MASTER state
These will be configurable and have sane defaults. |
|
| 2015-07-13 13:36:25 |
OpenStack Infra |
neutron: status |
New |
In Progress |
|
| 2015-07-24 17:21:26 |
OpenStack Infra |
neutron: status |
In Progress |
Fix Committed |
|
| 2015-07-29 18:59:12 |
Doug Hellmann |
neutron: status |
Fix Committed |
Fix Released |
|
| 2015-07-29 18:59:12 |
Doug Hellmann |
neutron: milestone |
|
liberty-2 |
|
| 2015-08-01 01:05:45 |
OpenStack Infra |
tags |
l3-ha |
in-feature-pecan l3-ha |
|
| 2015-08-01 02:20:35 |
OpenStack Infra |
tags |
in-feature-pecan l3-ha |
in-feature-pecan in-stable-kilo l3-ha |
|
| 2015-08-02 10:11:23 |
OpenStack Infra |
tags |
in-feature-pecan in-stable-kilo l3-ha |
in-feature-pecan in-stable-juno in-stable-kilo l3-ha |
|
| 2015-10-15 12:25:56 |
Thierry Carrez |
neutron: milestone |
liberty-2 |
7.0.0 |
|
| 2015-11-14 10:34:30 |
Alan Pevec |
nominated for series |
|
neutron/juno |
|
| 2015-11-14 10:34:30 |
Alan Pevec |
bug task added |
|
neutron/juno |
|
| 2015-11-14 15:07:44 |
Alan Pevec |
neutron/juno: status |
New |
Fix Committed |
|
| 2015-11-14 15:07:44 |
Alan Pevec |
neutron/juno: milestone |
|
2014.2.4 |
|
| 2015-11-19 21:45:40 |
Alan Pevec |
neutron/juno: status |
Fix Committed |
Fix Released |
|
| 2016-01-31 22:40:01 |
OpenStack Infra |
tags |
in-feature-pecan in-stable-juno in-stable-kilo l3-ha |
in-feature-pecan in-stable-juno in-stable-kilo in-stable-liberty l3-ha |
|
| 2016-05-09 11:45:42 |
Dave Walker |
nominated for series |
|
neutron/kilo |
|
| 2016-05-09 11:45:42 |
Dave Walker |
bug task added |
|
neutron/kilo |
|
