← Back to team overview

yahoo-eng-team team mailing list archive

[Bug 1443421] Re: After VM migration, tunnels not getting removed with L2Pop ON, when using multiple api_workers in controller

 

** Changed in: openstack-ansible/trunk
    Milestone: mitaka-2 => mitaka-3

** No longer affects: openstack-ansible/liberty

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

Title:
  After VM migration, tunnels not getting removed with L2Pop ON, when
  using multiple api_workers in controller

Status in neutron:
  In Progress
Status in openstack-ansible:
  Confirmed
Status in openstack-ansible trunk series:
  Confirmed

Bug description:
  Using multiple api_workers, for "nova live-migration" command, 
  a) tunnel flows and tunnel ports are always removed from old host
  b) and other hosts(sometimes) not getting notification about port delete from old host. So in other hosts, tunnel ports and flood flows(except unicast flow about port) for old host still remain.
  Root cause and fix is explained in comments 12 and 13.

  According to bug reporter, this bug can also be reproducible like below.
  Setup : Neutron server  HA (3 nodes).
  Hypervisor – ESX with OVsvapp
  l2 POP is on Network node and off on Ovsvapp.

  Condition:
  Make L2 pop on OVs agent, api workers =10 in the controller.

  On network node,the VXLAN tunnel is created with ESX2 and the Tunnel
  with ESX1 is not removed after migrating VM from ESX1 to ESX2.

  Attaching the logs of servers and agent logs.

  stack@OSC-NS1:/opt/stack/logs/screen$ sudo ovs-vsctl show
  662d03fb-c784-498e-927c-410aa6788455
      Bridge br-ex
          Port phy-br-ex
              Interface phy-br-ex
                  type: patch
                  options: {peer=int-br-ex}
          Port "eth2"
              Interface "eth2"
          Port br-ex
              Interface br-ex
                  type: internal
      Bridge br-tun
          Port patch-int
              Interface patch-int
                  type: patch
                  options: {peer=patch-tun}
          Port "vxlan-6447007a"
              Interface "vxlan-6447007a"
                  type: vxlan
                  options: {df_default="true", in_key=flow, local_ip="100.71.0.41", out_key=flow, remote_ip="100.71.0.122"}    <<<<<<<<<<<< This should have been deleted after MIGRATION.
          Port "vxlan-64470082"
              Interface "vxlan-64470082"
                  type: vxlan
                  options: {df_default="true", in_key=flow, local_ip="100.71.0.41", out_key=flow, remote_ip="100.71.0.130"}
          Port br-tun
              Interface br-tun
                  type: internal
          Port "vxlan-6447002a"
              Interface "vxlan-6447002a"
                  type: vxlan
                  options: {df_default="true", in_key=flow, local_ip="100.71.0.41", out_key=flow, remote_ip="100.71.0.42"}
      Bridge "br-eth1"
          Port "br-eth1"
              Interface "br-eth1"
                  type: internal
          Port "phy-br-eth1"
              Interface "phy-br-eth1"
                  type: patch
                  options: {peer="int-br-eth1"}
      Bridge br-int
          fail_mode: secure
          Port patch-tun
              Interface patch-tun
                  type: patch
                  options: {peer=patch-int}
          Port "int-br-eth1"
              Interface "int-br-eth1"
                  type: patch
                  options: {peer="phy-br-eth1"}
          Port br-int
              Interface br-int
                  type: internal
          Port int-br-ex
              Interface int-br-ex
                  type: patch
                  options: {peer=phy-br-ex}
          Port "tap9515e5b3-ec"
              tag: 11
              Interface "tap9515e5b3-ec"
                  type: internal
      ovs_version: "2.0.2"

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


References