yahoo-eng-team team mailing list archive
-
yahoo-eng-team team
-
Mailing list archive
-
Message #77654
[Bug 1794991] Re: Inconsistent flows with DVR l2pop VxLAN on br-tun
Reviewed: https://review.openstack.org/640797
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=a5244d6d44d2b66de27dc77efa7830fa657260be
Submitter: Zuul
Branch: master
commit a5244d6d44d2b66de27dc77efa7830fa657260be
Author: LIU Yulong <i@xxxxxxxxxxxx>
Date: Mon Mar 4 21:17:20 2019 +0800
More accurate agent restart state transfer
Ovs-agent can be very time-consuming in handling a large number
of ports. At this point, the ovs-agent status report may have
exceeded the set timeout value. Some flows updating operations
will not be triggerred. This results in flows loss during agent
restart, especially for hosts to hosts of vxlan tunnel flow.
This fix will let the ovs-agent explicitly, in the first rpc loop,
indicate that the status is restarted. Then l2pop will be required
to update fdb entries.
Closes-Bug: #1813703
Closes-Bug: #1813714
Closes-Bug: #1813715
Closes-Bug: #1794991
Closes-Bug: #1799178
Change-Id: I8edc2deb509216add1fb21e1893f1c17dda80961
** Changed in: neutron
Status: In Progress => Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1794991
Title:
Inconsistent flows with DVR l2pop VxLAN on br-tun
Status in neutron:
Fix Released
Bug description:
We are using Neutron (Pike) configured as DVR with l2pop and ARP
responder and VxLAN. Since few weeks we are experiencing unexpected
behaviors:
- [1] Some instances are not able to get DHCP address
- [2] Instances are not able to ping other instances on different compute
This is totally random, sometime it will work as expected and sometime
we will have the behaviors describe above.
After checking the flows between network and compute nodes we have
been able to discover that for behavior [1] it is due to missing flows
on the compute nodes pointing to the DHCP agent on the network one.
About behavior [2] it is related to missing flows too, some compute
nodes have missing output to other compute nodes (vxlan-xxxxxx) which
prevent an instance on compute 1 to communicate to an instance on
compute 2.
When we add the missing flows for [1] and [2] we are able to fix the
issues but if we restart neutron-openvswitch-agent the flows are
missing again.
For [1] sometime just disable/enable the port on the network nodes
related to each DHCP solve the problem and sometime not.
For [2] the only way we found to fix the flows without adding them
manually is to remove all instances of a network from the compute and
create a new instance from this network which will sends a
notification message to all computing and network nodes but again when
neutron-openvswitch-agent restart the flows vanish again.
We cherry-picked these commits but nothing changed:
- https://review.openstack.org/#/c/600151/
- https://review.openstack.org/#/c/573785/
Information about our deployment:
- OS: Ubuntu 16.04.5
- Deployer: Kolla
- Docker: 18.06
- OpenStack: Pike/Rocky
Any ideas ?
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1794991/+subscriptions
References