Neutron agents do not use network MTU

[Kevin Benton]

The Neutron agents do not use the MTU set in the network object for their interfaces. This prevents the L3 and DHCP agents from being compatible with networks with jumbo frames and it causes them to transmit packets larger than the network's MTU onto the network where they will be dropped instead of correctly fragmenting, generating an ICMP error; or, in the case of the DHCP agent, reducing the MSS for its traffic.

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/283790
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=4df8d9a7016ab20fce235833d792b89309ec98a7
Submitter: Jenkins
Branch: master

commit 4df8d9a7016ab20fce235833d792b89309ec98a7
Author: Kevin Benton <email address hidden>
Date: Mon Feb 22 16:41:45 2016 -0800

    Make agent interface plugging utilize network MTU

    This changes the 'plug' and 'plug_new' interfaces of the
    LinuxInterfaceDriver to accept an MTU argument. It then
    updates the dhcp agent and l3 agent to pass the MTU that
    is set on the network that the port belongs to. This allows
    it to take into account the overhead calculations that are
    done for encapsulation types.

    It's necessary for the L3 agent to have the MTU because it
    must recognize when fragmentation is needed so it can fragment
    or generate an ICMP error.

    It's necessary for the DHCP agent to have the MTU so it doesn't
    interfere when it plugs into a bridge with a larger than 1500
    MTU (the bridge would reduce its MTU to match the agent).

    If an operator sets 'network_device_mtu', the value of that
    will be used instead to preserve previous behavior.

    Closes-Bug: #1549470
    Closes-Bug: #1542108
    Closes-Bug: #1542475
    DocImpact: Neutron agents now support arbitrary MTU
               configurations on each network (including
               jumbo frames). This is accomplished by checking
               the MTU value defined for each network on which
               it is wiring VIFs.
    Co-Authored-By: Matt Kassawara <email address hidden>
    Change-Id: Ic091fa78dfd133179c71cbc847bf955a06cb248a

[YAMAMOTO Takashi (yamamoto)]

this affects midonet interface driver resides in networking-midonet.

[Thierry Carrez (ttx)]

This issue was fixed in the openstack/neutron 8.0.0.0b3 development milestone.

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/287073
Committed: https://git.openstack.org/cgit/openstack/networking-midonet/commit/?id=13e2fc56713d1af074248516ef635d824feaf92c
Submitter: Jenkins
Branch: master

commit 13e2fc56713d1af074248516ef635d824feaf92c
Author: YAMAMOTO Takashi <email address hidden>
Date: Wed Mar 2 17:51:09 2016 +0900

    Add mtu argument to the interface driver plug_new

    To match with the latest Neutron.

    Closes-Bug: #1552135
    Closes-Bug: #1549470
    Related Neutron change: Ic091fa78dfd133179c71cbc847bf955a06cb248a
    Change-Id: I9a660922b1aa6826ec19696ee81abb1e9f11d6a4

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/liberty
Review: https://review.openstack.org/305782

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/305782
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=c55aba1dba31c6730c80db0118286f1f9e84cd9b
Submitter: Jenkins
Branch: stable/liberty

commit c55aba1dba31c6730c80db0118286f1f9e84cd9b
Author: Kevin Benton <email address hidden>
Date: Mon Feb 22 16:41:45 2016 -0800

    Make agent interface plugging utilize network MTU

    This changes the 'plug' and 'plug_new' interfaces of the
    LinuxInterfaceDriver to accept an MTU argument. It then
    updates the dhcp agent and l3 agent to pass the MTU that
    is set on the network that the port belongs to. This allows
    it to take into account the overhead calculations that are
    done for encapsulation types.

    It's necessary for the L3 agent to have the MTU because it
    must recognize when fragmentation is needed so it can fragment
    or generate an ICMP error.

    It's necessary for the DHCP agent to have the MTU so it doesn't
    interfere when it plugs into a bridge with a larger than 1500
    MTU (the bridge would reduce its MTU to match the agent).

    If an operator sets 'network_device_mtu', the value of that
    will be used instead to preserve previous behavior.

    Conflicts:
     neutron/agent/l3/dvr_edge_ha_router.py
     neutron/agent/l3/dvr_edge_router.py
     neutron/agent/l3/ha_router.py
     neutron/agent/linux/interface.py
     neutron/tests/functional/agent/l3/test_dvr_router.py
     neutron/tests/functional/agent/test_dhcp_agent.py

    Additional modifications for Liberty:
    - test_dvr_router_lifecycle_ha_with_snat_with_fips_nmtu renamed into
      test_dvr_router_lifecycle_without_ha_with_snat_with_fips_nmtu,
    - the test validates DVR without HA.

    Reason for the change: Liberty does not support DVR + HA routers (the
    test raises DvrHaRouterNotSupported without those modifications).

    Closes-Bug: #1549470
    Closes-Bug: #1542108
    Closes-Bug: #1542475
    DocImpact: Neutron agents now support arbitrary MTU
               configurations on each network (including
               jumbo frames). This is accomplished by checking
               the MTU value defined for each network on which
               it is wiring VIFs.
    Co-Authored-By: Matt Kassawara <email address hidden>
    (cherry picked from commit 4df8d9a7016ab20fce235833d792b89309ec98a7)

    ===

    Also squashing in the following fix to pass unit tests for midonet
    interface driver:

    Support interface drivers that don't support mtu parameter for plug_new

    The method signature before Mitaka did not have the mtu= parameter. We
    should continue supporting the old signature, since it can be used in
    out of tree interface drivers. The class is part of public neutron API,
    so we should make an effort to not break out of tree code.

    Local modifications:
    - don't issue a deprecation warning in minor release update.

    Change-Id: I8e0c07c76fd0b4c55b66c20ebe29cdb7c07d6f27
    Closes-Bug: #1570392
    (cherry picked from commit 8a86ba1d014a5e758c0569aaf16cfe92492cc7f1)

    ===

    Change-Id: Ic091fa78dfd133179c71cbc847bf955a06cb248a

[Thierry Carrez (ttx)]

This issue was fixed in the openstack/neutron 7.1.0 release.

[OpenStack Infra (hudson-openstack)]

Related fix proposed to branch: master
Review: https://review.openstack.org/342958

[OpenStack Infra (hudson-openstack)]

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

commit a9133b7255355942a386756ef98df0bee6f0c33b
Author: Ihar Hrachyshka <email address hidden>
Date: Fri Jul 15 18:14:12 2016 +0200

    Remove deprecated network_device_mtu option

    The right way to configure Neutron to work with infrastructure MTU is by
    using plugin agnostic global_physnet_mtu and ml2 specific
    path_mtu/physical_network_mtus options. The deprecated option is error
    prone and does not allow to use different MTUs per network.

    Closes-Bug: #1603493
    Related-Bug: #1549470
    Related-Bug: #1542108
    Related-Bug: #1542475

    DocImpact Remove all references to network_device_mtu option from
              Neutron documentation. Note that Nova has a deprecated option
              with the same name that will need a separate patch to be removed.

    Depends-On: I8e6cc99fe70d0c41a705431fb3160e8fccacff10
    Depends-On: I337b284076a794027fbd63796119d56bd1923cf2
    Change-Id: I7287db9df25a78a59b2dfa28acfde7fe69d17f40