When neutron does a switch-over between router 1 and router2, the router1 conntrack flows shoud be deleted

Bug #1865061 reported by Slawek Kaplonski
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
neutron
Confirmed
Low
Unassigned

Bug Description

Originally reported for RHOSP-14 by Candido Campos.

Description of problem:

When neutron does a switch-over between router 1 and router2, the contrack flows of router1 shoud be deleted

How reproducible:

Steps to Reproduce:
1. Deploy OpenStack with 3 controllers
2. Create a Network with a router and at least one vm
3. create a fip and assign it to the vm
4. ssh to vm fip: ssh -vvv cirros@X.X.X.X
5. In controller with active router: ip netns exec qrouter-XX ip link set ha-XXX down ; ip netns exec qrouter-XX ip link set ha-XXX up
7.Check that contrack flows are not deleted: docker exec -t -i -u root neutron_l3_agent ip netns exec qrouter-XXX conntrack -L
7. Again In controller with active router: ip netns exec qrouter-XX ip link set ha-XXX down ; ip netns exec qrouter-XX ip link set ha-XXX up
8.When router active switch back to the previous router ssh connection is broken.

Actual results:

conntrack flows are reused. SSh connection is broken.

Expected results:

contrack flows are recreated. ssh connection isn't broken.

The problem exists only if second failover will be done in short time, before conntrack table on first controller will be cleared. So it's not very serious problem for real L3HA deployments probably but it would be nice to have it fixed.

Tags: l3-ha
Revision history for this message
LIU Yulong (dragon889) wrote :

HA router now has non-preemptive mode, that means the "original-master" is back again, the "new-master" should still work. So the SSH connection should be broken because Neutron now does not sync the conntrack flows. Then HA router is intentionally to do VRRP state change twice to simulate the real world issue? But how could it happen in real world? IMO, more like an infrastructure networking issue.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.