yahoo-eng-team team mailing list archive

[Tore Anderson <tore@xxxxxx>]

Public bug reported:

When using an overlay network on a physical network with standard
Ethernet MTU (1500 octets), the instances' effective MTU is reduced.

The Neutron Router should inform the nodes about this fact, by including
the MTU Option in the ICMPv6 Router Advertisements it sends. The current
situation leads to blackholing of traffic, as the absence of the MTU
Option causes the instance to believe it will be able to successfully
transmit 1500 octets large frames to the network. However, these will be
silently discarded. The symptom of is usually that the TCP three-way
handshake succeeds, but that the connection appears to hang the moment
payload starts being transmitted.

The MTU Option is documented here:
https://tools.ietf.org/html/rfc4861#section-4.6.4. The corresponding
radvd.conf option is called AdvLinkMTU. Note that the Neutron router is
clearly aware of the reduced effective MTU, as it does use the
corresponding DHCPv4 option to advertise it to instances/subnets using
IPv4.

I observe this problem on OpenStack Kilo.

** Affects: neutron
     Importance: Undecided
         Status: New

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

Title:
  MTU Option should be included in ICMPv6 Router Advertisements

Status in neutron:
  New

Bug description:
  When using an overlay network on a physical network with standard
  Ethernet MTU (1500 octets), the instances' effective MTU is reduced.

  The Neutron Router should inform the nodes about this fact, by
  including the MTU Option in the ICMPv6 Router Advertisements it sends.
  The current situation leads to blackholing of traffic, as the absence
  of the MTU Option causes the instance to believe it will be able to
  successfully transmit 1500 octets large frames to the network.
  However, these will be silently discarded. The symptom of is usually
  that the TCP three-way handshake succeeds, but that the connection
  appears to hang the moment payload starts being transmitted.

  The MTU Option is documented here:
  https://tools.ietf.org/html/rfc4861#section-4.6.4. The corresponding
  radvd.conf option is called AdvLinkMTU. Note that the Neutron router
  is clearly aware of the reduced effective MTU, as it does use the
  corresponding DHCPv4 option to advertise it to instances/subnets using
  IPv4.

  I observe this problem on OpenStack Kilo.

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