yahoo-eng-team team mailing list archive

[OpenStack Infra <1590397@xxxxxxxxxxxxxxxxxx>]

Reviewed:  https://review.openstack.org/327651
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=8893ebe6c5aa2baf5665e96e939d53bcef08c9d7
Submitter: Jenkins
Branch:    master

commit 8893ebe6c5aa2baf5665e96e939d53bcef08c9d7
Author: Ihar Hrachyshka <ihrachys@xxxxxxxxxx>
Date:   Thu Jun 9 23:44:32 2016 +0200

    ovs: set device MTU after it's moved into a namespace
    
    Open vSwitch forbids to raise MTU for devices that are in the same
    namespace with the bridge, but allows that same operation once the
    device in question is moved into another namespace. This is a side
    effect of missing validation in vswitchd implementation for plugged
    interfaces located in other namespaces.
    
    This behaviour makes the order in which we move device into a namespace
    and set MTU significant. The previous order left MTU lowered for router
    and dhcp ports in case there was a port served by that same bridge with
    lower MTU.
    
    This effectively lowers MTU for router interfaces from what is supported
    by underlying physical interfaces. With that, frames from an external
    network of infrastructure MTU size will not be served by affected
    routers.
    
    This Neutron issue affects all systems where router or dhcp ports are
    served on the same node as compute ports. This includes any AIO setup,
    as well as L3/DHCP agents colocated with nova-compute. While for
    traditional (legacy) L3 agents, such setup is not that widely used, the
    bug probably affects real world DVR setups that maintain router
    namespaces on compute nodes.
    
    The fix reverses the order of interface plugging procedure steps, first
    moving ports into namespaces, then setting their MTUs. This seems to
    solve the issue.
    
    The fix is short term, because we effectively utilize a bug in Open
    vSwitch. A better long term fix could be rearranging bridge setup so
    that there is no need to plug devices that belong to different networks
    into the same bridges. That would require an extensive thought and would
    open questions on how to migrate existing workloads using the current
    bridge setup to the new world without significant data path disruption.
    
    Added functional test that triggered the issue before the fix.
    
    Change-Id: Ibd9866d2d8fe12bb253c6fb9978f583293b32734
    Closes-Bug: #1590397


** 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/1590397

Title:
  Router interfaces get wrong MTU inherited from br-int

Status in neutron:
  Fix Released

Bug description:
  When booting an instance on a network with encapsulation type vxlan
  (and thus automatically set MTU to 1450), this will also lower the MTU
  of the integration bridge to that value:

  $ ip link show br-int
  6: br-int: <BROADCAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UNKNOWN mode DEFAULT group default
      link/ether 7e:39:32:87:27:44 brd ff:ff:ff:ff:ff:ff

  In turn, all newly created ports for routers, DHCP agents and the
  like, will also be created with MTU 1450, as they are forked off br-
  int.

  This effectively lowers MTU for router interfaces from what is supported
  by underlying physical interfaces. With that, frames from an external
  network of infrastructure MTU size will not be served by affected
  routers.

  This bug affects all systems where router or dhcp ports are served on
  the same node as compute ports. This includes any AIO setup, as well as
  L3/DHCP agents colocated with nova-compute. While for traditional
  (legacy) L3 agents, such setup is not that widely used, the bug probably
  affects real world DVR setups that maintain router namespaces on compute
  nodes.

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