yahoo-eng-team team mailing list archive

[Mark McClain <1228313@xxxxxxxxxxxxxxxxxx>]

** Changed in: neutron
       Status: New => Invalid

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

Title:
  Multiple tap interfaces on controller have overlapping tags

Status in OpenStack Neutron (virtual network service):
  Invalid

Bug description:
  Host: Ubuntu
  Release: Grizzly w/ Quantum

  Multiple problems reported, including instances no longer receiving
  IPs via DHCP. My troubleshooting usually involves confirming
  connectivity from the namespaces and checking OVS, so I logged into
  the controller to find the following tap interfaces had overlapping
  tags:

  Port "tap78c4dd08-ad"
              tag: 1
              Interface "tap78c4dd08-ad"
                  type: internal

  Port "tapa827f51e-be"
              tag: 1
              Interface "tapa827f51e-be"
                  type: internal

  Port "tap5ec14dfb-56"
              tag: 1
              Interface "tap5ec14dfb-56"
                  type: internal

  There were approximately 8 provider networks configured, and these
  taps corresponded to 3 different namespaces on the controller. The
  other taps had unique tags (as expected). Pinging from each namespace
  revealed only one of the three namespaces to be working properly.
  Restarting the 'openvswitch-switch' service renumbered the tags and
  restored connectivity from all namespaces. Looking back I should have
  checked the ovs flows to see what the rules looked like, but I was in
  a hurry to get things working.

  The user of the system is in the process of testing their environment,
  which includes constanting creating networks/subnets/instances,
  removing them, and recreating them via API.

  I don't have any additional information to provide, but am curious to
  know how we might be able to recreate a condition that would cause
  overlapping tags such as this. Plan to check the flows the next time
  this happens to confirm the theory of duplicate/overlapping rules w/
  incorrect vlan rewrites.

  Thanks- JD

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