neutron ovs agent restart introduces downtime

Bug #1592534 reported by Dmitry Sutyagin
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Mirantis OpenStack
Status tracked in 10.0.x
MOS Neutron
Won't Fix
MOS Maintenance
Alexander Ignatov

Bug Description

Reproducible on - all version up to 8.0, have not tried on 9.0

  restarting neutron-plugin-openvswitch-agent introduces network downtime
  stop of the agent does not introduce downtime, but start does.

Steps to reproduce:
  1 - start ping of a floating ip / internal ip of a VM
  2 - stop neutron-plugin-openvswitch-agent on compute
  3 - start neutron-plugin-openvswitch-agent on compute
  4 - observe several lost packets

I believe it should be possible to start agent without manipulating ovs internals if they are already correctly set up - we need to make necessary checks (read operations) and act based on results, and avoid touching anything which is already configured correctly.

I believe a similar issue is with neutron-l3-agent if we kill it and then it starts back up (by pacemaker)

description: updated
Revision history for this message
Bug Checker Bot (bug-checker) wrote : Autochecker

(This check performed automatically)
Please, make sure that bug description contains the following sections filled in with the appropriate data related to the bug you are describing:

actual result

expected result

For more detailed information on the contents of each of the listed sections see

tags: added: need-info
Revision history for this message
Eugene Nikanorov (enikanorov) wrote :

losing several packets is not yet a downtime.
tcp layer can handle that.

There was a fix upstream which eliminates rebuilding the connection between br-int and physical bridges.

Changed in mos:
importance: Undecided → Medium
Revision history for this message
Dina Belova (dbelova) wrote :

Targeting to 10.0 (at least for now) due to medium priority.

Changed in mos:
milestone: none → 10.0
status: New → Confirmed
tags: added: move-to-10.0
tags: added: 10.0-reviewed
Revision history for this message
Alexander Ignatov (aignatov) wrote :

@Dmitry, I was tried to reproduce this issue on released 9.0 ISO, it's not reproducible there with the same scenario you mentioned in bug description. I believe this is fixed by,n,z

You can try latest 8.0-MU to check if it's fixed in liberty-based code.
Closing this bug for 9.1 and 10.0.

Revision history for this message
Dmitry Sutyagin (dsutyagin) wrote :


This is reproducible on the latest 8.0 MU. Will test on 9.0 today to confirm your results.

Revision history for this message
Dmitry Sutyagin (dsutyagin) wrote :

Confirm - not reproducible in 9.0, and like I stated earlier - reproducible in 8.0 MU1. However maybe 8.0 MU2 due to be released next week will fix that issue, I don't know.

Revision history for this message
Denis Meltsaykin (dmeltsaykin) wrote :

Closing as Won't Fix as this is a medium importance non-customer-found bug.

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.