Comment 10 for bug 1956846

Rudolfo, Maximilian,

It isn't clear to me that the change in Neutron to adding routes with protocol "static" rather than the old (default) protocol "boot" will make any difference for Maximilian; he will still end up with duplicate routes which seems to be the basic problem.

Rudolfo, you state 'upgrade to Train. As commented, since this version any route without a defined protocol will be created/updated with protocol "static".' Does this imply that if Maximilian specifies the routes to be "proto keepalived" or "proto 18" that Neutron will create the routes with that protocol? A quick look at the code you have provided links to doesn't appear to support a protocol being configured.

I presume that when Maximilian upgrades to train, if he wants to use the same workaround as he is using now by specifing "proto boot", he will need to change that to "proto static".

Rudolfo, as you mention above, I think the real cause of the problem is that Neutron is adding the routes which keepalived is managing. I cannot see any reason for Neutron doing that, and it means that the virtual_routes functionality in keepalived cannot be used properly, since the routes will exist even when the VRRP instance is not in master state, since Neutron has created them. The purpose of the virtual_routes, virtual_rules and virtual_ipaddresses is that they are only configured when the VRRP instance is in master state.

It isn't clear to me in the code where Neutron is creating the routes, but is it also the virtual IP addresses and virtual ip rules that keepalived manages?