yahoo-eng-team team mailing list archive

[Eugene Nikanorov <enikanorov@xxxxxxxxxxxx>]

I think that will never be fixed for Grizzly as that release is quite old.
Also, AFAIK, GRE requires OVS 1.10+ to work.

Marking as 'Won't Fix'

** Tags added: ovs

** Changed in: neutron
       Status: New => Won't Fix

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1269795

Title:
  Network node port tags not reliably implementing

Status in OpenStack Neutron (virtual network service):
  Won't Fix

Bug description:
  I'm getting inconsistent implementations of port tags for router
  internal interfaces and DHCP interfaces when they're created in OVS by
  the Quantum OVS Plugin.

  The resulting symptom is that when a new network/subnet is created
  then either the instance is not able to get a DHCP address (this is
  when the dhcp port isn't tagged) or the instance is unable to
  communicate outside of its network (this is when the internal router
  interface port isn't tagged).

  Environment:
   - Ubuntu 12.04.3 LTS
   - Grizzly 2013.1.4-0ubuntu1~cloud0
   - Quantum with GRE Tunneling
   - OpenVSwitch 1.4.0-1ubuntu1.5

  For example, what I should be seeing is something like this:

          Port "tap7ef1ee95-52"
              tag: 30
              Interface "tap7ef1ee95-52"
                  type: internal
          Port "qr-8bfc6675-3a"
              tag: 13
              Interface "qr-8bfc6675-3a"
                  type: internal

  However, I end up seeing something like this:

          Port "tap2b520e87-5e"
              Interface "tap2b520e87-5e"
                  type: internal
          Port "qr-ba0036f3-7e"
              Interface "qr-ba0036f3-7e"
                  type: internal

  It's not consistently happening - sometimes it actually is done
  correctly.

  The workaround to repair this is either to manually tag the interfaces
  (which can be done if at least one of the ports on the subnet was
  correctly tagged) or to restart 'quantum-plugin-openvswitch-agent',
  which unfortunately causes a drop in connectivity for those which were
  correctly tagged.

  Has anyone else seen this?

  Does anyone know of a bug fix or perhaps a better workaround?

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1269795/+subscriptions